SOA介绍  实现方法

Web service已经不再是新婚的娘子。众多企业都已经创建各种实验性Web Services
项目，事实证明，这项新兴的分布式计算技术确实能够降低集成和开发的成本。另外，一些关键的Web
Services标准纷纷制定，强安全（robust
security）和管理方面的产品也陆续问世。对于志向远大的企业来说，他们已经在考虑下一步了。

对大多数公司来说，下一步要考虑的不再是点对点的应用，而是Web
services在企业间以及业务伙伴间更为宽广的应用。这种技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对IT在组织中的角色有新的观点和认识，而不仅仅是一种实现方法。通过对业务的敏捷反应，企业可以得到实实在在的回报，而要达到这一点，面向服务架构设计师的角色非常关键。除此之外，潜在的回报更是不可胜数－分布计算技术能够保证对业务需求足够灵活的反应，而这种业务上的敏捷正是各公司梦寐以求而目前还遥不可及的。

分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的解决方案。但这种架构不是什么新思想；CORBA和DCOM就很类似，但是，这些过去的面向服务架构都受到一些难题的困扰：首先，它们是紧密耦合的，这就意味着如分布计算连接的两端都必须遵循同样API的约束。打比方说，如果一个COM对象的代码有了更改，那么访问该对象的代码也必须作出相应更改。其二，这些面向服务架构受到厂商的约束。Microsoft控制DCOM自不必说，CORBA也只是一个伪装的标准化努力，事实上，实现一个CORBA架构，经常都是在某个厂商对规范的实现上进行工作。

Web services是在改进DCOM和CORBA缺点上的努力。今天应用Web
services的面向服务架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准（如XML和SOAP）提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web
services而不用对使用这些Web
services的客户端的知识有任何了解。我们将这种基于标准的、松散耦合的面向服务的架构简称为SOA。

SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。

但是，要得到种强大和灵活性，需要有一种实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。本文将讨论SOA的实践，即：面向架构的设计师在构建SOA时必须要做的事情。

SOA的原则

SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。

要满足这种业务敏捷性，SOA的实践必须遵循以下原则：

* 业务驱动服务，服务驱动技术

从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。

* 业务敏捷是基本的业务需求

SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。

* 一个成功的SOA总在变化之中

SOA工作的场景，更象是一个活的生物体，而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化，因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说，要转向设计一个活的生物体要求崭新的思维方式。如下文所写的，SOA的基础还是一些类似的架构准则。

SOA基础

在IT行业有两个越来越普遍的发展方向，一个是架构方面的，一个是方法学方面的，面向服务的架构设计师可以从中有所收获。第一个就是MDA（模型驱动架构），由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML（也是由OMG提出）的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use
cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。

MDA的核心就在于在设计阶段系统就已经完全描述，这样，在创建系统的时候，几乎就没有错误解释的可能，模型也就可以直接生成代码。但MDA有一些局限性：首先，MDA假设在创建模型之前，业务需求已经全部描述，而这一点，在当前典型的动态业务环境中几乎是不可能的。第二，MDA没有一个反馈机制。如果开发人员对模型有需要改动的地方，并没有提供给他们这么一个途径。

SOA的另一个基础是敏捷方法（AM），其中非常有名的方法是极限编程（XP）。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中要有一个用户代表，他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中，并且设计要尽量小并且非形式化。AM的目标是仅仅创建用户想要的，而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性－处理需求变更的敏捷性。AM的主要弱点是其规模上的限制，例如，XP在一个小团队和中型项目中效果不错，但是当项目规模增大时，如果没有一个一致的清晰的计划，项目成员很难把握项目中的方方面面。

从表面看来，MDA和AM似乎是相对立的－MDA假定需求是固定的，而AM恰恰相反。MDA的中心是形式化的模型，而AM恰恰要避开它们。但是，我们还是决定冒险把这些不同方法中的一些元素提取出来，放入到一个一致的架构实践中。

在SOA中有三个抽象层次，按照SOA的第一条准则：业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来，表现在平台相关的模型之中。MDA并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。SOA必须连接这些模型，或者说抽象层次，得到单一的架构方法。我们将从五个视图的架构实现方法来实现这个连接。

