CHAPTER 7: BUSINESS PROCESS SPECIFICATION AND REGIS TRATION
7.2 B USINESS P ROCESS S PECIFICATION
7.2.1 Business Process Definition Language
The BPDL is an XML-based language that enables the specification of complex VE business processes. The BPDL provides all the necessary mechanisms to describe complex processes and relationships among them. Each step within a process is a special business goal that an autonomous, intelligent agent undertakes the responsibility to execute and manage when specialised conditions are satisfied.
The basic syntactical elements of the Business Process Definition Language are:
• Business Process, a description of the sequence of steps to be completed in order to accomplish a business goal. A business process has a name, a set of input and output parameters, and special start pre-conditions. A process consists of one or more sub-processes,
• Sub-process, or each step within a process. A sub-process has a name, a set of input and output parameters, and start pre-conditions. With these elements, every sub-process specifies the flow of data and the flow of control. The flow of data, specified through the input/output parameters between activities, is a series of mappings between output data and input data to allow activities to exchange information. Actually, the output parameters of one process can be input parameters of another process. The flow of control, specified by special logical conditions assigned to the sub-processes or atomic processes, is actually the order in which activities are being scheduled and executed. A sub-process consists of one atomic process or one or more sub-processes. A sub-process can be either local, when the current domain can execute the whole sub-process, or remote, when the execution of the sub-process can be performed by another domain. Sub-processes are used for nesting and modular design and reusability reasons.
• Atomic process has a name and a business object assigned to it that will be deployed when the atomic process is executed. The atomic process passes to the external business object the input data, waits for the execution of the business object, collects the output data, and finally sends them back to the workflow system. The atomic processes are computational elements, i.e. they provide special elementary operations into the business process. The atomic process has always a well-defined functionality and is always associated with an external business object.
• Input Parameters: a sequence of typed variables and structures that are used as input to the invoked activities. An input parameter has a name, a basic type like string, integer, etc. and constraints which associate parameters with certain values. During process specification time, the input parameters have only default values and optional constraints associated to them.
• Output Parameters: a sequence of typed variables and structures denoting the output of an invoked sub-process or atomic process. An output parameter, in a similar way like the input parameters, has a name, a basic type like string, integer, etc. and constraints which associate parameters with certain values. During process specification time, the output parameters have only default values and optional constraints associated to them.
• Conditions, which specify the circumstances under which certain events will happen. When a condition becomes true then the corresponding sub-process should start its execution.
Conditions can be either atomic or composite.
• Atomic Conditions are simple logical expressions formed among an input or output parameter, a binary comparison operator and a value. The comparison operators might be >,
<, >=, <=, =,etc.
• Composite Conditions are complex logical expressions formed in terms of atomic conditions and logical operators such as AND, OR, or NOT. The BPDL also enables the specification of conditions on an existing condition specification language, like the JESS language or OMG Constraint Language. These conditions are computed based on several standard third party conditions checkers included into the agents.
• Business Obje ct: is any type of external object that can be accessed either locally or remote through Java RMI or CORBA-IIOP. It is the responsibility of the atomic process to deploy and integrate the business into the business process specification.
The following picture depicts the relationships among the different entities of the BPDL.
B u s i n e s s O b j e c t s
P a r a m e t e r s n a m e t y p e v a l u e c o n s t r a i n t A t o m i c C o n s t r a i n t s
p a r a m e t e r o p e r a t o r v a l u e
C o m p o s i t e C o n s t r a i n t s e q u e n c e _ a t o m i c
B u s i n e s s P r o c e s s n a m e
i n p u t P a r a m e t e r s o u t p u t P a r a m e t e r s p r e C o n d i t i o n
C o n s t r a i n t n a m e 1
1 1
1
1
1
1
1
A t o m i c p r o c e s s e s n a m e
c o n s t r a i n t
1 1 1 1 1
1 1
1
I n p u t P a r a m e t e r s 1
1
1
1
0 . . * 1
0 . . * 1
S u b P r o c e s s n a m e
i n p u t P a r a m e t e r s o u t p u t P a r a m e t e r s p r e C o n d i t i o n l o c a l O R r e m o t e
1 . . *
1
1 . . *
1
0 . . * 1
0 . . * 1
1
1 1
1 1 1
0 . . * 1
O u t p u t P a r a m e t e r s 1
1
1 1
0 . . * 1
0 . . * 1
0 . . * 1 1
0 . . *
1
0 . . *
Figure 36: Business Process Definition Language Class Model
The specification of the business process definition language in XML-DTD format is the following. This specification is actually a direct translation of the model presented in Figure 36.
<!-- Entry point for business process definition in XML -->
<!ELEMENT business-process-definition (process-definition | condition-definition | parameter-condition-definition)*>
<!-- Generic class for representing a business process definition -->
<!ELEMENT process-definition (process-name, comment?, in-data*, out-data*, (atomic-process | composite-process))>
<!ELEMENT process-name (#PCDATA)>
<!ELEMENT atomic-process (external-task-name)>
<!ELEMENT external-task-name (#PCDATA)>
<!ELEMENT composite-process (composite-process-element+, exception-handling-process-element*)>
<!ELEMENT composite-process-element (precondition-name?, sub-process-name, time-allowed-to-complete?, (is-remote | to-be-negotiated)?, in-data*, out-data*)>
<!ELEMENT exception-handling-process-element (exception-source+, sub-process-name, time-allowed-to-complete?, (is-remote | to-be-negotiated)?, in-data*, out-data*)>
<!ELEMENT precondition-name (#PCDATA)>
<!ELEMENT exception-source (#PCDATA)>
<!ELEMENT sub-process-name (#PCDATA)>
<!ELEMENT is-remote EMPTY>
<!ELEMENT to-be-negotiated EMPTY>
<!ELEMENT in-data (#PCDATA)>
<!ELEMENT out-data (#PCDATA)>
<!ELEMENT time-allowed-to-complete (#PCDATA)>
<!ATTLIST time-allowed-to-complete
unit (seconds | s | minutes | m | hours | h | days | d) #REQUIRED trials CDATA "1">
<!-- Generic class for representing a condition definition -->
<!ELEMENT condition-definition (condition-name, comment?, (atomic-condition | composite-condition))>
<!ELEMENT condition-name (#PCDATA)>
<!ELEMENT rule (rule-language, rule-body)>
<!ELEMENT rule-language (#PCDATA)>
<!ELEMENT rule-body (#PCDATA)>
<!ELEMENT composite-condition (is-not?, (is-or | is-and), branch-condition-name+)>
<!ELEMENT is-not EMPTY>
<!ELEMENT is-or EMPTY>
<!ELEMENT is-and EMPTY>
<!ELEMENT branch-condition-name (#PCDATA)>
<!ELEMENT atomic-condition (((is-not?, process-status?) | rule), external-condition-name)>
<!ELEMENT process-status (process-name)>
<!ATTLIST process-status process-state (running | notStarted | suspended | aborted | terminated | completed) #REQUIRED>
<!-- Generic class for representing parameter definition -->
<!ELEMENT external-condition-name (#PCDATA)>
<!ELEMENT parameter-definition (parameter-name, comment?, parameter-type, parameter-value)>
<!ELEMENT parameter-name (#PCDATA)>
<!ELEMENT parameter-type (#PCDATA)>
<!ELEMENT parameter-value (#PCDATA)>
<!ELEMENT comment (#PCDATA)>
The above provided business process definition DTD and an example business process definition are provided at the end of the thesis on the ANNEX.
The BPDL has been defined for the purposes of dynamic VEs. During specification time, each process can be specified either as local or remote. A process is considered local when the specification of this process exists fully in this domain. On the contrary, a process is considered remote, when the specification and execution of this process can be provided only by another domain. This is achieved by the setting of a special flag called isRemote. When a sub-process has been specified as remote, then the corresponding flag isRemote has been set to true.
Otherwise, if the process is not considered remote, then it is local, and in that case the execution and management of the sub-process will be done within the same domain.
The BPDL has been specified in XML-DTD while the specification of each process is done in XML. This design choice has four very serious consequences. The main reason is that the
extension of the language can be easily performed due to the dynamic capabilities of the XML.
Additionally, the specification of processes is done in XML, which is simple ASCII text, and thus, the business process descriptions are ASCII text files that can be easily stored in any conventional file system. Furthermore, XML is an open standard that most of the emerging systems and especially agent-based ones will in the near future support. And finally, a business process definition parser in XML can be easily developed due to the existing commercial support of XML parsers.
The Business Process Definition Language supports increased re-usability and modular design.
This is achieved due to the call by name concept. This means that existing business process specifications can be easily used in other process specifications by only referring to the name of the process, sub-process, or atomic process. For example, if there is a sub-process called
“find_book”, that has been specified within one process A, then this sub-process is specified only one time and its name can be used to represent the specification of this sub-process in different other processes, though the specification of the sub-process has been done in another process. This means that process specifications can easily include references to other processes.
In this way, high degree of reusability and modularity is achieved. This concept leads directly to reusability of process specification building blocks. In a similar way like the middleware services, processes can be built by combining existing business process specifications. This reduces significantly the business process specification costs and increases the degree of flexibility of the specified processes.