近日，JBoss發佈了流行的對象/關係（O/R）映射框架Hibernate 4。Hibernate 4主要的新特性如下所示：
所謂多租戶架構，就是將大型的企業應用劃分爲虛擬的多個客戶端/客戶（又叫做租戶）而不必將所有數據放在一個共享空間中。該原則改進了管理、監控， 甚至是安全，對於大型的服務提供商來說非常有幫助。提供雲基礎設施的公司也會從多租戶架構中獲益頗豐。該原則有幾種實現方式，列舉如下：
- 每個客戶端/租戶使用不同的數據庫與/或模式
- 所有客戶端使用相同的數據庫/模式，但所有表中都有一個附加的列（比如說tenant_id），用於過濾數據
Hibernate 4.0支持上述第1種方式，並且計劃在下一個版本中支持第2種方式（也就是區分多個租戶）。
Hibernate中新增的另一個重要特性就是“Services”API規範。除了標準的內建服務外，你還可以通過該API以其他幾種方式擴展 Hibernate。現在已經有了幾種方式可以插入到Hibernate內核中，但Service API則提供了一種標準方式來實現這一點。近日，InfoQ有幸採訪到了Hibernate項目領導Steve Ebersole以深入瞭解這些新特性：
InfoQ：你能否談談“Services”的概念呢？他們只能用於Hibernate擴展麼，對於應用開發者來說有何價值呢？
首先，我覺得大家應該認識到有很多應用開發者在每天的應用開發中也會開發Hibernate擴展。如果你開發自定義事件監聽器、自定義類型等等，那麼你就在開發Hibernate擴展。這種情況很常見。
你可以將Services API看作是小型、領域特定的CDI，提供對常見行爲的統一處理，需要諸如生命週期、依賴、JMX管理等。因此從這個角度來說，開發者會很頻繁地開發 Services。一個簡單的示例就是某個事件監聽器想要向JMS中寫入。我可以將JMS看作是一個Service，因爲其他監聽器或是自定義擴展都可能 會用到該JMS連接。
但Services是無限多的。難道“應用代碼”會查找並直接使用Services麼？不，通常不是這樣。但這並不意味着每個人都會這麼看。還是回到方纔 的JMS用例，我可以確定地說應用代碼也需要與該JMS連接交互。這樣，它就可以從Hibernate中查找該JMS連接。基本上，它會使用 Hibernate管理整個生命週期。
InfoQ：OSGi對於你來說有多重要？Hibernate距離完整支持OSGi還有多遠呢？
這個問題很有意思。根據我的經驗，在我們真的開始推進時，很多人會問“OSGi支持”或“OSGi兼容”對於他們到底意味着什麼，他們要麼不知道，要麼就是答非所問。我覺得這應該是雙重的：
首先，Hibernate能否處理OSGi環境下的模塊化類加載？毫無疑問，在4.0前這是很棘手的，因爲之前的Hibernate使用了一個非常傳統的 ClassLoader設置。在4.0中，ClassLoaderService成爲標準服務之一，它定義了Hibernate查找類與資源的方式，以及 如何解析標準的Java ServiceLoaders。本質上，它定義了一個API，通過class-path處理Hibernate的所有交互。更爲重要的是，它是通過一種可 交換的方式來定義的。其意圖在於非傳統的類加載環境可以交換他們自己的策略來決定Hibernate該如何與ClassLoaders交互。這已經在 JBoss AS中得到了充分的測試，測試中使用了自定義的ClassLoaderService來與模塊化類加載進行交互。因此從這個角度來說，Hibernate 已經實現了目標。
其次，就導入/導出來說，Hibernate是如何定義自己的“OSGi元數據”？目前，Hibernate並未在其任何jar中定義特定於OSGi的元 數據。如果有人做了這方面的貢獻，我們就會將其納入進來。要知道的是Hibernate團隊中沒有人是OSGi專家。這應該由熟悉OSGi元數據的相關人 士來實現。我們在4.0中所做的是將包劃分開來以便向感興趣的人們表明立場，如果我理解的沒錯，那麼這些人應該擔負起這個責任。
InfoQ：日誌框架爲何發生了變化？
在Hibernate 4開發伊始，我們就決定要在日誌中加入對i18n的支持。在那時就我們所知，JBoss Logging是唯一一個完整支持i18n（包括參數化）的日誌庫。其i18n支持更加類似於GNU gettext，相對於更加Java化的ResouceBundle方式，Hibernate開發團隊一致認爲JBoss Logging的方式更好。JBoss Logging的異常消息也支持i18n（通過常見的方式實現），但我們並沒有用到這個功能。
此外，JBoss Logging還包含了對消息鍵的內建支持，它將消息鍵作爲獨立的概念而非ResourceBundle中的鍵，以此來實現i18n。這是個不可改變的 鍵，與導致日誌消息的情況相關聯。這個概念非常適合於圍繞着這些鍵來構建FAQ和文檔。沒錯，你可以直接通過SLF4J、Java Util Logging等做到這一點。但從工具的角度來看，我認爲這些鍵應該成爲一等公民。對於充斥了很多日誌的大型項目來說，你真的要能夠確保這些鍵是唯一且一 致的。JBoss Logging也做到了這一點。
InfoQ：有些人可能會說這些新特性幾乎都是內部的。這是否意味着Hibernate已經成熟了，不需要再添加用戶能夠直觀看到的一些變化了？Hibernate是否已經進入了“維護”模式了呢？
當然不是了，雖然我們沒有添加新的特性，但Hibernate並沒有進入到維護模式。它需要維護麼？當然了。不知道是否有人注意到，Hibernate已 經10歲多了。我們已經貼了不少創可貼，我覺得在計劃並開發新特性時，我們不應該在創可貼上繼續貼新的創可貼了。Hibernate生長自YAGNI設計原則，隨着時間的流逝，契約/API概念將會變得自然而明顯。他們也將不斷髮展。
我覺得目前只有爲數不多的Java OSS項目能夠像Hibernate那樣長久以來保持成功狀態，這些成功的框架都會經歷一個或多個大的重構期。
InfoQ：Hibernate 5有哪些值得期待的特性呢？當前的開發目標是什麼？
5.0的主要目標在於重新設計Hibernate O/R元數據的模型，包括XML和註解。這些代碼來自Hibernate最初的需要。來自JPA的的新需求或特性將會構建於其上。這麼做的主要原因在於很多項目都使用了這些類，我們想要降低對這些項目的破壞。但說實在的，重新思考這些模型已經有些晚了。
Java artifacts已經位於Maven Central中了，可見Hibernate 4已經爲進入到Java應用中做好了準備。
