在某些情况下，无法包装某个功能并将其作为服务公开。

　　但是，可以通过更容易集成的形式包装该功能，例如消息队列接口或Java连接器体系结构（Java Connector Architecture，JCA），从而允许新服务就地访问该功能（也称为间接公开）。一般来讲，JCA适配器提供了更加可靠的服务质量，例如由中间件直接管理的安全性、性能、事务、故障转移。IBM SAP JCA适配器就是支持这些服务质量的适配器示例。

　　·将功能集成到服务中

　　在某些情况下，只需将现有的功能用作服务实现中的一个逻辑组件，即可让新服务就地访问该功能。例如，服务实现可以使用面向消息的协议（如Java Message Service）来直接访问应用程序公开的现有功能。

　　在任何可能的场景中，都可以向使用应用程序的其他服务公开OMG PLM服务接口。

                       

　　图7. 将现有PLM应用程序作为服务公开的选项
 
　　服务规范

　　服务规范定义依赖关系、组合、公开决策、消息、服务质量约束以及与服务状态管理相关的决策。服务规范任务的目标是详细描述服务模型。

　　服务规范包括以下子任务：

　　·应用Service Litmus Test以做出公开决策。
　　·确定服务依赖关系。
　　·确定服务组合和流。
　　·确定非功能性需求。
　　·指定服务消息。
　　·编写状态管理决策文档。

　　应用Service Litmus Test以做出公开决策

　　在SOMA方法的此阶段，侯选服务已选定并在（分类的）服务组合中做了文档记录。我们现在需要确定必须将哪些候选服务作为服务公开。

　　虽然从理论上讲，可以通过将其接口作为服务描述导出，从而公开任何侯选服务，但不是每个侯选服务都必须这样。由于可能危害非功能需求，也许这样做在经济上和实践上是不可行的。特别是，公开所有类中的所有方法的糟糕决策将产生浩如烟海并且通常无法管理的服务，从而导致服务增殖综合症(Service Proliferation Syndrome)。这会导致大量性能和服务管理问题，Trucks Inc.的可能智力资本损失就更不用说了。我们必须记住，我们选择公开的每个服务都具有关联的成本：服务的资金支持、治理、底层基础结构（其安全性、性能和管理）以及实现它们的组件都必须考虑在内。

　　因此，需要某些标准来帮助决定是否公开某个服务，并且最重要的是，对于提供服务功能以及服务的维护、监视、安全性、性能和其他服务级别协议的服务组件，帮助决定是否要资助该服务组件的创建。例如，Trucks Inc.可能不希望公开某个触发CPU和磁盘空间使用模拟的服务。

　　此决策制定过程称为服务公开决策(Service Exposure Decision)。

　　可以使用一组Service Litmus Test形式的标准来筛选候选服务集合。

　　确定服务依赖关系

　　详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。

　　存在两种需要考虑的依赖关系类型：

　　功能依赖关系

　　功能依赖关系是这样的服务之间的依赖关系，即这些服务彼此依赖以交付所需交付的服务。如图8中，Manage Configuration组合服务具有对Validate parts、build combinations和Develop BOM服务的功能依赖关系。

                       

　　图8. 车辆设计流程中的组合服务（IBM汽车流程分类框架）
 
　　处理依赖关系

　　处理依赖关系是这样的服务之间的依赖关系，即这些服务编排在一起以构成业务流程。例如，设计审查流程依赖如图9所示的服务。

                       

　　图9. 设计审查流程
 
　　确定服务组合和流

　　检查功能区域和业务流程可以帮助详细描述服务及其流的组合。服务流规范描述服务之间的编排。例如，设计审查组合服务是一个长时间运行的可中断流程宏流。捕获反馈和请求返工流程是短时间运行的不可中断流程（微流）。

　　确定非功能性需求

　　服务模型必须考虑用于指定服务质量(QoS)的非功能性需求。在PLM领域，在服务标识和设计中预先考虑非功能需求可能非常重要。

