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

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

Thêm vào BST

Báo xấu

100
lượt xem 11
download

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

Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Đây là bài viết thứ tư trong loạt năm bài viết về cách thức tập hợp và kết nối các nhà cung cấp dịch vụ đã được mô hình hóa trong "Phần 3. Thực hiện dịch vụ" và dàn dựng các tương tác để cung cấp một giải pháp hoàn chỉnh cho các yêu cầu nghiệp vụ. Thành phần kết quả sẽ trở thành một thành phần dịch vụ cấu tạo lên các dịch vụ được...

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 4

Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Đây là bài viết thứ tư trong loạt năm bài viết về cách thức tập hợp và kết nối các nhà cung cấp dịch vụ đã được mô hình hóa trong "Phần 3. Thực hiện dịch vụ" và dàn dựng các tương tác để cung cấp một giải pháp hoàn chỉnh cho các yêu cầu nghiệp vụ. Thành phần kết quả sẽ trở thành một thành phần dịch vụ cấu tạo lên các dịch vụ được cung cấp bởi các thành phần người lập hóa đơn (Invoicer), sản phẩm (Productions), và người chuyển hàng (Shipper) để cung cấp một dịch vụ có khả năng xử lý các tiến trình của việc đặt hàng. Nó cũng chỉ ra cách thành phần dịch vụ này hoàn thành các yêu cầu nghiệp vụ đầu tiên. Về loạt bài viết này Trong các bài viết trước của loạt bài này (xem trong phần "Xem thêm thông tin về loạt bài viết", góc trên - bên trái), chúng tôi đã phác ra một cách tiếp cận tới việc xác định các dịch vụ được kết nối với các yêu cầu nghiệp vụ. Chúng tôi bắt đầu bằng việc nắm bắt các mục tiêu cần thiết để xác định nhiệm vụ nghiệp vụ. Tiếp đó, chúng tôi đã mô hình hóa các thao tác nghiệp vụ và các tiến trình để đạt được mục tiêu đề ra. Tiếp theo chúng tôi sử dụng tiến trình nghiệp vụ này như một hợp đồng giúp xác định các dịch vụ được yêu cầu và các mối quan hệ tiềm năng giữa chúng. Sau đó chúng tôi hoàn chỉnh các đặc tả các dịch vụ đã được xác định. Trong bài viết đầu tiên, Phần 1. Xác định dịch vụ, chúng tôi tìm cách tối đa hóa tiềm năng của giải pháp SOA bằng cách xác định các dịch vụ có liên quan đến nghiệp vụ. Chúng tôi thiết kế topo dịch vụ dựa trên các yêu cầu nghiệp vụ và kết nối những dịch vụ này trở lại với các dịch vụ cộng tác biểu diễn các yêu cầu hợp đồng sao cho giải pháp dịch vụ được hoàn thành.
Trong bài viết thứ hai, Phần 2. Đặc tả dịch vụ, chúng tôi mô hình hóa chi tiết các đặc tả dịch vụ. Một đặc tả dịch vụ định nghĩa mọi thứ các khách hàng cần thiết để quyết định xem họ có quan tâm và muốn sử dụng dịch vụ không và cách chính xác để sử dụng dịch vụ. Nó cũng chỉ ra mọi thứ mà nhà cung cấp dịch vụ phải biết để thực thi thành công dịch vụ. Trong Phần 3. Thực hiện dịch vụ chúng tôi mô hình hóa việc thực hiện kết quả đặc tả dịch vụ với nhà cung cấp dịch vụ: lập hóa đơn, sản phẩm, chuyển hàng. Mỗi một thành phần này cung cấp các dịch vụ và khả năng theo các đặc tả dịch vụ. Mỗi thao tác dịch vụ được cung cấp có một phương thức biểu diễn cách mà dịch vụ được thực thi chính xác. Phương thức đó có thể là một tiến trình UML bất kỳ, ví dụ như: một hoạt động (Activity), một tương tác (Interaction), một máy trạng thái (StateMachine), hoặc một ứng xử mờ (OpaqueBehavior). Việc lựa chọn phương thức là tùy thuộc vào người lập mô hình. "Mô hình SOA: Phần 5. Cài đặt dịch vụ", là bài viết cuối cùng trong loạt năm bài viết này, sử dụng kiến trúc phần mềm UML IBM® Rational® chuyển đổi thuộc tính sang SOA để tạo ra một việc thực thi các dịch vụ Web có thể được sử dụng trực tiếp bởi những người phát triển tương tác IBM® WebSphere® để cài đặt, kiểm tra và triển khai giải pháp đã hoàn thành. Nội dung của bài viết Trong bài viết này, chúng tôi tập hợp các nhà cung cấp dịch vụ được tạo ra trong bài viết thứ ba để sử dụng các khả năng của họ cho các nhà cung cấp dịch vụ khác. Nghĩa là, chúng tôi sẽ tạo ra một dịch vụ mới từ các thành phần của các dịch vụ khác. Kỹ thuật này có thể áp dụng đệ qui cho các thành phần dịch vụ một số lần bất kỳ, với một tập các dịch vụ quan tâm và ở mức trừu tượng hóa bất kỳ. Tuy nhiên, có thể có một số ràng buộc cấu trúc ảnh hưởng đến các hoạt động của dịch vụ, vấn đề về an ninh và hiệu suất, lượng dữ liệu trao đổi, giao thức truyền thông
và kết nối các vấn đề ràng buộc mà các dịch vụ được cung cấp bởi các thành phần đó. Những vấn đề này sẽ xác định kiến trúc giải pháp và không được trình bày trong loạt bài viết này. Hãy xem trong phần Thiết kế giải pháp SOA sử dụng một kiến trúc tham khảo để biết thêm chi tiết về những chủ đề quan trọng này. Trong cả loạt bài viết này, chúng tôi sử dụng các công cụ có sẵn như IBM® Rational® và IBM® WebSphere® để xây dựng các giải pháp nhân tạo rồi liên kết chúng lại sao cho chúng tôi có thể thẩm tra được giải pháp đó dựa vào các yêu cầu và quản lý việc thay đổi hiệu quả hơn. Bảng 1 tóm tắt tất cả các tiến trình chúng tôi sẽ thực hiện trong quá trình phát triển ví dụ và các công cụ được sử dụng để xây dựng lên các giải pháp nhân tạo. Bảng 1: Các công cụ, nhiệm vụ, vai trò của tiến trình phát triển. Vai trò Nhiệm vụ Các công cụ Quản trị nghiệpChuyển thành mục IBM® Rational® RequisitePro® tiêu nghiệp vụ vụ Phân tích các yêu Phân tích IBM® WebSphere® Business Modeler cầu của nghiệp vụ nghiệp vụ Kiến trúc phần Thiết kế kiến trúc IBM Rational Software Architect phần mềm mềm Thực thi giải pháp IBM® Rational® Application Developer Phát triển các
and WebSphere Integration Developer dịch vụ Web Xem lại việc thực thi dịch vụ Chúng ta cùng bắt đầu bằng việc xem xét các nhà cung cấp dịch vụ mà đã được cài đặt trong bài viết trước. Hình 1 chỉ ra nhà cung cấp dịch vụ lập hóa đơn. Hình 1. Nhà cung cấp dịch vụ lập hóa đơn Invoicer Một nhà cung cấp dịch vụ lập hóa đơn cung cấp dịch vụ giao thức lập hóa đơn InvoicingProtocol cho việc tính toán giá cả ban đầu cho mỗi hóa đơn đặt hàng và sau đó định nghĩa lại giá này khi thông tin vận chuyển hàng được biết. Tổng chi
phí của hóa đơn phụ thuộc vào nơi sản phẩm được sản xuất và nơi mà nó được chuyển đến. Giá ban đầu được tính có thể được sử dụng để xác nhận khách hàng có thẻ tín dụng hợp lệ hoặc muốn mua sản phẩm hay không. Đó là cách tốt nhất để hoàn thành một hóa đơn. Hình 2 chỉ ra nhà cung cấp dịch vụ sản xuất. Hình 2. Topo dịch vụ sản xuất Nhà cung cấp dịch vụ sản xuất sẽ cung cấp một dịch vụ lịch biểu để xác định nơi hàng hóa sẽ được sản xuất và sản xuất khi nào. Những thông tin này có thể được sử dụng để tạo ra lịch biểu vận chuyển hàng được sử dụng trong tiến trình giải quyết đơn đặt hàng. Hình 3 chỉ ra nhà cung cấp dịch vụ vận chuyển Shipper.
Hình 3. Nhà cung cấp dịch vụ vận chuyển Shipper Nhà cung cấp dịch vụ vận chuyển cung cấp dịch vụ ShippingService để chuyển hàng hóa đến với khách hàng theo thông tin trên hóa đơn bán hàng. Dịch vụ này yêu cầu giao diện của ScheduleProcessing để yêu cầu khách hàng xử lý lịch biểu hoàn chỉnh. Các thành phần của dịch vụ Khi các dịch vụ đã được cung cấp bởi một số nhà cung cấp, chúng ta đã sẵn sàng để sử dụng các nhà cung cấp này để hoàn thành các yêu cầu nghiệp vụ đầu tiên. Việc kết hợp và dàn dựng các dịch vụ này theo yêu cầu nghiệp vụ để cung cấp một phương thức cho dịch vụ mua hàng. Chúng ta sẽ tạo ra một thành phần OrderProcessor cung cấp một dịch vụ mua hàng để xử lý các hóa đơn đặt hàng. Nhà cung cấp dịch vụ này yêu cầu các dịch vụ phải được định nghĩa bởi các đặc tả dịch vụ InvoicingService, Scheduling, và ShippingService. Chúng ta sẽ tạo ra thêm một thành phần OrderProcessing, nó sẽ tập hợp các thể hiện của các thành phần Invoicer, Productions, và Shipper theo như thành phần OrderProcessor để thực thi các hoạt động của dịch vụ để xử lý các hóa đơn đặt hàng.
Nhà cung cấp dịch vụ Xử lý Hóa đơn Đặt hàng Dịch vụ xử lý hóa đơn đặt hàng được xác định bởi đặc tả dịch vụ mua hàng (xem hình 4) bao gồm một số khả năng (hay thao tác) sau: + processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice Dịch vụ này sẽ được cung cấp bởi một nhà cung cấp dịch vụ OrderProcessor. OrderProcessor là một thành phần cung cấp một dịch vụ bằng cách kết nối các nhà cung cấp dịch vụ khác nhau lại, chúng được dàn dựng theo các yêu cầu trong hợp đồng. Nghĩa là, một số bộ phận mà phương thức của dịch vụ cung cấp được thiết kế để sử dụng các nhà cung cấp dịch vụ khác theo một cách nhất định nào đó. Những thành phần này cung cấp giao diện mua hàng thông qua cổng dịch vụ mua hàng của nó. Tất cả các tương tác với khách hàng thông qua cổng này, bằng cách đó chúng ta tách được máy trạm khách hàng ra khỏi tương tác mà thành phần này có thể thực hiện với các dịch vụ khách hàng hoặc nhà cung cấp khác. Việc này sẽ hạn chế sự nối cặp trong mô hình, làm cho nó dễ dàng sửa đổi khi thị trường, dịch vụ khách hàng và nhà cung cấp thay đổi. Hình 4. Đặc tả dịch vụ mua hàng Việc tổ chức thành phần OrderProcessor được biểu diễn trong khung nhìn Project Explorer được chỉ ra trong hình 5.
Hình 5. Vùng chức năng nghiệp vụ quản lý hóa đơn (package - gói) Nhà cung cấp dịch vụ OrderProcessor được chứa trong gói org::ordermanagement, nó được sử dụng để tổ chức các dịch vụ liên quan đến quản lý hóa đơn. Gói quản lý hóa đơn cũng chứa các giao diện dịch vụ liên quan, dịch vụ khách hàng, nhà cung cấp dịch vụ. Sơ đồ OrderProcessor chỉ ra trong hình 6 cung cấp một khung nhìn mở rộng của nhà cung cấp dịch vụ xử lý hóa đơn OrderProcessor và các dịch vụ được cung cấp và được yêu cầu. (Các dịch vụ được yêu cầu đôi khi được gọi là các tiêu chuẩn đòi hỏi giúp phân biệt giữa nhu cầu và khả năng.) Khung nhìn mở rộng hay "hộp đen" là cái mà khách hàng của nhà cung cấp dịch vụ nhìn thấy. Cấu trúc bên trong của các thành phần, được chỉ ra trong ví dụ sau đây, sẽ cung cấp một khung nhìn bên trong hay "hộp trắng" về cấu trúc hỗ trợ việc thiết kế, cài đặt thành phần.
Hình 6. Nhà cung cấp dịch vụ OrderProcessor Khung nhìn mở rộng không phải là một đặc tả tách rời cài đặt. Nó là khung nhìn đơn giản về một số mặt của thành phần. Nếu người thiết kế kiến trúc hoặc người phát triển muốn tách biệt rõ ràng đặc tả của nhà cung cấp dịch vụ với việc cài đặt nó, một thành phần đặc tả sẽ được sử dụng. Một thành phần đặc tả định nghĩa một giao kèo giữa khách hàng và nhà cung cấp dịch vụ mà tách riêng chúng ra khỏi các cài đặt nhà cung cấp. Thành phần đặc tả có thể được thực hiện bởi rất nhiều thành phần cụ thể mà cung cấp các dịch vụ theo nghĩa là thực hiện hợp đồng và cung cấp chất lượng chấp nhận được của dịch vụ. Xem "Mô hình hóa SOA: Phần 2. Các đặc tả dịch vụ" để biết thêm chi tiết. Thành phần nhà cung cấp dịch vụ đủ đơn giản và ổn định, trong ví dụ này, nhà thiết kế kiến trúc hoặc nhà phát triển quyết định không sử dụng đặc tả dịch vụ. Kết quả là, bất kỳ khách hàng dịch vụ nào sử dụng thành phần OrderProcessor sẽ bị dính dáng tới việc cài đặt cá biệt này. Đây là kiểu thiết kế phụ thuộc vào số lượng
dịch vụ sẽ được sử dụng và số thay đổi có thể của chúng theo thời gian. Chỉ có kiến trúc giải pháp có thể quyết định mức độ móc nối có thể chấp nhận được với một hệ thống đặc biệt. Thành phần OrderProcessor cũng có các cổng dịch vụ biểu diễn các tiêu chuẩn đòi hỏi cho các nhu cầu được cung cấp bởi các nhà cung cấp dịch vụ khác: lập hóa đơn, lập lịch, vận chuyển hàng. Các nhà cung cấp dịch vụ này cung cấp các dịch vụ được sử dụng bởi thành phần OrderProcessor để cài đặt các thao tác dịch vụ mà nó cung cấp. Mỗi điểm tương tác dịch vụ được gộp trong một giao thức đơn giản ảnh hưởng đến các giao diện được cung cấp hoặc được yêu cầu. Ví dụ: điểm tương tác lập hóa đơn yêu cầu giao diện lập hóa đơn để tính toán giá ban đầu và gửi đi giá vận chuyển. Tuy nhiên, có thể sẽ tốn thời gian để tính giá vận chuyển, do đó dịch vụ OrderProcessor cung cấp giao diện InvoiceProcessing thông qua cổng lập hóa đơn của nó sao cho nhà cung cấp dịch vụ lập hóa đơn có thể gửi đi một hóa đơn khi nó sẵn sàng. Vấn đề về sự mắc nối tiềm ẩn Chú ý rằng có một vấn đề thiết kế tiềm năng có thể sinh ra sự mắc nối không mong muốn. Các quy tắc chỉ ra cách một nhà cung cấp dịch vụ hóa đơn tương tác với việc lập hóa đơn được bắt giữ lại trong cùng một tiến trình nghiệp vụ như là các qui tắc cho việc giao tiếp với các nhà cung cấp dịch vụ lập lịch và vận chuyển hàng hóa. Điều đó làm cho chúng ta rất khó khăn trong việc sử dụng lại các dịch vụ lập hóa đơn, lập lịch, vận chuyển mà không làm tăng các giao thức tương tác. Việc mắc nối này thường ảnh hưởng đến các kết quả của việc cài đặt trực tiếp các tiến trình nghiệp vụ cũng như các thao tác dịch vụ. Các mô hình xử lý nghiệp vụ tập trung vào các bước trong một thao tác cần thiết để hoàn thành một mục tiêu nghiệp vụ đặc biệt, chẳng hạn như hiệu quả của việc xử lý hóa đơn. Các mô hình
này thường không chú trọng vào cách các bước tăng sự liên kết, giảm sự mắc nối, dễ sử dụng lại, tối thiểu hóa sự quá tải thông tin được phân phối, xử lý an ninh mạng, quản lý sự tương tác của dữ liệu, ... Tất cả các mối quan tâm đến giải pháp IT phải dùng các kiến trúc phần mềm và các mô hình thiết kế đã được kiểm nghiệm và xác minh. Việc sử dụng các hợp đồng dịch vụ cung cấp một cách để chính thức bắt giữ lại các yêu cầu nghiệp vụ, đồng thời cho phép sản xuất lại theo kiến trúc của nhà cung cấp dịch vụ và đạt được các yêu cầu nghiệp vụ và các giải pháp IT quan tâm. Liên kết giữa các giải pháp kiến trúc và yêu cầu nghiệp vụ được thông qua hợp đồng hoàn chỉnh, chúng kết nối các phần của các nhà cung cấp dịch vụ với các qui tắc mà chúng thực hiện trong hợp đồng dịch vụ. Chúng tôi không bàn tiếp về những vấn đề trong thiết kế ở ví dụ này nữa, nhưng chúng tôi sẽ chỉ ra cách để liên kết các giải pháp dịch vụ với các yêu cầu nghiệp vụ mà nó hoàn thành. Mô hình thiết kế cài đặt xử lý đặt hàng Đến đây, chúng ta đã hoàn thành kết cấu kiến trúc của mô hình dịch vụ và bắt giữ nó trong các khung nhìn mở rộng của các nhà cung cấp dịch vụ. Điều tiếp theo cần làm là thiết kế một phương thức cho thao tác dịch vụ của processPurchaseOrder được cung cấp bởi thành phần OrderProcessor. Phương thức thiết kế phải thích ứng với mọi hợp đồng dịch vụ đã hoàn thành từ trước hoặc các đặc tả dịch vụ đã thực hiện cũng như là các đặc tả dịch vụ mà trong đó các thao tác đã được định nghĩa. Cấu trúc bên trong Các nhà cung cấp dịch vụ OrderProcessor cung cấp một đặc tả dịch vụ đơn giản, việc mua hàng, thông qua cổng dịch vụ mua hàng của nó. Đặc tả dịch vụ này chỉ ra một thao tác đơn giản, processPurchaseOrder. Một nhà cung cấp phải cung cấp một số phương thức cho tất cả các thao tác dịch vụ mà nó cung cấp. Ví dụ này sử
dụng một thao tác (Activity) như là một phương thức của thao tác dịch vụ processPurchaseOrder. Chi tiết về cách làm được chỉ ra trong phần cấu trúc bên trong của thành phần OrderProcessor mà nó cung cấp dịch vụ. Cấu trúc bên trong thành phần OrderProcessor được bắt giữ trong các sơ đồ, giao diện, lớp và các hành động như được chỉ ra trong khung nhìn Project Explorer trong hình 7 và trên sơ đồ cấu trúc thành phần trên hình 8. Hình 7. Tổ chức của nhà cung cấp dịch vụ OrderProcessor Khung nhìn Project Explorer chỉ ra một danh sách các phần của nhà cung cấp OrderProcessor và một phương thức (cách thức) cho mỗi thao tác được cung cấp. Một ngầm định được dùng trong ví dụ này là sử dụng một sơ đồ các lớp có cùng tên với thành phần và trong gói chứa thành phần để chỉ ra khung nhìn mở rộng của
nó. Đây là sơ đồ được chỉ ra trong hình 6 và phần cuối của hình 7. Một sơ đồ cấu trúc thành phần của thành phần cùng tên và được chứa trong thành phần cung cấp khung nhìn bên trong của cấu trúc nhà cung cấp dịch vụ. Đây là sơ đồ trực tiếp dưới nhà cung cấp dịch vụ OrderProcessor trong hình 7. Những thỏa thuận ngầm này giúp ta dễ dàng kết hợp khung nhìn mở rộng và khung nhìn nội tại của các ứng cử viên tham gia dịch vụ, đồng thời khoanh vùng các sơ đồ cũng như thành phần. Sơ đồ cấu trúc thành phần OrderProcessor được chỉ ra trong hình 8 cung cấp một khung nhìn của cấu trúc bên trong của nhà cung cấp dịch vụ. Nó cũng chỉ ra các phần (cổng và thuộc tính) tạo lên cấu trúc tĩnh của thành phần. Hình 8: Cấu trúc bên trong của nhà cung cấp dịch vụ OrderProcessor Cấu trúc bên trong của thành phần OrderProcessor rất đơn giản. Nó bao gồm các cổng dịch vụ cho các giao diện được cung cấp hoặc được yêu cầu, cộng thêm một
số các thuộc tính khác lưu giữ trạng thái của nhà cung cấp dịch vụ. Thuộc tính ID được sử dụng để chỉ ra các thể hiện của nhà cung cấp dịch vụ. Thuộc tính này sẽ được sử dụng để lập mối tương quan giữa tương tác khách hàng và nhà cung cấp dịch vụ tại thời điểm chạy. Các thuộc tính Schedule (lịch biểu) và shippingInfo (thông tin vận chuyển) là những thông tin được dùng trong cài đặt thao tác dịch vụ processPurchaseOrder. Phương thức cho các thao tác dịch vụ đã được cung cấp Mỗi thao tác dịch vụ được cung cấp bởi một nhà cung cấp dịch vụ phải được thực hiện bởi: Behavior (Activity, Interaction, StateMachine, or OpaqueBehavior) là các • phương thức của thao tác AcceptEventAction (cho việc gọi không đồng bộ) hoặc AcceptCallAction • (cho yêu cầu hoặc các trả lời cuộc gọi đồng bộ) trong một thao tác Activity thuộc về thành phần. Nó cho phép một thao tác đơn Activity (thông thường) có nhiều hơn một mục nhập đồng thời, và nó tương ứng với các thao tác đa nhận trong ngôn ngữ thực thi xử lý nghiệp vụ (BPEL). Các thao tác AcceptEventActions này thường được sử dụng để xử lý việc gọi lại cho các thông tin trả về từ các CallOperationActions đồng bộ. Thành phần OrderProcessor có một ví dụ cho cả hai loại thực hiện dịch vụ. Thao tác processPurchaseOrder có một phương thức Activity với cùng tên. Hoạt động này, được chỉ ra trong hình 9, là một cách thức của nhà cung cấp dịch vụ tự cung cấp thao tác dịch vụ.
Hình 9: Việc thực thi thao tác dịch vụ processPurchaseOrder Sơ đồ này rất gần với sơ đồ WebSphere Business Modeler với cùng cách ứng xử. Các thao tác dịch vụ InvoiceProcessing và ScheduleProcessing đều được thực hiện thông qua các hành động sự kiện chấp nhận các xử lý processInvoice và processSchedule trong tiến trình. Chú ý rằng, các thao tác phù hợp trong giao diện được biểu hiện như là các thao tác trigger để chỉ ra khả năng đáp trả lại thao tác AcceptCallActions (tương tự như sự tiếp nhận và thao tác AcceptEventActions nơi mà trigger là một tín hiệu sự kiện - SignalEvent). Từ khóa trigger không phải là một phần của UML 2 và chỉ bao gồm việc làm nổi bật cách những thao tác này được thực hiện.
Chú ý: Những thao thác sẽ không được chấp nhận trừ khi hoạt động processPurchaseOrder đang chạy và dòng điều khiển đã đạt tới việc chấp nhận hai hành động. Nó chỉ ra việc thực thi một thao tác có thể được xác định khi các thao tác khác được giải đáp. Việc hoàn thành các hợp đồng dịch vụ Thành phần OrderProcessor bây giờ đã hoàn thành, nhưng vẫn còn hai việc phải làm: 1. Đầu tiên, chúng ta cần nối nhà cung cấp dịch vụ OrderProcessor với tiến trình nghiệp vụ mà đã được mô hình hóa các yêu cầu. 2. Sau đó, chúng ta cần tạo ra một hệ thống con kết nối các nhà cung cấp dịch vụ có khả năng cung cấp các yêu cầu về giao diện của OrderProcessor với các cổng dịch vụ thích hợp. Đây là kết quả trong một hệ thống con triển khai có thể chạy. Phần này sẽ xử lý các kết nối giải pháp SOA lại với các yêu cầu nghiệp vụ. Phần tiếp trình bày về việc triển khai hệ thống con. Thuật ngữ Hiện trạng các dịch vụ phần mềm IBM® diễn tả một sự cộng tác giữa các dịch vụ như là "Một tập các dịch vụ hoạt động cùng nhau một cách phù hợp theo một số các đặc tả qui trình". Về cơ bản thì đây là một hợp đồng chỉ ra cách một tập các dịch vụ được kết nối với nhau và được dàn dựng để đạt được một số mục tiêu, ví dụ cách mà các dịch vụ khác nên được cài đặt hoặc cách mà một số các mục tiêu nghiệp vụ có thể đạt được. Một dịch vụ cộng tác cũng có thể được dùng để diễn tả chính thức các yêu cầu cần phải đạt được. Sự tương tác giữa các mô hình xử lý
nghiệp vụ WebSphere Business và mô hình Rational Software Architect UML được thiết kế để khai thác các mối cộng tác như thể là đóng vai trò trung tâm trong việc diễn tả các yêu cầu. Nó chỉ ra tiến trình nghiệp vụ theo mô hình WebSphere Business Modeler như là một sự cộng tác khi nó được mở ra trong mô hình Rational Software Architect. Thuật ngữ sự cộng tác dịch vụ, hợp đồng các yêu cầu dịch vụ, và hợp đồng các yêu cầu dịch vụ thương mại đều có nghĩa tương tự nhau và đều sử dụng sự cộng tác để biểu diễn các yêu cầu và để chỉ ra cách một tập các dịch vụ được sử dụng cùng nhau. Sự khác nhau giữa các thuật ngữ đơn giản chỉ nhằm làm nổi bật sự cộng tác trong các ngữ cảnh đặc biệt. Không có bất cứ thứ gì trong phần này làm thay đổi cách mà thành phần OrderProcessor được dịch thành một thực thi SOA. Việc kết nối một thành phần với các hợp đồng dịch vụ chỉ diễn tả cách thành phần hoàn thành các yêu cầu được chỉ ra bởi dịch vụ đó. Nó không ảnh hưởng gì đến việc thực thi của các nhà cung cấp dịch vụ hoặc cách nó được chuyển thành giải pháp SOA. Tuy nhiên, sự liên kết phức tạp hơn một sự phụ thuộc đơn giản. Đặc biệt, nó chỉ ra các phần của một nhà cung cấp dịch vụ có vai trò trong hợp đồng các yêu cầu dịch vụ và cách ràng buộc trên thành phần để hoàn thành các ràng buộc trong nghiệp vụ. Nó giúp cho việc theo vết dễ dàng hơn, trợ giúp cho việc quản lý các thay đổi nhỏ và khả năng sử dụng sự hợp lệ của các mô hình để chắc rằng giải pháp đưa ra thực sự giải quyết được các yêu cầu. Hình 10 chỉ ra các yêu cầu của nhà cung cấp dịch vụ OrderProcessor, việc sử dụng một hợp đồng dịch vụ cung cấp khung nhìn vai trò trung tâm cho các tiến trình nghiệp vụ được tạo ra bởi việc phân tích nghiệp vụ. Việc sử dụng thêm một sự cộng tác với nhà cung cấp dịch vụ OrderProcessor để chỉ ra hợp đồng dịch vụ mà nó hoàn thành.
Hình 10: Việc hoàn thành một hợp đồng dịch vụ Sử dụng sự cộng tác, được gọi là hợp đồng trong hình 10, là một thể hiện của sự cộng tác dịch vụ tiến trình đặt hàng được chỉ ra trong hình 11. Nó chỉ ra rằng nhà cung cấp dịch vụ OrderProcessor hoàn thành các yêu cầu nghiệp vụ xử lý hóa đơn đặt hàng. Các kết nối chỉ ra phần nào của nhà cung cấp dịch vụ đóng vai trò gì trong hợp đồng dịch vụ. Ví dụ: cổng lập hóa đơn giữ vai trò lập hóa đơn (invoicing), cổng mua hàng đóng vai trò xử lý hóa đơn (orderProcessor). Những kết nối vai trò này không liên quan đến các kênh kết dịch vụ sẽ được diễn tả trong phần tiếp theo. Các kênh kết nối dịch vụ được sử dụng để kết nối các yêu cầu của khách hàng với nhà cung cấp dịch vụ trong các hệ thống con. Kết nối vai trò chỉ ra phần nào giữ vai trò gì trong một hợp đồng dịch vụ. Sự thể hiện một kết nối vai trò có thể chặt hoặc lỏng. Tính chặt của hợp đồng hoàn chỉnh có nghĩa là các phần phải tương thích về kiểu với vai trò mà nó đảm nhận. Tính lỏng của hợp đồng hoàn chỉnh nghĩa là các phần có vai trò như qui định trong kiến trúc, nhưng
tính hợp lệ của mô hình không và không thể kiểm chứng vai trò và sự tương thích của các phần. Đó là vì hợp đồng dịch vụ nghiệp vụ còn chưa hoàn thành hoặc mới chỉ có được những phác họa về các yêu cầu nghiệp vụ một cách không chính thức. Hình 11: Hợp đồng các yêu cầu dịch vụ
Việc chỉ ra cách giải pháp SOA hoàn thành các yêu cầu nghiệp vụ dẫn đến phải làm thêm việc chỉ ra hợp đồng và các kết nối vai trò, nhưng nó cung cấp một sự thuận tiện rất lớn cho việc quản lý sự thay đổi. Mô hình truy vấn có thể được sử dụng để xác định nhà cung cấp dịch vụ nào hoàn thành các yêu cầu nghiệp vụ nào, bất cứ sự thay đổi đó là về yêu cầu hay kết quả của một sự thay đổi vai trò trong một sự cộng tác dịch vụ. Nhà xây dựng mô hình có thể chuyển trực tiếp đến phần có vai trò tương ứng để xác định cách các đặc tả dịch vụ của các phần cần phải thay đổi để đạt được sự thay đổi trong yêu cầu. Sự hợp lệ của mô hình cũng có thể được sử dụng để xác định xem có vai trò nào đã thay đổi, và do đó, những phần đóng vai trò đó trong giải pháp SOA có còn khả năng thực hiện tất cả các vai trò mà nó đảm nhận hay không. Điều này thể hiện mạnh hơn những sự phụ thuộc thuần túy mà không trợ giúp được gì về ngữ nghĩa hay làm mất ngữ nghĩa của các thực hiện. Nó cũng là một cách chính thức để thẩm tra kết nối giữa giải pháp SOA và các yêu cầu nghiệp vụ để chắc chắn rằng, nghiệp vụ có liên quan phù hợp với các yêu cầu và cho phép giải pháp nhanh chóng dễ dàng thích ứng được với các thay đổi. Việc tập hợp các hệ thống con của OrderProcessing Điều cuối cùng cần làm trong giải pháp SOA là tạo ra hệ thống con OrderProcessing sử dụng các nhà cung cấp dịch vụ mà ta đã thực thi ở trên và tập hợp các phần đó thành một giải pháp có thể triển khai. Hệ thống con được chỉ ra trong hình 12 trình bày thành phần có thể triển khai mà kết nối một nhà cung cấp dịch vụ OrderProcessor với các nhà cung cấp dịch vụ khác mà cung cấp các dịch vụ mà nó yêu cầu. Hệ thống con này là một sự tập hợp các thành phần mà cung cấp tất cả thông tin cần thiết để triển khai và chạy các dịch vụ OrderProcessor.