任务:记录服务实现决策
本任务的重点在于根据现有中间件环境内运行的软件组件来实现服务模型。
用途

本任务的目的是为实施提供设计模型,开发人员可使用该模型来实施服务组件,从而提供必需的服务。

关系
主要描述

服务模型的用途主要是确定服务、其组织、协作及其详细和完整的规范。实施的角色被委托给现有的 Rational Unified Process(RUP)设计模型,具体而言是服务组件模型元素。通常,服务模型是由设计模型实现的。但是,也可以从只需要规范的服务模型中直接生成工件。从允许在构造之前进一步描述服务的服务模型中创建用例模型也是很有用的。

步骤
决定来源方法

在决定如何实现服务时,有很多可考虑的备选方法(见下图)。 这不是直接的“构建还是购买”决策,其中还有其他值得注意的选项。 “变换”操作使用多种技术的组合(包括业务规则抽取)为组件服务的实现拉出独立使用的功能片段。“集成”是对实现功能的旧功能进行“包装”;集成基于调用。预订基于“发布 - 预订”模型的可用性(在面向消息的中间件环境中),使用者在此模型中预订服务供应商所提供的服务。其中一个选项是将功能(例如工资发放)外包给其他企业。随着 Web service 和企业到企业的集成日益普遍,也可以考虑更广泛地使用此选项。

  • 构建 - 出于各种原因,此决策将在内部进行和开发服务。
  • 购买 - 采购可在内部部署和管理的服务。
  • 变换 - 使用多种技术的组合(包括业务规则抽取)为组件服务的实现拉出独立使用的功能片段。
  • 预订 - 基于“发布 - 预订”模型的可用性(在面向消息的中间件环境中),使用者在此模型中预订服务供应商所提供的服务。
  • 集成 - 是对实现功能的旧功能进行包装;集成基于调用。
  • 外包 - 随着 Web service 和企业到企业的集成日益普遍,也可以考虑更广泛地使用此选项。

服务实现决策与服务组件关联。每个服务组件可以视为是实现服务所需的功能的容器。 它由功能组件和技术组件组成,或使用这两种组件。 决定如何实现这些服务组件很重要。这并不只是简单地决定“购买还是构建”。 还有很多需要考虑的问题,例如:

  • 变换可能涉及抽取规则或克隆现有代码并对其进行重新编写,以便作为具有已定义接口的组件加以执行。
  • 与消息传递或包装程序集成。

示例

我们希望捕获“租车”示例中的实现决策,虽然在 UML 模型中(在许多示例中一直使用此模型)很难做到这一点。 为了对此过程提供帮助,可使用“实现矩阵”模板来记录这些决策的结果,如下图中所示。

决定开发方法

所描述选项的优点是无论您选择哪个选项,可跟踪性方面,从用例模型到设计模型,然后再到实施之间有一条连接。

文本内容中所述的图。

我们建议使用设计模型来实现服务模型。这使设计人员实施者能够在生成实施工件之前将模式应用于设计模型以及模型的其他功能和结构。

现有资产的精细型映射

我们不能忘记,几乎没有什么解决方案是在不考虑现有应用程序的情况下构建的,这些现有应用程序提供了支持解决方案的功能或解决方案必须与之交互的功能。 所以应当对将作为任何解决方案的一部分加以复用的现有旧应用程序进行编目,并确定它们的功能,这是极其重要的。 通过面向服务的解决方案,我们能够采用许多方法将新的服务与现有的功能进行集成。 下图展示了这些方法:

  • 将现有功能合并为一个服务。在此情况下,我们希望原样保留功能,但使用工具或中间件来将现有的功能展现为一个服务。 例如,IBM 提供了将旧的 CICS 事务展现为 SOAP Web service 的能力。
  • 用一个服务合并和替换现有功能。在此情况下,我们按照前面所述对功能进行合并,但我们使用得到的服务规范在以后重新开发该服务,方法是替换原来的服务并将客户重定向到新的实施。
  • 使用更服从于服务调用的适配器。在某些情况下,无法合并功能并将其显现为一个服务,但是可以将该功能合并到更易于集成的对象中,例如消息队列接口或 Java Connector Architecture(JCA)。这使得新服务能够访问相应的功能。
  • 将功能集成到服务中。很明显,在某些情况下,只需将旧功能用作服务实施内的逻辑组件,新服务就可以访问相应的旧功能。

文本内容中所述的图。

第三和第四种方法提供的灵活性应当是最大的,这是因为这两种方法使用的是现有的功能,但并不继续按原样向客户显现该功能。 而第一和第二种方法在将现有功能合并为服务时可能会引起问题,这是因为 Web service 协议的性能与本机数据格式和 XML 的不匹配可能会引起性能问题。

必须对现有软件资产及其依赖关系和接口进行分析,以便确定是否需要进行更改才能支持业务功能。例如,为了替旧的业务功能实施创建 Web service 接口,分析可能涉及到检测联机事务、批处理作业,或有助于执行此功能的持久数据存储的组合和流程。 可能必须更改现有应用程序的当前设计才能支持此功能。 还需要确定使用所期望的服务质量创建 Web service 接口时可能遇到的任何障碍。  例如,业务功能的整体批处理实施在作为服务调用时可能需要亚秒级的响应时间。   

将现有资产合并为一个服务模式

然而,在某些情况下,可以开发一个旧服务分区,其中有一组低级别的旧功能单独显现为服务。 只有较高级别的服务才能访问此分区,利用它们向服务使用者展示更详细的以业务为准的规范。 对旧功能的此封装应视为一种临时解决方案,只应在充分了解合并技术的性能特性时才采用。 有关更多信息,请参阅概念解决方案分区

从某种角度来看,旧功能合并是服务供应商模型元素的一种简化形式,它通过一个单独的服务实现只具有单一操作的单个规范。 下图展示了旧功能“更新客户地址”的该模式。

 文本内容中所述的图。

在定制此模式时,您可能需要执行以下操作:

  • 一组现有功能可能由同一组件提供,因此应使用相同的服务供应商。
  • 上述模式是自动生成的;最好使用“exec${service}”格式对缺省的操作名称进行重命名。
  • 类似地,对缺省生成的消息进行重命名也是很有意义的;与此同时,应对消息结构进行建模。
  • 缺省的模式假定操作获取一条输入消息并返回一条消息;旧功能可能不返回任何消息,或仅返回一个通知,因此应当对生成的操作签名进行修正。
  • 架构设计师/设计人员应确保为服务供应商上的“allowedBindings”属性指定正确的值。
属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息