Khóa luận Nghiên cứu và thử nghiệm hệ thống WORKFLOW

để 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. Hình 27 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. 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. 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. 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 Scenario 1 – Liên kết riêng rẽ (dạng chuỗi) Tiến trình B Tiến trình A 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 B3 A4 B4 B1 A1 B5 A5 B2 A3 A2 Miền dịch vụ WF B Miền dịch vụ WF A 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 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 Scenario 2 – Liên kết theo trật tự (các tiến trình con lồng vào 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 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 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 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 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 C1 C4 C2 C3 C5 C6 Tiến trình C Workflow Engine(s) A Workflow Engine(s) B Miền dùng chung của dịch vụ Workflow A và B 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 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 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 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 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. 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 Workflow API and Interchange formats Workflow API and Interchange formats Workflow Enactment Service Workflow Enactment Service Workflow Engine(s) Workflow Engine(s) 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: 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 thể, khả năng giao tiếp bắt buộc phải dùng tới cách tiếp cận qua cổng. Các đối tượng chỉ định và các thuộc tính được ánh xạ giữa hai môi trường thông qua một ứng dụng cổng chung. Trong trường hợp đơn giản nhất, hai dịch vụ Enactment riêng rẽ sử dụng các định dạng tiến trình riêng của chúng và bất cự một ánh xạ nào giữa chúng đều được quản lý bởi ứng dụng cổng. Cách tiếp cận cũng có thể sử dụng trong các truờng hợp đơn giản hơn như scenario 1 và 2 hay một vài ví dụ thông thường của scenario 4 Các giao tiếp trong quá trình thực thi Trong quá trình chạy, các lời gọi WAPI được sử dụng để truyền điều khiển giữa các dịch vụ Workflow để ban hành các tiến trình con hay các hành vi riêng rẽ trên một dịch vụ cụ thể. Khi cả hai dịch vụ đều hỗ trợ các lời gọi WAPI ở một mức chung và cùng có chung một quan niệm về các đối tượng định nghĩa tiến trình (bao gồm các quy ước đặt tên, dữ liệu Workflow, dữ liệu ứng dụng ...), Engine sẽ trực tiếp giao tiếp với nhau – mặc dù sẽ có đòi hỏi sự chấp thuận về giao thức chung hỗ trợ cho các WAPI chính Các lời gọi API có thể được sử dụng để thiết kế một cổng chwsc năng cho phép kết hợp giữa hai dịch vụ workflow bởi các ánh xạ những quan niệm khác nhau về đối tượng và dữ liệu của hai môi trường và (khi cần) hỗ trợ các môi trường giao thức khác nhau trong mỗi dịch vụ workflow Workflow domain A Workflow domain B WAPI WAPI Protocol A Protocol B Workflow Engine(s) Workflow Engine(s) Start activity Transformations start activity or processs completion completion Prrocess definition object types & names Workflow relevant data formats & names Application data transfer Gateway Applitcation Hình 2-12. Gate way operation using WAPI Hình vẽ trên mô tả nguyên lý chính của thao tác cổng theo một trường hợp kết hợp cụ thể, một hành vi riêng rẽ từ một miền (A) có thể được ánh xạ tới một hành vi đơn lẻ hoặc một tiến trình / tiến trình con mới trong miền thứ hai (B) Phần lớn các câu lệnh WAPI có vẻ thích hợp được khai thác để hỗ trợ cho chức năng giao tiếp khác bằng lời gọi trực tiếp giữa hai dịch vụ workflow hoặc thông qua một chức năng cổng. Rất nhiều câu lệnh WAPI được thảo luận từ trước cũng có khả năng thích hợp cho chức năng giao tiếp này Thiết lập phiên làm việc Các thao tác trên các định nghĩa workflow và các đối tượng của chúng Các chức năng liên quan tới điều khiển tiến trình và trạng thái của chúng Các chức năng quản lý hành vi Các thao tác quản lý dữ liệu CÁC CHỨC NĂNG QUẢN TRỊ VÀ GIÁM SÁT Phần này giới thiệu chuẩn giao diện chung cho các chức năng quản trị và giám sát. Các chức năng này sẽ cho phép một dịch vụ quản lý ứng dụng có thể làm việc với các engine của các nhà cung cấp khác. Điều này sẽ cung cấp một giao diện chung cho phép một vài dịch vụ Workflow chia sẻ phạm vi của chức năng quản trị và giám sát hệ thống chung Giao diện sẽ bao gồm những câu lệnh cụ thể nằm trong tập WAPI để điều khiển các chức năng quản trị và giám sát được chỉ định. Hơn nữa, các cân nhắc mở rộng được mong đợi để xác định phạm vi giao diện này có thể khai thác các cơ chế giao thức đã có như CMIP, SNMP để thiết đặt và gọi các trạng thái quản lý cùng các thông tin thống kê được định nghĩa trong một Cơ sở thông tin quản lý (MIB) mở Giao diện quản trị và giám sát Giao diện phía dưới minh hoạ một ứng dụng quản lý độc lập tương tác với các miền Workflow khác nhau, mặc dù có nhiều kịch bản triển khai khả thi. Trong ví dụ này ứng dụng quản lý có thể là phần không thể thiếu của một dịch vụ enactment, mặc dù năng lực quản lý các chức năng khác nhau xuyên suốt các miền Workflow thêm vào (không thuần nhất) Hình 213 Giao diện quản trị và giám sát hệ thống Giao diện có thể áp dụng cho các ứng dụng quản lý với các chức năng quản lý khác.Ví dụ, nó cũng có thể quản lý một định nghĩa tiến trình, giữ vai trò như một kho lưu trữ và phân phối các định nghĩa tiến trình tới các miền Workflow khác nhau thông qua các thao tác trong giao diện 1 Một giao diện quản lý và giám sát của Workflow bao gồm các vùng chức năng điển hình là : Các hoạt động quản lý người dùng: Thiết lập/ xoá bỏ/ đình chỉ/ bổ xung các đặc quyền của người dùng hay nhóm người dùng. Các hoạt động quản lý vai trò (role): Định rõ/ xoá/ bổ xung vai trò. Thiết lập hay huỷ bỏ thiết lập trên các thuộc tính của vai trò. Các hoạt động quản lý kiểm tra : Truy vấn/in ra/tạo mới/xoá bỏ các vết sự kiện hay các bản ghi vết sự kiện... Các hoạt động điều khiển nguồn tài nguyên: Thiết lập/huỷ bỏ thiết lập/chỉnh sửa tiến trình hoặc các hành vi cùng mức Kiểm tra dữ liệu điều khiển tài nguyên. Các chức năng giám sát tiến trình: Thay đổi trạng thái thực hiện của định nghĩa tiến trình Workflow cũng như các bản sao tiến trình. Cho phép/không cho phép các phiên bản nhất định của một định nghĩa tiến trình. Thay đổi trạng thái của tất cả các bản sao của hành vi hay tiến trình thuộc cùng một loại. Gán các thuộc tính cho tất cả các bản sao của tiến trình hay hành vi thuộc cùng một loại. Kết thúc tất cả các bản sao của tiến trình. Các chức năng liên quan tới trạng thái tiến trình: Mở/đóng các truy vấn đối với bản sao của hành vi hay tiến trình. Lấy về các chi tiết của bản sao của tiến trình hay hành vi. GIAO DIỆN ĐỊNH NGHĨA TIẾN TRÌNH SIÊU MÔ HÌNH Hiệp hội quản lý Workflow (WFMC) đã xây dựng một siêu mô hình để định nghĩa tiến trình với một tập các kiểu đối tượng cơ sở phù hợp cho việc trao đổi các định nghĩa tiến trình tương đối đơn giản. Sau đó tập các đối tượng cơ bản có thể được mở rộng bởi nhà cung cấp với các đối tượng có chức năng bổ sung. Siêu mô hình mô tả các thực thể mức cao được chứa trong một định nghĩa tiến trình, quan hệ giữa chúng và các thuộc tính của chúng. Siêu mô hình cũng định nghĩa các quy tắc khác nhau cho việc nhóm các định nghĩa tiến trình vào các mô hình tiến trình liên quan và sử dụng dữ liệu định nghĩa chung qua các đinh nghĩa (hoặc mô hình ) tiến trình khác nhau. Các thực thể mức cao được chỉ ra trong hình dưới đây: Hình 31 Các thực thể mức cao của siêu mô hình Mỗi một thực thể ở trên có một tập các thuộc tính, các thuộc tính này sẽ mô tả các đặc điểm của mỗi thực thể đó. Các thực thể trong siêu mô hình Mỗi một siêu mô hình sẽ xác định một tập các thực thể được sử dụng trong quá trình trao đổi định nghĩa tiến trình. Các thực thể mức cao sẽ được chỉ ra dưới đây: Định nghĩa tiến trình Thực thể định nghĩa tiến trình sẽ cung cấp thông tin một cách khái niệm để áp dụng cho các thực thể khác cho tiến trình Workflow đó. Nó cung cấp các thông tin giám sát (thời gian tạo, tác giả) hoặc cung cấp các thông tin được sử dụng trong quá trình thực thi (tham số khởi tạo, độ ưu tiên, các giới hạn thời gian được kiểm tra, thông tin mô phỏng, người được thông báo). Hành vi tiến trình Một định nghĩa tiến trình bao gồm một hay nhiều hành vi, các đơn vị công việc logic hay bao gồm định nghĩa tiến trình khác. Một hành vi mô tả một công việc. Công việc đó sẽ được thực hiện bằng việc phối hợp các tài nguyên hoặc các ứng dụng tính toán. Các hành vi sẽ sử dụng các dữ liệu liên quan đến Workflow. Phạm vi của hành vi là cục bộ đối với mỗi định nghĩa tiến trình cụ thể. Một hành vi có thể là một tiến trình con. Trong trường hợp này hành vi đó sẽ thực thi một định nghĩa tiến trình riêng biệt. Nó có thể được thực hiện một cách cục bộ trong một dịch vụ Workflow tương tự hoặc dịch vụ từ xa. Một tiến trình con cũng chính là một định nghĩa tiến trình, nó cũng chứa các hành vi, chứa các chuyển tiếp, chứa các tài nguyên, các ứng dụng (mặc dù chúng có thể kế thừa từ một nguồn chung). Một hành vi có thể là một hành vi khối nhằm thực hiện một tập các hành vi hoặc ánh xạ các hành vi và các chuyển tiếp. Các hành vi và các chuyển tiếp sẽ chia sẻ không gian tên và tiến trình chứa chúng. Cuối cùng, hành vi giả (dummy activity) không thực hiện một công việc cụ thể nào cả (Do vậy nó không kết hợp với các tài nguyên cũng như các ứng dụng). Hành vi giả hỗ trợ một cách đơn giản việc đưa ra quyết định định tuyến giữa các phép chuyển đầu vào và các phép chuyển đầu ra. Thông tin chuyển tiếp giữa các hành vi Mỗi hành vi có liên quan đến các hành vi khác theo các điều kiện điều khiển. Các điều kiện đó được gọi là thông tin chuyển tiếp. Mỗi một chuyển tiếp đều có 3 thành phần cơ bản đó là hành vi nguồn, hành vi đích và điều kiện . Một chuyển tiếp từ hành vi này đến hành vi khác có thể có điều kiện hoặc không có điều kiện (Bao gồm các biểu thức được tính giá trị để cho phép hoặc cấm chuyển tiếp đó). Việc chuyển tiếp trong một tiến trình có thể diễn ra một cách trình tự hoặc song song. Các thông tin có liên quan được kết hợp với các điều kiện gia nhập (join) hoặc điều kiện phân tách (split) được định nghĩa trong hành vi tương ứng. Phạm vi của một chuyển tiếp cụ thể là cục bộ đối với định nghĩa tiến trình chứa nó. Đối với các chuyển tiếp phức tạp, chúng không thể được biểu diễn bằng cách sử dụng các chuyển tiếp cơ bản và các chức năng gia nhập và phân tách, chúng được hình thành bằng cách sử dụng các hành vi giả, là hành vi có thể được xác định như những bước chuyển trung gian giữa các hành vi thực để cho phép phối hợp bổ xung vào các thao tác gia nhập và phân tách. Khai báo thành phần tham gia Workflow Phần này cung cấp cách mô tả các tài nguyên đóng vai trò như là người thực thi các hành vi khác nhau trong định nghĩa tiến trình. Các tài nguyên cụ thể, có thể được gán để thực hiện các hành vi cụ thể, chúng được định rõ như một thuộc tính của hành vi đó. Thao tác gán là việc kết nối hành vi đó với một tập các tài nguyên (trong khai báo tài nguyên Workflow). Các tài nguyên này có thể được cấp phát cho hành vi đó. Việc khai báo thành phần tham gia Workflow không nhất thiết phải là con người hoặc một cá nhân riêng biệt, nhưng cũng có thể xác định một tập các cá nhân có cùng kỹ năng hoặc trách nhiệm, hoặc một tài nguyên tự động như máy móc. Siêu mô hình bao gồm một vài kiểu tài nguyên có thể được định nghĩa trong thành phần khai báo thành phần tham gia Workflow. Kho tài nguyên Kho tài nguyên chứa các thành phần tham gia. Đó có thể là con người, là các chương trình, hoặc các máy móc thiết bị. Trong nhiều trường hợp việc khai báo thành phần tham gia có thể tham chiếu đến kho tài nguyên, kho tài nguyên có thể là một mô hình tổ chức trong trường hợp thành phần tham gia là con người. Khai báo ứng dụng Workflow Phần này cung cấp sự mô tả các ứng dụng IT hoặc các giao diện có thể được triệu gọi bởi các dịch vụ Workflow nhằm mục đích hỗ trợ tự động một phần hoặc tự động hoàn toàn việc thực thi một hành vi. Các ứng dụng như vậy có thể là các công cụ công nghiệp chung, hoặc các dịch vụ xí nghiệp cụ thể, hoặc các thủ tục cục bộ đã được cài đặt trong framework của hệ thống quản lý Workflow đó. Việc định nghĩa các ứng dụng Workflow phản ánh giao diện giữa Workflow engine với các ứng dụng đó. Dữ liệu liên quan đến Workflow Phần này định nghĩa dữ liệu được tạo ra và sử dụng trong mỗi bản sao tiến trình trong quá trình thực thi. Dữ liệu đó luôn sẵn sàng cho các hành vi hoặc các ứng dụng trong Workflow và có thể được sử dụng nhằm chuyển những thông tin liên tục hoặc các kết quả trung gian để tính toán các biểu thức điều kiện như là trong các chuyển tiếp hoặc để gán các thành phần tham gia. Dữ liệu liên quan đến Workflow có kiểu xác định. Các hành vi, các ứng dụng được triệu gọi và/hoặc các điều kiện chuyển tiếp có thể tham chiếu tới dữ liệu liên quan Workflow. Dữ liệu môi trường và dữ liệu hệ thống Đây là dữ liệu được bảo trì bởi hệ thống quản lý Workflow hoặc môi trường hệ thống cục bộ, nhưng cũng có thể được truy cập bởi các hành vi hoặc được sử dụng bởi hệ thống Workflow đó trong việc tính toán các biểu thức điều kiện một cách tương tự như dữ liệu liên quan Workflow. Các kiểu dữ liệu và các biểu thức Siêu mô hình đưa ra một số các kiểu dữ liệu chuẩn như ( kiểu chuỗi, kiểu số nguyên, kiểu số thực, kiểu thời gian). Các biểu thức có thể sự dụng các kiểu dữ liệu đó để hỗ trợ việc tính toán. Ngoài ra còn hỗ trợ một số kiểu mở rộng khác. Tiến trình và gói Theo hình II -2 mô hình tiến trình bao gồm các thực thể khác nhau mà những thực thể này có thể được sử dụng trong nhiều định nghĩa tiến trình.Ví dụ một định nghĩa tiến trình có thể sử dụng thành phần tham gia hay các ứng dụng của một định nghĩa tiến trình khác. Vì vậy người ta đưa ra khái niệm gói. Gói như là một bộ chứa để chứa định nghĩa tiến trình và một số thuộc tính chung từ các thực thể định nghĩa tiến trình. Mỗi một định nghĩa tiến trình được chứa trong một gói sẽ tự động kế thừa tất cả các thuộc tính chung từ gói đó, trừ khi chúng được định nghĩa lại trong định nghĩa tiến trình đó. Trong một gói, phạm vi của một vài thực thể là toàn cục và một số thực thể có thể được tham chiếu từ tất cả các định nghĩa tiến trình Workflow được chứa trong gói đó. Những thực thể đó là: Đặc tả thành phần tham gia Workflow Khai báo ứng dụng Workflow Dữ liệu liên quan Workflow Siêu mô hình tiến trình Siêu mô hình tiến trình đưa ra một tập cơ bản các thực thể và thuộc tính cho việc trao đổi định nghĩa tiến trình. Trong mỗi một định nghĩa tiến trình các thực thể sau đây phải được định nghĩa, hoặc là tại định nghĩa tiến trình đó, hoặc kế thừa trực tiếp hoặc tham chiếu từ một gói mở rộng. Hành vi tiến trình Workflow Thông tin chuyển tiếp giữa các hành vi Đặc tả thành phần tham gia Workflow Khai báo ứng dụng Workflow Dữ liệu liên quan Workflow Hình 32 Siêu mô hình định nghĩa tiến trình Workflow Mỗi thực thể có các thuộc tính khác nhau và chúng sẽ được mô tả trong các phần sẽ được trình bày ở các phần sau của tài liệu này. Siêu mô hình gói Nhiều định nghĩa tiến trình có giới hạn giống nhau trong mộ