通过本系列的第1部分了解一些基本的SOA术语。Bertrand Portier将定义包括服务、体系结构、面向服务的体系结构、治理和业务流程在内的多个术语，并说明为何它们是SOA成功的基础。他还介绍了IBM SOA Foundation中的主要情况。

　　引言

　　在任何领域中，语义都非常重要，而在面向服务的体系结构（Service-oriented architecture，SOA）中更是如此。由于SOA涉及多个团队和组织，因此就相关术语达成一致至关重要。本系列将带着您开始SOA之旅，为您定义基础术语和主要概念。您将了解SOA领域中所使用的各个词汇。对于每个术语，将说明其为何对SOA重要、其在这种情况下的含义、相关的标准有哪些以及与其他术语的区别如何。

　　关于组织方式的说明

　　以下列出的术语并不是按照字母顺序排列的，也不是按照其重要性进行排列。我们将按照构建块的方式对其进行排列。首先讨论的是“服务”，因为这个术语可能是理解SOA框架的最基本概念。我们将以服务为基础形成“体系结构”、“治理”和“业务”概念的定义。在很多情况下，我们都将较大的术语分解为较小的组成部分进行讨论。

　　服务

　　服务显然是面向服务的体系结构的核心，术语服务 的使用非常广泛。不过，这个术语对于不同的人有不同的含义，“什么是服务？”这个问题经常会引发激烈的争论。我听到过人们讨论业务任务、业务服务、应用程序功能、技术服务或基础设施服务。我将基于IBM Rational Method Composer Plug-in for SOA Governance和IBM Rational Unified Process for Service-Oriented Architecture给出一个定义。（有关更多信息，请参见参考资料部分。）

　　“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。”

　　由于存在多种不同的定义，通过定义“服务”来开始本文的讨论比较困难。例如，您可能会认为上述定义过于偏重于技术。请记住，一定不要过于依赖于服务的正式定义，而要将重点放在服务背后的主要概念上，包括：

　　·业务一致性：服务并不基于IT功能，而是基于业务的需求。服务业务一致性由服务分析和设计技术提供支持。
　　·规范：服务是自包含的，采用接口、操作、语义、动态行为、策略和服务质量进行描述。
　　·可重用性：服务可重用性由服务粒度设计决策予以支持。
　　·协议：服务协议是实体（即服务提供者和使用者）之间就相关事项达成的一致意见。这些协议基于服务规范，而不是实现。
　　·承载和可发现性：随着生命周期的进展，将承载服务，并可以对其进行发现；这由服务元数据、注册中心和存储库提供支持。
　　·聚合：松散耦合的服务聚合为企业内部或企业间的业务流程或组合应用程序。

　　这些组合特征表明SOA并不仅与“技术”相关，而且也与业务要求和需求相关。

　　还要务必注意，并非所有东西都是服务。例如，有些IT功能不应该作为服务公开。可以使用IBM的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）等分析技术基于上面列出的概念标识恰当的服务列表。我们将在本文中详细讨论这些方面的内容（包括本部分中所有以粗体显示的术语）。

　　体系结构
　　
　　和服务类似，很难得到一个大家一致认可的体系结构的定义。不过，与服务不同的是，人们在谈论SOA时有时候会忘记体系结构，而显然不应将其忘记！事实上，企业体系结构和面向服务的体系结构具有相同的目标，即通过集成的IT策略支持业务。例如，企业架构师是SOA成功的关键，因为他们将根据不断发展的业务需求和要求确定企业的IT系统的策略发展方向。

　　Open Group Architecture Forum (TOGAF)根据上下文提供了两个体系结构定义：

　　·“系统的正式描述，或用于指导其实现的组件级别的系统详细计划。
　　·组件的结构、它们相互间的关系以及控制其设计及将来发展的原则和指导方针。”

　　这两个定义都与理解SOA中的“A”相关。对其进行进一步细分，我们会发现体系结构对于进行以下工作必不可少：

　　·在不同的抽象级别进行设计和建模
　　·将规范与实现分离
　　·构建灵活的系统
　　·确保满足业务需求
　　·分析需求更改的影响
　　·确保遵循相关原则

　　企业体系结构

　　以下是维基百科(Wikipedia)中的定义：

　　“企业体系结构是这样一种做法，即应用描述组织的流程、信息系统、个人和组织子单元的全面而严格的方法，从而使其与组织的核心目标和策略方向保持一致。

