تسهیل جریانات کاری متقابل سازمانی با رویکرد مشاهده جریان کار

Interconnecting business processes across systems and organisations is considered to provide significant benefits, such as greater process transparency, higher degrees of integration, facilitation of communication, and consequently higher throughput in a given time interval. However, to achieve these benefits requires tackling constraints. In the context of this paper these are privacy-requirements of the involved workflows and their mutual dependencies. Workflow views are a promising conceptional approach to address the issue of privacy; however this approach requires addressing the issue of interdependencies between workflow view and adjacent private workflow. In this paper we focus on three aspects concerning the support for execution of cross-organisational workflows that have been modelled with a workflow view approach: (i) communication between the entities of a view-based workflow model, (ii) their impact on an extended workflow engine, and (iii) the design of a cross-organisational workflow architecture (CWA). We consider communication aspects in terms of state dependencies and control flow dependencies. We propose to tightly couple private workflow and workflow view with state dependencies, whilst to loosely couple workflow views with control flow dependencies. We introduce a Petri-Net-based state transition approach that binds states of private workflow tasks to their adjacent workflow view-task. On the basis of these communication aspects we develop a CWA for view-based cross-organisational workflow execution. Its concepts are valid for mediated and unmediated interactions and express no choice of a particular technology. The concepts are demonstrated by a scenario, run by two extended workflow management systems.

1.1. Motivation We observe that the notion of Business Process Management (BPM) is receiving increasing attention from analysts, customers, and solution providers. BPM is considered to provide comprehensive answers to the problem of application component, application, system, and business integration by providing higher-level constructs that are able to reflect contexts, involved entities, and their dependencies. Particular in the context of cross-organisational interactions (a.k.a. Business-to-Business), we observe that a particular context requires the involved partners to adapt for the purpose of the interaction. This adaptation can, however, not necessarily be reflected in the partners' private (internal) business processes without inflicting their ability to interact with other partners in a different context. Imagine an automotive supplier that is providing parts to two different car manufacturers that prescribe a particular sequence of interaction. This means that process-oriented abstractions need to be modelled and tightly bound to their corresponding private business process. Furthermore, these have to be executed in equilibrium such that internal actions that affect the interaction with other partners are communicated, and that the coordination between the partners effects their private workflows, i.e., that they synchronise with each other. Workflow views are considered a promising conceptual approach to selectively hide details of private workflows, whilst providing a process-oriented interface to facilitate the state-oriented communication between trading partners. However, with the introduction of workflow views we need to address the issue on how a workflow engine could support them and how this would affect the design of an underlying architecture that would facilitate the cross-workflow-system communication. Workflow interoperability standards, such as BPEL4WS [17], and WSCI [13] provide important constructs to model interactions of web services. However, they neither address a model-oriented relationship between private workflows and their publicly visible abstractions nor do they model the interaction between abstract processes. It is further not the focus of these specification to propose how such a model could be supported by a runtime engine. In this paper we therefore consider a workflow management system (WfMS) and conceptualise a supporting architecture that enables execution of private workflows in a cross-organisational context without compromising the privacy and contingency of private workflows, which reflect best business practice, and provide a scalable visibility to structural information of private workflows to trading partners. This paper is organised as follows: in Section 1 be motivate our work, clarify our understanding on cross-organisational workflow, elaborate on related work, and introduce a distributed workflow model. In Section 2 we consider architectural aspects, a scenario, and unmediated and mediated interactions. In Section 3 we particularly focus on an approach to tightly bind a private workflow to its corresponding abstract workflow and investigate how this approach behaves during execution time. In Section 4 we discuss a supporting cross-organisational workflow architecture and introduce its constituent entities. Section 5 presents an extended workflow management system for cross-organisational workflows, called Nehemiah. We conclude and mention future work in Section 6. 1.2. On cross-organisational workflow types In order to position the particular architectural issues in cross-organisational workflow management we need to investigate and clarify our understanding of this term. We observe the involvement of an external party which is interacting within the context of a task of a workflow or within the context of a workflow. We therefore consider cross-organisational/cross-system workflows, which we classify into two main types: Distributed Workflows, also known as composite workflows, and Outsourced Workflows. 1.2.1. Distributed workflows All activities or sub-workflows of the workflow of a party are implemented inside the scope of the workflow. The existing workflow is augmented by means of one or more activities or sub-workflows of an external workflow. In Fig. 1 we consider a distributed workflow (coalition workflow) with the participation of the partners A and B. Partner A owns and implements tasks t2, t4, t5, which are underlaid in dark-grey in the figure. Partner B owns and implements tasks t1, t3, t6, which are underlaid in light grey in the figure.In Fig. 2 we analyse this distributed workflow in greater detail. Because both workflows from partners A and B are pre-existing, they are complete in the sense that their respective tasks are linked by dependencies; these are d(t2,t4), d(t4,t5), d(t1,t3) and d(t3,t6).As the workflows from partners A and B are run by different systems, it is important for the systems to coordinate their interactions, e.g., by means of routing tasks and dependencies. In the example, t4 needs to wait until t2 AND t3 are completed. Therefore, Fig. 2 also depicts the routing tasks that are required to ensure order preservation and co-ordination of tasks t1,…,t6. It is necessary to apply the routing tasks, which are AND-splits and AND-joins in order to synchronise the flow of work within a partner's organisation with the flow of work outside. In the figure, each outgoing dependency requires the emitting task to add an AND-split, whilst each incoming dependency requires the receiving task to add an AND-join. 1.2.2. Outsourced workflows In Outsourced Workflows, one or more activities or sub-workflows of an existing workflow are implemented outside of the scope of the workflow by an external task or workflow. The existing activities or sub-workflows in the workflow are placeholders for external activities or sub-workflows. Fig. 3 shows the general principles of an outsourced workflow model.As the workflows from partners A and B are run by different systems, it is important for the systems to coordinate their interactions, e.g., by means of routing tasks and dependencies. In the example, t4 needs to wait until t2 AND t3 are completed. Therefore, Fig. 2 also depicts the routing tasks that are required to ensure order preservation and co-ordination of tasks t1,…,t6. It is necessary to apply the routing tasks, which are AND-splits and AND-joins in order to synchronise the flow of work within a partner's organisation with the flow of work outside. In the figure, each outgoing dependency requires the emitting task to add an AND-split, whilst each incoming dependency requires the receiving task to add an AND-join. 1.2.2. Outsourced workflows In Outsourced Workflows, one or more activities or sub-workflows of an existing workflow are implemented outside of the scope of the workflow by an external task or workflow. The existing activities or sub-workflows in the workflow are placeholders for external activities or sub-workflows. Fig. 3 shows the general principles of an outsourced workflow model.In the figure, partner B's tasks t12 and t14 are proxies for partner A's tasks t13, t15, and t16 that implement them. Tasks t12 and t14 communicate with partner A's implementing tasks during their lifecycle. This is transparent for workflow management system that performs the workflow of partner B because the outsourcing acts exactly the same as a performing agent. With regards to our architectural considerations we propose to realise distributed workflows through control-flow dependencies, whilst outsourced workflows better communicate through state dependencies. We discuss this in the following sections and relate our proposed workflow model to the concepts of workflow distribution and outsourcing.

