级别： 初级 Mohammad Abu-Matar (abumatar@hotmail.com), 高级软件工程师, LexisNexis
2008 年 4 月 11 日 在本文中，了解一种基于软件产品线原理来设计面向服务的应用程序的方法。探索面向服务的软件产品线（Service-Oriented Software product line，SoSPL）方法，此方法将 SPL 可变性分析技术应用于 Web 服务，以设计基于服务的自定义应用程序。了解软件产品线（software product line，SPL）如何促进不断发展的系统系列的敏捷和灵活的应用程序开发。了解采用 SPL 原理如何提供一种系统的方法来分析和设计面向服务的应用程序。
面向服务的体系结构（Service-Oriented Architecture，SOA）已作为一种基于标准的计算模型而出现，用于设计、构建和部署灵活的分布式软件应用程序。SOA 极其强调松散耦合的设计方法，其中具有不同计算平台的异构系统可以协作和发展，而不需要对核心体系结构作出重大更改。服务被设计为自包含的模块，可按需要进行广告、发现、组合和协商。
软件产品线（Software product line，SPL）是软件系统的系列，它们共享公共功能，但是每个成员具有可变的功能。SPL 的主要目标是通过利用所有开发生命周期阶段中的可重用资产，从而实现敏捷和高速的成员系统开发。此目标类似于 SOA 的目标。
尽管存在与 SOA 相关的广泛学术和行业活动，但是不存在用于分析与设计面向服务的应用程序的端到端系统方法。另一方面，SPL 是一个具有相当多方法论支持的既定领域。当我开始使用 SPL 时，组合 SOA 和 SPL 将是构建不断发展的复杂系统的强大方法这一事实就变得非常清楚了。然而，只有诸如 CBDI Service Oriented Architecture Practice Portal（请参见参考资料）等少数组织提到了 SOA 和 SPL 之间的相似性。某种组合方法可以帮助将面向服务的计算提升为主流。
本文探索面向服务的 SPL 方法中所需的跨越所有开发生命周期阶段的活动——面向服务的软件产品线（Service-Oriented Software Product Line，SoSPL）方法。此类方法可以通过整合 SPL 原理来提升 SOA 的技术发展水平。
本文简要介绍一种用于面向服务的单一（非系列）系统的方法，然后介绍一种将该方法扩展到 SPL 的 SoSPL 方法。
针对单一系统的面向服务的分析与设计
SoSPL 方法的核心是面向服务的分析与设计（Service Oriented Analysis and Design，SOAD）活动。SOAD 是一个新兴领域，它涉及到基于业务需求来确定和构建服务。SOAD 将服务视为第一级实体，非常类似于处理类和对象的面向对象的分析与设计（Object Oriented Analysis and Design，OOAD）。
OOAD 中的典型起点是用例模型，但 SOAD 中的起点是业务流程建模。
需求活动
业务流程建模（Business process modeling，BPM）通常用于说明服务需求。业务流程 是一组执行用于实现某个目标的相关业务任务。其重点集中于业务流程而不是用例。其中没有对任何参与者建模，并且重点在于从业务角度看到的业务流程行为。
可以使用统一建模语言（Unified Modeling Language，UML）活动关系图对业务流程建模。活动关系图对于在域业务建模期间详细描绘业务流程工作流特别有用。图 1 显示了一个酒店预订流程。该关系图中的每个活动都表示一个包含子活动的高级活动。
图 1. 酒店预订流程的 UML 活动关系图
可查看此图像的放大版本。
此阶段的产物是一组 BPM 模型，这些模型以描述业务流程行为的 UML 活动关系图表示。
分析活动
候选服务是基于需求模型来确定的。确定可重用服务是一个主要目标，因为可重用性是面向服务的最重要好处之一。一个业务流程模型可以由单个服务或由多个服务来实现。
您可以分析业务流程模型以确定可重用的自主操作。其目标是指定满足所需业务流程的最基本操作，以便您能够逻辑地将它们分组到候选服务中。您必须决定是在单个服务中集合所有操作，还是将相关操作分组到不同的服务中。
候选服务将基于它们在目标应用程序中扮演的角色进行归类。可以开发一个 UML 元类模型来描述分类，例如在 developerWorks 文章“UML 2.0 Profile for Software Services”（请参见参考资料）中介绍的模型。除了该文描述的构造型，您还可以确定表 1 列出的构造型。
表 1. 服务构造条件
| 构造型 | 角色 |
|---|
abstract service
| 非具体；未绑定到实际的服务实现 |
application service
| 具体 |
standalone service
| 不允许成为某个组合的一部分 |
composable service
| 允许成为某个组合的一部分 |
composite service
| 由两个或更多个服务构成 |
entity centric service
| 数据密集型 |
task centric service
| 业务逻辑 |
controller service
| 控制和协调其他服务 |
monitor service
| 监视其他服务 |
分析阶段的产物是一个元类模型，此模型描述候选服务、候选服务的角色构造型及其操作。
设计活动
在此阶段，您将设计在分析阶段确定的候选服务。
服务接口 是对该服务提供的操作的描述。它详细描述操作、输入/输出参数和消息类型。您还可以指定候选服务所需要的其他服务。服务接口设计要求您同时指定所提供的和所需要的接口。（要了解有关基于 Web 服务的详细操作和消息设计步骤的更多信息，请参阅图书 Service-Oriented Architecture Concepts, Technology, and Design；请参见参考资料。）
您可以对分析阶段产生的编排模型进行分析，以确定哪些服务需要从头构建，以及可以使用哪些现有的服务。此外，您应该检查遗留系统，以确定是否其部分功能可作为服务公开并包括在组合中。
验证组合可以确保参与组合的服务的兼容性。您可以使用“Automatic Composition of E-Services that Export Their Behavior”（请参见参考资料部分）中描述的正式或非正式验证技术之一。
此阶段的产物是一个多视图模型，其中显示所有的参与服务、各服务必需和提供的接口以及它们的调用顺序。
用于软件产品线的 SOAD
要构建 SoSPL，您必须扩展针对单一系统所描述的活动，以下各部分将对此进行说明。
需求活动
必须用共性和可变性分析对需求活动进行扩充。您需要从业务流程模型转变到功能模型。SPL 需求共性和可变性分析阶段广泛使用功能模型来对 SPL 成员应用程序的所有可能配置建模。相关功能被分组到各个功能组中。产品线成员从功能组中选择它们所需的功能。
通过自定义，可以将服务用在多个系统中。基本的通用服务可由具有不同功能的多个系统调用。要在软件产品线中使用服务，需要在考虑可变性的情况下对服务进行分析。
通过在 UML 活动关系图中引入可变点，您可以对需求可变性建模。为此，可以使用分支和监护结构，以及指示可变位置（可变点）和要在那些可变点处插入的不同行为的 UML 构造型。
图 2 显示了酒店预订活动关系图中的一些可变点。可变点对约定、居住和会议预定进行区分。
图 2. 酒店预订流程的 UML 活动关系图中的变化
可查看此图像的放大版本。
按照图书 Designing Software Product Lines with UML（请参见参考资料部分）中介绍的分类，您需要确定公共、可选和替代功能。公共功能是产品线的所有成员中都存在的需求。可选功能是产品线的部分成员中存在的需求，替代功能是产品线的部分成员从中进行选择的需求。
您可以基于业务流程活动关系图中的可变点确定功能。每个可变点可以映射到单个功能，或者多个可变点可以映射到一个功能。此外，整个业务流程可以映射到一个功能，或者一个功能可以包含多个业务流程。
最后，您将为整个产品线开发一个功能模型（以 UML 元类关系图表示），如图 3 所示。
图 3. 酒店预订流程的 UML 元类功能模型
可查看此图像的放大版本。
分析活动
首先，你要使用针对单一系统的分析部分中描述的方法，确定产品线的所有成员共有的候选服务。然后，通过使用前面讨论的针对单一系统的相同技术，考虑可选和替代的服务。
下一步，您要分析业务流程模型中已确定的可变点。您必须确定是要作为单个服务的一部分还是作为多个服务的一部分对这些可变点建模。如果可变点非常小，可通过对服务的操作和参数应用可变点来对单个候选服务建模。但是，如果可变点在业务流程模型中普遍存在，则更加可管理的方法是将相关功能逻辑地分组到单独的服务中。
当您在一个服务中对所有可变点分组时，可以考虑某种参数化的服务方法。参数化可应用于服务的操作、参数和消息。（有关 Web 服务参数化的示例，请参见参考资料部分）。
当您将相关功能分组到单独的服务中时，通过基于服务所提供的功能来发现和绑定到不同的服务，从而可以实现可变性。功能建模可以为您提供软件产品线成员的服务组合性质的早期指示。服务需要按特定的顺序组合才能交付所需的功能。因此，可变性会影响各个参与服务以及它们在组合中的执行顺序。
您可以开发一个功能/服务依赖关系模型，该模型与图书 Designing Software Product Lines with UML（请参见参考资料）中描述的功能/类依赖关系模型类似。在该模型中，必须将服务构造型化，以指示它们是已经可用（静态选择）还是需要被发现（动态选择），此外还指示它们的角色和可重用性构造型。
设计活动
首先，你要使用针对单一系统的设计部分中描述的方法，设计产品线的所有成员共有的服务。然后，通过使用针对单一系统的相同技术，考虑可选和替代的服务。
下一步，您需要设计在功能分析期间确定的可变点。可变点可通过参数化的服务或通过多个参与组合的服务来实现。
可以对服务的若干方面应用参数化以实现可变性：
- 操作和参数可变性——您可以在接口定义级别参数化操作和参数。可以使用 Web 服务定义语言（Web Service Definition Language，WSDL）文档实现可变性。可以将 WSDL 文档中的每个元素视为候选可变点。添加元素和重新对操作排序不会破坏 WSDL 中的向后兼容性。因此，您可以基于产品线功能来设计服务，而不必引入单独的 WSDL 文档。
- 传输可变性——可以在服务的传输协议方面实现可变点。例如，一个 SPL 成员可以选择 SOAP 作为传输协议，而另一个成员可以选择 FTP。这种传输选择可以在 WSDL 文档中参数化。
- 端点可变性——可以在服务的位置选择方面实现可变点。例如，有些产品线成员可能指定多个统一资源标识符（Uniform Resource Identifier，URI），而其他成员可能仅指定一个位置。您可能需要多个端点以实现容错或数据复制。端点指定也可以在 WSDL 中参数化。
- 可发现性和绑定可变性——可以在产品线成员的发现和绑定方式方面实现可变点。您将通过公开某些特征在公共注册中心对服务进行广告。SPL 成员可以参数化这些广告的特征，以控制客户机发现和绑定到服务的方式。可以将统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）技术用于此目的。
- 错误处理可变性——可以在产品线成员处理其错误的方式方面实现可变点。基于决定在某些情况下采取什么操作的功能条件，可以对错误处理进行参数化。例如，有些产品线成员可能记录错误消息，而其他成员可能尝试执行预定的纠正操作。
可以使用多种设计模式（例如 Strategy 和 Decorator）来实现服务中已确定的可变点。Strategy 模式可用于实现操作的可变性，Decorator 模式可用于实现参数的可变性。
当您将相关功能分组到若干服务中时，可以通过使用 Web 服务的业务流程执行语言（Business Process Execution Language for Web Service，BPEL4WS）构建基于功能的服务，从而实现变化。BPEL4WS 是一种基于 XML 的流程组合语言，用于定义若干称为合作伙伴的服务的组合，以实现特定的业务需求。使用 BPEL4WS 的条件和调用结构，您可以动态或静态地选择基于功能的服务。在动态选择中，流程包含诸如 UDDI 等发现机制。可以利用 UDDI 的编程接口来搜索为产品线成员提供所需功能的特定服务。
分析部分中确定的功能组名称可以映射到 BPEL4WS 中的条件。通过使用 switch 和 invoke 构造，您可以基于服务的功能组名称来选择服务。然后，当基于其功能组名称选择了某个特定服务时，通过再次使用 switch 和 invoke 构造来选择服务中的各个功能，您可以实现更细粒度的功能选择。
可以使用诸如 Composite、Iterator 和 Chain of Responsibility 等设计模式实现服务之间的组合变化。Composite 模式可用于实现包含其他子服务的组合服务，而 Iterator 模式可用于实现子服务的遍历。此外，可以使用 Broker 体系结构模式来设计此类组合的体系结构。
总结
在本文中，您了解了一种基于软件生产线原理来设计面向服务的应用程序的方法。您可以将 SPL 可变性分析技术应用于 Web 服务，以设计基于服务的自定义应用程序。采用 SPL 原理可通过提供一种创建面向服务的自定义应用程序的系统方法来帮助设计人员。
参考资料 学习
获得产品和技术
讨论
关于作者  | | | Mohammad Abu-Matar 是一位高级软件工程师，在研究、体系结构、系统工程、软件设计和开发方面拥有超过 13 年的技术经验。他拥有电气工程学士学位和信息技术（对象技术）硕士学位，同时还是一名信息技术（软件工程）博士生。Mohammad 为 LexisNexis 工作，后者是一家面向法律、商业和政府部门的主要研究和数据提供商。 |
对本文的评价
| 
