Máy chủ web của tôi sẽ bị quá tải nhanh chóng nếu tất cả công việc được thực hiện tại đó. Tôi sẽ đứng lên một máy chủ thứ hai đằng sau nó, để xử lý dữ liệu.Dịch vụ web so với EJB so với RMI, lợi thế và bất lợi?
Lợi thế của EJB đối với RMI hoặc ngược lại là gì?
Điều gì về dịch vụ web (SOAP, REST)?
EJB được xây dựng trên RMI. Cả hai đều ngụ ý các máy khách Java và các bean. Nếu khách hàng của bạn cần phải được viết bằng thứ gì đó khác (ví dụ: .NET, PHP, v.v.), hãy sử dụng các dịch vụ web hoặc một dịch vụ web khác có giao thức dây không dây, như HTTP hoặc XML qua HTTP hoặc SOAP.
Nếu bạn chọn RMI, bạn không cần máy chủ ứng dụng Java EE EJB. Bạn phải giữ các JVM máy khách và máy chủ đồng bộ; bạn không thể nâng cấp máy khách mà không nâng cấp máy chủ. Bạn phải viết tất cả các dịch vụ mà máy chủ ứng dụng EJB cung cấp cho bạn (ví dụ: kết nối tổng hợp, đặt tên và dịch vụ thư mục, tổng hợp, yêu cầu xếp hàng, giao dịch, v.v.).
RMI là cấp độ khá thấp khi bạn nghĩ về nó. Tại sao bạn lại bỏ tất cả các con đường trở lại CORBA?
Lựa chọn tốt hơn là EJB 3.0 so với Mùa xuân. Nó phụ thuộc vào việc bạn có thích phát triển POJO hay không, muốn có một sự lựa chọn công nghệ quan hệ bên cạnh ORM và JPA, trong số những thứ khác.
Bạn có thể thanh toán cho máy chủ ứng dụng Java EE (ví dụ: WebLogic, WebSphere) hoặc sử dụng một nguồn mở (JBOSS, Glassfish và OpenEJB và ActiveMQ) hoặc bạn có thể gắn bó với Spring và triển khai trên Tomcat, Jetty, Resin hoặc bất kỳ động cơ servlet/JSP nào khác.
Xuân cung cấp rất nhiều lựa chọn bằng cách công nghệ thuyết bất khả tri: kiên trì (Hibernate, iBatis, JDBC, JDO, JPA, TopLink), Remoting (HTTP, Hessian, vải bố, RMI, SOAP web service) vv
EJB 3.0 là thông số kỹ thuật với nhiều nhà cung cấp; Mùa xuân chỉ có thể có từ Spring Source.
Tôi muốn giới thiệu Spring. Nó rất chắc chắn, có rất nhiều lực kéo, không đi đâu cả. Nó để lại tất cả các tùy chọn của bạn mở.
dịch vụ Web là tuyệt vời về mặt lý thuyết, nhưng có một số gotchas mà bạn cần phải xem ra cho:
Mô-đun dịch vụ web của Spring rất tốt, nhưng hãy cẩn thận khi chọn triển khai theo cách này. Viết về giao diện dịch vụ POJO. Những điều này sẽ cho phép bạn có được sự tách biệt về khái niệm mà bạn muốn, trì hoãn lựa chọn triển khai cho đến giây phút cuối cùng và cho phép bạn thay đổi ý định nếu suy nghĩ đầu tiên không hoạt động tốt.
giữa EJB và RMI, EJB chắc chắn sẽ tốt hơn - nó có mọi thứ RMI có và nhiều hơn nữa thông qua các container (đối tượng tổng hợp, quản lý giao dịch, vv)
giữa dịch vụ EJB và web, dịch vụ web sẽ cung cấp cho bạn có nhiều tính di động hơn nếu bạn muốn có thể gọi chúng từ các ứng dụng không phải java trong tương lai. EJB một lần nữa cung cấp cho bạn những thứ như quản lý giao dịch và tổng hợp mà bạn có thể không nhận được "ra khỏi hộp" với các dịch vụ web.
Cá nhân, nếu tôi đang làm điều đó, tôi có lẽ sẽ sử dụng EJB hoặc một số khung đối tượng từ xa tương tự (tính năng truy cập từ xa cũng xuất hiện trong tâm trí). Nếu bạn cần khả năng gọi các đối tượng từ một ứng dụng không phải java, bạn luôn có thể sử dụng các EJB của mình với các proxy dịch vụ web đơn giản khi cần thiết.
Bạn có thể nhanh chóng so sánh Spring Remoting với EJB không? Tôi không cần khả năng làm việc với các ứng dụng không phải Java, nhưng đã thấy EJB khó sử dụng trong quá khứ, trong khi các dịch vụ web cảm thấy đơn giản hơn và đơn giản hơn để viết/duy trì. –
@Dean J - EJBs khá phức tạp trong các phiên bản J2EE cũ hơn, nhưng đã được đơn giản hóa rất nhiều trong 3.0. Tôi đã không sử dụng remoting mùa xuân nhiều, nhưng đây là một bài viết so sánh hai một chút: http://onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html?page=1 –
Tôi sẽ xem xét bài viết đó và đánh giá lại EJB3; EJB2 chỉ cảm thấy xấu xí. –
Dịch vụ web (SOAP, REST) Nếu máy chủ kết thúc của bạn sẽ không được hiển thị công khai, bạn sẽ không nhận được bất kỳ lợi ích nào khi sử dụng giao diện dịch vụ web độc lập như SOAP/REST.
Trong thực tế, bạn sẽ phải chịu một hình phạt với tất cả các chi phí được thêm vào bởi các thẻ XML gói dữ liệu qua một cuộc gọi từ xa, chưa kể đến lần truy cập mà bạn sẽ lấy từ marshalling và unmarshalling XML thành đối tượng java.
Mặc dù mọi cuộc gọi được phân phối sẽ yêu cầu một số mức tuần tự hóa - ngay cả RMI/EJB, nhưng giá sẽ lớn hơn khi tuần tự hóa thành XML có thể đọc được của con người.
Bạn có thể không cần phải mã hóa các cuộc gọi từ xa bằng java, bạn có thể chuyển tiếp dịch vụ của mình bằng cá thể httpd đơn giản, được định cấu hình để cân bằng tải trên nhiều máy chủ java sử dụng mod_jk hoặc mod_proxy.
Các mô-đun này có thể được sử dụng để tải số dư trên các thùng chứa servlet như tomcat/jetty hoặc các vùng chứa ejb như jboss/glassfish.
REST không nói gì về định dạng dây (ví dụ: XML). – user359996
Trong thực tế với một máy chủ Node.js và một API REST RESTI, tôi chắc chắn 100% các seriaziation và deserialization của các đối tượng Javascript sẽ thổi bất kỳ điều Java nào. – bluehallu
Tôi đồng ý với duffymo. Mùa xuân là cách để đi ... –
Dịch vụ web mùa xuân? Mùa xuân là một từ lớn để tìm kiếm. :-) –
Đã chỉnh sửa để thêm siêu liên kết: http://www.springsource.org/ – duffymo