Mô hình hóa hướng quy trình cho SOA, Phần 1: Một kỹ thuật phân rã quy trình

Làm thế nào để xác định các mô hình phù hợp quy trình nghiệp vụ với SOA

Bài đầu tiên này đi về phân rã một quy trình nghiệp vụ thành các lớp khác nhau của việc gán trách nhiệm — đối lập với các mức chi tiết khác nhau— và cũng xem xét vai trò của các bộ điều khiển quy trình cũng như làm cách nào các dịch vụ được xác định bởi chúng cần ở đâu. Trong loạt bài này, học về một kỹ thuật phân rã mới có thể giúp bạn xác định quy trình nghiệp vụ phù hợp với một kiến trúc hướng dịch vụ (Service-Oriented Architecture SOA).

Ruud Schoonderwoerd, Tư vấn, IBM

Ruud Schoonderwoerd photoRuud Schoonderwoerd là một cố vấn quản trị và kiến trúc sư công nghệ thông tin (IT) của IBM Global Business Services ở Anh Quốc. Ông ta làm về các chương trình công nghệ thông tin lớn ở phía khách hàng IBM, tập trung vào BPM, SOA và các phương thức phân phối



10 07 2009

Giới thiệu

Mô hình hóa quy trình đang ngày càng quan trọng đối với các dự án CNTT dựa trên SOA. Bạn có thể dùng mô hình hóa quy trình để xác định các dịch vụ, các yêu cầu cấu trúc, và định nghĩa các quy trình nghiệp vụ thực thi trên một nền tảng quản lý quy trình nghiệp vụ (business process management - BPM).

Phần 2 sẽ giải thích về thông tin trong bài này bằng cách dùng một tập các mẫu quy trình nghiệp vụ. Các bài sau sẽ tìm hiểu làm thế nào cách tiếp cận này có khả năng cải thiện cách các nhà phân tích nghiệp vụ thu thập các yêu cầu và cấu trúc các ca sử dụng, và các nhà kiến trúc xác định các giải pháp SOA

Mô hình hóa quy trình, thứ được hiểu bởi cả doanh nghiệp và những người liên quan CNTT là một công cụ cần thiết để thực hiện lợi ích lẫn nhau của SOA và BPM: càng phù hợp giữa nghiệp vụ và CNTT thì càng tái sử dụng tốt hơn.

Trong loạt bài này, học về mô hình hướng quy trình cho các giải pháp SOA. Bài này đi về một kỹ thuật phân rã quy trình cho phép bạn xác định các mô hình quy trình gần như phù hợp với kiến trúc đích dựa trên SOA, bởi thế các mô hình quy trình của bạn trung thực hơn đối với giải pháp được triển khai.


Tại sao chúng ta cần các mô hình quy trình phù hợp SOA

Thể hiện các lợi ích của mô hình hóa vẫn khó khăn vì hầu hết các kỹ thuật mô hình hóa quy trình dựa trên các khái niệm có trước SOA và BPM. Một cách truyền thống, các mô hình quy trình khác nhau được tạo ra trong một doanh nghiệp cho các mục đích khác nhau. Ví dụ, mô hình hóa quy trình có thể được dùng trong định nghĩa chiến lược, thay đổi tổ chức, yêu cầu các yêu cầu, tối ưu hóa thao tác, đặc tả tính năng, luồng giao diện người dùng, các chỉ thị công việc và các luồng tích hợp ứng dụng doanh nghiệp (EAI). Thậm chí nếu hai mô hình muốn biểu diễn cùng quy trình, chúng vẫn khác nhau.

Mô hình hóa quy trình có các vấn đề duy trì, khả năng lần vết và kiểm thử sau:

  • Khi một mô hình quy trình tiến hóa trong vòng đời của một dự án CNTT, nó thường bắt nguồn từ một mô hình mơ hồ được sinh ra cho một mục đích khác hơn là cho những thứ nó được dùng sau này trong vòng đời.
  • Để tránh vấn đề trên, một mô hình mới thỉnh thoảng được tạo ở mỗi giai đoạn của vòng đời, tạo ra sự cần thiết để lần vết tường minh các sản phẩm vốn đắt đỏ khi bảo trì.
  • Thông thường, những người hành nghề trong pha (mô hình hóa) ngược của một dự án SOA không hiểu được ảnh hưởng của công việc họ về sau.

