A cross organisation compatible workflows generation and execution framework

With the development of the Internet, the demand for electronic and online commerce has increased. This has, in turn, increased the demand for business process automation. In this paper, we look at the use of workflows for business process automation. An automatically generated workflow can save time and resources needed for running online businesses. In general, due to the interdependencies between their activities, multiple business organisations will need to work together by collaborating and coordinating their activities with each other. This gives rise to the need for workflow collaboration across organisations. Current systems for workflow collaboration are only capable of reconciling existing workflows of the collaborating organisations. Automatic workflow generation systems only generate workflows for individual organisations and cannot handle the automatic generation of compatible workflows for multiple collaborating organisations. To overcome this problem, in this paper, we present a framework that is able to generate multiple sets of compatible workflows for multiple collaborating organisations. The proposed framework supports runtime enactment and runtime collaboration of the generated workflows. This framework enables users to save the time and resources that would otherwise be spent in modelling, reconciling and reengineering workflows.


Introduction
A Business process can be defined as "a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships" (Workflow Management Coalition, 1999). It means that a business process is essential for the business goals of organisations. Workflow is the technology used to model automated business processes. According to Workflow Management Coalition's definition, a workflow 1 is "the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules" (Workflow Management Coalition, 1999). A workflow has two main stages (Workflow Management Coalition, 1999):  Build-time stagethis refers to the stage where workflow descriptions of the business process are defined or changed. This can be automatic or manual.
 Execution stagethis is where instances of the business process are created, executed and managed. This is the operational stage.
In the real world, organisations have to interact with other organisations to do business. For any two organisations to proceed in business, they need to have compatible workflows and compatible means that there should be an agreed sequence of activities exchanging collaborative messages and information . The point where exchange of collaborative messages and information takes place between two collaborating workflows is called an interface activity. An interface activity can be a sending activity or a receiving activity. The set of all interface activities in a workflow is called interface process . The proposed framework uses the idea of interface activities for collaboration among the interacting organisations. Interface activities decouple the collaborating workflows. A receiving activity only has to know the details of the corresponding sending activity and does not need the representational details of the entire collaborative workflow.
When two of more organisations do business together, the need for workflow collaboration across multiple organisations arises (Chen and Chung, 2007). Such collaboration is referred to as cross organisational workflow collaboration. Incompatible workflows should be reconciled before proceeding with business. Considerable amount of effort is needed to ensure that workflows are compatible (Chiu et al., 2004;Schulz and Orlowska, 2004) and proceed into the execution stage.
Recent research on workflow collaboration focuses on reconciling existing incompatible workflows (Krukkert, 2003;Chen, 2008). This is a bottom-up approach. In an alternative topdown approach, organisations meet, discuss and design collaborative processes and then implement them (Chen and Chung, 2007). Both of these approaches are time consuming, especially, if an organisation has many business partners to collaborate with. Every time an organisation has to collaborate with another organisation, both the organisations will have to invest a lot of time and resources to come up with compatible workflows. In case of any change to the workflow of an organisation, negotiations may have to be done all over again with all the collaborating organisations.
Another paradigm in the literature is automatic workflow generation, which is based on AI planning where a workflow is considered as a plan (Chen and Yang, 2005;Dong and Wild, 2008). If every activity in a workflow is treated as a web service, a workflow represents a plan of web services to achieve the desired goal state from a given initial state (Saleem, 2012). Web services are self-contained units of application logic (Srivastava and Koehler, 2003), which can be can be discovered, connected to and executed over the internet.
Therefore workflow generation can be treated as a web services composition problem (Dong and Wild, 2008). In web services composition, a planner reasons about a pool of available services and the service that can bring about the desirable effect is added in the plan.
Executing the plan will result in the goal state (Chen and Yang, 2005).
In web service composition, the planning system requires formal domain ontology for planning. Domain ontology refers to the formal representation of the environment where planning takes place (Chen and Yang, 2005). A web service composition environment is primarily a collection of web services, so the domain ontology is in the form of web services descriptions (Saleem, 2012).
Existing automatic workflow generation systems automatically generate workflows for single organisations only and cannot generate compatible workflows for multiple collaborating organisations Okutan and Cicekli, 2010). The proposed framework automatically generates compatible workflows for multiple collaborating organisations to meet their high-level goals, without the organisations having to model their workflows beforehand.
As the proposed framework independently generates compatible workflows for each collaboration scenario among collaborating organisations, the organisations do not have to worry about keeping their workflows compatible with the other organisations they interact with. Unlike the approach presented in this paper, in both manual and automatic workflow collaboration negotiations, the organisations have to change their workflows in such away that it becomes compatible with the workflow of the negotiating organisation and at the same time remains acceptable to the existing organisations it is interacting with. Thus the proposed framework eliminates the need for the time consuming negotiations that might otherwise have been necessary to reconcile incompatible workflows.
The framework uses SHOP2 for planning because SHOP2 supports complex domains, extended goals and non-deterministic actions (Peer, 2005). Furthermore, it is a highly efficient planning system and has a Web Ontology Language for Services (OWLS) type mechanism for representing atomic tasks and decomposing composite tasks into atomic tasks . The similar mechanism of OWLS and SHOP2 to hierarchically decompose complex tasks into sub tasks makes it straightforward to map OWLS definitions directly into SHOP2 domain Wu et al., 2003) and create workflows based on the translated domain. SHOP2 is a hierarchical task network (HTN) planner. It requires domain knowledge for planning. The OWLS web services descriptions can be translated to create the SHOP2 domain. The SHOP2 domain consists of operators and methods. Operators are atomic tasks that can be executed directly. Methods are specifications to decompose complex tasks into atomic tasks. SHOP2 is a substantially expressive planner . The expressivity of SHOP2 is similar to Planning Domain Definition Language (PDDL) . In the context of semantic web services, PDDL is neither too restrictive nor too expressive and is considered as a viable compromise between expressivity and efficiency (Peer and Vokovic, 2005). It uses a restricted subset of first order logic to describe the semantics of operations. SHOP2 supports logical connectives such as conjunction, disjunction, implication, negation and universal quantification to combine logical atoms.
SHOP2 supports the evaluation of arbitrary code at planning time through complex precondition reasoning. This makes it possible to integrate existing knowledge bases on the semantic web into SHOP2 domain .
Business Process Model and Notation (BPMN) language is the most widely used standard to represent workflows (Meng et al., 2012). It defines the notation and semantics of business processes (OMG, 2011). It is a workflow modelling language (OMG, 2011) and lacks the semantic precision required for automatic business process generation and execution (Ouyang et al., 2008), and so we cannot use it as a notation for the proposed framework. Automatic workflow generation can be achieved by exploiting web services composition. OWLS is a language for describing web services (OWL Services Coalition, 2003). It is used to describe the functionality, access point, execution mechanism and compositional capabilities of web services. In OWLS, each service is modelled as a process . A process can be atomic, simple or composite. OWLS is a set of ontologies and OWLS process ontology describes web services composition based on 'action' or 'process' metaphor. It describes simple tasks as simple actions or simple processes and complex tasks as composite actions or composite processes. This similar way of modelling makes it possible to translate OWLS web services descriptions to SHOP2 domain .
In the rest of the paper, section 2 outlines the related work. Section 3 discusses the assumptions made for the proposed framework. Section 4 gives the general architecture of the framework. Section 5 presents the functionality of the framework and explains the major algorithms involved. Section 6 discusses implementation details. Section 7 describes application examples and Section 8 discusses the paper and highlights future work.

