我当前的产品实体服务实现与业务流程无关，因此在消费者想要发现或存储产品信息的任何情况下都可以高度重用。 但是，按照现状，产品实体服务旨在在受信任的环境中使用。 这意味着对诸如创建，更新或删除之类的操作的访问没有限制。 在严格控制的公司沙箱中，这很好，但是如果我想与不信任的用户共享我的一些服务操作或产品信息怎么办？
让我们想象一下，除了内部使用产品实体服务外，我们还希望满足以下敏捷的“用户故事”……
这样一来：我发布的产品信息是准确的，并且经常可供异地客户使用。
作为：销售总监兼IT经理。
我们希望：为非现场用户和系统提供我产品信息的高可用性“只读”副本。
这种情况在商业中并不罕见，过去我已经与一些客户一起实现了类似的用户案例。 但是，关于我们用于实现实体服务的技术（Java / JAX-WS和CouchDB NoSQL）的奇妙之处在于，它们使开发此方案非常容易。
首先是建筑设计。
为了实现这个用户故事，我将针对服务体系结构调用另外两种SOA设计模式-服务数据复制和并发合同。 在第二篇文章中，我们已经讨论了“合同至上”的方法，因此除了要说它仍然适用于此之外，我将不做任何其他详细说明。 该合同仍然是标准化和脱钩合同 。
服务数据复制是一种模式，可通过在基础结构上其他位置创建服务所需的数据的完整副本来帮助您实现高水平的服务自治性和可用性。 然后可以使用此副本代替原始副本，以平衡基础结构上的负载。
当“ [现有]服务的合同可能不适合或不适用于所有潜在服务使用者”时，将使用“ 并发合同”模式。 例如，当出于安全性，协议或可访问性的考虑，需要为特定的用户子集（例如异地用户或处理能力或带宽受限的移动设备）提供类似（但不相同）的内容。
为了实现我们的新用户故事，我们将同时使用这两种模式来提供“只读”版本的产品实体服务。 但是，通过提供产品实体服务的第二个“只读”版本，您也可以说我们正在部分实现冗余实现 SOA模式，因为我们为服务的某些关键操作提供了第二个冗余选项。
最终的架构看起来像这样（单击放大）…
服务合同。
最初的产品实体服务提供了五项操作- 获取，查找，创建，更新和删除，但是向外部人员提供所有这些功能不是必需的，并且可能存在很大的问题（在安全性，完整性等方面）。 我们当然不希望任何外部用户在未经我们许可的情况下创建或更新我们的产品信息。
因此，在新的“ 只读产品实体服务 ”的Web服务合同中，我完全删除了Create ， Update和Delete操作，仅提供了Get和Find 。 所有数据类型保持相同（相同的Product.xsd描述产品实体等）。 保持数据类型相同很重要，因为我在故意应用规范模式和模式集中化模式并利用标准化服务合同主体以避免转换。
Java代码。
有了这个新的只读服务，我仍然要先签订合同，因此我创建了一个新的Maven项目，在构建期间的首要任务是导入只读产品实体服务的WSDL联系人并从中创建一组JAX -WS服务接口和数据对象。
从现在开始，我可以重用已经为“完整”产品实体服务开发的一些代码。 通过将以前的代码库重构为模块，我什至可以让Maven将原始代码视为该新服务的依赖项。 本质上，我感兴趣的是为Get和Find操作的业务和持久性逻辑创建的EJB和DAO。
通过重用现有代码并在Amazon云上创建Glassfish服务器 ，我可以在创纪录的快速时间内站起来使用新服务，并且可以完成用户故事的一半。 我现在只需要一些可复制的产品数据即可使用…
开始数据复制。
Couch DB免费提供了一个出色的企业级复制系统。 这使得实现服务数据复制SOA模式非常容易。
Couch DB的内置数据复制器可以在网络或Web上可用的任何两个CouchDb实例之间复制整个文档数据库。 在这种情况下，我已经在名为IrisCouch的托管提供程序上创建了CouchDb数据库。 他们可以一口气为我提供安全的CouchDB实例或各种大小的实例，并将照顾所有必要的基础架构和备份要求。 对于小型用户，他们甚至免费这样做。
为了设置复制，我只需要使用CURL命令行工具通过HTTP向本地CouchDB实例发出特定指令即可。 这些说明告诉我的本地CouchDB服务通过Web在IrisCouch上的远程CouchDB数据库中复制我的产品数据。
数据库复制指令是一个JSON文档，看起来像这样……
{'source':'products','target':'https://username:password@instance.iriscouch.com:6984/products','create_target':true,'continuous':true}本质上，此JSON指令说“ 永远将本地产品数据库文档复制到远程Iriscouch实例 ”。 发出命令后，CouchDB立即开始工作，并开始将本地数据复制到远程数据库实例。 这包括更新和删除以及产品数据库中存储的所有“设计文档”。 然后，该产品副本立即可用于托管在Amazon EC2云中的我的只读产品实体服务。
从此以后，使用此服务的Get或Find操作的服务使用者将看到内部使用的数据的副本。 复制将使信息保持最新。
最后是用户验收测试。
那么，我们对新用户故事的要求做得如何？
通过在亚马逊云上托管只读版本的产品实体服务，我们创建了高度可用的异地网站服务。 它提供的数据是我们在现场使用的数据的精确副本，在正常情况下，两个副本之间的延迟只有最短的时间。
如果我的现场网络出现故障，无论如何都将继续运行基于只读云的产品实体服务版本，并且由于我们使用的是Amazon云基础设施，因此如有必要，它可以受益于几乎无限的运行时资源。 可用性永远不会成为问题。 我们可以随时添加更多计算机，并提供负载平衡，并在必要时将计算机分布在多个大洲。
我的猜测是，销售总监会很高兴我们的客户总是可以看到我们产品目录中的信息，并且客户自己应该对他们现在所获得的全面而可靠的服务感到非常满意。 最后，IT管理人员会很高兴网络安全性保持不变，并且新的异地托管服务几乎不需要花钱就能运行并且非常可靠。
剩下的就是向我们的客户宣传只读产品实体服务端点，并支持他们使用它。 总而言之，在办公室度过了非常成功的一天。
您想自己尝试只读产品服务吗？
端点详细信息可以在SOA Growers 简单服务存储库中找到 。 点击“服务资料库”链接，然后查找“ R20121231”？ 释放。 在此处，您可以找到指向该服务的WSDL，WS-I证书的链接，以及指向一个在AWS微实例上托管的实时演示Web服务终端节点的链接。
体验现场演示的最佳方法是下载SOAP-UI测试套件。 该测试套件需要SOAP-UI v4（可以免费下载）。 测试套件包含对服务上所有可用操作的简单测试。
在线上了解整个博客系列…
这可能是本系列中有关使用Java和CouchDB构建实体服务的最后一部分。 如果您错过了本系列中的任何较早的博客文章，并且想赶上来，下面列出了其他条目…
- 使用NoSQL实现实体服务–第1部分：概述
- 使用NoSQL实现实体服务–第2部分：合同优先
- 使用NoSQL实现实体服务–第3部分：CouchDB
- 使用NoSQL实现实体服务–第4部分：JavaEE
参考： 使用NoSQL实施实体服务–第5部分：我们的JCG合作伙伴 Ben Wilcock在SOA，BPM，Agile和Java博客上的第5部分：使用云提高自治性 。
翻译自: https://www.javacodegeeks.com/2012/09/implementing-entity-services-using.html
