任务:服务规范
此任务根据包含的设计元素和外部子系统/接口的协作来定义和指定面向服务的解决方案的服务和结构。
规程:分析和设计
用途
  • 根据包含的设计元素和外部子系统/接口的协作,定义面向服务的解决方案的服务和结构。
  • 要分析服务的共同点和可变性(请参阅指南:可变性分析)。
  • 记录服务规范。
  • 确定服务间的依赖关系和通信。
关系
主要描述
本任务优化了在活动:确定服务过程中确定并取得资格的一组工件:服务规范,并提供了其他结构和详细信息。此设计级别的详细信息包括接口、消息、服务组合以及供应商的服务分配。
步骤
复用企业服务组合

一个经常提到的使用面向服务的体系结构(SOA)的好处是使服务能够代表企业中可复用的资产,而不是开发仅限于单一应用程序范围的组件。此企业视图很重要,这是因为它体现了真正面向服务的 IT 体系结构将所有的基础结构和业务功能作为服务来提供,并且由企业开发的应用程序能够复用服务组合中的功能这一概念。

因此,在开始一个项目时,了解是否要将服务开发为服务组合的一部分,或是否要开发使用这些服务的应用程序功能是很重要的。 例如,开发供客户访问其帐户信息的门户网站站点就是一个使用客户信息、帐户信息、商品以及其他信息所构成服务组合中的服务进行应用程序开发的项目。 在各种情况下,使用服务组合具有不同的含义;服务设计人员需要描述它们的服务规范并将该规范作为服务组合的一部分进行发布。 此规范使应用程序开发者能够了解服务的交互需求。 通过确保服务的实施遵守服务规范,服务实施者现在可以使用同一服务规范来开发服务的一个或多个实施。 下图展示了企业范围的服务组合与项目的组合之间的关系。

关于更多信息,请参阅概念服务组合

使用设计模式和机制

使用适合于所设计服务的设计模式和机制并依照项目设计指南。 合并模式或机制能有效地执行此任务中的许多后续步骤,但是要符合模式或机制定义的规则。

请注意,模式和机制一般随着设计的演进而合并,而不只是作为此任务中的第一步。 此外,它们经常应用于一组模型元素,而并非仅应用于单个元素。

将服务转变为其实现通常涉及到一组模式,有些模式在指南:服务组件模式中有描述。

描述解决方案的逻辑组织

它经常用于将您的想法根据不同的视图组织为一个系统,以及您所开发的服务如何与这些视图相配。 在定义逻辑组织视图时,将服务分配到视图中并不表示统一建模语言(UML)概念或范畴中的所有权,也就是说,相同的服务应当能够参与多个逻辑视图。 在开发服务(或至少在这些视图的第一个迭代)之前,在模型中对组织视图进行布局是很有必要的,这样将使服务能够分配到指定的视图中。 在服务模型中,我们使用模型元素服务分区来代表视图的某个方面。这些分区可用于代表解决方案中任意数目的不同方面,但不表示分配给它们的服务的所有权。 关于更多信息,请参阅概念解决方案分区

此外,通过允许分区模型单独演进,这些分区(至少是那些代表关键视点的分区)可以独立于服务本身而存在于模型中。

描述服务元素

在考虑建模软件系统时,此类模型总有许多入口点,有许多可使用的表示法,并且当然有许多方法可以使用,这些情况很普遍。 在大多数情况下,这些入口点是由于必须解决的技术或业务领域方面的特定问题而产生的。 这些问题非常重要,足以充当起点,因为了解它们以及它们之间的交互对于实现成功是至关重要的。

我们曾经观察到在开发面向服务的解决方案时有少数此类问题;下图将这几大问题表示为特定的设计任务。 虽然这些问题中的每一个都可以充当服务设计的起点,并且针对某个特定的服务类对每种方法进行了很好的优化,但很有可能大型项目在确定和设计服务时会结合使用多种方法。

文本内容中所述的图。

关于更多信息,请参阅活动:现有资产分析,其中展示了一组支持这些方法的详细技术。

消息设计

在此方法中,重点就集中在服务领域。通过诸如领域工程或面向对象的分析和设计等技术,能够很深入地了解抽象领域模型的开发。 此方法的重点一般就是为消息模式产生可复用性高的模型。 服务设计通常是辅助活动,虽然它有时候是并行执行的。 例如,在电子数据交换(EDI)中,不存在任何真正的服务接口概念,这是因为 EDI 系统通常具有一个单独的消息全局收件箱和发件箱。

