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

Những hợp đồng này bao gồm các giao diện được yêu cầu và được cung cấp, các giao diện đó đóng vai trò gì trong các đặc tả dịch vụ cũng như các quy tắc hoặc giao thức cho các vai trò đó t

Mô hình hóa SOA: Phần 2 Đặc tả dịch vụ

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

Tóm tắt: Trong bài viết thứ hai của loạt năm bài này, chúng ta tiếp tục xác định

giải pháp SOA bằng mô hình đặc tả chi tiết cho mỗi dịch vụ Những đặc tả này sẽ xác định rõ những hợp đồng giữa các khách hàng và các nhà sản xuất dịch vụ Những hợp đồng này bao gồm các giao diện được yêu cầu và được cung cấp, các giao diện đó đóng vai trò gì trong các đặc tả dịch vụ cũng như các quy tắc hoặc giao thức cho các vai trò đó tương tác với nhau như thế nào

Nội dung của bài viết này

Bài viết đầu tiên trong loạt bài, "Mô hình SOA: Phần 1 Xác định dịch vụ" (xem

Đọc thêm trong loạt bài này, ở góc trên bên trái), chỉ ra một hướng tiếp cận cho

việc xác định những dịch vụ được kết nối với các yêu cầu nghiệp vụ Chúng ta bắt đầu bằng việc thu thập các mục tiêu và các đối tượng cần thiết để thực hiện những nhiệm vụ nghiệp vụ Sau đó chúng ta mô hình hóa các hoạt động và các tiến trình nghiệp vụ đó thành những mục tiêu và những đối tượng Tiếp theo chúng ta coi tiến trình nghiệp vụ như là một sự cộng tác dịch vụ mà đại diện là một hợp đồng những Yêu cầu Dịch vụ nghiệp vụ phải được hoàn thành bằng giải pháp của chúng

ta Sau đó chúng ta sử dụng bản hợp đồng những yêu cầu đó xác định các dịch vụ yêu cầu và các mối quan hệ tiềm ẩn giữa chúng Nó cũng cung cấp một chuẩn để xác định những dịch vụ nghiệp vụ liên quan được liên kết với những mục tiêu và những đối tượng nghiệp vụ mà chúng ta hi vọng hoàn thiện

Trong bài viết trước, chúng ta cũng xem xét làm thế nào để tối đa hóa tiềm năng của một giải pháp SOA bằng việc xác định những dịch vụ nghiệp vụ có liên quan Chúng ta đã thiết kế cấu trúc liên kết dịch vụ (service topology) dựa trên những yêu cầu nghiệp vụ cũng như đã kết nối những dịch vụ với sự cộng tác dịch vụ mà

đại diện cho chúng là những bản hợp đồng Yêu cầu Dịch vụ sao cho giải pháp dịch vụ phải hoàn thành

Trong bài viết thứ hai, chúng ta tiếp tục xác định giải pháp SOA bằng mô hình đặc

tả chi tiết cho mỗi dịch vụ Các đặc tả này sẽ xác định rõ những hợp đồng giữa các khách hàng và các nhà sản xuất dịch vụ Những hợp đồng này bao gồm các giao diện được yêu cầu và được cung cấp, các giao diện đó đóng vai trò gì trong những đặc tả dịch vụ, cũng như các quy tắc hoặc giao thức cho những vai trò đó tương tác với nhau như thế nào

Tổng quan về đặc tả dịch vụ

Bây giờ chúng ta đã sẵn sàng bắt đầu mô hình hóa những chi tiết của các đặc tả dịch vụ Một đặc tả dịch vụ phải chỉ ra mọi thứ mà một khách hàng tiềm năng của dịch vụ cần biết để ra quyết định nếu họ quan tâm đến việc sử dụng dịch vụ cũng như làm thế nào để họ sử dụng dịch vụ một cách chính xác Nó cũng phải chỉ rõ tất cả những gì mà một nhà cung cấp dịch vụ phải biết để thực hiện dịch vụ một cách thành công Vì vậy, một đặc tả dịch vụ là một "người dàn xếp" hoặc một bản hợp đồng giữa những gì khách hàng cần và những gì nhà cung cấp dịch vụ cung cấp

