-- Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ
|
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. 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. 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.
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.
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.
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:
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.
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.
Nhà cung cấp dịch vụ OrderProcessor được chứa trong gói 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.
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 ẩnChú ý 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 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.
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.
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 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:
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ụ.
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ú ý: 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:
Đâ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.
Sử dụng sự cộng tác, được gọi là 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.
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ệ 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. VNSON Corp sưu tầm |
Không có nhận xét nào:
Đăng nhận xét