SOA的五视图实现方法

企业架构设计师发现他们的职业非常有竞争力并且值得骄傲，因为他们要从很多方面来通盘考虑IT系统。Kruchten（RUP的开发负责人）将这些方面提取出来，在应用到SOA时，我们称为五视图实现方法（five-view
approach）。

四个方框表示对一个架构的不同审视方法，分别代表不同的涉众（stakeholder）。弟五个视图，use-case视图涵盖了其它视图，在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上，是系统部署人员对架构的视图；实现视图描述了软件代码的组织，是从开发人员角度出发的视图；业务分析人员则利用过程视图进行工作，它描述的是软件系统的运行时特性。最后，逻辑视图表示的是用户的功能需求。在SOA中，面向服务的架构必须能够以use-case视图中的用例将用户连接到服务，将服务连接到底层的技术。

为了表示面向对象的架构是如何工作在这些视图之上，让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠：由业务模型和服务模型表示的业务领域和由服务模型及平台相关模型表示的技术领域（两个领域共享服务模型）。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务，根据变化的业务需求，按照需要将它们安排在过程之中。另一方面，技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型，起到的是轴心的作用，业务以它为中心进行。

SOA元模型从MDA中继承平台无关模型和平台相关模型，但是添加了AM和用户交互以及敏捷的反馈这两部分，后者通过椭圆之间的双向箭头来表现。类似地，元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样，服务模型中的任何需求的变化，都会反映到用户每天的业务处理中。同样，由于底层技术是模型驱动的，技术专家也可以根据这些变化的需求迅速而有效地作出应变。

SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说，SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示，涉众（stakeholders，译者注：RUP中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。

SOA（面向服务的架构）为我们提供了一种很好的改变现有业务流程模式的途径，成功实施SOA项目的关键在于分析重点、减低风险，给出企业真正需要的功能模块。本质上讲，SOA并不是一种新技术，它仅仅是一种系统设计/规划模式，甚至可以说，只是一种现有业务流程重组转换模式。

要将现有的IT架构转变到SOA架构需要时间、资金、勇气，以及一位强有力的领导者。基于SOA架构建立的IT系统可以帮助企业节约系统的开发成本，并可以大大提高企业的敏捷性。但是，要想实施基于SOA架构的系统，不但需要大胆的构想，更需要大胆的行动。为了实现这一目标，对企业内所有的员工，这既包括IT部门员工，也包括其他部门的员工，都需要转变对业务流程的固有看法。这需要相关的职能部门为了长远的目标而放弃眼前的利益，也要求IT系统设计师及开发人员从服务的角度来考虑系统的构成，同时，可能会放弃某些环节的控制权，如版本控制等。整个SOA系统可能要涉及变更管理、技术管理、风险管理以及日常业务管理等多个已有的业务系统。

这些情况的确能够让人们在是否选择SOA模式上犹豫不决，就像在黑暗的SOA森林中找不到前进的方向一样，但实际情况并不如想象的那么困难，根据已经实施的SOA系统，我们还是能够找出其实施路径的。
SOA的定义

简单的讲，SOA就是将现有的一些功能模块打包成独立的程序包，命名为“服务”模块，这些服务模块在整个软件系统的角色相当于在垒高玩具中所用到的小砖块。对于这些服务模块，需要对其接口进行良好定义，使得其他的应用系统可以使用“拿来主义”，方便的使用这些服务模块。通过创建服务模块库，将所建立的模块集中到模块库中，这样，利用库中的服务模块，可以方便的构建出所需要的应用系统，这好像我们在垒高游戏中，使用同样的小砖块，只需要对砖块进行重新排列，我们既可以搭建出城堡，又可以搭建成鳄鱼或飞机。与面向对象的技术不同，SOA架构所需要的服务模块可以分布在更为广泛的分布环境中，而不必像面向对象技术那样，需要使用大块的可重用去构建一个全新的系统。对于基于SOA架构所构建的系统，我们不必考虑如何基于具体的操作系统构建具体的服务模块，也不必考虑具体的操作系统，只要这些操作系统支持标准的服务接口就可以方便的使用这些服务模块。