Thật lý tưởng, thông tin này được cung cấp ở một chỗ Điều này làm cho việc tìm kiếm những vị trí chứa tài sản cho các dịch vụ sử dụng lại một cách dễ dàng và có được tất cả những thông tin cần thiết mà không phải trình duyệt nhiều tài liệu khác nhau hoặc tìm kiếm trên những phần tử có liên quan Các đặc tả dịch vụ bao gồm tối thiểu những thông tin sau:

• Tên dịch vụ, dùng để chỉ mục đích của dịch vụ

• Các giao diện được cung cấp và được yêu cầu, theo đó xác định những khả năng hoạt động được cung cấp bởi dịch vụ và những yêu cầu của khách

hàng Chú ý: Điều này không bao gồm việc dịch vụ được thực thi như thế

nào, đúng hơn là tương tác giữa các khách hàng và các nhà cung cấp dịch

• Chất lượng mà các khách hàng dịch vụ mong đợi và các nhà cung cấp được

hi vọng sẽ cung cấp như chi phí, tính sẵn có, hiệu suất, dấu chân, khả năng thích ứng với nhiệm vụ, thông tin cạnh tranh và v.v

• Các chính sách cho việc sử dụng dịch vụ như chính sách an ninh, những phạm vi giao tác cho việc duy trì an ninh cũng như tính toàn vẹn hoặc cho việc phục hồi dịch vụ hay dịch vụ được yêu cầu nhưng không có khả năng thực hiện thành công

Giống như tất cả những bài viết trong loạt bài này, chúng ta sử dụng các công cụ IBM® Rational® và IBM® WebSphere® hiện có để xây dựng giải pháp và liên kết chúng với nhau, do đó chúng ta có thể thẩm định giải pháp đối với những yêu cầu và quản lý thay đổi một cách hiệu quả hơn Bảng 1 tóm tắt tiến trình mà chúng

ta sẽ dùng để phát triển ví dụ cũng như những công cụ chúng ta sẽ sử dụng để xây dựng các thành phẩm Ngoài ra chúng ta mở rộng ngôn ngữ mô hình hóa hợp nhất (UML) cho mô hình các dịch vụ bằng việc thêm IBM® Software Services Profile vào các mô hình UML trong IBM® Rational® Software Architect

Bảng 1: Tiến trình phát triển các vai trò, các nhiệm vụ và các công cụ

Vai trò Nhiệm vụ Các công cụ

Quản lý Giao

dịch

Chuyển các mục đích

và các đối tượng nghiệp vụ

IBM® Rational® RequisitePro®

Xem lại xác định dịch vụ

Hãy xem lại những yêu cầu nghiệp vụ và những dịch vụ được xác định để đáp ứng chúng, chúng ta đã mô tả chi tiết trong "Mô hình SOA: Phần 1 Xác định dịch vụ." Hình 1 biểu diễn các yêu cầu nghiệp vụ như là một sự cộng tác của những vai trò trong nghiệp vụ đó, những trách nhiệm của vai trò và các quy tắc cho những vai trò đó tương tác

Hình 1 Hợp đồng Các yêu cầu Dịch vụ

Sự cộng tác dịch vụ này thể hiện bằng một hợp đồng các yêu cầu lấy ra từ một

tiến trình nghiệp vụ Nó chỉ rõ giải pháp dịch vụ gì phải thực hiện Sự cộng tác dịch vụ này là một kiến trúc trung gian nhưng đặc tả của các yêu cầu chuẩn hóa

không quá ràng buộc vào giải pháp SOA Bằng kiến trúc trung gian, hợp đồng

các yêu cầu chỉ ra rằng giải pháp đang làm là gì chứ không phải là làm như thế nào

Hình 2 biểu diễn tổng quan về các đặc tả dịch vụ đã xác định sẽ tạo thành giải

pháp và dùng những phụ thuộc để chỉ ra chúng được sử dụng như thế nào

Hình 2 Cấu trúc liên kết dịch vụ

Cuối cùng, hình 3 chỉ ra bạn có thể sử dụng các dịch vụ đó như thế nào để hoàn thành những yêu cầu nghiệp vụ của mình

Hình 3 Kết nối hợp đồng Các Yêu cầu Dịch vụ