Related Work
Most of the existing work on cross organisational workflow collaboration in the literature deals with build time collaboration. Van-der-Aalst and Weske (2001) applied a three step Public-to-Private approach to inter-organisational workflows. In the first step, the partner organisations agree on a common public workflow; in the second step, the common public workflow is divided between the interacting organisations; and in the third step, the organisations create their private workflows autonomously. This approach requires manual negotiations to reach an agreement, which can be very time consuming especially if there are many partners. Krukkert (2003) proposed a solution in the openXchange project. Two activity diagrams are taken as input and compared to find out all common execution sequences. If any common sequence is found then a common activity diagram is constructed for collaboration. For the solution to work, there must be a common activity sequence in the workflows or activity diagrams of the participating organisations. If a common sequence is not found, then collaboration cannot proceed, which is a limitation of the system. In such cases, manual changes need to be done to the activity diagrams in order to introduce a common sequence path. Alternatively, a third party collaboration system is required to bring about collaboration.
Both cases undermine the benefit of using Krukkert's soloution. Chen (2008) presented an approach for reconciling existing workflows to bring about compatibility. A software collaboration agent extracts the interface processes from two workflows that are intending to work together and gives an offer to a candidate provider, which evaluates the offer and creates a counter-offer. The partner then either accepts or rejects the offer. The process of offer generation, counter-offer generation, acceptance and rejection goes on recursively till the negotiation is terminated or reconciliation is achieved.
Since workflows need to be executed, there needs to be runtime collaboration so that the transfer of files and information happens smoothly among the in-house and cross organisational activities. Chen and Chung (2006) presented a bottom-up cross organisational workflow enactment approach. The approach is workflow management system (WfMS) independent and the enactment is done via progressive linking enabled by runtime agents.
Each interaction point in the collaborating workflows is modelled as interface activity and agents make sure that outgoing data and incoming data are delivered to the corresponding activities accordingly. A form filling approach is used to ensure this. The form represents the progress of interoperation and can be used for historical record.
With the increase in demand for reusability and interoperability, research has considered composing web services into composite services to automatically generate business processes. Sirin et al. (2003) created a semi-automatic web services composition system, which allows users to select from a list of web services at each step of composition. The user starts the composition process by selecting one of the services registered with the system. The system then checks for web services that can satisfy the selected service, presents them to the user and the user selects one to add in the plan. The system then checks for web services that satisfy the next requirement. The process continues until the composition completes.
Later,  extended their semi-automatic web service composition system to a fully automatic system. They implemented an OWLStoSHOP2 translator to translate collections of OWLS process definitions into SHOP2 domain. The SHOP2 planner then uses the created domain to produce a valid plan according to the constraints entered by the user and imposed by the relevant web services. The generated SHOP2 plan is converted to OWLS format by a plan converter called SHOP2toOWL, and executed by the Execution System. A limitation with this system is that it plans for a single organisation only and does not take collaboration among multiple business organisations into account. Okutan and Cicekli (2010) proposed an event calculus based web service composition and execution (WSCE) system. The system has two phases, namely composition phase and execution phase. In the composition phase, the OWLS process definitions are translated to axioms in event calculus domain. Web services are encoded as actions, web service inputs and outputs as action's knowledge preconditions and knowledge effects, and web service preconditions and effects as action preconditions and effects. The user inputs are substituted as initial condition axioms and the outputs as goals. Based on the domain knowledge, the Abductive Event Calculus Planner generates plans to reach the given goal state. The plans are presented to the user in the form of visual graphs, which can be sorted according to user's quality of service parameter among execution duration, price, reliability and availability. In the execution phase, the selected graph is transformed to OWLS descriptions and passed to the execution engine. The user enters the actual input values, and the actual web services modelled by the OWLS processes are invoked.
WSCE is a good effort to use event calculus for web service composition. The main benefit of this system is that it supports concurrent plans and so it is better suited for solving real world business scenarios. The main issue with this system is that it can compose workflows for a single organsisation only and does not take the generation of collaborative workflows for multiple organizations into account. The work, if extended for solving multi-organisation scenarios, can be a good addition to research.
Recently, there has been some work on composing workflows for multiple organisations. Chen et al. (2011) suggested a Pi-Calculus based approach to compose web services into cross organisational business processes. A cross organisational business processes is modelled as a set of concurrent local processes, which has a global start and a global end activity. The activities in the local processes can receive external start messages. A cross organisational controller controls the flow of control and data in the cross organisational process. The limitation with this work is that it uses a manual modelling approach and the web services composition is not automatic.
Correˆa da Silva et al. (2013) presented a lightweight, flexible and user-friendly platform for cross organisational workflow interactions. The platform is named JamSession and it can be considered as a meeting point for already existing software components to form new and innovative service systems. JamSession is a user-friendly and light-weight platform, providing an appropriate framework to specify and implement cross organisational workflow interactions. It uses knowledge-based interaction protocols and predicates to models cross organisational workflows and activities in such away that the workflow definitions are local to the respective workflow management systems, and only the interaction protocols are made public. It makes the workflows highly decoupled. While the paper claims that the interaction protocols can be used to specify and execute cross organisational workflows, it only shows examples for the execution of cross organisational workflows. So, it is not possible to deduce whether the interaction protocols can be used for bringing about collaboration among cross organisational workflows at build time.
Problem Solving Methods (PSMs) (Crubezy, 2003) is another area that has a conceptual resemblance to web service composition, due to its focus on reusable domain-independent reasoning about ontologies (Elenius, 2004). In PSMs, the properties of a method can be specified as a method ontology. With the help of mapping ontologies, the inputs and outputs of the PSM can be connected to the entities in the ontologies of different domains. The use of the idea of PSM and mapping ontologies can be interesting in web services composition domain.

