Sử dụng mô hình để thiết kế các quy trình nghiệp vụ và dịch vụ

Lắp ghép các thành phần bằng các công cụ mô hình hóa

Bạn sẽ nhận được một cái nhìn tổng quan về thiết kế quy trình nghiệp vụ và các dịch vụ, vai trò, các công cụ liên quan và các luồng công việc được dùng trong kiến trúc phần mềm. Tác giả nêu bật các lợi thế của việc tích hợp các phần và các dịch vụ trong một quy trình nghiệp vụ hay dịch vụ và đưa ra các ví dụ để trình bày những tác động mà các mô hình khác nhau mang theo các công cụ thường dùng để tạo ra các tạo phẩm có thể triển khai được. Tác giả cũng giải thích các kỹ thuật được sử dụng để đạt được các kết quả tốt, thậm chí từ các mô hình chưa hoàn chỉnh và tóm tắt các cách thực hành mô hình hóa SoaML để sử dụng khi lắp ráp các quy trình và các dịch vụ.

Tanya Wolff, Nhà phát triển chất lượng phần mềm, IBM

Ảnh của Tanya WolffTanya là nhà phát triển thuộc nhóm Rational Software Architect và nhóm Kiểm định hệ thống Green Threads (Green Threads System Verification Test). Cô đã thử nghiệm phát triển và tích hợp các sản phẩm Green Thread theo hướng nghiệp vụ bằng cách áp dụng các kịch bản đầu cuối, từ việc lấy yêu cầu đến việc triển khai trong một môi trường cộng tác có sử dụng các công cụ IBM Rational và WebSphere.



26 12 2012

Lựa chọn những đôi giày và những chiếc mũ

Khi các doanh nghiệp phát triển và thích ứng với thay đổi theo định hướng ngành nghề và các tiến bộ công nghệ thì các kiến trúc quy trình nghiệp vụ cũng phải liên tục được phân tích và tối ưu hóa các giải pháp hiện tại. Nhờ đưa ra các chiến lược mới để tự động hóa các dịch vụ hay cải thiện các quy trình, trong khi vẫn bám sát tầm nhìn nghiệp vụ và tối đa hóa việc tái sử dụng, các kiến trúc sư và các nhà phát triển có thể rút ngắn khoảng cách từ yêu cầu đến thực hiện, cung cấp các giải pháp tiện lợi, linh hoạt, có thể dò vết được. Các lợi ích này hỗ trợ cho việc tích hợp nghiệp vụ và tính nhanh nhẹn. Với sự ra đời của phiên bản IBM® Business Process Manager 7.5 (BPM - Trình quản lý Quy trình nghiệp vụ của IBM) và khả năng lấy nghiệp vụ làm trung tâm trong phiên bản IBM® Rational® Software Architect 8.0.4, có thể nói các nhà thiết kế phần mềm có thể lựa chọn và trang bị thêm những đôi giày và những chiếc mũ mới vào bộ công cụ của mình.

Việc xây dựng một giải pháp nghiệp vụ bắt đầu bằng phân tích các quy trình nghiệp vụ hiện tại và các dịch vụ Công nghệ thông tin (CNTT) hỗ trợ chúng. Rồi bạn xác định cách tiếp cận nào là thích hợp nhất để bắt đầu con đường đạt được các mục tiêu kinh doanh bằng cách chọn kiến trúc hướng dịch vụ (SOA - Service-Oriented Architecture) hoặc tiếp cận theo cách quản lý quy trình nghiệp vụ (BPM - Business Process Management) -- hay có thể ví von rằng nên đội chiếc mũ SOA hay BPM, nhớ rằng cả hai đều cần thiết trong vòng đời kiến trúc và phát triển. Với những kiến trúc sư có hiểu biết về các công cụ hỗ trợ, có kinh nghiệm và quan tâm đến cơ sở hạ tầng nghiệp vụ thì có thể phân tích những hạn chế và đưa ra chiến lược để thiết kế một giải pháp phù hợp. Còn những nhà phát triển thì được quyền chọn lựa "những đôi giày" -- đó là các công nghệ hay các công cụ -- để tuân thủ các yêu cầu, đưa giải pháp đó ra triển khai và duy trì quản trị giải pháp đó. Các nhà phát triển có thể cần một đôi giầy leo núi tốt nếu họ đang chuẩn bị leo dốc, họ sẽ cần một đôi giày đẹp khi muốn tập trung vào giao diện người dùng hoặc nếu thời gian đưa ra thị trường là điều cốt yếu thì họ cần đi đôi giày có thể chạy nhanh nhất.

Biểu đồ tổng quan trong Hình 1 cho thấy các công cụ liên quan đến cả hai cách tiếp cận, gồm có mô hình hóa, thực hiện, mô phỏng, triển khai và quản trị. Bạn bắt đầu mô hình hóa quy trình nghiệp vụ hay dịch vụ bằng cách sử dụng Rational Software Architect, phân tích và tối ưu hóa theo yêu cầu bằng cách sử dụng Process Designer (Bộ thiết kế quy trình) của BPM, tạo ra các đoạn mã nhờ sử dụng các công cụ chuyển đổi của Rational Software Architect và sau đó tiếp tục thực hiện với Integration Designer (Bộ thiết kế tích hợp) của BPM. Mục đích cuối cùng của việc triển khai ứng dụng quy trình nghiệp vụ hoặc dịch vụ hoàn chỉnh là một máy chủ quản lý quy trình nghiệp vụ (BPM Process Server). Có thể lưu trữ các máy chủ và các ứng dụng trong Trung tâm quy trình BPM ( BPMProcess Center). Hình 1 minh họa quy trình này.

