早在SOA刚开始引起关注的时候，其目的只是为了把应用功能作为共享服务来提供。许多公司在发展过程中组建了各自的SOA架构，当然现在仍在这么做。只不过区别在于，在过去的几年里业务部门更加了解IT具有的战略价值，而IT部门也更加了解业务部门所要承受的竞争压力。因而， SOA就有可能让IT部门和业务部门之间比过去更紧密、更协调。

业务部门需要可重新组合的一组服务，从而获得新的业务流程来支持新的产品或者服务。而SOA的作用正是发布这些服务，并提供稳定一致的框架。按照该框架，服务可得到治理并编制成应用。虽然许多SOA计划仍处在早期阶段，但提高业务反应能力的承诺却是实实在在的。我们也看到越来越多的企业正向更高级的部署阶段迈进。

下面介绍的这些案例，就是实施SOA的典例。

康卡斯特公司依托领域专门知识建立SOA

你在决定要采用SOA方案时，忍不住会开始购买企业服务总线（Enterprise Service Bus,ESB）、注册中心及其他工具。康卡斯特（Comcast）公司负责应用架构和IT治理的高级经理Tom Adler说，但是这忽视了SOA的重要价值：你可以把创建及部署的应用与它们执行的业务流程结合起来。从架构入手有助于确保你有合理的框架做到这一点，无论现在还是将来需求变化时都是如此。

一年半前，康卡斯特（Comcast）公司启动这个项目时，顶住了请来厂商的诱惑，而是请来了专家，弄清楚公司首先需要什么。而所有厂商只想把ESB卖给康卡斯特。架构方面的工作不仅仅在于确立框架，还要开始确认你在业务流程和应用方面哪些地方存在冗余。这是得到业务部门认可及支持的关键，因为这非常具体地表明了哪些地方有机会节约成本，从而有助于证明有必要对SOA基础设施和工具进行投入，还能表明在何处使用通用服务有助于减少维护和整合方面的复杂性，以便将来提高开发工作的响应能力。而这个目标让公司可以消除冗余服务。

开发架构之后――Adler称之为通用领域模型，康卡斯特的下一步就是开发治理框架，用于服务开发及部署。服务必须进行治理，否则没有人会知道存在某一服务，也不会遵循相应的政策和程序。只有经过治理的服务才添加到服务注册中心中，供其他人重复使用。

很快出现的一个治理挑战就是决定谁拥有服务。康卡斯特公司相当分散，所以这种企业文化自然支持让服务创建者拥有其相应领域的服务。像单次登录这些通用服务自然属于IT部门。

Adler现在意识到康卡斯特漏掉了一个步骤，就是在确定架构后还要开发通用数据服务模型。由于没有标准的数据服务访问公司信息、管理系统之间的相互关系，所以开发人员最终开发的服务以不同方式来完成任务，从而导致不一致性，因而无法兑现SOA的承诺，即轻松实现服务组件的混合搭配。事实上，康卡斯特先前低估了这一重要性，而代价就是事后改动了一些服务，强制使用这种模型。　　

与单单认为SOA只是技术问题相比，康卡斯特的SOA项目注重架构。这有助于SOA概念得到更广泛的应用，因为公司一开始并没有认为SOA意味着单单使用Web服务，而是把SOA概念运用到了所有项目中，不只是明显具有Web服务功能的项目。Web服务只是公布服务的一种方式――它只是个实现细节而已。实际上，内部的初期SOA项目大多针对遗留应用，从而减少了公司内外（如外部的开票公司）的集成点，而这是让业务部门深为头痛的一大难点。

举例说，开发人员平时使用最适合各自的知识及所构建应用的众多工具和编程语言。由于使用标准的流程和政策，而不是特定的工具和技术方法，开发人员可以更好地遵循架构的意图，而不是让每个项目受制于某一特定的工具或者技术。既遵循统一架构，又允许技术多样性，这也是有实际原因的，在一家有9000名员工的公司，让每个人都使用相同方法是不切合实际的。

类似于那些大规模的公司还要适应不断变化的业务需求和技术机遇。所以定期评审参考架构很重要，避免它不成为约束性措施或者一纸空文，那样就没人会理睬。不管出现哪一种情况，你都得不到SOA的好处。虽然架构不是每个月都在变化，但在康卡斯特公司里Adler还是每个月都要评审一次。

Leapfrog愿意考虑开源的SOA方案

