2009-06-08 44 views
7

Tôi đang xem xét kiến ​​trúc SOA cho một bộ dịch vụ để hỗ trợ một doanh nghiệp mà Im tư vấn, trước đây chúng tôi đã sử dụng tích hợp cơ sở dữ liệu nơi mỗi ứng dụng chọn ra nó cần từ cơ sở dữ liệu MS SQL được chia sẻ với nó vv .. Chúng tôi đã có các ứng dụng khác nhau tích hợp với cơ sở dữ liệu quái vật bao gồm java, .net và truy cập microsoft, có tính toàn vẹn tham chiếu như tất cả mọi thứ đã được kết hợp chặt chẽ.Phong cách SOA - Chia sẻ dữ liệu

Tôi hơi bối rối về cách hỗ trợ chia sẻ dữ liệu giữa các dịch vụ.

Cho phép sử dụng Dịch vụ sản phẩm nằm trên cơ sở dữ liệu Sản phẩm do người bán buôn cung cấp mỗi tháng. Chúng tôi xây dựng một mô hình miền và ngồi trên cơ sở dữ liệu với Hibernate hoặc whatvever, implentation wise Sản phẩm là một đồ thị đối tượng lớn cung cấp thông tin được cung cấp bởi người bán buôn về sản phẩm.

Bây giờ, giả sử dịch vụ Đánh giá, Dịch vụ giá, Dịch vụ giao hàng và Dịch vụ chứng khoán sẽ đăng ký ProductUpdated, ProductAdded, ProductDeleted. Vấn đề là mỗi dịch vụ chỉ cần một phần hoặc một số phần của thông tin về Sản phẩm. Vận chuyển có thể chỉ cần kích thước và trọng lượng. Giá cả chỉ có thể cần id sản phẩm, chi phí bán buôn, giảm âm lượng, giá có hiệu lực cho đến nay. Đánh giá có thể cần id sản phẩm, tên sản phẩm, nhà sản xuất. Có phải là thực hành tiêu chuẩn chỉ để xuất bản toàn bộ Sản phẩm (hợp đồng thuê bao không phù hợp cụ thể như ProductUpdated và lược đồ phù hợp - đại diện cho tất cả đồ thị đối tượng sản phẩm) và cho phép người đăng ký bản đồ bất cứ thứ gì họ cần cho mô hình miền của họ (hoặc quái làm những gì họ muốn với, có thể thậm chí không có một mô hình tên miền) ...

Hoặc khi tôi viết những dòng này tôi nghĩ có lẽ:

sản phẩm Dịch vụ Xuất bản ProductAdded nhắn (không bao gồm chi tiết sản phẩm chỉ là một ID của sản phẩm và có thể là dấu thời gian)

Giá dịch vụ su bscribes để ProductAdded và xuất bản RequestPricingForProduct nhắn

Sản phẩm Dịch vụ Xuất bản ResultForPricingForProduct nhắn

Hmm .. dường như tốt hơn một chút ... nhưng nó cảm thấy như tôi đang xây dựng hợp đồng cho dịch vụ sản phẩm dựa trên những gì các dịch vụ khác tôi có thể xác định và những gì họ sẽ cần, có lẽ trong tương lai Dịch vụ XYZ đòi hỏi một cái gì đó khác nhau. Im sẽ dừng lại ở đó vì tôi nghĩ rằng nó trở nên rõ ràng hơn, nơi tôi đang bối rối ... có lẽ ở trên sẽ làm việc bởi vì tôi nên vạch trần một cách để trả lại bất cứ điều gì mà nên được công chúng hmmm ngay.

Bất kỳ nhận xét hoặc hướng nào được đánh giá cao. Xin lỗi nếu điều này xuất hiện nửa nướng.

Trả lời

3

Gần đây tôi đã ở vị trí của bạn. Vấn đề với việc phơi bày trực tiếp đối tượng bên dưới thông qua dịch vụ là bạn tăng sự ghép nối giữa các lớp và có ít điểm trong việc sử dụng Kiến trúc hướng dịch vụ. Bạn sẽ không thể thay đổi các đối tượng hoặc quy tắc kinh doanh này mà không ảnh hưởng đến dịch vụ web.

