IT界出现的最新术语SOA，是服务型架构（service oriented architecture）的缩写。它是如今IT经理、系统集成商和IT供应商的最常挂在嘴边的词，然而只有很少的经理、集成商或供应商知道它到底是什么。SOA其实不是一种产品，技术或者体系结构，它只是一种应用软件一体化的概念。这一点制造业的专业人士应该知道，因为他们常常被要求将他们的系统与其它系统界面通过ESB(企业服务总线)主干网，以SOA 模式连接起来。ESB是软件、路由信息、缓冲请求和回应的连接通道，而SOA则限定了通过这条通道的内容。

　　最早的SOA 概念是希望任何应用软件的界面都应该具备一定的商业用途，比如可以处理一个购货订单或者进行库存的实物清算。只要开始服务就可以自动完成整套相关的商业流程。举一个例子，有一项可以提供“为到达的货物分配一个库存容器号码”的服务。这项服务用物质化的ID标签，为库存的容器分配一个号码。因此，它的SOA界面可能就是被称为“AssignStorageContainerID. （分配库存容器ID）”的服务。它通过那个分配号码的应用软件与ESB相连。当分配ID时，程序有可

　　能同时执行其他的工作，例如记录任务；专项储存库存号码资料以备货物到达时能及时调用；以及将容器的状态标记为“使用中”。

　　SOA的设立基于6个假设的前提：系统是松散耦合的；界面交换是非物质的；程序具有RPC(remote procedure call远程功能呼叫)功能；界面基于消息；消息使用XML 数据；以及界面支持同步或不同步两种数据传输形式。

　　当一个系统工作时不会对另一系统产生较大程度，而同时服务的实施在幕后进行时，系统被认为是松散耦合的。而非物质的界面并没有固定的形式，每次使用的其实只是被交换的数据，而不是隐藏在背后的服务提供商的知识和经验。RPC 功能就是程序运行起来就像一个本地函数或者子程序调用那般简单，使用者完全不必理会界面信息的任何细节。一个基于信息的界面通过ESB在程序间传送消息；这些消息基于XML 数据，而非可展开的文件或某种专用的二进制语言。服务可能是同步的，即发送请求然后等待即时回应。同样的，当服务请求发出后，程序继续处理另一个过程，稍后再做出回应，这时服务是不同步的。

　　这些简单的SOA 概念很难在现有的系统里实现。关键是为系统提供的服务确定适当的程度和类型。服务可以是精细型的，也就是执行诸如改变某一数据要素；也可以是粗放型的，即可处理重要复杂的商务过程的服务。可以想见，粗放型的服务是比较受欢迎的SOA 应用类型；当然，在很多情况下，精细型服务也是不可或缺的。

　　制造团队应该帮助企业认清他们的系统需要实现的服务是粗放型还是精细型的，以方便其做出决定。通常会使用到SOA模式的商业流程主要集中在物质管理、物流控制，包括原材料、设备和人员的运转等。粗放型服务主要针对生产、测试、维护等主要流程，而精细型服务则主要处理与材料、设备和人员相关的具体信息。必须强调一点：SOA不是一个随处可用的解决办法；要实现SOA必须要很好地理解生产制造在企业供应链里所起的作用。

　　在任何领域中，语义都非常重要，而在SOA中更是如此。由于 SOA涉及多个团队和组织，因此就相关术语达成一致至关重要。

　　在任何领域中，语义都非常重要，而在SOA中更是如此。由于 SOA涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始SOA之旅，为您定义各种基础术语和它们背后的重要概念。您将了解 SOA领域中需要理解并用于沟通的各个词汇。对于每个术语，将说明它在 SOA领域中有何重要性、在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。

　　在文中，您将探索各种术语和技术，它们有的与在高抽象级别(分析)下设计 SOA有关，另一些则涉及如何推进到较低的抽象级别(设计)，后一种级别的下面紧接着代码级。

　　关于组织方式的说明

　　以下列出的术语并不是按照字母顺序排列的，同时也未按照其重要性进行排列。相反，我们将按照构建块的方式对其进行组织。本文是以服务概念为基础的，为了定义其他术语，它们对与特定原则有关的概念进行分组，如本文中的分析 和设计。