　　创建企业体系结构的主要目的是为了确保业务策略与IT投资保持一致。通过这样，企业体系结构可支持从业务策略一直到基础技术的可跟踪性。”

　　可以将项目级别的“体系结构”和组织级别的“企业体系结构”与此进行比对。请注意对流程、信息系统、人员、目标、策略和业务IT一致性的参考信息。

　　面向服务的体系结构

　　面向服务

　　正如IBM SOA Foundation白皮书中所述“…面向服务是将业务作为一组有联系的服务集成的方法。”有关IBM SOA Foundation的更多信息，请参见参考资料。

　　此处的关键词是“业务”。例如，面向服务可提供非常有用的灵活性，能使用来自一个业务部门（Line Of Business，LOB）、多个业务部门以及业务合作伙伴的服务灵活地实现业务流程。

　　SOA Foundation参考模型

　　IBM SOA Foundation中提供了一个SOA参考模型，如图1中所示，此模型说明了为了支持面向服务的体系结构所需的主要功能。

　　由于这个模型基于面向服务的概念，因此它允许从小项目做起，逐渐扩展在企业内的集成，从而在出现新业务需求时以增量的方式采用SOA。有关SOA Foundation的更多信息，请参见参考资料。

　　图1. SOA Foundation参考模型
 
　　面向服务的体系结构

　　IBM SOA Foundation对SOA的定义如下：

　　“面向服务的体系结构(SOA)是一种用于创建企业IT体系结构的体系结构样式，利用了面向服务的原则来实现业务和支持业务的信息系统之间更为紧密的关系。”

　　SOA具有以下特征：

　　·它加强了企业体系结构和业务之间的联系。
　　·它允许将组合应用程序作为一组集成服务进行构建。
　　·它提供了灵活的业务流程。

　　面向服务的体系结构是全新（与“革新”相对）的事物，意味着新的企业人员角色、新的协作方式、新的支持框架以及新的软件构件。

　　SOA解决方案堆栈

　　如图2中所示，SOA解决方案堆栈是一个SOA参考模型，描述SOA解决方案的运行时概念视图。

　　有时也将其称为“SOA分层体系结构”，其中介绍了各个层次和概念（如业务流程、服务或服务组件）及其相互间的关系。

　　它不依赖于实现所使用的技术。这个分离非常重要，具体请参见本系列的第2部分中的模型驱动的体系结构（Model-Driven Architecture，MDA）的相关内容。

　　图2. SOA解决方案堆栈
 
　　5个层次分别如下（按照从下到上的顺序）：

　　·可操作系统：表示现有IT资产，说明IT投资非常宝贵，应该在SOA加以利用。
　　·服务组件：实现服务，可能通过使用“可操作系统”层中的一个或多个应用程序来进行。如模型中所示，使用者和业务流程并不能直接访问组件，而仅能访问服务。现有组件可以在内部重用，或在合适的情况下在SOA中使用。
　　·服务：表示已部署到环境中的服务。这些服务由可发现实体进行治理。
　　·业务流程：表示将业务流程作为服务编排实现的操作构件。
　　·使用者：表示用于访问业务流程、服务和应用程序的通道。

　　治理

　　因为SOA具有跨组织的特征，其中的服务投资者、设计人员、实现人员、维护人员或客户并不位于相同的组织、业务部门、IT部门、LOB、分支机构或企业中，因此治理对于以增量的方式成功采用SOA非常必要。

　　此部分包含IBM Rational Method Composer Plug-in for SOA Governance中的相关定义。它定义了治理、IT治理、SOA治理及其与管理或遵从性之间的差别。它还描述了SOA治理所处理的各项挑战。有关Rational Methode Composer的更多信息，请参见参考资料部分。

　　治理

　　”治理是关于以下方面的概念：

　　·建立责任、授权和通信链，以对人员进行权利分配（决策权）。
　　·建立度量、策略和控制机制，以支持各个人员执行各自的角色任务和履行相关职责。

　　治理处理的是分配决策权力，并决定使用何种措施以及遵循哪些策略来进行这些决策。决策权分配给角色，而不是个人。另一方面，管理 则包括为角色分配人员以及监视策略的执行情况。

　　任何治理解决方案中都包含要符合组织的遵从性要求的目的。遵从性 是记录并证明治理已就位并得到了执行：会记录决策，并遵循有关决策的策略。”

　　IT治理

　　“IT治理指属于组织的信息技术流程以及这些流程支持业务目标的方式的治理方面的内容。”

