Mô hình hóa SOA: Phần 3

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:19

Thêm vào BST

Báo xấu

101
lượt xem 14
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Mô hình hóa SOA: Phần 3. Thực hiện dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài thứ ba này của loạt bài viết năm phần giải thích các dịch vụ Web nền tảng SOA được cài đặt như thế nào. Quá trình nhận thức dịch vụ bắt đầu bằng việc quyết định thành phần nào sẽ cung cấp dịch vụ nào. Quyết định đó đóng vai trò quan trọng trong tính sẵn có, khả năng phân phối, bảo mật, phạm vi giao dịch và tính tương tác của dịch vụ. Sau khi các quyết...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Mô hình hóa SOA: Phần 3

Mô hình hóa SOA: Phần 3. Thực hiện dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài thứ ba này của loạt bài viết năm phần giải thích các dịch vụ Web nền tảng SOA được cài đặt như thế nào. Quá trình nhận thức dịch vụ bắt đầu bằng việc quyết định thành phần nào sẽ cung cấp dịch vụ nào. Quyết định đó đóng vai trò quan trọng trong tính sẵn có, khả năng phân phối, bảo mật, phạm vi giao dịch và tính tương tác của dịch vụ. Sau khi các quyết định đó đã được đưa ra, bạn có thể mô hình hoá cách thức chức năng của mỗi dịch vụ được cài đặt và các chức năng yêu cầu thực sự được sử dụng như thế nào. Sau đó, bạn có thể sử dụng tính năng chuyển đổi UML-to-SOA có sẵn trong IBM® Rational® Software Architect để tạo một dịch vụ Web mà có thể được sử dụng trong IBM® WebSphere® Integration Developer để cài đặt, kiểm tra, và triển khai giải pháp hoàn thiện đó. Về loạt bài viết này Trong bài viết đầu tiên của loạt bài viết này, "Phần 1. Xác định dịch vụ", chúng ta đã phác thảo một cách tiếp cận để nhận dạng các dịch vụ mà được nối với những yêu cầu nghiệp vụ. Chúng ta đã bắt đầu nắm bắt các mục đích nghiệp vụ và các mục tiêu cần thiết để thực hiện một nhiệm vụ nghiệp vụ. Rồi chúng ta đã mô hình hoá các hoạt động và tiến trình nghiệp vụ mà cần thiết để đạt được các mục đích và các mục tiêu. Sau đó, chúng ta đã sử dụng quá trình nghiệp vụ như một giao ước giúp ta nhận ra các dịch vụ yêu cầu và các mỗi quan hệ tiềm tàng giữa chúng. Trong bài viết thứ hai, "Phần 2. Đặc tả Dịch vụ", chúng ta đã mô hình hoá các chi tiết của đặc tả dịch vụ. Một đặc tả dịch vụ định nghĩa tất cả mọi thứ một khách hàng tiềm tàng của dịch vụ cần được biết để có thể quyết định họ có quan tâm tới sử dụng dịch vụ hay không, và chính xác cách sử dụng nó như thế nào. Nó còn chỉ rõ mọi thứ một nhà cung cấp dịch vụ cần phải biết để có thể cài đặt thành công
dịch vụ. Nghĩa là, một đặc tả dịch vụ là một người thương thuyết hay giao kèo giữa cái mà người sử dụng cần và cái mà nhà cung cấp có. Thông tin này lấy được trong đặc tả dịch vụ, nó giúp dễ dàng tìm kiếm dịch vụ tái sử dụng trong các kho tài nguyên và thu được tất cả các thông tin cần thiết mà không phải lục qua rất nhiều tài liệu khác nhau hay tìm kiếm các yếu tố có liên quan. Trong bài này chúng ta sẽ xem xét thiết kế cách thức các dịch vụ thực sự được cung cấp hay, trong thuật ngữ Unified Modeling Language (UML), được nhận thức như thế nào. Thiết kế nhận thức dịch vụ bắt đầu bằng việc quyết định thành phần nào sẽ cung cấp dịch vụ nào. Quyết định đó đóng vai trò quan trọng trong tính sẵn có, khả năng phân phối, bảo mật phạm vi giao dịch và tính tương tác của dịch vụ. Sau khi các quyết định đó được đưa ra, bạn có thể thiết kế cách thức chức năng của mỗi dịch vụ được cài đặt, từ đó, các chức năng yêu cầu thực sự được sử dụng như thế nào. Bài tiếp theo trong loạt bài viết, "Modeling SOA: Phần 4. Cấu thành dịch vụ," sẽ miêu tả cách các dịch vụ này có thể được hợp thành để tạo những dịch vụ mới như thế nào. Bài cuối cùng, "Phần 5. Cài đặt dịch vụ," sẽ sử dụng tính năng chuyển đổi UML sang SOA của IBM® Rational® Software Architect để tạo ra cài đặt của các dịch vụ Web mà có thể được trực tiếp sử dụng trong IBM® WebSphere® Integration Developer để thi triển, kiểm tra, và triển khai giải pháp hoàn thiện đó. Nội dung của bài viết này Sự am hiểu hoàn thiện về mô hình hoá SOA đòi hỏi tới các chi tiết về cách thức một dịch vụ thực sự được thực thi bởi nhà cung cấp và sử dụng bởi khách hàng. Nếu sự thực thi là phức tạp, thì có thể đặc tả là không chính xác hoặc các dịch vụ được nhận dạng là sai. Bài viết này chỉ ra cách để thiết kế cài đặt của mỗi đặc tả dịch vụ ta đã thiết kế trong bài trước. Thiết kế sự cài đặt bao gồm 3 bước: 1. Quyết định nhà cung dịch vụ nào cung cấp những dịch vụ nào
2. Thiết kế các cài đặt dịch vụ 3. Tổ hợp và kết nối khách hàng và nhà cung cấp dịch vụ cần thiết để mô hình hoá những cài đặt hoàn thiện Quyết định những dịch vụ nào được cung cấp bởi những nhà cung cấp nào (có thể có hơn một nhà cung cấp) bị ảnh hưởng bởi rất nhiều yếu tố, bao gồm: Các dịch vụ được sử dụng nhiều nhất ở đâu • Chúng được triển khai nhiều nhất ở đâu • Những khả năng nào của dịch vụ là bắt buộc • Sự ổn định của khu vực chức năng • Nơi nào có nhiều sự thay đổi được thấy trước nhất • Có bao nhiêu sự tương tác chấp nhận được trong phạm vi • Các vấn đề bảo mật • Các công nghệ cài đặt nền tảng sử dụng được • Khả năng tích hợp vào tái sử dụng của hệ thống đã có • Sự phân tích chi tiết của tất các các vấn đề này nằm ngoài phạm vi của bài viết này, nhưng nó sẽ được bao quát đầy đủ trong phương pháp IBM® Service Oriented Modeling and Architecture (SOMA). Ở đây, chúng ta sẽ cho rằng, bằng cách nào đó, kiến trúc IT đã quyết định những nhà cung cấp dịch vụ nào sẽ cung cấp những dịch vụ nào, nên ta có thể tập trung vào cách thức những nhà cung cấp được mô hình và kết hợp trở thành những giải pháp khách hàng.
Cũng giống tất cả các bài trong loạt bài này, chúng ta sẽ sử dụng các công cụ có sẵn của IBM Rational và IBM WebSphere để xây dựng giải pháp giả lập và kết nối chúng với nhau do đó ta có thể thẩm tra lại giải pháp với những nhu cầu và quản lý thay đổi hiệu quả hơn. Bảng 1 cung cấp bảng tóm tắt của toàn bộ quá trình chúng ta sẽ sử dụng trong phát triển ví dụ và những công cụ được sử dụng để xây dựng các giả lập. Bảng 1: Vai trò, nhiệm vụ và công cụ của quá trình phát triển Vai trò Nhiệm vụ Công cụ Truyền đạt mục đích Nhà điều hành IBM® Rational® RequisitePro® và mục tiêu nghiệp nghiệp vụ vụ Nhà phân tích Phân tích các nhu cầu IBM® WebSphere® Business Modeler nghiệp vụ nghiệp vụ Kiến trúc sư Thiết kế kiến trúc của IBM Rational Software Architect giải pháp phần mềm IBM® Rational® Application Developer và Nhà phát triển Cài đặt giải pháp IBM® WebSphere® Integration Developer dịch vụ Web Xem lại xác định và đặc tả dịch vụ
Hãy bắt đầu từ xem xét lại các đặc tả dịch vụ mà ta đã nhận dạng và chỉ ra trong các bài viết trước. Hình 1 cho thấy giao ước các điều kiện dịch vụ nghiệp vụ mà giải pháp của ta phải đáp ứng được. Hình 1. Giao ước các điều kiện của dịch vụ
Nhắc lại là sự cộng tác dịch vụ này tượng trưng cho một giao ước các yêu cầu, có thể nhận được từ một tiến trình nghiệp vụ mà nó miêu tả giải pháp dịch vụ của ta phải làm gì. Đó là một đặc tả trung lập về mặt kiến trúc các điều kiện mà không nhất thiết đòi hỏi một giải pháp SOA. Hình 2 trình bày các đặc tả dịch vụ đã được nhận dạng cần thiết để đáp ứng các điều kiện. Về cơ bản, chúng ta đang xây dựng (mua, tái sử dụng, phỏng theo) các dịch vụ có khả năng đảm nhiệm những vai trò trong giao ước các điều kiện của dịch vụ nghiệp vụ này. Hình 2. Topo dịch vụ Hình 3 trình bày đặc tả dịch vụ Scheduling hoàn thiện. Đặc tả dịch vụ này là một giao diện đơn giản, vì không có giao thức quan trọng nào để sử dụng dịch vụ lập lịch.
Hình 3. Đặc tả dịch vụ Scheduling Hình 4 trình bày đặc tả dịch vụ ShippingService. Hình 4. đặc tả dịch vụ ShippingService Đặc tả dịch vụ này phức tạp hơn một chút, vì nó mô hình hoá sự tương tác giữa một nhà buôn và một người đặt mua, sử dụng kiểu giao tiếp gọi lại (callback) đơn giản. Do đặc tả này bao gồm cả giao thức hành vi, ta mô hình hoá nó sử dụng lớp
trừu tượng (abstract class) mà định nghĩa các vai trò (thuộc tính) liên quan trong giao thức dịch vụ. Trách nhiệm của những vai trò này được định nghĩa bởi kiểu (types) của chúng, mà chính là các giao diện đã cung cấp hay được yêu cầu bởi đặc tả dịch vụ. Sự tương tác ShippingService của đặc tả dịch vụ ShippingService chỉ rõ các quy tắc để nhà buôn và người đặt mua tương tác. Sự tương tác này sẽ là giao ước cho các kênh dịch vụ kết nối tới một dịch vụ định nghĩa bởi giao diện dịch vụ này. Hình 5 trình bày đặc tả dịch vụ InvoicingService.
Hình 5. Đặc tả dịch vụ InvoicingService Giao thức này cũng phức tạp hơn một chút, vì các chức năng được cung cấp và yêu cầu của dịch vụ phải gọi và đáp ứng lại theo một trật tự nhất định. Trong trường hợp này, một biểu đồ hoạt động được sử dụng để chỉ rõ giao thức dịch vụ. Dù sao, đây chỉ đơn thuần là vấn đề lựa chọn; chúng ta có thể sử dụng một cơ cấu tương tác hay trạng thái. Hình 6 trình bày đặc tả dịch vụ Purchasing:
Hình 6. Đặc tả dịch vụ Purchasing Đặc tả dịch vụ Purchasing miêu tả chức năng có thể được chỉ ra trong tiến trình nghiệp vụ gốc Process Purchase Order. Nó miêu tả một dịch vụ được nhận dạng và thiết kế để thấy rõ tiến trình nghiệp vụ đó. Bởi vì không có giao thức dịch vụ nào liên kết với đặc tả này, chúng ta một lần nữa mô hình hoá nó sử dụng một giao diện theo khuôn mẫu. Bây giờ, chúng ta đã sẵn sàng để thiết kế các thành phần mà cung cấp mỗi một dịch vụ đó. Thực hiện dịch vụ Một dịch vụ (service) chỉ ra tập các khả năng, được cung cấp bởi nhà cung cấp dịch vụ, mà thoả mãn các nhu cầu của khách hàng hay người sử dụng của dịch vụ. Bước đầu tiên trong thiết kế cài đặt dịch vụ là chuẩn bị cho các dịch vụ. Nghĩa là, tìm giải pháp để nhà cung cấp dịch vụ sẽ cung cấp dịch vụ cho phép nào. Đây là phần mấu chốt trong thiết kế một SOA, bởi vì lựa chọn nhà cung cấp là thiết lập những mối quan hệ giữa người sử dụng và người cung cấp dịch vụ. Do đó, điều này thiết lập cả về khả năng của hệ thống và sự tương tác giữa các bộ phận của nó. Bạn có thể đặt tất cả các thao tác vào một dịch vụ duy nhất và có một giải pháp đơn giản. Nhưng tất cả các khách hàng sẽ phụ thuộc vào một dịch vụ đó, điều này sẽ dẫn đến sự tương tác với mật độ rất cao. Bất cứ thay đổi nào trong nhà cung cấp sẽ dẫn tới khả năng thay đổi trong tất cả các khách hàng. Đây là vấn đề chung đối với các thư viện bộ phận trong lập trình C thời trước. Bạn cũng có thể tạo một dịch vụ riêng biệt cho mỗi chức năng, nhưng cách này sẽ dẫn tới một hệ thống rất
phức tạp mà không mang lại khả năng đóng gói và kết dính tốt. Sẽ gặp khó khăn trong việc mô hình hoá sự giao tiếp giữa khách hàng và nhà cung cấp dịch vụ theo một giao thức để sử dụng một tập các chức năng có liên quan. Rốt cuộc, quyết định các nhân tố tham gia vào dịch vụ là một việc đòi hỏi kĩ năng nhất định và có thể bị tác động bởi rất nhiều sự thoả hiệp. Khả năng phân phối có thể đóng một vai trò quyết định. Thật là tuyệt nếu chúng ta có thể thiết kết những giải pháp SOA không phụ thuộc vào vị trí khách hàng hay nhà cung cấp, nhưng điều đó thông thường không được thực tế lắm. Nơi một dịch vụ được triển khai, trong mối quan hệ với khách hàng và các dịch vụ cần thiết khác, có thể có ảnh hưởng sâu sắc tới hiệu quả thực thi, tính sẵn có, và bảo mật của giải pháp. Bỏ qua điều này trong kiến trúc giải pháp có thể dẫn đến đưa ra một cài đặt giải pháp không thể chấp nhận được. Vấn đề của chúng ta ở đây thì khá đơn giản, nên không khó để xác định nhân tố nào sẽ cung cấp hay sử dụng những dịch vụ nào. Những phần tiếp theo cung cấp mô hình của các nhà cung cấp dịch vụ cho tất các cả dịch vụ trình bày trong Hình 2 và các đặc tả chi tiết dịch vụ dựa vào hình này. Đây là một ví dụ khá đơn giản, và nhiều nhà cung cấp dịch vụ chỉ cung cấp một dịch vụ với chỉ một khả năng. Đây sẽ không phải là trường hợp thông dụng. Các nhà cung cấp dịch vụ được trông đợi sẽ cung cấp hay sử dụng (hay cả hai) rất nhiều dịch vụ với nhiều chức năng có thể. Ví dụ này cố tình được đơn giản hoá để tập trung vào các khái niệm mà không phải lún sâu vào chi tiết của nó. Lập hoá đơn (Invoicing) Một nhà cung cấp dịch vụ lập hoá đơn cung cấp giao diện Lập hoá đơn để tính toán giá gốc cho đơn mua hàng, và sau đó nó sẽ tinh chỉnh giá này khi được biết thông tin vận chuyển. Tổng giá của đơn đặt hàng phụ thuộc vào vị trí sản phẩm được sản xuất ra và nơi chúng được chuyển đi từ. Tính toán giá gốc có thể được sử
dụng để thẩm tra rằng khách hàng có đủ tín dụng hay vẫn muốn mua sản phẩm. Tốt hơn là thẩm tra điều này trước khi hoàn thiện hoá đơn. Chúng ta bắt đầu thiết kế nhà cung cấp dịch vụ này bằng cách tạo ra một trường hợp sử dụng hệ thống chỉ rõ yêu cầu của nó và một thành phần được gọi là Invoicer mà nhận thức trường hợp sử dụng này. Thành phần Invoicer sẽ nằm trong gói tín dụng được nhập gói CRM (customer relationship management) để sử dụng các định nghĩa dữ liệu (thông điệp) dịch vụ chung. Hình 7 trình bày những gì ta đã làm được. Hình 7. Nhà cung cấp dịch vụ Invoicer ban đầu Nhà cung cấp dịch vụ Invoicer sẽ cung cấp dịch vụ InvoicingService. Chúng ta mô hình nó bằng cách bổ sung một cổng vào Invoicer, có kiểu là đặc tả dịch vụ InvoiceService. Tất cả các dịch vụ đều được đặt kiểu bởi đặc tả dịch vụ mà định nghĩa những chức năng nào được cung cấp và đòi hỏi cùng với giao thức để sử dụng chúng. Hình 8 thể hiện Invoicer với dịch vụ lập hóa đơn đã được bổ sung.
Hình 8. Bổ sung một InvoicingService vào nhà cung cấp dịch vụ Invoicer Từ kiểu của dịch vụ, chúng ta có thể thấy được nó cung cấp giao diện Lập hóa đơn và yêu cầu giao diện InvoiceProcessing. Từ kiểu dịch vụ, chúng ta biết những khách hàng đã kết nối với dịch vụ phải làm gì để sử dụng dịch vụ và Invoicer (hay bất cứ nhà cung cấp nào khác) phải làm gì để thực hiện nó. Bất cứ một sử dụng hay thực hiện của dịch vụ phải nhất quán với đặc tả dịch vụ và giao thức của nó. Cổng thanh toán hoá đơn còn có thể chỉ ra nhưng liên kết có thể được cung cấp bởi thành phần Invoicer để sử dụng trong kết nối với các thành phần khác. Các cách tiếp cận liên kết có thể, như là RMI qua IIOP (Remote Method Invocation qua Internet Inter-ORB Protocol) hay SOAP qua HTTP, có thể một lần nữa mang tác động sâu sắc tới hiệu quả thực thi, tính sẵn có, và bảo mật của dịch vụ. Do đó, những vấn đề liên quan nên được giải quyết như một phần của thiết kế dịch vụ, cho dù rằng chúng có thể là đặc trưng cho một nền tảng. Tối thiểu, bản thiết kế giải pháp phải giải quyết được các kết nối với dịch vụ là cục bộ hay từ xa hay cả hai. Invoicer cung cấp giao diện Lập hóa đơn, bao gồm hai thao tác: initiatePriceCalculation • completePriceCalculation • Invoicer phải cung cấp thiết kế cho quá trình cài đặt hay phương thức cho mỗi thao tác dịch vụ này. Phương thức cũng phải gọi thao tác processInvoice của giao
diện InvoiceProcessing khi sự tính toán giá cả đã hoàn thành. Hình 9 trình bày thành phần Invoicer sở hữu hai hành vi có tên giống những thao tác được cung cấp. Hình 9. Các cài đặt dịch vụ Invoicer Hoạt động completePriceCalculation là phương thức cho thao tác dịch vụ Invoicing::completePriceCalculation. Nó sử dụng một hành động cụ thể để tính toán tổng giá, sau đó nó gọi thao tác InvoiceProcessing::processInvoice trên cổng lập hoá đơn. (Pin nhập vào của hành động processInvoice là cổng lập hoá đơn). Chú ý rằng điều này phù hợp với giao thức lập hoá đơn được chỉ ra bởi đặc tả dịch vụ InvoicingService. Hành vi cụ thể initiatePriceCalculation là phương thức cho thao tác dịch vụ initiatePricesCalculation. Thao tác này được cài đặt sử dụng mã Java™ lấy trong thân hàm của hành vi cụ thể.
Lập lịch sản xuất (Production scheduling) Một nhà cung cấp dịch vụ lập lịch sản xuất cung cấp giao diện Lập lịch để quyết định hàng hoá sẽ được sản xuất tại đâu và khi nào. Thông tin này có thể được sử dụng để lập lịch chuyển hàng dùng trong xử lý đơn hàng. Thành phần Productions cung cấp giao diện Lập lịch qua cổng lập lịch, như được thể hiện trong Hình 10. Cổng này chỉ ra các kiểu kết nối khả thi sẵn có trên cổng đó. Hình 10. Nhà cung cấp dịch vụ Productions Các phương thức thao tác dịch vụ là các hành vi requestProductionsScheduling và sendShippingSchedule. Chi tiết của các cài đặt này không được thể hiện trong biểu đồ và có thể được để cài đặt bởi người phát triển sử dụng những ngôn ngữ đặc trưng nền tảng, dễ ứng dụng hơn.
Chuyển hàng Nhà cung cấp dịch vụ chuyển hàng cung cấp giao diện Shipping để chuyển hàng hoá tới một khách hàng cho một đơn hàng đã được lập. Nó còn đòi hỏi giao diện ScheduleProcessing để đưa ra yêu cầu rằng khách hàng quyết định lịch trình hoàn thiện. Hình 11 trình bày dịch vụ Shipper cung cấp dịch vụ chuyển hàng như được chỉ ra bởi đặc tả dịch vụ ShippingService. Hình 11. Nhà cung cấp dịch vụ Shipper Các kiểu liên hợp (Conjugate types) Để sử dụng thiết kế nhà cung cấp dịch vụ đã được trình bày, chúng ta cần hiểu mối quan hệ giữa khách hàng và nhà cung cấp dịch vụ, họ kết nối như thế nào, làm sao để chỉ ra kiểu của các cổng trên mỗi đầu của kết nối, và làm sao để quyết định các kiểu đó có tương thích, kết quả là một kết nối hợp lệ. SOA là về kết hợp nhu cầu của khách hàng với khả năng của nhà cung cấp. Nhân tố khách hàng có những nhu cầu mà họ gặp qua yêu cầu. Nhân tố nhà cung cấp có
những khả năng họ cung cấp qua các dịch vụ. Những nhu cầu của khách hàng được ánh xạ tới những khả năng nhà cung cấp bằng kết nối đòi hỏi với dịch vụ. Cách thức khách hàng sử dụng các dịch vụ và cách thức nhà cung cấp cung cấp chúng phải tương thích với các giao thức đã định nghĩa trong các đặc tả dịch vụ và yêu cầu. Khi một cổng khách hàng (một yêu cầu) được kết nối tới một cổng dịch vụ nhà cung cấp, các cổng tại cuối mỗi kết nối phải tương thích. Điều này nghĩa là yêu cầu của khách hàng phải cần giao diện cổng cung cấp, và khách hàng phải cung cấp các giao diện cần thiết. Hơn nữa, khách hàng và nhà cung cấp phải tương tác dựa trên giao thức được định nghĩa trong giao diện dịch vụ. Cổng yêu cầu có thể sử dụng bất cứ lớp nào để định nghĩa kiểu của nó. Nó có thể cung cấp hay yêu cầu (hoặc cả hai) bất cứ giao diện nào, chừng nào chúng còn tương thích với bất cứ cổng dịch vụ nào chúng kết nối tới. Nghĩa là, khách hàng và nhà cung cấp được tách riêng cho tới khi họ được kết nối, và họ không yêu cầu phải có một đặc tả dịch vụ đặc biệt tương ứng với đặc tả dịch vụ được cung cấp. Dù sao, có rất nhiều trường hợp khi kiểu một yêu cầu của khách hàng chính xác là phần bù hoặc liên hợp (conjugate) của cổng dịch vụ nó kết nối tới. Kết quả là, nó có thể thuận tiện để định nghĩa một quy ước để dễ dàng chỉ rõ và bổ nhiệm liên hợp của một đặc tả dịch vụ có thể được sử dụng như một kiểu cho cổng yêu cầu sử dụng. Kiểu này được biết tới như là liên hợp của một đặc tả dịch vụ. Chỉ có một điểm khác biệt giữa một đặc tả dịch vụ và liên hợp của nó là các giao diện được cung cấp (nhận thức) và đòi hỏi (sử dụng) là được đảo chỗ. Mọi thứ khác trong lớp là giống nhau, bao gồm cả hành vi mô hình hoá giao thức dịch vụ. Ví dụ, cân nhắc giao diện dịch vụ InvoicingService. Hình 12 trình bày liên hợp của InvoicingService, gọi là ~InvoicingService.
Hình 12. ~InvoicingService, liên hợp của InvoicingService Quy ước được sử dụng ở đây là đặt tên liên hợp giống tên của đặc tả dịch vụ, chỉ khác là bắt đầu bằng ~. (kí hiệu dấu ngã). Bất cứ quy ước đặt tên nào đều có thể được sử dụng, nhưng nó phải được sử dụng nhất quán để thuận tiện nhận ra mối quan hệ giữa các kiểu này. ~InvoicingService có cấu trúc bên trong và các hành giống InvoidingService. Nó đơn thuần sử dụng các giao diện cung cấp bởi InvoicingService và nhận thức các giao diện được yêu cầu. Một mở rộng trong tương lai của IBM Software Service Profile dành cho UML có thể giới thiệu khái niệm về cổng yêu cầu để phân biệt nhu cầu với khả năng. Khi đó, một cổng yêu cầu có thể sử dụng cùng kiểu với cổng dịch vụ, cách này loại bỏ được sự cần thiết về định nghĩa kiểu liên hợp. Một cổng yêu cầu sẽ chỉ ra các khả năng của dịch vụ đang được sử dụng, trong khi một cổng dịch vụ sẽ chỉ ra rằng chúng đang được cung cấp. Nội dung tiếp theo Bây giờ chúng ta đã kết thúc quá trình nhận dạng, đặc tả, và cài đặt (hay nhận thức) thiết kế của các dịch vụ, khách hàng, và nhà cung cấp dịch vụ cần thiết để đạt được các mục tiêu nghiệp vụ. Kết quả là một mô hình thiết kế trung lập về công nghệ của một giải pháp dịch vụ có kiến trúc. Nhưng chúng ta vẫn chưa tạo ra một khách hàng (consumer) dịch vụ mà có thể mang lại với nhau các dịch vụ được cung cấp bởi Invoicer, Productions, và Shipper và sử dụng chúng để lập một đơn
đặt hàng. Bài viết tiếp theo trong loạt năm bài viết này, "Mô hình hoá SOA: Phần 4. Các thành phần tạo lên dịch vụ," trình bày cách để tập hợp và kết nối những nhà cung cấp dịch vụ này và dàn dựng các tương tác của chúng để cung cấp một giải pháp hoàn thiện cho các yêu cầu nghiệp vụ.