　　例如，物料单同步服务可能引入企业ERP的重要事务处理管理，值得在服务标识阶段进行文档记录。

　　指定服务消息

　　服务模型中的数据流通常以在服务之间流动的消息的形式表示。在确定服务规范的过程中，存在数据模型未完成的情况。要考虑有关将实现的服务的详细信息在此时间点不足够的情况。虽然如此，仍然需要考虑用于服务输入和输出的数据和消息。

　　在某些情况下，OMG PLM Services 2.0模型的多态结构可能允许在设计服务消息时采用增量方法。

　　让我们举一个例子，假设某个服务设计人员知道需要执行某个查询，但是并不完全知道确切的查询类型。该设计人员可以在服务标识的此阶段指定Specific_query或Relationship_query。以后，该设计人员可能更深入地了解了消息规范，并选择Geometric_model_relationship_query（请参见图10）。

                    

　　图10. OMG PLM Services 2.0计算模型中的示例查询类
 
　　编写状态管理决策文档

　　在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。

　　例如，在某些情况下，流程的某些部分的状态管理可能由组合服务或其他元素控制。

　　OMG PLM Services 2.0包含若干面向状态的对象，例如与某个特定工作通知单相关的活动，如图11所示。

                            

　　图11. 活动通常是面向状态的实体
 
　　服务组件规范

　　服务规范任务的最后一部分是组件规范。孤立地执行此任务通常是非常困难的，因此实现任务通常并行地执行并且是迭代的。服务组件规范包括以下子任务：

　　·确定组件属性
　　·确定事件和消息
　　·确定组件内部流
　　·创建组件类关系图
　　·面向变化的设计

　　所有服务组件规范都打包在一个或多个服务组件模型中，从而使这些模型成为主要的设计构件，其中包含在SOMA方法的早期阶段中捕获的大多数服务规范。一般来讲，服务组件规范采用UML组件的形式进行描述。在下面的示例中，我们使用IBM Rational Software Architect来定义UML组件关系图。

　　关于Rational Software Architect：IBM Rational Software Architect是一个集成的设计和开发工具，它使用UML的模型驱动的开发来创建良好架构的应用程序和服务。使用Rational Software Architect，您可以统一软件设计和开发的所有方面：

　　·比以往更高效地开发应用程序
　　·利用最新的建模语言技术
　　·检查和控制Java应用程序的结构
　　·使用开放和可扩展的建模平台
　　·简化您的设计和开发工具解决方案
　　·与该生命周期的其他方面集成

　　图12显示了Trucks Inc.如何组织其各种UML服务组件模型。企业范围的服务组件模型包含在业务单位级别进行维护的其他模型（请注意，这里仅显示了三个业务单位）。

　　UML模型可以将其他UML模型（如行业标准模型）作为OMG PLM Services 2.0和OAGIS 9.1 UML模型加以引用。通过这种方式，负责指定服务组件的SOA架构师就能够在UML工具中重用那些标准的大多数元素。在下面的示例中，我们演示了如何重用OMG PLM Services 2.0 UML模型。

                        

　　图12. Trucks Inc.的UML服务组件模型的组织
 
　　下面让我们介绍一下Trucks Inc.如何使用IBM Rational Software Architect、用于软件服务的UML 2.0概要和OMG PLM Service 2.0 UML模型，在UML中将其企业PDM应用程序作为服务组件进行建模。

　　关于UML概要：UML概要为独立于领域的统一建模语言添加了简单的扩展机制。概要允许定义领域特定的实体和规则。用于软件服务的UML 2.0概要专用于服务组件规范。它使架构师可以定义服务组件模型，然后使用模型驱动的开发技术生成WSDL服务定义。有关UML概要的更多信息，请参见以下网页：

http://www.ibm.com/developerworks/rational/library/05/419_soa/

　　一个基本的体系结构假设在于，企业PDM应用程序将遵循 “现有资产分析”中阐述的间接公开模式来使用JCA适配器（请参见图13）进行集成。

                         

　　图13. 使用间接公开模式通过JCA适配器将Trucks Inc.企业PDM作为服务组件集成在一起                    
 