Hình 1. Cấu trúc liên kết của thiết kế quy trình nghiệp vụ
Biểu đồ luồng công việc

Theo cách tiếp cận SOA, động cơ nghiệp vụ và các mục tiêu dẫn dắt thiết kế giải pháp thông qua định nghĩa các nhu cầu và các khả năng, là những ứng viên cho các dịch vụ. Rational Software Architect được dùng để xác định các mục tiêu nghiệp vụ như các trường hợp sử dụng và định nghĩa các chiến lược để đạt được chúng trong một kiến trúc các dịch vụ, gồm nhiều bên tham gia sử dụng và cung cấp dịch vụ. SOA cho phép nghiệp vụ này có nhiều khả năng tương thích và khả năng phân phối hơn, với các phần sử dụng lại được, bằng cách tách giao diện ra khỏi việc thực hiện, qua đó cải thiện tính thích ứng.

Mẹo nhỏ:
Để bắt đầu xây dựng một giải pháp SOA khi sử dụng Rational Software Architect, hãy tạo ra một mô hình UML với một khuôn mẫu thiết kế các dịch vụ, có đi kèm với các hướng dẫn từng bước của quy trình đó.

Trước tiên các kiến trúc sư BPM sẽ mô hình hóa quy trình nghiệp vụ, xác định tài nguyên và sự hòa phối (orchestration) có liên quan, để xem có thể cải thiện quy trình ở đâu. Giải pháp này được tinh chỉnh bằng cách trích xuất các giao diện được cung cấp và được yêu cầu từ những cộng tác như vậy thông qua phép chuyển đổi sang một mô hình dịch vụ. Từ đó, cấu trúc của giải pháp được mô tả chi tiết trong một hệ thống phân cấp theo gói của các bên tham gia và các dịch vụ. BPM đưa mô hình quy trình và việc thực hiện quy trình xích lại gần nhau hơn, dẫn dắt tới những giải pháp nhanh nhẹn hơn và có thể truy vết từ các yêu cầu đến bảo đảm chất lượng.

Mẹo nhỏ:
Để bắt đầu xây dựng một giải pháp quản lý quy trình nghiệp vụ (BPM) bằng Rational Software Architect, hãy tạo một dự án BPMN có một khuôn mẫu quy trình (process template) hoặc nếu bạn thích thiết kế nhiều quy trình cộng tác, hãy sử dụng một khuôn mẫu cộng tác (collaboration template). Để bắt đầu xây dựng giải pháp của bạn với Bộ thiết kế quy trình của IBM BMP, hãy tạo ra một ứng dụng quy trình mới trong Trung tâm quy trình và mở nó trong Bộ thiết kế quy trình. Bạn sẽ cần Phiên bản 7.5.1 của BPM để xuất khẩu (export) mô hình BPMN 2.0 (Business Process Modeling Notation 2.0 – Ký pháp mô hình hóa quy trình nghiệp vụ 2.0), mà mô hình này sẽ được nhập khẩu (import) vào Rational Software Architect. (Với Phiên bản 7.5 của Bộ thiết kế quy trình, bạn chỉ có thể nhập khẩu một mô hình BPMN 2.0).

Khi mô hình hóa, hai cách tiếp cận thường được trộn lẫn vào nhau. Như vậy, có thể xem một quy trình như một dịch vụ và ngược lại. Một quy trình gồm có các hoạt động tham chiếu các dịch vụ; có thể mô tả chi tiết mỗi dịch vụ bằng một biểu đồ hoạt động hay một quy trình. Khi sử dụng cách tiếp cận SOA, kiến trúc sư có thể chọn sử dụng các quy trình BPMN để mô tả các hợp đồng dịch vụ trong kiến trúc các dịch vụ và cho thấy các bên tham gia sử dụng và cung cấp các dịch vụ đã quy định trong các hợp đồng đó như thế nào. Mô hình BPMN, gọi cách tiếp cận BPM, có thể chứa các dịch vụ CNTT. Nếu vậy, kiến trúc sư sử dụng một mô hình SoaML để dựng lên các hoạt động của quy trình và các giao diện dịch vụ. Một dịch vụ CNTT như vậy có thể vẫn đòi hỏi sự tham gia đầy đủ hoặc một phần của con người.

Bất kể cách tiếp cận nào, nơi mà sự cộng tác của các bên tham gia có liên quan đến giải pháp đó, cả hai cách tiếp cận SOA và BPM đều hoàn thành một thiết kế và bắt đầu lắp ghép quy trình hoặc dịch vụ theo Ngôn ngữ mô hình hóa SOA (SoaML - SOA Modeling Language), như được trình bày trong trong mô tả sản phẩm Rational Software Architect. Các ví dụ trong bài này đề cập đến nhiệm vụ Lắp ghép của các bên tham gia (Assemble participants) trong tạo phẩm SoaML.


Lắp ghép một giải pháp quy trình hoặc dịch vụ

Việc có thể lắp ghép các bên tham gia trong giai đoạn mô hình hóa phát triển dựa vào nghiệp vụ trao cho nhà thiết kế nhiều quyền kiểm soát hơn về việc chỉ đạo sẽ chọn bên tham gia nào trong số các bên tham gia có thể hoàn thành một vai trò cho một việc thực hiện cụ thể. Các bên tham gia trưng ra các dịch vụ do họ cung cấp và biểu diễn các dịch vụ cần thiết thông qua các cổng (ports). Các cổng được định kiểu bằng các giao diện dịch vụ (service interfaces), mô tả các hoạt động có sẵn và các tham số đầu vào và đầu ra của chúng. Các bên tham gia được lắp ghép theo một biểu đồ cấu trúc hỗn hợp (composite structure diagram) của một bên tham gia riêng biệt, bên tham gia hỗn hợp hoặc bên tham gia lắp ghép. Cơ cấu bên trong của bên tham gia này thu gom các cá thể (instances) của các bên tham gia cộng tác làm các đặc tính của bên tham gia lắp ghép.