Hậu quả là, các mô hình quá trình phát triển trong các pha trước không có một liên kết rõ ràng đến dự án thực sự được triển khai. Hoặc các mô hình này điều khiển giải pháp sai hướng.

Các mô hình quá trình dựa trên SOA có thể được tạo ra dùng các mô hình quá trình khác, ít chính xác hơn như là đầu vào. Một tiếp cận trực tiếp để xác định các giải pháp có nhiều lợi ích:

Tiện bàn giao
Cải thiện sự bàn giao của của các mô hình quá trình từ các nhà phân tích nghiệp vụ tới các nhà kiến trúc— và từ các nhà kiến trúc tới các nhà phân tích, phát triển và các đội kiểm thử.
Giảm tái tạo.
Giảm tái tạo các mô hình từ một giai đoạn vòng đời sang một giai đoạn khác.
Tăng cường khả năng lần vết
Có vết tốt hơn của các dự án dựa trên BPM và SOA
Đáp ứng các kỳ vọng của khách hàng
Tăng cường tỉ lệ đáp ứng kỳ vọng của khách hàng bằng cách trực quan hóa giải pháp, cải thiện tính trong sáng của giao tiếp và cải thiện sự phù hợp của thứ được yêu cầu với những gì được bàn giao.
Tăng tốc bàn giao dự án
Dùng các nguyên tắc chỉ dẫn và các mẫu làm đơn giản hóa và đem lại các thiết kế chính xác hơn.
Định nghĩa một ngôn ngữ và một khung làm việc (framework) chung.
Hỗ trợ trao đổi các mô hình quy trình giữa những người hành nghề.
Kiểm thử và xác minh hiệu quả hơn
Một liên kết tốt hơn giữa các yêu cầu và thứ được bàn giao mang lại hiệu quả kiểm thử và xác minh
Tăng cường khả năng tái sử dụng
Các dịch vụ được tái sử dụng dường như có một sản phẩm được xác định rõ ràng trong các giai đoạn vòng đời khác.

Kiến trúc liên quan tới IBM SOA

Kĩ thuật mô hình hóa quy trình được minh họa dùng kiến trúc tham chiếu IBM® SOA, là một bản thiết kế dùng cho nhiều sáng kiến SOA của các khách hàng IBM. (Tài nguyên có thêm chi tiết về kiến trúc tham chiếu IBM SOA.) Bài này tập trung vào ba lớp trong kiến trúc có liên quan nhất đến mô hình quy trình mẫu: lớp tiêu thụ, lớp quy trình nghiệp vụ và lớp dịch vụ.

Các dịch vụ hay các quy trình?

Việc đặt tên các lớp kiến trúc thỉnh thoảng có thể bị hiểu sai:

  • "Các quy trình nghiệp vụ - Business processes” có nghĩa là đây là chỗ các quy trình nghiệp vụ được thực thi. Trong thực tế, cũng có các ứng dụng tiêu thụ quy trình nghiệp vụ cụ thể trong lớp tiêu thụ, cũng có các quy trình nghiệp vụ thủ công không có triển khai hệ thống nào cả. Một cái tên chính xác tuy dài hơn có thể là "các quy trình nghiệp vụ phối hợp", bởi vì các quy trình này thường xuyên dùng một engine phối hợp là một phần của nền tảng BPM.
  • "Các dịch vụ - Services” có thể ám chỉ tới tất cả các dịch vụ thuộc lớp này. Nhưng các quy trình nghiệp vụ trong lớp quy trình nghiệp vụ thông thường cũng được phơi bày dưới dạng các dịch vụ. Ngay cả các tiến trình tiêu thụ cũng có thể được phơi bày dưới dạng các dịch vụ trong một giao diện nghiệp vụ tới nghiệp vụ (B2B).

