我當前的產品實體服務實現與業務流程無關，因此在消費者想要發現或存儲產品信息的任何情況下都可以高度重用。 但是，按照現狀，產品實體服務旨在在受信任的環境中使用。 這意味著對諸如創建，更新或刪除之類的操作的訪問沒有限制。 在嚴格控制的公司沙箱中，這很好，但是如果我想與不信任的用戶共享我的一些服務操作或產品信息怎么辦？
讓我們想象一下，除了內部使用產品實體服務外，我們還希望滿足以下敏捷的“用戶故事”……
這樣一來：我發布的產品信息是準確的，并且經常可供異地客戶使用。
作為：銷售總監兼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
——mongoDB的索引詳解)