Điều này hoàn thành việc xác định các dịch vụ và chúng có liên quan đến những yêu cầu nghiệp vụ như thế nào Phần còn lại của bài viết này giải thích việc mô hình hóa một cách chi tiết những đặc tả dịch vụ như thế nào Những đặc tả dịch vụ này là một bản mô tả tỉ mỉ các giao diện được biểu diễn trong hình 2 Chúng cung cấp nhiều chi tiết đã liệt kê trong phần Tổng quan

Khi các giao diện hoàn thành, bạn vẫn chưa biết được những người tham gia dịch

vụ nào sẽ cung cấp hoặc yêu cầu những dịch vụ được mô tả bởi các giao diện, và bạn cũng không biết những khả năng dịch vụ được thực thi như thế nào, việc sử dụng các dịch vụ khác một cách hợp lý Ở bài viết tiếp theo chúng ta sẽ đề cập đến vấn đề này khi chúng ta đưa ra chủ đề thực hiện dịch vụ

Các loại đặc tả dịch vụ

Một đặc tả dịch vụ cần cung cấp các thông tin sau:

• Tên dịch vụ, dùng để chỉ dịch vụ đó về cái gì hoặc nó làm gì

• Các giao diện được cung cấp và được yêu cầu, miêu tả các khả năng hoạt động của dịch vụ Mỗi khả năng hoạt động bao gồm:

o Tên của nó, thường là các cụm động từ để chỉ nó làm cái gì

o Đầu vào và đầu ra dữ liệu dịch vụ bắt buộc hoặc không bắt buộc

o Các tiền điều kiện mà các khách hàng sẽ đáp ứng trước khi sử dụng khả năng

o Các hậu điều kiện mà những khách hàng có thể đòi hỏi và những nhà cung cấp phải cung cấp nhờ vào việc dùng khả năng một cách

thành công

o Các ngoại lệ hoặc các điều kiện sai phải được đưa ra nếu khả năng

có thể không được cung cấp vì lí do nào đó, cho dù là các tiền điều kiện thỏa mãn

• Giao thức liên lạc hoặc những quy tắc xác định khi những khả năng có thể được sử dụng hoặc theo trật tự gì

• Các khả năng mà khách hàng mong được cung cấp để có thể sử dụng hoặc tương tác với dịch vụ

• Các yêu cầu mà những người thực thi phải làm khi cung cấp dịch vụ

• Các ràng buộc phản ánh việc sử dụng dịch vụ nhằm đạt được thành công gì

và nó sẽ được đánh giá như thế nào

• Chất lượng của dịch vụ mà các khách hàng mong muốn và hi vọng những nhà cung cấp dịch vụ sẽ cung cấp như: chi phí, tính sẵn có, hiệu suất, dấu chân, khả năng phù hợp với nhiệm vụ, thông tin cạnh tranh, v.v

• Các chính sách cho việc sử dụng dịch vụ như chính sách an ninh và những phạm vi nghiệp vụ cho việc duy trì tính toàn vẹn hay cho việc phục hồi từ việc thực hiện dịch vụ hoặc dịch vụ đã yêu cầu không có khả năng thành công

Rõ ràng là ở đây có rất nhiều thông tin nhưng không phải tất cả đều được đưa ra trong bài viết này Cụ thể, chúng ta sẽ không xem xét đến chất lượng của các dịch

vụ hoặc những chính sách Những điều này đủ phức tạp để tạo thành các bài viết riêng cho chúng Hơn nữa chúng có thể được cụ thể hóa với những nhà cung cấp dịch vụ riêng, bản thân nó không cần giao diện dịch vụ riêng Thay vào đó, chúng

ta sẽ tập trung vào những nguyên tắc cơ bản cần thiết cho việc định nghĩa và sử dụng một dịch vụ

Những đoạn tiếp theo đề cập một cách chi tiết cho mỗi đặc tả dịch vụ đã xác định được trình bày ở Hình 2 Trật tự trình bày sẽ từ đặc tả dịch vụ đơn giản mà không

có giao thức, đến một đặc tả dịch vụ biểu diễn một giao thức yêu cầu/đáp ứng đơn giản, rồi đến một dịch vụ phức tạp có chứa một giao thức đa bước cùng với tương tác giữa khách hàng và nhà cung cấp

Hình 4 Đặc tả dịch vụ Lập lịch