　　图14显示了在此集成场景中需要考虑的四个主要元素：

　　企业PDM组件

　　此UML组件表示企业PDM应用程序。例如，这可能是现有的应用程序或诸如PTC Windchill、Siemens UGS TeamCenter等COTS PLM应用程序。

　　企业PDM UML组件通过接口实现关系与特定于企业PDM的API UML接口相关联。

　　特定于企业PDM的API

　　此UML接口表示特定于企业PDM的API。此API可作为Web服务公开，或者可以使用诸如RMI/IIOP等协议。为了充分利用诸如安全性处理、事务处理、连接池和集群等JCA适配器功能，应该使用诸如RMI/IIOP等可靠的传输协议。一般来讲，COTS PDM应用程序公开多种API，具体取决于用途：

　　——作为Web服务公开的API

　　SOA客户端（例如门户应用程序）通常使用作为Web服务公开的API。

　　——使用可靠传输协议的API

　　可以在具有高级别QoS要求的多种业务场景中重用的可靠SOA组件利用使用可靠传输协议的API。例如，SAP公开了一个名为Java Connector API(JCO)的API。

　　企业PDM适配器

　　此UML组件表示将企业PDM集成在一起的JCA适配器。此组件被构造型化为服务提供者（此构造型来自于用于软件服务的UML 2.0概要）。拥有服务组件UML建模经验的SOA架构师能立即识别出此组件是服务提供者，并且其一个或多个接口被其他服务组件重用。

　　诸如IBM SAP JCA适配器等商业化JCA适配器附带了称为企业元数据发现（Enterprise Metadata Discovery，EMD）的功能，允许JCA适配器（在开发时）检查PDM应用程序能够公开的各个操作。设计人员通常选择这些操作的某个子集，并让EMD工具生成与这些操作对应的基于服务的接口。

　　一般情况下，适配器公开的服务接口不使用HTTP作为传输协议绑定。相反，所使用的是中间件平台支持的可靠传输协议。例如，IBM WebSphere使用了支持各种服务绑定传输协议的服务组件体系结构，如RMI/IIOP、JMS和HTTP。

　　企业PDM适配器UML组件通过接口实现关系与特定于企业PDM的服务UML接口相关联。它通过使用关系与企业PDM UML组件相关联。

　　特定于企业PDM的服务接口

　　此UML接口包含EMD期间为我们的服务组件选择的操作的子集。此接口被构造型化为服务规范（此构造型也来自于用于软件服务的UML 2.0概要）。使用该适配器的服务组件通常使用此接口。

　　但是在此阶段，我们的适配器仅将选定的特定于应用程序的操作作为服务公开。使用此适配器作为企业组件将会带来许多缺点。使用此适配器公开的服务的任何组件都必须将自己的数据表示形式映射到特定于企业PDM的数据表示形式。

　　下一步是将此适配器的接口映射到与OMG PLM Services 2.0兼容的接口，即Trucks Inc.的与PLM无关的语言。

                        

　　图14.重用特定于企业PDM的API中可用的操作子集的Trucks Inc.企业PDM及其JCA适配器
 
　　让我们以一种简单情况为例，其中只有一个与企业PDM同步集成的需求。在此情况下，OMG PLM Services 2.0 PLM_general_connection接口就是我们的服务组件必须公开的服务接口。

　　在此阶段，需要引入两个主要组件：负责将OMG PLM Services 2.0数据转换为企业PDM数据以及执行相反转换的映射。由于PLM数据结构的复杂性质，这些映射很可能是在开发方面最耗时间的组件。Trucks Inc.的另一个替代选择是购买专用于OMG PLM服务标准的商业化适配器。例如，ProSTEP推出的OpenPDM包含大量与大多数COTS PLM应用程序兼容的适配器。但是，在Trucks Inc.需要指定服务组件来包装现有应用程序的情况下，那些映射的开发将是必需的。

