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

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ụ 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ụ 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 [...]... 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ụ,"... 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... 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... 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ả... 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... 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... đượ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ụ,... 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...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... 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 . 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ụ. 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. 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