面向服务架构（SOA）的原则
--------------------------------------------------------------------------------

来自：umlchina 摘译：自adtmag，风自由 [2003/10/16]
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中也有这个词，表示软件开发中涉及到的各种角色如：用户、设计人员、开发人员乃至测试人员等等。）在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下，设计阶段和运行阶段之间的界限变得模糊起来，很难清晰地分离这两个阶段。

剩下的部分
我们已经为面向服务的架构提供了一个高层次的框架，其中MDA和AM的元素帮助工具的使用者来创建和维护SOA。但是，SOA中还缺少一些内容－那就是软件开发商和专业的服务组织必需提供的。理想情况下，开发商必需提供面向服务的业务流程、工作流以及服务的协调工具和服务；另外，能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的；技术专家必须配备可以从模型中自动生成代码，并在代码变化时更新模型的工具，最后，开发商必须提供支持SOA的软件，帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层次。幸运的是，这方面的产品即将上市。

另外，最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的：“这是如何创建Web services的方法，现在，我们来使用它们集成吧”，对Web services技术的这种方法是伟大的第一步，因为它可以惊人地降低集成的开销，这是现在的技术管理人员最乐意见到的了。但当经济进一步发展，IT走出低谷，企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构，IT可以提供给企业实现业务敏捷性的这样一个框架。

SOA（面向服务的架构）的先见者与先行者
----访BEA CIO Rhonda Hocker
2003年10月31日
　　2002年的12月，Gartner提出“面向服务的架构(SOA)”是“现代应用开发领域最重要的课题”。对于BEA CIO Rhonda Hocker来说，这一结论毫不意外，因为早在18个月前，Rhonda Hocker就提出要将BEA的IT基础架构转变为面向服务的架构(SOA)。

　　改造之后，他们能够更快地推出新的应用，支持BEA快速变化的业务需求，同时还极大地降低了成本。就此，bea.com网站编辑Michele Rosen与Hocker进行了交流，并Hocker介绍了BEA是如何利用自己的软件取得了这些成就。

　　问：BEA是一家企业级软件公司，这一点对于BEA IT部门的工作有何影响？答：BEA IT部门有两个战略性目标，首先要让我们在IT上的投入更快地发挥效益，或者说快速实现IT价值。其次，展示BEA解决方案的价值。WebLogic Platform使我们成功地实现了这两大目标。此外，我们还会把自己使用这一平台的实际经验反馈给公司的产品部门和支持部门，进而对我们的客户有所帮助。

　　问：你所说的“快速实现IT价值(faster time to value)”是什么意思？答：“快速实现IT价值”意味着我们不仅能够更快地完成项目，而且能够更快地实现投资回报。“快速实现IT价值”的基础是要构建一个具有良好可伸缩性的IT应用基础架构，它能够与公司的业务同步发展，随机应变，并将IT部门从维护和支持的复杂性中解放出来，同时提高核心企业应用的效率。当我们要更改这些核心企业应用时，不会影响IT基础架构中的其它层。通过这种能够“快速实现IT价值”的IT基础架构，我们使公司具有最大程度的灵活性，能够轻松应对业务的不断变化。

　　问：为了帮助BEA的IT部门“快速实现IT价值”，你们做了哪些工作？答：我们转向为面向服务的架构(SOA)，这种架构有三个层次：-基础层：由只需少量改动的ERP、SFA等标准核心应用构成；-企业基础架构服务层(Enterprise Infrastructure Services)：用于集成和扩展底层应用，并且作为公用层提供安全服务和访问管理，这些公用服务能够重复使用；-定制门户应用层(Custom Portal Applications)：可以量身定做，满足特定的业务需求。

　　问：到底什么是SOA？为何它对快速实现IT价值那么重要？答：SOA充分利用Web服务，将流程中的各个环节如“获得客户信息”(GetCustomerInfo)封装起来，然后以多种方式展示这些模块。在SOA中，架构中的每一层都不受其他层变化的影响。面向服务的架构还有助于提高重用率，从而促进生产力的提高和成本的降低。举个例子，像“获得客户信息”这样的服务可能会非常复杂。而在SOA架构中，这种服务被封装起来，并体现为Web服务的形式，这样我们就可以创建能够持续察看客户情况的连贯视图。由此，我们不仅能够节约开发的时间，并且使我们可以不受变化的影响。当我们需要对门户层进行修改时，我们也不必考虑客户数据的构成方式。