Có vẻ như bạn đang đi đúng hướng. Nếu bạn nghiêm túc về việc phân tách các lớp của mình, thì mẫu phổ biến nhất là tạo một nhóm thông điệp riêng biệt mới chỉ dành cho dịch vụ web, có khả năng mỗi dịch vụ và dịch các đối tượng nội bộ của bạn qua lại.

Để biết ví dụ về cách thiết lập lớp dịch vụ theo cách này, hãy xem mẫu "Giao diện dịch vụ". Về phía khách hàng của dịch vụ, có một mô hình đối diện được gọi là "Cổng dịch vụ".

Hướng dẫn Kiến trúc Ứng dụng 2.0 có toàn bộ chương dành riêng cho các loại quyết định bạn đang thực hiện (http://apparchguide.codeplex.com/Wiki/View.aspx?title=Chapter%2013%20-%20Service%20Layer%20Guidelines). Tôi sẽ tải xuống toàn bộ hướng dẫn.

Đây là phần phù hợp nhất với bạn. Câu chuyện dài ngắn, nếu bạn dành thời gian để tạo các phương pháp thô sơ mới và các đối tượng dựa trên thông điệp, bạn sẽ kết thúc với một dịch vụ web tốt hơn nhiều:

Hãy xem xét các nguyên tắc sau khi thiết kế giao diện dịch vụ : Cân nhắc sử dụng giao diện hạt thô cho các yêu cầu hàng loạt và giảm thiểu số lượng cuộc gọi qua mạng. Thiết kế giao diện dịch vụ theo cách mà thay đổi đối với logic nghiệp vụ không ảnh hưởng đến giao diện. Không triển khai các quy tắc kinh doanh trong giao diện dịch vụ. Cân nhắc sử dụng các định dạng chuẩn cho các tham số để cung cấp khả năng tương thích tối đa với các loại máy khách khác nhau. Đừng đưa ra các giả định trong thiết kế giao diện của bạn về cách khách hàng sẽ sử dụng dịch vụ. Không sử dụng kế thừa đối tượng để triển khai phiên bản cho giao diện dịch vụ.

5

Tôi thực sự nghĩ rằng giải pháp cho vấn đề này là KHÔNG chia sẻ dữ liệu. SOA có nghĩa là dữ liệu được sở hữu bởi một dịch vụ - đó là quyền hạn kỹ thuật của dữ liệu đó. Tôi khuyên bạn nên đọc một số bài viết của Pat Helland, chẳng hạn như Data On The Inside, Data On The Outside.

Điều duy nhất nên được chia sẻ giữa các dịch vụ khác nhau này là khóa chính - ProductId trong ví dụ của bạn. Nếu không, đối với mỗi dịch vụ, dữ liệu cần nhất quán về mặt giao dịch sẽ kết hợp với nhau.

Không cần phải là một "Sản phẩm". Mỗi dịch vụ có thể có một cái nhìn khác nhau về sản phẩm trong dịch vụ của họ. Đối với dịch vụ Giá cả, bạn có một productId và một mức giá. Đối với dịch vụ đánh giá, productId và đánh giá. Và cứ thế.

Nơi điều này bắt đầu gây nhầm lẫn cho mọi người là cách hiển thị dữ liệu này trong giao diện người dùng nếu dữ liệu đó từ tất cả các dịch vụ khác nhau này. Làm cách nào để bạn có thể hiển thị danh sách các bài đánh giá cho một sản phẩm có tên sản phẩm từ ProductService và văn bản đánh giá từ ReviewService?

Câu trả lời cho điều đó là soạn giao diện người dùng từ tất cả các dịch vụ khác nhau. Lấy sản phẩm từ dịch vụ sản phẩm và nhận dữ liệu đánh giá từ dịch vụ đánh giá và sau đó kết hợp dữ liệu đó trong giao diện người dùng.

Các vấn đề liên quan