Assumptions
To define a starting point and clear context for the proposed framework, the following assumptions have been made.
1. It is assumed that the collaborating organisations follow OWLS ontology for services, as OWLS is the most widely used standard specification for adding semantics to web services (Dong and Wild, 2008). OWLS provides a standard set of ontologies to the collaborating organisations for describing and composing web services. Apart from the service ontology, the collaborating organisations only need to follow the same domain ontology for the inputs/outputs/preconditions/effects that are not local to a single organisation and are used by multiple collaborating organisations.
2. Collaborating organisations can pass atomic, simple or composite OWLS processes to the proposed framework. Atomic process represents a single-step directly executable web service; simple process is an abstraction of an atomic process or a composite process; composite process represents a compound web service, which can be decomposed into atomic web services. Composite processes are assumed to have a complete decomposition into atomic processes. Such composite processes are executable. The effects and outputs of the processes are assumed to be unconditional.
It is assumed that all atomic services in the workflows will execute without failure.
3. It is assumed that during workflow generation and execution, the world does not change as a result of the actions of another agent and the initial state contains all the necessary information of the domain for the planning to be done. It is assumed that the services are readily available for execution and are always executable.
4. The collaborating organisations are required to know the input preconditions, outputs and effects of each other's corresponding interface activities so that compatible workflows could be generated and collaboration could be carried out at runtime among the sending and receiving processes. An interface activity can be a sending activity or a receiving activity. In this paper, an activity name followed by "_s" or "_r" means it is a sending or receiving activity respectively.

5.
To ensure maximum usability of the framework, it is assumed that arbitrary number of organisations can collaborate with each other. This assumption is in line with the real world business environment in which more than two organisations can collaborate simultaneously, e.g. in a Vendor/Customer/Supplier scenario three organisations need to collaborate together. Figure 1 shows the general architecture of the proposed cross organisation compatible workflows generation and execution framework. Although there can be more than two collaborating organisations, for clarity the figure only depicts two. The framework requires OWLS process definitions and high-level goals from collaborating organisations as input.

Architecture
As shown in Figure 1, the collaborating organisations pass their OWLS process definitions and high-level goals to the Collaboration and Workflow Generation Manager (CWGM). The CWGM loads the processes and passes the process definitions to OWLStoSHOP2 Translator, which translates them into SHOP2 domain descriptions. OWLStoSHOP2 Translator also translates high-level goals into a SHOP2 problem. Preplanning analysis of the domain and the problem is done so that operators and workflows of the collaborating organisations can be tracked. CWGM identifies operators in the domain that can enable the creation of multiple plans. Based on identified operators, methods are inserted into the domain description to ensure the creation of multiple plans. The inserted methods are used by SHOP2 to identify alternate composition paths, and hence to create multiple plans.

