Java EE thực sự là gì? [đóng cửa]

Java EE có "tấm vải che bí ẩn" xung quanh nó đối với các nhà phát triển Java trẻ tuổi - một điều mà tôi đã cố gắng nâng cao bản thân mình trong một thời gian nhưng không thành công.

Sự nhầm lẫn phát sinh từ:

• Java EE dường như vừa là thư viện vừa là nền tảng - có nhiều cách để "lấy" thư viện Java EE, điển hình là từ cách tải xuống Java EE SDK của Oracle. Tuy nhiên, thư viện Java EE sẽ không hoạt động, cũng như không biên dịch trừ khi mã của bạn đang được chạy hoặc có quyền truy cập vào máy chủ ứng dụng Java EE (chẳng hạn như JBoss, GlassFish, Tomcat, v.v.). Tại sao? Các thư viện không thể hoạt động bên ngoài môi trường máy chủ ứng dụng? Tại sao tôi cần thứ gì đó lớn như JBoss chỉ để biên dịch mã đơn giản để gửi email?

• Tại sao các thư viện Java EE không phải là "chuẩn" và được bao gồm trong bản tải xuống JVM thông thường và / hoặc SDK?

• Tại sao có rất nhiều dịch vụ Java EE khi thực sự chỉ có hai phiên bản chính của Java tiêu chuẩn (Oracle JVM / SDK | OpenJDK JVM / JDK)?

• Người ta có thể làm gì với Java EE mà họ không thể làm với Java tiêu chuẩn?

• Người ta có thể làm gì với Java tiêu chuẩn mà họ không thể làm với Java EE?

• Khi nào một nhà phát triển quyết định họ "cần" Java EE?

• Khi nào nhà phát triển quyết định họ không cần Java EE?

• Tại sao phiên bản thư viện Java EE không đồng bộ với các bản phát hành thư viện Java tiêu chuẩn (Java EE 6 so với Java 7)?

Cảm ơn vì đã giúp tôi xóa sổ!

Tại sao các thư viện không thể hoạt động bên ngoài môi trường máy chủ ứng dụng?

Trên thực tế họ có thể. Hầu hết các thư viện có thể được sử dụng trực tiếp độc lập (trong Java SE) hoặc được đưa vào .war (thực tế gần như luôn luôn là Tomcat). Một số phần của Java EE, như JPA, có các phần rõ ràng trong các thông số kỹ thuật tương ứng của chúng cho biết chúng nên hoạt động và được sử dụng như thế nào trong Java SE.

Nếu có bất cứ điều gì, đó không phải là môi trường máy chủ ứng dụng đang bị đe dọa ở đây, mà là sự hiện diện của tất cả các thư viện khác và mã tích hợp hợp nhất chúng.

Do đó, các chú thích sẽ chỉ được quét một lần cho tất cả các lớp của bạn thay vì mọi thư viện (EJB, JPA, v.v.) tự quét đi quét lại. Cũng do đó, các chú thích CDI có thể được áp dụng cho các bean EJB và các trình quản lý thực thể JPA có thể được đưa vào chúng.

Tại sao tôi cần thứ gì đó lớn như JBoss chỉ để biên dịch mã đơn giản để gửi email?

Có một số điều sai với câu hỏi này:

1. Để biên dịch, bạn chỉ cần API jar, dưới 1MB cho Hồ sơ web và hơn 1MB một chút cho hồ sơ đầy đủ.
2. Để chạy, bạn rõ ràng cần một bản triển khai, nhưng "đồ sộ" đang phóng đại mọi thứ. Ví dụ, OpenJDK có dung lượng khoảng 75MB và TomEE (một triển khai Hồ sơ web có hỗ trợ thư) chỉ là 25MB. Ngay cả GlassFish (triển khai Hồ sơ đầy đủ) cũng chỉ có 53MB.
3. Mail hoạt động hoàn toàn tốt từ Java SE (và do đó là Tomcat) cũng như sử dụng mail.jar và activation.jar độc lập .