　　IT治理可以通过分配IT流程的决策权和措施进行描述。

　　SOA治理

　　“SOA治理是IT治理的扩展，具体关注服务和其他SOA构件的生命周期。”

　　具体来说，SOA治理关注的是有关服务标识、资金投入、设计、实现、部署、重用、发现、访问、监视、管理和退役的方法和流程。

　　“SOA治理处理以下这些类型的挑战：

　　·哪些新组织角色和结构可促进服务标识、设计和共享？
　　·哪些标准支持服务的投资、维护、使用和共享？
　　·业务部门如何决定在服务创建和维护方面进行投资？
　　·企业的面向服务的成熟度如何？
　　·需要进行哪些训练、培训或指导？”

　　生命周期

　　服务生命周期

　　服务生命周期由服务可能处于的状态以及触发状态间转换的事件组成。

　　在其生命过程中，服务将度过很多阶段（和我们一样 :)）。将服务的生命周期视为具有状态（位置）和转换的业务状态机；服务可能处于其中的某个状态，而转换使其从一个状态发展到另一个状态。

　　SOA治理考虑的是有关服务生命周期的计划、定义、启用和测定。SOA治理定义服务状态的含义、从一个状态发展到另一个状态需要发生的操作（转换）、如何进行（流程和方法）以及由谁进行（角色）。

　　例如，SOA治理可以将服务状态定义为标识、投入资金、指定、实现、审批、操作、发布、弃用和退役。

　　基础SOA框架则将需要通过生命周期支持服务，并确保遵循了配备的流程。例如，服务注册中心和存储库需要允许用户进行相应的操作，以便服务在生命周期中逐渐发展。协作和投资组合管理工具需要能够允许用户（仅限于具有权限的用户）作出将使得服务从一个状态过渡到另一状态的决策，并在需要进行操作时通知用户。

　　SOA生命周期

　　IBM SOA Foundation在其SOA生命周期的定义中使用了四个阶段：

　　·建模包括业务分析与设计（要求、流程、目标和主要性能指标）及IT分析与设计（服务标识和规范）。
　　·组装包括服务实现和组合应用程序的构建。
　　·部署包括应用程序和运行时（如企业服务总线——Enterprise Service Buses，ESB）的部署。
　　·管理包括操作环境维护、服务性能监视和服务策略执行。

　　正如上面定义的，SOA治理和流程为这四个阶段提供支持。此情况如图3中所示。

　　图3. SOA生命周期
 
　　业务

　　现在的企业需要能够识别更改，并快速对其作出反应，而且还要同时维护其由雇员、合作伙伴、客户组成的生态系统。正如IBM On Demand Business所述，需要全面利用先进技术，以实现此目标。有关IBM On Demand Business的信息，请参见参考资料部分。

　　由于客户和法律法规遵从之类的外部要求和竞争与市场之类的变化，业务必须具有灵活性和敏捷性。面向服务的体系结构可帮助实现此目标，允许业务根据变化快速调整。

　　业务一致性

　　SOA成功的关键在于，对遗留应用程序等现有IT资产的重用。不过，SOA允许企业将其技术工作的重点放在将支持其业务功能或流程的服务上——例如，能够与业务任务对应的服务操作——而不是基于竖井(silo)式信息体系的服务。业务一致性涵盖范围更全面，且能促进业务和IT之间更好地进行沟通。在本系列后面的部分中，我们将讨论SOA分析和设计的自顶向下、自底向上及中间相遇方法，从而了解如何将业务模型细化为IT模型，以及可以如何利用主要的现有功能。

　　不过，与业务保持一致并不意味着让业务功能和IT实现紧密耦合。关键的SOA概念之一就是松散耦合以及规范（业务模型、接口）和实现（技术）之间的分离，通过这样可将更改（如替换服务提供者）的影响降到最低。

　　业务组件化

　　IBM Component Business Model是一种策略方法，允许企业将重点放在核心竞争力上（使得企业从竞争者中脱颖而出的部分），了解如何使用资源，从而更好地保持业务和IT之间的一致性。有关Component Business Model的更多信息，请参见参考资料部分。非常需要这些业务组件交互的集成以及灵活性（如外包组件），而这通过面向服务得到了实现：业务组件具有独特的业务用途，通过其提供或使用（来自其他组件）的服务进行协作。这可以被视为“业务体系结构”的一部分。

　　业务建模

