現在該開始使用NoSQL項目對SOA實體服務進行編碼了，并且正如我所承諾的，我將從Web服務的合同開始。 看一下本系列的第1部分 。

這種從Web服務合同定義開始的技術是面向服務的體系結構實現的“合同優先”方法的核心，并具有許多技術優勢，包括……

• 正邏輯對合同的耦合（因為實現代碼遵循合同）。
• 消費者對合同的正耦合（因為消費者與合同耦合）。
• 避免合同與實施的耦合（在實施影響合同的情況下）。
• 避免合同與技術之間的耦合（消費者變得依賴于實施技術）。

我不想繼續進行合同優先的SOA，但這確實很重要。 實際上，這是某些Web服務框架（例如受人尊敬的Spring Web Services）所允許的唯一方法。 這里將詳細解釋Springsource僅支持合同優先方法的原因。

我服務的商業案例。

我決定實現一個用于管理“產品”實體的Web服務，我將其稱為“ 產品實體服務 ”。 產品信息管理 （簡稱PIM）是一種非常常見的業務活動，因此，我的實體服務應具有很大的重用潛力。 我個人知道這是正確的，因為我以前有零售和國防物流方面的經驗，但是如果我想證明這種情況，我通常會分析業務流程并尋找所有有利于產品信息的地方。 如果這樣做，我可能會發現以下業務流程將成為產品實體服務的潛在消費者（例如，在傳統零售環境中）…

• 購買，產品購買和入職
• 銷售訂單捕獲
• 銷售訂單履行
• 客戶服務
• 目錄制作
• 業務2-業務支持
• 等等等

我的產品實體服務的運營。

因為我要創建的服務純粹是管理產品實體，所以我將使操作保持基本狀態。 我的服務將為消費者提供創建，讀取，更新，刪除和查找操作。 該服務將是具有WS-I互操作性證書的基于SOAP的Web服務，以幫助確保跨平臺與眾多消費者的兼容性。 稍后，我可能還會提供同一服務的REST版本（通常稱為并發合同模式）。

然后，我的服務使用者（可能是其他服務或流程）可以隨心所欲地使用這些產品實體，例如，通過提供更多與業務相關的功能來支持產品工作流程，例如“批準”或“中止”。

我的服務合同將使用Web服務描述語言（ WSDL ）進行描述。 我傾向于手工制作這些文件，然后根據WS-I基本概要文件進行檢查，以確保已創建可互操作的合同。 WSDL并不是特別友好的文件，但是我認為任何優秀的SOA架構師都應該能夠編寫一個。

產品實體的數據模型。

產品數據實體應該能夠描述對企業有價值的現實生活中的產品。 每個企業對于此數據項應包含的內容都有自己的想法，因此，為了使其簡單起見，我將定義一些基本字段，例如id，名稱，描述，制造商，類別和大小 。 我還將添加一些內部管理字段，例如版本，創建/更新/刪除的日期等。最好將這些數據視為“文檔”，因為SOA和NoSQL肯定會從以文檔為中心的視圖中受益。世界。

產品文檔將使用XML Schema（即XSD ）進行描述。 我也傾向于手工完成這些工作，并且在結構中使用了很多模塊化來幫助支持模式集中化模式，該模式促進了SOA中使用的數據模型之間的重用和互操作性。 這種技術通常稱為創建“規范數據模型”，該模型描述一個中央模型中的所有業務實體。

創建Java服務。

既然服務合同已經完成，我準備創建我的maven項目并開始實施服務。 為此，我使用最新的Netbeans IDE，因為它具有用于啟動Maven項目和導入WSDL進行實施的出色向導。 Maven幫助代碼編譯，打包，部署和測試以及管理依賴關系并為我的服務執行代碼生成。 這兩個工具都是免費的。

WSDL導入過程將創建一個Java接口，該接口代表并反映服務的合同。 它還創建了一組Java對象，這些對象表示服務用作消息的XML結構。 這些對象由導入例程使用JAXB批注進行批注。 JAXB提供將XML文本“編組和解組”到Java對象中的功能。 作為JAX-WS Web服務框架的一部分，這種情況在后臺不可見地發生。

我現在要做的就是在服務上創建方法的實現。 首先，我只是添加一些基本的樣板代碼以使某些功能正常工作。 完成此操作后，我將服務部署到服務器上，并進行一些基本的集成測試，以檢查它們是否全部懸掛在一起，以及服務端點是否按預期公開。 我為此使用的服務器是Oracle的Glassfish 3.1 ，它可以集成到Netbeans中，并且也是免費的。

初始服務集成測試

我將SOAP UI用于我的服務測試，因為它是免費的并且非常強大。 它幾乎可以用作幾乎所有SOAP或REST服務的測試工具，并且使用這樣的測試工具將使我不必構建工作的服務客戶端，而這可能是非常耗時的。

我應該提到，可以使用SOAP-UI以完全測試驅動的方式完成服務開發，但是從一開始就部署基本服務（即使它不起作用）也很容易，只是為了從中獲取它的WSDL。是使用“ http：// service？wsdl”約定的端點，并檢查是否已正確部署和集成所有內容。 如果我不這樣做，那么我就可以開始使用WSDL，但是端點位置將無法工作，因此測試失敗的原因不是邏輯不好，而是因為普遍缺乏服務可用性。

現在，我可以創建基本測試，以在Glassfish本地托管的服務實現和SOAP-UI測試客戶端之間成功地向后和向前傳遞產品消息，即使這些消息不執行任何操作并且其中包含的產品不執行任何操作堅持下去。

下一步是開始CouchDB集成，以便可以保留和從NoSQL數據庫檢索產品消息。 然后，在服務和CouchDB DAO之間，我將添加使它全部表現正常所需的任何業務邏輯。

當我啟動CouchDB DAO時，立即訂閱以獲得警報。 如果您錯過了本日記系列的第1部分，則可以在這里趕上 。

到目前為止的費用：

• 軟件–￡0。
• 時間– 2到8個小時（取決于經驗）。

參考： 使用NoSQL實施實體服務–第2部分：我們的JCG合作伙伴 Ben Wilcock在SOA，BPM，Agile和Java博客上的合同優先 。