- 范围 <此架构适用于企业的哪个领域>
- 操作系统层
- 打包的应用程序
- 自定义应用程序
- 架构决策
- 企业组件层
- 企业组件支持的功能范围
- <这个企业组件支持业务领域、目标和过程>
- 关于控制的决策
- <作为这个客户端组织内部企业组件来选择某物的标准>
- 架构决策
- 服务层
- 服务分类表
- 架构决策
- 业务过程和合成层
- 业务过程可以表现为舞蹈编排（choreographies）
- 架构决策
- <哪一个过程需要编排在舞蹈编排里面以及哪一个镶嵌在应用程序里面？>
- 访问或者表现层
- <证明这层中 Web 服务和 SOA 的含意；即便要。例如，在用户接口级别上调用 Web 服务的 portlet 的使用，以及在此层机能上的含意。>
- 集成层
- <包含 ESB 因素>
- <我们如何确保使用服务的客户端系统级的一致性（SLA）和服务质量（QoS）？>
- 安全问题和决策
- 性能问题和决策
- 技术和标准的局限性以及决策
- 服务的监控和管理
- 描述和决策
层 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 实现服务质量的标准。