各个地方的IT开发人员通常都面临这样一个问题：一年下来，不同部门开发的应用搬到网站门户这样的通用系统上后，根本无法很好地协同运行。

2007年初，Leapfrog Enterprise就遇到了这样的困境：当时这家玩具公司需要稳定一致地为供应商和顾客提供各种应用，希望更充分地利用基于互联网的商业交易。Leapfrog Enterprise公司的系统基础设施主管Eugene Ciurana说，公司在今年3月决定需要一种新的方式来开发应用，于是启动了SOA项目，最初的努力如今收到了成效。他说：“我们希望为Web基础设施和系统奠定基础，于是我们从新的起点开始。”

Leapfrog有着典型SOA项目通常会有的许多目标：更多地重复使用代码、缩短开发时间以及方便整合。但是这家公司不想让SOA对开发工具和整合平台而言只是“换汤不换药”。相反，Leapfrog希望自己的开发人员能从遵循某个平台的最佳实践概念中解放出来，以便致力于应用的功能、使用最适合每项任务的一系列广泛的开发技术——Leapfrog的开发人员现在使用诸多开发技术，包括Java 5与Java 6、微软的C#以及附带各种第三方库的Web服务。

举例说，Ciurana不想迫使开发人员都使用相同的传输机制。按照他的说法，如何传输并不重要。他决定使用开源的Mule ESB作为消息传输骨干，靠它来处理诸多传输接口。这样一来，开发人员可以尽量少去关注服务的实现，而是把精力集中所要实现的功能上。结果就是，开发人员往往使用HTTP作为传输机制，不过也有人使用代表性状态传输（Representational State Transfer，REST）和简单对象访问协议（SOAP）。只要效果最好，或者开发人员觉得用起来最方便，什么传输机制都行。有了Mule ESB的方案，开发人员他们用不着担心在特定的SOAP堆栈中有什么或者使用什么集成开发环境（IDE）。Ciurana之前在沃尔玛网站的时候就用过Mule，所以他确信这是Leapfrog的“新起点”项目需要的基础。

Ciurana 指出，Leapfrog之所以能采用这种方法，是因为把重点放在了整合应用上。大部分整合是在应用层面进行的，即应用与应用进行联系。所以应用只要进行输入及输出。开发人员把服务作为普通的Java对象（Plain Old Java Object，POJO）来编写，让Mule ESB把POJO“传送”到消息传输网络，从而在ESB里面完成各种转换。如果你使用SOAP和REST，往往通常会考虑如何连接外界。但要是使用POJO，就用不着这么做。

Ciurana还喜欢Mule ESB的简单，因为只需要管理消息传输。所有商业的SOA厂商都希望把一整套产品卖给用户企业。不过这只不过从一种专有的SOA系统换成另一种专有的系统。由于使用Mule ESB，Leapfrog必须组合SOA堆栈的各层，但Ciurana乐于付出这样的代价，以换取使用上的灵活性。

Leapfrog使用两个ESB，一个ESB用于管理企业资源规划（ERP）、活动目录和数据仓库等内部系统之间的数据流以及应用相互联系；另一个ESB用于面向客户、基于Web的应用，譬如提供给消费者的客户账户自我管理应用和在线游戏。这不但为安全管理和访问管理带来了自然的界限，还提供了为对方充当后备的功能：一旦需要，其中一个ESB就能接过另一个ESB的工作。

Ciurana指出，Leapfrog确实不得不创建通用的服务命名模式，以便服务在每个ESB上都能运行。要求极其准确的名称可以让所有服务井然有序。为了获得ESB方面的自由，这是很小的代价。

美国联合航空公司结合SOA与事件驱动架构

尽管SOA概念很合理：把业务流程分解成各个构成元素，然后开发独立的软件服务，让你在需要时对组件进行配合搭配，从而满足各种业务要求，但是它假设：你在处理的是不相关联的事务处理功能。SOA的这个基本前提要求：业务功能应当是几乎能够以不受限制的方式来组合。

但许多业务任务不是可以这样分解的，而是依赖特定的事件顺序。航空公司就是使用事件驱动流程的一个典例，所以它们部署了事件驱动架构（Event-Driven Architecture，EDA）来处理事件。美国联合航空公司的中间件工程经理Ramnath Cidambi说：“EDA完全面向流程，而SOA涉及的是不相关联的黑盒子（即未知因素）。”他指出，两者各有一席之地。毕竟，航空公司也有机票预订和座位安排等事务处理系统，而不是只有事件驱动系统，如飞机着陆后调度运送燃料的卡车，或者航班到达后更新航班信息牌等系统。

