一些人认为实体服务（Entity Services）或以业务为中心的实体是面向服务架构的基本要素。这一观点并没有得到所有人的认同。那么，实体服务是 SOA 模式，亦或反模式？上个月， Shy Cohen ，在文章“面向服务架构中服务的本体和分类”中定义实体服务如下：
“实体服务揭示并显露出系统中的业务实体。它们可以被认为是业务过程中以数据为中心的组件（名词），如：雇员、顾客、销售订单等。实体服务的例子包括，管理顾客信息的客户服务，或管理顾客所下订单的订单服务。”
Shy 还写道：
“实体服务有一个普遍的特点：在实体级别支持增、查、改、删（CRUD），同时为了解决问题领域、支持应用特性和用例的需要，添加了领域特定的操作。领域特定操作的一个例子是：客户服务暴露一个名为FindCustomerByLocation的方法，它可根据顾客的地址定位顾客的 ID。”
Thomas Erl（即将出版的“ SOA： Principles of Service Design ”的作者，同时他还是其它几本 SOA 书籍的作者），以类似的方式定义实体服务：
几乎在每个企业中，都将会出现业务模型文档，它用来定义组织相关的业务实体。业务实体的例子包括顾客、雇员、发票和索赔等。实体服务模型表示一个以业务为中心的服务，它基于一个或多个业务实体的功能边界或上下文。由于对大多数父业务过程不可知，它被认为是一个高度可复用的服务。结果是，多个父业务过程可利用实体服务实现自动化。实体服务也被认为是以实体为中心的业务服务或业务实体服务。右图展示了一个实体服务的例子。它的一些能力让人想起传统的 CRUD（增、读、改、删）方法。
看起来并不是每个人都同意此观点。John Evdemon，Shy 的同事（同样工作于微软），认为 CRUD 接口是 SOA 的反模式：
“对 web 服务而言，CRUD 操作是错误的代理级别。CRUD 可能在服务内部或横跨几个服务实现，但它们不应该以这种方式暴露给消费者。这是服务将内部（私有）能力渗透到服务的公共接口的例子。”
同样，在谈及 CRUD 时， Steve Jones （“企业SOA 实施策略”的作者，该书由InfoQ 出版）总体上相当直率，并断定：“ CRUD 是垃圾”。最近， Nick Malik 、 Jack Van Hoof 和 Udi Dahan 同样在讨论实体服务的问题，而且他们的结论是（来自 Udi 的博客）：
“实体服务属于应用架构领域。它们并不是服务的成员，服务是 SOA 分解的基本单元。 一个 SOA 服务既可以使用实体服务实现，也可不使用。如果是，那些实体服务就不能在 SOA 服务边界之外被访问。这样，它们就是 SOA 的实现细节。在这种情况下，我们可以就实体服务优于其它事物（如领域模型模式）的相对价值，进行非常有趣的讨论。”
或者正如 Nick Malik 总结的：
“那么，实体服务是反模式吗？从企业的视角来看，是的。从应用的视角来看，则不是。（两者之间并不冲突）。我认为，这依赖于你站在哪个角度来看。”
尽管如此，仍然还有服务粒度的观点 —— 即使在应用级别。如果服务的粒度太细，就几乎不违反“分布式计算的 8 个谬论”，并且如同 Peter Deutsch 当初定义这些谬论时所说的：
[当你做出错误假定的时候]“所有东西最后被证明是错误的，所有东西导致了大麻烦及痛苦的学习经历。”
你有何高见？
评论