Bài này có thể tham chiếu tới các quy trình nghiệp vụ không ở trong lớp quy trình nghiệp vụ hoặc các dịch vụ không ở trong lớp dịch vụ. Ở những chỗ thích đáng, tôi sẽ tham chiếu tường minh tới lớp.

Lớp tiêu thụ

Lớp tiếp thụ chứa các ứng dụng được dùng bởi những người dùng cuối bên trong một tổ chức hoặc các giao diện đến với các tổ chức bên ngoài (chẳng hạn các khách hàng hoặc đối tác). Các ứng dụng tiêu thụ chịu trách nhiệm về các hộp thoại hoặc các phiên với những người dùng. Lớp tiêu thụ thỉnh thoảng được gọi bởi lớp trình diễn.

Lớp quy trình nghiệp vụ

Các quy trình trong lớp quy trình nghiệp vụ được gọi (dùng các dịch vụ) bởi các ứng dụng trong lớp tiêu thụ. Chúng đạt tới các mục tiêu nghiệp vụ cụ thể và được cấu thành từ các nhiều activity (hành động). Các quy trình trong lớp quy trình nghiệp vụ thường xuyên được cài đặt như là các quy trình phối hợp thực thi trong một nền tảng BPM. Đối với kỹ thuật trong bài này, không cần phân biệt giữa các quy trình chạy dài các tiến trình chạy ngắn:

  • Các quy trình chạy dài, hay còn gọi là các quy trình luồng công việc, có ít nhất một bước có: một người thực hiện một activity (hành động), đợi một sự kiện bên ngoài xảy ra hoặc một xử lý dài ghê gớm. Một ứng dụng tiêu thụ không thể mong đợi một kết quả trung gian từ một quy trình dài.
  • Các quy trình chạy ngắn được cấu thành từ các dịch vụ tự động hoàn toàn và được hoàn thành (hầu như) tức thời. Một ứng dụng tiêu thụ có thể mong đợi một kết quả hầu như tức thời khi gọi một quy trình chạy ngắn.

Cũng có các lý do về kiến trúc khác rất tốt để đưa ra sự phân biệt này.

Lớp các dịch vụ

Lớp các dịch vụ cung cấp các khối xây dựng dưới dạng các dịch vụ cho các lớp quy trình nghiệp vụ và lớp tiêu thụ. Các lớp này, chúng được tự động, có thể biểu diễn các activity (hành động) trong một quy trình nghiệp vụ. Hình 1 nêu bật các lớp của kiến trúc tham chiếu SOA liên quan đến bài này.

Hình 1. Kiến trúc tham chiếu IBM SOA
Kiến trúc tham chiếu IBM SOA

Kỹ thuật được mô tả sau đây trong bài này yêu cầu các mô hình xử lý được phân lớp phù hợp với các lớp đó. Trước khi đi vào chi tiết hơn, phần tiếp theo thảo luận về các acitivty (hành động) con người mà là thành phần của các quy trình chạy dài (workflow).


Các activity (hành động) con người trong các quy trình chạy dài

Một bước trong một quy trình chạy dài có thể đáp ứng tới một activity con người (một thành phần luồng công việc thủ công). Thông thường, các tác vụ như vậy được thực thi bởi một nhân viên của doanh nghiệp thực thi một vai trò cụ thể trong quy trình. Các nền tảng BPM có thể cung cấp cách gửi activity này tới một danh sách các tác vụ và biểu diễn một giao diện người dùng (UI) cho những người dùng lựa chọn các tác vụ từ danh sách. Danh sách tác vụ tự nó không là một tính năng trong các mô hình quy trình; nó là một cách trừu tượng hóa.

Nguyên tắc phân lớp

Một tính năng then chốt của SOA là kiến trúc được phân lớp tuân theo nguyên tắc phân lớp. Nó được phân rã thành nhiều lớp, ở đó mỗi lớp phục vụ lớp bên trên nó, cung cấp một tập các dịch vụ mà không cần biết là chúng được triển khai thế nào. Ngược lại, các lớp lại phụ thuộc vào các dịch vụ được cung cấp bởi các lớp phía dưới. Phân lớp có sức mạnh vô cùng trong việc giải quyết tính phức tạp. Các hệ thống được phân lớp thì dễ dàng để hiểu hơn, chúng trừu tượng hóa (che dấu) các chi tiết triển khai của các chức năng bên dưới đối với các lớp quan tâm.