联合航空公司很早就投资EDA，七年来使用IBM公司的WebSphere作为消息传输总线。在过去的一年，这家公司启动了SOA项目，处理公司网站上使用的现代化Web服务。但是这两种环境大不一样，所以它们有可能并行存在。不过随着公司开始在内部运营方面添加事务处理服务，这种情况正在开始发生变化，譬如利用文本消息（使用Web服务）通知客户服务代表当天的时刻表，使用人力资源系统查看谁在值班、谁请了病假等等，从而安排人员负责各个机场的不同登机口。这使Web服务与事件驱动流程处于同一环境中，从而使这家航空公司除了网站项目外，还可以启动SOA项目。

联合航空公司的挑战在于，弄清楚如何设计服务架构，并把服务部署到拥有而且需要两套架构的公司环境。虽然这家公司的内部运营使用两套架构，但不能完全分开来对待。毕竟，航班取消（一个事件）也会影响到事务处理系统（如重新调度航班、更新基于Web的航班状态查询工具，或者发放代金券）。许多流程既包括事件部分，又包括事务处理部分：客户服务代表从事务处理系统得到当天的时刻表，而航班取消、天气造成的延误等因素会导致航班状态出现变化，原来的时刻表很快就会失效。事件驱动系统可以跟踪航班状态，调度事务处理系统随后通过定期查询航班状态（航班的显示屏使用同样的流程）来重新调度人员。

最大的挑战在于弄清楚消息传输系统。ESB并不使用Web服务标准之外的标准，所以如何处理事件驱动服务并不明朗，还会由于使用不同的产品和工具出现不一致。不过，吸引Cidambi的是使用ESB同时用于SOA和EDA，因为它们可以很好地处理消息传输、数据转换以及其他关键的数据路由任务。

如今，美国联合航空公司有两个ESB，一个用于EDA服务，另一个用于SOA服务。它使用IBM WebSphere集成代理器，作为面向发布和订阅的消息传输平台，用于事件驱动服务。需要时可传输事件，并且处理服务之间的任何转换――其实是充当EDA的ESB。至于传输方面，现有的J2EE应用完全面向消息传输，所以都使用Java消息服务（Java Message Service，JMS）而不是Web服务作为消息传输标准。

该公司采用了BEA AquaLogic ESB用于其SOA服务，因为Cidambi期望这个比较新的平台会更适应比较新的SOA概念；更适合公司里面使用的WebLogic服务器环境和Eclipse开发环境。AquaLogic基本上在WebLogic上运行，所以不需要整合。

Cidambi没有把EDA服务迁移到AquaLogic上，也是为了避免不必要的工作；他指出， WebSphere运行相当好。要是迁移到新的ESB，势力会出现干扰和意外情况：公司用了七年的时间来优化WebSphere平台、解决运营方面的问题；迁移到像AquaLogic这些新的ESB需要马上投入精力；毫无疑问，新的问题也会暴露出来。

Cidambi面临的另一个问题是EDA方面缺乏标准的XML模式（XML Schema）。这样一来，在EDA服务和SOA服务之间传输消息就变得更复杂、更费力。

汤姆逊金融公司自动实现服务遵从治理

许多公司之所以青睐SOA概念，是因为它有望缩短开发时间。但是一些SOA开发人员却发现，服务治理的一个重要方面实际上会减慢开发速度，从而使有望加快速度的优点荡然无存。金融出版及信息服务公司汤姆逊金融公司负责产品管理核心服务的副总裁Vladimir Mitevski回忆道，该公司在SOA项目的早期阶段就发现了这一令人讨厌的意外事实。

Mitevski指出：“服务要成为一种企业生产资产，就要符合几种方法和政策。”有不少要求非常苛刻：比如XML元素的名称不能用缩写，还必须是字典里真正有的单词；而用户名和密码等一些条目不能用硬编码。如果你只有少数几项服务，那么企业架构团队通常能跟踪并且发现得了任何问题。但很快，评估人员就会成为瓶颈，甚至由于工作负担加大，开始疏漏一些问题。