Trong cấu trúc hỗn hợp, các cổng trên các cá thể của bên tham gia được kết nối theo các kênh dịch vụ (service channels), gói gọn các tương tác giữa các bên tham gia. Các cá thể và các kênh dịch vụ này điều khiển các công cụ chuyển đổi UML-sang-SOA (UML-to-SOA transformation) trong Rational Software Architect để tạo ra các tạo phẩm thực hiện và thiết lập thông tin kết buộc trong việc thực hiện giải pháp đã lắp ghép.

Một giải pháp khác cho quy trình hoặc dịch vụ tương tự đang phát triển có thể sử dụng hoặc một số hoặc tất cả các bên tham gia giống nhau hoặc các bên tham gia mới với các cách thực hiện khác nhau, nhưng lại trưng ra các giao diện giống nhau để thích ứng với các nhu cầu nghiệp vụ khác nhau.


Các lợi ích của việc lắp ghép với các công cụ mô hình hóa

Việc lắp ghép các bên tham gia khi sử dụng các công cụ mô hình hóa được cung cấp trong phiên bản 8.0.4 của Rational Software Architect làm cho nhiệm vụ này thành một bước thiết yếu trong phát triển quy trình hoặc dịch vụ và nó rất có ích về một số mặt, như được mô tả trong các mục nhỏ sau đây.

Hiệu quả

Các kiến trúc sư SOA và BPM có thể chuyển đổi một mô hình dịch vụ đã hoàn chỉnh thành các tạo phẩm thực hiện và chuyển giao chúng cho các nhà phát triển tích hợp để tiếp tục dòng chảy của vòng đời phát triển SOA. Trước phiên bản 8.0.4 của Rational Software Architect, nhiệm vụ lắp ghép các bên tham gia được thực hiện bởi cả hai vai trò; kiến trúc sư có thể mô hình hóa các kết nối giữa các bên tham gia đã lắp ghép, trong khi các nhà phát triển tích hợp, sau khi nhập khẩu vào Bộ thiết kế tích hợp (Integration Designer), lại kết nối các phần bằng cách chỉ rõ thông tin kết buộc với mỗi nhập khẩu. Sự trùng lắp về công sức này được xoá bỏ nhờ việc nâng cấp phép chuyển đổi trong phiên bản 8.0.4.

Bây giờ Rational Software Architect chuyển đổi các bên tham gia đã lắp ghép theo một quy trình hoặc theo SOA thành một tập hợp các mô đun SCDL (Service Component Definition Language - Ngôn ngữ định nghĩa thành phần dịch vụ), được nối với nhau thông qua dịch vụ SCA (Service Component Architecture - Kiến trúc thành phần dịch vụ) và các nhập khẩu và xuất khẩu tham chiếu, khi thiết lập chính xác các đích nối SCA và các kết buộc nhập khẩu.

Khả năng dò vết

Các cá thể của bên tham gia đã lắp ghép biểu diễn các vai trò theo sự cộng tác hay giải pháp. Mỗi cá thể thành phần trong giải pháp được truy cập qua các cổng và việc thực hiện của chúng được biểu diễn bằng các hành vi trong định nghĩa thành phần, do đó hoàn thành đặc tả về các mục tiêu nghiệp vụ.

Việc sử dụng quy trình SOMA (Rational Service-Oriented Modeling and Architecture – Kiến trúc và Mô hình hóa hướng dịch vụ Rational) trong việc mô hình hóa các giải pháp tinh chỉnh các mục tiêu nghiệp vụ theo hướng thực hiện.

  • Trước tiên, xác định các dịch vụ cần thiết để đạt được các mục tiêu nghiệp vụ bằng cách sử dụng các vai trò và các cộng tác.
  • Thứ hai, quy định các dịch vụ qua các giao diện dịch vụ và các giao thức.
  • Cuối cùng, chúng được thực hiện thành các thành phần, các cổng và các kênh dịch vụ.

Mỗi giai đoạn là một bước tinh chỉnh thêm nữa của đặc tả.

Ở đây các quy trình nghiệp vụ hoặc các yêu cầu được quy định qua các trường hợp sử dụng và các mô hình nghiệp vụ, việc xác định dịch vụ là một sự tinh chỉnh thành các vai trò và các cộng tác. Tiếp đó, dần dần chúng lại được tinh chỉnh thành các hợp đồng dịch vụ và các giao diện và các vai trò và sau đó tiếp tục tinh chỉnh thành các dịch vụ và các hành vi.

Sau khi tất cả các giai đoạn tinh chỉnh để hoàn thiện định nghĩa trừu tượng của các dịch vụ hoặc ác hành vi, giai đoạn thực hiện bắt đầu bằng việc lắp ghépcác bên tham gia. Nhiệm vụ lắp ghép này là cái cho phép kiến trúc sư chỉ rõ các kênh truyền dẫn giữa các bên tham gia và thực hiện các vai trò theo cộng tác. Dịch vụ đã trưng ra dựa vào bên tham gia lắp ghép có thể dễ dàng dò vết ngược lại tới yêu cầu nghiệp vụ hoặc trường hợp sử dụng hệ thống.

