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

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

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

Điều hành công

việc

Truyền tải các mục tiêu, mục đích công việc

Chuyên viên phát

triển dịch vụ

Thực thi giải pháp IBM® Rational® Application Developer

and IBM® WebSphere® Integration

mạng 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)

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