Đặc tả dịch vụ Lập lịch là một giao diện UML đơn giản được định nghĩa trong gói các sản phẩm Nó cung cấp hai thủ tục dịch vụ Mỗi thủ tục có thể có các tiền điều kiện và các hậu điều kiện và chúng có thể đưa ra các ngoại lệ Các tham số của các thủ tục dịch vụ được yêu cầu có thể là dữ liệu (các thông điệp) dịch vụ hoặc các kiểu nguyên thủy Điều này đảm bảo rằng những tham số thực sự không có giả thiết về việc gọi theo tham chiếu hoặc gọi theo tham trị, nơi mà dữ liệu dịch vụ được định vị (trong không gian địa chỉ gì), cho dù khách hàng và nhà cung cấp dịch vụ đang thực hiện trên một bản sao dữ liệu hoặc những nguồn dữ liệu bền v.v Tất cả những thứ được yêu cầu đó để đảm bảo rằng dịch vụ không bị ràng buộc bởi nơi mà nó có thể bị phá hủy trong mối quan hệ với các dịch vụ khác Dữ liệu dịch vụ được định nghĩa trong phần Mô hình dữ liệu dịch vụ tiếp theo

Dịch vụ Vận chuyển (Shipping service)

Dịch vụ Vận chuyển là một giao thức ít phức tạp hơn Một khách hàng muốn vận

chuyển các sản phẩm thì yêu cầu dịch vụ vận chuyển Tuy nhiên, nó có thể đưa ra

thời gian cho nhà vận chuyển xác định xem các sản phẩm được đặt ở đâu, cho dù

chúng đang sẵn có trong kho hoặc đang được sản xuất, và chi phí hiệu quả nhất để gửi các sản phẩm Vì vậy, đó có thể là một khoảng thời gian trước khi lịch biểu vận chuyển có hiệu lực Nói chung, khách hàng sẽ không muốn chờ đợi cho đến khi lịch biểu được hoàn thành bởi vì điều này có thể ngăn cản các công việc khác đang diễn ra song song hoặc việc thỏa thuận không cần thiết giữa các tài nguyên

hệ thống với những tiến trình hoạt động lâu dài

Do đó, các kiến trúc sư Công nghệ Thông tin quyết định sử dụng một đáp ứng yêu cầu đơn giản hoặc giao thức gọi lại giữa khách hàng và nhà cung cấp Khách hàng yêu cầu vận chuyển và sau đó đáp ứng lại một yêu cầu từ người vận chuyển để xử

lý lịch biểu đầu đủ Để mô hình hóa giao thức này chúng ta cần chỉ rõ những vai

trò, trách nhiệm của nhà sản xuất và khách hàng, giao thức hoặc các quy tắc để

họ tương tác với nhau như thế nào Nội dung cuối này là quan trọng bởi vì người vận chuyển sẽ không có khả năng gửi một lịch biểu nếu họ không bao giờ nhận được một yêu cầu vận chuyển

Một đặc tả dịch vụ sẽ cho bạn mọi thứ bạn cần biết về một dịch vụ Nó bao gồm

cả những yêu cầu mà bạn phải đáp ứng để sử dụng dịch vụ (đôi khi được gọi là hợp đồng Quyền sử dụng hoặc Cách sử dụng, xem bài viết của Daniels và

Cheesman được liệt kê trong phần Các tài nguyên), cộng với các yêu cầu mà một

người thực hiện dịch vụ phải đáp ứng (đôi khi được gọi là hợp đồng Thực hiện)

Điều này cũng giống với loại thông tin mà bạn cần thu nhận cho những yêu cầu nghiệp vụ; ngoại trừ phạm vi đối tượng và mức độ chi tiết là khác nhau Đòi hỏi những thông tin này vì bạn đang xác định chi tiết trong một bản hợp đồng các Yêu cầu Dịch vụ để cho một khách hàng và nhà cung cấp dịch vụ tương tác với nhau như thế nào

Trong trường hợp này chúng ta sử dụng một lớp trừu tượng để định nghĩa đặc tả dịch vụ như biểu diễn trong Hình 5

Hình 5 Đặc tả dịch vụ Vận chuyển

Đặc tả ShippingService bao gồm hai vai trò:

• Vai trò người vận chuyển (shipper) là vai trò của nhà cung cấp Nó có

nghĩa vụ hoàn thành các nhiệm vụ vận chuyển được đưa ra bởi kiểu của nó

và giao diện vận chuyển

