服务用例

    此 SOA 开发流程中的第一步是开发描述服务的服务用例。

    Alistair Cockburn 将用例 定义为“系统涉众之间有关系统的行为的协定”(请参阅参考资料部分列出的 Writing Effective Use Cases)。用例必须适合所定义的系统范围，能够代表此情况下使用系统的主要参与者的观点，且能够在一致的抽象层次上表示参与者的系统使用情况。

    Alistair 给出的一个例子是网上的股票购买服务，其中，购买者使用与股票代理的网站协同工作的个人金融应用程序来购买股票。系统范围既包含金融应用程序，又包含代理的网站。购买者是主要的参与者。抽象级别为应用程序和网站之间的交互，而不是应用程序或网站内的详细信息。用例将描述主要成功方案(购买者根据这些方案购买股票)和一些可能出现错误的扩展。

    因此，用例是关于以下内容的文本描述:希望系统如何工作、将涉及到哪些人以及他们之间如何交互、系统在正常运行时如何工作，以及出现错误时应该如何处理。它关心的是系统将做什么，而不考虑将如何 实现。

    现在，假定所讨论的不是系统或应用程序，而是一个 SOA 服务。用例技术仍然适用。可以采用此技术来描述服务使用者与服务提供程序如何进行交互，说明服务做什么 而不用描述其如何 实现。服务用例 的最初草稿应将重点放在服务的行为上。由于这是必须调用的服务，因此后面的用例草稿还应该指定调用协议——将用于调用服务的技术、传输和数据格式。(用例纯粹主义者甚至可能说协议不属于用例的实现细节，他们是对的。但服务用例不仅描述服务，而且还要描述如何调用该服务，因此协议是使用者和提供程序参与者之间的协定的一部分，必须在某个地方加以指定。)

    因此，开发用例的第一步是对服务完成的操作进行充分的描述。此描述代表了使用者对提供程序必须提供的行为的要求，主要由协调程序开发团队创建，但同样以提供程序开发团队提供的输出为基础。这两种类型的开发团队必须对用例满意才行，因为这些用例是对所有团队开发其负责的应用程序部分的要求。

    服务不仅要在条件良好的情况下正常工作，而且还要能够恰当地处理出现错误的情况，这非常重要。因此，您的服务用例应该对错误情况和服务无法成功处理的错误输入加以处理。其中很多错误路径最终都表现为用例的备用路径。其他错误场景也可能非常极端，因而需要各自的错误用例。在这两种方法中，用例都必须记录服务如何像成功路径一样全面地处理错误。

    示例用例

    例如，让我们看看股票报价示例的服务用例。它需要做三件事，因此需要以下三个服务用例:

    1. 简单报价:使用者传入股票代码;提供程序返回指定的股票的当前价格。

    2. 复杂报价:使用者传入股票代码;提供程序返回指定股票的当前价格，当前的最高价格、最低价格以及交易量。

    3. 历史报价:使用者传入股票代码和日期;提供程序返回指定股票和日期的复杂报价。

    即便对于这样的简单示例，仍然需要确定很多问题并将其添加到用例中，如下所示:

    1.如果股票代码无效，或者提供程序所属的交易所不支持该股票，该如何处理?

    2.应该为价格使用何种格式?浮点数可能存在舍入误差。小数更为准确，但不标准。字符串效率较低，但更为明确。

    3.应该为复杂报价使用何种格式?逗号分隔值?数组?对象?XML 文档?SOAP 响应?

    4.如果所请求的日期是当日或将来的时间，该如何处理?如果日期是过去的某个市场不开放的日期，该如何处理?对于交易所尚未开始进行股票交易的日期该如何处理?如果日期过早，而不存在相关记录了，该如何处理?如果股票代码或交易从那以后发生了变化，又该如何处理?

    即使开发本文中的简单用例也不简单。用例非常麻烦，必须考虑周全才能圆满地完成开发工作。此时的细心工作是非常不错的一项投资;利用好的服务用例可以开发良好的服务测试和服务模拟，从而帮助开发团队正常进行开发工作。