Đóng gói EJB trong JavaEE 6 WAR so với EAR

Question

Bắt đầu một dự án mới và muốn biết những ưu và nhược điểm của việc đóng gói EJB trong WAR so với EAR.

JNDI vẫn hoạt động khi EJB ở trong WAR không? hiệu quả? v.v.

Cảm ơn.

Answer 1

Một động lực quan trọng để có hạt EJB trong một JAR riêng biệt là để tách tuổi cũ logic nghiệp vụ và xem logic.

Vì EJB chỉ tập trung vào logic nghiệp vụ, nên đặt chúng vào một mô-đun riêng biệt.

Đây chính là điều mà Java Enterprise Archive truyền thống tạo điều kiện thuận lợi. Các hạt EJB đi vào một tệp JAR đại diện cho EJB module, trong khi các tạo phẩm liên quan đến web (Facelets, bean sao lưu, mã tiện ích) đi vào tệp Lưu trữ Web (WAR) đại diện cho Web module. Lưu ý rằng một WAR không thực sự phải là một tệp. Trong cái gọi là định dạng bùng nổ, chúng chỉ là các thư mục.

Một khía cạnh quan trọng của sự tách biệt này là hai mô-đun đó là bị cô lập thông qua phân cấp trình nạp lớp. Web module có quyền truy cập vào tài nguyên (thường là đậu) từ EJB module và EJB module có thể tham chiếu tài nguyên (thường là thư viện) được xác định trong ô EAR tổng thể. Một hướng khác là không thể. Cụ thể, EJB module không thể truy cập bất kỳ tài nguyên nào được xác định trong Web module.

Việc thực thi này có chủ ý.

Logic nghiệp vụ phải hoàn toàn độc lập với mọi công nghệ chế độ xem. Việc thực hiện cách ly này ngăn cản các nhà phát triển vô tình hoặc khi áp lực trộn lẫn những mối quan ngại đó. Những lợi ích của việc tách biệt này là logic nghiệp vụ có thể được sử dụng bởi các khách hàng Java SE, các khách hàng mô-đun Web, các máy khách JAX-RS, v.v. Nếu logic nghiệp vụ vô tình có các phụ thuộc JSF hoặc Servlet, sẽ rất khó để sử dụng nó từ các máy khách Java SE.

So sánh điều này với Facelets không cho phép sử dụng tập lệnh. Điều này giữ cho Facelets sạch sẽ và để chúng tập trung vào bố cục thành phần và đánh dấu độc quyền. Một sự tương tự khác là mã hóa với các giao diện, tách riêng hợp đồng khỏi việc thực hiện.

Vì vậy, có một mô-đun EJB riêng biệt thực sự là thực hành tốt nhất. Tuy nhiên ...

Đối với các dự án nhỏ hơn có thể là không cần thiết để có sự tách biệt này và để bắt đầu lập trình, có thể khó khăn để quấn đầu của họ xung quanh cấu trúc của những gì cần phải đi đâu.Loại bỏ sự tách biệt bắt buộc do đó làm cho nó dễ dàng hơn cho các nhà phát triển thiếu kinh nghiệm để bắt đầu với Java EE. Nó cung cấp cho họ một giới thiệu nhẹ nhàng vào Java EE và sau đó một khi họ nhận được ý tưởng về phân lớp, sau đó họ có thể chọn để giới thiệu một EJB module anyway.

Answer 2

tôi nghĩ rằng những gì bạn cần lưu ý là EJB bên trong WAR là một phần của EJB Lite, đó là một nỗ lực tốt để làm cho một ứng dụng chạy với các dịch vụ tối thiểu được cung cấp bởi một container EJB. Bởi vì bạn không phải lúc nào cũng cần tất cả các dịch vụ được cung cấp bởi một container EJB.

Vì vậy, nếu bạn băn khoăn về ưu và khuyết điểm của việc đóng gói EJB trong WAR hoặc trong EAR, thì bạn nên suy nghĩ về số lượng dịch vụ bạn cần.

HTH.

Answer 3

Cho đến nay đây là những gì tôi nhận được.

EJB trong WAR

ưu:

1. đơn giản để phát triển và triển khai

2. Bạn có thể tiếp xúc với phương pháp Session Bean như dịch vụ REST với @Path chú thích. Xem here

khuyết điểm:

1. tra cứu JNDI không được hỗ trợ, vì vậy tôi tin rằng bạn không thể làm RMI từ một khách hàng ứng dụng

2. Như Arjan chỉ ra nó thiếu mô đun trong thiết kế.

Answer 4

Tôi hiện đang nghiên cứu một số hướng dẫn để chứng nhận EJB 3.1 và phải kiểm tra mọi tính năng của nó. Và tất cả đều có sẵn khi sử dụng chiến tranh.

Nó rất khác EJB Lite từ bao bì WAR.

Bạn có thể có một số mô đun lôgic bằng cách sử dụng các lọ ejb mà bạn có thể đưa vào dự án web của mình. Nhưng tất cả các mô-đun chia sẻ cùng một môi trường (jndi) để một số xung đột tên có thể xảy ra. Trong một dự án EAR, mỗi module có một không gian tên riêng.

Answer 5

Tôi đã thực hiện một số thử nghiệm về chủ đề này và thực sự ngạc nhiên về kết quả. Kết luận của tôi không bao giờ sử dụng EJB trong WAR. Hãy để công việc cho container EJB vì vậy nếu ai muốn sử dụng EAR để phát triển EAR tốt nhất và không bị lỗi.

Khi tôi làm việc EJB trong WAR bằng NetBeans 7.1.3, Glassfish 3.1.2.2 và JRebel để phát triển nhanh hơn, tôi đã nhận ra rằng JRebel chỉ hoạt động hoàn hảo với việc tải lại các thay đổi trong EJB modul nếu nó được triển khai trong gói EAR. Nếu tôi thực hiện gói WAR đơn giản, trình nạp lớp hoạt động theo cách hoàn toàn lạ trong giai đoạn phát triển và gây ra rất nhiều lỗi ngẫu nhiên.

Nhưng dù sao gói chiến dịch trong triển khai bình thường hoạt động hoàn hảo như mentiod bởi những người khác.

Cũng trong gói WAR, các thay đổi trong chuỗi NamedQuery không xuất hiện sau khi lưu và biên dịch. Nếu tôi đóng gói vào EAR, sự phát triển rất trơn tru và nhanh chóng. Tất nhiên điều này có thể là một lỗi cũng trong JRebel.