Figure 1 Architecture of the Proposed Framework
The CWGM can be present on a central system or one of the collaborating organisations. It is assumed that all the collaborating organisations agree to provide the path to their process definitions to CWGM. The workflow generation process needs to be repeated for every set of collaborating organisations. This is necessary because the atomic processes of the collaborating organisations and the services modelled by the atomic processes can be outside the boundaries of the collaborating organisations and their availability can change anytime.
So, the generated workflows are always based on the available atomic processes that can be actually enacted. As the workflow generation process is purely automatic and based on process definitions, it will not create an explosion of interaction modalities among the collaborating organisations. Once the process descriptions are specified, the workflow generation process is extremely quick as compared to workflow negotiation process; so this must not be a concern for the collaborating organisations.
In order to avoid planning against a huge number of irrelevant services, the framework discards the irrelevant processes from the set of loaded processes to make sure that they are not translated to SHOP2 format or used in the planning. This approach saves time. The relevance of web services for workflow generation is decided on the basis of their outputs and effects and it is achieved by a recursive checking algorithm.

Functionality
The developed framework takes OWLS process definitions of the collaborating organisations as input, reads the process definitions, translates them into HTN format, merges the domains together, creates multiple sets of compatible workflows and executes the selected set of compatible workflows. The framework presented in the paper is closely related to the system proposed by . The work presented in this paper extends the application of AI planning to workflow generation as well as workflow collaboration. Below are some of the major extensions and improvements the proposed framework makes to the approach taken by Sirin et al. for workflow generation. 1. Their system considers automatic workflow generation for a single organisation only.
They do not focus on workflow collaboration among business organisations. The proposed framework integrates automatic workflow generation with cross organisational workflow collaboration and is capable of generating multiple sets of compatible workflows for multiple collaborating organisations. Similarly, collaboration is also supported at runtime.
2. They limit a service to either have outputs or effects. In real world, a service can have effects and outputs at the same time. The framework presented in this paper does not have this limitation.
3. Similarly, their system executes information-providing services (services with only outputs) at planning time to produce the required output. The developed framework does not execute web services at planning time. It is because a service can have both effects and outputs and executing a web service at planning time can have real effects on the world e.g. charging the credit card for a certain amount of money. 4. They look at web service composition as finding an execution path for already defined composite processes, which limits the automation of workflow generation by involving users to define composite processes. If atomic processes and goals of the collaborating organisations are fed up as single unit to Sirin's system, it will fail to generate any plan. To enable it to generate a plan, we will need to group the atomic processes in the form of a composite process. The framework presented in this paper looks at web service composition as automatically generating a composite process from the atomic processes and then specialising it to create an execution path for the composite process. The OWLS to SHOP2 translation mechanism of both systems are hugely different due to this reason.
The following sub-sections discuss the detailed functionality and present the algorithms involved at each step.

Translating OWLS Process Definitions to SHOP2 Domain Descriptions
Collaborating organisations can load their OWLS process definitions to the CWGM using an interactive GUI. The collection of OWLS process definitions of an organisation are loaded in the form of an OWL file or a single composite process importing the atomic, simple and composite processes of the organisation.
The OWLSReader module of the CWGM reads the OWLS process definitions included in the OWL file loaded through GUI. The initial states and goal states of the collaborating organisations can be selected from GUI. All processes are loaded from the OWLS process definitions. The loaded processes and their inputs, outputs, preconditions and effects are prefixed with organisation number for keeping track of the operators and workflows in the collaboration process. For example an atomic process PaymentCheck of the first organisation that loads its processes will be prefixed with Org1 and will become Org1PaymentCheck. The inputs, outputs, preconditions and effects of interface activities are not prefixed. This is because the outputs/effects of interface activities are used by the corresponding interface activities of other collaborating organisations.
The OWLStoSHOP2 Translator module translates OWLS process definitions into SHOP2 domain descriptions. OWLStoSHOP2 Translator also translates initial states and high-level goals selected from GUI into a SHOP2 problem. In order to translate OWLS processes into SHOP2 format, we propose the following algorithm.
The first step in the algorithm is to translate atomic processes into SHOP2 operators. Simple processes and composite processes are decomposed until they contain only atomic processes, which are subsequently translated into SHOP2 operators. The translated atomic processes are then grouped together in the form of an if-then-else method. The if-then-else method acts as the top-level composite process of the respective organisations. We present algorithms to carry out these tasks. The purpose of planning is to create an execution path for this automatically generated top-level composite process.
The Translate-Atomic-Process(Q) algorithm translates OWLS atomic processes into SHOP2 operators. It extends the translation algorithm put forward in , to translate atomic processes with both outputs and post-conditions. It takes a definition Q of an atomic process A as input and outputs a SHOP2 operator O.

Translate-Atomic-Process(Q)
Let Q be the definition of an atomic process A and O be a SHOP2 operator operators. This enables the presented framework to use web services that have both outputs and effects in workflow generation.
The Translate-Composite-Process(Q) algorithm translates an OWLS composite process into a set of SHOP2 operators. It takes a definition Q of a composite process C as input and outputs a set L of SHOP2 operators. It works as follows.