Hầu hết các nền tảng tính toán phức tạp, tồn tại lâu dài và thành công đều có sự phân lớp. Ví dụ nổi tiếng nhất của phân lớp là bộ Giao thức Internet (Internet Protocol stack).

Vi phạm nguyên tắc phân lớp
Khi một lớp gọi một lớp ở trên, nguyên tắc phân lớp bị phá vỡ. Điều này cần phải tránh vì nhiều lí do. Ví dụ, nó sẽ làm cho thiết kế ít khả năng lần vết hơn, có thể gây ra sự đệ quy không chủ định và dẫn đến mất các lợi ích của việc phân lớp.

Khi bạn quyết định làm thế nào biểu diễn các tác vụ con người trong các mô hình xử lý, xuất hiện ba tùy chọn có thể sau:

  • Tùy chọn 1: Từ quan điểm của một người mô hình hóa quy trình, các activity con người là các bước trong một quy trình nghiệp vụ tương tự với các acitivity được tự động trong lớp các dịch vụ. Vì vậy chúng nên được mô hình hóa như thế và được coi một cách lô gic nằm cùng lớp với các acitivty được tự động.
  • Tùy chọn 2: Từ quan điểm của một kỹ thuật viên, các activity con người yêu cầu một giao diện lệ thuộc vào các cơ chế điều khiển truy cập và các khả năng khác như là các ứng dụng tiêu thụ khác. Các activity con người cũng có thể dùng các dịch vụ được cung cấp bởi các lớp ở dưới. Cài đặt này có thể là một phần của lớp tiêu thụ.
  • Tùy chọn 3: Các activity con người tự nó là một phần của lớp lớp quy trình nghiệp vụ, như là chúng được cung cấp và dàn xếp bởi một giải pháp BPM.

Các quan điểm đó không phù hợp với nhau, và hai tùy chọn đầu tiên làm phá vỡ nguyên tắc phân lớp (xem thanh trượt), mỗi thứ có các cách khác nhau:

  • Các activity con người có thể cần gọi các quy trình nghiệp vụ chạy thời gian ngắn, thứ có thể nằm trong một lớp cao hơn nếu các activity người dùng được coi là thành phần của lớp các dịch vụ.
  • Các nhà mô hình hóa quy trình nghiệp vụ có thể nghĩ tới các activity quy trình con người được gọi bởi các quy trình nghiệp vụ. (Invoked được dùng trong nghiệp vụ hơn là nghĩa kỹ thuật, như là cơ chế gọi hiệu quả cấp phát tác vụ tới dòng đợi tác vụ người dùng.) Nếu các activity quy trình người dùng là một phần của lớp tiêu thụ, từ quan điểm của một nhà mô hình hóa quy trình, điều này có thể hiệu quả có nghĩa là lớp quy trình nghiệp vụ gọi lớp trên.

Giải pháp là sự làm mịn hóa của tùy chọn thứ ba, nơi mà các activity con người được đặt trong lớp quy trình nghiệp vụ, giữa các quy trình chạy dài và chạy ngắn. Làm như vậy, bạn có thể đảm bảo rằng các activity con người không gọi lớp các quy trình chạy dài.


Phân rã quy trình phù hợp SOA

Đối với các dự án SOA cùng với một thành phần BPM, bạn nên trung thành với cấu trúc phân rã quy trình được chỉ ra ở hình 2. (Khung làm việc này điều khiển nhân tố cơ bản phía sau các mẫu trong phần 2 của loạt bài này.)

Hình 2. Khung làm việc phân rã quy trình
Khung làm việc phân rã quy trình

Các mô hình quy trình phát triển để đặc tả các chức năng của giải pháp dựa trên SOA nên tuân theo cấu trúc phân rã ở Hình 2. Mỗi quy trình đơn lẻ thuộc về một trong các lớp.

