概念:服务组合
此概念描述启用组织时服务的优点,以通过从服务组合编写应用程序来鼓励复用。另外还讨论了有效存储、从存储库发现和检索服务的服务分类。
关系
主要描述

简介

面向服务的体系结构被宣传的优点之一就是能远离 IT 中的“纵向结构”想法,将应用程序作为功能的岛屿来开发。我们现在往往认为应用程序是为这个目的而构建的一组组件的垂直集成。通常情况是开发项目是围绕应用程序的开发或维护而设立,在某些极端情况下,开发团队只负责一个应用程序。下图表示一个普通的业务应用程序结构,显示了其实应用程序之间的唯一复用经常是它们共享一个公共的数据库。

通过文本内容对图进行描述。

鉴于面向服务的方法会使我们看到应用程序作为服务的集成这个更水平的视图;所以事实上我们所有的服务都是功能组合中的同位体,从中可以开发应用程序(现在可以被视为 IT 解决方案中与用户交互的那些部分)。以下内容说明了如何才能将订单应用程序作为一组面向用户的 portlet 开发以集成到门户网站服务器中,以及业务逻辑是由一组服务提供的,这些服务反过来使用一组基础结构服务。

通过文本内容对图进行描述。

服务提供了独立部署的组件,这些组件以通常允许它们完全自包含的详细程度提供,这导致服务管理和保护其自己的数据存储,而不是共享数据库存储器。这看起来与一些公司多年来引入公共数据存储器或至少所有应用程序共享公共数据模型的做法相违背。恰恰相反,面向服务的体系结构往往将设计人员带入开发公共的消息模型而非公共的数据存储器,以简化通过中间件技术集成服务。

企业视图 

正如我们前面所提到的,对于 IT 服务更广泛的功能、需求和目标,更重要的是对于服务所支持的业务,项目和开发团队都有有限的范围和有限的可视性。 因此,关键是在转向“面向服务的解决方案”和集成解决方案的水平视图的过程中,IT 方面的架构设计师能够设想到用于支持业务本身运作所需业务解决方案的服务组合。对服务建模的一个优点是抽象的模型能省略某些详细信息,因此以可伸缩的方式呈现服务组合的宽阔视图,例如,在存在许多服务的情况下,模型能呈现支持为软件设计人员设计器所作决定的组合视图。

显然,随着组织转换为面向服务的体系结构,服务将会增加,因此服务组合不会从大模型开始,但可以根据可用和规划的服务来捕获转换的状态。开发服务组合时,服务分区在组织模型和对服务分类方面也是至关重要的。

服务分类

在服务确定的早期阶段(请参阅活动:现有资产分析),通常只是将候选服务捕获为名称列表,可能构造为分层列表或存储在电子表格中。在研讨会环境中工作以及从源资料中引出候选服务时,这类列表十分有用。随着候选服务数量的增加,非结构化的列表很快会变得无法控制。因此,应尽快确定服务分类方案,以便在类别层次结构中将候选服务组织成组。

虽然服务名称的简单列表可以作为快捷的起点,但最终还要捕获每个服务的其他信息,这一点很重要。可将这些信息细分为两类:支持服务确定的信息和支持服务规范的信息。服务确定重点在于构建可与业务功能、业务目标以及诸如现有系统的资产相关联的服务组合,并指示是将服务考虑为候选服务,还是已选择进行显现。服务组合模板可按服务组合中所需的详细级别来记录服务。

能用多种方法对服务组合中的服务分类是很重要的,但通常我们使用描述服务的用途、所有权或组织的术语。为了支持这种分类,每个服务分区都有一个分类属性,可用于表示分类类型,分区的名称成为该分类方案中的一个值。

例如,很多公司已开发下图(或某种变体)来帮助设想该组合中的服务“类型”。请注意,此分类虽然常见,但只是对服务组合进行划分的一种可能方法。在此示例中,每个分区都以其设定为“区域”的分类属性命名。

通过文本内容对图进行描述。

  • 用户交互服务用于描述用户如何与应用程序进行交互;例如,对于可能需要将工作分配给人类用户的服务,必须存在一些服务,它们知道如何向用户通知该工作以及随后向发起服务通知工作完成。
  • 特定于应用程序的服务是作为开发活动的一部分而开发的服务,它们被认为不适合复用,因此不被视为服务组合的一部分。也可能因为服务是可编写的实体,所以服务可以成为服务组合的一部分,但不会发布它所使用的嵌套服务。
  • 流程集成服务是通常由商业中间件提供的服务,提供服务的编排以便可以在中间件中制定流程并使用服务组合中的服务来实施流程。
  • 信息集成服务也是商业中间件服务,为调解服务之间的数据格式和消息内容提供服务;例如,该服务可生成一条客户消息,该消息聚集从服务组合中的其他服务检索到的数据。
  • 业务服务是特定于业务的那些服务,为业务而开发,并对为支持业务而开发的应用程序提供直接支持。示例有客户管理、库存、人力资源等。
  • 基础结构服务是提供不仅业务服务需要而且集成服务也需要的公用 IT 功能的服务。示例有消息传递、目录、认证、旧访问等。

关于分类类型的更多示例,请参阅概念服务分区。

服务存储库

所以,除了服务组合的模型,重要的是设计人员和开发人员在设计和实施时都能以详细的方式访问服务规范。多个服务也可以实施相同的规范,这样,允许查询表单“实施顺序指定的所有服务”的注册表就允许开发人员从现有服务编写解决方案,允许集成开发人员确定要使用哪些服务来满足业务或技术需求。

服务存储库也能使用以上的服务分区引入的分类值,将这些值预填充为描述存储库所挂起服务的元数据。

例如,解决方案可以调用装运服务,注册表可以确定 3 种服务,一种服务提供装运,其他两种服务提供安全消息交换,但其中一种服务只对 Java 消息服务(JMS)执行此操作,而另一种服务则提供 SOAP over HTTP。业务需求仅指定保持客户信息私有,因此需要安全的消息交换,IT 标准建议 JMS 不用于远程服务,因此我们缩小了选择范围。

以下内容显示了当前可用于服务注册表的一些技术实施。

  • UDDI;Web service 标准注册表,这被广泛采纳并旨在支持开发和集成时间查询。但是,跟踪与服务规范关联的所有数据所需的定制级别当然引发了一些关于当今的 UDDI 是否足以支持我们在此讨论的企业服务组合的问题。
  • RAS 存储库;可重用资产规范旨在支持可重用资产的可定制元数据描述,的确有用于 Web service 的元数据概要文件。虽然 RAS 并非旨在提供服务组合,但为了开发时间元数据可以执行此操作,尽管当前不适合集成时间查询。
  • 定制;面临这些选择的许多组织都选择了实施定制服务存储库,在设计时管理一组元数据或服务的设计文档以及实施时相关联的 Web service 工件。在大多数情况下,为集成时间查询部署产品服务时,将使用单独的 UDDI 存储库。