Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ

Đâ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.

Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM

Jim Amsden là một nhân viên kỹ thuật lâu năm tại IBM với hơn 20 năm kinh nghiệm thiết kế và phát triển các ứng dụng và công cụ cho công nghiệp phát triển phần mềm. Ông có bằng Thạc sĩ về Khoa học Máy tính tại trường Boston. Sở thích của ông là phát triển các yêu cầu, lập trình mạng, phát triển hướng dịch vụ, J2EE UML, và các kiến trúc định hướng dịch vụ. Ông là đồng tác giả của cuốn "Enterprise Java Programming with IBM WebSphere". Hiện tại, Jim tập trung tìm cách tích hợp các công cụ để hỗ trợ tốt hơn cho quá trình phát triển phối hợp.



06 07 2009

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ệp vụChuyển thành mục tiêu nghiệp vụIBM® Rational® RequisitePro®
Phân tích nghiệp vụPhân tích các yêu cầu của nghiệp vụIBM® WebSphere® Business Modeler
Kiến trúc phần mềmThiết kế kiến trúc phần mềmIBM Rational Software Architect
Phát triển các dịch vụ WebThực thi giải phápIBM® Rational® Application Developer and WebSphere Integration Developer

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
Nhà cung cấp dịch vụ lập hóa đơn

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
Sơ đồ 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
Sơ đồ nhà cung cấp dịch vụ vận chuyển

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
Sơ đồ đặ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)
Màn hình biểu diễn vùng chức năng nghiệp vụ quản lý hóa đơn

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
Sơ đồ 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
Sơ đồ 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
Sơ đồ 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) 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ơ đồ 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ơ đồ về 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ụ
Sơ đồ 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.

Hình 12: Việc tập hợp các phần thành một hệ thống con có thể triển khai
Sơ đồ việc tập hợp các phần thành một hệ thống con có thể triển khai

Hệ thống con OrderProcessing chứa các thể hiện của các thành phần dịch vụ xử lý hóa đơn, lập hóa đơn, sản phẩm, và vận chuyển (OrderProcessor, Invoicer, Productions, và Shipper). Dịch vụ lập hóa đơn của thành phần người bán (seller) được kết nối với dịch vụ lập hóa đơn (invoicing) của thành phần Invoicer. Đây là một kết nối đúng bởi vì đặc tả dịch vụ của dịch vụ lập hóa đơn của thành phần OrderProcessor là một sự kết hợp của dịch vụ lập hóa đơn của nhà cung cấp dịch vụ Invoicer provider. Nó cũng cung cấp cả giao diện xử lý hóa đơn InvoiceProcessing để người nhập hóa đơn có thể nhận được việc cập nhật thông tin về việc lập hóa đơn.

Kết nối các dịch vụ (các thể hiện của đặc tả dịch vụ) nghĩa là các ứng viên đồng ý tương tác thông qua bộ nối theo đặc tả dịch vụ. Nghĩa là chúng cho phép giao thức được yêu cầu hoạt động. Các đặc tả dịch vụ định nghĩa các vai trò mà chúng kết nối các ứng viên trong một giao thức. Bộ kết nối kênh dịch vụ giữa cổng lập hóa đơn của bộ xử lý đặt hàng khách hàng và cổng lập hóa đơn của nhà cung cấp việc lập hóa đơn có một hợp đồng (một cách thức), đó là dịch vụ lập hóa đơn (InvoicingService) ứng xử theo đặc tả dịch vụ của nó. Tên của bộ nối là một tập tên của hợp đồng của nó theo qui ước. Bất cứ sự tương tác nào giữa những bộ nối này được yêu cầu phải theo hợp đồng hoặc giao thức đó. Nhũng bộ kết nối này chính thức hóa việc dùng sự phụ thuộc trong kiến trúc dịch vụ.

Chú ý rằng bộ nối giữa các phần của nhà cung cấp và người bán là không có hợp đồng giao ước. Đó là bởi vì không có giao thức nào trong giao diện dịch vụ lập lịch Scheduling; do đó, không có hợp đồng nào cần cho một bộ nối.

Các khách hàng khác và nhà cung cấp dịch vụ cũng được kết nối tương tự. Các dịch vụ kết nối có thể đưa ra các kiểu kết nối khác nhau. Kênh dịch vụ giữa các điểm tương tác dịch vụ có thể xác định chính xác loại kết nối nào được dùng.

Hệ thống con OrderProcessing bây giờ đã hoàn thành và sẵn sàng để triển khai. Nó có các thể hiện riêng cho tất cả các nhà cung cấp dịch vụ được yêu cầu cần thiết để thực thi đầy đủ dịch vụ xử lý hóa đơn đặt hàng processPurchaseOrder. Sau khi nó được triển khai, các khách hàng sử dụng dịch vụ khác có thể kết nối tới dịch vụ mua hàng của thành phần OrderProcessor của người bán hàng và gọi ra các hoạt động của dịch vụ.

Tóm tắt lại nội dung đã trình bày và nội dung của phần tiếp theo

Đến đây chúng ta đã hoàn thành việc xác định, đặc tả, thực hiện các dịch vụ, khách hàng và nhà cung cấp cần thiết để đạt được các mục tiêu nghiệp vụ. Kết quả tuy chưa phải là một công nghệ rõ ràng những là mô hình thiết kế hoàn chỉnh của một giải pháp dịch vụ có kiến trúc.

Để thực sự chạy được giải pháp, chúng ta cần tạo ra một nền thực thi chắc chắn với các quyết định về thiết kế kiến trúc được bắt giữ lại trong mô hình các dịch vụ. Chúng ta có thể tạo ra giải pháp thủ công, sử dụng mô hình như là một tài liệu hướng dẫn. Nhưng điều này dễ gây ra sự mệt mỏi, dễ mắc lỗi, trong khi yêu cầu người phát triển phải có kỹ năng cao và hiểu chắc chắn về những quyết định về kiến trúc được cài đặt đúng. Tất nhiên là có thể tạo ra giải pháp một cách thủ công và việc có mô hình như là tài liệu hướng dẫn là rất hữu ích. Nhưng việc có một mô hình hoàn chỉnh, chính qui và đã được xác thực cho phép chúng ta có cơ hội để khám phá phương pháp phát triển mô hình hiện đại (MDD) để tạo ra một khung giải pháp từ mô hình trên và sau đó hoàn thành việc viết mã chi tiết trong một môi trường lập trình trên nền đặc biệt nào đó. Đây là chủ đề của bài viết tiếp theo trong loạt bài viết này với nội dung: "Mô hình hóa SOA: Phần 5. Cài đặt dịch vụ." Trong bài viết này chúng tôi sử dụng việc chuyển đổi đặc tính từ kiến trúc phần mềm quan hệ UML (Rational Software Architect UML) sang kiến trúc SOA để tạo ra các giải pháp dịch vụ Web có thể được sử dụng trực tiếp trong bộ phát triển web tích hợp WebSphere Integration Developer để cài đặt, kiểm tra, và triển khai một giải pháp hoàn chỉnh.


Tải về

Mô tảTênKích thước
RSM sample modelRSM_sample_model.zip60KB

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational, SOA và dịch vụ Web
ArticleID=406422
ArticleTitle=Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ
publish-date=07062009