Một kênh dịch vụ doanh nghiệp (ESB) có thể đưa các giao diện dịch vụ tới các lớp khác nhau (quy trình chạy dài, quy trình chạy ngắn, activity con người, activity tự động), nhưng những thứ đó không được đối xử như nhau. Cấu trúc logic của khung làm việc áp đặt các luật cái gì nên được gọi cái gì, vì thế cá mô hình và thiết kế dễ dàng được lần vết và hiểu.

Các quy trình có thể chỉ gọi hoặc bắt sự kiện từ các quy trình trong các lớp bên dưới, như được chỉ ra bởi các mũi tên. Chúng không nên biết tới bởi các lớp bên trên. Mỗi lớp được thảo luận tiếp sau đây.

Các quy trình thủ công (manual processes) và các quy trình kinh nghiệm khách hàng (customer experience processes)

Lớp các quy trình thủ công và các quy trình kinh nghiệm khách hàng thiết lập ngữ cảnh cho các quy trình ở các lớp bên dưới. Các quy trình trong lớp này không có lớp liên quan trong kiến trúc tham chiếu SOA; tuy nhiên, chúng giúp giải thích điều gì dẫn đến việc khởi chạy một quy trình tiêu thụ.

Các quy trình tiêu thụ (consumer processes)

Các mô hình quy trình tiêu thụ cụ thể xác định quy trình của các ứng dụng người dùng cuối. Chúng biểu thị một ứng dụng tương tác với các quy trình bên dưới như thế nào. Ứng dụng lớp tiêu thụ giữ trạng thái phiên làm việc được yêu cầu bảo trì các hộp thoại với người dùng. Các người dùng có thể là người dùng bên ngoài (khách hàng), người dùng bên trong (nhân viên) hoặc người dùng hệ thống (các công việc lập lịch lô hoặc các giao diện B2B). Mục đích chính của lớp tiêu thụ là thu thập tất cả các thông tin được yêu cầu để bắt đầu một quy trình nghiệp vụ hoặc một giao tác.

Bất kỳ một lô gic mà định nghĩa bên trong các quy trình tiêu thụ phải cụ thể với ứng dụng (hoặc kênh). Vì thế, nó nên vẫn tách rời khỏi lớp quy trình nghiệp vụ.

Các quy trình tiêu thụ cụ thể gọi các quy trình chạy dài trong chế độ khởi chạy và quên đi (fire-and-forget hay request-acknowledgment). Chúng không đợi phản hồi nhưng chúng cũng có thể gọi các quy trình chạy ngắn dùng một tương tác gọi - phản hồi. Các ứng dụng (đối tượng) tiêu thụ cần biết khi nào quy trình nghiệp vụ được gọi bởi quy trình ngắn hoặc dài, như là chúng có thể chỉ mong đợi một kết quả sắp xảy ra từ sau đây.

Business Process Modeling Notation (BPMN) nhanh chóng trở thành chuẩn ký hiệu từ lúc nào không rõ cho các mô hình quy trình. Tuy nhiên, các sản phẩm được dùng để biểu diễn các quy trình tiêu thụ cụ thể không cần thiết phải là các mô hình BPMN. (Thật là khó để bao gồm biểu diễn trực quan của các giao diện người dùng (UI) trong các biểu đồ BPMN.) Các sản phẩm khác có thể là các ca sử dụng, các luồng màn hình, các khung dây (wireframe) hoặc bản mẫu giao diện người dùng. Trong một trường hợp như thế, một đặc tả phải làm cho nó rõ nơi nào các quy trình nghiệp vụ cơ bản (chạy ngắn hoặc dài) và các dịch vụ được gọi, và các kết quả được xử lý ra sao.

Các quy trình chạy dài

Các quy trình chạy dài (hay các quy trình luồng công việc) được gọi bởi các quy trình tiêu thụ, hoặc như một kết quả của các sự kiện sinh ra bởi các quy trình chạy ngắn (xem SOA dựa trên sự kiện). Chúng được dự định tái sử dụng thông qua hai loại quy trình.

