2.4.1. Các ứng dụng workflow phía khách
Bộ quản lý danh sách công việc- worklist handler là một thực thể phần mềm. Thực thể này tương tác với người dùng cuối khi có các hành vi đòi hỏi sự tham gia của nguồn tài nguyên con người. Bộ quản lý danh sách công việc có thể được cung cấp như một phần của sản phẩm quản lý Workflow hay có thể được viết bởi người dùng. Trong một số trường hợp khác, Workflow có thể được tích hợp vào trong một môi trường desktop chung cùng với các dịch vụ văn phòng khác như mail …Vì vậy cần có một cơ chế truyền thông mềm dẻo giữa dich vụ Workflow enectment và các ứng dụng Workflow client để hỗ trợ cho việc xây dựng các hệ điều hành khác nhau sẽ gặp trong tương lai.
Trong mô hình Workflow, việc tương tác xảy ra giữa các ứng dụng khách và Workflow engine thông qua một giao diện được xác định rõ ràng với các khái niệm như Worklist( danh sách công việc)- hàng đợi của các mục công việc do Workflow Engine gán cho một người dùng cụ thể (hay một nhóm người dùng chung). Tại mức đơn giản nhất, danh sách công việc có thể được truy cập bởi Workflow engine nhằm mục đích gán các khoản mục công việc và bởi bộ quản lý
danh sách công việc để lấy ra các khoản mục công việc giao cho người dùng xử lý.
Việc kích hoạt các khoản mục công việc riêng lẻ từ danh sách công việc (ví dụ khởi động ứng dụng và liên kết dữ liệu liên quan tới Workflow) có thể được kiểm soát bởi ứng dụng Workflow client hay người dùng cuối. Một loạt các thủ tục được xác định giữa ứng dụng Workflow client và dịch vụ Workflow enactment để cho phép: bổ sung các hành vi vào trong danh sách công việc, loại bỏ các hành vi đã hoàn thành khỏi danh sách công việc, dừng tạm thời một số hành vi.
Việc triệu gọi ứng dụng có thể được điều khiển từ bộ quản lý danh sách công việc, hoặc dưới sự kiểm soát trực tiếp của người dùng cuối. Phần này sẽ được đề cập chi tiết trong giao diện III- giao diện triệu gọi ứng dụng.
Một phần của dữ liệu liên quan đến hành vi gắn kết với danh sách công việc là thông tin cần thiết cho phép bộ quản lý danh sách công việc triệu gọi các ứng dụng phù hợp. Tại nơi các dữ liệu ứng dụng được phân loại rõ ràng, sự kết hợp có thể được lưu trữ trong bộ điều khiển danh mục công việc và sử dụng cho mục đích này. Trong các trường hợp khác, sự trao đổi đầy đủ bao gồm tên và thông tin định vị ứng dụng có thể là cần thiết giữa bộ quản lý danh sách công việc với Workflow engine, trong đó ứng dụng Workflow client có thể cũng thực thi một vài chức năng từ giao diện triệu gọi ứng dụng để lấy được các thông tin cần thiết.
Một danh sách công việc có thể chứa nhiều khoản mục liên quan đến một vài bản sao đã được kích hoạt khác nhau của một tiến trình đơn lẻ hoặc các khoản mục cụ thể từ việc kích hoạt một vài tiến trình khác nhau. Bộ quản lý danh sách công việc phải có tiềm năng tương tác với một vài Workflow engine và một vài dịch vụ enactment khác nhau.
Do đó giao diện giữa ứng dụng Workflow client và Workflow engine phải đủ mềm dẻo theo nghĩa của:
•Bộ định danh các tiến trình và hành vi •Tên và địa chỉ tài nguyên
•Các cơ chế truyền thông có thể có
để chứa được các cách tiếp cận cài đặt khác nhau.
2.4.2. Giao diện ứng dụng workflow phía khách
Cách tiếp cận để đáp ứng các yêu cầu ở trên hàm chứa một sự đa dạng ẩn chứa sau một tập chuẩn các API được sử dụng trong một khuôn khổ thống nhất để truy cập từ một ứng dụng Workflow tới Workflow engine và danh sách công việc bất chấp bản chất việc cài đặt thực tế của sản phẩm.
Các API và các tham số của chúng sẽ được ánh xạ lên một vài cơ chế truyền thông khác nhau để đáp ứng tính đa dạng của các mô hình cài đặt Workflow.
Cách tiếp cận tổng quát cho API ứng dụng khách được chỉ ra trong hình dưới.
Sau đây sẽ cung cấp một cách nhìn tống quan về các APIs cho ứng dụng máy khách được nhóm theo các lĩnh vực chức năng khác nhau:
Thiết lập session
•Kết nối/ huỷ kết nối của các session giữa các hệ thống tham gia
Các hoạt động định nghĩa Workflow
•Lấy lại/ truy vấn (với các tiêu chuẩn chọn lọc để chọn) trên tên hay thuộc tính định nghĩa tiến trình.
Các chức năng điều khiển tiến trình
•Tạo/ khởi động/ kết thúc một tiến trình riêng lẻ cụ thể •Đình chỉ/ bắt đầu lại một tiến trình riêng lẻ
•Ép buộc thay đổi một trạng thái trong một tiến trình đơn lẻ hay một hoạt động
•Gắn hay truy vấn một thuộc tính của một tiến trình hoặc một hoạt động
Các chức năng trạng thái tiến trình
•Mở/đóng một tiến trình hay một hoạt động truy vấn, thiết lập để chọn lọc các tiêu chuẩn.
•Nắm bắt chi tiết tiến trình hay hoạt động, lọc những thông tin quan trọng •Nắm bắt chi tiết một tiến triến trình hoặc hoạt động cụ thể (đơn lẻ)
Các chức năng quản lý danh sách công việc/ khoản mục công việc
•Mở/đóng một truy vấn danh sách công việc, thiết lập để chọn lọc các tiêu chuẩn
•Nắm bắt các danh mục danh sách công việc, chọn lọc những thông tin quan trọng
•Khai báo sự lựa chọn/ gán lại/ hoàn thành một mục công việc cụ thể •Gán hay truy vấn một thuộc tính mục công việc
Các chức năng giám sát tiến trình
•Thay đổi trạng thái hoạt động của một định nghĩa tiến trình Workflow và/hoặc tiến trình hiện còn hoạt động.
•Thay đổi trạng thái của toàn bộ tiến trình hoặc hoạt động của một loại cụ thể
•Gán các thuộc tính tới tất cả các tiến trình hay hoạt động của một loại cụ thể
•Chấm dứt toàn bộ tiến trình
Các chức năng điều khiển dữ liệu
•Lấy lại/ trả về dữ liệu liên quan hay ứng dụng Workflow
Các chức năng quản trị
Hỗ trợ thêm các chức năng quản lý thông qua WAPI để có thể phù hợp cho các ứng dụng khách nào đó.
Các triệu gọi ứng dụng
Các chức năng được giới thiệu ở trên cung cấp một mức chức năng cơ bản để hỗ trợ triệu gọi ứng dụng nhờ bộ điều khiển danh sách công việc. Một số câu lệnh được đưa ra cho chức năng triệu gọi ứng dụng cũng có thể có liên quan và được sử dụng cho môi trường ứng dụng khách.
2.5.CÁC CHỨC NĂNG TRIỆU GỌI ỨNG DỤNG2.5.1. Triệu gọi ứng dụng trong hệ thống Workflow 2.5.1. Triệu gọi ứng dụng trong hệ thống Workflow
2.5.1.1. Các ứng dụng được triệu gọi
Bất kỳ cài đặt cụ thể nào của hệ thống quản lí Workflow nào cũng không có đủ nguyên lý thiết kế để có khả năng hiểu được cách triệu gọi tất cả những ứng dụng tiềm năng, đang tồn tại trong một môi trường sản phẩm không thuần nhất như thế nào. Điều này đòi hỏi nguyên lý thiết kế đó phải đáp ứng được việc triệu gọi có thể thực hiện xuyên xuốt trong tất cả các platform và môi trường mạng khác nhau, cùng với một cách thức truyền ứng dụng, dữ liệu liên quan tới Workflow trong một phương pháp mã hóa và định dạng chung (hoặc chuyển đổi nó sang môi trường ứng dụng riêng biệt).
Tuy nhiên, có rất nhiều hệ thống Workflow đề cập tới một phạm vi giới hạn lớn hơn của các ứng dụng, cụ thể ở đây dữ liệu được định kiểu một cách rõ ràng và có thể trực tiếp kết hợp (ví dụ thông qua một thư mục) với một công cụ ứng dụng cụ thể như các trình soạn thảo hoặc bảng tính . Trong trường hợp khác, việc triệu gọi ứng dụng của một thao tác bởi một ứng dụng cụ thể nào đó có thể được
hoàn thành thông qua một cơ chế trao đổi chuẩn như giao thức OSI TP hoặc X.400. Một vài cách cài đặt sử dụng tới khái niệm “Application Agent” để chứa các phương thức triệu gọi đa dạng đằng sau một giao diện chuẩn trong dịch vụ Workflow Enactment.Đó cũng là triển vọng để phát triển khả năng Workflow hóa các công cụ ứng dụng, thông qua việc sử dụng một tập chuẩn các API để kết nối với dịch vụ Workflow Enactment - chấp nhận dữ liệu ứng dụng, đăng ký và trả lời các sự kiện hành động ... Các API có thể sử dụng trực tiếp bởi công cụ ứng dụng hoặc một ứng dụng Agent
Bảng 1-1 Giao diện triệu gọi ứng dụng
Tổ chức WfMC tập trung vào phát triển danh sách kiểu giao diện cùng với tập APIs để sử dụng cho ứng dụng Workflowriêng biệt trong tương lai.
2.5.1.2. Giao diện triệu gọi ứng dụng
Hình sau chỉ phạm vi của giao diện được dự định áp dụng cho các Ứng dụng Agent và các ứng dụng được thiết kế có khả năng Workflow hóa (vd tương tác trực tiếp với Workflow Engine)
Trong trường hợp đơn giản, sự triệu gọi ứng dụng được Workflow engine quản lí một cách cục bộ dựa trên các thông tin bên trong định nghĩa tiếntrình để xác định bản chất của hành vi, kiểu ứng dụng được triệu gọi và bất kỳ yêu cầu dữ liệu nào. Ứng dụng được triệu gọi có thể là cục bộ đối với Workflow engine và nằm trên cùng một nền với Workflow engine hoặc nằm trên một nền mạng truy cập được tách biệt; định nghĩa tiến trình chứa những thông tin đầy đủ về kiểu ứng dụng và địa chỉ để triệu gọi ứng dụng. Trong trường hợp này các quy định về việc đặt tên và đánh địa chỉ ứng dụng là cục bộ giữa định nghĩa tiến trình và Workflow engine.
Kiểu giao diện Truy nhập dữ liệu liên
quan tới Workflow Chuẩn tham gia
Lời gọi tiến trình cục bộ File cục bộ Không
Shell script File cục bộ Môi trường POSIX
Lời gọi ORB (liên kết đối tượng, chạy dịch vụ)
Thông qua tham chiếu (gọi tham số )
Có
Lời gọi thực thi từ xa Thông qua tham chiếu (gọi tham số )
Có
Chuyển thông điệp (X.400)
Được đính kèm hoặc thông qua tham chiếu
Có
Giao dịch Được đính kèm hoặc thông qua tham chiếu
Hình 2-7 Giao diện ứng dụng được triệu gọi
Phần dưới đây sẽ đưa ra phác thảo của tập các câu lệnh có thể áp dụng cho các chức năng triệu gọi ứng dụng :
Thiết lập phiên làm việc:
•Kết nối / Huỷ bỏ kết nối của phiên ứng dụng.
Các chức năng quản lý hành vi:
(Workflow engine tới ứng dụng) •Bắt đầu chạy hành vi
•Tạm ngưng / Khôi phục / Loại bỏ hành vi. (Workflow ứng dụng tới engine).
•Cảnh báo hành vi đã hoàn thành. •Sự kiện báo động (đồng bộ hoá). •Truy vấn các thuộc tính của hành vi.
Các chức năng quản lí dữ liệu:
•Cung cấp các dữ liệu liên quan đến Workflow. •Cung cấp dữ liệu ứng dụng hoặc địa chỉ của dữ liệu.
Trong các tình huống phức tạp hơn gồm có sự tương tác giữa các Workflow engine không thuần nhất, người ta đòi hỏi rằng các thông tin triệu gọi ứng dụng được truyền giữa các Workflow engine hoặc như là một phần của trao đổi trong thời gian thực hiện hoặc nhờ việc nhập vào các phần của định nghĩa tiến trình sau giai đoạn phát triển tiến trình.
2.5.1.3. Agent ứng dụng
Dựa trên các công nghệ kết nối khác nhau, cái gọi là “Tool Agents” có thể điều khiển các ứng dụng và thông tin trao đổi. Tool Agents diễn tả như một sự chỉ ra công nghệ triệu gọi. Tool Agents dùng ít nhất một công nghệ triệu gọi nhất định, chẳng hạn là các câu lệnh DDE, giao thức OLE, CORBA….
Công nghệ để tương tác giữa một Tool Agent và một ứng dụng tương đương độc lập với mức dưới của kiến trúc và ứng dụng- các giao diện cụ thể được quản lí dưới sự điểu khiển Tool Agents. Giao diện triệu gọi xác định cách Tool Agent được sử dụng bởi ứng dụng Workflow ví dụ như một worklist handler hoặc Workflow engine. Cuối cùng, mục đích của Tool Agents có thể được so sánh với mục đích của các thành phần phần mềm đã được chuẩn hóa..
Tập các chức năng giao diện ứng dụng cung cấp các dịch vụ tới Tool Agents, để Tool Agent có thể triệu gọi và điều khiển các ứng dụng được kết hợp với các mục công việc.
Giao diện triệu gọi ứng dụng định nghĩa tập API, các API này ở mức cao và được sử dụng bởi các thành phần hệ thống Workflow (engine và ứng dụng khách) để chỉ ra driver ứng dụng được gọi bởi Tool Agents. Tool Agents có thể bắt đầu, kết thúc hoặc ngừng các ứng dụng, nó chuyển Workflow và các thông tin liên quan ứng dụng tới ứng dụng hoặc từ các ứng dụng tới Workflow và điều khiển các mức
trạng thái ứng dụng đang chạy. Vì thế giao diện triệu gọi ứng dụng WAPI chỉ được định hướng dựa vào Tool Agent. Tuy nhiên, thông tin thêm vào có thể được yêu cầu bởi ứng dụng qua Tool Agent sử dụng các chức năng chuẩn của WAPI. Như vậy giao diện có thể nắm giữ được các yêu cầu hai chiều (các yêu cầu tới ứng dụng và từ ứng dụng), nó phụ thuộc vào các giao diện và kiến trúc các ứng dụng làm thể nào để tương tác với một Tool Agent.
Giao diện này cho phép yêu cầu và cập nhật dữ liệu ứng dụng và nhiều chức năng liên quan khác trong thời gian chạy.
Hệ thống Workflow biết sự cài đặt Tool Agents. Kiến trúc cơ bản của Tool Agent cũng có thể so sánh với các driver-interface ví dụ ODBC ….Trong phạm vi giao diện, không có nhiều kĩ thuật kết nối giữa Tool Agents và hệ thống Workflow.
2.5.1.4. Các ứng dụng có khả năng Workflow
Ứng dụng có khả năng Workflow là ứng dụng có chức năng Workflow được gắn vào hệ thống. Trong những hệ thống này, Workflow không thể định nghĩa lại tiến trình được mà những định nghĩa này là cứng trong hệ thống, nó được nhà cung cấp định sẵn để phản ánh những tiến trình được mọi người thừa nhận ví dụ như tiến trình phát triển dự án: lấy yêu cầu người dùng - phân tích thiết kế - mã hóa – kiểm thử - vận hành và bảo trì. Và ứng dụng sẽ thực thi xuyên suốt theo kịch bản của những tiến trình như vậy. Việc cài đặt ứng dụng này tùy theo nhà khai thác sản phẩm Workflow và yêu cầu của từng khách hàng.
2.6.CHỨC NĂNG GIAO TIẾP MỞ
Mục đích chính của tổ chức là định nghĩa các chuẩn mà qua đó sẽ cho phép các hệ thống Workflow được sản xuất bởi các nhà cung cấp khác nhau để chuyển các khoản mục công việc một cách liền mạch giữa chúng với nhau
Công việc của tổ chức chủ yếu tập chung vào việc phát triển một vài trường hợp giao tiếp, mà chúng có thể áp dụng hiệu quả tại mức, từ đơn giản là việc truyền đi một nhiệm vụ nào đó tới việc trao đổi toàn bộ một định nghĩa tiến trình, trao đổi các dữ liệu liên quan tới Workflow...
Có bốn mô hình giao tiếp được nhận biết, chúng bao trùm các mức khác nhau của những khả năng có thể xảy ra. Các mục sau đây sẽ mô tả những mô hình giao tiếp đó, các minh họa sử dụng các hình vuông để biểu thị cho các nhiệm vụ và các hành vi, với các hình khác nhau để chỉ rõ các các nhiệm vụ được sắp xếp trong từng dịch vụ Workflow Enactment
2.6.1. Scenario 1 – Liên kết riêng rẽ (dạng chuỗi)
Mô hình này cho phép một kết nối điểm trong tiến trình A liên kết tới một điểm khác trong tiến trình B. Mặc dù hình minh họa chỉ ra những điểm kết nối này là ở đầu và cuối của các tiến trình nhưng thực tế các điểm kết nối có thể là ở bất kỳ vị trí nào trong tiến trình. Điều này tạo nên một tiến trình kép từ hai tiến trình con
Hình 2-7. Mô hình chuỗi các dịch vụ