Tính linh hoạt

Khả năng để thiết kế mô hình các dịch vụ từ việc xác định dịch vụ đến lắp ghép các bên tham gia tập trung vào các sở thích của nhà thiết kế trong việc dẫn dắt các giải pháp theo hoặc một phối cảnh SOA hoặc một phối cảnh BPM hoặc cả hai. Chúng ta có thể thiết kế một kiến trúc dịch vụ bằng UML để xác định các dịch vụ hoặc thiết kế một quy trình theo một mô hình BPMN để minh họa các hoạt động có liên quan và xác định các dịch vụ ứng cử viên. Có thể coi một bên tham gia lắp ghép như là bên cung cấp một dịch vụ hoặc quy trình, theo cách tiếp cận.

Từ phối cảnh SOA, các trường hợp sử dụng được thực hiện bởi một bên tham gia đang cung cấp một giao diện dịch vụ đơn giản hoặc bởi một bên tham gia lắp ghép có các cá thể của hai hoặc nhiều bên tham gia cộng tác.

Từ phối cảnh BPM, các quy trình nghiệp vụ cũng có thể là đơn giản hoặc cộng tác. Các quy trình nghiệp vụ đơn giản được thực hiện bởi một bên tham gia đơn lẻ đại diện cho một doanh nghiệp hoặc một phòng ban trong một doanh nghiệp, trong khi quy trình cộng tác liên quan đến nhiều phòng ban hoặc nhiều đối tác kinh doanh.

Tiện lợi

Các nhà thiết kế triển khai sử dụng các lợi thế của cả BPM lẫn SOA khi xem xét hệ thống đích của các thành phần. Mặc dù dịch vụ hoặc quy trình đơn giản có thể được thực hiện bởi một mô đun JEE (Java Enterprise Edition - Ấn bản doanh nghiệp Java) hoặc quy trình BPEL (Business Process Execution Language - Ngôn ngữ thực hiện quy trình nghiệp vụ), các giải pháp hoặc các quy trình cộng tác có thể tích hợp một sự pha trộn các cách thực hiện. Không chỉ là các cách thực hiện này có khả năng hoán đổi lẫn nhau theo các sở thích của các nhà phát triển, mà chúng thường bị buộc phải có trong các công cụ. Một phép chuyển đổi UML-sang-SOA sẽ tạo ra một cách thực hiện BPEL cho một bên tham gia đang trưng ra nhiều dịch vụ để định tuyến cuộc gọi dịch vụ tới các dịch vụ thích hợp. Tầm quan trọng của việc lắp ghép UML được thấy rõ trong cách nó tích hợp, phân phối và thích ứng với nhiều bên tham gia, nhiều dịch vụ và nhiều công nghệ trong việc xây dựng các giải pháp gắn kết cho doanh nghiệp.


Phép chuyển đổi sang SOA hoạt động thế nào

Với phiên bản 8.0.4 của Rational Software Architect, khả năng để tạo ra SCDL với các nhập khẩu được kết buộc chính xác từ một bên tham gia lắp ghép trong một mô hình SoaML có thể được trình bày bằng một vài ví dụ để cho thấy thuật toán chuyển đổi hoạt động như thế nào. Các phép chuyển đổi đúng do việc rà soát các kênh dịch vụ trên một phần của các thành phần lắp ghép đã được ủy thác việc thực hiện dịch vụ được cung cấp. Một lời giải thích về thuật toán đang làm việc là rất có ích trong việc tìm hiểu một số kết quả.

Khi chuyển đổi một bên tham gia lắp ghép, Rational Software Architect thực hiện thuật toán lắp ráp chuyển đổi được hiển thị trong Liệt kê 1.

Liệt kê 1. Thuật toán lắp ghép chuyển đổi
1.  Given a composite participant, find the participant instances in the internal structure of 
    the composite that are delegated from its ports.
2.  For each instance delegate:
       a.  Create an SCA module with a SCDL component and an export
       b.  Find all of the participant instances connected by service channels to the instance.
       c.  For each instance,
             i.  Create an SCDL import in the current module and set the binding properties.
            ii.  Inspect the instance's type.
           iii.  If it has a composite structure, call the transform assembly  (recurse).
            iv.  Otherwise, create an SCA module with a component and an export.
Hình 2. Biểu đồ tiến trình để chuyển đổi bên tham gia lắp ghép
Biểu đồ của luồng công việc

Thuật toán này đệ quy với mỗi bên tham gia dọc theo cây ủy thác, duyệt qua các kết nối, tạo ra các mô đun SCA. Phép đệ quy kết thúc khi gặp một bên tham gia đơn giản không có cấu trúc bên trong; có nghĩa là, nó không đòi hỏi thêm giao diện nào.


Các ví dụ

Để minh họa các hoạt động bên trong phép chuyển đổi này và các hạn chế của nó, cần có các ví dụ với các lắp ghép liên quan đến nhiều hơn một bên tham gia, với ít nhất ba bên tham gia. Điều này đòi hỏi có một bên tham gia lắp ghép và ít nhất hai bên tham gia có liên quan đến một cộng tác, ở đó cuộc đối thoại xảy ra trong một kênh dịch vụ đơn nhất giữa chúng.

Các ảnh chụp màn hình cho thấy mô hình trong Rational Software Architect trước khi các công cụ chuyển đổi được áp dụng và cấu trúc SCA đã tạo ra trong Bộ thiết kế tích hợp sau khi chuyển đổi. Trong trường hợp mà phép chuyển đổi đưa ra các kết quả lạ do một mô hình lắp ghép không đúng, một sự lựa chọn kỹ thuật phục hồi được đưa ra cho người dùng Bộ thiết kế tích hợp để có thể làm việc với các tạo phẩm đã cho.