　　分析和设计

　　分析和设计的内容包括若干活动，通过这些活动，可根据功能和非功能需求集来指定初始的 IT 体系结构。其他一些活动也可作为分析和设计的基础，这些活动对初始的体系结构加以细化，使抽象级别由分析级进入设计级，这一细化程度足以让开发人员生成和编写出实现代码。

　　SOA分析和设计也可以指以下术语中的一个或多个：

　　服务建模

　　面向服务的分析和设计

　　面向服务的建模和体系结构 (SOMA)

　　Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

　　分析会在较高的(概念级)抽象级别上对将要构建的系统进行描述。分析的输入是一组需求和现有的资产(或是应用程序或系统)。输出则是对需要构建的各个方面的描述。分析对 SOA来说是至关重要的，因为通过分析，可以在服务标识期间使 IT 与业务保持一致。分析结果将作为输入在设计中使用。

　　设计会描述将要构建的系统，更重要的是，它还会对如何构建加以描述。

　　大多数体系结构工作是在分析和设计的工作流中、在项目的细化阶段执行的。

　　面向服务的分析和设计利用了分析和设计原则(如面向对象的开发或基于组件的开发中的原则)。例如，您也许还记得所谓的面向对象的分析和设计 (OOAD)。不过，必须注意的是，SOA的工作重点始终在于服务(而不是对象或组件)。

　　注意：分析级模型常会发展为设计级模型，所以对于分析和设计而言只有一套 RUP 原则。

　　面向服务的分析和设计工作的主要输出是一个服务模型(即先前所说的服务规范)和一个设计模型，服务模型记录了面向服务的系统中所有重要的体系结构部件，而设计模型则进一步阐述了服务模型应如何实现的细节。这两个模型对 SOA设计进行了全面说明，开发者可以据此明白无误地执行这一实现。

　　在下列各部分中将描述相关任务，为您介绍面向服务的分析和设计的相关术语。

　　注意：术语标识 和规范 适用于基于组件的开发中，而术语规范 和实现 则是由通用建模语言 (Unified Modeling Language, UML) 定义的。这三个术语构成了 RUP SOMA 的核心活动(术语的含义未变)。

　　服务标识

　　服务标识 是核心的面向服务的分析活动。服务标识的目的是将各个分组的概念化服务及其操作标识出来。

　　这些经过标识的服务对于业务而言是有意义的，业务需要这些服务。事实上，业务分析师会帮助软件架构师进行这项工作。下一部分将介绍服务设计原则，您会了解到对服务逻辑分组的需求、对服务及其操作的业务命名的需求。这些都是在服务标识期间决定的，其间使用了多种技术，RUP SOMA 中描述的那些技术也包括在内。

　　我们来深入了解一下：

　　自顶向下方法

　　业务体系结构工作从一组业务目标开始，标识出一个或多个应予关注的业务流程，这在 SOA中是非常典型的。通过业务建模工作，可能会出现已经过设计的业务流程(即未来的流程)，对于正在设计中的系统，它们可以被视为功能性的需求。

　　自顶向下方法旨在分解业务元素(主要是业务流程和用例)，然后将它们细化为适合服务的粒度。在使用自顶向下方法的过程中，您通常要在业务任务中标识出各种服务操作。这种做法的好处在于，您可以确保标识的服务与业务保持一致。

　　自底向上方法

　　自底向上方法旨在分析现有的 IT 资产(如遗留的应用程序和系统)，找出可以作为服务公开的功能，以便重用它们。

　　重用是 SOA的一个重要组成部分，对于 SOA的成功是极为关键的。您可能知道，遗留应用程序(即已经部署的应用程序)是您的公司最宝贵的资产，应该加以利用。例如，自底向上方法将分析现有的信息管理系统 (IMS) 事务或 COBOL 程序。

　　对于自底向上的分析，有一句忠告：您必须谨慎从事，不要盲目地公开现有的 IT 功能。例如，用于创建、读取、更新、删除 (CRUD) 数据的各项服务的粒度可能太小，无法与业务保持一致。

　　SOA的反思：SOA架构的本质

