Cơ sở dữ liệu SOA và chia sẻ

Question

Tôi không hiểu SOA (Kiến trúc hướng dịch vụ) và cơ sở dữ liệu. Trong khi tôi bị hấp dẫn bởi khái niệm SOA (đóng gói logic nghiệp vụ có thể sử dụng lại thành dịch vụ) tôi không thể hiểu được nó hoạt động như thế nào nếu các bảng dữ liệu được đóng gói trong một dịch vụ được yêu cầu bởi các dịch vụ/hệ thống khác --- hoặc là phù hợp với SOA tại tất cả trong trường hợp này?

Để cụ thể hơn, giả sử tôi có hai dịch vụ:

• CustomerService: chứa bảng Customers cơ sở dữ liệu của tôi và logic kinh doanh có liên quan.
• OrderService: chứa bảng và logic Orders của tôi.

Bây giờ nếu tôi cần JOIN các bảng Customers và Orders với câu lệnh SQL? Nếu các bảng chứa hàng triệu mục nhập, hiệu suất không được chấp nhận sẽ dẫn đến nếu tôi phải gửi dữ liệu qua mạng bằng cách sử dụng SOAP/XML. Và cách thực hiện JOIN?

Làm một ít nghiên cứu, tôi đã tìm thấy một số giải pháp đề xuất:

• Use replication để tạo một bản sao cục bộ của dữ liệu cần thiết khi cần thiết. Nhưng sau đó không có đóng gói và sau đó là điểm của việc sử dụng SOA là gì? Điều này được thảo luận on StackOverflow nhưng không có sự nhất trí rõ ràng.
• Thiết lập Master Data Service để gói gọn tất cả dữ liệu của cơ sở dữ liệu. Tôi đoán nó sẽ nhận được kích thước quái vật (với cơ bản một cuộc gọi API cho mỗi thủ tục được lưu trữ) và yêu cầu cập nhật tất cả các thời gian. Đối với tôi, điều này có vẻ liên quan đến khái niệm enterprise data bus.

Nếu bạn có bất kỳ đầu vào nào về điều này, vui lòng cho tôi biết.

---

Edit: Một năm đã trôi qua, và sự quan tâm của tôi trong SOA đã giảm bớt, như có sự nổi tiếng của khái niệm nói chung. Ngày nay, mọi người dường như muốn tập trung vào các dịch vụ RESTful thay thế.

Answer 1

Một trong những nguyên tắc xác định của "dịch vụ" trong ngữ cảnh này là nó sở hữu, tuyệt đối, dữ liệu đó trong khu vực chịu trách nhiệm cũng như các hoạt động trên dữ liệu đó.

Sao chép dữ liệu, thông qua nhân rộng hoặc bất kỳ cơ chế nào khác, mương trách nhiệm đó. Hoặc bạn cũng có thể sao chép các quy tắc kinh doanh, hoặc cuối cùng bạn sẽ có một tình huống mà bạn cần phải cập nhật dịch vụ khác để thay đổi các quy tắc nội bộ của bạn.

Sử dụng một dịch vụ dữ liệu đơn lẻ chỉ là "không làm SOA"; nếu bạn có một nơi duy nhất quản lý tất cả dữ liệu, bạn không có các dịch vụ độc lập, bạn chỉ có một dịch vụ.

Tôi sẽ đề xuất, thay vào đó, tùy chọn thứ ba: sử dụng bố cục để đặt dữ liệu đó lại với nhau, tránh hoàn toàn cấp cơ sở dữ liệu HOẠT ĐỘNG hoạt động.

Thay vì suy nghĩ về việc cần tham gia những hai giá trị với nhau trong cơ sở dữ liệu, suy nghĩ về làm thế nào để soạn chúng lại với nhau ở các cạnh:

Khi bạn render một trang HTML cho một khách hàng, bạn có thể cung cấp HTML từ nhiều dịch vụ và soạn chúng bên cạnh nhau một cách trực quan: chi tiết khách hàng đến từ dịch vụ khách hàng và các chi tiết đơn đặt hàng từ dịch vụ đặt hàng.

Tương tự như email hóa đơn: soạn dữ liệu được cung cấp từ nhiều dịch vụ một cách trực quan, mà không cần tham gia vào cơ sở dữ liệu.

Điều này có hai ưu điểm: một, bạn không cần phải tham gia vào cơ sở dữ liệu và thậm chí cần phải lưu trữ dữ liệu trong cùng một loại cơ sở dữ liệu. Bây giờ mỗi dịch vụ có thể sử dụng bất kỳ kho dữ liệu nào phù hợp nhất với nhu cầu của họ.

Hai, bạn có thể dễ dàng thay đổi bên ngoài ứng dụng của mình. Nếu bạn có các bộ phận nhỏ, có thể ghép lại, bạn có thể dễ dàng thêm sắp xếp lại các bộ phận theo những cách mới.

Answer 2

Nguyên tắc hướng dẫn là ok để lưu trữ dữ liệu không thay đổi Điều này có nghĩa là dữ liệu đơn giản bất biến từ thực thể khách hàng có thể tồn tại trong dịch vụ đặt hàng và không cần phải chuyển đến dịch vụ khách hàng mỗi khi bạn cần thông tin. Phá vỡ tất cả mọi thứ để các dịch vụ bị cô lập và sau đó luôn luôn thực hiện các cuộc gọi thủ tục từ xa bỏ qua các fallacies of distributed computing. Nếu bạn có nhu cầu báo cáo mở rộng, bạn cần tạo một dịch vụ bổ sung. Tôi gọi đó là dịch vụ Báo cáo tổng hợp, một lần nữa nhận dữ liệu chỉ đọc cho mục đích báo cáo. Bạn có thể xem bài viết I wrote about that for InfoQ một vài năm trước

Answer 3

Trong câu hỏi SO bạn trích dẫn, nhiều người cho rằng dịch vụ truy cập dữ liệu dịch vụ khác là tốt, vì vậy dịch vụ Đặt hàng có thể có chức năng GetAllWithCustomer, tất cả các đơn đặt hàng cùng với các chi tiết của khách hàng cho đơn đặt hàng đó.

Ngoài ra, câu hỏi này của tôi có thể hữu ích:

https://softwareengineering.stackexchange.com/questions/115958/is-it-bad-practice-for-services-to-share-a-database-in-soa