Business Process Repository

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.

For all local business processes specified in this domain the corresponding XML file name is specified. An example of the business.xml file, that contains two processes, namely Process1 and Process 2, is given:

<?xml version="1.0"?>

<!DOCTYPE BUSINESS-CONTROL SYSTEM "Business.dtd">

<BUSINESS CONTROL>

<BUSINESS>

<NAME>Process1.xml</NAME>

</BUSINESS>

<BUSINESS>

<NAME> Process2.xml </NAME>

</BUSINESS>

</BUSINESS-CONTROL>

Initially, the BPR reads and interprets the business.xml file. The BPR locates all the files of the currently specified business process specifications, opens the specification files, reads the specifications in XML, produces the Definition Model for each process, and creates the List of Business Process Specification (LBPS). The LBPS is actually the list of all DMs, i.e. business processes that can be provided by this domain. Access to this list is done through the names of the business processes that uniquely identify a business process specification.

The Definition Model (DM) is an object-oriented representation of the business process specification. The DM contains actually the relationships of different processes, sub-processes, atomic processes and conditions and consists of the following modules:

• process definition: provides the operations for the retrieval and setting of the appropriate elements of a process, like set and get input/output parameter, set and get external task, or set and get sub-processes. One of the key methods is the createInstance that enables the creation of an instance of this process. The Workflow Provider Agent (WPA) uses this method to create a new instance of the process (see Workflow Provider Agent (WPA) section in next chapter).

• Sub-process definition: provides operations for the retrieval and setting of the appropriate elements of a sub-process, like set and get input/output parameter, set and get atomic process, set and get sub-processes. This is actually what the Workflow Provider Agent uses to locate the sub-processes of a process and execute them recursively.

• process condition definition: provides operations for the retrieval and setting of the appropriate elements related to the conditions of a process or sub-process like the logical expressions of the conditions.

The following Figure 37 depicts the class model of the DM, the key operations that the different modules provide and the relationships that they have.

0..*

1 1 0..*

1 1

ProcessDefinition createInstance() : ProcessInstance getName() : String

getExternalTaskName() : String

getSubprocessDefinitions() : SubprocessDefinitionCollection getIndataNames() : StringCollection

getOutdataNames() : StringCollection

ProcessConditionDefinition

createInstance(subprocess : SubprocessInstance) : ProcessConditionInstance isNot() : Boolean

setNot(bool : Boolean) : void isAnd() : Boolean isOr() : Boolean setOr(bool : Boolean) : void getExternalConditionName() : String getRuleBody() : String

SubprocessDefinition

createInstance(parentProcess : ProcessInstance) : SubprocessInstance getProcessDefinitionName() : String

isRemote() : Boolean

getPreconditionDefinition() : ProcessConditionDefinition getIndataNames() : StringCollection

getOutdataNames() : StringCollection BusinessProcessRepository

getProcessDefinition(processDefinitionName : String) : ProcessDefinition addProcessDefinition (processDefinitionName : String)

removeProcessDefinition(processDefinitionName : String)

Figure 37: Process Definition Class Model

When a particular business process with a particular name is requested for execution, the BPR searches the LBPS, locates the Definition Model for this process and returns it back to the agent that requested the process. The agent, based on the DM, can create an instance of the process, can find all the sub-processes and atomic processes, and can get all the conditions associated with a particular sub-process. More details regarding how the DM is deployed during the instantiation, execution and management of a process are provided in the Workflow Provider Agent section.

The main operations of the BPR are provided to the Business Process Analyst (BPA) in a manual way. When the BPA wants to specify a new business process, it uses the BPDL and writes manually in a XML file the specification of the process including all the necessary elements like sub-processes, input and output parameters, and conditions. During the specification phase, the BPA can reuse existing specifications of processes and sub-processes that have been previously specified in other specifications. It is assumed that the BPA has a thorough understanding of the syntax and the grammar of the BPDL. Then, the BPA updates the configuration file of the existing business processes, i.e. the business.xml, by declaring the newly specified process. In a similar way, when the BPA wants to modify an existing business process, it opens the corresponding XML file of the business process specification and makes the appropriate modifications. Changes to the configuration file, namely the business.xml, are not required since the process has been already registered. The BPR will automatically get the modified specification of the process and put it into the LBPS. Finally, when the BPA wants to delete a business process specification, he only needs to delete the name of the process from the corresponding configuration file. Optionally, the BPA can also delete the XML specification file from the file system. If the deleted process specification is referenced by name by other processes, then inconsistencies will occur. In that case, the BPA is responsible for modifying the process specifications accordingly to avoid the problem.

In the following sections, the relationship of BPR with the execution of the business processes and the workflow engine are provided.