通过将这些原则应用到面向服务的体系结构设计，可以帮助通过 IT 灵活性实现业务灵活性远景。
引言
面向服务的体系结构(Service-Oriented Architecture，SOA)提供了支持业务灵活性的 IT 灵活性远景。在本文中，我们将重点讨论 IT 灵活性的两个特定方面:流程实现的分离和简化。如何说明和实现各个服务对 IT 灵活性的这些方面有很大的影响，因此也对业务灵活性有很大的影响。我们此处的目标是提供支持 SOA 远景的服务说明和实现指南。本文的论述结构如下:
- 首先，我们将描述将在其中说明和实现服务和服务操作的上下文环境。我们将考虑 SOA 基础结构的职责和服务的职责。
- 接下来，我们将讨论适用于整个服务(而不是各个操作)规范的设计原则。
- 最后，我们将说明适用于各个服务操作的设计原则。
我们在文中所给出的设计原则旨在通过改善流程实现的分离和简化来提高 IT 灵活性，因此，我们将通过对这些理念进行更为深入的分析来完成我们的介绍。
分离
SOA 原则非常强调将服务使用者和服务提供者分离开来，关于此类分离实际的含义，有很多不正式但非常有用的约定。分离背后的一个基础概念就是，对服务提供者的修改不应要求在服务使用者中进行相应的修改。例如，将当前在特定操作系统上运行的服务重新部署到另一个平台的决定完全可能不要求对服务使用者进行更改。一个主要的 SOA 指导原则就是，要减少使用者和提供者之间的依赖关系。
分离应用于技术层面，强调 Web 服务和异步消息交付之类的技术，以允许使用者独立于服务提供者选择实现和可用性选项。我们还可以通过各种方式让 SOA 基础结构实现技术分离，如:
表 1. 分离技术
| 依赖项 | 所需的分离 | 分离技术 |
| 平台 | 服务硬件、操作系统或实现语言的选择不应对服务使用者的选择进行约束。 | 服务采用不会约束服务使用者平台的标准服务公开机制。通常使用 Web 服务技术。 |
| 位置 | 对服务实现位置的更改应尽可能少地影响客户机。 | SOA 基础结构提供了运行时服务定位和请求路由机制。 |
| 可用性 | 各个服务可用性特征不应影响业务流程的整体可用性。例如，不应要求对服务和使用者的维护计划进行同步。 | SOA 基础结构具有合适的存储与转发特征，提供了可靠的异步调用机制。 |
| 版本 | 应该可以在不要求所有服务使用者同时升级的前提下引入新版本的服务。 | SOA 基础结构提供了消息转换和扩充功能。即使服务提供者接口本身(使用者和提供者之间的基础结构中介)发生了更改，服务使用者也可访问基础结构提供的一致接口。 |
服务应该设计为与要部署到其中的 SOA 基础结构兼容，特别是，服务应确保避免不必要的耦合。举个相反的例子，有状态服务接口将倾向于通过将使用者与特定提供者实例关联来增加使用者和提供者间的耦合。
分离的概念也同样适用于非技术的业务层次。服务使用者应该尽可能与服务提供者实现的业务逻辑细节分离。为了实现此类分离，同样也需要进行细心的设计。在下面的服务设计原则部分，我们将讨论将服务接口表述为有意义的业务操作(而不是细粒度的原语方法)的好处。
| 共10页: 1 [2] [3] [4] [5] [6] [7] [8] [9] [10] 下一页 |
