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

http://vnson.com/chat-luong/312-mo-hinh-hoa-soa-phan-2-dac-ta-dich-vu

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

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ụ" , 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 vụ. Giao thức chỉ rõ các quy tắc cho những khả năng hoạt động được sử dụng như thế nào hoặc theo trật tự gì. Các ràng buộc phản ánh tác dụng của những dịch vụ được mong đợi thực hiện một cách thành công là gì và nó được đánh giá như thế nào. 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® Phân tích Giao dịch Phân tích các yêu cầu nghiệp vụ IBM® WebSphere® Business Modeler Kiến trúc Phần mềm Thiết kế kiến trúc của giải pháp IBM Rational Software Architect Người phát triển các Dịch vụ Web Thực thi giải pháp IBM® Rational® Application Developer and IBM® WebSphere® Integration Developer   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: Tên của nó, thường là các cụm động từ để chỉ nó làm cái gì. Đầu vào và đầu ra dữ liệu dịch vụ bắt buộc hoặc không bắt buộc. 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. 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. 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. Dịch vụ Lập lịch (Scheduling service) Việc đặc tả dịch vụ Lập lịch được biểu diễn trong hình 4 là rất đơn giản. Dịch vụ cung cấp hai khả năng hoạt động: khả năng đáp ứng một yêu cầu lập lịch sản xuất và khả năng tạo ra một lịch biểu vận chuyển. Như trên chúng ta đã biết, trong trường hợp này không có giao thức cho việc sử dụng những khả năng hoạt động này cũng như một khách hàng có thể sử dụng nó theo trật tự nào đó. 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 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. Hình 6. Đặc tả InvoicingService InvoicingService là một lớp để xác định giao thức liên lạc, hội thoại hoặc những quy tắc tương tác giữa người đặt hàng và người lập hóa đơn. Những chi tiết của giao thức được thu nhận vào thành phần ownedBehavior của lớp, nó được dùng để xác định những mẫu tương tác hợp lệ cho việc sử dụng dịch vụ này. Trong trường hợp này, giao thức được biểu diễn như là một hoạt động của UML. Giao thức chỉ ra rằng một người đặt hàng phải khởi tạo một cách tính giá trước khi thử lấy tính toán giá đầy đủ. Sau đó người đặt hàng phải đáp ứng lại yêu cầu (trong trường hợp này là yêu cầu gọi lại) để xử lý hóa đơn cuối cùng. Vài khách hàng yêu cầu dịch vụ lập hóa đơn có thể thực hiện nhiều hơn ba hành động này tuy nhiên một chuỗi các hành động cụ thể đó được ràng buộc bởi giao thức. Chú ý rằng ActivityPartitions trong hành động InvoicingService biểu diễn các vai trò hoặc các thuộc tính trong lớp InvoicingService. Một hành động yêu cầu thao tác phụ thuộc vào một phân hoạch cho biết yêu cầu được thể hiện bởi phân hoạch đó (điểm mấu chốt của hành động đầu vào đạt tới là vai trò được biểu diễn bằng phân hoạch hoạt động). Trong trường hợp này, chỉ có một tương tác giữa người đặt hàng và dịch vụ lập hóa đơn, do đó lớp đặc tả dịch vụ chỉ có một ownedBehavor. Ở trường hợp khác, có thể có nhiều hơn một tương tác giữa khách hàng và nhà cung cấp, mỗi cái sử dụng một giao thức khác nhau. Đặc tả dịch vụ sẽ có ownedBehavior để chỉ rõ các mẫu tương tác hợp lệ cho mỗi tương tác này. Ở thời điểm này bạn không biết nhà cung cấp dịch vụ thực thi InvoicingService gì. Và bạn cũng không biết những gì khách hàng dịch vụ có thể sử dụng. Bạn chỉ biết khách hàng bất kỳ sẽ phải làm gì để sử dụng dịch vụ và nhà cung cấp bất kỳ phải làm gì khi thực thi điều đó. Đặc tả Mua hàng (Purchasing specification) Cuối cùng là đặc tả dịch vụ cho việc xử lý những trình tự mua hàng (Hình 7). Hình 7. Đặc tả dịch vụ Mua hàng Giống như đặc tả dịch vụ Lập lịch, Thanh toán là một giao diện đơn giản chỉ có một thủ tục cung cấp khả năng cho việc xử lý các trình tự Thanh toán đối với khách hàng, những người sẽ lấy về một hóa đơn. Như một hiệu ứng phụ, các danh mục đã đặt trước được sản xuất (nếu cần) và được chuyển tới khách hàng. Giao diện dịch vụ này biểu diễn khả năng hoạt động đã chỉ rõ trong tiến trình nghiệp vụ Xử lý Đơn Đặt Mua hàng ban đầu. Nó biểu diễn một dịch vụ đã xác định và được thiết kế từ tiến trình nghiệp vụ đó. Thăm lại cấu trúc liên kết dịch vụ Chú ý rằng để những đặc tả dịch vụ được định nghĩa đầy đủ hơn, chúng ta có thể đưa ra xem xét một cấu trúc liên kết dịch vụ khác được trình bày trong Hình 3 ở trên. Nhớ rằng nó biểu diễn làm thế nào mà các thể hiện của những dịch vụ đã xác định có thể được sử dụng để hoàn thành hợp đồng những yêu cầu dịch vụ nghiệp vụ. Nhưng biểu đồ đó không thể hiện nhiều về những dịch vụ của bản thân chúng, chúng được kết nối như thế nào hoặc những gì liên quan đến các giao thức trong những tương tác của chúng. Bây giờ các đặc tả dịch vụ đã hoàn tất, bạn tạo ra một biểu đồ mới và chỉ rõ làm thế nào những người tham gia sử dụng các dịch vụ này có thể tương tác để hoàn thành các yêu cầu. Bạn sẽ quay lại biểu đồ này ở bài viết tiếp theo trong loạt bài này, "Mô hình SOA: Phần 3. Thực hiện dịch vụ", nơi mà dịch vụ sẽ được sử dụng như là điểm bắt đầu cho những dịch vụ tích hợp cuối cùng, giải pháp ở ví dụ này. Hình 8 biểu diễn một thành phần Xử lý Đơn đặt hàng mà cung cấp một ngữ cảnh cho việc thể hiện một khung nhìn khác của cấu trúc liên kết dịch vụ. Các phần của nó thể hiện rằng những người tham gia xử lý đơn đặt hàng sẽ cung cấp hoặc yêu cầu những dịch vụ (hoặc cả hai) cần thiết cho việc hoàn thành hợp đồng những yêu cầu Xử lý Đơn Đặt Mua hàng. Chúng ta không biết một cách chính xác những gì mà những thành phần đó còn lại (chúng không có kiểu), nhưng chúng ta có thể chỉ ra những gì chúng cần để thực hiện bằng cách đưa ra vai trò của chúng trong các đặc tả dịch vụ và định nghĩa làm thế nào để chúng tương tác và bằng những yêu cầu gì để chúng hoàn thành. Hình 8. Chi tiết những tương tác dịch vụ Những kết nối giữa các bộ phận của thành phần xử lý đơn đặt hàng dự đoán trước những tương tác giữa các bộ phận. Trong trường hợp này, các tên của kết nối tương ứng với tên của những hợp đồng của chúng, chúng là các giao thức cho những đặc tả dịch vụ tương ứng. Điều này cũng cho biết những bộ phận này phải cung cấp hoặc yêu cầu những giao diện được chỉ rõ bởi đặc tả dịch vụ và những phần sẽ sử dụng những giao diện này theo giao thức của đặc tả dịch vụ đó. Điều này được thực hiện và được mô hình hóa trong những mô tả thực hiện của các dịch vụ như thế nào sẽ được trình bày trong bài viết tiếp theo của loạt bài này. Chúng ta cũng nhận thấy rằng các bộ phận sẽ tương tác với nhau theo cách để hoàn thành hợp đồng các yêu cầu Xử lý Đơn Đặt Mua hàng. Do đó, Xử lý Đơn Đặt hàng tóm tắt lại có hai việc: Những khách hàng và nhà cung cấp dịch vụ (hoặc những người tham gia) cần đáp ứng các yêu cầu nghiệp vụ Những kết nối và những giao thức chỉ ra rằng làm thế nào những người tham gia tương tác thực hiện được như vậy. Mô hình dữ liệu dịch vụ Mô hình dữ liệu Quản lý Mối quan hệ Khách hàng (Customer Relationship Management, CRM) đã định nghĩa trong gói org::crm, định nghĩa tất cả dữ liệu được dùng bởi tất cả các thao tác dịch vụ trong mô hình Tiến trình Đặt Mua hàng ở ví dụ này (Hình 9). Gói CRM biểu diễn thiết kế của một mô hình dữ liệu dịch vụ Quản lý Mối quan hệ Khách hàng có thể được sử dụng lại trong một số dịch vụ, dù cho các dịch vụ được cung cấp bởi những tổ chức khác nhau. Dữ liệu dịch vụ được phát hiện và chuẩn hóa như thế nào, nó liên quan đến các thực thể bền hoặc những nguồn dữ liệu vật lý như thế nào nằm ngoài phạm vi của bài viết này. Những gì chúng ta đề cập đến ở đây là dữ liệu dịch vụ là gì và mô hình thu được như thế nào. Hình 9. Mô hình miền những dịch vụ CRM Mỗi kiểu dữ liệu trong Hình 9 biểu diễn dữ liệu dịch vụ. Dữ liệu dịch vụ là dữ liệu bị thay đổi giữa những khách hàng và những nhà cung cấp dịch vụ. Các kiểu dữ liệu của các tham số cho những thủ tục dịch vụ là những thông điệp hoặc những kiểu nguyên thủy. Chú ý: Những thông điệp dữ liệu dịch vụ không giống như những thông điệp của Ngôn ngữ Mô tả Dịch vụ Web (Web Services Description Language, WSDL). Một thủ tục dịch vụ có thể có số đầu vào và đầu ra với kiểu thông điệp hoặc kiểu nguyên thủy. Những thủ tục dịch vụ có thể được thiết kế để dùng với đầu vào, đầu ra đơn và những thông điệp lỗi nhưng điều này không cần thiết, và có thể dẫn đến sự kết hợp dữ liệu không mong muốn. Những thông điệp là các đối tượng truyền dữ liệu (DTOs) có thể dễ dàng bị thay đổi giữa những không gian địa chỉ trong môi trường phân tán. Những khách hàng và những nhà cung cấp dịch vụ không có giả định về nơi mà dữ liệu được định vị thực sự và do đó họ thừa nhận rằng họ có một bản sao của vài khung nhìn trên dữ liệu miền bền thực sự. Các thông điệp không có định dạng. Chúng là các đối tượng giá trị, trong đó biểu thức của chúng được dựa trên giá trị nội dung chứ không phải trên định dạng của chúng. Những thông điệp thể hiện dữ liệu bị thay đổi giữa những khách hàng và những nhà cung cấp dịch vụ trong một môi trường phân tán. Những nhà cung cấp dịch vụ cũng thường truy cập đến những dữ liệu bền để dùng vào các thiết kế thực thi của dữ liệu đó. Mối quan hệ giữa dữ liệu dịch vụ và dữ liệu miền bền đã dùng trong những thiết kế thực thi dịch vụ là trách nhiệm của nhà cung cấp dịch vụ và việc thực thi các khả năng hoạt động dịch vụ của họ. Thông thường dữ liệu dịch vụ là một phép chọn và phép chiếu (hoặc khung nhìn) của dữ liệu miền. Tuy nhiên, làm thế nào để dữ liệu dịch vụ được lấy ra hoặc cập nhật dữ liệu miền tùy thuộc vào việc thực thi dịch vụ. Các đối tượng dữ liệu dịch vụ (SDOs) là những máy thực thi rất có ích cho các thông điệp dữ liệu dịch vụ. Chúng cũng có khả năng quản lý những tập hợp thay đổi và vận chuyển một cách tự động những thay đổi đến nơi lưu trữ bền. Những thực thi của người tham gia dịch vụ có thể sử dụng các khả năng này nhưng họ không cần được đánh địa chỉ trong mô hình. Mô hình dữ liệu sử dụng một kiểu thông tin khuôn mẫu (stereotype) để định danh các thuộc tính sao cho những thể hiện của lớp bao hàm có định danh duy nhất. Vấn đề này sẽ xuyên suốt mô hình các dịch vụ, nói một cách cụ thể bởi vì những dịch vụ Web và Ngôn ngữ Thực thi Tiến trình Giao dịch cho những dịch vụ Web (Business Process Execution Language - BPEL) dựa vào dữ liệu nghiệp vụ để định danh đối tượng trên cơ sở giá trị hoặc sự tương quan của thể hiện. Phần tiếp theo là gì Trong bài viết này, chúng ta đã mô hình hóa đặc tả dịch vụ một cách chi tiết cho mỗi dịch vụ đã xác định. Những đặc tả này đưa ra các giao diện được cung cấp và được yêu cầu, các vai trò của những giao diện này trong đặc tả dịch vụ và 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 trong dịch vụ cung cấp. Những đặc tả dịch vụ định nghĩa một hợp đồng giữa những yêu cầu của khách hàng và những dịch vụ của nhà cung cấp mà hợp đồng cần phải có những khả năng. Bài viết tiếp theo trong loạt năm bài viết, "Mô hình hóa SOA: Phần 3. Thực thi dịch vụ" giải thích làm thế nào để những dịch vụ được thi hành một cách thực sự. Sự thực thi dịch vụ bắt đầu với việc quyết định thành phần nào sẽ cung cấp những dịch vụ nào. Quyết định đó có những thực thi quan trọng trong dịch vụ sẵn có, phân tán, an ninh, phạm vi nghiệp vụ và sự kết nối. Sau khi những quyết định này được làm chúng ta có thể làm thế nào mô hình hóa khả năng hoạt động dịch vụ được thực thi và do đó làm thế nào để những dịch vụ đã yêu cầu được sử dụng một cách thực sự. Sau đó chúng ta sẽ sử dụng đặc điểm của phép biến đổi UML-to-SOA có trong Rational Software Architect nhằm tạo ra một giải pháp cho những dịch vụ Web mà nó có thể được dùng một cách trực tiếp trong Rational Application Developer hoặc WebSphere Integration Developer, kiểm thử và triển khai giải pháp đã hoàn thiện. VNSON Corp sưu tầm