In this paper we discussed the entities of an architecture that provides execution support for mediated and unmediated cross-organisational workflows. We argued how this architecture supports our view-based cross-organisational workflow model, which we particularly investigated with regards to state dependencies between private workflows and workflow views. We introduced an explicit modelling approach to describe those dependencies. In this context we argued how private workflows and workflow views should be tightly coupled through state dependencies, whilst workflow views should be loosely coupled through synchronisation tasks. Finally, we demonstrated the viability of our proposed approach on the basis of an extended workflow management system that executes private workflow in equilibrium with its corresponding workflow view in the context of a coalition workflow in which it interacts with other workflow views from other partners. We proposed a Petri-Net based representation as the basis for consideration of state dependencies between the tasks in a workflow and the adjacent task in a workflow view. This representation is focused on the structural aspects of a workflow, which includes the internal states of tasks and view task, and their state dependencies. The key idea behind the introduction of workflow views that abstract from private workflows is the provision of a mechanism that allows for a multi-granular privacy of workflows. We postulate that a workflow view needs to be protected from unauthorised interaction. Outside of the context of deeper considerations in this paper are the major requirements towards any system that supports the electronic exchange of sensitive data to ensure that the data remains private, in the sense that it is protected from being observed by a third party. Whilst the workflow view approach provides for the limited visibility of certain information concerning the underlying private workflow, we have not considered topics related to the actual communication between trading partners and their workflow views. These are data integrity, which means that data is protected from being changed whilst in transit. For example, data could be modified or forged. Or a header of a valid message A could be associated with the body of a valid message B in order to create a forged message C. Messages could be replayed: a valid message could be re-used for a repeated request to IT system. Also authentication needs to be ensured: is the sender of data who he claims to be? Further, there is denial-of-service: a third party floats an IT-systems with forged IP packets such that this system becomes so busy handling these packets that it becomes very slow or unable to handle real requests. In this paper we have mainly considered the structural aspects of a workflow and the control-flow dependencies between tasks. However, as workflows represent business processes, tasks represent actions in the real world. Actions always read, write, or alter data. Consequently, tasks have to reflect the data lifecycle, whilst workflows need to be considered with data flow in addition to control flow. We firmly believe that future work needs to address data flow in workflow modelling and execution. We briefly discuss this below. In Fig. 20 we consider task-relevant data. A task consumes data at the beginning of its lifecycle to enter the state running. During its lifecycle it exchanges data with its environment in order to achieve its business objective. At the end of its lifecycle it produces some data that is required by the next task. The union of task-relevant data from all tasks of a workflow form workflow-relevant data.From a workflow modelling perspective we argue that the union of exchange data of a set of tasks that are represented by a single view task has to be modelled conscious of the fact that once the view-task represents many tasks that require interaction with the coalition, the coalition partner would not be aware in which order they have to exchange data with l. A better approach is to have maximum one task that requires data exchange with the coalition being represented through the view task. We note that still all tasks are able to exchange data within their own organisation, because the corresponding private workflow's details are all known to its owning entity. Finally, the issue of transactions requires further consideration. Our model is intended for transactional behaviour of private workflow tasks and their corresponding workflow view task in terms of atomicity (all state changes to a private workflow task are reflected in the corresponding view task or none of them and vice versa) and consistency (state information in private workflow task and corresponding workflow view task are consistent). However, this needs to be revisited in the context of semantic considerations of private workflows.