Ba thiết kế SoaML minh họa các kết quả thành công của việc chuyển đổi các bên tham gia đã lắp ghép trong bộ thiết kế tích hợp của IBM:

  • Thiết kế đơn giản trình bày sự cộng tác đơn giản nhất: hai bên tham gia đã lắp ghép, một giao diện đã cung cấp được ủy thác.
  • Thiết kế lồng nhau trình bày các bên tham gia lắp ghép lồng nhau. Mỗi bên tham gia lắp ghép có một giao diện đã cung cấp được ủy thác và hai bên tham gia đã lắp ghép.
  • Thiết kế kép trình bày một giải pháp có hai giao diện được cung cấp. Nó có thể biểu diễn một quy trình nghiệp vụ có hai điểm nhập vào hoặc nhiều khả năng hơn, là một giải pháp SOA cung cấp nhiều hơn một giao diện dịch vụ.

Một thiết kế thứ tư cho thấy sự hạn chế hiện tại của phép chuyển đổi trong việc điều chỉnh các lắp ghép không đầy đủ.

  • Thiết kế không ủy thác (NoDelegate) trình bày tác động của việc lắp ghép các bên tham gia, nhưng bên tham gia lắp ghép hoặc không cung cấp một dịch vụ hoặc không ủy thác một trong các phần của nó. Thiết kế này chưa hoàn thành và không có cảnh báo nào từ Rational Software Architect, do đó kiến trúc sư cung cấp kết quả này cho nhà phát triển. Ví dụ này cung cấp các kỹ thuật cho các nhà phát triển để sử dụng trong việc hoàn thành mô hình trong Bộ thiết kế tích hợp.

Chắc chắn có thể có các thiết kế khác nữa. Ví dụ, các cuộc hội thoại phức tạp hơn có thể góp phần tăng thêm số cổng và các kênh dịch vụ giữa các bên tham gia trong cùng quy trình đó, có thể hình dung ra nhiều sự trừu tượng hóa và hiện thực hóa hơn để góp phần tăng thêm mức lồng nhau sâu hơn và, tất nhiên, có thể có nhiều bên tham gia hơn, do đó đóng góp nhiều dịch vụ hay quy trình hơn mà trường hợp sử dụng hoặc việc thiết kế quy trình nghiệp vụ đòi hỏi.

Sự cộng tác đơn giản của hai bên tham gia

Mô hình này cho thấy hai bên tham gia; bên thứ nhất có một hoạt động UML như là hành vi của nó, gọi hoạt động trong bên tham gia thứ hai. Các hướng dẫn SoaML nhấn mạnh việc giảm thiểu việc ghép đôi, vì vậy tất cả các kết nối đều là giữa các cổng. Một kết nối ủy thác nối các cổng bên trong đến một cổng cùng kiểu dựa vào bên tham gia lắp ghép, trong khi các kênh dịch vụ kết nối các cổng yêu cầu đến các cổng dịch vụ bên trong cấu trúc của bên tham gia lắp ghép.

Hình 3. Lắp ghép một cộng tác đơn giản
Biểu đồ của mô hình

Phép chuyển đổi UML-sang-SOA trên mô hình này sinh ra các mô đun SCA và một thư viện. Mỗi mô đun com.simple.Part1.Participantcom.simple.Part2.Participant có một thành phần và một xuất khẩu. Mô đun đầu tiên cũng có một triển khai thực hiện BPEL trong hành vi của thành phần và một nhập khẩu để tham chiếu các dịch vụ cần thiết trên mô đun thứ hai. Nhập khẩu có các đặc tính kết buộc với tên mô đun và tên xuất khẩu, trỏ đến xuất khẩu trên mô đun thứ hai (nhập khẩu trong com.simple.part1.Participant được kết buộc với xuất khẩu của com.simple.part2.Participant).

Hình 4. Các thành phần SCA của một sự cộng tác đơn giản
Biểu đồ mô đun SCA có các đặc tính nhập khẩu

Các bên tham gia lồng nhau

Mô hình UML này cho thấy ba bên tham gia: bên thứ nhất yêu cầu bên thứ hai, bên thứ hai yêu cầu bên thứ ba. Có hai lắp ghép trong mô hình UML là A1 và A2. A2 là lắp ghép lồng nhau có chứa bên tham gia thứ hai và thứ ba.

Hình 5. Lắp ghép các bên tham gia lồng nhau
Mô hình hợp phần A2 lồng nhau

Kết quả được tạo ra từ phép chuyển đổi này trình bày quy trình đệ quy trong thuật toán. Các mô đun tương ứng với Participant (Bên tham gia), Participant2 và Participant3. Mặc dù có năm bên tham gia trong mô hình UML, phép chuyển đổi này chỉ tạo ra ba mô đun SCA. Mục đích của việc lắp ghép các bên tham gia sẽ xác định các đặc tính kết buộc đối với các nhập khẩu của các mô đun ủy thác như trong Bộ thiết kế tích hợp trong Hình 6.

Hình 6. Các thành phần SCA trong các lắp ghép lồng nhau
3 mô đun SCA và các đặc tính kết buộc

Ủy thác kép

