原文：http://www.ibm.com/developerworks/cn/webservices/ws-soa-design1/
。 SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。
服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用
Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。对于每一层，你都必须做设计和架构决定。因此，为了帮助用文件说明你的
SOA，你可能应该创建文档，由每个层相应的部分所组成。
这里是为你的 SOA 架构文档设计的模板：
1. 范围 <此架构适用于企业的哪个领域>
2. 操作系统层
1.
打包的应用程序
2.
自定义应用程序
3.
架构决策
3. 企业组件层
1.
企业组件支持的功能范围
2.
<这个企业组件支持业务领域、目标和过程>
3.
关于控制的决策
1. <作为这个客户端组织内部企业组件来选择某物的标准>
4.
架构决策
4. 服务层
1.
服务分类表
2.
架构决策
5. 业务过程和合成层
1.
业务过程可以表现为舞蹈编排（choreographies）
2.
架构决策
1. <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
6. 访问或者表现层
1.
<证明这层中 Web 服务和 SOA 的含意；>
7. 集成层
1.
<包含 ESB 因素>
1.
<我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
2.
安全问题和决策
3.
性能问题和决策
4.
技术和标准的局限性以及决策
5.
服务的监控和管理
现在，让我们更加仔细的描述一下每一层以及每一层之间的合成。
层 1：操作系统层。本层包含现有的自定义构建的应用程序，也叫做 遗留系统，包含现有的 CRM 和 ERP
打包应用程序，以及较旧的基于对象的系统实现，还有业务智能应用程序。SOA 的复合层架构可以利用现有的系统并且用基于服务的集成技术来集成它们。
层 2：企业组件层。本层由那些负责实现功能和保持公开服务 QoS 的企业组件组成。这些特殊的组件是企业和业务单元级支持的企业资产的受管理和控制的集合。同企业范围资产一样，他们通过架构最佳实践应用程序来负责确保
SLAs 的一致。大多数情况下，本层使用基于容器的技术，比如实现组件、负载均衡、高可用性和工作量管理的应用服务器。
层 3：服务层。业务选择来支持和公开的服务处在这一层。它们可以被发现或者直接静态绑定，接下来被调用，或者可能的话，编排到合成服务中。这个服务公开层同样提供了获取企业范围组件，业务单元特定组件，以及有些情况下，特定项目组建的机制，并且以服务描述的形式具体化了他们的接口子集。因此，企业组件使用它们接口提供的功能在运行时提供服务实现。在这一层的接口公开为一个服务描述，在这层中他们被公开以提供使用。他们可以独立存在或者作为合成服务。
层 4：业务过程合成或编排层。第三层中公开的服务的合成和编排在这一层中被定义。通过配合、编排，服务被绑定成一个流程，并且从而作为单独的应用程序而共同作用。这些应用程序支持特殊的用例和业务过程。这里，可视的流程合成工具，比如
IBM® WebSphere® Business Integration Modeler
或者 Websphere Application Developer Integration Edition，都可以用来设计应用程序流程。
层 5：访问或表现层。尽管这一层经常超出了围绕 SOA 讨论的范围，但是它却变得越来越有意义。在这里我描述它因为标准越来越集中，比如用于
Remote Portlets Version 2.0 的 Web 服务和其他技术，这些技术追求在应用程序接口或者表现层来利用
Web 服务。你可以把它作为将来的层用来满足将来的解决方案的需求。注意到以下这两点是非常重要的：SOA
将用户接口从组件中分离出来；最终你需要提供从访问路线到服务或者合成服务的端到端解决方案。
层 6：集成（ESB）。这一层使服务可以集成，通过引入一系列可靠的性能的集合，比如智能路由，协议中介和其他转化机制，经常被描述为
ESB（参阅 参考资料）。Web Services Description Language（WSDL）制定了绑定，其包含提供服务的地址。另一方面，ESB
为集成提供了位置独立机制。
层 7：QoS。这一层提供了监视，管理和维持诸如安全，性能和可用性等 QoS 的能力。这是一个通过
sense-and-respond 机制和监测 SOA 应用程序健康的工具来进行的后台处理过程，包括 WS-Management
和其他相关协议的所有的重要的标准实现以及为 SOA 实现服务质量的标准。
基于服务的建模和架构过程包含三个主要的步骤：服务，组件和流程（典型地，服务的编排）的鉴别，指定和实现。
Service 鉴别：这个过程由域分解、现有资产分析和目标服务建模的自顶向下、自底向上、中间向外技术的联合组成。在自顶向下视图中，业务用例的蓝图提供了业务服务的规范。这个自顶向下的过程作为域分解来被引用，域分解由业务领域到它的功能区域和子系统的分解组成，包含它的流程或过程分解成过程、自过程和高级别业务用例。很多情况下，这些用例是公开在企业边缘的业务服务，或者在贯穿业务线企业边界内所用的非常好的候选。
在过程的 从下到上的部分或者现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的
API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。
中间向外视图由目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。
服务分级和分类：这个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。
子系统分析：这个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面的活动中实现服务。
组件指定：在下面的主要活动中，实现服务的组件的细节将指定：
* 数据
* 规则
* 服务
* 可配置概要
* 变更
消息和时间指定以及管理定义出现在这一步骤中。
服务分配：服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。结构化组件在你使用模式来构造企业组件时会通过以下几点的联合的形式出现：
* 中介体
* Facade
* 规则对象
* 可配置概要
* 工厂
服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务向 SOA 层中的分配是一个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架构有关系，也同在运行时设计和用来支持
SOA 实现的技术操作架构有关的。
服务实现：这个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用
Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同于业务功能包括：服务的安全、管理和监视。
事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。
自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。
| 
