网络便是一切
当可重用的好处逐渐被人们所了解的时候，网络上的应用就如雨后春笋般涌现。如何确保这些已经过度开发的服务在网络上的传输呢?尤其在是它们还在不断地横向(使用不同的程序实现相同的服务)和纵向(编写程序提供新的服务)地扩展的时候。
使用XML工具，就可以从服务器到网络设备下载XML文档。XML网络服务的标准中指定使用XML头文件来描述常规信息，就好比IP头文件的用处一样。每当需要反应的时候，诸如Cast Iron系统应用集成套件、Forum系统的Vantage、Intel的XSLT加速器(一种XML加速器)，以及IBM的WebSphere DataPower和Cisco的Application Oriented Network line，都会提供对这些功能的支持。
RouteOne(位于密歇根州的汽车金融公司)的技术总监Subramaniam说到：“我们已经发现了DataPower的优势，RouteOne凭借其和一些商业巨头的合作，如戴姆勒克莱斯勒、福特、通用和丰田等，提供给汽车经销商一个单一的、基于网络的信用系统。汽车经销商可以往该系统中输入客户信息，并进行信用的认证，这样就可以将数据发送给多家汽车公司了。”
该系统是RouteOne在五年前，在传统的企业应用集成系统(EAI)的基础之上利用Java构建的。“但是这一系统是非常昂贵的，并且需要大量的硬件来支撑系统的运行。”Subramaniam补充说。然而，XML的信息革命已经开始了，RouteOne跃跃欲试，甚至没有耐心去等待Web服务标准制定的完成，如Web服务安全标准等，就踏上XML之路了。
Subramaniam的团队从电子商务领域(采用ebXML标准)，以及Java消息服务和数字签名中获得了灵感，创造了一个基于XML的高度安全的信息基础设施。他们打造了一个“非常轻量级的”系统，该系统现在被超过120家的银行和金融公司所使用。
但是，XML数字签名对于硬件设备来说，很可能是一场灾难。因此，RouteOne把目标投向了DataPower，并且开始用DataPower为XML应用设备服务，而这迅速成为了RouteOne SOA系统以及其应用程序工作流的核心。
最近，Subramaniam扩展了这些XML设备的功能，使它们拥有了更多的用途，并可以处理更多的应用。其不但可以负责处理XML数字签名，还可以把消息从一种格式转换成另外一种格式，比如，把XML格式转换成EDI格式。另外，还提供了诸如XML加密等安全保护功能，也包括了处理工作流的异常，比如当XML文件无法通过数字签名被有效性验证时，它们能够执行一项预定的任务。
Subramaniam介绍说：“从本质上讲，RouteOne把这项工作通过智能应用交由网络设备来处理，并创造了‘完全硬件化的企业服务总线’。而这些网络设备拥有很高的吞吐率，并且也能很好地得到扩展。”
“而人们不在本地进行XML处理的一个重要原因就是，这会消耗许多硬件和内存资源，使得应用无法大规模运行，并且扩展性受到了限制。因此，使用网络上的硬件资源，对于需要大规模处理XML的情况是非常有意义的。的确，你可以优化XML处理，但你必须很好地了解XML的处理过程，才能很好地做到优化。既然我们已经有了DataPower，为什么还要那么麻烦呢?”他补充说。
WinterGreen的Eustis也很喜欢这种方式，她说：“DataPower给了我们很多帮助，它很安全，它可以把数据包转换成消息，而这正是我们所希望的。因为假如你现在正在处理一些可重用的组件，你一定希望他们是消息的形式而不是数据包的形式。
正如Eustis所说的那样，当一个以Web服务为基础的SOA架构，再加上XML的处理器后，消息路由就成为了问题的关键。数据包转化成为了消息，消息成为了工作流中的一部分，并用于执行业务逻辑。而这正是网络应用的真正意义，也是网络团队需要密切监督SOA项目的原因。“事实上，配置一个XML设备应该是精通路由协议的那些IT专家的拿手活儿，但是这却不是一个普通的程序员所能够理解的。”Subramaniam说。
架构之争
虽然，基于面向服务的架构(SOA)的Web服务是基于标准的，但并不表示业界就不会对这种架构进行“宣战”。很多人同意并遵守基本的、经过实践检验的Web服务标准。这些标准包括：Web服务安全(WS-securITy)、SOAP和UDDI。另外，还包括下面一些被广泛接受的标准：包括基于XML的Web服务的Java API、商业过程执行语言(Business Process Execution Language)、Web服务可靠通信(WS-Reliable Messaging)、Web服务寻址(WS-Addressing)、SOAP附件(SOAP with Attachments)、消息传输优化机制(Message Transmission Optimization Mechanism)和Web服务策略(WS-Policy)等。
事实上，架构之争从来没有停止过，争论的焦点主要在于企业应当如何把Web服务拼凑成一个完全的SOA体系架构。有一种架构模型——服务组件架构(SCA)得到了BEA、IBM、Oracle、SAP和Sybase等公司的支持，但还有一家公司并没有支持。那就是微软。
对于Java阵营中的企业来说，SCA将带来极大的帮助。SCA的规格说明由“结构化信息标准优化组织”(Organization for the Advancement of Structured Information Standards)所制定，包括服务的封装、一个policy框架、混合和调谐几种类型组件(Java、C++、Web服务、COBOL)的技术细节，以及与Spring框架(一种J2EE的应用框架)的集成。
“SCA是封装复合应用程序的一个基础平台，它的确是让下一代的打包服务成为组件的方法，而这种组件能更好地被管理和被部署，并成为一个个能够与其他服务一起合作的单元。”Oracle的资深SOA技术专家David Chappell说。
“由于SCA紧紧地依靠着Java，因此，微软仍坚持自己的架构模型：Windows Communication Foundation(WCF)。”微软互联系统部门的产品管理总监Steven Martin说: “对于只使用微软的.NET的Crutchfield公司的 Weiskircher来说，在2005年WCF还在作为Indigo进行测试的时候就开始被认为是一个不错的选择。基于.NET的WCF使Crutchfield公司把五个原先分布的应用程序组合成为了一个大的、基于服务的应用程序，同时改进了整个应用程序的性能。最终，SOA是可能成为所有软件的默认架构，而现在，我们要做的是搭建一个已经经过实践检验、并行之有效的基础平台，来解决特定的商业问题。”
