Làm thế nào để thực hiện khớp nối lỏng lẻo với kiến ​​trúc SOA

Question

Tôi đã thực hiện rất nhiều nghiên cứu gần đây về SOA và ESB, v.v.

Tôi đang nghiên cứu thiết kế lại một số hệ thống cũ tại nơi làm việc và muốn xây dựng nó với nhiều kiến ​​trúc SOA hơn so với kiến ​​trúc hiện tại. Chúng tôi sử dụng các dịch vụ này trong khoảng 5 trang web của chúng tôi và một trong những vấn đề lớn nhất hiện có với hệ thống kế thừa của chúng tôi là hầu như tất cả thời gian chúng tôi sửa lỗi hoặc cập nhật chúng tôi cần triển khai lại 5 trang web của mình quá trình tiêu tốn khá nhiều thời gian.

Mục tiêu của tôi là tạo giao diện giữa các dịch vụ được ghép nối lỏng lẻo để thay đổi có thể được thực hiện mà không phải triển khai lại tất cả các dịch vụ và trang web phụ thuộc.

Tôi cần khả năng mở rộng giao diện dịch vụ đã có mà không vi phạm hoặc cập nhật bất kỳ phụ thuộc nào của nó. Có ai trong số các bạn gặp vấn đề này trước đây không? Bạn đã giải quyết nó như thế nào?

Answer 1

Tôi đề xuất xem xét một phong cách dịch vụ khác với bạn có thể đã làm cho đến thời điểm này. Xem xét các dịch vụ cộng tác với nhau bằng các sự kiện, thay vì yêu cầu/trả lời. Tôi đã sử dụng phương pháp này trong nhiều năm với khách hàng ở các ngành dọc khác nhau với rất nhiều thành công. Tôi đã viết khá nhiều về những chủ đề này trong 4 năm qua. Dưới đây là một trong những nơi bạn có thể bắt đầu:

http://www.udidahan.com/2006/08/28/podcast-business-and-autonomous-components-in-soa/

Hy vọng điều đó sẽ hữu ích.

Answer 2

Điều bạn đang hỏi không phải là một chủ đề dễ dàng. Có nhiều cách bạn có thể thực hiện để làm cho Kiến trúc hướng dịch vụ của bạn được kết hợp lỏng lẻo.

Tôi khuyên bạn nên kiểm tra số SOA book series của Thomas Erl. Nó giải thích mọi thứ khá rõ ràng và sâu sắc.

Answer 3

Có một số phương pháp bạn có thể thực hiện. Kiến trúc SOA của chúng tôi liên quan đến các thông báo XML được gửi đến và đi từ các dịch vụ. Một cách chúng tôi đạt được những gì bạn mô tả là tránh sử dụng thư viện ràng buộc dữ liệu cho lược đồ XML của chúng tôi và sử dụng trình phân tích cú pháp XML chung để chỉ lấy các nút dữ liệu bạn muốn bỏ qua những thứ bạn không quan tâm. thêm các nút mới vào thư mà không vi phạm bất kỳ ai hiện đang sử dụng nó. Chúng ta thường chỉ làm điều này khi chúng ta cần một hoặc hai mẩu thông tin từ một cấu trúc lược đồ lớn hơn.

Ngoài ra, giải pháp khác (ưa thích) mà chúng tôi sử dụng là phiên bản. Phiên bản dịch vụ tuân thủ một lược đồ/giao diện cụ thể. Khi lược đồ thay đổi (ví dụ: giao diện được mở rộng hoặc sửa đổi), chúng tôi tạo phiên bản dịch vụ mới. Bất cứ lúc nào chúng tôi có thể có 2 hoặc 3 phiên bản trên đường đi bất cứ lúc nào. Theo thời gian, chúng tôi không dùng nữa và sau đó xóa các phiên bản cũ hơn, trong khi cuối cùng di chuyển mã phụ thuộc vào các phiên bản mới hơn. Bằng cách này, những người phụ thuộc vào dịch vụ có thể tiếp tục sử dụng phiên bản hiện tại của dịch vụ trong khi một số phụ thuộc cụ thể có thể 'nâng cấp' lên phiên bản mới. Phiên bản dịch vụ nào được gọi được định nghĩa trong tệp cấu hình cho mã phụ thuộc. Lưu ý rằng nó không chỉ là lược đồ được phiên bản, mà còn là tất cả các mã triển khai cơ bản nữa.