Mô hình UML này cho thấy hai bên tham gia. Mỗi bên cung cấp một giao diện và mỗi bên đều yêu cầu bên kia. Đây là nơi kiến trúc sư sẽ thấy các lợi ích của việc ghi nhận sự hiệp lực giữa các cách tiếp cận BPM và SOA. Một kiến trúc sư BPM sẽ thiết kế một quy trình ở đó tên của bên tham gia lắp ghép phản ánh quy trình mà các bên tham gia cộng tác đang nói về nó. Tuy nhiên, trong ví dụ này, bản thiết kế tuân theo các hướng dẫn về cách thực hành lắp ghép tốt, trong đó một đầu nối ủy thác sẽ được thêm vào tất cả các giao diện được cung cấp bên trong lắp ghép còn chưa được kết nối. Điều này giống như một giải pháp SOA: cung cấp một tập các giao diện, chứ không phải là một quy trình đơn lẻ. Nhà thiết kế đội mũ SOA tự đắc, còn nhà thiết kế đội cái mũ BPM bắt đầu lo lắng. Thế nhưng hãy giữ lại cái mũ BPM ấy, bởi vì nó sẽ làm cho việc hiểu phép chuyển đổi dễ dàng hơn.

Hình 7. Lắp ghép nhiều dịch vụ
Hợp phần mô hình UML có 2 ủy thác

Nhấp vào để xem ảnh lớn

Hình 7. Lắp ghép nhiều dịch vụ

Hợp phần mô hình UML có 2 ủy thác

Sau khi chuyển đổi bên tham gia lắp ghép UML, SCA kết quả có chứa một mô đun SCDL cho mỗi bên tham gia trong hợp phần. Mỗi mô đun có chứa một nhập khẩu được kết buộc với xuất khẩu khác. Kết quả này có thể làm cho kiến trúc sư SOA bối rối, bởi vì nó vẫn còn sinh ra hai mô đun, một mô đun cho mỗi quy trình, thỏa mãn phong cách BPM.

Hình 8. Các thành phần SCA của nhiều dịch vụ
2 mô đun SCA có các kết buộc nhập khẩu SCA

Lưu ý:
Những ví dụ này cho thấy các quy trình và các dịch vụ được cung cấp chỉ ở mức giao diện. Về lý thuyết, có thể có một vài hoạt động được cung cấp trong mỗi giao diện. Tuy nhiên, một giải pháp theo phong cách-BPM chỉ có một phương thức duy nhất trong giao diện của nó để biểu diễn quy trình, trong khi ở SOA, một bên tham gia có thể thực hiện nhiều phương thức, trưng ra tất cả các phương thức này trong một giao diện đơn lẻ hoặc trong nhiều giao diện riêng biệt. Nếu kiến trúc sư SOA chỉ thấy một mô đun đơn lẻ trong SCA được tạo, thì họ sẽ thiết kế một bên tham gia mới có sử dụng cả hai bên tham gia, cung cấp bất kỳ số lượng dịch vụ nào và bọc cả ba bên tham gia trong một bên tham gia lắp ghép thứ tư. Sau đó, hai giao diện được trưng ra ban đầu sẽ được kết nối thông qua các kênh dịch vụ tới bên tham gia thứ ba.

Hình 9. Lắp ghép các thành phần bằng cách sử dụng nhiều dịch vụ
Hợp phần có 3 cá thể bên tham gia

SCA kết quả sẽ có các khối xây dựng gốc như trong ví dụ Ủy thác kép (Double Delegation) ban đầu, cộng với mô đun mới sẽ nhập khẩu cả hai.

Hình 10. Các thành phần SCA khi sử dụng nhiều dịch vụ
3 mô đun SCA và các đặc tính kết buộc nhập khẩu

Nhấp vào để xem ảnh lớn

Hình 10. Các thành phần SCA khi sử dụng nhiều dịch vụ

3 mô đun SCA và các đặc tính kết buộc nhập khẩu

Lắp ghép không có ủy thác nào

Mô hình UML lắp ghép các bên tham gia trong một kịch bản đơn giản, nhưng không ủy thác.

Theo hướng dẫn trong bản hướng dẫn khuôn mẫu mô hình hóa dịch vụ, bên tham gia lắp ghép cần tạo ra một đầu nối ủy thác cho tất cả các giao diện được cung cấp mà còn chưa được kết nối với một cổng yêu cầu. Ví dụ này cho thấy những gì sẽ xảy ra nếu chúng ta không hoàn thành mô hình này.

Hình 11. Lắp ráp không cần ủy thác
Hợp phần UML không có đầu nối ủy thác nào

Phép chuyển đổi tạo ra các mô đun khối xây dựng cho mỗi bên tham gia trong lắp ghép, cũng như một mô đun lắp ghép riêng biệt, nhưng không tạo ra các nhập khẩu đúng trong mô đun lắp ghép. Việc thực hiện các thành phần kết quả trong lắp ghép chứ không phải trong các mô đun riêng của chúng, vì vậy nên tránh luồng công việc này. Tốt nhất là để lại các thành phần không được kết nối. Đừng bọc chúng trong một lắp ghép cho đến khi bạn đã sẵn sàng để ủy thác dịch vụ đó cho một việc thực hiện cụ thể.

Hình 12. Các thành phần SCA không được xuất khẩu
Các mô đun SCA cho tất cả các bên tham gia UML

Cách giải quyết khác

Nếu bạn không có quyền truy cập vào mô hình ban đầu để bổ sung ủy thác hoặc loại bỏ bên tham gia lắp ghép, có các cách tiếp cận khác mà bạn có thể thực hiện để sửa chữa mô đun trong Bộ thiết kế tích hợp.

