XPDL 2.1规范详解 - XML流程定义语言

需积分: 9 129 浏览量更新于2024-07-28 收藏 3.16MB PDF 举报

"XPDL 2.1 规范是Workflow Management Coalition (WfMC) 制定的一份标准，用于定义XML流程定义语言，旨在促进工作流管理的标准化。此规范文档编号为WFMC-TC-1025，于2008年10月10日最终批准，版本号为2.1a。" XPDL（XML Process Definition Language）是一种基于XML的标记语言，专门设计用来描述和交换工作流过程模型。它提供了一种标准化的方式来定义业务流程，使得不同工作流管理系统之间能够进行流程模型的互操作。XPDL 2.1规范的发布，标志着该语言的成熟和广泛接受，它允许开发者以结构化、可读性强的方式定义和存储复杂的业务流程。在XPDL 2.1中，关键知识点包括： 1. **流程定义**：XPDL允许详细地描述每个流程，包括活动、决策点、事件和转换。活动代表流程中的任务，可以是人工或自动执行的；决策点处理流程中的条件分支；事件则表示流程中的特定状态或触发器；转换则定义了活动之间的流向。 2. **数据模型**：XPDL支持数据模型的描述，允许流程中涉及的数据结构和变量被定义和引用。这有助于确保流程中数据的一致性和完整性。 3. **角色和参与者**：XPDL定义了流程参与者和角色的概念，使得可以明确指定哪些任务由哪些用户或角色来执行。 4. **并发和同步**：XPDL支持并行活动和同步机制，允许在流程中同时处理多个任务，并规定何时这些任务应合并或等待其他任务完成。 5. **版本控制**：由于XPDL是XML格式，所以它天然支持版本控制，使得流程模型的修改历史得以记录和跟踪。 6. **互操作性**：XPDL的标准化特性确保了不同工作流管理系统之间可以导入和导出流程模型，促进了系统的集成和迁移。 7. **工具支持**：许多工作流建模和管理工具都支持XPDL，这使得开发人员能够利用这些工具创建、编辑和分析流程模型。 8. **版权信息**：WfMC对XPDL规范拥有版权，但允许在遵守特定许可条款的情况下复制、存储和传输其内容。 XPDL 2.1的使用，有助于企业提升其业务流程的灵活性、可维护性和透明度，同时也为工作流系统的开发者和实施者提供了统一的标准和语言，降低了跨平台操作的难度。通过理解和掌握XPDL，可以更有效地设计、实现和优化业务流程，从而提高企业的运营效率。

展开

Workflow Management Coalition Process Definition 10 October 2008

designers / administrators to ensure consistent name / data type usage within process definitions / models to support

subflow operations (including any required remote process interoperability).

6.2. Package Meta-Model

Multiple process definitions are bound together in a model definition. The Package acts as a container for

grouping together a number of individual process definitions and associated entity data, which is applicable to

all the contained process definitions (and hence requires definition only once).

Process

(W. Process)

Package

[Business Process

Diagram (BPD)]

Type Declaration

Application

Participant

Pool

Lane

Data Field

ExternalPackage

0..1

0..10..1

0..1

MessageFlow

Association

Artifact

source

target

sourcetarget

Activity

target

source

target

Resource Repository or

Organizational Model

System and

environmental data

W. Relevant Data

Data Object

Group

Annotation

Figure 6.1: Package Definition Meta Model

The meta-model for the Package identifies the entities and attributes for the exchange, or storage, of process models. It

defines various rules of inheritance to associate an individual process definition with entity definitions for participant

specification, application declaration and relevant data field, which may be defined at the package level rather than at

the level of individual process definitions.

The Package Definition allows the specification of a number of common process definition attributes, which will then

apply to all individual process definitions contained within the package. Such attributes may then be omitted from the

individual process definitions. (If they are re-specified at the level of an individual process definition this local attribute

value takes precedence over the global value defined at the package level.)

