对思科的期望：在路由器中实现虚拟服务器

　　上述路由器能够运行那些使用思科提供的SDK创建的第三方应用程序，这也是思科试图借用虚拟化技术取代网络基础设施服务器的第一步。虽然IOS还没有像Windows系统那样开放(思科已经在支持Linux系统，且该系统本身就是开放的)，但它仍然能允许用户将第三方应用程序植入ISR，这样就削弱了用户数据中心的回流数据量，从而减少了分支机构路由器的工作负载及压力。

　　虽然思科在进军服务器领域的战略上曾是呼声最大的厂商，但是它并不是唯一一家在路由器中装载可以运行第三方应用的平台的厂商。人们更应该把对投身这一技术的赞誉给予3com公司，因为它早在1年前就已宣布其OSN(开放服务网络)可以作为应用程序的植入平台，并且当时Riverbed也已经推出了WAN(广域网)优化的简易版产品。

　　从宏观部署来看，思科的产品与3com的产品非常类似：两者都涉及到了分支机构的路由器，但是两者都没有直接在路由器上放置第三方应用。相反，思科和3com都将第三方应用运行在一个独立的新加模块上，该模块实际上就是一个递减的刀片服务器。如果相比仅用软件途径植入第三方应用的Riverbed，思科和3com采用单独再加一个模块的方式的确增加了用户成本，但是对于x86平台，当这些应用程序正在和路由器争抢运行中必需的处理器、内存以及硬盘资源时，采用单独的模块则更有助于从路由设施中分离应用程序对资源的争抢。

　　而当3com一直采用单一的OSN模块时，思科却因为有不同的ISR模型而拥有不同扩展刀片的两个独立产品，并且有适用于中高端1841、2800以及3800的ISR，同时适用内存的容量范围为256MB~2GB。思科的这些型号并没有参照很多服务器的标准(或其他任何标准)，但却类似于3com的1GB模块。当然，思科和3com的研发目标都是非常希望由分支机构少量工作人员使用的服务能运用到这些模块上，而不是使整个数据中心都虚拟化。

　　思科的模块运行在所谓的AXP(应用扩展平台)上，并且其IOS的一个新版本是基于Linux平台的。这种设计理念使模块中植入应用程序相对容易一些，但是思科特有层的存在意味着该操作系统并非对任何Linux分发方案都是一致的。至少，Linux应用程序需要再次编译，而对于那些有效访问路由器的特性，用户还需要重新使用API编写访问程序。

　　但是无论如何，路由器不会只承载某些应用程序，它的安全架构需要有标识的代码，而且思科一直对自己标识的那些私有密码戒备森严。放置在路由器上的每一个应用程序，即使是那些用户开发来完成内部应用的程序，也必须在运行之前得到思科的允许。对此，思科方面的解释为，一个应用程序显然只有在得到许可后，用户才可以无偿得到标识的密码，但是需要完全由思科许可的想法，本身就会很自然地导致一些用户对路由器开放性的质疑。

　　API仅仅是应用程序能够直接在模块上运行的实现途径，意思是模块内存的系统规定参数空间严格限制了其上能运行什么样的应用程序。然而，用户或第三方开发者们可以通过在模块上编写代理来客服这些限制条件，这个代理可以将数据输送到其他地方的Java或Windows服务器上。

　　就像3com一样，思科也已经签署了好几个合作伙伴来共同开发路由器应用程序，但是这两个企业却有着不同的合作战略：思科已经在很多领域拥有了自己的产品，如安全、VoIP以及3com也正在攻克的应用。最初，思科有九家合作伙伴，包括Avocent，该厂商旗下的LANDESK管理软件将能被运行在路由器上。其他合作伙伴则都是统一通信领域或指向特定产业领域的。举例来说，当NICE系统公司需要面向金融服务和政府部门记录电话时，Sagem-Interstar公司正好有一个应用是截获VoIP线路中的传真电话的，思科的分销商ICW系统公司就将医疗记录保持应用与ISR绑定，并称该植入应用后的设备为保健型路由器。

　　显然，诸如思科和3com所重视的第三方应用植入路由器的思路，很大程度上为用户减少了各种应用服务器在硬件上的开销，同时又能减少应用中产生的下行流量。只是随着时光的变迁，加之各种网络优化厂商，如Riverbed等厂商的努力，思科在路由器上的突出优势能否继续延伸到植入应用后的市场认可中?思科的网际开放战略是否真正能给用户带来应用的开放?用户选择怎样的优化策略能更有效达到高的收入支出比?用户似乎还需要拭目以待!