RMI so với dịch vụ web. Điều gì tốt nhất cho Java2Java remoting?

Question

Tôi mới dùng cả Dịch vụ Web và RMI và tôi tự hỏi đó là cách tốt nhất để làm điều khiển từ xa giữa các ứng dụng web khác nhau, khi các ứng dụng này được viết bằng Java, đó là khi các ngôn ngữ lập trình khác nhau không quan trọng là lợi thế của WS).

Mặc dù một mặt tôi đoán rằng có một chi phí hiệu suất khi sử dụng dịch vụ web (có ai có một số con số để chứng minh điều đó không?), Mặt khác có vẻ như với tôi rằng các dịch vụ web được kết hợp lỏng lẻo hơn nhiều và có thể được sử dụng để thực hiện một kiến ​​trúc hướng dịch vụ (SOA) (không thể với RMI, đúng không?).

Mặc dù đây là một câu hỏi chung, ý kiến ​​của bạn là gì?

Cảm ơn

Answer 1

Các dịch vụ web cho phép làm một kiến ​​trúc lỏng lẻo. Với RMI, bạn phải đảm bảo rằng các định nghĩa lớp luôn đồng bộ trong mọi trường hợp ứng dụng, có nghĩa là bạn luôn phải triển khai tất cả chúng cùng một lúc ngay cả khi chỉ một trong số chúng được thay đổi (không nhất thiết, nhưng nó là yêu cầu khá thường xuyên vì UUID nối tiếp và không có gì)

Ngoài ra nó không phải là rất khả năng mở rộng, mà có thể là một vấn đề nếu bạn muốn có cân bằng tải.

RMI hoạt động tốt nhất cho các ứng dụng cục bộ nhỏ hơn, không liên quan đến internet nhưng vẫn cần được tách riêng. Tôi đã sử dụng nó để có một ứng dụng java xử lý thông tin liên lạc điện tử và tôi đã khá hài lòng với kết quả. Đối với các ứng dụng khác yêu cầu triển khai phức tạp hơn và hoạt động trên internet, tôi thích sử dụng các dịch vụ web hơn.

Answer 2

Trải nghiệm của tôi với RMI và dịch vụ web phản ánh các phỏng đoán của bạn ở trên. Nói chung, hiệu năng của RMI vượt xa các dịch vụ web, nhưng đặc tả giao diện được trình bày rõ ràng cho các Dịch vụ Web.

Lưu ý rằng không phải giao thức nào trong số các giao thức này yêu cầu rằng các ứng dụng trên cả hai mặt là Java. Tôi có xu hướng sử dụng Dịch vụ Web khi tôi có một hoặc nhiều đối tác bên ngoài đang triển khai giao diện, nhưng RMI nếu tôi kiểm soát cả hai đầu kết nối.

Answer 3

Cho dù bạn sử dụng Dịch vụ web hay phương pháp "gốc" hơn cũng phụ thuộc vào môi trường. Nếu bạn phải vượt qua proxy hoặc một số tường lửa của công ty, các Dịch vụ Web có nhiều khả năng hoạt động vì chúng chỉ dựa trên HTTP. RMI yêu cầu bạn mở một cổng khác cho ứng dụng của bạn có thể khó khăn (không phải về mặt kỹ thuật) trong một số môi trường ...

Nếu bạn biết vấn đề này không phải là vấn đề, bạn nên cân nhắc sử dụng RMI. SOA không phụ thuộc vào công nghệ nhiều như thiết kế dịch vụ tốt. Nếu bạn có một thùng chứa EJB, bạn có thể gọi đậu phiên qua RMI và bổ sung thêm chúng dưới dạng dịch vụ web, nếu bạn thực sự cần, nhân tiện.

Hiệu suất phụ thuộc vào dữ liệu bạn dự định trao đổi. Nếu bạn muốn gửi các lưới đối tượng phức tạp từ ứng dụng này sang ứng dụng khác, nó có thể nhanh hơn với RMI, vì nó được truyền theo định dạng nhị phân (thường). Nếu bạn có một số loại văn bản/nội dung XML anyway, dịch vụ web có thể tương đương hoặc thậm chí nhanh hơn, kể từ đó bạn sẽ không cần phải chuyển đổi bất cứ điều gì cả (để giao tiếp).

HTH,
Martin

Answer 4

RMI có thể là hướng tốt hơn nếu bạn cần duy trì trạng thái phức tạp.

Answer 5

Còn về Spring Remoting. Nó kết hợp giao thức HTTP giống như REST với định dạng nhị phân của RMI. Hoạt động hoàn hảo cho tôi.