Translate-Composite-Process(Q)
Let Q be the definition of a composite process C and L be a set of SHOP2 operators.
The Translate-Composite-Process(Q) algorithm translates a composite process into a set of SHOP2 operators. It calls Translate-Atomic-Process(q i ) if its component process is an atomic process, to translate the component atomic process into a SHOP2 operator. If its component process is a composite or simple process, it calls Translate-Composite-Process(q i ) or Translate-Simple-Process(q i ) to translate it into a set of SHOP2 operators.
The translation algorithm described in  translates composite processes directly into SHOP2 methods as it looks at web service composition as finding an execution path for already defined composite processes. The proposed framework looks at web service composition as automatically combining atomic processes to form a composite process, for which an execution path can be found. This enables the proposed framework to automatically generate compatible workflows from atomic processes of collaborating organisations and enable the organisations to avoid the time consuming task of creating composite processes on their own.
The Translate-Simple-Process(Q) algorithm translates OWLS simple processes into a set of SHOP2 operators. It takes the definition Q of a simple process as input and outputs set L of SHOP2 operators.

Translate-Simple-Process(Q)
Let Q be the definition of a simple process S and L be a set of SHOP2 operators (b 1 , . . . , b n ) is the list of processes collapsing in S as defined in Q for i = 1, . . . , n If b i is an atomic process and q i is the definition of The Translate-Simple-Process(Q) algorithm translates a simple process into a set of SHOP2 operators. It checks each of its constituent processes and 1. calls Translate-Atomic-Process(q i ) for each atomic process to translate it into a SHOP2 operator, and 2. calls Translate-Composite-Process(q i ) for each composite process to translate it into a set of SHOP2 operators.
The basic focus of the implemented framework is to compose the atomic processes of the collaborating organisations into compatible workflows of OWLS services, capable of achieving the desired goal states from the initial states, as defined by the collaborating organisations. Unlike the discussed approaches Wu et al., 2003), the implemented framework is not focussed on finding an execution path for already defined composite processes. We believe that forming an execution path for an already built composite process limits the strength of workflow generation by limiting the automation. Therefore, the composite processes are decomposed to atomic processes and then the atomic processes are used to create a single SHOP2 if-then-else method to guide the composition process.
The collection of OWLS processes passed to CWGM is translated into a SHOP2 domain. The Translate-OWLStoSHOP2(P,G) algorithm that translates a collection of OWLS processes into SHOP2 domain is as follows. It takes a collection P of OWLS processes and a set G of goals states as input, and creates a SHOP2 domain D as output.

Translate-OWLStoSHOP2 (P, G)
Let P be a collection of OWLS processes, K be the set of definitions of OWLS processes in P, G is the conjunct of all goal states as specified by the organisation, M The Translate-OWLStoSHOP2(P,G) works as follows.
1. It translates each of the constituent processes of P into SHOP2 operators by calling the relevant algorithms. Unlike the proposed approach described above, the approach by  does not combine operators to form a method. This means that their system can generate workflows only if the user manually defines the composite processes and passes them to the system. The composite processes and atomic processes are passed to the system together, for translation into SHOP2 domain. Pre mi M i makes it a recursive expression and JBP will be called recursively by the planner until valid plans are found or the SHOP2 returns a failure.

Combining the Translated SHOP2 Domains into a Joint Domain
As the system proposed by  targets the creation of workflows for a single organisation only, it has a single SHOP2 domain to begin with. Therefore, they do not present any algorithm for collapsing the domains of multiple collaborating organisations into a single domain.

Planning for All Possible Sets of Compatible Plans
To plan for all possible sets of compatible plans, the SHOP2 needs to be extended in order to enable it to handle data inputs. During planning, the preconditions especially the ones representing data inputs will remain true in the entire lifecycle of the planning process until explicitly made false by an operator. If the atomic processes do not explicitly make their preconditions/inputs false, SHOP2 will keep repeatedly adding the first task list whose preconditions are true in the workflow. This will create an infinite loop. Similarly, if a precondition in the if-then-else method is true for which the task list is to decompose a method, the method will keep repeatedly getting decomposed into primitive tasks and the loop will continue infinitely. We extend the SHOP2 planning algorithm so that the same tasks are not repeatedly added to the workflow (plan) or selected for decomposition (see Figure 2).
The extended SHOP2 planner creates a set P = (P 1 P 2 …P n ) of multiple valid plans where every plan P i in P is a sequence of instantiated operators (O 1 ,O 2 ,…,O m ) that will achieve the desired goals from the given initial states, in the joint domain. All plans in P are joint plans.
The joint plans are divided into sub-plans, one for each organisation, compatible with each other. The division is based on the prefix attached to each operator after reading the OWLS process definitions. Operators with the same prefix are added into the plan for the organisation represented by the "Org + Organisation Number". The control dependencies and data dependencies are kept the same as in joint plans. The set of compatible plans with the least number of operators is highlighted to the users for execution. Considering each operator takes the same time, this is the least cost heuristic. The users can select the highlighted set or any other set of compatible plans for execution.
If 's' is the current state of the world, 'T' is the task list and 'D' is the domain, the algorithm for the extended SHOP2 planner is as follows:

Figure 2 Extended SHOP2 Algorithm for Workflow Generation
The compatibility of the plans generated by the division of a joint plan is intuitive. In the joint plan, the compatible plans for each organisation are arranged together in a particular order that ensures the achievement of the goal states of all collaborating organisations. This means there is an agreed sequence of activities that can ensure the achievement of the goals of every collaborating organisation, which is the definition of compatibility (Yang and Papazoglou, 2000).