如果你认为SOA是解决目前IT系统所有痼疾的万能良药，那你可能要失望了。SOA并不能代替已经在公司内部存在的那些被良好集成的应用系统。通过合理的部署，SOA系统可以改善原有的IT系统效率，使得原有的那些应用系统更具有柔性。
SOA如何改变业务流程

ProCard公司是一家信用卡服务公司，他们能够提供其竞争对手（如visa）不具备的信用卡服务，这些服务包括动态跟踪信用卡持有者个人信息变化，比如增加信用卡透支额度或个人通信地址的变更，要完成这些服务，需要一套完整实时信息系统来代替原有的离线信息系统。同时，ProCard清楚地知道其竞争对手也会建立完成这些功能的信息系统。所以，ProCard面临一个选择：是继续使用原有的信息系统来实现这些新的服务项目，还是建立一个新的信息系统。最终，ProCard选择了后者，基于SOA架构建立新的信息系统。

ProCard可以将从他们的信息系统中将那些完成实时功能的模块抽取出来，形成一个独立的软件产品，以满足对包括Visa系列信用卡在内的产品支持。但是，出于长远考虑，他们希望所构建的系统能够为更多的潜在用户所用。因此，他们决定使用SOA架构构建了面向服务的软件功能组件，这样用户可以方便的将这些功能组件集成到他们的系统中，并且它们还提供一些扩展接口，满足未来软件功能扩展的需要。但是，大胆的想法往往会遇到很大的阻力。要实现SOA的系统，必须说服业务流程部门的人员赞成这一决定，也就是说，需要改变现有的ProCard的业务模型，不但要让他们知道这个想法是可以实现的，而且要让他们知道这种改变是必须的。ProCard的COO（前任CIO）Inn
Hill说道，“从技术上讲，我们的员工可以很快的接受这一新系统，但从业务流程角度讲，我们需要花较长的时间来适应新系统所带来的改变。”其中最关键的一点，Hill提到，是确保我们不仅仅局限于技术层面，更重要的是考虑潜在的商业利益，这就要求我们从简单的独立系统供应商转变成一个服务供应商。“我相信如果我们提供基于服务的一些功能模块，那我们将会开拓一个我们未曾涉足的领域。”Hill同时也强调，一些银行可能不会购买这一新的软件服务，但是，一些对个人信息感兴趣的机构可能会购买这一服务，这样，对ProCard而言，就开拓了除了原有市场之外的另一个新的市场。

“无论从哪个角度来看，实现SOA是一个梦想，它的影响不仅仅是技术层面的，更重要的是，它可以改变我们现有的流程模式。”Hill补充道。
技术是难点，说服员工是难上之难

SOA项目主管必须清楚一点：对于SOA项目的实施，不能一次将所有的功能都加以实现，不能一口吃个胖子。在SOA项目中将风险最小化的一个方法是先将一些小的或有利于业务流程使用SOA模式构建相应的服务模块，这样可以让员工先适应这种新的服务模块，不至于使整个公司因为引入了新的IT系统而陷入混乱。ProCard的CIO
Guido
Sacchi表示，之所以引入SOA来构建新的IT系统，是出于几方面考虑的：首先，新的架构可以降低IT系统结构的复杂度；其次，可以减少系统的运营成本，同时，增加系统的灵活性。

为了减少整个项目的风险，他决定先对呼叫中心中的两个功能进行服务模块化——站内客户服务和离站信息收集，并将它们作为SOA的测试项目。之所以选择这两个功能是因为它们具有相对固定的项目预算，并且其运营成本相对较高。同时，如果这两个功能服务能够成功实现的话，那可以增加新的利润来源，并且提供新的SOA项目可以成功的证据。

原有的系统的复杂度很高，为完成系统功能，定义了很多复杂的接口，并且代码相当复杂。“如果我们想更改或增加系统的某些功能，我们必须为新的功能目标重写大量的代码。”Sacchhi说道，“比如，要想完成数据的抽取转换装载功能，我们必须针对不同的需求，重构这一功能模块。”但是，在SOA架构上，通过建立柔性的服务模块，就可以方便的利用已经建立的服务模块实现相应的系统功能，而不必为每个需求建立一个独立的功能模块。同时，利用SOA架构，也能节省大量的开发时间。并且，基于SOA架构更为便利的一点是，所实现的服务模块可以为不同的需求所用，就像砖块一样，为完成相应的功能，只需调用重组相应的服务模块即可。

