SOA 语法——服务 (Services) 是动词还是名词？

Jason Bloomberg 的最新文章——服务 (Services) 是动词还是名词？——讨论了服务 (Services) 是应该表示动词还是名词：

你可以设计服务为实体服务 (Entity Services) 或任务服务（Task Services），前者自然表示业务实体，后者则代表实现过程中的某些专门的步骤的动作，换句话说，就是动词。那哪种方式更好呢？

为了说明“名词”和“动词”类型的服务的差别，Jason 如下使用了一个批准待办保险单的服务例子

……根据面向对象的方式，我们有一个保险单的对象，它可以支持一些操作，包括如下伪代码中的批准保险单操作： myPolicy = new Policy (); … successOrFailure = myPolicy.approve ();

……你当然也可以创建一个和上面代码差不多的带批准操作的实体服务：Policy 服务，但最大的不同点在于服务是无状态的，你不能实例化他们，因此如下代表了实现同样的功能，一个实体服务怎么做：

请求创建保险单，指定创建操作–> 保险单服务–> 响应返回保险单号码 12345

请求批准保险单 12345，指定批准操作–> 保险单服–> 响应返回成功或失败

尽管这是一个典型的面向对象思想的设计服务的方式，Jason 指出：

……另外一种实现相同功能的方式是使用如下的任务服务 (Task Services)，在这里服务代表动词而不是名词： 请求创建保险单–> 创建保险单的服务–> 响应返回保险单号码 12345

请求批准保险单 12345–> 批准保险单的服务–> 响应返回成功或失败

在这个例子中，两个任务服务 (Task Services) 没有任何操作，它们更像是实现了服务中上下文的功能。但是，一个批准服务除了批准保险单还会做什么呢？

Jason 的观点是：

实体和任务服务既能帮助架构师们把以往的功能连接起来，并且也能够灵活的处理需求。实体服务（Entity Services）直接抽象出遗留（legacy）功能，任务服务（Task Services）则把基本实体服务的单个操作抽象出来，过程服务（Process Services）通常是由任务服务组成的。或者说，过程服务是基于服务导向的商业应用（SOBA）的接口，如果这些应用由设计正确的任务服务组成，他们将会展现出其过程的本质。

Jason 在结尾的时候说

事情常常是这样的，架构师们处理时往往有好几个选择，并且对于每个选择是否恰当往往取决于业务本身的问题， 一个典型的例子就是“选择合适的工具” 的理论，如果这个业务问题是过程为中心的，比如为了提高效率或优化订单保险过程，那么用任务服务的组合来实现基于服务导向的商业应用 (SOBAs) 将会带来更大灵活性。如果是信息为中心的业务问题，比如在呼叫中心的推销员的屏幕上显示整理过的客户信息的例子，架构师可能会更关注实体服务（Entity Service）因为推销员往往正在处理某个特定的客户，而且必须要能够和客户灵活地交流。

尽管 Jason（好几次）在文章中希望说明 SOA 和 OO 的不同，本篇更多地证明了面向对象的思想是如何影响我们理解 SOA 理解的。 让我们回到 Wikipedia 上的定义

• 名词：格变化中的一部分，标志着一个具体或抽象的实体。
• 动词：没有格变化，但是会因为时态，人称，数的影响而变化，标志一个活动，执行的过程或经历

根据 Jason 的解释，“服务是固有无状态的” ，他们不能代表一个实体，在他的例子中，一个保险单服务并不是一个实体服务，而是一组支持任何保险单上的操作的方法集合。这类似于J2EE 的无状态会话Bean，几乎不能被叫做名词，因此，最后得出，服务并不是一个名词，它是一个动词或一组动词的集合，Jason 所谓的实体和任务服务的不同在于他们提供的方法个数。

查看英文原文： SOA Grammar – Are Services Verbs or Nouns? - - - - - -

译者介绍：晁晓娟，从事 Web 开发管理多年，留过学，呆过外企，尝试过创业，关注项目管理，架构和产品，热爱天马行空的把所有的传统的非传统的 IDEA 搬到互联网上来。InfoQ 中文站内容团队，尤其是架构、SOA 和 Ruby 社区需要您的参与，有意者请邮件至 editors【AT】cn.infoq.com 。