传统的“商家到商家”场合(通过 EDI 标准化表示)就是此类方法的一个示例。 在此情况下,设计活动的重点是开发特定行业或其他范围中达成一致,并且被视作具有代表性的消息类模式的消息模式,例如 ACORD、SWIFT 和 RosettaNet 等行业标准(请参阅任务:消息设计)。

服务设计

在此方法中,设计人员关心的是将业务或应用程序期望的功能显现为一个或一组服务。 在此情况下,我们不必了解哪些服务客户机选择处理我们的服务,但我们了解这些客户机期望的交互种类。 因此,消息应当是次要的,它们是为响应操作的需求而开发的。

诸如 AmazoneBay 等公司提供的 Web Service API 就是此方法的示例。此类服务接口不在客户机上放置业务流程。在大多数情况下,它们甚至不在客户机上施加所需的接口,但是它们以一种明确且直观的方法向第三方开发人员显现相应的服务供应商的操作。

如上所述,通过了解参与者的需要、服务的外部客户机以及提供支持这些需要的操作(例如浏览目录)、向购物车添加商品、检出等,以服务为中心的建模通常很适合于用例驱动的方法。

协作设计

在协作设计中,重点在于两个或更多服务的协作;这就是一个由服务组成的流程视图,与软件开发活动相比,它与更传统的业务建模相关。 在此方法中,服务被视为协作中的履行角色,因此服务规范是为跨一个或多个协作的角色定义的一组职责。

那些参与开发 RosettaNet Partner Interchange Processes(PIPs)或 OAGIS 标准的人员认可此类方法,虽然在这些情况下并未充分进行协作。 在与业务流程设计有关的事务或业务集成活动中(其中 IT 系统的组件显现为服务),此类方法很常见。

在此情况下,通常可从协作直接派生服务规范,但是此方法似乎不太注重消息内容,这导致需要一种混合方法才能顾及完整性。

策略确定和捕获

策略是一个含义广泛的术语,此处表示可视为非功能需求的语句或约束。 从此模型的角度,必须认识到我们不希望模型中含有关于技术信息的详细语句,而是根据这些需求更实际地捕获系统的用途。 例如,我们可能知道某个消息必须保密传输,因为其中包含了客户的个人详细信息;我们希望捕获的是该消息应当保密的意图,而不是捕获需要使用 AES 128 位加密法对规范的 XML 数据集进行数据加密,同时使用 X.509 证书进行公用密钥加密这一意图,这主要是因为基本上不会有人知道其含义,更不用说能够以此抽象级别在模型中指定它(请参阅任务:确定安全性模式)。

下图展示了策略与服务模型元素的关联。请注意,虽然下面所确定的规范组件是我们感兴趣的主要领域,但策略信息也可以与除此之外的其他信息相关联。

文本内容中所述的图。

关于对安全策略建模的更多信息,请参阅白皮书《面向服务的体系结构中的建模安全问题》。

模型服务依赖关系

在规范过程中必须开发的工件:服务模型的另一个重要方面是捕获服务之间的依赖关系。 作为服务模型的一部分,自然会捕获很多依赖关系。 这些依赖关系可能与服务和其规范之间的关系一样明显,也可能更复杂,例如两个独立服务之间的逻辑关系,这是因为它们实施同一规范。 这些依赖关系(在工件:服务模型报告:服务依赖关系中有描述)对于了解将服务部署为自治单元的能力非常重要,当依赖关系变为对服务更改能力的约束时,还会随着时间影响其演进。

服务依赖关系描述了在较大的环境中产生的服务之间的关系,是关于如何使用这些服务的问题。如果服务是从其他服务的组合形成的,此组合服务取决于所组合的各个服务。在业务流程环境中使用服务时,存在一个与流程相关的依赖关系,它是根据业务流程中的步骤(这些步骤指示了服务的使用顺序)产生的。

  • 根据多个服务的组合产生的功能依赖关系/组合依赖关系
    • 示例:“预订车辆”取决于其功能的“检查速率”和“进行预订”。
  • 临时依赖关系,其中有一些前置或后置条件或处理需求必须在组合或编排中说明。
    • 前置条件依赖关系 - 即其他服务调用必须成功执行后当前调用才能开始执行。
    • 处理依赖关系 - 即另一个服务调用必须成功地完成对当前服务的执行。
    • 后置条件依赖关系 - 当服务在执行后需要进行其他服务调用时将出现此情况。

这些依赖关系通常属于服务客户机在选择对服务进行复用时必须执行的决策过程,尤其是在有多个实施可供选择的情况下。