　　我一直在反思SOA到底是什么，是一种什么样的架构。虽然了解到一些基于SOA构架的产品，但总觉得依然“隔着一层纸”，并不清楚什么才是真正的SOA架构。

　　年初的时候，写过一篇名为“国内EAI正当时，BPM为时尚早，Workflow持续增长，SOA依然概念”的Blog日志。那个时候，我认为SOA还依然是个很“虚”的概念。而现在，我只能说：Sorry，那时候的我，错了。SOA已经不再是概念，而是一个实实在在的构架了。

　　在写完那篇帖子之后，我一直在反思SOA到底是什么，是一种什么样的架构。因为在在TIBCO中国研发中心工作的原因，可以接触到TIBCO的一些最新的SOA产品。

　　虽然了解到一些基于SOA构架的产品，但总觉得依然“隔着一层纸”，并不清楚什么才是真正的SOA架构。

　　很多时候，我依然会认为SOA构架只是满足把应用暴露成Service(或者说是WebService)，以SOAP等之类的消息进行信息的传输，以及基于Service之间的一些业务逻辑的整合应用(比如BPEL)等。

　　我相信，这样的困惑，在国内很多中间件产品、应用产品中都存在，在很多国内的开发人员、架构师心中也存在。

　　昨天，有幸参加了CSDN主办的“SOA产业链及未来企业软件趋势”研讨会，收获不小。参见昨天写的blog随感“参加“SOA产业链及企业软件趋势研讨会”的感想”。经过那些专家们(毛新生、Tiger、李勇、梁耀文等)的解惑，对SOA是一种什么样的构架，有了一些更深刻的认识。

　　但说真的，如果不是目前在TIBCO中国研发中心工作的经历，以及所接触到一些国外最新产品构架的巨变，仅凭昨天的听讲，也很难把握毛先生他们所说的那些SOA理念。

　　具体昨天有哪些重要的理念就不在重复的叙述了，参看“参加“SOA产业链及企业软件趋势研讨会”的感想”，里面有详细的叙述。

　　今天只谈反思：SOA架构的本质。

　　刚刚看到一篇新闻，讲的是SAP代号为A1S的新产品软件设计方法，参见“新闻分析：解密代号A1S”。这和昨天研讨会上，SAP的李勇先生，所阐述的一些观点很类似：SAP的产品在往SOA架构迁移中，经历了三个大的步骤：第一步，提供更好的服务层面的容器或平台的支持;第二步，把业务抽象成服务，确切地说，是抽象业务对象(Business Object);第三步，把面向垂直或水平层面的各个产品，基于业务对象进行整合。

　　事实上，这就包含了昨天各个专家所阐述的SOA架构的本质：一切围绕业务对象(Business Object)或业务模型(Business Model)，至于“服务”，只是这些业务模型暴露出来的形式，因为以统一的服务形式暴露出来，更便于不同供应商和客户之间的信息交互。

　　在Gartner十年前提出SOA概念的时候(1996年)，尚没有web service技术。SOA架构的本质，并不是说把你的应用或者组件包装成Service就是SOA，而是说，你需要基于一种构架，能够让你的产品能够更适应“业务敏捷性(Business Agility)”。但是这种业务敏捷性仅仅是一家提供商或产品是很难满足的，肯定需要各个不同的供应商协助完成，不同的产品之间能够比较容易的进行消息交互。这样的灵活度肯定不是传统的基于消息的EAI产品所能够满足的，需要一种新的协议或标准来支撑。—— 当Web Service诞生之后，所有的大厂商都发现这是一种非常符合他们需求的技术。

　　但是服务的本质，是在后端能够提供一套“业务模型”。而制成这种业务模型或业务对象构建的技术，正好就是前几年所热炒的“模型驱动构架(Model-Driven-Architecture)”。事实上，现在各大厂商都在基于这个构架在转变自己的产品构架，BEA，IBM，TIBCO都在进行着这样的巨变。

　　在回头想想我们常说的“SOA真理三角”：数据(Data)——组件架构(Component Architecture)——组合(Composition)。因为几乎所有的业务模型最终需要被“业务对象+业务组件”反映出来，而它们之间需要进行一系列的组合和交互，来满足业务的处理。