Hiện nay, trong phiên bản 8.0.4 của Rational Software Architect, bạn sẽ thấy ba mô đun được tạo ra:

  • com.noDelegate.Part1.Assembly
    Gồm có hai thành phần và một xuất khẩu. Không có dây nối nào đến xuất khẩu này vì không có ủy thác nào trong mô hình UML. Một trong các thành phần có một cách thực hiện BPEL trong biểu diễn SCDL của nó, trỏ đến tệp, com/noDelegate/Part1/Participant.bpel vẫn chưa tồn tại trong mô đun này. SCDL cho thành phần này có chứa mã sau:
<implementation xsi:type="process:ProcessImplementation">
 <scdl:implementationQualifier xsi:type="scdl:Transaction" value="global"/>
 <process bpel="com/noDelegate/Part1/Participant.bpel"/>
</implementation>
  • com.noDelegate.Part1.Participant

Có chứa một thành phần không có cách thực hiện nào trong SCDL của nó, một xuất khẩu có kiểu giao diện com.noDelegate.Part1.ServiceInterface và một nhập khẩu có kiểu giao diện com.noDelegate.Part2.ServiceInterface2. Tuy nhiên, đặc tính kết buộc vẫn chưa quy định một mô đun/xuất khẩu đích. Có một tệp BPEL trong thư mục com/noDelegate/Part1.

  • com.noDelegate.Part2.Participant
    Gồm có một thành phần và một xuất khẩu.

Phép chuyển đổi tạo ra một tập các mô đun khối xây dựng như dự kiến, nhưng nó cũng tạo ra một mô đun cho bên tham gia lắp ghép. Mô đun này cố gắng để lắp ghép các khối xây dựng thực tế, chứ không phải nhập khẩu các tham chiếu đến chúng. Điều này làm cho việc triển khai các thành phần này rút cục sai vị trí.

Bạn phải quyết định xem bạn có muốn ẩn các khối xây dựng trong mô đun lắp ghép không, bằng cách chọn tiếp tục làm việc với mô đun com.noDelegate.Part1.Assemblyhay là giữ nguyên các khối xây dựng bằng cách tiếp tục làm việc với các mô đun com.noDelegate.Part1.Participantcom.noDelegate.Part2.Participant.

Phương pháp để lắp ghép các thành phần bên trong mô đun là phương pháp từ trên xuống, tương tự như soạn một thành phần cấu trúc con trong UML. Cách tổ hợp cấu trúc con là mâu thuẫn với tôn chỉ về sử dụng lại mô đun và nó chỉ nên được thực hiện nếu không hề cần đến các bộ phận này ở bên ngoài tổ hợp đó, do đó loại bỏ sự cần thiết tạo ra các thành phần có thể triển khai riêng biệt. Để xây dựng sự cộng tác, việc sử dụng một phương pháp từ dưới lên sẽ là thực hiện các bước mà phép chuyển đổi thường phải làm nếu mô hình đã được tạo đúng bằng UML. Các khối xây dựng vẫn còn nguyên vẹn và nằm ngoài mô đun lắp ghép đang được xây dựng.

Thực hiện các bước theo phương pháp bạn đã chọn để hoàn thành sự cộng tác trong Bộ thiết kế tích hợp (ID).

Cách giải quyết từ trên xuống

Một mô đun lắp ghép gồm có các thành phần được kết nối nội bộ.

  1. Di chuyển BPEL từ mô đun com.noDelegate.Part1.Participant vào mô đun com.noDelegate.Part1.Assembly. Bạn có thể sao chép hệ thống phân cấp thư mục đầy đủ từ khung nhìn Navigator (Dẫn hướng). Bảo đảm rằng tệp ParticipantArtifacts.wsdl cũng được sao chép và vào cùng một thư mục như BPEL.
  2. Xóa và xây dựng lại mô đun com.noDelegate.Part1.Assembly. Bảo đảm rằng BPEL được đặt đúng vị trí bằng cách nhấn đúp phím chuột trên thành phần này trong biểu đồ lắp ghép. Thao tác này sẽ mở ra biểu đồ BPEL.
  3. Sửa chữa các lỗi mới trong các đặc tính của thành phần như các dấu báo lỗi đề xuất. Ảnh chụp màn hình trong Hình 13 cho thấy các đặc tính đúng cho giao diện và tham chiếu.
Hình 13. Các đặc tính giao diện trong thành phần đã chỉnh sửa
Biểu đồ lắp ráp có các đặc tính giao diện
Hình 14. Các đặc tính tham chiếu trong thành phần đã chỉnh sửa
Biểu đồ có các đặc tính tham chiếu, đã chỉnh sửa
  1. Nối xuất khẩu tới giao diện đang được cung cấp.
  2. Xóa các mô đun sau:
    • com.noDelegate.Part1.Participant
    • com.noDelegate.Part2.Participant

Cách giải quyết từ dưới lên

Giữ nguyên các khối xây dựng – các bên tham gia cộng tác -- ở bên ngoài việc lắp ghép và tham chiếu đến chúng bằng cách sử dụng các nhập khẩu trong mô đun lắp ghép. Trong ví dụ này, khối xây dựng duy nhất là dịch vụ cần thiết được thực hiện trong com.noDelegate.Part2.Participant. Com.noDelegate.Part1.Participant là mô đun để nhập khẩu khối xây dựng đó. Mô đun com.noDelegate.Part1.Assembly là không cần thiết.

  1. Sao chép thẻ implementation từ thành phần của mô đun đầu tiên vào thành phần của mô đun thứ hai.
  2. Xóa mô đun đầu tiên là, com.noDelegate.Part1.Assembly.
  3. Tạo một module mới gọi là com.noDelegate.Assembly có một thành phần SCA và một xuất khẩu SCA nối với nó.
  4. Thêm thông tin kết buộc tới nhập khẩu trong mô đun thứ hai, com.noDelegate.Part1.Participant. Kết quả sẽ giống như Hình 4, các thành phần SCA của một cộng tác đơn giản, trong ví dụ đầu tiên.