下面列出了服务模型中的重要的依赖关系/关联种类。

  • 服务与实施它的服务供应商之间的关系。
  • 服务与它实施的服务规范之间的关系。
  • 服务与它需要的任何服务规范之间的关系。
  • 服务与将该服务和其他服务相连接的任何服务通道之间的关系,以及连接后与通道另一端的服务之间的关系。
  • 服务与它所在的任何服务分区之间的关系。

因此,确保所有服务规范的完整性很重要,这不仅包括服务规范提供的操作和消息,还包括诸如回调操作所需的接口等所有的依赖关系。 报告服务依赖关系概述了服务模型的重要依赖关系。

模型服务组合和工作流

服务通常由其他现有的服务组成,在某些情况下,通过诸如编排等技术可在没有显式代码的情况下开发服务(仅为现有服务的组合)。 在规范过程中,对于复用企业服务组合中已有元素的服务并且已记录依赖关系的服务,如果它们的功能依赖于组合后服务的功能且可以在不访问组合服务的情况下部署该合成服务,则可将这些服务视为组合服务。

在一些 SOA 框架中,业务流程层仅用于管理已编排的和组合服务,其中复杂的流程是以更精细服务的受管编排形式提供的。 在此示例中,Web service 的业务流程执行语言(BPEL4WS)可用作开发组合服务、服务流和业务流程层的工具。

因此,可确定两种组合服务:

  • 硬连接组合服务 - 此类组合服务的特征是灵活性低,这是由于服务的流和控制是预定义的,其中工作流和控制未外部化。 此类服务具有有吸引力的服务质量属性,例如性能。
  • 宽松连接组合服务 - 此类组合服务的特征是灵活性高,其中将服务并入业务流程是通过将工作流和控制外部化来实现的。组合的工作流描述已外部化。 此类组合用于开发建模工具、通过规则动态变化和通过建模静态变化。使用 BPEL 的组合是一个例子。

关于更多信息,请参阅概念:服务组合和编排以及指南:服务实现 - SOA 应用程序中的 BPEL 服务以获取特定于项目的示例。

记录非功能需求

利用面向服务的体系结构可提供机会选择工件:服务供应商,不仅根据它提供的功能,而且还根据它可以保证的服务质量(QoS)。 更改服务供应商的原因之一通常可能是非功能需求发生更改,因此必须达到现有供应商不支持的新级别的 QoS。 还可能是由于服务使用者预期的 QoS 降低导致。 通常而言,与其他体系结构风格相比,面向服务的体系结构允许较低成本的灵活性。

可以从两个方面查看 QoS:使用者和供应者。服务供应者保证提供并维护其每个服务或服务组的服务质量。 另一方面,服务使用者综合比较以获取所需的 QoS,并根据此 QoS 选择供应商。 需要重点注意的是在商业环境中,当使用者和供应商在服务的使用方面签订了法律合同,即会在服务级别协议中将这些服务质量保证具体化,如果供应商未能满足此协议,则通常会受到惩罚。

因此,为某个服务或一组服务清楚地指定使用者所需的非功能需求(例如事务成本、性能、可用性和安全性等)非常重要。 在此服务规范任务中,我们将为期望的 QoS 确定非功能需求。 非功能需求将用于为提供服务的服务组件落实资源,还用于为服务组件的实现和维护提供资金,以确保 QoS 的按时交付。 必须制定关键的体系结构决策以确保能够达到承诺的服务质量(基于非功能需求)。

此指南中没有定义如何将非功能需求附加到工件:服务规范中。 也没有为构成此需求的内容设置边界,显然上面已提到了 QoS 和安全性,示例可能包括:

  • 可用性(即平均故障间隔时间)
  • 可操作窗口(是否存在并不希望使用服务的情况?)
  • 响应时间(服务需要多少时间来响应请求)
  • 高峰吞吐量(服务在每个单位时间(如每秒、每分钟或每小时)内可响应多少请求)
记录状态管理需求

虽然认为个别服务没有状态,但是组合经常要求保留组合服务调用过程中的状态信息。 服务的编排者通常负责状态的管理。或者出于性能原因,实施和实现多个相关服务的组件或对服务的操作的组件可能需要保留调用之间的状态。

SOA 环境中的状态管理可分成三大类:

  • 事务状态 - 在与客户机对话时,服务具有开放的事务。
  • 安全性状态 - 在与客户机对话时,安全环境保持为开放状态。
  • 功能状态 - 与客户机对话时,涉及许多相关操作。

关于更多信息,请参阅指南:服务的状态管理

更多信息