7 soa
我考虑了一组servives的SOA架构,以支持进出口咨询了,以前我们使用的数据库的集成,每个应用程序挑选出来它从一个共享的MS SQL数据库需要与它等合作业务.我们有各种与怪物数据库集成的应用程序,包括java,.net和microsoft访问,由于一切都是紧密耦合的,因此存在引用完整性.
我对如何支持服务之间的数据共享感到有点困惑.
让我们将产品服务放在批发商每个月提供的产品数据库之上.我们构建了一个域模型,并使用Hibernate或者它来实现数据库的实现,实现明智产品是一个大型对象图,给出了批发商提供的有关产品的信息.
现在假设Review服务,定价服务,送货服务和Stock Service将订阅ProductUpdated,ProductAdded,ProductDeleted.问题是每个服务只需要有关产品的部分或部分信息.运输可能只需要尺寸和重量.定价可能只需要产品ID,批发成本,批量折扣,迄今为止有效的价格.审核可能需要产品ID,产品名称,生产商.
是标准做法只是发布整个产品(适当的非订户特定合同,例如ProductUpdated,以及合适的架构 - 代表所有产品对象图),并让订户将他们需要的任何内容映射到他们的域模型(或者他们做什么他们想要,甚至可能没有域模型)...
或者当我写这篇文章时,我想的可能是:
产品服务发布ProductAdded消息(不包括产品详细信息只是产品ID和时间戳)
定价服务订阅ProductAdded并发布RequestPricingForProduct消息
产品服务发布ResultForPricingForProduct消息
嗯..似乎更好一点......但它的感觉就像我建基于什么其他服务我可以找出什么,他们会需要,也许在未来的XYZ服务需要的东西不同产品的服务合同.我会停在那里,因为我认为它变得越来越清楚,我感到困惑...或许上述方法将起作用,因为我应该揭露一种方式来返回任何应该是公共的正确的.
任何评论或方向都非常感谢.对不起,如果这出现了一半.
我实际上认为这个问题的解决方案是不共享数据.SOA意味着数据由服务拥有 - 它是该数据的技术权威.我建议阅读一些Pat Helland文章,例如Data On The Inside,Data On The Outside.
这些不同服务之间唯一应该共享的是主键 - 示例中的ProductId.否则,对于每个服务,需要在事务上保持一致的数据一起使用.
不需要一个"产品".每项服务可以在其服务中具有不同的产品视图.对于定价服务,您有productId和价格.对于审核服务,productId和审核.等等.
如果这些数据开始让人感到困惑,那么如果来自所有这些不同的服务,那么如何在UI中显示这些数据.如何显示具有ProductService产品名称和ReviewService评论文本的产品的评论列表？
答案是从所有不同的服务组成UI.从产品服务获取产品并从审阅服务获取审阅数据,然后在UI中合并这些数据.
我最近处于你的位置。通过服务直接暴露底层对象的问题是增加了层之间的耦合，并且使用面向服务的体系结构变得毫无意义。您将无法在不影响 Web 服务的情况下更改这些对象或业务规则。
听起来你走在正确的轨道上。如果您认真对待分离层，那么最常见的模式是仅为 Web 服务（可能是每个服务）创建一组新的单独消息类，并来回转换您的内部对象。
有关如何以这种方式设置服务层的示例，请参阅“服务接口”模式。在服务的客户端，有一种相反的模式，称为“服务网关”。
《应用程序架构指南 2.0》有一整章专门介绍您所做的决策类型（http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines）。我会下载整个指南。
这是与您最相关的部分。长话短说，如果您花时间创建新的粗粒度方法和基于消息的对象，您最终将获得更好的 Web 服务：
设计服务接口时请考虑以下准则： 考虑使用粗粒度接口来批处理请求并最大程度地减少网络上的调用数量。设计服务接口时应确保业务逻辑的更改不会影响接口。不要在服务接口中实现业务规则。考虑使用标准参数格式，以提供与不同类型客户端的最大兼容性。不要在界面设计中假设客户端使用服务的方式。不要使用对象继承来实现服务接口的版本控制。