Workflow Management Coalition Process Definition 10 October 2008

6.2.1. Process Repository

The process definition import/export interface is assumed to operate to/from a definition repository of some form

associated with the process or workflow management system. The import/export interface is realized by the transfer of

files containing XPDL into or out of such repository. This interface specification allows the import or export of process

definition data at the level of individual process definitions and packages.

The internal interface between the repository and control functions is specific to individual vendor products and does

not form part of this standard. It is assumed that separation is provided (for example by version control) between

repository usage as a static repository (for persistent, ongoing storage of process definition data) and any dynamic usage

(for managing changes to the process execution of extant process instances).

The local storage structure of the process definition repository is not part of the WfMC standard. The use of a package

is defined only as an aid to simplify the import/export of reusable data structures. Where a simple process repository

structure is used, operating at a single level of process definition, shared information within an imported package may

be replicated into each of the individual process definitions at the import interface (and similarly repacked, if required,

for process definition export).

6.2.1.1. Redefinition and Scope

The possibility of redefining attributes and meta-model entities and referencing external packages introduces the

principles of scope and hierarchy into the XPDL (and process repository) structures.

(i) Relevant data field

Process relevant data field has a scope that is defined by the directly surrounding meta-model entity and is

not nested. The visibility of its identifier is also defined by that entity.

(ii) Attributes

Attributes including extended attributes have a scope that is defined by the directly surrounding meta-

model entity and are nested, i.e. may be redefined at a lower level. Example: The name attribute is

redefined in each entity definition. The visibility of extended attribute identifiers is within the particular

entity and all sub-entities unless the identifier is redefined in a sub-entity.

(iii) Participants and applications

Participants and applications have a scope and visibility equivalent to extended attributes. All referenced

relevant data field and extended attributes have to be defined in the scope where they are used, at least in

the same package.

For a referenced external package entity that needs itself reference to entities and their identifiers defined in its external

package clause the mechanism is started with the root in that package. That guarantees that no conflict takes place if the

invoking process has an entity with the same id, which the definer of the referenced package cannot be aware of.

The described mechanism of external package provides high flexibility for designers and administrators. One can

separate organization descriptions (participant entities) and process definitions in separate models, one can add a new

release of a process description or add a new process definition sharing the rest of the definition of previously defined

and exchanged models without resubmitting the whole context etc.

Workflow Management Coalition Process Definition 10 October 2008

6.4. Entities Overview

The meta-model identifies the basic set of entities used in the exchange of process definitions. The top-level entities are

as follows:

6.4.1. Swimlanes

Swimlanes are used to facilitate the graphical layout of a collection of processes and the activities they contain. They

may designate participant (see section 7.4.1) information at the process level and performer information at the activity

level. The Swimlane structure is depicted by a collection of non-overlapping rectangles called Pools. Each Pool may be

further subdivided into a number of Lanes.

Figure 6.3: Swimlanes

6.4.1.1. Pool

A Pool acts as the container for flow objects (activities) and Sequence Flow (transitions) between them. The Sequence

Flow may cross the boundaries between Lanes of a Pool, but cannot cross the boundaries of a Pool. The interaction

between Pools is shown through Message Flow.

Another aspect of Pools is whether or not there is any activity detailed within the Pool. Thus, a given Pool may be

shown as a ―White Box,‖ with all details exposed, or as a ―Black Box,‖ with all details hidden. No Sequence Flow is

associated with a ―Black Box‖ Pool, but Message Flow can attach to its boundaries.

A Pool with flow objects and Sequence Flow contains a Process. An attribute of the Pool identifies the contained

Process. (This attribute is null if the Pool is a ―Black Box‘). The flow objects and Sequence Flow are in that Process,

See Process Definition in sections 6.4.2 and 7.5.

Each page of the diagram is regarded as an invisible ‗background pool‘. Activities and sequence flow not within an

explicit Pool are treated as contained by the background pool. Some implementations may not support multiple

