通过服务模拟来简化SOA开发(1)

　通过用例和模拟对象简化 SOA 开发——特别在您的项目涉及多个团队时——并提高 SOA 应用程序质量。借助于可重用服务和需要很少的新代码的应用程序(因为可以依赖这些可重用服务)，面向服务的体系结构 (SOA) 可以大幅度提高应用程序开发的速度。

　　但是 SOA 还可能大大增加应用程序开发的复杂性，因为团队需要同时进行应用程序的不同部分的工作，而且要在最后成功地将各个部分组合起来。

　　SOA 开发问题

　　使用 SOA 开发应用程序可提供更多的应用程序部署选项，但也使得开发工作变得越发困难。这是因为 SOA 将应用程序开发拆分为两个截然不同的部分:

　　SOA 服务提供程序(SOA Service Provider，SOA-SP) ——该层的代码实现服务。它具有服务 API，以对服务进行声明和为客户机提供调用服务的方法。
SOA 服务协调程序(SOA Service Coordinator，SOA-SC)——该层的代码通过一个或多个 SOA-SP 中的服务提供用户功能。它可能具有 UI 或 GUI，以便同传统应用程序一样与 SOA-SC 进行交互。
例如，某个金融应用程序的 SOA 可能如图 1 中所示。

　　

图 1 个人金融应用程序和服务

　　通常由独立的团队分别负责同时开发这两个独立的部分。一个团队负责开发 SOA-SC——对用户而言的应用程序。另一个团队负责开发 SOA-SP，或许存在多个负责此项任务的团队，而每个团队负责开发若干服务。虽然可能已经实现了一些提供程序，但可能仍然需要专门为此应用程序实现其他的提供程序。

　　而这给我们提出了第一个问题:如果某些提供程序尚未实现，协调程序开发团队如何开发其负责的应用程序部分呢?

　　这两个团队——开发服务的团队和开发协调程序的团队——需要使其活动同步。他们必须就服务 API 达成一致;服务 API 可以是简单的 Java™ 接口或 Java Message Service (JMS) 消息格式和队列名称，但必须就此达成一致。但仅就接口达成一致是不够的;服务具有行为，因此团队必须就服务的行为达成一致。服务并不会始终成功地工作，因此团队还必须就错误情况和相应的响应达成一致。

　　在理想的情况下，多个团队可以非常容易地协调工作，最初的决策可以稍后进行修改，而所造成的影响却非常小，并且评估工作非常灵活，此外还会不断地进行改进。在现实世界中，团队之间经常存在协作问题，往往较早地(甚至不成熟地)做出不可更改的决策，而且评估方法是固定的。

　　这样就带来了第二个问题:协调程序和提供程序团队如何较早而可靠地就服务如何工作达成一致?

　　经常通过多个提供程序来实现服务冗余。这样就可以在提供程序之间提供负载平衡和故障转移功能，从而使得协调程序的服务体验更为一致和可靠。冗余可以通过多次部署同一服务实现来实现。不过，当不同的供应商部署了不同的提供程序时，服务几乎肯定具有不同的实现。尽管如此，对于协调程序，所有提供程序的全部实现的工作方式都必须一致，以便协调程序可以采用可交换的方式来调用提供程序。服务的不同实现(特别是来自不同供应商的不同实现)是由不同的团队开发的，而这些团队必须加以协调，以确保开发的是相同的服务。

　　因此，第三个问题就是:多个提供程序团队如何实现相同的服务，以确保他们的实现具有兼容性?

　　以上是使用 SOA 进行开发的主要问题。必须实现尚未开发的服务来开发协调程序，协调程序团队和提供程序团队必须就服务如何工作达成一致，而且，多个提供程序团队也必须就服务如何工作达成一致。如果没有良好的流程，这就会导致一片混乱，如果不对其进行检查，将会导致 SOA 项目失败。

　　SOA 开发流程

　　下面给出用于对协调程序和提供程序团队进行同步的简单流程，以帮助确保可重用服务以及使用这些服务的应用程序能够成功地进行开发:

　　﹡　使用服务用例描述服务。
　　﹡　开发体现服务用例的服务测试。
　　﹡　开发通过服务测试的服务模拟。
　　﹡　提供程序团队采用服务模拟作为原型，并将服务测试作为要求，从而实现服务。
　　﹡　协调程序团队将服务测试作为服务使用者可以进行的工作的示例，并在实际的服务仍然处于开发过程的同时使用服务模拟对其代码进行测试。

　　这个简单的流程处理了以下问题:如何确定服务的范围以及如何保持团队的一致性和高效率，从而避免发生意外。公正地说，还有许多其他问题仍然没有通过此流程得到解决。该流程并没有涉及服务自身如何开发或协调应用程序如何开发的问题。它并不涉及服务的质量问题(即服务的可靠性问题)，而是只定义服务如何提供必要的行为。该流程总体上也不处理传统独立应用程序如何使用 SOA 重新进行体系结构设计，以及如何发现或设计服务。所有这些问题都是必要的，但其并不在此流程的范围之内。

　　此流程使协调应用程序和服务实现协同工作，并允许团队以相当独立的方式同时对这两个部分进行开发。这并非 SOA 项目所需的全部内容，但却是一个不错的起点。

　　为了说明此流程，我将讨论如何实现一个简单服务。它就是大家都喜欢用的服务示例，即股票报价服务。为了让内容更丰富一些，我提供了以下三种类型的信息:

　　﹡　简单的当前价格报价
　　﹡　包含当前价格、当日最高价和最低价以及当天交易量的复杂报价
　　﹡　包含过去某天的复杂报价的历史报价

　　此示例应该足以阐释该流程的工作过程。

　　服务用例

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

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

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

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

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

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

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

　　示例用例

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

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

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

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

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

　　﹡　如果股票代码无效，或者提供程序所属的交易所不支持该股票，该如何处理?
　　﹡　应该为价格使用何种格式?浮点数可能存在舍入误差。小数更为准确，但不标准。字符串效率较低，但更为明确。
　　﹡　应该为复杂报价使用何种格式?逗号分隔值?数组?对象?XML 文档?SOAP 响应?
　　﹡　如果所请求的日期是当日或将来的时间，该如何处理?如果日期是过去的某个市场不开放的日期，该如何处理?对于交易所尚未开始进行股票交易的日期该如何处理?如果日期过早，而不存在相关记录了，该如何处理?如果股票代码或交易从那以后发生了变化，又该如何处理?

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