Tại sao các thư viện Java EE không phải là "chuẩn" và được bao gồm trong bản tải xuống JVM thông thường và / hoặc SDK?

Theo một cách nào đó, Java EE là một trong những nỗ lực đầu tiên nhằm chia nhỏ JDK vốn đã khổng lồ thành nhiều phần để dễ quản lý và tải xuống hơn. Mọi người đã phàn nàn rằng các lớp đồ họa (AWT, Swing) và Applet nằm bên trong JRE khi tất cả những gì chúng làm là chạy một số lệnh trên máy chủ không đầu. Và sau đó bạn cũng muốn bao gồm tất cả các thư viện Java EE trong JDK tiêu chuẩn?

Với việc cuối cùng phát hành hỗ trợ mô-đun, chúng tôi sẽ chỉ có một JRE cơ sở nhỏ với nhiều thứ có thể cài đặt riêng biệt dưới dạng gói. Có lẽ một ngày nào đó nhiều hoặc thậm chí tất cả các lớp tạo nên Java EE cũng sẽ là gói như vậy. Thời gian sẽ trả lời.

Tại sao có rất nhiều dịch vụ Java EE khi thực sự chỉ có hai phiên bản chính của Java tiêu chuẩn (Oracle JVM / SDK | OpenJDK JVM / JDK)?

Có nhiều hơn hai phiên bản Java SE. Ít nhất có IBM JDK, BEA trước đây (JRocket, đang được hợp nhất thành Oracle / Sun vì mua lại), nhiều triển khai mã nguồn mở khác và một loạt các triển khai để sử dụng nhúng.

Lý do đằng sau Java SE và EE là một đặc tả là nhiều nhà cung cấp và tổ chức có thể triển khai nó và do đó nó khuyến khích sự cạnh tranh và giảm thiểu rủi ro bị nhà cung cấp khóa.

Nó thực sự không khác gì với các trình biên dịch C và C ++, nơi bạn có nhiều dịch vụ cạnh tranh cũng như tất cả đều tuân thủ tiêu chuẩn C ++.

Tại sao phiên bản thư viện Java EE không đồng bộ với các bản phát hành thư viện Java tiêu chuẩn (Java EE 6 so với Java 7)

Java EE được xây dựng trên Java SE, vì vậy nó bị tụt hậu. Các phiên bản tương ứng với nhau. Java EE 5 yêu cầu Java SE 5. Java EE 6 yêu cầu Java SE 6, v.v. Chỉ là hầu hết khi Java SE X hiện tại, Java EE X-1 là hiện tại.

Dưới đây là một số câu trả lời được soạn nhanh cho các câu hỏi của bạn ...

• Tại sao các thư viện JavaEE không thể hoạt động mà không có máy chủ ứng dụng? Các dịch vụ được cung cấp bởi JavaEE (giao dịch được quản lý vùng chứa, tiêm phụ thuộc được quản lý vùng chứa, dịch vụ hẹn giờ, v.v.) vốn có liên quan đến Máy chủ ứng dụng tuân thủ JavaEE (ví dụ: GlassFish, JBoss, WebSphere, v.v.). Do đó, các thư viện JavaEE không phục vụ mục đích nào nếu không có một vùng chứa như vậy. " Tại sao tôi cần một thứ gì đó khổng lồ như JBoss chỉ để biên dịch mã đơn giản để gửi email? " Có nhiều cách để gửi email mà không cần JavaEE ... Nhưng nếu bạn muốn thực hiện theo cách JavaEE, bạn cần một vùng chứa JavaEE.

• Tại sao các thư viện JavaEE không được bao gồm trong tải xuống JavaSE? Lý do tương tự mà nhiều thư viện không được đưa vào: nó sẽ quá mức cần thiết. Vì bạn thậm chí không thể sử dụng các thư viện JavaEE mà không có máy chủ ứng dụng, tại sao phải đưa chúng vào? JavaEE nên được tải xuống nếu và khi một nhà phát triển cài đặt một máy chủ ứng dụng và quyết định sử dụng JavaEE.

