新的Java EE 7規范負責人Linda DeMichiel（右圖）在主題演講中詳細介紹了通用方法。 Java EE 7的主要重點是將Java應用程序引入云中。 通過從J2EE到Java EE的步驟，通用服務方法已集成到平臺中。 意思是，開發人員能夠使用服務并以聲明方式使用服務。 從Java EE 7開始，平臺本身應成為一種服務。 在含義上提供了使用Java EE應用程序服務器啟用PaaS（平臺即服務）的足夠方法。 基本上是為了使EE的客戶和用戶能夠利用整個范圍的云（公共，私有和混合）。 這應該通過添加新的平臺角色，元數據和API來實現，這些角色支持所需的需求，如多租戶，彈性和可伸縮性。 除了新的“塊上孩子”，成熟的規范還需要大量更新以支持這些要求。
查看9個“進行中的”規范中已經存在的要點問題，應該使我們更加了解如何實現“云目標”。
JPA 2.1（ JSR 338 ）
包含新功能的第一個規范是JPA 2.1。 可以使用以下簡短列表來描述新功能：
–多租戶（表區分符）
–存儲過程 –自定義類型和轉換方法 –示例查詢 –動態PU定義 –模式生成（附加映射元數據以提供更好的標準化）
JMS 2.0（ JSR 343 ）
一般而言，這可以認為是最成熟的規范。 自上次維護版本（2002年4月）以來，還有9年的時間。
–適度的范圍
–易于發展 –可插拔JMS提供程序 –支持“云”的擴展
EJB 3.2（ JSR 345 ）
Enterprise JavaBeans 3.2的目標是鞏固這些進步，并繼續簡化EJB架構，并為進一步實現云計算的Java EE平臺范圍的目標提供支持。 EJB 3.2的范圍旨在相對地集中于這些目標。
–增量因式分解（攔截器）
–進一步使用注釋來簡化EJB編程模型 –建議的可選：BMP / CMP –建議的可選：使用RPC的Web服務調用
CDI 1.1（ JSR 346 ）
自從CDI 1.0規范的最終版本發布以來，社區已經發現了許多問題，并且對該規范進行了更新可以解決這些問題。 此處提供了建議的更新列表，但是EG將考慮隨著JSR進行而提出的其他問題。
–嵌入式模式
–生命周期事件 –聲明式包掃描 –攔截器和裝飾器的全球訂購 –注入靜態變量
Servlet 3.1（ JSR 340 ）
在開發Servlet規范3.1時，EG將考慮平臺的任何要求，以優化Web應用程序的平臺即服務（PasS）模型。 除此之外，還應解決以下領域。
–云支持
– NIO.2異步I / O –利用Java EE并發 –安全改進 – Web套接字支持 –易于發展
JSF 2.2（ JSR 344 ）
新的JSF JSR將是一項重要的功能更新，它將基于以前的JavaServer Faces版本的改進。
–易于發展
– HTML 5支持（表格，標題，元數據） –新組件 – Portlet集成
JAX-RS 2.0（ JSR 339 ）
JAX-RS解決了大多數要求的社區功能。 僅舉幾例：
–客戶端API
–超媒體 –用于驗證的主要API將是Bean驗證API –易于發展
表達式語言3.0（ JSR 341 ）
自JSP 2.0以來，表達式語言（EL）已成為JSP規范的一部分。 在Java EE 7中，它將成為一個單獨的JSR。
–獨立的JSR
–易于在外部容器中使用 –基于標準的集合選擇 –新運營商 –用于表達評估的CDI事件
Bean驗證1.1（ JSR 349 ）
作為1.0版，Bean驗證在明智的方面保持了優勢。 社區已經表達了對其他功能的興趣，這些功能可以增強規范第一版中所做的工作。 –與其他JSR（JAXRS，JAXB，JPA，CDI，EJB，JSF）集成 –方法級驗證 –約束構成
云？ 那是雨嗎？
通過查看這些提案，很明顯其中一些提案具有啟用云的空間。 有些根本不在乎。 到目前為止，搜索云內容很少成功。 讓我們看一下傘JSR 342 。 官方頁面是公開的，可以在http://java.net/projects/javaee-spec/上找到。 非常有趣的是Java EE 7平臺和PaaS模型支持文檔 （PDF），該文檔描述了Java EE 7中PaaS支持的總體體系結構。通過評論，專家組在很大程度上達成了一致。 它總結了所需的角色（PaaS產品供應商，PaaS提供者，PaaS客戶經理，PaaS客戶，應用程序提交者，應用程序管理員，最終用戶），并給出了兩個示例場景，它們在PaaS環境中發揮作用。 進一步，您會發現一些定義和術語：
PaaS應用程序：
“包含領域特定代碼的離散軟件工件，
可以由PaaS客戶上載到PaaS環境并部署在其中。
該工件可能會消耗PaaS資源，并分布在多個JVM中 根據QoS設置和/或SLA的實例。 根據其使用條款， 隨后，可以通過以下方式將PaaS應用程序部署到PaaS環境中： 可能還有其他任何PaaS客戶。”
承租人：
“由于在此處描述的模型中，PaaS客戶對應于
隔離域，我們將使用術語“租戶”來避免與
在業務環境中“客戶”一詞的其他用法。”
應用程序開發人員：
“我們將使用“應用程序開發人員”一詞來表示
應用程序開發人員的常識。 用傳統的Java EE術語， 此角色在應用程序組件提供程序和應用程序之間分配 匯編器。”
此外，您還可以找到有關“保護”投資的強制性聲明：
Java EE 7的目標是增加對PaaS模型以及
SaaS模型的有限形式，同時盡可能保留
建立了Java EE編程模型，并進行了大量投資 由客戶，供應商和系統集成商集成到Java EE生態系統中。（來源： Java EE 7平臺和對PaaS模型的支持 ）
您很快就會看到Jerome Dochez的qcon London幻燈片 ，您會發現，與專家組在公開文檔中討論的內容相比，還有很多事情要處理：
–更好的云打包（模塊化應用程序）
–版本控制
–部署模型 – SLA監控 –帳單
而且我敢肯定，您可以提出更多建議。 由甲骨文Openword的Adam Leftik和John Clingan提出的GlassFish / Java EE戰略和路線圖 （PDF）通過查看以下內容對未來進行了更詳細的描述：
–動態服務供應
– Iaas管理
–使用自動縮放的彈性 –監控 –虛擬機管理程序抽象
到目前為止，這似乎是在云中使用Java EE的最完整，最具體的方法。 看到GlassFish團隊使用最新的GF 4.0發行候選者進行演示時，您可以想象到工作完成了多少。 （即使我認為仍有大量工作要做：）
沒有雨，但是會陰天
目前正在發生許多變化。 在成熟的規范中，隨著方向的改變，這是預期的。 通過相信新的Oracle云產品和GlassFish團隊正在進行的前沿工作，我相信可以實現宏偉的目標，因為我們有足夠的商業價值。 我擔心的是，單一規范可能會拒絕包含“需要的”云內容，以支持錯誤修復或社區要求。 這是傘式規范首次朝著完全不同于包含子項的方向發展。 另一方面，正如我們從過去所知，雨傘本身是一個可比較的小規格，它在非常一般的細節水平上進行規定。 一般而言，這可以為供應商帶來機會。 在此讓我補充一點：我堅信，Java EE 7自古以來對規范領導者將是最大的挑戰。 通常，遵循整個“云”主題而不分散或優先考慮單個包含的規范將是一項非常政治的工作。 即使Linda DeMichiel是Java EE的資深人士，我也相信很多工作正在這里等待。
2013年夏季與2012年第三季度最終發布–錯失良機
我在時間表上遇到的真正大問題是，我們沒有機會獲得用于應用程序打包的真正模塊化方法。 無論是針對云的打包（以及相關的東西，如版本控制，SLA等）設計什么，都將無法利用Java SE 8隨附的新項目Jingsaw功能。我個人認為，這是對Java的主要要求云的Java EE PaaS基礎架構。 如果新的云元數據將建立在Java EE 6打包規范的基礎上，那么就錯過了采用最新，最好的Java模塊化的機會。 我非常好奇地看到，EG將如何解決此問題，而無需再次使用Java EE 8進行所有工作。
參考：來自JCG合作伙伴 Markus Eisele的 Java EE過去，現在和Cloud 7 ，在“使用Java進行企業軟件開發”博客中 。
- 在云中開發和測試
- Java EE中的配置管理
- 泄漏：Oracle WebLogic Server 12g
- Java EE6裝飾器：在注入時裝飾類
- Java教程和Android教程列表
翻譯自: https://www.javacodegeeks.com/2011/10/java-ee-past-present-cloud-7.html
