值得注意的是，對于他的那種R＆D工作，我完全不需要使用Java EE。 我不需要像Glassfish這樣的JEE服務器所提供的安全性或交易功能，我可能可以使用比Tomcat或Jetty輕一些的東西。 但是，我喜歡JEE的便利性和功能，許多在像Tomcat這樣的標準Java應用程序服務器上開始使用的應用程序最終都會將JEE功能移植到Tomcat中（例如JAX-WS）或遷移到完整的JEE服務器（例如玻璃魚。
Tomcat的用戶經常需要JEE功能-這是在Apache上啟動TomEE項目的主要理由。 該項目將JEE Web Profile功能添加到普通的Tomcat堆棧中，因此它可以處理EJB和JAX-WS之類的事情。
將業務邏輯分為Bean。
我的應用程序已經有2個不同的層。 第一個（從消費者的角度來看）是Web服務層，其任務是提供所有Web服務操作以及其他服務特定任務，例如處理定制SOAP標頭和消息傳遞元數據 ，這些問題有助于解決冪等問題。 最后一層是數據庫訪問層 ，負責與數據庫通信以及處理我的Product實體的持久性和檢索。
我現在要添加的第三層也是最后一層是連接前兩層的中間層-業務邏輯層。 該層將負責實施產品實體服務的規則和決策，例如確保在執行持久性操作之前，存在，添加或驗證任何語義上重要的信息。
這種語義上重要的信息的一個例子是產品的“狀態”。 在我的模型中，我允許產品在多個狀態之間轉換，以維持嚴格的產品生命周期。 這些階段如下，并且本質上是線性的（每個狀態都跟隨最后一個狀態）…
- 臨時
- 有貨
- 可售
- 已停產
- 已刪除
在我的業務邏輯層中，我的Product Manager bean確保每個實體的狀態對于每個服務操作都有意義。 例如，如果您對Product調用createProduct（）操作，則給定的Product必須具有“臨時”狀態。 如果沒有，我的邏輯將對其進行更改。
這些規則對于每個企業都是唯一的，因此它不是一個適合所有解決方案的規模。 在現實世界中，規則引擎或類似的工具將是理想的選擇，因為它將在定義和管理這些規則時提供更多的靈活性。 但是，對于我的基本R＆D需求，此硬編碼解決方案很好，并且充分展示了提供業務邏輯層的好處，因為您可以將業務邏輯“關注點”與消息和數據庫處理邏輯分開 。
一種數據模型可以全部統治。
所有這些層都有一個共同點，那就是它們管理的數據（aka Entity）對象。 產品實體由XML表示，由XSD描述并由WSDL引用。 這些定義被JAX-WS轉換為Java對象，并且這些相同的Java對象在整個代碼中本機使用，從而避免了任何數據模型轉換 。
這種技術被稱為“避免轉換”，是這種基于NoSQL的實體服務開發技術的特殊樣式的主要優點之一。
避免轉換是一種最佳實踐，可以提高服務的可重用性和可組合性– soapatterns.org。
實質上，通過此服務開發，我設法在每個層中使用了這些相同的Java數據對象，但仍保持了真正的合同優先的開發方法。 對于開發人員而言，這確實是個好消息。 我還避免了對數據模型轉換層的需求，當消息和數據庫之間的數據模型不兼容時（對于ESB銷售人員而言，這是個壞消息），這常常就變得很必要。
使用NoSQL還使我完全避免了對表和數據關系使用任何SQL DDL，并且不需要任何復雜的對象映射，例如處理傳統ORM所需的那些映射。 我什至可以隨時間推移變形我的數據模型，而不會經常破壞東西（非常適合服務版本控制）。
關于保持JEE簡單的注意事項。
為了減少與JEE相關的部署和配置麻煩，我使用了新的部署和打包機制，該機制使您可以在同一應用程序WAR文件中定位EJB和Web應用程序。 這使使用JEE功能變得輕而易舉，并大大簡化了Maven的構建，因為我僅使用一個項目和零個部署描述符（甚至缺少web.xml！）。
使用EJB 3.1的JEE從未如此簡單，因為它現在基于使用一些非常簡單的Java注釋。 例如，指定無狀態EJB可以是那么簡單，因為添加@Stateless注釋的一類。 這樣做是在告訴應用程序服務器將類部署到池中，以使其具有高可用性，并將對方法的調用包裝在事務中。 作為無狀態Bean，它將沒有會話的概念，并且不會在調用之間保持任何狀態（對于無狀態服務而言是理想的）。
@Stateless
public class ProductsManager為了從應用程序的另一部分（例如，從@WebService類）使用此bean，您只需添加正確類類型的引用變量，然后使用@EJB注釋對該變量進行注釋。 這告訴應用程序服務器在運行時使用一種稱為依賴項注入的機制從預填充的bean池中“注入”正確類型的實例。
@WebService(...)
public class ProductsEntityService implements Products {@EJBprivate ProductsManager bean;...其他有用的JEE功能。
消息驅動的Bean非常適用于實現事件驅動的消息傳遞 ，其中消息生產者和使用者之間需要持久和異步通信。 但是，我可能不會將它們用于特定的R＆D工作，因為我的需求是用例太弱而無法證明工作的合理性（我將向誰通知新產品？）。 此外， @ MessageDriven bean批注使此功能非常易于使用，并且它是基于JMS的完善且高度可靠的功能。
EJB 3.1還允許使用許多新的有用的bean類型。 單例bean是由服務器管理的單例類，并使用@Singleton批注指定（如果需要為群集單例之類的事情，這很方便）。 @Schedule批注可用于根據日程安排（例如，每個星期五中午）生成常規事件，這些時間可以方便地進行報告等。
摘要
因此，我現在擁有一個可以正常工作的n層Web服務，該服務能夠使用NoSQL數據庫來持久化，管理和檢索Product實體。 下次，我將介紹使用這些技術實現更多SOA模式的方法。 訂閱我的博客以在發生這種情況時得到通知。
繼續第5部分 。
參考： 使用NoSQL實施實體服務–第4部分：我們的JCG合作伙伴 Ben Wilcock的Java EE ，位于SOA，BPM，Agile和Java博客上。
翻譯自: https://www.javacodegeeks.com/2012/09/implementing-entity-services-using_389.html
)
