我正在開發一種契約優先集成，我首先設計了XSD & WSDL文件，以便客戶調用託管在我們服務器上的特定Web服務。我還需要以結構化的方式將請求保存在數據庫表中（Oracle數據庫首先，其他數據庫將在晚些時候發佈）。我需要保存所有領域作爲單獨的列和多個發生節點應該可能有自己的表等創建一個Web服務，JPA實體和數據庫表，以XSD開頭
我想從XSD創建WS存根，並將它們標記爲JPA的實體，然後使用這些創建數據庫表實體。我正在學習JPA（EclipseLink），我想知道這是否是最好的方法。
所以基本上我的問題是：當你從請求/響應XSD開始時，你們如何創建Web服務，JPA實體和數據庫表？
感謝您的所有想法。
問候， 格克汗
使用Web服務生成的類爲JPA實體可能似乎是個好主意，但在實踐中它將會是保持一個噩夢。
保持JPA圖層和WebService圖層分離好得多。
JPA層將通過優化數據庫設計驅動（之類的關係，規範化/反規範化出於性能的考慮，適當的字段類型的使用，主鍵生成策略等）
在另一方面，Web服務圖層是您的應用程序（或應用程序的一部分）的外部接口，它會被提供給您或以這種方式進行設計，因此從API使用的角度來看它是最舒適的，它可能遠不是最佳的從JPA的角度來看。
想想如果有人會告訴你WSDL將要更改，一些字段將從一個類移動到另一個類將會發生什麼。如果Web服務生成的類是您的實體，您還必須更改數據庫模式，遷移數據等。
反之亦然。如果您需要更改數據庫模式（例如，出於性能原因），則需要更改應用程序Web服務界面，我懷疑Web服務用戶會爲此感到高興。
因此，即使它意味着更多的工作，也要保持JPA層和Web服務層分離，因此您可以更改一個部分而不更改另一個部分。
在模型視圖控制器模式中JPA圖層是模型的一部分，Web服務就是您的視圖 - 它們不應該相互依賴太多。
我在DoxDB上採用了一種稍微不同的方法，因爲我選擇了JSON而不是XML作爲文檔結構，儘管我認爲它與您所需要的沒有太大差別（事實上，當我開始使用它時XML首先）。
使用LOB存儲您的XML內容。您的JPA只有一個@Lob註釋，您可以加載內容。
使用XSD驗證您的數據來自您的傳輸使用Marshaller，它通過您的@WebService調用，它提供了CRUDL方法在JPA實體中處理作爲lob的條目。
然後調整安全性和性能。
需要注意的是我自己不映射將JSON/XML到數據庫中的字段和表格，而是我有一個表，一個「SCHEMANAME」欄，LOB以及一些ID（雖然事情目前它有一些額外的審覈字段和只執行邏輯刪除的字段）。我搜索了Stack Overflow，並且似乎共識是，如果數據相似，最好有一個大的表對比許多小表，而且JPA不支持動態表名。
取代JAX-WS，我選擇了JAX-RS（REST API），但這只是一個傳輸層，您可以根據自己的需要選擇其中之一。在那一層，我實現了一個與JPA交互的CRUDL API。你可以在JAX-RS中傳遞XML，如果你不想，你不需要去WSDL。
最初的表現措施並不算太壞。加載100,000行花了大約一分鐘，做單行檢索仍然在亞秒。檢索和渲染100,000行大約需要5秒鐘。當然，它沒有科學，我懷疑它會在現實生活中產生這樣的性能，由於XA事務，分佈式友好，安全性和傳遞性依賴性很小而導致大量負載。
我早期做出的一個體繫結構決策是DoxDB不會對數據庫執行搜索，而是將作業傳遞到ElasticSearch，該ElasticSearch通過其REST API調用，而不是嵌入到應用程序中（這將涉及到他們的依賴關係）。這是供應商的具體情況，但目前我還沒有找到更好的選擇。
我想到的是同樣的東西 - 關於保留JPA和WS的存根是絕對正確的。我也在檢查從XSD文件生成表創建腳本的工具，但沒有一個真正證明自己創建它們太不同，至少我有更多的控制權。我的問題是，Web服務請求/響應XSD具有太多多次發生的節點，並且有些節點深度很深，所以很難對所有這些關係進行建模，因爲表列不能是表本身。我需要爲所有多個發生節點定義單獨的表並添加適當的鍵列 – GTware 2013-05-07 19:55:58