Một mục tiêu quan trọng của WFMC là định nghĩa các chuẩn cho phép các hệ
quản lý workflow của các nhà cung cấp khác nhau có thể trao đổi các mục công việc một cách trơn chu với nhau.
Các sản phẩm workflow rất đa dạng, từ những hệ quản lý workflow được sử
dụng cho việc định tuyến không dự tính trước của các công việc hoặc dữ liệu, cho đến các hệ quản lý workflow được sử dụng cho các tiến trình sản xuất đòi hỏi tuân thủ
nguyên tắc chặt chẽ. Với nỗ lực chuẩn hóa khả năng phối hợp hoạt động, WFMC xác
định không bắt buộc các nhà cung cấp sản phẩm workflow phải chọn lựa giữa việc cung cấp một sản phẩm mạnh tập trung vào nhu cầu của khách hàng và việc từ bỏ sức mạnh của các hệ quản lý workflow này đểđổi lấy khả năng phối hợp hoạt động.
Công việc của WFMC do đó tập trung vào việc phát triển một số tình huống phối hợp hoạt động ở một số mức độ, từ việc đơn gian như trao đổi công việc cho đến phức tạp như phối hợp hoạt động ứng dụng workflow với việc hoàn thiện trao đổi định nghĩa tiến trình, dữ liệu liên quan workflow và các giao diện cảm quan (look and feel) chung. Với nhiệm vụ này, ban đầu các tình huống phối hợp hoạt động đơn giản sẽ
được hỗ trợ, các tình huống phức tạp hơn đòi hỏi các công việc kế tiếp trong các định nghĩa phối hợp hoạt động.
Mặc dù có thể coi việc phát triển của các tình huống phối hợp hoạt động rất phức tạp trong đó một số engine của các nhà cung cấp khác nhau phối hợp để thực hiện một dịch vụ enactment riêng, tình huống này không có khả năng thực hiện trong tương lai gần, vì nó đòi hỏi tất cả các engine đều có thể thông dịch một định nghĩa tiến trình chung và chia sẻ một tập chung các dữ liệu điều khiển workflow, kết quả là việc bảo trì một khung nhìn chia sẻ của các trạng thái xử lý giữa các engine điều khiển workflow không đồng nhất. Một mục tiêu hiện thực hơn trong tương lai gần là khả
năng trao đổi các phần của một tiến trình để hỗ trợ trong thời gian thực thi của một dịch vụ enactment khác.
Bốn mô hình phối hợp hoạt động có thể xảy ra trong thực tế đã được xác định, bao gồm các mức độ (đang tăng lên) của khả năng phối hợp hoạt động.
Phần sau giới thiệu các mô hình phối hợp tiềm năng; các minh họa sử dụng các ô vuông để ám chỉ các công việc (task) và hành động (activity), được đánh bóng khác nhau để biểu thị các công việc được phối hợp bởi các dịch vụ workflow enactment riêng lẻ.
a.Tình huống 1 – Kết nối các thành phần rời rạc (Liên kết móc xích)
Mô hình này cho phép một điểm kết nối trong tiến trình A kết nối tới một điểm trong tiến trình B. Mặc dù minh họa cho thấy các điểm kết nối ở các điểm cuối và
điểm đầu của các tiến trình, nó chỉđược sử dụng cho mục đích minh họa. Các điểm kết nối có thểở bất kỳ đâu trong các tiến trình nhằm hỗ trợ cho tiến trình chung được tạo bởi kết nối của 2 tiến trình.
Hình 2-5 Mô hình các dịch vụ được liên kết móc xích
Mô hình này hỗ trợ việc trao đổi một mục công việc (một bản sao tiến trình hoặc hành động) giữa hai môi trường workflow, sau đó mục công việc này tiếp tục hoạt
nghĩa cài đặt, nó có thể được thực hiện thông qua chức năng ứng dụng giao tiếp (gateway application function), xử lý chuyển đổi định dạng dữ liệu, kết gắn (map) tên tiến trình và hành động, v..v.. hoặc có thể được gộp vào một trong số các dịch vụ
workflow, ví dụ như khi một lời gọi API chuẩn được sử dụng giữa hai dịch vụ.
b.Tình huống 2 – Phân cấp (có các tiến trình con bên trong)
Tình huống này cho phép một tiến trình được thực thi trong một workflow domain cụ thể có thể được gói gọn (encapsulated) như một công việc trong một tiến trình (cấp cao hơn) được thực thi trong một workflow domain khác. Mối quan hệ phân cấp tồn tại giữa tiến trình cấp cao hơn và tiến trình được gói gọn, kết quả là hình thành tiến trình con của tiến trình cấp cao hơn. Mối quan hệ phân cấp có thể được tiếp tục qua một vài cấp độ, tạo nên một tập các tiến trình con lồng nhau. Sự hồi quy ở trong tình huống này có thể hoặc không được cho phép trong các sản phẩm WFM.
Hình 2-6 Mô hình tiến trình con lồng nhau
Trong lược đồ trên, dịch vụ workflow A có một hành động được định nghĩa (A3)
được thực thi như một tiến trình đầy đủ (B) trong dịch vụ workflow B và điều khiển
được trả về cho dịch vụ A khi quá trình thực thi hoàn thành. Như trong tình huống 1 ở
trên đây, việc trao đổi điều khiển hành động có thể thông qua chức năng giao tiếp các
ứng dụng hoặc bằng các lời gọi hàm API trực tiếp giữa hai dịch vụ workflow. Lược đồ
minh họa trường hợp đơn giản với một điểm vào và một điểm thoát ra trong tiến trình B, mặc dù các luật điều hướng hành động trong B có thể cho phép các tình huống luồng hành động khác, ví dụ như các điều kiện hoàn thành tiến trình cho phép tiến trình được hoàn thành sau hành động B5 và điều khiển trả về cho workflow domain A.
c.Tình huống 3 – Kết nối các thành phần không rời rạc (Ngang hàng)
Mô hình này cho phép một môi trường pha trộn hoàn toàn; lược đồ chỉ ra một tiến trình tổ hợp C, bao gồm các hành động có thể được thực thi bởi nhiều dịch vụ
workflow, tạo ra một domain được chia sẻ. Các hành động C1, C2 và C5 có thểđược phối hợp thực thiện bởi máy chủ A (hoặc thậm chí một vài máy chủ không đồng nhất (adsbygoogle = window.adsbygoogle || []).push({});
trong một domain chung) và các hành động C3, C4 và C6 được phối hợp thực hiện bởi máy chủ B.
Trong tình huống này, tiến trình sẽ tiến hành trong suốt qua từng công việc, mà không có bất kỳ hành động cụ thể nào của người dùng hoặc người quản trị, cùng với các tưong tác giữa các engine workflow riêng lẻđược thực hiện nếu cần thiết.
Hình 2-7 Mô hình ngang hàng
Tình huống này đòi hỏi cả hai dịch vụ workflow cùng hỗ trợ một tập lệnh API chung để truyền thông và để thông dịch một định nghĩa tiến trình chung, hoặc được nhập vào cả hai môi trường từ một tiến trình xây dựng chung hoặc được kết xuất giữa các dịch vụ trong giai đoạn thực thi. Dữ liệu liên quan workflow và dữ liệu ứng dụng workflow có thể cần được trao đổi giữa các engine không thuần nhất.
Trong khi đơn giản được minh họa như một tình huống phối hợp công việc, các vấn đề phức tạp khác trong mô hình peer-to-peer sẽ đòi hỏi phải nghiên cứu sâu hơn. Nhưđã chỉ ra, mỗi hành động cụ thểđược liên kết với một workflow domain cụ thể, ví dụ nhưđã được xác định trước trong định nghĩa tiến trình. Những vấn đề phức tạp hơn xuất hiện khi một hành động cụ thể có thể được thực thi hoặc ở trong hai dịch vụ
workflow hoặc là một bản sao tiến trình đặc biệt có thể được tạo ra hoặc kết thúc độc lập với các dịch vụ. Ở mức độ cao nhất, hai dịch vụ workflow enactment khác nhau có thể yêu cầu chia sẻ nhiều dữ liệu trạng thái tiến trình mà bình thường được quản lý ở
bên trong mỗi dịch vụ, kết quả là tạo ra một dịch vụ không đồng nhất. WFMC dựđịnh sẽđịnh nghĩa một số mức độ tương thích, cho phép các đặc tả cũ hơn có thể hoạt động với các tình huống đơn giản hơn và các hàm chức năng bổ sung có thể hoạt động với các tình huống phức tạp hơn được thêm vào trong tương lai.
d.Tình huống 4 – Đồng bộ hóa song song
Mô hình này cho phép hai tiến trình hoạt động về cơ bản là độc lập với nhau, có thể thông qua các dịch vụ enactment riêng rẽ, nhưng yêu cầu các điểm đồng bộ hóa tồn tại giữa hai tiến trình. Việc đồng bộ hóa đòi hỏi một khi mỗi tiến trình tiến đến một
điểm xác đinh trước trong chuỗi thực thi tương ứng của chúng, một sự kiện chung
được tạo ra. Kiểu cơ chế này có thểđược sử dụng để làm thuận tiện hơn cho các chức năng như là xử lý đồng bộ thông qua các luồng thực thi song song, tạo điểm kiểm tra của việc phục hồi dữ liệu hoặc trao đổi dữ liệu liên quan workflow giữa các bản sao tiến trình khácc nhau.
Trong mô hình dưới đây, việc đồng bộ hóa được thực hiện giữa hành động A3 trong tiến trình A và hành động B4 trong tiến trình B.
Hình 2-8 Mô hình đồng bộ hóa song song
Các cặp công việc tương xứng có thểđược đồng bộ hóa tại các thời điểm đặc biệt trong mỗi tiến trình. Điều này yêu cầu một cơ chế phối hợp và theo dõi sự kiện, bổ
sung vào các dịch vụ workflow để có thể nhận ra các công việc từ hai định nghĩa tiến trình. Cơ chế này chưa hoàn thiện, nhưng được xác định nằm trong phạm vi của hoạt
động đặc tả hiện thời của WFMC.
e.Các chức năng phối hợp công việc WAPI
Mô hình diễn tả các luồng thông tin và điều khiển giữa các hệ thống workflow không đồng nhất được chỉ ra trong hình sau.
Hình 2-9 Giao diện phối hợp công việc workflow
Có 2 phần chính cần thiết cho khả năng tương tác giữa các hệ quản lý workflow: • Sự mở rộng tới các phần thông dịch chung của định nghĩa tiến trình (hoặc một
tập con) là cần thiết và có thểđược lưu trữ
• Hỗ trợ tại thời gian chạy cho sự trao đổi các kiểu thông tin điều khiển khác nhau và để trao đổi các dữ liệu liên quan và/hoặc ứng dụng của workflow giữa các dịch vụ enactment khác nhau.
e.1.Sử dụng các định nghĩa tiến trình trao đổi qua nhiều domain
Khi hai dịch vụ enactment có thể phiên dịch được một định nghĩa tiến trình chung (có thểđược sinh ra từ một công cụ xây dựng định nghĩa tiến trình chung), hai môi trường thực thi workflow có thể chia sẻ một khung nhìn chung về các thông tin về
các đối tượng định nghĩa tiến trình và thuộc tính của chúng. Đối tượng có thể bao gồm hành động, ứng dụng, các tên của vai trò và tổ chức, các điều kiện duyệt, v..v.. Việc này cho phép mỗi workflow engine có thể trao đổi việc thực thi của các hành động hoặc các tiến trình con tới các workflow engine bên ngoài hệ thống workflow enactment chứa nó, trong ngữ cảnh của việc đặt tên chung và mô hình đối tượng. Hướng tiếp cận này đặc biệt thích hợp cho tình huống tương tác thứ 3, khi có vài hệ
thống tương tác ở mức peer, mặc dù cũng có thể được tận dụng để áp dụng cho các tình huống đơn giản hơn.
Khi việc trao đổi định nghĩa tiến trình theo các hướng tiếp cận như trên đều là bất khả thi, khả năng tương tác bị ràng buộc vào hướng tiếp cận giao diện, theo đó các tên và thuộc tính của đối tượng được liên kết giữa hai môi trường thực thi workflow thông qua một giao diện làm việc phối hợp ứng dụng. Trong trường hợp đơn giản nhất, hai dịch vụ enactment riêng lẻ sử dụng các định dạng định nghĩa tiến trình của chúng với các liên kết giữa cả hai môi trường thông qua giao diện. Cách tiếp cận này thiết lập sự
phối hợp hoạt động một cách hiệu quả cho các tình huống 1 và 2, hoặc một số trường hợp thông thường có liên quan của tình huống 4.
e.2.Các tương tác điều khiển ở thời gian thực thi
Tại thời điểm thực thi, các lời gọi hàm WAPI được sử dụng để chuyển điều khiển giữa các dịch vụ workflow để thực hành các tiến trình con hoặc các hành động riêng lẻ (adsbygoogle = window.adsbygoogle || []).push({});
trên một dịch vụ workflow cụ thể. Khi cả hai dịch vụ workflow hỗ trợ cùng một cấp độ
của các lời gọi hàm WAPI và khung nhìn chung của các đối tượng định nghĩa tiến trình (bao gồm các quy ước đặt tên và bất kỳ dữ liệu liên quan của workflow hoặc dữ
liệu ứng dụng của workflow), việc này sẽ được thực hiện trực tiếp bởi các workflow engine của hai dịch vụ này, mặc dù việc này sẽ yêu cầu việc chấp thuận một giao thức chung hỗ trợ cho các nguyên thủy WAPI (WAPI primitives).
Hình 2-10 Hoạt động giao tiếp sử dụng WAPI
Lược đồ trên minh họa các nguyên lý chính của việc thực thi qua giao diện; phụ
thuộc vào tình huống phối hợp hành động cụ thể, một hành động đơn lẻ từ một domain (A) có thểđược liên kết tới một hành động đơn hoặc một tiến trình/tiến trình con mới trong domain thứ hai (B).
Một số lượng lớn các lệnh WAPI thường được khai thác để hỗ trợ khả năng tương tác phối hợp theo cách gọi hàm thực thi trực tiếp giữa hai dịch vụ workflow hoặc thông qua các hàm giao diện. Nhiều lệnh WAPI cũng có thể áp dụng trong các tương tác phối hợp workflow như:
• Thiết lập phiên làm việc
• Các thao tác lên các định nghĩa workflow và các đối tượng của chúng • Các chức năng điều khiển và trạng thái của tiến trình
• Các chức năng quản lý hành động • Các thao tác xử lý dữ liệu
Một cấp độ quản lý chung giữa nhiều workflow domain cũng sẽ là cần thiết, trong đó có sử dụng các chức năng được phát triển trong giao diện 5.
Một khi các hành động đang được thực thi trên một dịch vụ workflow (cấp con) riêng, các tương tác từ các ứng dụng workflow phía khách với dịch vụ ban đầu (ví dụ
như truy vấn trạng thái của một bản sao hành động/tiến trình, hoặc bản sao tiến trình tạm dừng/tiếp tục/hủy bỏ) có thể cần một sự tham chiếu tới dịch vụ cấp con. Khi đó một vài hoạt động có thể cần được liên kết móc xích với nhau qua một vài workflow engine (ví dụ như khi các hành động khác nhau trong một bản sao tiến trình đang thực thi được phân tán qua một vài bộ máy). Một sốđịnh dạng của dịch vụ cảnh báo sự kiện cũng được yêu cầu để thông tin về dịch vụ đang khởi tạo của các thay đổi trạng thái của hành động và việc hoàn thành thực thi của các hành động hoặc/và các tiến trình con. Dự kiến một số hành động WAPI bổ sung sẽ được phát triển theo thời gian, để hỗ
trợ các WAPI hiện có và các chức năng khác nảy sinh từ các tình huống phối hợp phức tạp hơn.
Phạm vi của các tương tác có thể xảy ra là tương đối rộng và phức tạp về mặt chuyển đổi trạng thái (ví dụ như các thành phần giúp ngăn chặn thất bại thực thi và phục hồi); nghiên cứu sâu hơn được yêu cầu để phát triển các mức độ tương thích cần thiết để có thể hình thành một cơ sở thực tiễn cho sự phối hợp tương tác giữa các sản phẩm khác nhau.