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.

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

Jim Amsden là một nhân viên kỹ thuật lâu năm tại IBM với hơn 20 năm kinh nghiệm thiết kế và phát triển các ứng dụng và công cụ cho công nghiệp phát triển phần mềm. Ông có bằng Thạc sĩ về Khoa học Máy tính tại trường Boston. Sở thích của ông là phát triển các yêu cầu, lập trình mạng, phát triển hướng dịch vụ, J2EE UML, và các kiến trúc định hướng dịch vụ. Ông là đồng tác giả của cuốn "Enterprise Java Programming with IBM WebSphere". Hiện tại, Jim tập trung tìm cách tích hợp các công cụ để hỗ trợ tốt hơn cho quá trình phát triển phối hợp.



02 10 2007

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ụ
Điều hành công việcTruyền tải các mục tiêu, mục đích công việcRational RequisitePro
Chuyên viên phân tích công việcCác yêu cầu phân tích công việcWebSphere Business Modeler
Kiến trúc sư phần mềm Thiết kế kiến trúc các giải phápRational Software Architect
Chuyên viên phát triển dịch vụ mạng Thực thi giải phápIBM® Rational® Application Developer and IBM® WebSphere® Integration Developer

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)
Các yêu cầu công việc nêu trong các tiêu chuẩn cần thiết

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ố 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
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 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
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ụ
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.

<<serviceCollaboration (Hợp tác dịch vụ)>> 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.
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)
Sơ đồ dịch vụ cấu trúc topo

Lưu ý:
Dịch vụ topo (service topology) được khám phá và thiết kế như thế nào, vượt quá phạm vi của bài viết này. IBM RUP dành cho SOMA (xem tài nguyên) cung cấp một quy trình, các phương pháp và hướng dẫn làm thế nào để khám phá các dịch vụ từ các khu vực chức năng kinh doanh.

Một cách đơn giản để khám phá các dịch vụ yêu cầu là nhìn vào các yêu cầu kinh doanh được xác định như là sự hợp tác dịch vụ và nghĩ xem các nhà cung cấp dịch vụ nào sẽ được yêu cầu để đóng vai trò trong sự hợp tác đó. Chúng ta có thể thực sự chuẩn hoá điều này bằng cách tạo một sơ đồ biểu hiện các tính năng của dịch vụ sẽ được sử dụng nhằm đáp ứng đầy đủ thoả thuận hợp tác dịch vụ (Service Collaboration contract).

Hình 9 diễn tả một thành phần tóm lược mà mô hình hoá tình huống đối với quy trình các đơn đặt hàng mua sắm. Nó gồm một vài phần với định dạng là các đặc tính dịch vụ được thảo luận trước đây. Sơ đồ cũng trình bày cách thức sử dụng tiềm năng của các đặc tính dịch vụ trong một bối cảnh cụ thể. Chúng ta vẫn chưa biết các nhà cung cấp tham gia dịch vụ nào hoặc cách dùng các dịch vụ này, chỉ vài sự tham gia là chúng ta biết. Những phần này cũng là các bản tóm tắt, vì chúng là các ví dụ của đặc tính dịch vụ, chứ không phải ví dụ của các nhà cung cấp dịch vụ này.

Hình 9. Đáp ứng thoả thuận Yêu cầu Dịch vụ
Đáp ứng thoả thuận Yêu cầu Dịch vụ

Tuy nhiên, những gì sơ đồ này trình bày là làm sao các dịch vụ này đáp ứng đầy đủ thoả thuận yêu cầu hợp tác dịch vụ (Service Collaboration). Thoả thuận là một sử dụng hợp tác, một ví dụ của hợp tác dịch vụ Quy trình Đặt hàng Mua sắm (Process Purchase Order). Những thành phần của Quy trình Đặt hàng Mua sắm được giới hạn với vai trò của chúng trong thoả thuận. Nó cung cấp một đường dẫn ngược lại các yêu cầu kinh doanh và diễn tả mối liên quan kinh doanh của mỗi giao diện dịch vụ mà chúng ta đang dự định chỉ ra và thực hiện. Hành vi của hợp tác dịch vụ Quy trình Đặt hàng Mua sắm chỉ ra những phần dịch vụ này phải tương tác thế nào khi thực thi dịch vụ. Chúng ta sẽ xem xét lại điều này khi xác định và thực hiện các dịch vụ để đảm bảo rằng giải pháp đáp ứng các yêu cầu thoả thuận.

Những gì tiếp theo

Trong bài viết này, chúng ta phác hoạ một kỹ thuật để xác định dịch vụ được kết nối tới các yêu cầu kinh doanh. Chúng ta đã bắt đầu bằng cách nắm bắt mục tiêu kinh doanh và các mục tiêu cần thiết để hiện thực hoá các mục tiêu kinh doanh. Sau đó chúng ta đã mô hình hoá các phương thức kinh doanh và các quy trình cần thiết để đáp ứng các mục tiêu và nhiệm vụ. Tiếp theo, chúng ta xem xét quy trình kinh doanh như là một sự hợp tác dịch vụ mà đại diện một thoả thuận Yêu cầu Dịch vụ Kinh doanh phải được đáp ứng đầy đủ bởi các giải pháp cuối cùng của chúng ta. Sau đó, chúng ta đã sử dụng thoả thuận yêu cầu này để 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. Điều này đưa ra một cách chuẩn mực trong việc xác định các dịch vụ liên quan đến kinh doanh, được kết nối với các mục tiêu và mục đích kinh doanh mà chúng đã có chủ ý để đáp ứng.

Bài viết tiếp theo trong loạt bài viết này, Mô hình hoá SOA: Phần 2. Xác định dịch vụ sẽ mô hình hoá cụ thể đặc tính dịch vụ của mỗi dịch vụ. Các đặc tính này sẽ xác định các giao diện được cung cấp và được yêu cầu, vai trò của các giao diện này trong đặc tính dịch vụ, và các nguyên tắc hoặc giao thức làm sao để các nguyên tắc này tương tác với nhau trong việc cung cấp dịch vụ.


Tải về

Mô tảTênKích thước
RSM sample modelRSM_sample_model.zip60KB

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Rational, SOA và dịch vụ Web
ArticleID=390958
ArticleTitle=Mô hình hóa SOA: Phần 1: Xác định dịch vụ
publish-date=10022007