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

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 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: 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. 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 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. [...]... 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... 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. .. 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ữ... 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ý... 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... 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... 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... 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... 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... 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 . 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ô. 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 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