Runtime Execution and Collaboration
The developed framework provides runtime support for the generated sets of compatible workflows. The developed runtime execution mechanism is the only execution mechanism so far that enables the execution of multiple collaborating compatible OWLS based workflows.
The existing execution mechanisms from literature enact automatically generated workflows for single organisations only, however they can handle adhoc processes that are outside the boundaries of the organisation in the workflows (Chen et al., 2011).
The selected set of compatible plans is passed to SHOP2toOWLS Translator, which converts it into enactable workflows of OWLS atomic processes. At runtime, the control and data dependency among the activities in the set of compatible workflows is followed as specified in the joint workflow that was sub-divided to create the selected set of compatible workflows.
Since each activity in the selected set of compatible workflows is basically an OWLS atomic process, which is a model of an actual WSDL service, the activity can be enacted directly using the enactment mechanism of OWLS API. The enactment of an atomic process is a call to the corresponding web accessible program with its inputs instantiated. The generated outputs are kept in form of a name-value pair, so that they can be passed as inputs to the corresponding processes downstream.
In real life, workflows generally run locally in the respective organisations. Although, the developed runtime execution system provides a centralised system for the execution of the workflows of collaborating organisations, the actual web services are enacted locally at the collaborating organisations. It has a similar effect as that of executing workflows locally. To execute the workflows locally at the respective organisations, the generated plans may be distributed to the collaborating organisations and the execution system may be hosted at each collaborating organisation. It can be achieved by extending the system to the client-server architecture. It would be helpful in cases where the organisations are not comfortable with sharing their execution data with an external organisation hosting the execution system.
Since the implemented runtime execution mechanism has to deal with workflow enactment of multiple organisations, collaboration is also required at runtime. The collaboration among cross organisational activities is enabled by using sending and receiving activities, also known as interface activities . Whenever a sending activity is encountered, the data, information or documents to be sent are uploaded to a central server.
Whenever a receiving activity is encountered, the uploaded data, information or documents are downloaded from the server and processed. The uploading and downloading technique is used because if an organisation has to send huge documents to many different partners, it does not have to do it many times. It can upload it to the central server and all partners can download it accordingly. It also decouples the collaborating organisations from each other completely at runtime, which is a desired quality (Van-der-Aalst, 1999; Van-der-Aalst and Weske, 2001). The execution mechanism will wait on a receiving activity until the respective sending activity has been executed.
Unlike the presented enactment mechanism, the mechanism proposed by  targets the enactment of a single workflow only, and it is not able to perform runtime collaboration among the workflows of multiple collaborating organisations.

Implementation
A proof-of-concept prototype has been implemented for the proposed framework. The GUI is developed using Swing and AWT classes of Java. Figure 3 shows the GUI of the implemented prototype. As shown in the figure; processes, inputs, preconditions, outputs and effects are loaded to the system from OWLS process definitions. Initial states and goal states can be selected at GUI. At runtime, the workflow to execute can also be selected from GUI.
The OWLSReader, CWGM, OWLStoSHOP2 Translator, SHOP2toOWLS Translator and Runtime Execution Manager are also developed using Java. The OWLSReader and Runtime Execution Manager are based on OWLS API, which is a Java based API for programmatic access to read, execute and write OWLS service descriptions. The planning is done using a modified version of JSHOP2 planner. JSHOP2 is Java implementation of the SHOP2 planner.
OWLS process definitions can be created manually or automatically using OWLS editor of Protégé. Protégé can load WSDL files and generate a skeleton OWLS process. It further provides graphical control constructs such as sequence, split, join, and choice to create composite processes from atomic processes. WSDL2OWLS tool can also be used for automatic generation of OWLS process definitions from WSDL descriptions. Appendix C shows an atomic OWLS process IssueInspCert from the workflow collaboration example in Section 8. It has been created automatically from its WSDL descriptions using WSDL2OWLS tool. WSDL descriptions of the web services are automatically generated from the Java code of the web services with the help of Apache Axis2. We use Jsch API to upload and download files over Secure File Transfer Protocol (SFTP). Jsch is a Java implementation of SSH2.