• Vai trò người đặt hàng (orderer) có trách nhiệm với việc xử lý lịch biểu

vận chuyển Điều này được biểu diễn qua kiểu ScheduleProcessing của nó

Không cần thiết phải chỉ rõ những vai trò này cho nhà cung cấp và khách hàng Đó

là những vấn đề đặc biệt trong cuộc đối thoại lâu dài có thể liên quan đến nhiều bên Cũng dễ nhận ra một thực tế là khách hàng và nhà cung cấp là đối tượng mà

đặc tả dịch vụ thực hiện giao diện vận chuyển đã cung cấp và sử dụng giao diện ScheduleProcessing đã yêu cầu

Có một mối liên hệ giữa những vai trò của người vận chuyển và người đặt hàng Điều này chỉ ra rằng giao thức có chứa sự tương tác giữa những vai trò này

Tương tác requestShipping thuộc lớp ShippingService cho biết tương tác này là gì

Tương tác ShippingService chỉ rõ những khía cạnh hành vi hoặc những khía cạnh động của sự tương tác giữa những vai trò của người đặt hàng hoặc người vận chuyển Điều đó chỉ ra rằng, trước tiên người đặt hàng gửi một thông điệp

requestShipping (hoặc yêu cầu thủ tục requestShipping của người vận chuyển), và sau đó người đặt hàng phải đáp ứng lại thông điệp processSchedule từ người vận chuyển Tương tác có hai đường truyền: một là cho người đặt hàng còn một cho người vận chuyển Những thể hiện đối tượng này là các thuộc tính của người đặt hàng và người vận chuyển trong lớp đặc tả dịch vụ Tức là, các thông điệp được thay đổi giữa những vai trò thông qua mối kết nối giữa chúng Đây là trường hợp đơn giản, mẫu yêu cầu/đáp ứng hoặc gọi lại không đồng bộ là một đặc trưng trong nhiều giao thức dịch vụ

Giao thức ShippingService cũng có khả năng xác định việc sử dụng ứng xử của UML 2: một hoạt động, sự tương tác, máy trạng thái, máy trạng thái giao thức, hoặc ứng xử không rõ ràng (mã) Trong đó có việc chọn cái nào để sử dụng vào việc thiết lập các mô hình, các loại ưu tiên của chúng, hoặc khả năng ứng dụng vào các miền

Dịch vụ Lập hóa đơn (Invoicing service)

Tính toán giá cả bắt đầu và kết thúc cho một hóa đơn bao hàm giao thức phức tạp

hơn một chút giữa những người đặt hàng và người lập hóa đơn Rõ ràng

initiatePriceCalculation phải được gọi trước completePriceCalculation Sau đó người đặt hàng phải được chuẩn bị để xử lý hóa đơn kết quả

Chúng ta có thể thu nhận giao thức này bằng việc sử dụng một lớp trừu tượng để xác định những vai trò của người lập hóa đơn và người đặt hàng, trách nhiệm của

họ và giao thức (đối thoại hoặc những quy tắc) để họ tương tác với nhau như thế nào Điều này giống đặc tả ShippingService, ngoại trừ tương tác yêu cầu/đáp ứng đơn giản hơn Đó là một chuỗi trong đó các khả năng hoạt động dịch vụ phải được gọi với sử dụng dịch vụ hợp lệ

Đặc tả dịch vụ InvoicingService biểu diễn trong Hình 6 thu nhận giao thức này Chú ý rằng đặc tả dịch vụ này cũng thực hiện ca sử dụng (use case) Lập hóa đơn Một ca sử dụng có thể được sử dụng để biểu diễn dịch vụ - các yêu cầu cụ thể Đặc

tả dịch vụ bao gồm hai vai trò: Người lập hóa đơn và Người đặt hàng Kiểu của

những vai trò này tương ứng là thực hiện giao diện Invoicing và sử dụng giao diện InvoiceProcessing Các giao diện này gói gọn những trách nhiệm của những vai trò (dịch vụ hoặc các khả năng hoạt động yêu cầu hoặc các thủ tục) Hoạt động InvoicingService trong đặc tả dịch vụ xác định giao thức cho việc sử dụng những thao tác dịch vụ, liên lạc thực sự có thể xảy ra giữa vai trò của người đặt hàng và người lập hóa đơn