以下笔记摘录自 IBM DevelopmentWork CN :
本笔记只抄录部分重点，要获取更详细的内容，建议前往 http://www.ibm.com/developerworks/cn/webservices/ws-soa-term1/index.html
关于作者
 |
||
|
|
|
Bertrand Portier 是 IBM 软件部的 Enterprise Integration Solutions (EIS) 的一位 IT 架构师。他曾参与过大量策略 SOA 转换项目，并基于这些经验与 IBM 软件部开发团队进行了广泛的合作。他具有 J2EE 和 Web 服务方面的背景，目前正在参与大量基于资产和模型驱动的开发活动。 |
面向服务的体系结构（Service-oriented architecture，SOA）
我将基于 IBM Rational Method Composer Plug-in for SOA Governance 和 IBM Rational Unified
Process for Service-Oriented Architecture 给出一个定义。
“服务是执行可重复任务的可发现资源，由外部化的服务规范进行描述。”
您可能会认为上述定义过于偏重于技术。请记住，一定不要过于依赖于服务的正式定义，而要将重点放在
服务背后的主要概念上，包括：
业务一致性：服务并不基于 IT 功能，而是基于业务的需求。服务业务一致性由服务分析和设计技术提供
支持。
规范：服务是自包含的，采用接口、操作、语义、动态行为、策略和服务质量进行描述。
可重用性：服务可重用性由服务粒度设计决策予以支持。
协议：服务协议是实体（即服务提供者和使用者）之间就相关事项达成的一致意见。这些协议基于服务规
范，而不是实现。
承载和可发现性：随着生命周期的进展，将承载服务，并可以对其进行发现；这由服务元数据、注册中心
和存储库提供支持。
聚合：松散耦合的服务聚合为企业内部或企业间的业务流程或组合应用程序。
还要务必注意，并非所有东西都是服务。例如，有些 IT 功能不应该作为服务公开。可以使用 IBM 的面
向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）等分析技术基于上面
列出的概念标识恰当的服务列表。
Open Group Architecture Forum (TOGAF) 根据上下文提供了两个体系结构定义：
“系统的正式描述，或用于指导其实现的组件级别的系统详细计划。
组件的结构、它们相互间的关系以及控制其设计及将来发展的原则和指导方针。”
我们会发现体系结构对于进行以下工作必不可少：
在不同的抽象级别进行设计和建模
将规范与实现分离
构建灵活的系统
确保满足业务需求
分析需求更改的影响
确保遵循相关原则
创建企业体系结构的主要目的是为了确保业务策略与 IT 投资保持一致。通过这样，企业体系结构可支持
从业务策略一直到基础技术的可跟踪性。
SOA Foundation 参考模型
business service:
Exploit the SOA foundation to deliver a component business model
（利用SOA基础提供商业模型的一个组成部分。）
--------------------------------------------------------------------------------------------
Business innovation & optimization services: Provide for better decision-
making with real-time business.
（业务创新和优化服务：提供更好的决策提供实时业务。）
--------------------------------------------------------------------------------------------
Interaction services: Enable collaboration between people process &
information
（互动服务：启用人民之间的合作进程与信息）
Process services: Orchestrate and automate business process
（流程服务：协调和业务流程自动化）
Information services: Manage diverse date and content in a unified manner
（信息服务：管理不同日期和内容，在一个统一的方式）
--------------------------------------------------------------------------------------------
Enterprise service bus: Enable inter-connectivity between service
（企业服务总线：启用相互之间的连接服务）
--------------------------------------------------------------------------------------------
Partner services: Connect with trading partners
（合作伙伴服务：连接贸易伙伴）
Business application services: Build on a robust, scalable, and secure
services environment
（商业应用服务：建立一个强有力的，可扩展和安全的服务环境）
Access services: Facilitate interactions with existing information and
application assets
（接入服务：提供便利的互动与现有的信息和应用资产）
--------------------------------------------------------------------------------------------
Infrastructure service: Optimize throughput, availability and utilization
（基础设施服务：优化吞吐量，可用性和利用率）
--------------------------------------------------------------------------------------------
left: Development services: Intergrated environment for design and creation of
solution assets
（开发服务：集成环境的设计和建立解决资产）
--------------------------------------------------------------------------------------------
right: Management services: Manage and secure services, applications & resource
（管理服务：管理和安全服务，应用程序和资源）
面向服务的体系结构
IBM SOA Foundation 对 SOA 的定义如下：
“面向服务的体系结构 (SOA) 是一种用于创建企业 IT 体系结构的体系结构样式，利用了面向服务的原则
来实现业务和支持业务的信息系统之间更为紧密的关系。”
SOA 具有以下特征：
它加强了企业体系结构和业务之间的联系。
它允许将组合应用程序作为一组集成服务进行构建。
它提供了灵活的业务流程。
图2：SOA解决方案堆栈
5 个层次分别如下（按照从下到上的顺序）：
可操作系统：表示现有 IT 资产，说明 IT 投资非常宝贵，应该在 SOA 加以利用。
服务组件：实现服务，可能通过使用“可操作系统”层中的一个或多个应用程序来进行。如模型中所示，使
用者和业务流程并不能直接访问组件，而仅能访问服务。现有组件可以在内部重用，或在合适的情况下在
SOA 中使用。
服务：表示已部署到环境中的服务。这些服务由可发现实体进行治理。
业务流程：表示将业务流程作为服务编排实现的操作构件。
使用者：表示用于访问业务流程、服务和应用程序的通道。
治理
因为 SOA 具有跨组织的特征，其中的服务投资者、设计人员、实现人员、维护人员或客户并不位于相同
的组织、业务部门、IT 部门、LOB、分支机构或企业中，因此治理对于以增量的方式成功采用 SOA 非常
必要。
治理是关于以下方面的概念：
建立责任、授权和通信链，以对人员进行权利分配（决策权）。
建立度量、策略和控制机制，以支持各个人员执行各自的角色任务和履行相关职责。
治理处理的是分配决策权力，并决定使用何种措施以及遵循哪些策略来进行这些决策。决策权分配给角色
，而不是个人。另一方面，管理 则包括为角色分配人员以及监视策略的执行情况。
任何治理解决方案中都包含要符合组织的遵从性要求的目的。遵从性 是记录并证明治理已就位并得到了
执行：会记录决策，并遵循有关决策的策略。”
IT 治理
“IT 治理指属于组织的信息技术流程以及这些流程支持业务目标的方式的治理方面的内容。”
IT 治理可以通过分配 IT 流程的决策权和措施进行描述。
SOA 治理
“SOA 治理是 IT 治理的扩展，具体关注服务和其他 SOA 构件的生命周期。”
具体来说，SOA 治理关注的是有关服务标识、资金投入、设计、实现、部署、重用、发现、访问、监视、
管理和退役的方法和流程。
“SOA 治理处理以下这些类型的挑战：
哪些新组织角色和结构可促进服务标识、设计和共享？
哪些标准支持服务的投资、维护、使用和共享？
业务部门如何决定在服务创建和维护方面进行投资？
企业的面向服务的成熟度如何？
需要进行哪些训练、培训或指导？"
SOA 生命周期
IBM SOA Foundation 在其 SOA 生命周期的定义中使用了四个阶段：
建模包括业务分析与设计（要求、流程、目标和主要性能指标）及 IT 分析与设计（服务标识和规范）。
组装包括服务实现和组合应用程序的构建。
部署包括应用程序和运行时（如企业服务总线——Enterprise Service Buses，ESB）的部署。
管理包括操作环境维护、服务性能监视和服务策略执行。
图3：SOA生命周期：
|--> Assemble --> Deploy --> Manage |
------------<-----Model<-------------
业务一致性
SOA 成功的关键在于，对遗留应用程序等现有 IT 资产的重用。不过，SOA 允许企业将其技术工作的重点
放在将支持其业务功能或流程的服务上——例如，能够与业务任务对应的服务操作——而不是基于竖井
(silo) 式信息体系的服务。业务一致性涵盖范围更全面，且能促进业务和 IT 之间更好地进行沟通。在
本系列后面的部分中，我们将讨论 SOA 分析和设计的自顶向下、自底向上及中间相遇方法，从而了解如
何将业务模型细化为 IT 模型，以及可以如何利用主要的现有功能。
不过，与业务保持一致并不意味着让业务功能和 IT 实现紧密耦合。关键的 SOA 概念之一就是松散耦合
以及规范（业务模型、接口）和实现（技术）之间的分离，通过这样可将更改（如替换服务提供者）的影
响降到最低。
业务组件化
业务组件具有独特的业务用途，通过其提供或使用（来自其他组件）的服务进行协作。这可以被视为“业
务体系结构”的一部分。
业务建模
IBM Rational Unified Process对业务建模的定义如下：
“Rational Unified Process Business Modeling 规程提供了具体的指导信息，说明如何使用各种不同的
方法和技术在不同的正式级别描述“原始”或“将来”业务。”