汤姆逊金融公司有成千上万的服务：细粒度服务、粗粒度服务以及介于两者之间的服务，负责架构的人员却很少，于是公司马上感到了问题的棘手。Mitevski说：“不管粒度如何，每项服务都要经过评估这个流程。”只有那样，才可以进入服务注册中心。同样，变化了的服务需要评估，弄清楚是否遵从治理；只有符合规定，新版本服务才可以登记入册，供生产环境使用。但架构办公室因人员少而成了瓶颈。

考虑到涉及的应用都非常关键，譬如单次登录服务、为分析师和交易商提供金融市场信息的Web服务，以及可通过微软Office获取的基于Web的金融分析和图表服务，所以降低遵从要求不是一个好方法。

汤姆逊公司解决治理遵从工作负担这个问题的办法就是，求助于自动化技术，并使用WebLavers公司的政策评估工具。Mitevski说：“这些工具比较有效，不会漏过违反治理的情况。”公司确实花了一番时间来制订政策，以便工具可按照政策来评估遵从治理的情况。关键的是，架构师要评估工具的分析结果，弄清楚是否一再出现可能表明开发人员对重要政策缺乏了解，或者表明架构不清楚的某些问题。Mitevski说：“这帮助我们看清哪些方面可以改进；有些政策的确需要调整。”不过他发现，大多数违反治理的情况归咎于开发人员抄捷径。架构师也要确定何时允许开发人员出现不遵从治理的例外情况，不过这种情况极少发生；而且例外情况要记录在注册中心，以便告知其他用户。

对汤姆逊金融公司而言，服务遵从治理实现自动化带来了显著成效。过去要不同部门涉及某一高度编制的流程的20个人才能推出某项服务，而现在只要一个人。

捷普集团简化客户整合

侧重于制造服务的公司需要照顾到一系列客户整合，比如诸多客户使用的许多系统之间的开票、预测和订单等系统。可是随着你的客户群不断扩大、客户完善各自的系统，要管理所有这些点对点的沟通就困难重重。这就是为什么许多制造商求助于交易中枢的第三方供应商，它们又叫增值网络（Value-Added NetworksVAN）；这样，对于每一种供求关系，每个供应商和客户只要关心与VAN的单向沟通。

但如果你与客户之间的定制流程是标准的VAN无法满足要求的，那这种方法就不管用了。捷普集团（Jabil Circuit）这家定制电子产品制造商对此深有体会：当时通过人工维护所有那些定制的应用和界面，来面对这个难题。捷普有5000多个交易合作伙伴，不过大多数使用VAN方法就能应付得过来。不过有50个客户需要特殊的沟通机制或者业务流程，Sterling Commerce VAN正是为此而设计的。捷普集团的电子商务经理Lowel Gilvin回忆，通常每个客户都会有好几种这样的定制联系，这就加大了工作难度。必须进行某种改变，于是捷普采用了SOA原则，用可以重复使用通用功能、基于服务的联系取代了大多数这些定制联系。

第一步是把把订单到收款管理、预测和库存寄售等业务流程与联系流程分开来。如今，捷普为使用的大多数联系机制采用了标准服务，如适用性声明1（AS1）、适用性声明2（AS2）和FTP等机制；还为XML、平面文件、Excel和SAP iDocs等格式采用不同的数据处理服务。它为每个这样的客户组合了相应的联系服务、数据处理服务和业务流程，大多数情况下，使用表格和数据来自动完成组合。Gilvin指出，在有些情况下，客户使用不止一种联系机制，可能取决于涉及哪个部门；表格对这多种机制进行说明。

Gilvin指出，SOA的抽象、模块化和服务组合等概念通常可以适用。在某些情况下，通过组合服务满足不了特殊要求，于是捷普仍需要维护某些一次性的整合。但即便针对这方面，捷普也往往可以使用SOA方法作为整合的一部分。举例说，XML和SSL验证所用的证书无法作为标准服务来处理，因为证书具有惟一性，但捷普能把相应的联系服务和业务服务与硬布线的数据处理服务组合起来，让三个整合方面中的两个方面仍然享有SOA的重复使用和一致性等优点。

捷普不是使用ESB来管理消息传送、使用注册中心来管理服务存储库、或者使用面向SOA的开发环境来开发服务，而是使用Sterling Commerce的Gentran整合套件来满足上述三个用途。该套件是为了整合供应链的关系而设计的，这也是捷普竭力要管理的方面。正是这种有限的范围让捷普可以依赖这套工具的嵌入式架构，而不是自行建立架构。Gilvin指出：“我们有一小组标准的业务流程。”

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号