Bây giờ SCDL của mô đun tổ hợp đã hoàn thành. Bạn có thể tiếp tục thực hiện các khối xây dựng hoặc các thành phần nằm bên trong tạo nên lắp ghép đó. Khi thực hiện xong, bạn có thể làm cho nó có thể triển khai được như một dịch vụ web bằng cách tạo ra một kết buộc dịch vụ web trên xuất khẩu và bằng cách triển khai mô đun đó đến một máy chủ quy trình.


Các hướng dẫn mô hình hóa SoaML

Tối đa hóa việc sử dụng lại và giảm thiểu ghép đôi khi lắp ghép các bên tham gia bằng cách làm theo các cách thực hành tốt nhất được hướng dẫn bởi "Mô hình hoá với SoaML, Phần 4. Tổ hợp dịch vụ" của Jim Amsden (xem Tài nguyên để biết một liên kết đến loạt bài năm phần này):

  • Lắp ghép các bên tham gia thông qua sử dụng các tham chiếu đến các bên tham gia đã lắp ghép, bằng cách kéo thả các bên tham gia vào biểu đồ cấu trúc tổ hợp để tạo ra các cá thể bên tham gia.
  • Mô hình hóa các khả năng và các nhu cầu của bên tham gia thông qua các cổng dịch vụ và các cổng yêu cầu thay vì các mối quan hệ trực tiếp từ bên tham gia đến các giao diện dịch vụ.
  • Trong cấu trúc bên trong của bên tham gia lắp ghép, sử dụng các kênh dịch vụ giữa các cổng dịch vụ và các cổng yêu cầu của các cá thể bên tham gia để hoàn thành việc thực hiện dịch vụ hoặc quy trình mà bên tham gia lắp ghép biểu diễn.
  • Giữ cho định nghĩa bên tham gia và mô hình hóa lắp ghép như là các mối quan tâm tách biệt nhau. Các định nghĩa thành phần ở mức lớp, trong khi việc lắp ghép ở mức cá thể.
  • Sử dụng một bên tham gia làm bên tham gia lắp ghép, thay cho một hệ thống con vì nó hạn chế việc sử dụng lại các bên tham gia chứa trong đó
  • Bên tham gia lắp ghép phải có ít nhất một đầu nối ủy thác từ một dịch vụ được trưng ra đến một cổng của cá thể bên tham gia bên trong. Tất cả các cổng trong biểu đồ cấu trúc tổ hợp chưa được kết nối cần được ủy thác cho các cổng của bên tham gia lắp ghép.

Tóm tắt

Mô hình hóa một kiến trúc hướng dịch vụ đơn giản hoá việc phát triển một giải pháp quy trình hoặc dịch vụ, nơi có thể cải thiện hoặc thực hiện một quy trình nghiệp vụ. Việc lắp ghép các quy trình và các dịch vụ liên quan trong giải pháp nghiệp vụ là một nhiệm vụ của kiến trúc sư, được thực hiện trong Rational Software Architect. Trước phiên bản 8.0.4 của Rational Software Architect, kiến trúc sư được khuyên nên bỏ qua bước lắp ghép này khi mô hình hóa theo SoaML (xem Các vấn đề tích hợp BPM của IBM trong việc mô hình hóa và các phép chuyển đổi kiến trúc các quy trình nghiệp vụ và dịch vụ) và chuyển nhiệm vụ này cho nhà phát triển để hoàn thành các kết nối giữa các bên tham gia sau khi đã nhập khẩu các tạo phẩm được tạo ra vào Bộ thiết kế tích hợp (ID).

Bắt đầu từ phiên bản 8.0.4 của Rational Software Architect, sẽ hiệu quả hơn nếu nối các thành phần trong giai đoạn mô hình hóa khi phát triển quy trình. Nó đem lại nhiều tính linh hoạt thiết kế hơn bằng cách cung cấp các công cụ cho cả kiến trúc sư BPM lẫn kiến trúc sư SOA sử dụng. Các sản phẩm có thể tiện dụng hơn nhờ đưa ra các tích hợp trơn tru hơn cho các kiến trúc sư và các nhà phát triển, duy trì khả năng dò vết cho các quyết định thiết kế trong suốt quá trình phát triển và thực hiện mô hình hóa dịch vụ.

Bài này đã sử dụng các mô hình đơn giản để trình bày cách phép chuyển đổi UML-sang-SOA tạo ra các mô đun, các thành phần, các nhập khẩu và các xuất khẩu SCA và thiết lập các đặc tính kết buộc nhập khẩu đối với các nhập khẩu được tạo ra từ các giao diện cần phải có. Các kỹ thuật được đưa ra để hoàn thành việc lắp ghép SCA trong Bộ thiết kế tích hợp, nơi có thể không thấy các quá trình thực hiện SCDL và các đặc tính nhập khẩu. Một tập các cách thực hành tốt nhất để lắp ghép các bên tham gia bằng cách sử dụng SoaML đã được thu thập từ các bài viết trên developerWorks.

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
ArticleID=853384
ArticleTitle=Sử dụng mô hình để thiết kế các quy trình nghiệp vụ và dịch vụ
publish-date=12262012