在今天，很可能你已经开始着手进行一个或者两个SOA项目了。当然，这并不奇怪，在世界范围内的11000家大型企业中，有95%的企业已经开始投入某种努力去实现SOA了。

　　市场调研公司WinterGreen Research的高级分析师Susan Eustis介绍说：“这些SOA项目中的大部分都是以各部门之间或者是部门内部的互相协调作为开始的，随后开始逐步扩展，再后来就把用户的业务管理也包括了进去。可以说，SOA在扩大其影响力之前，也是从很小的尝试开始的。”

　　随着学术界和工业界的研究与实践的深入展开，原来笼罩在SOA头上的炫目光环也在渐渐褪去。仅存的一道光辉可能就是SOA被业界所接受的那条真理：对于SOA来说，网络便是一切。

　　事实上，并不是每一个项目都能与SOA完美地搭配，或者说，并不是所有的项目都能够很好地利用SOA这一架构模式。因为如果要想使其他项目能够重用一堆已经构建好了的服务(当然，假定这种重用并不难实现)，那么，在SOA项目或者SOA服务的初始建设阶段，往往需要花费惊人的代价。另外，那些元老级的技术，如.NET和Java，仍然流行于SOA的世界中。因此，或许有很多人会觉得自己的.NET或者J2EE程序运行得还不错，那就没有必要部署SOA了。

　　有分析师表示：“令人欣慰的是，SOA技术已经足够成熟了，因为它在不断地吸取实践过程中的那些经验和教训，现在已经是千锤百炼了。”而来自MindTree Consulting的CTO Kamran Ozair却表示：“在过去的几年中，SOA被吹捧成了‘下一个梦想’，因此，很多项目和工程就都被部署成为了基于Web的服务，而后来人们却感觉到，这并不是一条合适的发展之路。”

　　或许我们最大的教训就是学习到什么时候不应该使用面向服务的这种方法。“SOA并不是一条终结之路，你需要使用SOA的时候，往往是在你需要解决一个业务问题的背景下。”一家生产数字音频设备的厂商Crutchfield的IT主管Steven Weiskircher说。

　　Crutchfield公司开始SOA的破冰之旅是在两年前，那时公司升级了紧急任务目录、访问中心、电子商务和零售订单处理程序，在这些程序中90%都是自定义代码。Weiskircher介绍说，他的开发团队支持代码和对象的可重用性，而且团队中的大部分开发人员对于微软的编程工具也都比较熟悉，因此，他们选用了基于.NET的服务策略，但是后来他们马上意识到，他们不得不把关注的重点转移到业务目标上，而不是以前的技术目标。

　　“当然，软件开发的原则在几年之内并没有什么重大的改变。代码的可重用性，以及为了保护数据所产生需求的可持续性等，都是很有价值的设计原则。因此，对于服务来讲，有其发挥功能的地方，但也有其不适用的地方”。Weiskircher说。

　　在这其中，服务的延时性是问题的关键。“如果你把SOA看做是Web服务的话——不同的厂商对此有不同的争论——你应该意识到服务会给你的交易带来很大的开销。任何的传输都是依赖于多个组件的，并且会给网络造成影响，包括延时、抖动和丢包等。因为在20年前传输的是简单的ASCII文件，而现在却是时常臃肿不堪的XML文件。当你再在其上添加简单对象协议(SOAP)和Web服务的安全标准(WS-ScurITy)时，就有可能会增加延时，因为光是SOAP消息的封装和解析，就会耗费不少的处理器资源和网络资源。”Weiskircher解释说。

　　在决定哪一段代码应当抽象成SOA服务的时候，还需要考虑的是，服务可重用性带来的利益是否大于服务延时所带来的负面影响。如果代码主要是在同一台机器的同一个应用程序中运行，那么最好还是不要采用服务的方法; 但是如果代码被许多分布式的应用程序所重用，比如在一个工作流组件中的商业流程，那么把这段代码封装成服务就是适合的。

　　“比如，交易可能源自于许多不同的销售渠道，但交易所产生的工作流程却是类似的。不管销售渠道是怎样的，典型的工作流程都将包括收集资金、顾客信息和用户偏好等。这些都是共享的商业规则和可重用的业务逻辑，而基于Web的服务就会对这些流程具有重要的意义。”WeiSkircher说。

　　还有一些用户告诫我们说，可能很多企业的现存代码并不适合SOA。美国北卡罗来纳州夏洛特的Wachovia公司的资深系统架构师Tom Caddoo说：“我们的系统是对时间和延时很敏感的系统，这些因素往往会给我们带来非常巨大的损失。”

　　Wachovia公司通过考察自己的应用程序和执行环境，开始部署SOA。Wachovia认为，虽然可重用性有很大的诱惑，但是却不能够以牺牲性能作为代价。当然Wachovia也不愿意永远面对那些低效的已有代码。“我们也曾经疑问‘是简单地将现有的所有业务都封装成Web服务？还是需要将程序完全地重新设计？’然而最后的结果显示，我们的可重用程序与重新编写的程序之间的比例大约是50∶50。”Wachovia说。

　　网络便是一切

　　当可重用的好处逐渐被人们所了解的时候，网络上的应用就如雨后春笋般涌现。如何确保这些已经过度开发的服务在网络上的传输呢？尤其在是它们还在不断地横向(使用不同的程序实现相同的服务)和纵向(编写程序提供新的服务)地扩展的时候。

　　使用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是可能成为所有软件的默认架构，而现在，我们要做的是搭建一个已经经过实践检验、并行之有效的基础平台，来解决特定的商业问题。”