_確保高效發展進程的建議_ 很久以前，J2EE，特別是應用程式伺服器被認為過於臃腫和“重量級”。對於開發人員來說，使用此技術開發應用程式會非常繁瑣且令人沮喪。但是，由於 J2EE 框架的名稱已更改為Java EE，因此該假設不再適用。 Java EE 與其他企業框架相比區別在哪以及框架 輕量級 的標 ...
確保高效發展進程的建議
很久以前，J2EE，特別是應用程式伺服器被認為過於臃腫和“重量級”。對於開發人員來說，使用此技術開發應用程式會非常繁瑣且令人沮喪。但是，由於 J2EE 框架的名稱已更改為Java EE，因此該假設不再適用。 Java EE 與其他企業框架相比區別在哪以及框架輕量級的標準是什麼？
在選擇技術時，需要考慮的最重要方面之一是開發人員在開發過程中的生產力。工程師應該花費儘可能多的時間來實現用例和創收功能，因為這將使公司朝著目標前進。
所選擇的技術和方法應該最大限度地縮短開發人員的時間。具體哪些時間呢:等待構建，測試和部署; 配置應用; 實施與業務用例無關的管道; 並配置構建環境和外部依賴項。 但是大多數可用技術都沒有這樣做。
1.為什麼標準?
與其他框架相比，Java EE 的最大優勢之一是使用的API的標準化。標準聽起來可能很無聊而且不夠創新 - 從本質上講，這是真的，因為Java規範請求（JSR）已經成為行業內過去已經過充分證明的結果。 但使用這些標準有幾個優點。
2.整合規範
Java EE中的特定API - 例如上下文和依賴註入（CDI），JAX-RS，JSON 處理（JSR 353）和 Bean驗證 - 可以很好地協同工作，並且可以無縫地相互組合。 最重要的是，CDI 被用作應用程式組件之間的“粘合劑”。 該規範包含諸如“如果容器支持規範 A 和 B，那麼 A 必須與 B 無縫集成並良好地工作。”
例如，JAX-RS 支持 JSONP 類型，例如JsonObject用作請求或響應實體，它支持調用Bean 校驗功能 - 如果驗證失敗，則包括正確的HTTP狀態代碼（參見清單1）。
@Path("duke")
public class DukeResource {
@GET
public JsonObject getDuke() {
return Json.createObjectBuilder().add("name", "Duke").build();
}
@POST
public void create(@Valid @NotPlayedYet Game game) {
// game object has been validated at this point
}
}清單1. JAX-RS的JSONP和Bean Validation集成
使用 JSONP 類型意味著內容類型將是 application / json，並且如果驗證失敗，將發送HTTP狀態代碼 400 Bad Request。 這無需編寫任何配置代碼就能使一切都完成。
另一個例子是 CDI 使開發人員能夠通過 @Inject 將任何 bean 和用戶定義的對象註入 Java EE托管組件。 請參閱清單2，瞭解一個 bean 驗證 Validator，它直接使用另一個 CDI 托管bean。
public class GameNotPlayedValidator implements ConstraintValidator<NotPlayedYet, Game> {
@Inject
GameHistory history;
public void initialize(NotPlayedYet constraint) {
// no initialization needed
}
public boolean isValid(Game game, ConstraintValidatorContext context) {
return !history.exists(game);
}
}清單2. bean 驗證的 CDI 集成
集成是規範的一個主要方面，可以提供直接的開發人員體驗。開發人員可以依賴應用程式伺服器進行集成和配置工作，從而可以專註於應用程式的業務邏輯。
3.按配置約定驅動開發
由於 Java EE 的配置約定驅動方法，大多數實際應用程式不需要大量配置。 繁瑣的 XML 描述符的日子結束了。 對於簡單的 Java EE 應用程式，您不需要單個 XML 文件。
由於聲明性註釋，一個簡單的帶註釋的普通舊 Java 對象（POJO）處理 HTTP 請求（@Path），或分別作為 Enterprise JavaBeans（EJB）bean（@ Stateless） - 包括事務，監視或攔截器。過去，這些方法已在各種框架中得到很好的證明，並已在 Java EE 中進行了標準化。
如果需要，XML 描述符仍可用於部署時配置，但是配置約定有助於最大限度地提高開發人員的工作效率。
4.外部依賴
少數實際企業項目在部署工件中沒有任何額外依賴項的情況下工作。 但這些依賴關係的理由主要是由技術驅動 - 例如包括日誌記錄或實體映射框架或 Apache Commons 或 Google Guava 等常用庫 - 而不是用例。
Java EE 7 - 尤其是與 Java 8 一起使用時 - 具有足夠的功能來覆蓋大多數用例而沒有任何其他依賴性。開箱即用的內容大部分都可以用最少量的代碼來實現，例如，通過 CDI 提供商的可註入配置，通過攔截器的斷路器（查看 Adam Bien 的開源庫），或通過複雜的收集操作 Java 8 lambda 表達式和流。
當然，你可以爭辯說不要在這裡重新發明輪子。 但實際上，為了節省一些自編寫的代碼行，將兆位元組的外部依賴項包含在部署工件中並沒有多大意義。
經驗表明，最大的問題不是直接引入的依賴，而是傳遞的依賴。傳遞的依賴經常與應用程式伺服器上已有的庫版本衝突，並導致具有挑戰性的衝突。在一天的工作時間內，開發人員要花費更多時間來管理這些衝突，而不是聚焦在將小功能實現到項目中所需的時間。這主要適用於具有技術驅動而非用例驅動的依賴關係的情況。
有關簡單的 Java EE 7 項目Maven項目對象模型（POM）的文件啟發，請參閱清單 3，該文檔受Adam Bien的啟發 Java EE 7 Essentials Archetype.
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sebastian-daschner</groupId>
<artifactId>game-of-duke</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>game-of-duke</finalName>
</build>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>清單3. Java EE 7 Maven POM 文件
當然，有時應用程式確實需要集成對於實現軟體目標至關重要的庫。但是，這些依賴關係需要通過業務需求來證明。一般來說，它很有意義，可以節省時間和精力來最小化外部生產庫。
對於測試依賴關係，這是一個不同的故事，因為庫，例如JUnit，Mockito或者在某些情況下，Arquillian - 是至關重要的。 但同樣，關註測試依賴項列表也是有意義的。
5.精簡部署 Artifacts
由於應用程式伺服器知道Java EE API，因此該API不必包含在部署 artifact 中。 只包含業務邏輯 - 只需最少的膠水代碼和交叉關註點。
因此，這些千位元組大小的工件可以使構建時間非常短，因為構建過程不需要複製很多東西。這可以在每個構建上產生幾秒鐘的差異。 如果總結開發人員和持續集成（CI）伺服器所花費的所有額外時間，那就會產生很大的不同。項目建設的頻率越高 - 對於持續交付（CD）情景尤其如此 - 影響越大。
除了較短的構建時間外，小型部署 artifacts 還可確保較短的發佈和部署時間。 由於實現已經包含在運行時中，所以在所有情況下，移動部件花費的時間都是最小的。
6.Docker的理想框架
這正是Java EE成為Docker等容器技術的完美框架的原因。Docker 鏡像基於圖層，構建圖像時，基本圖像已包含操作系統，Java運行時和應用程式。因此，在每個構建中添加的唯一內容是部署工件的最後一個千位元組薄層。與胖WAR或獨立JAR方法相比，這節省了時間和存儲 - 不僅在每個構建上，而且在圖像版本化或發佈版本時 。
無論在哪個階段，擁有精簡的部署 artifacts 都可以實現非常快速和高效的部署管道。
7.現代應用伺服器
J2EE 應用程式伺服器是重量級軟體在啟動和部署時間，安裝大小和資源占用空間方面的體現。 但是在 Java EE 的新世界中，這已不再適用。
所有現代Java EE 7應用程式伺服器（如WildFly，Payara，WebSphere Liberty，Profile和TomEE）都可在幾秒鐘內啟動和部署。由於內部，全面的模塊化，他們只能載入所需的組件並儘快部署精簡的應用程式 artifacts。
現在的安裝尺寸和占地面積非常合理。 應用程式伺服器不會消耗比簡單的 servlet 容器更多的東西，但它具有完整的 Java EE 功能。 有趣的是，現在運行的瀏覽器實例消耗更多記憶體。
話雖如此，每個伺服器只部署一個應用程式是可能的，也可以是合理的 - 無論是在容器中還是在內部。 通過“每個容器每個應用程式伺服器一個應用程式”方法，您可以為現代微服務架構提供高效且靈活的解決方案。
8.打包
在打包過程中，不應該繼續使用EAR文件了。將整個應用程式部署在獨立的專門的伺服器上，要求我們在那個環境中必須可以訪問所有的組件方法，這樣做可以節省更多的構建和部署時間。除此之外，這還避免了EAR文件傾向於導致的類載入層次結構問題。
在大多數雲和微服務部署中，使用獨立的JAR包。 它們包含應用程式和運行時實現。 在Java EE領域，這種方法可以使用特定於供應商的工具鏈來實現，例如 WildFly Swarm，Payara Micro 或TomEE Embedded。
但是，由於上述原因，我強烈建議儘可能將業務邏輯與運行時分開。 這意味著將應用程式打包在僅包含應用程式代碼的WAR文件中。
在我看來，如果由於公司“政治”問題而不是技術原因而無法控制安裝或操作流程，則獨立 JAR 文件是一種有用的解決方法。 然後運送部署工件中所需的所有內容並且只需要 JRE 時可以解決相當多的非技術問題。
9.關於高效研發進程的建議
企業項目最有效的解決方案之一如下：
- 僅在提供 API 時使用 Java EE 7 和 Java 8
- 構建一個千位元組大小的 WAR 文件，其中僅包含業務邏輯和最小管道（例如 JAX-RS 資源或JPA）
- 構建 Docker 鏡像 - 僅將 WAR 文件添加到包含已配置的應用程式伺服器的基礎鏡像
- 通過使用容器部署應用程式的 CD 管道進行傳送
10.結論
“重量級 Java EE”的日子肯定結束了。 Java EE 中包含的 API 提供了高效且愉快的開發人員體驗以及標準內的無縫集成。 特別是，將應用程式代碼與運行時分離的方法可實現快速，高效的開發過程。
通過由多個供應商發起的新MicroProfile計劃，將來可能會進一步縮小Java EE所需的組件。
參考資料
- Java EE 7 Essentials Archetype
- 博客文章: "Stop saying 'heavyweight'"
- Java EE circuit breaker implementation
原文：https://community.oracle.com/docs/DOC-1008823
作者：Sebastian Daschner
譯者：[KeepGoingPawn](https://blog.csdn.net/hengji666
9月福利，關註公眾號
後臺回覆：004，領取8月翻譯集錦!
往期福利回覆：001，002, 003即可領取！