Hy vọng điều này sẽ hữu ích.

Answer 4

Có một số cách phổ biến để đạt được khớp nối lỏng lẻo cho các dịch vụ.

1. Sử dụng dịch vụ web/theo nghĩa đen của dữ liệu (định dạng dây) thay vì RPC, tránh ràng buộc dữ liệu dựa trên lược đồ.

2. Chấp hành nghiêm chỉnh các hợp đồng khi gửi đi dữ liệu, nhưng giữ vài giả định xử lý dữ liệu gửi đến, xpath là một công cụ tốt cho điều đó (mất trong, chặt ra)

3. Sử dụng ESB và tránh bất kỳ điểm trực tiếp đến giao tiếp điểm giữa các dịch vụ.

Answer 5

Dưới đây là một danh sách kiểm tra thô để đánh giá liệu SOA của bạn thực hiện Loose Coupling:

• Vị trí của hệ thống được gọi là (địa chỉ vật lý của nó): Liệu ứng dụng của bạn sử dụng các URL trực tiếp để truy cập hệ thống hoặc là ứng dụng được tách riêng thông qua lớp trừu tượng chịu trách nhiệm để duy trì kết nối giữa các hệ thống? Dịch vụ đăng ký và mô hình nhóm dịch vụ được sử dụng trong SAP NetWeaver CE là tốt ví dụ về khái niệm trừu tượng như thế nào. Sử dụng bus dịch vụ doanh nghiệp (ESB) là một ví dụ khác. Vấn đề là ứng dụng không nên mã hóa cứng địa chỉ thực của hệ thống được gọi là để thực sự được coi là kết hợp lỏng lẻo.

• Số người nhận: Ứng dụng có chỉ định hệ thống nào là người nhận cuộc gọi dịch vụ không? Một hỗn hợp được ghép lỏng lẻo sẽ không chỉ định các hệ thống cụ thể nhưng sẽ để lại việc phân phối các thông báo của nó tới lớp triển khai hợp đồng dịch vụ. Một ứng dụng kết hợp chặt chẽ sẽ gọi một cách rõ ràng hệ thống nhận theo thứ tự ; một ứng dụng kết hợp lỏng lẻo chỉ đơn giản là thực hiện các cuộc gọi đến giao diện dịch vụ và cho phép triển khai hợp đồng dịch vụ lớp để xử lý các chi tiết về việc gửi tin nhắn đến đúng hệ thống .

• Tính khả dụng của hệ thống: Ứng dụng của bạn có yêu cầu tất cả các hệ thống mà bạn đang kết nối để luôn hoạt động không? Rõ ràng, đây là một yêu cầu rất khó khăn, đặc biệt nếu bạn muốn kết nối với các hệ thống bên ngoài không nằm trong tầm kiểm soát của bạn. Nếu câu trả lời là tất cả các hệ thống phải luôn hoạt động, ứng dụng được kết hợp chặt chẽ trong vấn đề này.

• định dạng dữ liệu: Liệu việc áp dụng tái sử dụng các định dạng dữ liệu được cung cấp bởi các hệ thống phụ trợ hoặc bạn đang sử dụng một hệ thống kiểu dữ liệu kinh điển mà không phụ thuộc vào hệ thống loại được sử dụng trong các ứng dụng được gọi là ? Nếu bạn đang sử dụng lại các kiểu dữ liệu của hệ thống phụ trợ , có thể bạn phải vật lộn với các chuyển đổi kiểu dữ liệu trong ứng dụng của mình và đây không phải là cách tiếp cận rất lỏng lẻo.

• Thời gian đáp ứng: Liệu các ứng dụng đòi hỏi phải được gọi là hệ thống để đáp ứng trong vòng một khoảng thời gian nhất định hoặc là nó chấp nhận được cho các ứng dụng để nhận được một phút trả lời, giờ, hoặc thậm chí ngày sau đó?