-- Mô hình hóa SOA: Phần 3. Thực hiện dịch vụ
|
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:
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:
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.
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.
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 3 trình bày đặc tả dịch vụ Hình 3. Đặc tả dịch vụ Scheduling Hình 4 trình bày đặc tả dịch vụ
Đặ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 Hình 5. Đặc tả dịch vụ InvoicingService
Hình 6. Đặc tả dịch vụ Purchasing 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.
Đặ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 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ụ
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 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:
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 Hoạt động 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 đó.
Các phương thức thao tác dịch vụ là các hành vi 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 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ụ
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ụ
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. 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ụ. VNSON Corp sưu tầm |
Không có nhận xét nào:
Đăng nhận xét