面向服务的架构（SOA）绝对是一大热门。但是，重新调整网络以适合Web服务应用的时机是否成熟呢？

　　由于Web服务规划仍处于早期阶段，大多数组织在谨慎地改进IT基础设施，以顺应这股潮流。至少，这是面向服务架构（SOA）背后的思想。这个眼下最热门的概念备受Web服务厂商、分析师和幻想家的推崇。SOA也许是一个好东西——前提是实施得当。

　　严格说来，SOA并不是什么新概念，只是通过网络上可以发现的共享服务来提供应用功能的一种方法。其原理是，通过把应用程序从底层硬件提取出来，从而提高资源使用效率。有了可以重复使用的软件组件，就可以简化定制应用程序的开发，这样与使用依赖特定服务器的服务相比，IT人员就可以更有效地满足最终用户的需求。

　　就在不久前，这个概念还很难付诸实践，主要是因为SOA历来依赖专有的中间件，这种中间件往往让获得的各种效率荡然无存。Web服务的出现改变了这种局面。由于整个行业投入到了XML、简单对象访问协议（SOAP）、Web服务描述语言（WSDL）以及通用描述、发现和集成（UDDI）的标准化工作，使用所有竞争厂商都支持的接口，就可以发布、发现及调用服务。 SOA不仅仅是Web服务的集合体，也是发布、发现、运行及管理支持企业应用的服务所需要的技术架构。虽然Web服务确实简化了SOA的推广，但它仍影响网络性能和IT安全的关键决策。

　　不成熟的Web服务让设计SOA进一步复杂化。仍在竭力应对XML的企业面对不断变化的标准无所适从。原先来自不同市场的厂商开始竞相提供SOA解决方案，都声称各自为这种架构提供最重要的部分，无论是管理、安全和开发工具，还是让SOA有别于独立式Web服务的中间件——企业服务总线(ESB)。其中一些解决方案对SOA至关重要，另一些方案将依赖现有的IT架构和组织目标。

　　值得一提的是，SOA不是套装应用软件，也没法从哪家厂商处购得。实际上，SOA可能根本就不需要任何附加的软件或者技术。

　　SOA上路应用效果明显

　　SOA的主要优点是灵活。不像以前的计算模式如客户/服务器和大型机环境，SOA把IT功能作为跨平台的共享服务来提供。这带来了诸多好处，但最立竿见影的就是可以通过重复使用现有资产，获得明显的投资回报。

　　一旦SOA中有了一组Web服务，这种重复使用好处就会急剧变大，这就是“SOA网络效应”。SOA的价值会随着可用服务的数量以及使用这些服务的不同应用程序或者用户的数量而增加。这种价值会随着时间的推移不断增大。如果SOA在组织内外得到利用，增幅会更惊人。

　　企业开始可以让SOA用于内部服务，然后扩大范围，用于面向客户的应用。这需要与商业合作伙伴交换XML数据，这种做法在电信业和旅游业变得越来越常见。SOA还有助于面向客户的B2B应用，在这种情况下，用户并不知道底层的基础设施。

　　譬如说，一家银行可以使用客户的门户网站，支持客户查询和要求访问多个遗留后端系统的自助服务功能。SOA方案可以把这些功能作为Web服务，提供给面向客户的门户网站和银行内部员工。这就减少了提供全面访问遗留系统功能所需的内部集成工作，因为所有应用都使用同一个SOA接口。

　　SOA的灵活性还可以让组织受益，因为可以加快应用开发，通过重复使用硬件部件和软件组件，来降低成本。用这种办法开发应用程序的其质量可能比独立开发的还要高，因为组件预先经过了测试，Web服务接口也已经得到了验证。

　　这些好处绝不是推测出来的。摩托车生产商Harley-Davidson之所以能够在短短三年内为经销商开发及推广IP电话系统，要归功于使用Web服务进行应用集成。该公司运行BEA Systems的WebLogic应用系统，并辅以自己内部设计的Java框架，以构建可以重复使用的SOAP服务。VoIP链路可以重复使用原先为CRM应用系统设计的经销商联系服务。

　　为SOA而开发的应用程序具有的速度、简洁和质量让许多分析师认为，这种架构是可以使企业目标与IT服务和功能相一致的一种方法。如果实施合理，其灵活性会渗透到整个网络、乃至整个组织。IT部门可以随意改动技术，不必对可用服务进行改变；企业也可以改变其应用程序或者业务流程，IT架构受到的影响极小。