　　在SOA联盟组织的SDO和SCA标准，正是用于解决数据和组件模型描述的问题，这方面几乎所有的EAI厂商都加盟进来了，IBM、BEA、IONA、Oracle、SAP、Sybase、TIBCO、Software AG等等，这其中好包含国内的普元软件。

　　SOA 从概念到行动

　　真实的SOA世界距离我们还有多远?今天，尽管SOA还没有一个准确的定义，但IT公司们已经将其变成了触手可及的商业科技工具，在商业引擎的驱动下，利用这些工具部署SOA已经成为商业科技企业的现实。

　　真实的SOA世界距离我们还有多远?四五年前，SOA还只是一个空洞的概念，缺乏产品和技术标准的支持，企业只能视其为镜花水月;今天，尽管SOA还没有一个准确的定义，但IT公司们已经将其变成了触手可及的商业科技工具，人们不必再泛泛而谈SOA的未来，在商业引擎的驱动下，利用这些工具部署SOA已经成为商业科技企业的现实。

　　国际商业机器公司(IBM)、毕益辉系统有限公司(BEA System)、甲骨文公司(Oracle)、微软公司(Microsoft)等走在了SOA浪潮的前列。这些主流中间件厂商最早认识到SOA在未来平台技术中的超然地位，并且不遗余力地推动SOA技术的发展。如果说前两年这些厂商还停留在SOA概念的炒作阶段，那么，在经历了数年的研发和测试以后，从2005年开始，他们已经陆续推出各自的SOA策略、架构以及产品，真正将SOA推动到可部署阶段。

　　“SOA是BEA公司非常重要的战略。”BEA中国公司技术总监喻思成用“非常重要”形容SOA在BEA公司技术战略中的地位。就在上个月，BEA公司已经正式公布了他们最新的中间件软件品牌—AquaLogic，这条新产品线提供了全面的管理环境，帮助开发者使用开放的Web服务标准和工具创造所谓的SOA架构。而在此之前，已经有很多开发者基于 BEA公司的WebLogic Platform为企业开发SOA。BEA公司产品市场总监比尔•罗斯(Bill Roth)表示，与WebLogic Platform不同的是，AquaLogic的目标使用群体更集中于类似思爱普软件系统公司SAP、甲骨文公司的咨询顾问这样的人群，对于这些咨询顾问而言，配置应用系统并创造商业价值比写软件代码更有意思。

　　IBM公司则基于SOA理念提出了“整合”战略，希望通过建立基于开放标准的、统一的、高效的、易于管理的IT基础平台，通过SOA与Workplace客户端技术(WCT)，实现企业IT前台—用户端、后台服务器的整合，从而灵活地配制企业的内外部IT资源，使企业在市场需求、市场机遇或竞争威胁出现时能够迅速响应，成为能够真正随需应变的企业。“SOA相当于随需应变的DNA。”IBM公司WebSphere软件副总裁桑蒂•卡特(Sandy Carter)在接受《信息周刊》专访时如此评价。

　　在产品方面，IBM公司的信使软件WebSphere MQ提供了对SOA的支持。今年5月，IBM公司公布了信使软件的最新6.0版本和WebSphere Business Integration(WBI)Server Express版本软件。新版WebSphere MQ软件可以帮助企业显著降低日常频繁发生在操作系统与应用之间的数据交换成本，如人工译码、文件传输及端到端的方案等成本。新版WBI Server Express则包括了集成现有应用的新适配器，通过使用向导驱动(Wizard-Driven)的业务规则提供了业务灵活性，并简化了基于Web的远程部署。此外，IBM还提供了Rational测试工具，用来帮助开发客户基于SOA的数据应用。

　　微软公司的未来操作系统长角(Longhorn)已经公布了部分技术细节，微软公司高级副总裁埃里克•鲁德(Eric Rudder)透露，长角系统提供了一个安全可靠的Web服务体系架构，能够方便地与互联网上的其他系统进行交互。以前实现这样的功能，需要编写多达5.62万行代码，但如今，只需要3行代码就行了。

