【IT168 信息化】
SOA基本概念已经得到了广泛的宣传，也被众多厂商和用户所接受。SOA作为一种新的软件开发范型，通过松耦合方式更好的实现了软件资产的复用，因而可以很方便地构建业务敏捷的应用系统，以应对不断变化的市场环境和用户需求。下面我们就从一些SOA的案例中寻找实施SOA的途径。
从Comcast公司到美国联合航空，这些大公司不分行业都已经开始纷纷投入到SOA领域之中，他们改变其组织计划、开发和部署企业应用软件以进一步的实现这一领先的IT技术架构理念。
SOA在最初发展的时候，目的仅仅只是为了使应用功能可以被作为共享服务来使用，这一点牵引着这个领先的IT架构理念一步一步走到现在。不过，企业从最初开始得SOA道路到现在，都还在建立属于自己的架构体系。相比之下，不同的是在过去几年中，业务方面的需求更好的体现了这一IT技术的战略价值，而IT方面也更多的了解了业务方面需要承受多大的竞争压力。如此一来，SOA就能够提供IT与业务前所未有紧密结合的可能。
业务需要的是一组服务：能够重组，得出新业务流程以支持新的产品或服务组件。而SOA的职责所在就是发布这些服务，提供连贯一致的框架，使服务组件能够得到治理并重组为应用。虽然许多SOA的举措仍停留在早期阶段，它对增加业务反应度的承诺还是真是可靠的。我们看到越来越多的企业正推进更为高级的部署。以下案例研究则是最好的证明。
在自身独有技术领域内建立SOA
Comcast公司的应用体系架构和IT治理高级经理Tom Adler说：当你决定要采用SOA方案时，购买ESB、注册库和其他工具是很具吸引力的，这样能够使其所创建的应用程序结合起来并应用到其所执行的业务流程中去。从架构入手能帮助你确保目前和将来随时间推移后，任何需要改变的时候都有一个正确的框架来指导执行。
他还说：“一年半以前，我们开始这个努力时，我们顶住了来自厂商的诱惑，他们总是希望我们能够购买他们全套的产品套件。但是，我们引进了项目专家而不是厂商，并通过这些专家首先确定了我们到底需要什么。所有的厂商都只是希望将ESB出售给我们。”他指出：在架构上的努力不仅仅在于建立框架，还要开始找出自己在业务流程和应用程序方面存在的冗余。这才是在业务上得到大宗买入进的关键所在， 因为它能真实的呈现哪里有节约成本的机会、帮助确认SOA最终基础架构和工具的投资，并且能展示通用服务组件在哪里运用能帮助减少维护和整合的复杂性， 为未来更多的响应功能的发展提供了机会。这个目标使我们消除了那些冗余的服务组件。
在开发架构之后――Adler称之为共同域模型――Comcast公司的下一步是进行服务组件的发展和配置，以及治理框架的开发。他表示：服务必须要经过治理，否则没有人会知道该服务组件存在或是否遵循正确的政策和程序。只有经过治理的服务才能被增加到服务注册库中，才能被其他人再利用。
很快出现的一个治理挑战就是决定谁是服务的所有者。Adler说，Comcast公司是一家相当分散的公司，所以企业文化自然的支持由服务组件原创者在他们自身所在的特有技术领域中拥有该服务。他还补充道：如登陆之类的常见服务组件自然由IT负责。
目前Adler意识到Comcast公司错过的一个步骤就是在确定了架构体系之后需要开发一个公共数据模块。由于没有标准的数据服务组件以取得企业信息和管理系统之间的互动，开发人员最终没有以合适的方式设计自己的服务来完成任务，而这也导致他们对SOA原则的破坏，使服务组件之间容易混合与配对，并且出现不一致性。他说：“我们低估了先前的价值。”而代价就是在此之后为了加强该模式对一些服务的重复工作。
Adler相信：Comcast公司的 SOA努力着眼于架构而非将SOA视为技术问题，这帮助SOA的理念更为广泛的在公司传播和应用。例如，因为Comcast公司从一开始并不认为SOA就是对Web服务的使用，该公司在其所有的努力中都使用了SOA的理念，而非仅仅限于那些明显的能通过网络实现的地方。他说：Web服务仅仅是公开服务的一种方式，是执行的具体途径。一个结果就是，多数初期SOA努力实际上被导向遗产应用软件，从而使内外部整合性降低(比如帐单供应商)，这是业务方面的一大痛处。
开发商会使用最适合自己知识和应用的不同工具和编程语言。Adler说：通过标准化流程和政策替代特殊工具和技术手段，开发人员可以更好地坚持架构的意图而不是将每个人的努力硬塞进某种特殊工具或技术的限制或假设中。在共同架构下保持技术异质也是有现实原因的，他指出：在一个拥有9000名员工的公司，让每个人使用同样的方法论是不现实的。
Adler说：这样规模的公司也要适应不断变化的业务需求和技术机遇。定期回顾参考架构是很重要的，可以避免它成为一纸空文或是企业的束缚，任何一种情况都会使你损失SOA给你带来的好处。虽然架构的变化并没有那么频繁，Adler每月都会回顾一次。
让开源思想融入SOA策略之中
对于开发人员而言，他们无时无刻不面临的问题是：所有的应用程序使用在对于一个很普遍的系统时，即便是在同一时刻不同的团队之间也无法很好的达成协作。这样的问题在2007年初的时候给Leapfrog公司带来了不小的麻烦，当这个玩具公司试图将其多样的应用程序系统应用于供应商和客户，并在两者间取得一致，用以更好的利用以网络为基础的业务交易。Leapfrog公司系统基础设施主管Eugene Ciurana对此说道：正是这样的一个原因让我们决定采用一个全新的方式去开发应用程序，今年3月，也就是SOA开始得以实施的时候，到此为止我们也已经取得了一定的成果。他强调：“我们需要为将来基于网络的基础设施和应用系统奠定坚实的基础，因此，我们一切从头开始。”
在这个过程中Leapfrog公司一直有着一个确定不变的目标，而这个目标也是SOA思想最典型的目标：更大程度的代码重用，更快的开发时间以及更为简捷的集成应用。但是，Leapfrog公司并不仅仅只是打算让简单的让SOA在开发工具和综合应用平台上发挥微乎其微的作用。更多的是他们希望SOA能够在更为广泛的程度上自由发展，从一个领先理念指导的前提出发整合所有平台为一体以达到非常好的的效果，从而可以更好的专注于应用程序的功能性并在此程度上最大限度的使用各个开发技术所带来的优势。(Leapfrog公司的开发人员使用的是Java，微软的C#，以及来自第三方库中的Web服务。)
举例来说，Ciurana不希望迫使开发人员使用相同的传输方式。他说道，“如何传输其实并不重要”。他选择使用开源Mule ESB作为通讯支柱，并以此作为解决各层面传输问题之间的关键工具。通过这个途径，“开发人员可以尽可能的减少所需要面对的服务实施问题。”同时，他们可以更多的将精力集中在对功能性方面的实现，这也是他们努力的工作的目标重点所在。这样一来开发人员更趋向于使用HTTP传输协议，当然，REST和SOAP也会是他们的选择。“他们会考虑使用一些项目实现非常好的的同时也是最合适的传输方式。” Ciurana对此解释道。在Mule ESB的帮助下，“开发人员不需要担心在他所使用的SOAP栈中有什么独特不能被重用的内容或者是什么样的集成开发环境会是他们使用的。” Ciurana早在Walmart.com的时候就已经使用过Mule了，所以他认为这是Leapfrog公司值得“从头开始”的依据所在。
Ciurana 指出，Leapfrog公司之所以采用这样的作法是因为他们的重点是在如何整合应用。“大部分的整合都是针对于应用层面的，应用程序之间相互访问。整合能够将单纯的输入与输出仅仅停留在这一个层面去解决。”开发人员运用POJOs (plain old Java objects)完成服务组件的书写并将其与Mule ESB紧紧连在一起，并在ESB中完成几乎所有的转换。“通常情况下，当开发人员在使用SOAP和REST的时候，他们需要考虑如何为外界提供一个友好的接口。但是在POJOs的帮助下开发人员大可不用为这个问题担心。”他继续补充道。
对于Mule ESB而言，Ciurana更对它的简单明了情有独钟，它的议程管理已经足够不再需要更多的信息管理功能作为辅助。“所有的厂商都希望能够将他们的产品套件整套卖给我们。但是对于SOA的核心观点而言，对于完全不同的系统是需要友好整合在一起的。” 使用Mule ESB，Leapfrog公司可能需要去面对如何整合各个层面不同的SOA应用，但是Ciurana表示他乐于为此付出代价去换取一个更
具有可塑性的应用，因为这样能够给整个项目的实施带来更多的可能。
Leapfrog公司目前使用两个ESB系统，其中一个用以数据流的管理和应用，这类似于一个ERP系统，一个活动目录或者是一个数据仓库;另外的一个ESB系统则是基于网络的面向客户的应用系统，就如同它的客户帐号管理系统和它向消费者提供的在线游戏。之所以采取这样的分工是确保了所有应用的安全性和存取管理的便捷，同时也可保证数据等其他内容的相互备份，并在需要的时候相互代替进行工作。
Leapfrog公司创造着一种统一的服务计划，并能够在任一的ESB系统中运行，Ciurana强调，这能够保证我们“创建统一的服务接口”。这就使一个开放的ESB所能带来的理想效果。
将SOA与EDA结合
对于SOA最为明智的理解是对于处理散乱的信息处理功能，能够将业务流程作为整体指导并分成若干的不同的组件，发展成型的独立应用服务，并根据不同的业务应用需求将这些组件有选择性的匹配起来。在SOA的基础上，这些不同的功能模块组件能够像积木一样组合，同时也可以几乎无限的分散成各个块。
当然，并不是所有的业务都是那么的具有可分散性，而且对于业务的进展也是很难去估计的，相反，他们更多的依赖于具体的序列事件。航空公司是一个典型的事件驱动型流程例子，因此他们通常都有一套EDA来处理事件。美国联合航空中间件工程经理Ramnath CidamBI说：“EDA非常以流程为导向，而SOA则是负责离散黑盒子。”两者各司其职。他还指出毕竟，航空公司也有自己的交易系统，如订票、座位安排等等，并不仅仅是限于飞机着陆调度燃料卡车或航班到达后更新航班状态之类的事件驱动系统。
联合航空一直以来使用IBM Websphere作为其消息总线投资其EDA系统，长达七年。在过去的几年中，它开始投入SOA来操作在联合航空网站上使用的现代化Web服务。CidamBI表示：但是，这两种环境是截然不同的，因此他们应该是并行存在的。然而，这一切都在改变，因为公司开始其内部操作中加入交易服务，如以短信通知客服代表(使用Web服务)他们当天的行程，通过HR系统得知值班、病假人员等等来向各个机场登机口安排人员。这使Web服务与事件驱动流程处于同一环境中，使得航空公司在UnITed.com程式外开始发展SOA。
联合航空的挑战在于在存在并需要两种架构的行业中如何建设和实施服务。虽然航空公司内部运转需要两个架构，它不能将之完全区分对待。毕竟，航班的取消(一个事件)也会影响到交易系统(如重新安排航班，更新以网络为基础的航班信息查询工具或是开立信用凭证)。许多流程都同时具有事件与交易的成分：当客服代表从交易系统拿到他们当天的行程，由于航班取消、天气关系的延误等都会很快会使该时间表颇负争议。事件驱动系统可以追踪航班状态和调度交易系统，而后通过定期检测该状态更新员工分配。(飞行显示器使用相同的程序)。
最大的挑战还在于解决信息系统。CidamBI指出“ESB在Web服务标准之外并无标准可言，因此如何操作事件驱动服务并不很明确”。Cidambi运用ESB同时针对SOA和EDA，因为这两者在处理信息传输，数据转换和更重要的数据流程的时候有着杰出的效果.
就目前的应用看来，美国联合航空公司同时拥有两个ESB系统，其中一个是针对于EDA的服务组件，而另一个则是针对于SOA的服务组件。他们使用IBM的WebSphere用以整合，针对EDA的服务组件提供一个类似于出版和订阅的通讯平台，各项服务之间的传输，事件的传输变得有必要并且易操作，这也就是很容易理解的EDA ESB。至于传输方面，现有的J2EE平台应用对于信息的导向非常有利，所以他们使用JMS(Java 消息服务)作为消息传输标准而不是Web服务。
针对SOA的服务组件，美国联合航空公司采用的是BEA的AquaLogic ESB产品，CidamBI对此的解释是BEA的这款产品是一个更新的平台同时也是以SOA最新理念为导向的，同时它也更适合公司内部所使用的WebLogic应用服务器环境和Eclipse发展环境。“AquaLogic是最适合WebLogic的，也最能够在这个应用服务器之上发挥作用。” Cidambi说道，使用AquaLogic将不会再需要进行更多的整合工作。
对于EDA的服务组件之所以没有采用AquaLogic也是出于减少不必要的工作这一目的：美国联合航空公司已经连续7年使用WebSphere了，在这个平台上进行了最优的调整甚至是总结出了一套完整的工作指南，并且，WebSphere在这7年的使用中表现的非常出色，如果一旦涉及到要将其移植到一个别的ESB，比如说AquaLogic，必定会使之前的工作出现中断和破坏，一些无法意料的差错也会是在所难免的，同时，对于新的ESB来说也意味着很大一部分工作得重头再来一遍。
对于SOA和EDA之间的传输CidamBI仍旧面临着一个很大的问题，而这个问题也是困扰已久的问题，两者之间缺乏严谨标准的XML模式，让EDA与SOA的服务之间的信息传输变得非常复杂，也增加了很多的麻烦。
金融的服务顺从性自动化
大部门的公司之所以对SOA理念情有独钟是因为清楚的认识到SOA能够大幅度缩短应用程序开发周期。但是，一些以SOA为指导的开发人员发现实际上有一些关键的服务治理如果处理不当将会严重降低开发速度，而不会带来理想中的开发速度。来自财经出版和信息服务公司，Thomson金融的产品核心服务管理副总裁Vladimir Mitevski说道，这是他们公司在开始SOA征途初期的时候所发现的一个令人惊讶的事实。
Mitevski指出：“如果要真的成为一个对企业产品具有指导意义的资产，一个服务需要有着许多极其严格的要求和实现策略。”很多要求看起来是非常苛刻的，比如说一些基本的XML元素名称不能用缩写，必须是字典里真正有的字，举例来说，在某些系统里的登陆程序，用户名称和密码必须是有规范要求的。之所以会有这样苛刻的要求必定是有着充足的理由。它他补充道，当你只是有着很少的一些服务时，企业的架构团队能够很容易的理解这些问题并作出正确及时的处理，但是，一旦服务开始达到一个量的时候，如果没有这些苛刻的要求，架构团队肯定则会出现种种的疏漏，工作量和工作压力都无法缓解，更严重的是如何处理服务的瓶颈将无法很好的解决。
Thomson金融有着无数的服务组件，但是相对的他们的架构团队成员则并不是很多，这正式缘于他们对这些服务组件有着极其标准的统一与要求，所以才能够很快的解决服务组件的一些相关问题。“我们不用担心每个服务组件的粒度问题，不用担心他们是如何在整个流程中怎样进行的。” Mitevski说道。只有当服务组件能够达到这样的一个要求时才会被允许进入到库中。同样，新的服务组件在得到应用之前也必须要经过这样的评估才会允许注册入库，然后再可供产品使用。Mitevski还说道：“因为得考虑让库中的服务组件能够有一个大的规模，但是基于这样的评估标准，这对于架构方面的工作人员而言确实是个难度不小的瓶颈问题。”
降低这些服务组件的顺从性并不是一个好的解决方法，这都是由所需要面对的关键应用的性质所决定的，诸如单点服务登陆，对于分析师和交易人员的基于金融市场信息的Web服务，基于网络的财务分析和服务……这些都是服务组件严谨性的苛刻前提。
Thomson公司对于遵从工作量问题的解决方案是求助于自动化、使用WebLavers的政策评估工具。Mitevski说：“这些工具是很有效的，不会错过任何一个违反案例。”为这些工具标准的遵从性制定政策是需要时间的，更关键的是架构师需要评估工具分析来确定特定的事件是否重复出现，这是否意味着开发人员对于关键政策的理解不够或者架构中的模糊点存在。尽管Mitevski发现许多违反政策案例都有由于开发人员走捷径而造成的，他还是指出：这能帮助我们看到应该怎么做更好，而一些政策的确需要调整。除少数发生的违反规定的情况外，架构师还将决定甚么时候给与开发人员例外的权限，而这些额外权限将被写上注册表以告知其他用户。
让服务组件顺从性自动化给Thomson金融带来的最大好处则是服务组件开始变得更加灵动。Mitevski说：“曾经需要20个人参与的大的流程项目，在自动化实现了之后仅仅只是需要一个人就能顺利完成。”
让客户整合简单化
一家侧重于制造服务的公司需要容纳范围广泛的客户整合，如不同系统间帐单、预测和订单系统。然而随着你的客户系统的增长和演变，你将很难管理这些点对点的沟通。这是许多制造商转向交易枢纽-VANs(增值网络)第三方供应商的原因，这样一来对于每一组消费供货关系，双方只需要担心VAN的连接一个方面。
VANs就不太适合应用于定制程序，当你与客户涉及到此时，这种方法就会失败。Jabil是一家电子产品制造商，面临着其两难的抉择：手工维护所有定制应用程序和界面。Jabil拥有5000多家贸易伙伴，虽然大多数都能通过VAN方案来处理，但是有50家客户是需要特殊的沟通机制或业务流程的，因此Sterling Commerce VAN应运而生。该公司电子商务经理Lowel Gilvin回忆说：通常来说每一个客户都会有好几个这样的特制连接组合。这种情况需要改变，因此Jabil按照SOA原则用以服务为基础的连接替代了绝大多数的定制连接，并使得常见功能可以被再利用。
第一步就是分将如订单到付款管理，预测和库存发送等等的业务流程从沟通流程中分散出来。Jabil目前已经为多数沟通机制制定了服务标准，例如AS1 (适用性声明1)，AS2(适用性声明2)和FTP，以及为XML、平面文件，Excel和SAP的iDocs格式都有各自的数据处理服务。它为每一个客户将适当的沟通服务、数据处理服务和业务服务组合到一起。在大多数情况中，这些操作都是通过表格和元数据自动进行的。Gilvin指出：在某些情况下，客户也许是基于分工要使用一个以上的机制，那么这些表格就要处理这些不同的机制。
Gilvin还说：SOA原则下提取、模块性和服务组合通常是管用的。但在一些情况下，特殊要求不能仅仅通过组合服务得到满足，因此Jabil仍然使用一次性整合去维护。但即使在这里，Jabil往往可以将SOA方案用在部分的整合当中。举例来说，XML和SSL证书验证不能通过标准化服务来处理，因为证书都是少有的，但Jabil可以使用一种硬布线数据处理服务将适当的通信和业务服务组合起来，在三分之二的整合中保持了SOA的重组和一致性的益处。
Jabil Sterling Commerce公司的Gentran Integration Suite来实现信息、服务注册和进行服务的管理和开发，而不是用ESB管理信息，注册表来管理服务注册，或是面向SOA发展环境开发服务。该套装是专为供应链的互动而设计的，这是jabil所要管理的一切了。这个有限的范围让Jabil能依赖于工具嵌入式架构。Gilvin指出：我们的标准化业务流程是很小的。