Vendor/Customer Example
We will consider a Vendor/Customer example scenario. This is a modification of the example presented by Chen (2008). The vendor in this example is an overseas exporter. The vendor waits for the advance payment from a customer, checks the received payment and then starts the manufacturing process. After manufacturing the goods it issues a commercial invoice represented as Invoice, carries out factory inspection as an in-house procedure, produces an inspection certificate and sends it to the customer. The inspection certificate is represented as InspCert. It waits for the customer's request for making shipment arrangement. After getting the request it sends the commercial invoice to the customer and makes shipment and insurance arrangement. When the arrangement is done, the vendor sends the insurance certificate and bill of lading to the customer, and applies for a certificate of origin to the local authority. The bill of lading is represented by BL. The vendor then sends the certificate of origin to the customer. It waits for the payment for the invoice and the process completes after handling the payment.
The customer is an overseas importer. Customer sends advance payment to the vendor and waits for the inspection certificate, which is a proof of quality of the goods. It reviews the inspection certificate and if satisfied then it produces and sends shipment arrangement request to the vendor. The request is represented by SA. After receiving the commercial invoice, bill of lading and insurance certificate, the customer takes delivery of the goods, carries out a presale inspection and waits for the certificate of origin. The customer needs the commercial invoice and bill of lading to get goods from the shipping company. Certificate of origin is required to get an import permit from the local authority. After receiving the certificate of origin, the customer approves payment and sends full payment for the invoice to the customer.
The OWLS process descriptions simulating the actual activities of Vendor and Customer are passed to the implemented framework. The Vendor and Customer can have any number of OWLS processes and the developed framework will filter out any that are not relevant to a given application scenario. Each activity is represented as an OWLS process, which is grounded in an actual WSDL service. The OWLS process descriptions for Vendor and Customer are given in Table 1 and 2 respectively in Appendix A.
Based on the passed OWLS processes, the system generates 20 sets of compatible workflows in 6816 milliseconds. The generation of the 20 sets of compatible workflows is due to the identification of different composition paths, when the planner encounters activities that can be executed concurrently. Figure 4 shows two of the generated workflows for Vendor and Customer. The graphical representation of the workflows is used to make them more understandable. The solid lines show control dependencies while the dotted lines show data dependencies.   Similarly, in the Customer's workflow in Set 1, Bl_r has a control dependency on SA_s and Inv_r has a control dependency on BL_r. In the Customer's workflow in Set 2, Inv_r has a control dependency on SA_s and BL_r has control dependency on CustomsDeclaration.
Both sets of workflows are accurate and compatible. The workflows, when executed, are able to achieve the desired goals of the collaborating organisations. Moreover, the workflows can be executed to the end in coordination with the collaborating workflows. The compatibility of the workflows can be verified by considering their respective interface processes. Figure 5 shows the interface processes for the Set 1 of compatible workflows in Figure 4. The corresponding interface activities have been labelled with the same alphabet to make them clearer to follow. It can be observed that for every receiving activity there is a corresponding sending activity. Notice that Inv_r has to wait for InsuCert_s to complete before Inv_s to complete, so there is a delay of one activity. But there is no deadlock so the interface processes of both workflows are compatible.
After workflow generation, the user selects one from the sets of compatible workflows for execution. The sequential order of the activities specified by the control dependencies must be followed at runtime, e.g. AdvPay_r must be executed before PaymentCheck. Similarly, the data dependencies must also be followed at runtime. For example, Shipping Arrangement activity must be executed after IssueInv in both sets of compatible workflows, since Shipping Arrangement needs commercial invoice (Invoice), which is generated by IssueInv.
For cross organisational activities, the sending activities upload the data to a central server which is downloaded by the receiving activities. For example, in Figure 4, InspCert_s is a sending activity which uploads inspection certificate to a central server, and InspCert_r is a receiving activity which downloads the inspection certificate. The complete execution of the compatible workflows achieves the desired goals.

Retailer/Wholesaler/Manufacturer/Supplier Example
To illustrate the generality of the framework to handle multiple organisations, a scenario involving four organisations is used, namely retailer, wholesaler, manufacturer and supplier.
It is a common business collaboration scenario from the real world and therefore we have used it as an example to test the developed prototype. The retailer, manufacturer, wholesaler and supplier are represented by Retailer, Manufacturer, Wholesaler and Supplier respectively. The details and descriptions of OWLS processes of each of the organisations are given in Table 3, 4, 5 and 6 respectively in Appendix B. The OWLS process definitions as given in Table 3, 4, 5 and 6 were passed to the system and it generated 10 sets of compatible workflows for the four organisations in 9832 milliseconds. Figure 6 shows one of the generated sets. The workflows generated are accurate and compatible.
The workflow generation process starts when goodsreq holds, which means that the Retailer needs goods. The final goals for the Retailer, Wholesaler, Manufacturer and Supplier are s_RInvPay, r_RInvPay, r_WInvPay and r_MInvPay respectively. The goals indicate that the Retailer sends a payment for the invoice to Wholesaler, Wholesaler receives a payment for the invoice from the Retailer, Manufacturer receives a payment for the invoice from the Wholesaler and the Supplier receives a payment for the invoice from the Manufacturer.
At runtime, the set of compatible workflows with the least number of OWLS processes will be highlighted to the users for execution. In this particular scenario all the workflows are of the same length and so the first plan generated is highlighted to the users for execution. The users will enter the actual quantity of goodsreq to create a quotation inquiry. The QuotationInqPrep activity dependent on goodsreq will be executed to start the execution of the workflows. The in-house and cross organisational control and data dependencies will be followed, to make sure that all collaborating workflows in the selected set are enacted to the end.

Further Application Scenarios
The case studies above illustrated how collaboration between different partners in a supply chain in industry could be supported. The proposed framework and technologies can be used to support a wide range of cross organisation collaboration in different domains. For example, in the higher education sector it is common that a higher education institution would apply to different government funding bodies, charities or companies for research funding. Each of these organisations has their own workflows for application submission, review, and award notification and monitoring. These organisations typically work with many institutions and each of these institutions has its own workflows for grant preparation, grant expenditure, project monitoring and project reporting. It is clear that there is a huge potential and need for workflow support for cross organisation collaboration in this sector too. The proposed framework as illustrated can be modelled to support research grant management across different organisations and institutions.
Another application scenario is support for libraries. Each library normally has a workflow for lending out books. A library may be required to automatically obtain books from other libraries or buy it from bookstores like Amazon, if a required book is not available in the database of the library. Different libraries may have their own respective workflows for lending out books, and book stores like Amazon also have their workflows including activities like book searching, book selection based on certain criteria, card validation, payment and shipping etc. This scenario requires multi-organisation collaboration.
The proposed framework can also be used in the mortgage trading domain. A mortgage trading consultancy may be required to automatically obtain mortgage information from various banks, select the best available option based on the limitations and goals of the client and connect to the selected bank to begin the mortgage application process for the client.
For the above and other multi-organisation workflow collaboration scenarios, the proposed framework can be used to generate compatible workflows for the collaborating organisations, based on their web services descriptions and high level goals.

