Đồng nghiệp của tôi nói với tôi rằng sử dụng EJB địa phương không phải là ý tưởng tốt
tôi phản đối kịch liệt với điều đó. EJB địa phương là rất ý tưởng hay vì chúng là loại hạt hoàn hảo để triển khai logic nghiệp vụ của bạn. Vụ mùa hiện tại của đậu EJB có trọng lượng rất nhẹ nên bạn không phải tránh chúng vì bất kỳ trọng lượng nào được cho là nặng.
Lợi thế lớn nhất của các loại hạt này có lẽ là quản lý giao dịch tự động của chúng, sẽ được sử dụng rất nhiều khi thực hiện bất kỳ loại công việc cơ sở dữ liệu nào.
Nó không chỉ là về các ứng dụng doanh nghiệp cần truy cập vào hàng đợi JMS và các hệ thống EIS phức tạp. Bất kỳ ứng dụng web nào cũng thực hiện nhiều hơn một lần ghi vào cơ sở dữ liệu tại một thời điểm rất nhiều lợi ích từ việc này. Nếu không có giao dịch, bạn sẽ kết thúc bằng cách nói rằng User chỉ còn nửa chừng trong cơ sở dữ liệu bất cứ khi nào ngoại lệ hoặc sự cố xảy ra. Và nếu không có EJB, bạn sẽ phải xả mã của mình bằng các câu lệnh start\commit\rollback rất chi tiết, hãy để một mình truyền bá giao dịch của bạn (thường thông qua 'Kết nối') vào tất cả mã của bạn và có trường hợp riêng biệt khi giao dịch đang hoạt động hoặc không hoạt động .
Với hạt đậu EJB, tất cả sự phức tạp đó sẽ biến mất. Nó giống như bộ sưu tập rác và quản lý bộ nhớ thủ công.
Có rất nhiều tính năng thú vị khác mà ngay cả những ứng dụng web đơn giản nhất có thể sử dụng, như kiểm tra vai trò khai báo (@RolesAllowed), gộp nhóm đậu (để điều tiết thông lượng, trong số những thứ khác) và an toàn chỉ.
Trong Java EE 6, chúng trở nên dễ sử dụng hơn cho các ứng dụng web đơn giản, và ở đó chúng có thể xuất hiện ở mọi nơi trong một .war (không có .jar và ô riêng biệt .ear cần nữa).
Vì vậy, tôi bối rối: khi nào sử dụng GWT Servlet (thuận tiện hơn HTTPServlet đơn giản, nó cung cấp lời gọi phương thức kiểu RPC) và khi nào sử dụng EJB?
Bây giờ chúng ta đang nói về từ xa EJB. Trong trường hợp này câu trả lời là khác nhau.
Nếu khách hàng đang kết nối từ Internet, bạn hầu như không bao giờ sử dụng EJB từ xa. Có một số lượng lớn các cổng thường cần phải mở, bao gồm các cổng trên máy khách. Tương tự như vậy, nếu bạn có các máy khách không đồng nhất (.NET, C++, và thậm chí cả các máy khách Java đang chạy một phiên bản khác của AS mà EJB từ xa sử dụng), bạn thường sẽ không sử dụng các EJB từ xa. Quay lại đầu trang Cung cấp Phản hồi THÔNG TIN THÊM
Mặc dù về mặt lý thuyết hỗ trợ Corba (IIOP) và do đó cho phép các loại máy khách khác nhau, trong thực tế giao tiếp EJB từ xa chỉ hoạt động nếu cả máy khách và máy chủ đang chạy Java và ngoại trừ AS (Máy chủ ứng dụng) hoặc một trong số đó là một máy khách Java SE với các thư viện máy khách cho máy chủ từ xa (có thể là lớn).
Hơi khó xử lý đối với công nghệ truy cập từ xa, nhưng thông số EJB thậm chí không chỉ định cách thiết lập kết nối từ xa ngay từ đầu. Tiêu chuẩn thực tế là JNDI từ xa, nhưng vì đây không phải là đặc tả, JBoss ví dụ muốn ngừng hỗ trợ điều này trong JBoss AS 7.
Trong tất cả các trường hợp đó, bạn sẽ sử dụng công nghệ Web Service thay vì EJB từ xa. GWT Servlet có thể là một lựa chọn, nhưng không thực sự là một ví dụ kinh điển ở đây. Trừ khi bạn đã sử dụng GWT, tôi sẽ không khuyên bạn nên cài đặt nó chỉ cho kết nối web/rpc chung từ các máy khách tùy ý (không phải GWT).
Các giải pháp chung về Java là JAX-WS và JAX-RS, là triển khai thực hiện REST SOAP REST (cả hai có thể được kết hợp với EJB btw). Triển khai JAX-RS nổi tiếng là Jersey (example) và RestEasy. Trong Java EE 6 bạn không phải cài đặt bất cứ thứ gì cho chúng, vì chúng đã là một phần của nền tảng này. Đối với Java EE 5, bạn phải cài đặt riêng JAX-RS, nhưng JAX-WS đã có sẵn.
Mọi người thường thấy JAX-RS dễ dàng bắt đầu và cách tiếp cận hiện đại hơn, mặc dù JAX-WS có nhiều tính năng an toàn hơn (cũng chính là nơi phần lớn sự phức tạp của nó xuất phát).
Cuối cùng, khi làm chúng tôi sử dụng EJB từ xa? Thông thường, bạn sẽ làm điều này để liên lạc giữa các ứng dụng trên mạng cục bộ đang chạy AS giống nhau. Trong trường hợp đó, có lợi thế hiệu suất tiềm năng (serialization nhị phân có thể nhanh hơn so với chuyển đổi json/xml do đó và ra) và có một số tùy chọn mạnh mẽ để tuyên truyền một bối cảnh an ninh và điều phối một giao dịch phân tán. Các ứng dụng web đơn giản rất có thể sẽ không yêu cầu tính năng cuối cùng thường xuyên nếu có.
Mẫu thường thấy là của một tài nguyên JAX-RS (bean) chấp nhận yêu cầu từ khách hàng từ xa (web), và sau đó giao công việc cho một EJB cục bộ có chứa logic nghiệp vụ thực tế.
[Điều này có thể hữu ích] (http://stackoverflow.com/questions/2013793/web-services-vs-ejb-vs-rmi-advantages-and-disadvantages). – betomontejo