Answer 6

Để từ chối mùa xuân (tôi đoán bạn có nghĩa là HTTP Invoker), cả hai bên nên sử dụng Spring, nếu đó là trường hợp nó có thể được thảo luận.

Đối với ứng dụng Java sang Java RMI là một giải pháp tốt, JAX-RPC hoặc JAX-WS cho giao tiếp Java-tới-Java nên tránh nếu khách hàng không nằm trong tầm kiểm soát của bạn hoặc có thể chuyển sang nền tảng khác.

Answer 7

Một điều ủng hộ WS trên RMI là WS hoạt động trên cổng HTTP 80/443 thường không bị chặn tại tường lửa, có thể hoạt động sau NAT vv RMI có giao thức mạng cơ bản phức tạp, yêu cầu bạn mở Các cổng RMI và cũng có thể không hoạt động nếu máy khách bị NATTED. Thứ hai với RMI, bạn đang hạn chế giao tiếp của bạn với giao tiếp JAVA-JAVA, trong khi với Webservies thì không có giới hạn như vậy. Dễ dàng hơn để gỡ lỗi các dịch vụ Web qua dây khi dữ liệu là SOAP/HTTP, có thể dễ dàng được chụp thông qua các công cụ đánh hơi để gỡ lỗi. Tôi không biết một cách dễ dàng để làm điều này trên RMI. Bên cạnh đó RMI thực sự rất cũ và chưa nhận được nhiều sự chú ý trong vài năm qua. Nó đã trở lại lớn trong những ngày CORBA lớn, và cả RMI CORBA đều thực sự là công nghệ cổ xưa. Tùy chọn tốt nhất là các dịch vụ Web kiểu REST.

Answer 8

@ Martin Klinke

"Việc thực hiện phụ thuộc vào dữ liệu mà bạn đang có kế hoạch trao đổi. Nếu bạn muốn gửi lưới đối tượng phức tạp từ một ứng dụng khác, nó có thể nhanh hơn với RMI, vì nó chuyển trong một Tuy nhiên, nếu bạn có một số loại nội dung văn bản/XML, các dịch vụ web có thể tương đương hoặc thậm chí nhanh hơn, kể từ đó bạn sẽ không cần phải chuyển đổi bất kỳ thứ gì (để giao tiếp). " Theo như tôi biết vấn đề hiệu suất làm cho sự khác biệt trong quá trình tuần tự hóa-deserialization nói cách khác marshalling-demarshalling process.I không chắc chắn cả hai điều khoản này là cùng một btw Trong lập trình phân tán, tôi không nói về quá trình xảy ra trong cùng một JVM, đó là về cách bạn sao chép dữ liệu. Nó là một trong hai vượt qua bằng giá trị hoặc vượt qua bằng tham chiếu. Định dạng tương ứng để truyền theo giá trị có nghĩa là sao chép một đối tượng đến máy chủ từ xa trong tệp nhị phân.Nếu bạn có bất kỳ nghi ngờ cho đến bây giờ tôi d muốn nghe

sự khác biệt giữa việc gửi ở định dạng nhị phân và nội dung văn bản/xml là gì về marshalling-demarshalling hoặc serialization-deserialization?

Tôi chỉ đoán thôi. Nó không phụ thuộc vào loại dữ liệu bạn gửi. Loại dữ liệu nào bạn gửi sẽ là một phần của quá trình sửa đổi và sửa lỗi và cuối cùng sẽ được gửi trong tệp nhị phân phải không?

cổ vũ Hakki

Answer 9

Là một bigot mùa xuân và một số mũ của SOA trong nhiều năm tôi muốn tư vấn cho mùa xuân Remoting. Điều này hương vị của dịch vụ xuất khẩu sẽ làm các trick cho RMI.

org.springframework.remoting.rmi.RmiServiceExporter 

Các phương tiện khác đều có sẵn. Điều serialization là khá dễ quản lý nếu bạn phiên bản giao diện của bạn (điểm cuối) và DTOs hợp lý & quản lý UUID tuần tự đúng cách. Chúng tôi postfix 'Alpha', 'Bravo' để giao diện và đối tượng của chúng tôi và tăng, giảm & tái tạo nơi và khi cần thiết. Chúng tôi cũng sửa các UUID tuần tự hóa của chúng tôi thành 1 và đảm bảo các thay đổi chỉ bổ sung, nếu không chúng tôi chuyển từ nói 'Bravo' sang 'Charlie'. Tất cả có thể quản lý trong thiết lập Enterprise.