background pools.

6.4.1.2. Lane

Lanes are used to subdivide a Pool. All the activities within a Lane may inherit one or more properties from the Lane. A

typical use of this is to give the Lanes ‗role names‘ and have the Activities inherit these role names as ‗Participant

assignment/Performer expressions‘.

6.4.2. Process Definition

The Process Definition entity provides contextual information that applies to other entities within the process. It is a

Workflow Management Coalition Process Definition 10 October 2008

container for the process itself and provides information associated with administration (creation date, author, etc.) or to

be used during process execution (initiation parameters to be used, execution priority, time limits to be checked, person

to be notified, simulation information, etc.). Note that a BPMN Business Process Diagram (BPD) contains multiple

processes.

6.4.3. Process Activity

An internal process consists of one or more activities, each comprising a logical, self-contained unit of work. In

addition, special activities, referred to as routing activities or Gateways, are used to implement decisions that affect the

Sequence Flow path through the process. Special activities, referred to as Events, affect when activities happen and

what routes are taken.

A typical activity represents work, which will be performed by a combination of resource (specified by performer

expressions) and/or computer applications (specified by application assignment). Other optional information may be

associated with the activity such as information on whether it is to be started / finished automatically by the process or

workflow management system or its priority relative to other activities where contention for resource or system services

occurs. Usage of specific relevant data field items by the activity may also be specified. The scope of an activity is local

to a specific process definition (although see the description of a subflow activity below).

Note that many of the details about activities are needed only in an execution environment. BPMN diagrams can be

drawn and interchanged between design tools without including these details.

In addition to Applications, an activity may be implemented as one of a number of built-in BPMN tasks. Their attribute

details are discussed in section 7.6.5.3. BPMN diagrams do not require the use of Applications.

An activity may be a subflow - in this case it is a container for the execution of a (separately specified) process

definition, which may be executed locally within the same service, or (possibly using the process interoperability

interface) on a remote service. The process definition identified within the subflow contains its own definition of

activities, internal transitions, resource, and application assignments (although these may be inherited from a common

source). In- and out-parameters permit the exchange of any necessary relevant data field between calling and called

process (and, where necessary, on return). Such definitions are equivalent to BPMN Reusable subprocesses.

An activity may be a block activity that executes an activity set, or map of activities and transitions. Activities and

transitions within an activity set share the name space of the containing process. An activity set is equivalent to a

BPMN embedded subprocess.

An activity may be a route activity, which performs no work processing (and therefore has no associated resource or

applications), but simply supports routing decisions among the incoming transitions and/or among the outgoing

transitions. BPMN gateways are represented by Route activities.

Finally, an activity may represent a BPMN event. An event is something that ―happens‖ during the course of a business

process. These events affect the flow of the process and usually have a cause (trigger) or an impact (result). There are

three types of Events, based on when they affect the flow: Start, Intermediate, and End. Their attribute details are

discussed in section 7.6.4.

BPMN provides a specific graphical representation for the different activities:

Figure 6.4: Activities

6.4.4. Transition Information

Activities are related to one another via flow control conditions (transition information). Each individual transition has

three elementary properties, the from-activity, the to-activity and the condition under which the transition is made.

Transition from one activity to another may be conditional (involving expressions which are evaluated to permit or

inhibit the transition) or unconditional. The transitions within a process may result in the sequential or parallel operation

剩余216页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

ImmortalII

粉丝: 0

XPDL 2.1规范详解 - XML流程定义语言

XPDL 2.1白皮书

XPDL 2.1 SPEC

XPDL的规范和学习整理

xpdl 2.0 规范中文word版

XPDL规范中文版标准

xpdl和bpel规范文档.rar

XPDL学习英文资料

XPDL2.0规范中文翻译：XML过程定义语言

XPDL2.0规范详解：工作流管理联盟XML过程定义

XPDL 2.0 规范中文版：工作流管理联盟过程定义语言

最新资源