Từ quan điểm của quy trình tiêu thụ các quy trình chạy dài thì chúng "không mang tính hội thoại", và chúng có thể gọi các quy trình chạy ngắn hoặc các activity quy trình tự động. Chúng cũng có thể gọi các tác vụ con người bằng cách gửi một tác vụ tới danh sách hoặc hàng đợi công việc của "công nhân" (worker)

Các activity con người

Từ quan điểm của mô hình hóa quy trình, và trong khuôn khổ ngữ cảnh này, các activity con người được gọi bởi các quy trình chạy dài. Sự thực thi của chúng thông thường bắt đầu khi người mà đã được gán activity chọn nó từ một danh sách công việc. Các activity con người có thể tự nó được biểu diễn như là các quy trình, như là nó có thể lấy một số lượng lớn các bước (màn hình) để hoàn thiện chúng. Các activity con người có thể gọi các quy trình chạy ngắn và các activity tự động.

Một cách kỹ thuật, các activity con người được bắt đầu khi một công nhân (một số nơi gọi là công nhân nghiệp vụ) đăng nhập vào một ứng dụng công việc và chọn một tác vụ (hoặc tìm thể hiện quy trình). Tuy nhiên, trong khung làm việc này ứng dụng công việc được coi là một loại cơ chế gọi. Từ quan điểm của mô hình hóa quy trình, các activity con người được gọi bởi các quy trình chạy dài mà chúng là thành phần. Sự trừu tượng hóa này thậm chí trở nên hợp lệ hơn như là các mô hình BPM hiện đại cung cấp khía cạnh giao diện người dùng của các tác vụ con người, bao gồm danh sách công việc hoặc giao diện người dùng hàng đợi. Một danh sách công việc vì thế có thể được coi là một thực thể trừu tượng không yêu cầu mô hình hóa.

Các quy trình chạy ngắn

Các quy trình chạy ngắn được gọi bởi các quy trình tiêu thụ, các quy trình chạy dài, hoặc các tác vụ con người. Chúng luôn phải mang tính "không mang tính hội thoại" và thông thường là các activitie quy trình tự động phối hợp. Các quy trình chạy ngắn có khả năng thông báo tới thực thể gọi hoàn thành (có thể bao gồm cả dữ liệu kết quả) trong thời gian thực.

Các activity tự động

Các activity tự động là các bước nguyên tử trong các quy trình nghiệp vụ. Chúng có thể miêu tả các phê chuẩn (validation), tạo/đọc/sửa/xóa các thao tác dữ liệu, các luật nghiệp vụ và gọi các hệ thống bên ngoài.

Các activity tự động tương ứng với lớp các dịch vụ trong kiến trúc tham chiếu SOA. Trong suốt pha mô hình hóa quy trình, các activity có thể coi một cách tổng quát như là các ứng viên thao tác dịch vụ.


Bộ điều khiển quy trình

Cách tiếp cận trong bài này sát nhập ký pháp mà chỉ nên có một thực thể — bộ điều khiển quá trình — điều khiển một quá trình được đưa ra.

Một luồng quá trình nghiệp vụ luôn được điều khiển bởi cái gì đó. Mỗi quá trình, hoặc quá trình con chỉ nên có một bộ điều khiển quá trình. Nếu bạn không thể xác định được hoặc nếu một quá trình được mô hình hóa mới hơn nhảy từ một bộ điều khiển tới cái tiếp theo, sẽ có sự sai sót nào đó trong việc phân rã. Có vẻ như bạn xác định một quá trình con khác.

Ví dụ về các bộ điều khiển quá trình được thể hiện trong bàng sau.

