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

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:23

Thêm vào BST

Báo xấu

113
lượt xem 21
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Mô hình hóa SOA: Phần 1: Xác định dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài viết này là bài viết đầu tiên trong năm bài viết về phát triển phần mềm dựa trên kiến trúc định hướng dịch vụ (SOA). Nó giới thiệu cách sử dụng các mô hình UML được mở rộng cùng với Software Service Profile® để thiết kế một giải pháp SOA được kết nối tới các yêu cầu công việc, nhưng không phụ thuộc vào các giải pháp thực hiện. Tác giả miêu tả các mục tiêu, mục đích...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Mô hình hóa SOA: Phần 1

Mô hình hóa SOA: Phần 1: Xác định dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài viết này là bài viết đầu tiên trong năm bài viết về phát triển phần mềm dựa trên kiến trúc định hướng dịch vụ (SOA). Nó giới thiệu cách sử dụng các mô hình UML được mở rộng cùng với Software Service Profile® để thiết kế một giải pháp SOA được kết nối tới các yêu cầu công việc, nhưng không phụ thuộc vào các giải pháp thực hiện. Tác giả miêu tả các mục tiêu, mục đích của công việc và các quá trình công việc được tiến hành để đạt được mục tiêu đó, và giải thích cách sử dụng các quá trình để xác định dịch vụ liên quan đến công việc cần thiết nhằm đáp ứng các yêu cầu được đưa ra. Mô hình phát triển SOA như thế nào Sức mạnh của SOA nằm ở khả năng cho phép công việc được nhanh chóng thông qua quá trình tích hợp và tái sử dụng công việc. SOA đạt được việc này bằng hai cách: Đưa ra các giải pháp đã được cấu trúc xung quanh các dịch vụ có thể sử dụng lại, tóm lược các khả năng công dụng được tách ra từ việc thực thi; và cung cấp các điều kiện thích hợp để quản lý các điểm liên quan đến nhau giữa các tính năng. Mô hình có thể được sử dụng làm cầu nối các ngăn cách giữa các yêu cầu công việc và một giải pháp dựa trên dịch vụ được triển khai. Mô hình SOA đưa ra mức mô tả kiểu ký tự cho phép bạn tập trung vào dịch vụ công việc. Các cách tiếp cận phát triển dựa trên mô hình có thể được sử dụng để phát sinh ra các tiến trình SOA bằng cách sử dụng nền tảng như nền tảng Java™ 2, phiên bản doanh nghiệp (J2EE) hoặc IBM® CICS® mà đáp ứng các mục tiêu chức năng và phi chức năng khi giúp các tác vụ được nhanh chóng. Thuật ngữ Kiến trúc định hướng dịch vụ (SOA) có một vài ý nghĩa. Người dùng thực tế thường sử dụng SOA để xác định một kiểu kiến trúc và miêu tả một hạ
tầng công nghệ thông tin thông dụng, cho phép hệ thống công nghệ thông tin đã được xây dựng sử dụng kiểu kiến trúc đó để hoạt động. Đây là những viễn cảnh tập trung vào công nghệ rất hữu dụng nhưng như thế là chưa đủ. Để đạt được tiềm năng của nó, một hạ tầng công nghệ thông tin dựa vào SOA (từ đây gọi đơn giản là SOA) nên liên quan đến các công việc, do vậy được định hướng bởi công việc và được thực thi để hỗ trợ công việc. Chúng ta cần một cách thức thiết kế các giải pháp SOA mà kết nối với các yêu cầu công việc chúng thoả mãn. Điều này sẽ khó thực thi nếu các yêu cầu công việc được đưa ra như là một danh mục đơn giản các mục yêu cầu và mức tóm tắt của SOA được ghi lại trong một số tài liệu XML mà miêu tả một nhóm các dịch vụ mạng. Cái chúng ta cần là cấu hình hoá các yêu cầu công việc và đưa ra mức tóm tắt sao cho SOA có thể tương đồng hơn nữa với các công việc dịch vụ, và các dịch vụ này sẽ đáp ứng mục tiêu và mục đích công việc như thế nào. Điều này gắn kết giải pháp đã được triển khai với giá trị công việc dự kiến. Cùng lúc đó, chúng ta cần chia tách các vấn đề liên quan đến công việc ra khỏi sự tiến triển các nền tảng SOA mà hỗ trợ chúng. Mô hình và phát triển dựa trên mô hình (MDD) có thể giúp đạt được các mục tiêu này. Các mô hình cho phép chúng ta tóm gọn các chi tiết trong lúc thực thi và tập trung vào các vấn đề ảnh hưởng đến quyết định kiến trúc. Ở khía cạnh nào đó, cách tiếp cận chúng ta đang miêu tả áp dụng một trong các nguyên lý căn bản của SOA để phát triển các giải pháp SOA; chia tách các nghi ngại và giảm các sự kết hợp. Bây giờ, chúng ta tách rõ ràng các công việc và trách nhiệm của các nhà phân tích công việc với các nhân viên công nghệ thông tin. Thông thường, nhân viên phân tích công việc sẽ tập trung vào yêu cầu hoạt động và cấu trúc công việc cần thiết để đáp ứng mục tiêu và mục đích công việc, điều mà đạt được một số tầm nhìn xa của công việc. Thường thường, họ không quan
tâm (hoặc không đủ kỹ năng cần thiết để xử lý) đến những vấn đề của công nghệ thông tin như tái sử dụng, sự gắn kết và kết nối, phân phối, bảo mật, sự bền bỉ, tích hợp dữ liệu, sự trùng hợp, khôi phục hư hỏng, v.v.. Hơn nữa, các công cụ mô hình của quá trình công việc thường không đủ năng lực cần thiết để xác định các vấn đề này, và nếu nó có đủ năng lực, nó có thể cũng không phải là công cụ hiệu quả cho các nhân viên phân tích công việc. Loạt bài viết liên quan đến mô hình SOA Loạt bài viết này đưa ra cách sử dụng mô hình UML được mở rộng với phần mềm IBM® Software Service Profile (Hiện trạng Dịch vụ) để thiết kế một giải pháp SOA được liên kết với các yêu cầu công việc, nhưng độc lập với thực thi giải pháp. Nhìn chung là dễ dàng để hiểu các khái niệm bằng cách theo dõi các ví dụ súc tích, điển hình và hoàn chỉnh. Đó chính là cách chúng tôi tiếp cận ở đây. Chúng ta không dành nhiều thời gian cho các chi tiết của UML, mà thay vào đó, sẽ tập trung vào cách chúng ta sử dụng UML như thế nào để thiết kế và phát triển. Mặc dù loạt bài viết này về các giải pháp dịch vụ mạng từ các mô hình SOA, chúng ta bắt đầu bằng cách tập trung vào mục tiêu và mục đích công việc mà chúng ta cố gắng đạt được, vì vậy chúng ta truyền đạt các giải pháp vững vàng về đạt được giá trị đối với công việc. Sau đó, chúng ta khảo sát một quy trình công việc mà đưa ra mô hình chúng ta phải làm gì trong công việc để đạt được các mục tiêu. Điều này cung cấp các yêu cầu chức năng công việc mà giải pháp SOA phải thoả mãn. Tiếp theo, chúng ta sẽ sử dụng quy trình công việc này để giúp xác định dịch vụ hữu ích trong việc tạo ra một giải pháp SOA thoả mãn các yêu cầu công việc. Trong các bài viết tiếp theo trong loạt bài viết này, chúng ta sẽ tạo ra các đặc tính và thực thi dịch vụ thoả mãn các yêu cầu với một kiến trúc cho phép sử dụng lại
trong tương lai và tăng tốc công việc. Cuối cùng, chúng ta sẽ sử dụng MDD để tạo ra một giải pháp dịch vụ mạng có thể triển khai và hoạt động. Nhằm giúp ví dụ được thực tế, chúng ta sẽ dùng công cụ hiện tại là Rational và WebSphere của IBM® Rational® và IBM® WebSphere® để xây dựng giải pháp nhân tạo và kết nối chúng với nhau, do vậy chúng ta có thể xác nhận giải pháp đối với các yêu cầu và thay đổi quản lý hiệu quả. Bảng 1 đưa ra tổng kết của quy trình tổng thể mà chúng ta sẽ sử dụng trong việc phát triển ví dụ và các công cụ được sử dụng để xây dựng các giải pháp nhân tạo. Bảng 1. Vai trò, nhiệm vụ và công cụ quy trình phát triển Vai trò Nhiệm vụ Công cụ Truyền tải các mục Điều hành công tiêu, mục đích công Rational RequisitePro việc việc Chuyên viên phân Các yêu cầu phân WebSphere Business Modeler tích công việc tích công việc Kiến trúc sư phần Thiết kế kiến trúc Rational Software Architect các giải pháp mềm IBM® Rational® Application Developer Chuyên viên phát Thực thi giải pháp and IBM® WebSphere® Integration triển dịch vụ
Developer mạng Loạt bài viết này chú trọng vào cách nắm bắt các yêu cầu công việc, xây dựng các mô hình dịch vụ phù hợp với yêu cầu đó, tạo ra và triển khai các giải pháp hiện thực hoá các thiết kế. Chúng ta cũng nhấn mạnh các công cụ hỗ trợ. Chúng đại diện cho mức tối thiểu các khả năng mô hình SOA, được các công cụ của IBM giới thiệu gần đây trong Bảng 1, và được sử dụng để làm mô hình các yêu cầu của khách hàng và cung cấp dịch vụ trong mọi tầng kiến trúc. Các bài viết này không tập trung nhiều vào tất cả các phương pháp và kỹ năng để khám phá các yêu cầu, các cách tiếp cận đối với phân tích và định giá giải pháp dịch vụ, hoặc các cách tiếp cận để phân chia dịch vụ thành các tầng kiến trúc đa dạng. Để có thêm thông tin về các chủ đề quan trọng này, xem ®IBM Rational Unified Process (Quy trình hợp nhất Rational)® (RUP®) đối với SOA và tiến trình hợp nhất đối với SOMA (xem các đường dẫn). Chương trình soạn thảo bằng phương pháp Rational của IBM® cung cấp các quy trình phát triển, hướng dẫn, trợ giúp công cụ và các bài viết giải thích những cách khác để sử dụng công cụ phát triển những giải pháp và mô hình dịch vụ hoàn chỉnh. Ví dụ về quá trình đặt mua hàng Ví dụ này dựa trên ví dụ về quá trình đặt mua hàng được trích từ tài liệu OMG UML và siêu mô hình dịch vụ (OMG UML Profile and Metamodel for Services- UPMS) RFP. Nó dựa trên một ví dụ trong các đặc điểm của BPEL 1.1 (xem Tài nguyên). Đặc điểm của BPEL 1.1 bao gồm duy nhất một giải pháp chưa hoàn chỉnh, vì các mối tương quan không được xác định, dữ liệu công việc không đầy đủ, và không có lỗi liên quan đến điều khiển hoặc bù trừ. Ví dụ này gồm một số dữ liệu được giả tạo nhằm làm cho hoàn chỉnh, đặc biệt đối với dữ liệu cần cho sự tương quan.
Ví dụ bắt đầu bằng việc sử dụng IBM Rational RequisitePro® (Điều kiện cần thiết căn bản IBM) để miêu tả động lực công việc, thiết lập các mục tiêu, mục đích công việc cần đạt được. Tiếp theo là quy trình công việc ở mức độ cao được sử dụng khi dùng IBM Websphere Business Modeler® nhằm diễn tả các yêu cầu cấu trúc và hoạt động công việc cần thiết, đáp ứng các mục tiêu và mục đích. Các động lực này và mô hình quy trình thiết lập một tình huống nhằm xác định dịch vụ gắn kết với các yêu cầu công việc. Sau khi chúng ta hiểu yêu cầu công việc, chúng ta có thể tiến hành phát triển các dịch vụ đáp ứng các yêu cầu này. Bước đầu tiên trong một giải pháp SOA là xác định các dịch vụ. Để làm điều đó, chúng ta sẽ coi quy trình công việc như là một giao ước các Yêu cầu dịch vụ. Các tính chất và nhà cung cấp dịch vụ sau đó sẽ được thiết kế và kết nối với nhau sao cho thoả mãn các yêu cầu công việc, cũng như xác định được các vấn đề quan tâm về kiến trúc phần mềm. Quy trình xác định các dịch vụ cần tìm từ một mô hình kinh doanh được gọi là domain decomposition (sự phân tích miền). IBM Rational Unified Process (RUP) SOMA miêu tả sự phân tích miền và một số cách tiếp cận khác, cái mà được sử dụng chung, đưa ra sự đảm bảo nâng cao khi xác định tất cả các dịch vụ cần thiết cho công việc. Các yêu cầu công việc Tình huống: Một nhóm các công ty trong tập đoàn quyết định hợp tác để sản xuất một dịch vụ dùng lại được cho quy trình các đặt hàng mua sắm. Mục tiêu của dự án này là: Thiết lập một cách thức thông dụng của quy trình đặt hàng mua sắm • Đảm bảo các đặt hàng được xử lý đúng hạn và giao các hàng hoá theo yêu • cầu.
Giúp tối thiểu hoá hàng tồn kho và chi phí duy trì hàng tồn kho • Tối thiểu hoá các chi phí vận chuyển và sản phẩm • Hình 1 Thể hiện các yêu cầu được nêu trong Thông báo các tiêu chuẩn (RequisitePro. Notice) mà tác vụ kinh doanh Quy trình Đặt hàng Mua sắm đáp ứng tất cả mục tiêu công việc của chúng ta. Hình 1. Các yêu cầu công việc nêu trong các tiêu chuẩn cần thiết (RequisitePro) Chúng ta tạo một chỉ số hiệu quả chính (KPI) đối với mục tiêu 2: Quy trình xử lý đơn hàng đúng hạn (xem Hình 2).
Hình 2. Chỉ số hiệu quả chính Chỉ số này là điều chúng ta muốn theo dõi trong mô hình xử lý kinh doanh nhằm hiện thực hoá tác vụ kinh doanh. Chỉ số này trở thành một ràng buộc trong giải pháp SOA của chúng ta, và được giám sát trong dịch vụ mạng sẽ được triển khai. Điều này cho phép dịch vụ được theo dõi và quản lý nhằm đảm bảo rằng mục tiêu và mục đích công việc thực sự được đáp ứng. Các quy trình tổ chức kinh doanh Các chuyên viên phân tích kinh doanh từ các công ty thành viên đã phân tích các yêu cầu và xác định rằng quy trình xử lý IBM WebSphere Business Modeler® đáp ứng các mục tiêu công việc, cũng như các ràng buộc hoạt động kinh doanh. Quy trình hoàn toàn hoàn chỉnh và chi tiết này có thể được sử dụng như một cơ sở cho một thoả thuận mức dịch vụ chính thức (SLA) giữa các bên. Do vậy, giải pháp SOA của chúng ta thoả mãn các yêu cầu kinh doanh sẽ tuân thủ chặt chẽ các yêu cầu kinh doanh (Hình 3).
Hình 3. Mô hình quá trình xử lý Quy trình đặt hàng mua sắm Quy trình đặt hàng mua sắm đề xuất ba hoạt động cùng lúc: thứ nhất là quản lý sản xuất và lịch vận chuyển, thứ hai là tính toán giá cả và xuất hoá đơn, và thứ ba là vận chuyển hàng đã được đặt. Quy trình bắt đầu bằng cách tính toán giá cả dựa trên những hàng hoá đã đặt mua. Đơn giá này chưa hoàn thiện, tuy nhiên tổng hoá đơn sẽ phụ thuộc nơi sản xuất và mức chi phí vận chuyển. Cùng lúc đó, đơn đặt hàng được gửi đến nơi sản xuất để xác định sản phẩm có sẵn hay không và từ phân xưởng nào. Cũng tại lúc này, quy trình yêu cầu chuyển hàng và chờ lịch vận chuyển do nhà cung cấp lịch trình sản xuất gửi đến. Sau khi có lịch sản xuất, có thể xuất hoá đơn và chuyển cho khách hàng. Chúng ta sử dụng WebSphere Business Modeler nhằm tạo ra một biện pháp kinh doanh gọi là giới hạn thời gian quy trình xử lý đơn hàng để đáp ứng chỉ số KPI trong giới hạn thời gian quy trình xử lý đơn hàng (Order Processing Time Limit KPI) từ các yêu cầu kinh doanh. Biện pháp này giám sát thời gian xử lý Quy trình đặt hàng mua sắm và đưa ra cảnh báo nếu thời gian xử lý vượt quá năm ngày (Hình 4).
Hình 4. Các biện pháp kinh doanh đối với KPIs Các nhà phân tích kinh doanh có thể sử dụng WebSphere Business Modeler để thúc đẩy quy trình mua bán. Việc này giúp thực hiện các mục đích quan trọng sau: Thứ nhất, nó có thể được sử dụng để tiến hành quy trình mua bán để dự • đoán xem nó hoạt động như thế nào. Điều này cho phép các nhà phân tích kinh doanh thông qua các hoạt động với các cổ đông khác nhau. Các khách hàng thường không biết mình muốn gì cho tới khi bạn đưa ra một số thứ mà họ không thích. Điều hành một quy trình kinh doanh theo phương thức mô phỏng là cách tốt để thông qua quy trình hoạt động trước khi đầu tư vào một giải pháp cho các vấn đề sai sót. Dự đoán các quy trình kinh doanh thông qua các mô phỏng có thể giúp bạn phát hiện ra các cơ hội mới để sàng lọc những trường hợp khó phát hiện nếu chỉ bằng chạy quy trình. Điều thứ hai mà mô phỏng có thể được sử dụng là xác định xem một quy • trình được thực thi sẽ có chi phí thế nào và kéo dài bao lâu - vấn đề cốt yếu cần thiết khi ra quyết định kinh doanh. Các nhà phân tích kinh doanh có thể
giao các tài nguyên và khoảng thời gian đối với mỗi công việc trong quy trình. Các tài nguyên này có thể bao gồm mức độ sẵn có, chi phí, và vị trí thông tin. Tiếp theo, các mô phỏng WebSphere Business Modeler có thể được sử dụng để dự đoán một quy trình sẽ mất bao lâu, chi phí bao nhiêu và chỗ nào có những vướng mắc tài nguyên cần xử lý. Chạy các mô phỏng khác nhau sinh ra từ những thay đổi trong quy trình kinh doanh có thể dễ dàng được so sánh để xác định sự thay đổi có đem lại hiệu quả mong muốn hay không. Cuối cùng, kết quả chạy các mô phỏng này có thể được sử dụng để đánh • giá các chỉ số KPIs kinh doanh nhằm đảm bảo quy trình kinh doanh đáp ứng các mục tiêu. Điều này tạo được lòng tin đối với đội ngũ phát triển rằng họ đang đưa ra giải pháp tương thích cho đúng vấn đề vào thời điểm hợp lý. Chúng tôi cũng sẽ liên kết Quy trình xử lý đơn đặt hàng trong WebSphere Business Modeler với tác vụ kinh doanh trong quy trình xử lý đơn đặt hàng BUC1 trong các tiêu chuẩn cần thiết để chỉ ra quá trình hiện thực hóa tác vụ kinh doanh. "Realization" (Hiện thực hóa) là thuật ngữ chính thức trong mô hình tác vụ kinh doanh. Bạn có thể thấy tác vụ kinh doanh được kết nối với một quy trình bằng mũi tên nhỏ trong biểu tượng BUC trong trang xem lại các yêu cầu WebSphere Business Modeler. (Hình 5).
Hình 5. Liên kết quy trình kinh doanh với các tác vụ kinh doanh Bạn có thể sử dụng các yêu cầu phối cảnh trong WebSphere Business Modeler để điều chỉnh giữa quy trình kinh doanh và tác vụ kinh doanh mà mô hình hiện thực hoá Requirement Explorer trong WebSphere Business Modeler, các điều kiện quan trọng của máy khách, hoặc các yêu cầu trong Microsoft® Word®. Phần tiếp theo đề cập quy trình kinh doanh như là một thoả thuận các yêu cầu và chỉ ra cách xác định các dịch vụ trong một giải pháp SOA đối với các yêu cầu hoạt động đã định trước. Xác định dịch vụ Một số quy trình công việc có thể chạy trực tiếp từ nền, như quy trình IBM WebSphere Process Server®. Nhưng có những tình huống mà những quy trình kinh doanh không giải quyết đầy đủ các vấn đề công nghệ thông tin và có khả năng bị làm lại để tái sử dụng tốt hơn và để giải quyết các yêu cầu phi chức năng, như tính hiệu quả, khả năng đo lường, và độ bảo mật. Trong trường hợp này, các quy trình kinh doanh có thể như các đặc tính của yêu cầu mà một giải pháp SOA phải thực hiện.
Các yêu cầu dịch vụ Các yêu cầu đối với Quy trình đặt hàng mua sắm (Purchase Order Process) có thể đạt được từ quy trình kinh doanh WebSphere Business Modeler. Những yêu cầu này có thể xem như là thoả thuận dịch vụ, chỉ định vai trò tham gia vào quy trình kinh doanh, các công việc mong đợi được tiến hành, và các nguyên tắc về việc chúng tương tác với nhau thế nào. Thoả thuận dịch vụ này là các yêu cầu chính thống, ghi rõ đặc điểm cân bằng kiến trúc, được thực hiện bởi các người dùng dịch vụ tương tác và các nhà cung cấp, mà không giải quyết vấn đề nào về kiến trúc công nghệ thông tin và sự thực thi. Trong trường hợp này, thoả thuận dịch vụ chứa những thông tin tương tự như quy trình kinh doanh nguyên bản, nó đơn giản là một cách nhìn về quy trình kinh doanh được tạo ra bằng cách mở WebSphere Business Modeler sử dụng IBM® Rational® Software Modeler hoặc IBM® Rational® Software Architect. Các chuyên viên phân tích kinh doanh thường sử dụng WebSphere Business Modeler; trong khi, các kiến trúc công nghệ thông tin lại sử dụng Rational Software Architect. Các công cụ này khó có thể được sử dụng cùng nhau, và điển hình là chúng không được sử dụng để tiếp cận các vị trí người dùng giống nhau. Để giúp kiến trúc công nghệ thông tin có lợi ích từ công việc phân tích kinh doanh, Rational Software Architect có thể được sử dụng để nhập mô hình kinh doanh WebSphere Business Modeler vào một vị trí của Rational Software Architect, nơi mà sau đó các chuyên viên có thể mở nó và xem các nội dung của phân tích kinh doanh được trả lại trong Rational Software Architect như là UML.
Hình 6. Thoả thuận các yêu cầu dịch vụ Hãy cùng dành thời gian để hiểu sơ đồ này, vì chúng ta sẽ thấy các biểu đồ tương tự khi chúng ta phát triển giải pháp SOA.
Phối hợp Xử lý Đặt hàng Mua sắm (Process Purchase Order) tương ứng với quy trình kinh doanh Xử lý Đặt hàng Mua sắm. Lưu ý: Sự phối hợp sử dụng ký hiệu hệ thống phân loại (các hình chữ nhật được chia ô), chứ không phải ký hiệu hình ellipse gạch ngang (dashed ellipse). UML 2 cho phép một trong hai cách thức trên. Ví dụ này sử dụng ký hiệu hình chữ nhật vì nó có nhiều vai trò hơn. Khi vẽ mô hình hoặc nhận các yêu cầu dịch vụ từ các quy trình kinh doanh, sự hợp tác trả lời các câu hỏi sau: Hiệu ứng nào mà yêu cầu dự định hoàn thành? Đây là sự hợp tác tương • ứng với quy trình kinh doanh nếu sự hợp tác được lấy từ quy trình kinh doanh. Những tên này thường là các cụm động từ, xác định vai trò phối hợp dự định hoàn thành là gì. Ai tham gia để hoàn thành việc đó? Vai trò sự hợp tác chỉ ra những ai khi • phối hợp. Những vai trò này có thể tương ứng như những hàng song song (swim lanes) trong một quy trình kinh doanh. Trách nhiệm của vai trò này là gì? (Lưu ý: Các nhà cung cấp dịch vụ • đóng các vai trò này, không cần phải người sử dụng). Những hình thức của vai trò hợp tác thường có sự giao nhau. Trách nhiệm của các vai trò được chỉ ra như là các hoạt động giao nhau. Những thứ trong giải pháp dịch vụ của chúng tôi đóng một vai trò đủ năng lực thực hiện các trách nhiệm này. Cuối cùng, chúng phải thực thi những thao tác đó. Trong một quy trình kinh doanh, các vai trò chịu trách nhiệm về các công việc trong những hàng song song của chúng. Những sự giao nhau có thể được trích ra bằng cách
tạo ra các danh mục các công việc được chỉ định cho những vai trò đó trong quy trình kinh doanh. Các vai trò tác động vào cái gì? Đó là vai trò nào phải liên lạc với vai trò • khác? Điều đó hình thành sự độc lập giữa các vai trò. Sự tương tác này được biểu hiện bằng các kết nối giữa các vai trò trong sự hợp tác. Những kết nối này chỉ ra có một vài sự điều khiển hoặc dữ liệu chạy qua các hàng song song (swim lanes) trong quy trình kinh doanh. Các nguyên tắc nào cho các vai trò tương tác với nhau? Đây là hành vi • do sự hợp tác sở hữu. Hành vi này có thể là một hành động, sự tương tác, trạng thái của máy, hoặc hành vi khó hiểu (ví dụ: các mã trình). Hành vi này cho thấy khi nào các trách nhiệm của vai trò được yêu cầu và có thể chỉ ra thông tin được trao đổi giữa chúng. Hành động này tương ứng với một UML của quy trình kinh doanh. Chúng ta đánh giá xem các yêu cầu được đáp ứng hay không như thế • nào? Sự hợp tác có thể có những ràng buộc mà chỉ ra các điều kiện phải đúng với các yêu cầu cần thoả mãn. Những ràng buộc này tương ứng với các tiêu chuẩn kinh doanh KPI trong quy trình kinh doanh. Quy trình đặt hàng mua sắm là một sự hợp tác dịch vụ gồm bốn nguyên tắc, trong đó một nguyên tắc được hợp tác bởi chính quy trình. Những vai trò này được trích ra từ quy trình kinh doanh bằng cách kiểm tra các công việc được giao cho các vai trò trong các hàng song song (swim lanes) của quy trình kinh doanh. WebSphere Business Modeler dùng quan điểm dựa trên quy trình đối với các yêu cầu kinh doanh, trong khi các thoả thuận dịch vụ dùng quan điểm dựa trên vai trò. Cách này đưa ra một quan điểm dựa trên dịch vụ đối với các thoả thuận kinh doanh, làm cho nó dễ gắn kết các khoảng cách giữa yêu cầu của quy trình với kiến trúc các giải pháp dựa trên dịch vụ.
Thoả thuận dịch vụ có thể có những ràng buộc sinh ra từ các phạm vi cách thức (metrics and measures) và đơn vị đo lường từ mô hình thúc đẩy kinh doanh. Những ràng buộc này chỉ ra thoả thuận dịch vụ nào được dự định để hoàn thành và đo lường sự thành công như thế nào. Hợp tác dịch vụ cũng có thể nhận thức các tác vụ mà nắm bắt các thông tin bổ sung về các yêu cầu chức năng và phi chức năng ở mức độ cao đối với quy trình kinh doanh từ triển vọng của những cổ đông chính bên ngoài hoặc những người thi hành. Các tác vụ này có thể được xem trong các sơ đồ tác vụ trong Rational Software Architect và được kết nối tới các tác vụ kinh doanh trong RequisitePro. Điều này duy trì kết nối giữa thoả thuận yêu cầu dịch vụ, các quy trình kinh doanh, tác vụ kinh doanh, mục tiêu và mục đích kinh doanh. Thoả thuận hợp tác dịch vụ nêu trong Hình 6 có thể xem như WebSphere Business Modeler, hoặc nó đã có thể được phát triển trực tiếp trong Rational Software Architect. Sử dụng cách tiếp cận nào là vấn đề của sự ưu tiên, ai đang dùng mô hình, khả năng truy tìm được duy trì. Dĩ nhiên, chất lượng hợp tác dịch vụ từ quy trình kinh doanh WebSphere Business Modeler phụ thuộc vào mức độ chi tiết trong các quy trình này. Bài viết developerWorks sẽ cung cấp một thảo luận đầy đủ hơn về mối quan hệ giữa mô hình quy trình kinh doanh và mô hình dịch vụ. Xem Mô hình dịch vụ kinh doanh. Tổ chức dự án các dịch vụ Chúng ta đã sẵn sàng mô hình hoá một dịch vụ để thoả mãn các yêu cầu này. Giải pháp của chúng ta sẽ đáp ứng đầy đủ các yêu cầu này, nhưng nó không cần thiết bị ràng buộc bới chúng. Khi chúng ta thiết kế giải pháp SOA, chúng ta cần xác định các dịch vụ, thiết kế giao diện, và quyết định xem chúng sẽ được thực thi như thế nào: Nhà cung cấp dịch vụ cung cấp các dịch vụ gì và như thế nào. Điều này thiết lập sự độc lập giữa các nhà tiêu dùng và cung cấp dịch vụ, và thiết lập sự hợp lại
trong hệ thống. Quản lý sự hợp lại này là phần chính trong thiết kế dịch vụ dựa trên SOA. Bằng cách chia tách các yêu cầu kinh doanh từ các dịch vụ, chúng ta có sự linh động để thiết kế SOA đáp ứng cả yêu cầu về kinh doanh và hệ thống công nghệ thông tin. Điều đó giữ các yêu cầu kinh doanh trong các ràng buộc quá mức của giải pháp SOA, khiến cho sự dùng lại và nhanh chóng trong kinh doanh bị kém đi. Đầu tiên, chúng ta tạo một dự án mô hình dịch vụ Rational Software Architect gọi là PurchaseOrderProcessModel. Dự án này chứa một mô hình dịch vụ gọi là PurchaseOrderProcess. Mô hình này bao gồm một mô hình thông tin đối với dịch vụ, dữ liệu dịch vụ, đặc tính của các giao diện được cung cấp và yêu cầu. Nhưng bây giờ chúng ta tập trung chính vào xác định dịch vụ. Như thể hiện trong Hình 7, có năm gói chính trong mô hình PurchaseOrderProcess: org::ordermanagement chứa các phần tử được quan tâm cùng với quản lý • các đơn đặt hàng. org::crm chứa mô hình dữ liệu và các giao diện thông dụng cho các tiêu • chuẩn Quản lý quan hệ khách hàng (Customer Relationship Management) đã được hình dung, mà các khách hàng và cung cấp dịch vụ đã đồng thuận để phát triển các dịch vụ chia sẻ. com::acme::credit chứa các phần tử quan tâm cùng với quản lý hoá đơn và • tín dụng. com::acme::productions chứa các thành phần quan tâm cùng với sản • lượng và lịch trình. com::acme::shipping chứa các thành phần quan tâm cùng với vận chuyển. •
Năm gói này chia các miền có vấn đề thành các khu vực chức năng khác nhau. Nó giúp quản lý sự phức hợp, thiết lập các khoảng trống tên được yêu cầu, giúp tái sử dụng, và giữ các vấn đề quan tâm riêng lẻ trong các gói khác nhau (xem Hình 7). Hình 7. Sơ đồ phụ thuộc các gói. Tổ chức này có thể được gọi là tổ chức chi phối của mô hình dịch vụ. Các phần có thể sử dụng để dẫn chứng bằng tài liệu các phân lớp khác trong việc tổ chức các phần tử mô hình tương tự. Dịch vụ cấu trúc topo (Services topology) Chúng ta bắt đầu mô hình dịch vụ bằng việc xác định các dịch vụ được bao gồm khi xử lý một đơn hàng mua sắm. Đến đây, chúng ta không nhìn vào các chi tiết về các dịch vụ gì cũng như chúng tương tác thế nào. Chúng ta chỉ muốn tạo một phác hoạ về các dịch vụ là gì và một ý tưởng tốt về việc chúng có thể tương tác thế nào. Hình 8 là một sơ đồ đơn giản (hoặc sơ đồ không có định dạng chuẩn) trong Rational Software Architect, mà nó thể hiện các gói đại diện cho các khu vực chức năng kinh doanh, được miêu tả trước đây, và các dịch vụ chính sẽ được xác định
trong các gói này. Thông tin duy nhất được đưa ra về các dịch vụ cho đến lúc này là tên của nó. Sử dụng sự phụ thuộc trong sơ đồ một cách chủ đích để biểu hiện các dịch vụ dự kiến liên quan tới nhau thế nào. Đến đây, chúng ta không có các tính chất dịch vụ hoàn chỉnh, cũng không biết các yếu tố tham gia dịch vụ sẽ cung cấp hoặc yêu cầu dịch vụ gì. Chúng ta cũng không mô hình hoá bất cứ sự thực thi các dịch vụ này. Do đó, không có một cơ chế chuẩn mực về việc sử dụng sự phụ thuộc có nghĩa là gì. Chúng đơn giản là một cách xác định các sự thực thi được lường trước mà có thể đúng hoặc không đúng khi chúng ta hoàn thành sự thực thi và các đặc tính dịch vụ. Tuy nhiên, những sự phụ thuộc này có giá trị rất cao, vì chúng bắt đầu xác định sự sử dụng và hợp lại giữa các hệ thống cần quản lý một cách cẩn thận. Hình 8. Sơ đồ dịch vụ cấu trúc topo (Service topology diagram)