　　SOA还使我们能够将业务流程整合在一起。例如，我们可以选取一项业务流程，如“创建新项目”(CreateNewCase)，将它与另一个流程，如“申报客户支持”(NotifyCustomerSupport)，整合在一起。这样我们就能以一个或多个Web服务为中心来定制我们的业务流程，而无需定制应用层或门户层。同所有其他企业一样，BEA也面临着同样的挑战：既要实现目标又要减少成本。面对这一挑战，SOA有着切实的意义——它能够帮助我们加强对整个企业架构的控制能力；并且由于它具有高级别的重用性，有助于我们提升开发效率、加快开发速度；最后，采用只需少量改动的核心企业级IT应用，让我们只需优化基于标准技术的IT技能，降低了我们在客户化和人员技能方面的投入，从而节约了成本。

　　问：你所说的基于标准化的技术主要驻留在企业基础架构服务层(Enterprise Infrastructure Services layer)，请你详细介绍一下这一层的情况？答：首先，理解这一层所提供的内容很重要。这一层是由各种与应用保持中立的关键服务构建而成的，而这些服务(如“安全”)能够重复应用于每个单独的web应用。企业基础架构服务层(Enterprise Infrastructure Services layer)包括共享的应用服务、消息与代理服务、门户服务、以及共享的业务服务——这些服务使我们能够将业务逻辑和数据展示给整个企业。例如，定制的门户应用通过驻留在企业基础架构服务层的Web服务界面与基础应用交互。

　　问：在企业基础架构服务层中，你是如何应用BEA产品的？答：BEA产品可以在这里广泛使用——WebLogic Server是企业基础架构服务层中各层必不可少的部分；WebLogic Integration用于除门户服务之外的所有方面；此外，我们还将Liquid Data用于应用服务层(Application Services)；用WebLogic Workshop来构建Web服务。

　　问：你能否再介绍一些利用该体系结构构建定制门户应用的情况？答：当然可以。因为构建定制门户应用的效率很好，所以从2001年12月开始，我们平均每个季度都推出一种新的定制门户应用。这些应用不仅帮助用户提高了生产力，而且还降低了成本。

　　例如，借助eSupport客户支持门户，我们提升了呼叫中心的生产力，三年内节省成本约3,000万美元。同时，我们还赢得了高于平均水平的客户满意度。eSupport还入选了“技术支持专业人员协会”(Association of Support Professionals，ASP)评出的“2003年度十大杰出Web支持网站”。

　　我们的eOrders销售自动化应用通过显著缩减处理客户订单所需的时间，同样大幅提升了销售人员的生产力。而且eOrders也有助于节约成本，事实上，它在三年内节省了2,600万美元。

　　除了帮助BEA其他部门提高生产力，SOA也显著提升了IT生产力。我们开发新应用的时间减半，应用开发成本降低25%。此外，我们的技术支持成本每年可节约2,200万美元——在技术上很少能够像这样做到两者兼顾，不过，采用其他任何方式确实都难以实现这些成果。

　　问：你们取得这样的成功还有其它什么因素吗？答：问得好。单靠技术本身是无法解决问题的。要想取得成功，还要有好的团队、好的流程和对待成功的正确心态。我们必须比以往更专注于我们的IT技能，从而确保我们掌握精深知识，以便快速有效地执行计划。我们还必须将关键的IT功能集中在一起，从而确保拥有足够的监管能力。我们还实现了整个应用生命周期的标准化，特别是交付模式，这样就使我们能够组建更多高效的团队，并使应用之间的集成更加顺利。

　　除此之外，我们还与BEA内部负责业务的同事紧密合作，并保证我们的IT建设CEO、CFO以及其他主要高层管理人员的期望一致。在整个过程中，我们会时常地展示成果、宣传我们的成功、评估投资回报(ROI)，从而确保我们的价值为大家所知。

　　最后，我们自始至终地保持灵活的态度。如果做法得当，面向服务的架构将使IT具有足够的灵活性，从而使业务能够做到随机应变，而不是像有些企业那样，让业务坐等IT追上来。