　　IBM Rational Unified Process对业务建模的定义如下：

　　“Rational Unified Process Business Modeling规程提供了具体的指导信息，说明如何使用各种不同的方法和技术在不同的正式级别描述“原始”或“将来”业务。”

　　业务建模引入了一系列概念、交付内容和角色；它将描述和组织有关业务策略、业务远景、业务目标、业务目的、业务词汇、业务体系结构、业务分析与设计、业务规则、业务价值、业务用例、业务实体以及业务流程的任务。下面的部分对此进行了更为详细的说明。

　　SOA是有关重新组织业务和IT系统的长期策略，其目的是为了快速对变化作出响应。参考资料部分提供了IBM Systems Journal第44卷第4期有关SOA的链接，其中更为详细地说明了面向服务的思维方式中业务所处的位置。

　　业务流程

　　业务流程由一系列能产生有价值的结果的活动组成。

　　业务流程具有贯穿其中的相关业务项目（数据），包括作为流程的输入和输出使用的项目。

　　业务和任务

　　业务活动和任务是通过连接能组成业务流程的元素。

　　您可以将持续时间、成本、收益、资源、输入和输出与业务活动相关联。这些是用于对业务流程进行分解的元素。服务标识技术包括将业务流程分解为活动和任务的技术，将通过这些活动和技术对现有的或将要开发的服务（及其操作）进行标识。这些服务有时称为“业务服务”。

　　建模业务流程

　　组织的业务流程（当前的、“原始”流程）可能很复杂，因为这些流程经常是对最初开发的流程进行了大量的更改之后得到的。理解、正式定义并记录业务流程的工作非常重要。另外，通过建模和模拟“原始”和“将来”业务流程，将能够确定成本、延迟或能实现自动化的方面。

　　建模业务流程不仅提供了可视表示形式，而且，当在框架中进行此工作时，还能提供基础元数据（我们将在本系列的第2部分进行讨论），从而支持稍后将业务流程模型的元素细化为（或链接到）IT设计元素。

　　人工任务

　　很多时候在流程中都会需要人工交互（如出差审批或贷款审批）。在业务流程建模期间，会将人工任务标识为手工任务，并为每个人工任务分配不同的角色。部署后，SOA环境将需要把人工任务作为流程执行的一部分进行支持。例如，IBM WebSphere Process Server之类的产品将为用户提供等待其处理的人工任务的列表。通过与此类产品组合，IBM WebSphere Portal和Lotus Sametime之类的产品还将允许用户在需要的情况下与同事进行协作，并就他们的决定向系统发出通知，以便继续执行流程。人工方面对于SOA的成功非常重要。

　　BPEL

　　IBM、Microsoft和其他业界企业已经将业务流程执行语言（Business Process &#101xecution Language，BPEL）作为Web服务规范提交，以用于正式地指定业务流程和交互协议。

　　1.1版于2003年发布，目前已经发布了2.0版本OASIS提交草案，称为Web服务业务流程执行语言（Web Services Business Process &#101xecution Language，WSBPEL）。请参见参考资料部分中提供的相关链接。

　　行业

　　业务流程可以特定于某个领域或行业，如保险索赔流程。行业联盟定义行业业务流程。例如，电信管理论坛 (TeleManagement Forum) 为电信行业定义增强的电信运营图（Telecom Operations Map，eTOM）。除此之外，企业可以通过在内部采用经过验证的业务流程（如来自IBM Industry Models的流程）来使自己获得优于竞争者的优势。请参见参考资料部分提供的IBM Insurance Application Architecture (IAA)的链接，这就是IBM Industry Models中提供的流程之一。

　　业务流程管理

　　业务流程管理（Business Process Management，BPM）从业务流程整个生命周期的角度看待它，以便提高其效率、灵活性和控制。

　　BPM讨论的是进行建模、模拟、优化、部署、运行、管理和监视，然后将结果提交回去，以改进模型，从而进行一个持续的改进循环。IBM WebSphere提供了BPM所需的各种产品。

　　结束语

　　在SOA术语系列的第1部分中，我们定义了核心SOA术语，即服务、SOA以及SOA如何与体系结构相关。我们定义了SOA的两个核心元素，服务生命周期和SOA治理。最后，我们讨论了SAO和业务的关系，并对业务流程进行了说明。这仅是开始。本系列的后续部分将定义与IT设计、开发、运行时和管理相关的SOA术语。欢迎您继续阅读developerWorks上本系列的其他文章！