　　图15描述了这两个映射。我们显式地说明了需要哪些接口，以及哪些接口是通过在Rational Software Architect中设置相应的UML外观参数来提供的。PLM_general_connection接口是从OMG PLM Services 2.0 UML模型中重用的。

                            

　　图15. 对OMG PLM Services 2.0数据与企业PDM数据之间的来回转换建模
 
　　图16显示了带有两个映射（出站和入站）的企业PDM服务组件。

　　出站和入站定义：出站是从中间件层到应用程序层的方向。入站是从应用程序层到中间件层的方向。

　　我们显示了UML组件结构隔间，以表明作为内部组件的两个映射属于企业PDM服务组件。请注意那些小手柄，它们以紧凑的方式描述了需要并提供的接口。

　　图17中的UML组件关系图显示了从企业PDM服务组件通过适配器向下到达企业PDM应用程序的概况。Trucks Inc.的SOA架构师可能使用此关系图，以在单个关系图中解释其端到端设计。

　　从现在开始，从SOA集成的角度看，Trucks Inc.的企业PDM应用程序仅由企业PDM服务组件来表示。使用组件的服务不知道基础的集成方法和特定于应用程序的API。此设计具有许多优点。一个主要优点在于，Trucks Inc.可以在对其基于SOA的组件具有最小影响的情况下，将企业PDM应用程序替换为新应用程序。

                         

　　图16. 带有出站和入站映射的企业PDM服务组件

                    
 
　　图17. 从企业PDM服务组件往下到达企业PDM应用程序的概况
 
　　SOA治理

　　Trucks Inc.以高涨的热情和效率开始了服务标识过程，第一个SOA组件成功实现了。SOA现已成为一项公司战略，并在各个Trucks Inc.业务单位启动了多个项目。

　　但是在几个月后，Trucks Inc.遭遇到了某些围绕其SOA实现问题的困扰。他们未能实现其业务敏捷性目标：

　　·他们难于标识新的候选服务并对其进行优化。
　　·他们遇到了服务重用（以及服务重用的缺乏）方面的严重问题。
　　·公司标准的采用充其量也只是偶然的。
　　·准备好第一批服务以后，服务更改和版本的治理非常粗糙并且未经定义。
　　·没有办法在整个SOA运行时环境中一致地执行操作策略。

　　SOA治理项目需求

　　SOA治理有助于正确定义组织结构中的角色和职责。Trucks Inc.计划使用SOA治理场景来帮助他们控制新服务的创建，重用现有的服务，以及遵守标准和最佳实践。

　　本部分描述Trucks Inc.的组织结构，并列出他们的SOA治理需求。                          

　　图18显示了Trucks Inc.的IT组织结构。表2和表3定义了图18所示的组和角色。
　
　　Trucks Inc.组织由CIO领导的IT执行指导委员会（IT Executive Steering Committee，ITESC）率领。ITESC中的领域所有者拥有各自的相应业务领域中的业务功能并对其承担责任。
　
　　这些领域所有者向CIO报告，但他们还在各自的业务领域中具有直接报告职责。ITESC也列出了主要技术角色。这些技术角色与领域所有者一道致力于实现业务与IT之间的融合。

　　该组织模型的下一层显示了业务关系负责人和SOA委员会。业务关系负责人为领域所有者提供有关该特定业务领域优先级的见解。他们还与SOA委员会合作提供有关需要什么业务功能的见解。SOA委员会负责定义和更新SOA活动的战略和方向、体系结构的高级方向，以及在业务关系负责人的指导下正确确定服务组合方向。

　　SOA核心团队从SOA委员会获得指导以帮助实现所需的服务。SOA核心团队的作用如下：

　　·帮助定义整个服务生命周期中的各个流程
　　·帮助定义围绕那些流程的标准和最佳实践
　　·确保正确传达、执行和发展那些流程

　　与CoE组织的其他层一样，核心团队还包括来自业务和IT部门的代表。

                      

　　图18. Trucks Inc.IT组织结构

                
 
　　表2. Trucks Inc.组织中的组

                        
 
　　表3. Trucks Inc.组织中与SOA治理相关的角色