Discussion and Future Work
This paper presented a framework for the generation and execution of compatible workflows for multiple collaborating organisations. The presented framework is different from existing systems because the existing systems reconcile pre-modelled workflows. This is a time consuming technique, more so, if the organisation is collaborating with many partners.
Automatic workflow generation is the solution to tackle this problem. Existing systems that can automatically generate workflows can do so for single organisations only and cannot handle the generation of compatible workflows for multiple organisations. This leaves the organisation to reconcile the workflows with the collaborating partners on their own if there is any incompatibility, which again requires time and resources. The presented framework solves this problem by integrating workflow generation and workflow collaboration. It generates compatible workflows for multiple collaborating organisations, so that the time and resources invested in modelling and reconciling collaborating workflows can be saved. It also has the capability to handle the execution of the generated collaborating workflows.
Since the workflow generation is based on web services composition, the implemented framework supports reusability and interoperability. Web services from highly diverse sources can be composed in a workflow, and invoked to achieve a desired goal. So the already developed functionalities do not need to be redeveloped and can be reused to save time and resources. The implemented framework encourages cohesiveness and modularity.
The scenarios given in Section 7 show that the developed framework can generate compatible workflows for two or more collaborating organisations and it can support the collaborative enactment of workflows of two or more interacting organisations.
As obvious from the time taken for the generation of workflows in Section 8, the developed system makes the generation of compatible workflows for collaborating organisations extremely efficient. While the time required by the system presented in this paper is in milliseconds, the usual time required for manual collaborations is in days. Practically, the maximum number of organisations or the number of processes that the developed system can handle is dependent on the available memory of the hardware system running it.
SHOP2 does not follow a specific model of time (Parkinson et al., 2011). The time taken by the system to generate workflows is dependent on several factors, including: the number of collaborating organisations, the number of activities in the workflow of each collaborating organisation and the quality of the domain knowledge used for planning (Saleem, 2012). The SHOP2 domain for workflow generation problem is in the form of web services descriptions and OWLS process definitions translated into SHOP2 format. The order in which the methods are specified in the domain can influence the efficiency of SHOP2 (Sohrabi and McIlraith, 2009;Shivashankar et al., 2011). The order in which the if-else conditions are specified in the JBP method can also influence the efficiency of the system. So a linear increase in the planning time as a function of number of participating organisations cannot be concluded. Nonetheless, planning time for the scenario involving four organisations is also sufficiently fast for practical application.
The developed framework uses AI planning for workflow generation. AI planners are not usually designed for the web scale planning problems. A mismatch between SHOP2 and OWLS that exists is that the logic used for describing SHOP2 domain is differently expressive than OWL used for describing web services  i.e. while OWL assumes an open world, the SHOP2 has a closed world assumption. Similarly, SHOP2 assumes that the modelled domain must be correct which is not easy to ensure in the web domain . The data in the semantic web domain can be too huge for the relatively limited inferencing capabilities of AI planners. The integration of an OWL reasoner with SHOP2 will minimise these issues . The replacement of the theorem-prover of SHOP2 with a sound and complete OWL reasoner to exploit its inferencing capabilities, suitability to the semantic web and its usability for workflow generation will be investigated and implemented in future. The effect of the integration of OWL reasoner with SHOP2 on the efficiency of the developed framework also needs investigation.
The framework currently focuses on the compositional capabilities of OWLS processes and does not focus on the automatic discovery of OWLS processes from the web. The reasoning capability of OWL reasoners can be used for automatic web services discovery, which will be targeted in future. Similarly, the paper does not focus on the security aspects of web services invocation.
SHOP2 does not support concurrency  and hence it cannot create parallel workflows. SHOP2 can be extended to support concurrency, which will in turn enable the support for parallel workflows. ConGolog supports concurrency (Giacomo et al., 2000) and therefore can be used to create parallel workflows. The extension of SHOP2 for concurrency and the use of ConGolog interpreter for parallel cross organisational compatible workflows generation need further investigation.
Many small organisations carry out electronic commerce using online business platforms like eBay and Amazon. In such situations, the automatic workflow generation, collaboration and enactment is dependent on the permissions and functionalities provided by the host ecommerce platforms and the standards that they follow to provide point-to-point interaction.
To investigate the effort required to migrate or adapt such platforms to provide flexible crossorganisation collaboration would be an interesting and challenging area for further research.

Acknowledgements
This work is funded by Engineering and Physical Sciences Research Council (EPSRC) through Innovative Manufacturing and Construction Research Centre (IMCRC).

Supplier
The OWLS processes for Retailer, Wholesaler, Manufacturer and Supplier are given in Table   3, 4, 5, and 6 respectively. Only the processes relevant to this collaboration scenario are given.

Retailer)
Outputs/ Effects: r_RInvPay (Payment for the invoice received from the

Retailer)
Description: This process receives the payment for the invoice from the Retailer.