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

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

\

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

\

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

\

……根据面向对象的方式，我们有一个保险单的对象，它可以支持一些操作，包括如下伪代码中的批准保险单操作：\

myPolicy = new Policy (); ... successOrFailure = myPolicy.approve ();

\

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

\

请求创建保险单，指定创建操作--\u0026gt;保险单服务--\u0026gt;响应返回保险单号码12345

\请求批准保险单12345，指定批准操作--\u0026gt;保险单服--\u0026gt;响应返回成功或失败

\

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

\

……另外一种实现相同功能的方式是使用如下的任务服务(Task Services)，在这里服务代表动词而不是名词：\

请求创建保险单--\u0026gt;创建保险单的服务--\u0026gt;响应返回保险单号码12345

\

请求批准保险单12345--\u0026gt;批准保险单的服务--\u0026gt;响应返回成功或失败

\在这个例子中，两个任务服务(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。