Sacchi表示，基于SOA架构实现的站内客户服务和离站信息收集这两个功能模块，可以大大减少系统的响应时间。同时，SOA架构允许用户将不同的功能集成在一个统一的用户界面下，这样还可以免除用户在不同系统中切换操作之苦。使用SOA架构，开发人员还不必为每个系统构建不同的功能模块，不同系统中可以共享一些服务模块。
PorCard的COO
Hill对SOA有着不同的体会，他说，当开发小组很快的掌握了SOA技术，并开发出相应的服务之后，迫使ProCard从原来的软件产品供应商转变成了服务供应商。这一转变也使得ProCard重新考虑原有的质量控制体系。原来，他们的质量控制包括从开发、测试直至最终的产品交付的全过程，但是，现在的情况不同了，很多环节是不可控的，也是不必去控制的，比如，可以使用Visa提供的相应功能模块作为中间件，在此基础上开发出具体的服务模块，同时，对后台的数据库系统也不必去过多的考虑，只要开发的服务模块能够调用数据库中的数据，完成相应的功能就可以了。这样就大大简化了整个开发的工作流程，时间上缩短了，效率自然得到了提高。
基于SOA的折中方案

实践告诉我们，一个成功的SOA项目的实施，依靠的不是热情和勇气，而是细致周密的论证部署。1-800-Flowers.com的CIO
Enzo
Micali说道，“很多SOA技术的坚定支持者希望我们对我们所持有的7种不同品牌提供一个共同的服务平台。但是，我们的本意是为每个品牌提供一套独立的服务体系。”

Micali表示，他领导了一个架构设计小组和两个开发小组，其中一个开发小组主要开发面向客户的应用服务，另一个主要开发核心系统服务，起初，他们的工作都是鉴定哪些项目是可以基于SOA架构进行重构的。“经过一段时间的工作，我们发现那些在业务流程中最基本最通用的功能是可以抽取出来，使用SOA架构进行重构。”同时，常识性的知识在平衡客户需求和软件功能方面起到了极大的作用。并且，他还强调了一点，整个系统的开发部署时间以及系统的性能是检验系统是否成功的关键标准，不必通盘考虑所有的服务功能，相反，独立实现某一部分的功能却是一个比较不错的系统开发模式，

Micali也同意SOA支持者，也认为SOA技术是先进的，但是，他表示，如果所有的用户能够有足够的耐心等待的话，他也会将所有的系统功能转移到SOA架构上来，但是，实际情况并不允许我们去这么做。同时，他还表示，即便是所开发的系统并不是急需的，只要认定系统可以转移到SOA架构的平台上来，一定要提前试着去实现。
实现SOA架构系统的好处

尽管我们在上面一再告诫要慎重实施SOA项目，但是实施SOA项目所带来的好处还是很多。比如，我们成功构建了一个通用的服务功能模块，那我们在下一次开发时可以直接调用这一功能模块。“从这个意义上讲，第二次开发时的开发成本为零。”Sacchi说道。他还强调，利用共同的服务模块，还可以大大减少系统的处理时间，减少在多个环节中浪费掉的不必要时间，从而使整个系统的运行更为快速便捷。

SOA项目能够带来的另一个好处是管理上的统一。对于SOA系统而言，要想成功实施一个系统，必须从企业整体来通盘考虑，成立专门的架构设计小组，确定整个企业业务流程运作的最佳路径。这样整个业务流程及信息系统的管理将会实现统一管理，改变过去各部门、各业务环节脱节的现象。

同时，这些SOA项目实施的先行者也提醒SOA项目主管，“不要希望能将大海的水煮开”，要想成功实施SOA系统，必须根据业务流程仔细分析其服务功能，有所侧重的逐一实现，最终使整个系统达到它最佳的性能。（责任编辑：罗洪泽）