Bộ điểu khiển quá trìnhMô tả
Một con ngườiMột người quản lý luồng quá trình.
Một mẩu giấyMẩu giấy mà đi theo một quá trình có thông tin trên đó nó xác định cái gì cần phải làm tiếp theo (có thể kết hợp với các chỉ thị công việc).
Các chỉ thịCó một tập rời rạc các chỉ thị, hoặc được viết tường mình hoặc nằm trong đầu, chỉ thị quá trình.
Luồng màn hìnhMột người đang nhập thông tin vào màn hình và được chỉ dẫn sang màn hình tiếp bởi cơ chế luồng màn hình ở dưới.
Các quá trình chạy ngắn được hệ thống phối hợpMột hệ thống phối hợp một loạt các activity tự động hoàn toàn.
Các quá trình chạy dài được hệ thống phối hợpMột hệ thống BPM phối hợp một loạt các activity. Các tác vụ con người được gửi thông qua một danh sách các công việc, các thao tác hệ thống, chẳng hạn như các lời gọi dịch vụ, được thực thi tự động.

Trong khung làm việc phân rã quy trình, mỗi bộ điều khiển thuộc vào một trong các lớp. Ba ví dụ đầu tiên trong bảng trên tương ứng với lớp các quy trình thủ công và các quy trình kinh nghiệm khách hàng. Luồng màn hình có thể được dùng ở trong lớp tiêu thụ và lớp activity con người. Đối với hai ví dụ khác, hy vọng là lớp tương ứng rõ ràng.

Khái niệm bộ điều khiển quy trình bắt buộc nhà mô hình quá quy trình chấp nhận cơ chế trong đó luồng trong một quy trình bị điều khiển. Nó cũng sẽ:

  • Tránh các câu hỏi khó về sau từ các đội CNTT những người cần triển khai các khía cạnh của những quy trình này.
  • Thuận tiện hóa bước chuyển tới kiến trúc dựa trên SOA, như là mỗi lớp trong kiến trúc đáp lại một bộ điều khiển quy trình khác nhau.

Trong một bộ điều khiển (là một ký pháp trừu tượng), nó có thể được biểu diễn một cách đồ họa như ở hình 3.

Hình 3. Một quá trình và biểu diễn của nó với một bộ điển khiển quá trình tường minh
Một quá trình và biểu diễn của nó với một bộ điển khiển quá trình tường minh

Mỗi khi một activity trong quá trình hoàn thành, điều khiển được thực hiện bởi bộ điều khiển quá trình. Vai trò này có một biểu diễn nội bộ của luồng quá trình và xác định bước tiếp theo dựa trên sự biễu diễn. Ký pháp ở trên thực tế không bao giờ được dùng, vì nó sinh ra một mô hình quá trình không đọc được.


SOA dựa trên sự kiện

Một vài bối cảnh bao gồm một quy trình chạy dài cần phải được gọi bởi quá trình chạy ngắn mà có thể gây ra vi phạm cơ chế phân lớp ở trên. Điều này thường xảy ra khi quá trình chạy dài biểu diễn sự thi hành của một giao tác được biểu diễn bởi một quá trình chạy ngắn. Ví dụ, để quản lý bối cảnh, thao tác Đặt Chỗ (Place Order) (chạy ngắn) cần phải có kết quả liên quan đến các quá trình Hoàn thành đặt (Fullfill Order) và Bổ sung kho (Replenish Stock), cả hai đều là quá trình chạy dài.

Mục đích chính của nguyên tắc phân lớp là để cho các lớp thấp hơn không biết về các lớp cao hơn chúng đang phục vụ. Thông thường thì có nghĩa là một lớp cao hơn có thể gọi một lớp thấp hơn, nhưng không có chiều ngược lại. Nó cũng có nghĩa là lớp cao hơn lắng nghe và thực hiện dựa trên các sự kiện gửi từ lớp thấp hơn.

Ví dụ, quá trình chạy ngắn Đặt chỗ (Place Order) có thể sinh ra sự kiện Đơn Hàng Mới Phát Sinh (New Order Arrived). Một bộ lắng nghe sự kiện trong lớp các quá trình chạy dài có thể nhận sự kiện này và khởi chạy các quá trình Hoàn thành đặt (Fullfill Order) và Bổ sung kho (Replenish Stock)— mà quá trình Đặt chỗ (Place Order) không cần biết về sự tồn tại của các quá trình đó.