• Tại sao có rất nhiều dịch vụ JavaEE? Có thực sự " rất nhiều " dịch vụ JavaEE không? Nếu vậy, hãy liệt kê một số trong số chúng. Chính xác hơn, tôi tin rằng có nhiều cách triển khai của các API giống nhau .

• Người ta có thể làm gì với JavaEE mà họ không thể làm được nếu không có Java chuẩn? Rất nhiều. Bạn không thể dựa vào máy chủ ứng dụng để quản lý các giao dịch hoặc ngữ cảnh liên tục mà không có JavaEE. Bạn không thể cho phép máy chủ ứng dụng quản lý việc tiêm phụ thuộc EJB mà không có JavaEE. Bạn không thể sử dụng dịch vụ hẹn giờ do ứng dụng quản lý mà không có JavaEE. Câu trả lời cho câu hỏi này nên làm cho câu trả lời cho câu hỏi đầu tiên khá rõ ràng ... Hầu hết các dịch vụ được cung cấp bởi JavaEE đều yêu cầu một vùng chứa JavaEE.

• Bạn có thể làm gì với JavaSE mà bạn không thể làm với JavaEE? Ừm ... tôi không biết.

• Khi nào nhà phát triển quyết định họ cần JavaEE? Câu hỏi này hoàn toàn mang tính chủ quan ... Nhưng nếu bạn cần bất kỳ dịch vụ nào được cung cấp bởi JavaEE, bạn bắt đầu nghĩ về nó. Nếu bạn không biết JavaEE là gì ... có thể bạn không cần nó.

• Khi nào nhà phát triển quyết định họ không cần JavaEE? Xem câu trả lời trước.

• Tại sao phiên bản thư viện JavaEE không đồng bộ với phiên bản JavaSE? Câu hỏi hay. Tôi sẽ không giả vờ biết cách trả lời nó ... Nhưng tôi sẽ đoán câu trả lời là: "bởi vì chúng không đồng bộ".

Theo quan điểm của con mắt, Java EE là một nền tảng, tức là thứ mà chúng ta có thể xây dựng trên đó.

Dưới góc độ kỹ thuật hơn, tiêu chuẩn Java Enterprise Edition xác định một tập hợp các API thường được sử dụng để xây dựng các ứng dụng doanh nghiệp. Các API này được triển khai bởi các máy chủ ứng dụng - và vâng, các máy chủ ứng dụng khác nhau có quyền sử dụng các cách triển khai khác nhau của các API Java EE.

Tuy nhiên, thư viện java ee sẽ không hoạt động, cũng không biên dịch trừ khi mã của bạn đang được chạy trên hoặc có quyền truy cập vào máy chủ ứng dụng Java EE (chẳng hạn như JBoss, GlassFish, Tomcat, v.v.).

Bạn biên dịch dựa trên các API Java EE, vì vậy bạn chỉ cần các API đó tại thời điểm biên dịch. Trong thời gian chạy, bạn cũng sẽ cần triển khai các API này, tức là một máy chủ ứng dụng.

Tại sao tôi cần thứ gì đó lớn như JBoss chỉ để biên dịch mã đơn giản để gửi email?

Bạn không. Tuy nhiên, nếu bạn muốn sử dụng Java EE API để gửi thư, bạn sẽ cần triển khai API đó trong thời gian chạy. Điều này có thể được cung cấp bởi một máy chủ ứng dụng hoặc được cung cấp bởi một thư viện độc lập mà bạn thêm vào classpath của mình.

Tại sao các thư viện Java EE không phải là "chuẩn" và được bao gồm trong bản tải xuống JVM thông thường và / hoặc SDK?

Bởi vì chỉ có các API được chuẩn hóa, không phải các triển khai.