　　此前，微软已经推出了代号为Indigo的技术，这项技术据称为合作伙伴建立新一代连接系统SOA铺平了道路。Indigo既是.Net Framework 2.0的扩展，也是微软公司推进SOA的最新举措，更是对竞争对手，比如IBM公司和太阳计算机系统公司(Sun)等所提供的SOA方案的有力回应。“转向SOA已经是不可抗拒的趋势。” 埃里克•鲁德这样表态。

　　甲骨文公司的SOA策略与其“网格计算”战略紧密结合在一起。目前，甲骨文公司在SOA领域最大的优势来自其Enterprise Manager和 Application Server产品的覆盖面。通过不断收购和签署授权协议，甲骨文公司已经建立了一系列相对完整的开发和部署工具，其中最著名的包括Oracle database 10g、Oracle Application Server 10g和Oracle JDeveloper 10g。“SOA的关键是要把应用变成组件，Jdeveloper很重要的作用就是通过调用BEPL图形化工具，帮助客户把程序打包成组件。”甲骨文公司大中国区应用服务器咨询顾问总监雷振球透露。

　　SOA在影响中间件开发平台的同时，也改变了传统以应用为对象的开发方式，应用软件提供商同样必须适应SOA带来的影响。今年年初， 思爱普软件系统公司(SAP)表示说，他们将向企业提供“建设基于服务的架构”的服务—Enterprise Services Architecture Adoption Program (ESAP)。该服务向企业提供格式化的、逐步的服务，帮助企业解决建立以SOA为基础的各类解决方案时产生的策略变动。

　　据SAP 公司预计，到2005年底，该公司旗下所有产品将会以NetWeaver 基础软件为核心来打造。在NetWeaver 2004中包含一个综合性的组件设置，包括接口软件、应用服务程序、集成工具、数据分析系统、工作流程序、标准数据管，另外还有一个开发平台，所有这些都是基于SOA框架的。

　　不仅仅是SAP公司，大多数应用软件开发商都将随SOA而“舞”。事实上，很多开发商通过与平台开发商建立合作关系，在平台开发商提供的支持SOA的平台上进行应用系统的开发。“很多中国的ISV(独立软件开发商)都已经开始了行动。而且，不但是针对国内市场需要，他们将来走向国际市场，也必须要采用SOA的发展方向。”雷振球提醒中国的ISV。

　　SOA所带来的冲击波已远超出软件业。企业计算芯片提供商、通信产品开发商等如今都开始规划自己的SOA策略。英特尔公司去年推出了服务导向企业(Service Oriented Enterprise ，SOE)计划，SOE计划将移动计算、网格计算和可管理性元素融入同一框架之中，帮助IT经理利用这些技术来实现业务转型。根据基于该计划的英特尔企业平台技术发展策略，英特尔公司↖ntel)2005年首先实现双核处理器，以及“Silversvale”虚拟化分区技术;未来逐渐走向多核运算，虚拟化的范围也逐渐扩展到存储和I/O部件。

　　通信设备厂商亚美亚公司(Avaya)最近也发布了支持SOA的通信应用套件。这款名为Avaya Communication Manager 3.0的新产品是Avaya MultiVantage通信应用套件的核心部件。Avaya大中华区产品经理沈晓晖透露，Communication Manager 3.0采用了基于Web服务的开放式应用环境的架构，使开发者能够便捷地创建下一代企业通信应用，把实时通讯的应用融入到企业业务应用中，从而提高企业业务运作的灵活性。“SOA架构为ISV提供了最简单的接口，改变了原来开发的方式，从此，应用开发人员做Avaya产品的集成不再受到限制。”沈晓晖说，“这也许将改变我们传统的生活方式。”

　　尽管已有可部署的SOA 产品和平台出现，但这仅仅意味着开始。大部分企业将分阶段采用SOA，而SOA的核心标准也将继续演进。作为供应商们继续投入大力研发的战略性技术，在未来的一到两年内，竞争状况和针对明确的SOA要求推出的产品可能会发生巨大变化。另外，对于用户而言，究竟应该选择什么平台或者什么产品，的确是应该三思而慎行。