Các mô hình quá trình nghiệp vụ được thiết kế dùng các kỹ thuật phân rã và các mẫu rất phù hợp để xác định và đặc tả các ca sử dụng (và các liên kết "include" và "extend" giữa chúng) và các dịch vụ. Hãy tiếp tục đi theo loạt bài này để đi xa hơn về chủ đề này.


Kết luận

Không giống như hầu hết các kỹ thuật mô hình hóa quá trình đã chính thức hóa, kỹ thuật trong bài này không dùng hệ thống cấp bậc các quá trình. "Cấp bậc" ngầm chỉ một cấu trúc cây, ở đó mỗi quá trình thuộc về một quá trình mức cao hơn (trừ các quá trình ở mức cao nhất). Trong một hệ thống cấp bậc như thế, các quá trình con có xu hướng bị nhúng trái với độc lập, điều này bất lợi cho việc tái sử dụng.

Nghĩ tới "ngăn xếp" thay vì cấp bậc.

Kỹ thuật mô tả ở trong bài này dùng khái niệm ngăn xếp quy trình, ở đó lớp cao hơn phụ thuộc vào các dịch vụ được cung cấp bởi một lớp thấp hơn. Các dịch vụ có thể có các cài đặt quy trình nằm phía dưới. Các dịch vụ này và các thể hiện của chúng dạng các quy trình mang tính độc lập và vì thế được dùng ở các quy trình ở các lớp cao hơn khác nhau.

Tương tự, ký pháp "mức độ chi tiết" thường được dùng để xác định các quá trình con. Thay vào đó, kỹ thuật trong bài này quan tâm tới các lớp trách nhiệm. Một lớp cao hơn của trách nhiệm không cần thiết được quan tâm mức độ cao hơn của chi tiết. Ví dụ, bạn có thể tranh luận về mức độ chi tiết trong một quá trình tiêu thụ tương tự như quá trình chạy dài hoặc chạy ngắn. Tuy nhiên, các quá trình trong các lớp đó có các dạng khác nhau của trách nhiệm, nó luôn gọi lớp khác và không có lớp khác bao quanh.

Hãy để việc xác định dịch vụ mang tính hướng tiêu thụ

Với kỹ thuật phân rã quy trình, các mô hình của quy trình xác định các dịch vụ ứng viên bạn cần trong lớp quy trình nghiệp vụ, và các mô hình của các quy trình chạy dài hay chạy ngắn xác định các dịch vụ ứng viên bạn cần trong lớp các dịch vụ. Vì thế các dịch vụ được xác định thông qua việc chúng cần ở đâu và chúng được dùng chỗ nào. Một bài báo tương lai trong loạt bài này sẽ đi về xác định các dịch vụ và đặc tả chi tiết hơn.

Dùng phép phân tích các hệ thống đã có sẵn

Phép phân tích hệ thống đã có sẵn nên cung cấp cái nhìn từ dưới lên (bottom-up). Ở chỗ có thể, các mô hình quy trình phải phù hợp với phép phân tích bằng cách lựa chọn các bước activity tự động trong các quy trình tương ứng với các dịch vụ nó có thể được cung cấp bởi các ứng dụng có sẵn của tổ chức.


Lời cảm ơn

Các ý tưởng không tự mình tôi nghĩ ra. Tôi gửi lời cảm ơn tới các bạn đồng sự IBM đã thảo luận với tôi. Đặc biệt tôi xin cảm ơn Mano Cheema, Sunny Shah, Mike Evans, Bruce Anderson, Joe Hardman, Simon Plackett, Kim Clark, Richard Solly, Pete Cripps, Ian Turton, Tony Carthy, Ali Arsanjani và Doug McDavid vì những đóng góp của họ.

Tài nguyên

Học tập

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

Thảo luận

  • Tham gia vào diễn đàn kiến trúc CNTT để trao đổi các thủ thuật và kỹ thuật và để chia sẻ các thông tin liên quan về chủ đề rộng lớn của kiến trúc CNTT.

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=SOA và dịch vụ Web
ArticleID=407134
ArticleTitle=Mô hình hóa hướng quy trình cho SOA, Phần 1: Một kỹ thuật phân rã quy trình
publish-date=07102009