Tại sao có rất nhiều dịch vụ Java EE

Bởi vì mọi người không đồng ý về cách phù hợp để triển khai các tính năng nhất định. Bởi vì các nhà cung cấp khác nhau cạnh tranh để giành thị phần.

Người ta có thể làm gì với Java EE mà họ không thể làm với Java tiêu chuẩn?

Vì các triển khai Java EE được xây dựng bằng "Java tiêu chuẩn": Không có gì. Tuy nhiên, việc tận dụng các thư viện hiện có có thể tiết kiệm rất nhiều công sức nếu bạn đang giải quyết các vấn đề doanh nghiệp điển hình và việc sử dụng một API được chuẩn hóa có thể ngăn chặn việc khóa nhà cung cấp.

Người ta có thể làm gì với Java tiêu chuẩn mà họ không thể làm với Java EE?

Không có gì, vì Java EE bao gồm Java SE.

Khi nào một nhà phát triển quyết định họ "cần" Java EE? Khi nào nhà phát triển quyết định họ không cần Java EE?

Nói chung, các API Java EE giải quyết các vấn đề điển hình, lặp đi lặp lại trong điện toán doanh nghiệp. Nếu bạn gặp những vấn đề như vậy, thường là hợp lý khi sử dụng các giải pháp tiêu chuẩn - nhưng nếu bạn gặp các vấn đề khác nhau, các giải pháp khác nhau có thể được yêu cầu. Ví dụ, nếu bạn cần nói chuyện với cơ sở dữ liệu quan hệ, bạn nên cân nhắc sử dụng JPA. Nhưng nếu bạn không cần cơ sở dữ liệu quan hệ, JPA sẽ không giúp bạn.

Java EE là gì?

Hãy bắt đầu từ định nghĩa kinh điển tại wiki:

Java Platform, Enterprise Edition hoặc Java EE là nền tảng điện toán Java doanh nghiệp của Oracle. Nền tảng này cung cấp môi trường API và thời gian chạy để phát triển và chạy phần mềm doanh nghiệp, bao gồm các dịch vụ mạng và web cũng như các ứng dụng mạng quy mô lớn, nhiều tầng, có thể mở rộng, đáng tin cậy và an toàn khác.

Điểm chính ở đây là Java EE là một nền tảng cung cấp một API, không phải một số thư viện cụ thể.

Đối với Java EE cần những gì?

Phạm vi chính của Java EE là các ứng dụng dựa trên mạng, không giống như Java SE được định hướng phát triển các ứng dụng máy tính để bàn với sự hỗ trợ mạng đơn giản. Đây là điểm khác biệt chính giữa chúng. Khả năng mở rộng, nhắn tin, giao dịch, hỗ trợ DB cho mọi ứng dụng ... nhu cầu về tất cả những điều này đã tăng lên cùng với sự phát triển của mạng. Tất nhiên rất nhiều giải pháp sẵn sàng mà Java SE cung cấp rất hữu ích cho việc phát triển mạng, vì vậy Java EE mở rộng Java SE.

Tại sao chúng ta cần máy chủ ứng dụng để chạy mã của mình?

Tại sao chúng ta cần hệ thống vận hành? Bởi vì có rất nhiều công việc khó khăn với phần cứng, chúng tôi cần phải làm để tạo ra ứng dụng đơn giản nhất. Và nếu không có hệ điều hành, bạn cần phải làm lại nhiều lần. Oversimplified OS chỉ là một vùng chứa có lập trình, cung cấp cho chúng ta bối cảnh chung để chạy các ứng dụng của mình.

Và đây là những gì các máy chủ ứng dụng là. Chúng cho phép chúng tôi chạy các ứng dụng của mình trong ngữ cảnh của chúng và cung cấp cho chúng tôi rất nhiều chức năng cấp cao cần thiết cho các ứng dụng mạng tải trọng cao của doanh nghiệp. Và chúng tôi không muốn viết xe đạp của riêng mình để giải quyết vấn đề này, chúng tôi muốn viết mã để đáp ứng nhu cầu kinh doanh của chúng tôi.