　　在试图集成不同系统（如企业并购带来的系统）时，SOA的灵活性显得特别重要。譬如说，在自然增长和多次并购后，办公用品零售商Staples发现居然在使用五个重复的信用卡授权系统。Staples于是实施了五个系统都使用的Web服务，而不是改用单一授权系统，或者是构建多个接口连到每个后端应用程序。SOA提供了运行时支持、管理和安全功能，这样，五家银行和票据交换所当中哪家能够为某笔支付提供最佳服务，Staples就可以通过它来转发信用卡交易信息。如今，Staples每年总共要转发100万条交易信息。

　　没有Web服务的SOA面临挑战

　　可以实施没有Web服务的SOA。这种概念自面向对象技术兴起以来就已存在，表现为远程过程调用（RPC）中间件解决方案，如微软RPC和Java远程方法调用（RMI）。这些解决方案基于公共对象请求代理体系结构（CORBA）、分布式计算环境（DCE）以及组件对象模型/分布式组件对象模型(COM/DCOM），实施的是同步的客户/服务器通信模式。一个应用程序在其中充当客户机，另一个充当服务器。

　　与Web服务相比，这种模式有两大缺点:首先，同步操作会减慢应用程序的运行速度，因为客户机在服务器完成请求处理之前一直处于闲置状态。其次，类似RPC的解决方案通常是专有的，无法跨平台协同工作。最大的难题在于找到一种单一的RPC解决方案，能与各种所需的编程工具和计算平台兼容，还要价格合理。

　　譬如说，尽管CORBA得到了最广泛的平台和语言支持，但它很复杂也很昂贵。Java内置了支持CORBA和RMI的功能；微软的Windows支持DCOM和微软RPC；大多数Linux和Unix平台支持开放式网络计算（ONC）RPC。这样一来，跨异构计算环境实施单一的RPC解决方案也就成了难题。

　　面向消息的中间件（MOM）为解决RPC的两个问题起到了一定作用。MOM解决方案实施的是异步对等通信模式，这样应用程序在等待来自另一个应用程序的响应的同时，就可以继续处理正常事务，譬如IBM的WebSphere MQ、Sonic Software的SonicMQ、微软的MSMQ和TIBCO Software的Rendezvous。这种方法通常与松散耦合连接有关，这样一来，消息处理方式有了更大的独立性。

　　不过MOM在解决问题的同时也带来了问题。MOM解决方案的缺点在于：实施起来往往比基本的RPC来得复杂，也很昂贵、具有专有性。虽然Java平台提供了Java消息服务（JMS）API，可以连接到几乎各种MOM产品，但SonicMQ无法与WebSphere MQ协同工作，WebSphere MQ也无法与Rendezvous进行联系。这两种应用系统想联系，就必须使用相同的中间件层。

　　使用Web服务的SOA类似于使用MOM的SOA，不过用支持同步RPC和异步消息传送的开放标准取代了专有的中间件。无论SOA运行在Sun的J2EE上、微软的.NET上，还是运行在遗留平台上，都使用同一行业标准——XML来提供服务。

　　注册中心、ESB和WSM是SOA的核心

　　SOA要发挥作用，就得有许多核心架构要件。大多数SOA用户会看到的第一个部分就是服务注册中心（services registry），它通常基于面向Web服务目录的XML标准——UDDI。

　　第二个部分就是企业服务总线（ESB），又叫Web服务代理，它负责处理消息，把流量转发到最合适的应用程序或者服务。如今ESB越来越多地与监控SOA性能的Web服务管理（WSM）平台结合在一起。

　　最后，Web服务安全或者身份管理解决方案通常少不了。

　　1．需要注册

　　服务注册中心充当信息库，存放着SOA当中有可用的Web服务信息。注册中心本身使用UDDI来加以发布，而客户机在调用服务时，需要WSDL文档。因而，客户机或者用户就可以浏览UDDI注册中心，然后请求某项服务所需的WSDL文档。一些厂商通过独立产品提供UDDI注册中心，譬如Systinet、Cape Clear Software、IBM、微软和Novell。不过若要构建SOA，与Digital Evolution等公司的WSM平台进行捆绑的服务注册中心可能更吸引人，因为那样两者可以紧密集成。

　　WSM本身为调用Web服务提供了运行时环境，还负责管理服务运行、执行服务级别协议（SLA）。SOA市场有着大量的解决方案，包括Actional、AmberPoint、Infravio和Service Integrity等。

　　一些WSM厂商强调自己在这一大类当中提供不同的功能，不过它们通常提供相似的功能。譬如说，Digital Evolution强调安全和可靠消息传送功能；Infravio强调管理SLA的功能；Service Integrity强调监控和可见性;其他厂商则强调负载均衡和故障替换这些操作。WSM厂商们也在开始整合其他产品类别的功能，包括安全和ESB这两类，旨在逐步构建完整的SOA解决方案。

　　2．混合搭配

　　如今，还没有哪家厂商能够提供单一、综合的解决方案。SOA也需要ESB把XML解析成SOAP消息或者其他Web服务消息，然后相应地转发或者转换这些消息。旨在增强现有IT架构的ESB还为开始向SOA迁移的组织提供了一系列稳健的功能。许多厂商提供独立的ESB，包括Sonic、Fiorano Software、Cape Clear和Blue Titan。

　　一些分析师预计，WSM系统和ESB会在将来趋于融合，因为两者功能有重叠之处。其实，有关ESB的一份白皮书声称，ESB是“预包装的SOA实施方案，已经包括了实现SOA目标所必需的功能部件”。这番夸大之辞忽视了SOA的许多核心功能，譬如管理和服务发现功能。ESB功能是任何SOA的一个关键方面，但仅有它还不够。

　　3．服务安全

　　与网络上的其他各种资源一样，Web服务也需要确保安全。Web服务安全方面的标准已成了所有厂商关注的焦点，这些标准往往分为两大类：Web服务安全本身和联合身份管理（federated identity management）。

　　这两类都为具体实施提供了诸多选择。WSM解决方案（如Digital Evolution的方案）往往包括了对基本Web服务安全标准的支持，而Forum Systems和Reactivity等厂商提供专用的安全设备。联合身份管理通常包括在Netegrity、Tivoli、RSA Security和Novell等厂商的单次登录（SSO）解决方案里面。

　　Web服务安全通过Web服务安全（WS-Security）和安全声明标记语言（SAML）这些新兴标准，满足对验证、授权、机密性和数据完整性的需求。WS-Security 和SAML都基于现有的安全标准，从基本的安全套接层（SSL）、X.509证书、XML签名到XML加密等。

　　自由联盟（Liberty Alliance）负责基于标准的联合身份方面的大多数工作。基于SAML的联合身份把权限与身份联系起来。在SOA当中，用户和应用程序都一定要有身份。

　　随着Web服务从内部集成项目，扩大到针对客户和商业合作伙伴的面向外部的服务，联合身份也变得越来越重要。这会导致WSM厂商和身份管理厂商加强合作，前者拥有经过实践证明的保护Web服务安全的解决方案，后者扩大了SSO解决方案，以支持Web服务应用程序和SOA。

　　另辟蹊径的附加方案一样精彩

　　除了注册中心、ESB和WSM外，大多数SOA还包括取决于组织特定需求的其他部分。如果某家企业自行开发工具，会需要Web服务开发和编程工具，譬如集成开发环境（IDE）和WSDL编译器。

　　一旦SOA达到临界数量，核心架构可能也会得到其他新兴解决方案的补充。其中一些方案非常吸引人。譬如说，SOA策略和监管解决方案可以帮助网络设计师定义及执行Web服务访问规则。元数据也很重要，因为XML具有无限可扩展性。而WSM解决方案必须能够处理及管理Web服务文档里面的所有元素。

　　即便没有SOA，Web服务也需要使用附加产品。XML加速或者安全设备在组织内部的Web服务数量激增时，可以提供逐步提升性能这一重要功能。

　　为实施SOA提几条建议

　　SOA市场出现了群雄逐鹿的局面。SOA新兴公司提供先进工具，来帮助企业构建及运行SOA和其他Web服务，向拥有庞大用户群的老牌厂商叫板。IBM、微软、SAP和甲骨文等老牌厂商也绝不会轻易把控制权拱手让给WSM和ESB厂商。

　　网络设计师真正面临的问题就是找出促使实施SOA的主要动因。这些动因通常与SOA的灵活性带来的诸多业务和技术问题有关。譬如说，往往启动SOA和Web服务计划的是一些至关重要的商业需求，譬如获得收入和客户忠诚度、提高内部的IT和业务效率，或者降低成本。明白这一点，有助于阐明需要哪些SOA核心解决方案，以及实施的先后顺序。
　
　　譬如说，如果SOA的主要功能是提供面向外部的Web服务，那么最重要的功能就是可靠的安全和WSM解决方案。如果某家组织的初期目标是致力于集成，那么用Web服务替换或者补充企业应用集成（EAI）策略，就能获得投资回报。这种情况下，SOA可能需要基于ESB、并且结合现有的消息传送和集成技能的解决方案。

　　现有用户群也会影响到迁移到SOA的决策。有J2EE架构的组织可能会根据应用服务器解决方案如BEA的WebLogic或者IBM的WebSphere，来制订SOA策略。同样道理，SAP用户会倾向于把NetWeaver作为SOA的中心。不过，这些观点忽视了两个关键问题。首先，这些技术解决方案本身不是SOA;其次，SOA也并非涉及哪一家厂商或者是哪一款产品，而是涉及让IT人员能够针对组织的需求做出更迅捷的响应。

　　理想的SOA最初应当从业务角度来开发，与任何厂商无关。这保证了重点可以放在SOA提供的服务上，而不是产品或者技术上。一旦确立了这个大环境之后，为了引入及支持SOA，应当评估现有IT架构和应用组合；也应当调查新的SOA解决方案，以便构建稳健的SOA核心。

　　每家厂商自然声称，自己的SOA方案是最重要的。ESB、WSM、UDDI和安全厂商都认为，单单自己的解决方案就足以把现有的IT架构转变为SOA，但实际上，所有这些功能缺一不可。设计网络时，首先应当关注SOA的哪个核心要素对用户的需求最重要，但这仅仅是第一步。将来，可能还需要全面的SOA解决方案。

　　最终，SOA解决方案必须始终支持组织的目标。也许，SOA方面的真正较量在于保持这个重点。实施SOA必须首先是业务决策，其次才是如上所述的技术选择。如果IT主管能够牢牢抓住这个重点不放，就不会为厂商之间的口水战所动，让SOA需求与业务目标相一致。

　　注：名词解释

　　● UDDI服务注册中心 让Web服务能够被应用程序看见。鼓励开发人员向UDDI注册中心发布所有服务，这样就可以为重用代码和共享应用提供一个平台。它往往是向SOA迁移的第一步。

　　● 企业服务总线 提供了可靠消息传送和数据集成基础。解析XML消息，基于内容进行转发和转换。

　　● Web服务管理 为Web服务提供了可见性和管理。监控服务可用性，以确保服务质量、执行SLA(服务级别协议)。还负责处理负载均衡、故障替换及Web服务可靠消息传送。

　　● Web服务安全 为外部用户或者应用程序访问的Web服务提供了安全环境。包括加密、数字签名、验证、授权、机密性、数据完整性和不可否认性。可能与联合身份管理解决方案结合在一起。

　　SOA风险评估

　　作为一种概念，SOA已成熟。但实现SOA的Web服务技术并不成熟。XML、SOAP、WSDL和UDDI等核心标准在整个行业已得到接受，而其他标准如安全所需的标准还处在发展中。许多组织要投资于SOA，势必要进一步确定SOA与经营业绩有什么明确关系。

　　SOA没有Web服务也可以实施，也已有先例，这个事实很鼓舞人心。这意味着，由于Web服务的进入成本较低，而且能够重复使用现有的IT资产，SOA获得成功的可能性就更大了。SOA可以采用诸多方案通过诸多方法来实施，不过对每个组织来说，它们各自的好处还不明显。如果用户在设计和扩建方面的需求压倒一切，SOA和Web服务会带来巨大影响。衡量成功的尺度要与组织的目标和业绩联系起来。即便业务和IT没有紧密联系，SOA也会给内部的IT系统带来好处，从而提高内部客户的满意度。

　　SOA存在两个风险:一个风险是，向SOA迁移过早或者过晚、未能充分发掘节省成本的潜力;另一个风险就是，SOA实施不当（也就是说，没有用Web服务），可能会导致组织被过时、专有的技术缚住手脚。