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

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 Shi

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

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ềm

Thiết kế kiến trúc phần mềm IBM Rational Software Architect

Phát triển các Thực thi giải pháp IBM® Rational® Application Developer

dịch vụ Web 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

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 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