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ụ
Mô hình này hỗ trợ việc truyền một khoản mục công việc đơn (một bản sao tiến trình hay hành vi) giữa hai môi trường Workflow, sau đó nó được thực hiện một cách độc lập trong môi trường thứ hai. Mô hình có thể được thực hiện thông
Miền dịch vụ WF A A2 Miền dịch vụ WF B A1 A3 B2 A5 A4 B5 B1 B4 B3 Tiến trình A Tiến trình B
qua một chức năng cổng các ứng dụng, trình quản lý chuyển đổi định dạng dữ liệu, ánh xạ tên tiến trình và hành vi. Các chức năng này cũng có thể được gộp vào một trong các dịch vụ workflow và giao tiếp qua các lời gọi API chuẩn giữa chúng
2.6.2. Scenario 2 – Liên kết theo trật tự (các tiến trình con lồng vào nhau) nhau)
Mô hình này cho phép một tiến trình được thực thi ở một miền Workflow cụ thể có thể gói gọn toàn bộ như một nhiệm vụ đơn trong một tiến trình được thực thi ở một miền Workflow khác. Giữa hai tiến trình này tồn tại một mối quan hệ có trật tự, mối quan hệ này xuyên suốt và liên tục ở một vài mức, định hình một tập các tiến trình con lồng vào nhau
Hình 2-8. Mô hình các tiến trình con lồng vào nhau
Trong hình vẽ, một hành vi A3 được định nghĩa trong dịch vụ Workflow A đóng vai trò là toàn bộ tiến trình B trong dịch vụ Workflow B. Đây là một trường hợp đơn giản với một thực thể và điểm thoát đơn trong tiến trình B
2.6.3. Scenario 3 – Liên kết thành một khối (Peer to Peer)
Mô hình này cung cấp cho ta một môi trường pha trộn hoàn toàn, hình vẽ biểu thị một tiến trình ghép C, nó bao gồm các hành vi có thể thực thi xuyên xuốt các dịch vụ bao gồm nhiều Workflow –miền dùng chung. Các hành vi C1, C2 và C5 được phối hợp bởi dịch vụ A và các hành vi C3, C4, C6 lại được phối hợp bởi dịch vụ B A1 A4 A2 A3 A5 B1 B3 B2 B4 B5 Tiến trình A Tiến trình B Miền dịch vụ WF A Miền dịch vụ WF B
Trong trường hợp này, tiến trình sẽ tiến hành một cách trong suốt từ nhiệm vụ này tới nhiệm vụ kia, không có các hành động cụ thể bởi người dùng và quản trị gia, bằng các giao tiếp giữa các Workflow Engine riêng biệt với nhau
Hình 2-9. Mô hình Peer-Peer
Ngoài ra ở đây còn có sự yêu cầu cả hai dịch vụ Workflow phải cùng hỗ trợ một tập API chung cho quá trình giao tiếp và cùng có thể thông dịch một định nghĩa tiến trình chung. Chúng cùng phải được tiếp nhận vào môi trường làm việc các xây dựng của tiến trình chung và chuyển cho tiến trình kia những thay đổi trong suốt quá trình thực thi. Dữ liệu liên quan tới Workflow và dữ liệu ứng dụng cũng cần phải được trao đổi giữa các Engine
2.6.4. Scenario 4 – Liên kết đồ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ể truyền qua các dịch vụ enactment riêng biệt. Nhưng nó đòi hỏi phải có những điểm đồng bộ hóa giữa hai tiến trình. Việc đồng bộ này yêu cầu các tiến trình, mỗi một đoạn có một điểm xác định trước trong chuỗi thực thi của chúng để đồng bộ hóa. Kiểu cơ chế này sử dụng để làm cho các chắc năng trở nên dễ dàng như việc lập lịch tiến trình thông qua các luồng thực thi song song, điểm kiểm tra khôi phục dữ liệu hay việc truyền dữ liệu Workflow giữa bản sao các tiến trình khác nhau C1 C4 C2 C3 C5 C6 Tiến trình C Workflow Engine(s) A Workflow Engine(s) B
Trong hình vẽ dưới đây việc đồng bộ được chỉ ra giữa hành vi A3 của tiến trình A và hành vi B4 của tiến trình B
Hình 2-10. Mô hình đồng bộ hóa song song
Việc khớp các công việc có thể đồng bộ hóa tại các điểm xác định trong tiến trình. Điều này đòi hỏi việc tập hợp và cơ chế theo dõi, thêm nữa của hai dịch vụ phải có khả năng nhận biết các nhiệm vụ từ hai định nghĩa tiến trình.
2.6.5. Các hàm WAPI giao tiếp
Tính tổng quát của thông tin và điều khiển luồng giữa hai hệ thống Workflow không thuần nhất được chỉ ra ở hình dưới đây
Triệu gọi hành vi hoặc các tiến trình con Trao đổi Tiến trình/Trạng thái hành vi
/Ứng dụng điều khiển /Dữ liệu WF Phối hợp các điểm đồng bộ Đọc/ghi các định nghĩa tiến trình
Hình 2-11. Giao diện chức năng giao tiếp của Workflow
Có hai khía cạnh lớn cần xem xét với chức năng giao tiếp:
Workflow API and Interchange formats Workflow API and Interchange formats Workflow Enactment Service Workflow Enactment Service
Workflow
Engine(s) Workflow Engine(s) A1 A4 A2 A3 A5 B1 B3 B2 Tiến trình A Tiến trình B Miền dịch vụ WF A Miền dịch vụ WF B B3 B3
• Sự đánh giá tới quá trình 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ể hoàn thành được
• Quá trình thực thi hỗ trợ cho việc thông dịch nhiều kiểu khác nhau của thông tin điều khiển và để truyền dữ liệu Workflow, dữ liệu ứng dụng giữa các dịch vụ Enactment khác nhau
Sử dụng các định nghĩa tiến trình trong dịch vụ đa miền
Khi mà cả hai dịch vụ Enactment có thể truyền cho nhau một định nghĩa tiến trình chung, ví dụ được sinh ra từ một công cụ định nghĩa chung nào đó. Điều này cho phép cả hai môi trường cùng có chung một quan nhiệm riêng rẽ về các đối tượng định nghĩa tiến trình và các thuộc tính của chúng. Các đối tượng này có thể bao gồm hành vi, ứng dụng, một tổ chức và vai trò được đặt tên, hay những điều kiện định hướng, ...Những Workflow Engine riêng rẽ có thể truyền các thực thi của các hành vi hay tiến trình con tới những Engine không đồng nhất trong ngữ cảnh có sự quy ước chung về cách đặt tên và mô hình đối tượng. Cách tiếp cận này có thể áp dụng một cách cụ thể cho scenario 3, khi mà một vài hệ thống cùng làm việc ở mức ngang hàng với nhau
Khi quan niệm chung về một định nghĩa tiến trình là không khả thi, cách tiếp cận ‘Truy xuất ra bên ngoài’ các chi tiết của một tập con định nghĩa tiến trình như một phần của các trao đổi trong quá trình chạy là có thể được. Các API trao đổi định nghĩa tiến trình cung cấp một phương tiện của việc truy vấn dữ liệu về đối tượng và thuộc tính từ một dịch vụ Workflow cụ thể, do đó một Workflow Engine có thể sử dụng dữ liệu liên quan tới định nghĩa tiến trình cho một hành vi riên lẻ hay tiến trình con
Khi định nghĩa tiến trình trao đổi thông qua những cách tiếp ở trên là không