Một ví dụ khác ở đây có thể là JVM cho Java.

Tại sao Java EE không chứa máy chủ ứng dụng tích hợp?

Khó để nói cho tôi. Tôi nghĩ, nó đã được thực hiện để linh hoạt hơn. Java EE cho biết họ nên làm gì, họ quyết định cách thực hiện.

Tại sao JVM không bao gồm Java EE?

Vì họ đã hướng đến các lĩnh vực thị trường khác nhau. Java EE có một loạt các chức năng không cần cho các máy tính để bàn thông thường.

Tại sao có rất nhiều dịch vụ Java EE?

Bởi vì Java EE chỉ mô tả hành vi. Mọi người đều có thể thực hiện nó.

Người ta có thể làm gì với Java EE mà họ không thể làm với Java SE?

Để chinh phục internet. Nó thực sự khó làm với các ứng dụng và ổ cắm Java SE :)

Người ta có thể làm gì với Java SE mà họ không thể làm với Java EE?

Như đã đề cập ở trên Java EE mở rộng Java SE, vì vậy với Java EE, bạn sẽ có thể làm mọi thứ có sẵn cho Java SE.

Khi nào một nhà phát triển quyết định họ "cần" Java EE?

Khi họ cần sức mạnh của Java EE. Tất cả những gì được đề cập ở trên.

Khi nào nhà phát triển quyết định họ không cần Java EE?

Khi họ viết một bảng điều khiển hoặc ứng dụng máy tính để bàn thông thường.

Tại sao các phiên bản của Java SE và Java EE không được đồng bộ hóa?

Java luôn gặp rắc rối với việc đặt tên và lập phiên bản cho công nghệ của nó. Vì vậy, tình huống này không phải là một ngoại lệ.

Java EE là tất cả về khái niệm vùng chứa. Vì vậy, để tận dụng lợi thế của Java EE, bạn cần chạy ứng dụng của mình bên trong một vùng chứa. Hai cái chính là EJB và thùng chứa servlet đều có mặt trên bất kỳ máy chủ ứng dụng Java EE nào được chứng nhận.
Vùng chứa là một ngữ cảnh thực thi trong đó sẽ chạy ứng dụng của bạn và cung cấp tập hợp dịch vụ cuối cùng này. Mỗi loại dịch vụ được xác định bởi một đặc tả có tên JSR. Ví dụ JSR 907, JTA (java giao dịch Api) cung cấp một cách tiêu chuẩn để quản lý giao dịch phân tán dựa trên các tài nguyên khác nhau.
Nhìn chung, có nhiều cách triển khai khác nhau cho một JSR nhất định, việc triển khai bạn sẽ sử dụng tùy thuộc vào nhà cung cấp vùng chứa, nhưng bạn không thực sự bận tâm về điều đó vì bạn chắc chắn rằng hành vi tôn trọng hợp đồng được xác định trước: API JSR.

Mục đích của tất cả những điều này là xác định một môi trường thực thi tiêu chuẩn để cho phép đóng gói ứng dụng của bạn chỉ với những thứ cần thiết, id.est. Kinh doanh của bạn. Nó tránh phụ thuộc vào một bộ thư viện bên thứ ba không xác định và khác nhau mà bạn sẽ phải đóng gói và cung cấp cho ứng dụng của mình nếu không, và đó có thể là nguồn xung đột với các ứng dụng khác trên máy chủ. Trong Java EE, bạn biết rằng tất cả các yêu cầu phi chức năng tiêu chuẩn như bảo mật, giao dịch, khả năng mở rộng, lệnh gọi từ xa và nhiều yêu cầu khác sẽ được cung cấp bởi vùng chứa (được phân tích nhân tố cho tất cả các ứng dụng chạy bên trong nó) và bạn chỉ cần căn cứ vào công việc của mình.