一些人认为实体服务(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 当初定义这些谬论时所说的:
[当你做出错误假定的时候]“所有东西最后被证明是错误的,所有东西导致了大麻烦及痛苦的学习经历。”
你有何高见?
评论