首要特性是斷開或分離操作模式――在這種模式中，用戶應用程序連接到數據庫并從中取回數據后立刻釋放連接。數據作為相關的記錄集被應用程序查看――POJO圖形或DataGraph――看您喜好哪種術語了。數據可以在遠程進程中修改，而不需要對數據庫的原始數據建立活動連接。稍后，當重新建立數據庫連接時，這些修改可以合并到持久性數據中。這種斷開操作模式對可伸縮性非常關鍵，例如10000個活動用戶可以同時操作包含十個數據庫連接的連接池。這種應用程序使用模式同樣節省了大量的金錢，因為隨著連接數量的增加，數據庫安裝開銷將呈指數級增長。JAP支持這種斷開操作模式，當持久性存儲上下文關閉或事務提交后，取回的POJO實例將斷開連接，并且可以遠程修改斷開的對象圖并稍后合并到不同的持久性存儲上下文中。另一方面，SDO定義了ChangeSummary概念，用于跟蹤斷開的DataGraph中的改動。因此，JPA實現自然可以使用ChangeSummary內容將改動有效地并入到數據庫中。
JAP和SDO自然結合的另一點是：它們都使用取回的數據作為連接對象圖。JPA目前還沒有充分開發定義斷開數據圖的潛力，但是OpenJPA或Kodo支持一種名為FetchPlan的強大擴展――來自于JDO規范的貢獻，該規范良好定義了這一概念，即指定從數據庫取回對象閉包的哪一部分。這種控制非常重要，因為完整的實例閉包通常就是整個數據庫。另一方面，SDO DataGraph定義了一種經過配置的閉包，即所謂的根DataObject。
使用JPA持久性存儲SDO的關鍵挑戰是什么？
需要解決的關鍵分歧是類型系統。JPA是針對嚴格類型的POJO設計的。JPA實現管理的對象實例是由Java類靜態定義的，并由Java編譯器進行編譯。JPA（及其前身JDO）的美妙之處在于：這些實現能夠在不產生干擾的情況下截取對持久性實例的改變（狀態和/或關系）。對象仍然保持POJO特性，但JPA運行時可以知道用戶應用程序何時會對持久性對象調用setter方法以修改其狀態，或何時調用要求從數據庫取回更多日期（通常稱為Lazy Loading）的getter方法。實際的實現會根據截取改動的方式而有所變化――例如――OpenJPA或Kodo取決于增強――該過程將修改編譯后的持久性Java類的字節碼，而其他實現可能會使用不同的機制，例如代理原始實體。無論哪種情況，都需要對實現作出較大的改動，以脫離其基本假設。例如，存在編譯后表示持久性數據的Java類。
另一方面，SDO傾向于松散類型的對象。SDO可以使用名稱和年齡表示一個Person對象，而不需要定義一個Person.java類。Person的定義可存在于一個XML模式文檔中，或者甚至可以通過編程的方式創建。
那么如何使用JPA存儲一個Person DataObject而不用編寫Person.java類呢？理論上講，JPA怎么能采用不是強類型的數據表示呢？
類型轉換系統僅僅是開始。還有很多問題要解決：
如何定義實例的身份？
如何定義到數據庫模式的映射？
如何使用Java表示SDO類型之間的關系？
如何將斷開的DataGraph的改動轉換為Java實例的更新？
如何放寬JPA限制以使用松散類型數據？
為了不被答案不是特別明顯的問題混淆，我決定逐步執行一些步驟。因此我嘗試解決幾個簡單場景或用例。
用例：通過JPA API將SDO Types/DataObjetcs轉化為持久性數據
文章來源于領測軟件測試網 http://www.kjueaiud.com/
