面向服务的体系结构概述:第二部分

第二部分：作为解决方案的面向服务体系结构

自从“软件危机”促进软件工程的开创以来，IT 界一直在努力寻求解决上述问题的方案。在过去几年里，下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技术，而我们重点关注的将是这些技术如何帮助解决 IT 问题。

面向对象的分析和设计

在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中，Larman 将面向对象的分析和设计的本质描述为“从对象（物体、概念或实体）的角度考虑问题域和逻辑解决方案”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中，Jacobson 等将这些对象定义为“特点在于具有许多操作和状态（记忆这些操作的影响）的物体”。

在面向对象的分析中，这样的对象是用问题域来标识和描述的，而在面向对象的设计中，它们转变成逻辑软件对象，这些对象最终将用面向对象的编程语言进行实现。

通过面向对象的分析和设计，可以封装对象（或对象组）的某些方面，以简化复杂业务场景的分析。为了降低复杂性，也可以抽象对象的某些特征，这样就可以只捕获重要或本质的方面。

基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期，细粒度的对象被标榜为提供“重用”的机制，但是这样的对象的粒度级别太低了，没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中，粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式，还可以将打包的解决方案套件封装成这样的“组件”。

一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构，就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术：实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现

面向服务的设计

在“Component-Based Development for Enterprise Systems”中，Allen 涉及了服务的概念，“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口（它包括交互标准）进行访问。组件必须能够连接到其他组件（通过通信接口）以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体，它作为单个实例存在，并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。第 22 页的图 2-3 展示了重要的面向服务术语：

• 服务：逻辑实体，由一个或多个已发布接口定义的契约。
• 服务提供者：实现服务规范软件实体。
• 服务使用者（或请求者）：调用服务提供者的软件实体。传统上，它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。
• 服务定位器：一种特殊类型的服务提供者，它作为一个注册中心，允许查找服务提供者接口和服务位置。
• 服务代理：一种特殊类型的服务提供者，它可以将服务请求传送到一个或多个其他的服务提供者。

图 2-3 面向服务的术语

基于接口的设计

在组件和服务开发中，都需要进行接口设计，这样软件实体就可以实现和公开其定义的关键部分。因此，在基于组件和面向服务的系统中，“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义：

• 接口：定义一组公共方法签名，它按照逻辑分组但是没有提供实现。接口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。
• 已发布接口：一种可唯一识别和可访问的接口，客户端可以通过注册中心来发现它。
• 公共接口：一种可访问的接口，可供客户端使用，但是它没有发布，因而需要关于客户端部分的静态知识。
• 双接口：通常是成对开发的接口，这样，一个接口就依赖于另一个接口；例如，客户端必须实现一个接口来调用请求者，因为该客户端接口提供了某些回调机制。

第 23 页的图 2-4 定义了客户关系管理 (CRM) 服务的 UML 定义，它表示为一个 UML 组件，实现接口 AccountManagement、ContactManagement 和 SystemsManagement。在这些接口中只有头两个接口是已发布接口，不过，后者是公共接口。注意，SystemsManagement 接口和 ManagementService 接口构成了双接口。CRMservice 可以实现许多这样的接口，但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端提供不同或附加的服务。在一些运行时环境中，这样的功能也用于在单个组件或服务上支持相同接口的不同版本。

图 2-4 已实现的服务

分层应用程序体系结构

如前所述，面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法，但是您必须理解的一点是，好的基于组件的应用程序未必就构成好的面向服务的应用程序。一旦理解了服务在应用程序体系结构中所起的作用，组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第 24 页中的图 2-5 演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现（它更靠近应用程序的使用者）。为称呼系统的这一部分而创造的术语是“应用程序边界”，它反映了服务是公开系统的外部视图的极好方法的事实（通过内部重用并结合使用传统组件设计）。

图 2-5 应用程序实现层：服务、组件、对象