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 khi các
Trang 1Mô 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
Trang 2dị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
Trang 32 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
Trang 4Cũ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
Nhà điều hành
nghiệp vụ
Truyền đạt mục đích
và mục tiêu nghiệp
vụ
IBM® Rational® RequisitePro®
Nhà phân tích
nghiệp vụ
Phân tích các nhu cầu nghiệp vụ IBM® WebSphere® Business Modeler
Kiến trúc sư
phần mềm
Thiết kế kiến trúc của giải pháp IBM Rational Software Architect
Nhà phát triển
dịch vụ Web Cài đặt giải pháp
IBM® Rational® Application Developer và IBM® WebSphere® Integration Developer
Xem lại xác định và đặc tả dịch vụ
Trang 5Hã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ụ
Trang 6Nhắ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
Trang 7Hì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
Trang 8trừ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
Trang 9Hì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:
Trang 10Hì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
Trang 11phứ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ử
Trang 12dụ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
<<serviceProvider>> đượ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 <<service>> 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
Trang 13Hì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 <<service>> 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
Trang 14diệ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ể
