服务规范的类型

    一个服务规范需要提供如下信息：

    服务的名称，指示出它是什么或者它做什么。
    被提供和被要求的接口，描述服务的功能性的性能。每一个功能性都包括：
    它的名称，通常是一个动词词组，指示出它做什么
    任何被要求或者可选的服务数据输入和输出
    任何消费者在使用该功能之前所期望具备的前提条件
    任何 消费者 期望的并且是 生产者 必须提供的功能成功使用的后期条件
    即使前提条件已经被满足，但是功能由于某种原因未能被提供时，任何被提出的期望或者错误条件
    任何通讯协议或者规则，它们决定功能什么时候后能够被使用或着按照什么样的顺序被使用。
    消费者期望被提供使用的或者同服务进行交互的任何功能。
    在提供服务时，任何执行都必须满足的需求。
    反映服务想要达到什么样的成功以及如何对其进行评估的约束。
    服务消费者所期望得到的和服务提供者被期望提供的质量，例如花费、可用性、性能、脚印、任务的适宜性、和竞争信息等等。
    使用服务的原则，例如用于维持安全性和完整性或者用于将服务从无能力恢复到成功执行的安全性和事务范围。

    显然，本文不可能涵盖所有这些内容。特别是，我们将不会关注服务或者策略的质量。对于那些内容，将有专门的文章加以详细的说明。进一步地，它们可能明确一个服务特定的提供者，而不是特定服务的接口自身。我们要做的是，关注定义和使用一个服务的最根本的必须条件。

    下面各小节详细描述了每一个在 图2 中被识别的服务规范。其介绍顺序是从一个非常简单的没有协议的服务规范，到一个反映一个简单的请求/响应协议的服务规范，再到一个更加复杂的、涉及到消费者和提供者之间多步协议和交互作用的服务。

    时间进度服务

    图4中显示的 Scheduling 服务规范十分简单。服务提供了两种功能性：一种是对一个生产时间表请求进行响应的能力，一种是创建一个运送时间表的能力。据我们所知，在这种情况下，没有一种使用这些功能性的协议。这两者都能够被消费者以任何顺序被使用。

    图4. 时间进度服务规范
 
    Scheduling 服务规范是在生产包中定义的一个简单的 UML 接口。它提供两种服务操作。每一种操作都具有前提和后期条件，并且它们能够提出例外。服务操作的参数被要求要么为服务数据（消息），要么为简单类型。这就确保了参数不会出现被引用调用或者被值调用的状况，服务数据被放置在哪里（在什么地址空间中），服务消费者或者提供者是否在操作数据的一个副本或者某些持久数据源，等等。所有这些需要确保服务不受其配置地点的限制。服务数据被定义在下面的服务数据模型小节中。