Architecting Cross Architecting Cross-Organisational Organisational

0 downloads 0 Views 157KB Size Report
Page 1 ... EDOC (Enterprise Distributed Object Computing) standardisation [15]. The remainder of ... detail within the UML profile for EDOC and WfMC standard.
Architecting CrossCross-Organisational B2B Interactions Karsten Schulz, Zoran Milosevic DSTC Pty. Ltd. CRC for Distributed Systems Technology Level 7, General Purpose South The University of Queensland QLD 4072 Australia @dstc.edu.au Abstract Process-orientation is used increasingly as an approach to streamlining formerly inefficient business procedures and workflow management systems are frequently deployed IT systems to support this. The large number of workflow management systems available in the market and a growing demand for workflow systems demonstrates this trend. However in a world of electronic interconnectivity, the concepts for process automation within single organisation need to be extended to support co-operation with customers and partners in different organisations. Current workflow standards bodies provide limited support to enable this interconnectivity. They provide interfaces and data structures for interoperability but they do not address various aspects of the confidentiality of internal structures of processes – those that bring a competitive edge. This paper outlines our approach for dealing with these inter-organisational aspects. We propose a model for tiering business processes into organisations’ private business processes and shared business processes that interconnect them. Private business processes can expose interaction points and shared processes can link to these points so that an overall business process may span two or more organisations. The interaction points can selectively expose information about an organisation’s processes, process tasks and roles. The paper also presents how these modelling ideas can be supported by a corresponding architecture and describes a prototype that implements key ideas of the architecture.

1

Introduction

Workflow management systems have initially been designed to bridge the gap between a document-oriented office world and the process-oriented way humans think.

With the considerable rise of the World Wide Web (WWW) in recent years, companies and customers have recognized new opportunities to use this electronic medium to undertake business. Workflow management systems have taken a new and prominent role as back-end systems in electronic business transactions. This started in the business-to-consumer (B2C) area. For example, a web-browser enabled interface allows customers to select goods, put them in their electronic shopping basket, order, pay for them electronically and track their shipment. The use of workflow management systems has potentially an even more significant role in the emerging business-tobusiness (B2B) domain. As organisations are focusing more and more on their core competencies, they increasingly need better interaction channels and closer relationship with their partners in a business process. Workflow management systems need to ensure a smooth interaction of organisations in their joint business processes, whilst preserving their autonomy and competitive edge over others. Workflow management systems also need to allow for the integration of organisations’ existing infrastructures into crossorganisational business processes. To achieve the above goals, it is important to enable interoperability of workflow management systems (WfMS). This interoperability should address both the i) semantic issues related to business process interoperability, such as relationships between roles of one business process and business tasks in a partner organisation’s process and ii) interface-level interoperability, enabling WfMS systems to exchange data and events. This paper provides an approach for dealing with both of these interoperability aspects. The approach is motivated by our earlier experience in building workflow interoperability systems and our recent work on business process meta-modelling, as part of the UML profile for

1

Computing)

usable for all partners in a cross-organisational business scenario.

The remainder of the paper is structured as follows. Section 2 outlines several approaches to achieving workflow interoperability in a multi-organisational situation and sets the scene for positioning our work. Section 3 describes the problem of inter-organisational workflow management - in the presence of the requirement to keep certain aspects of companies’ business processes private. Section 4 introduces our modelling approach that provides a solution to this problem. This section also addresses the problem of ensuring that roles from one organisation have authority to interact with business process in another organisation. Section 5 presents a business architecture that enables realisation of this modelling approach and describes a prototype that implements one instance of that architecture. Section 6 concludes the paper and outlines future work directions.

Thus, the adoption of a common process definition language (i.e. a meta-model) by workflow vendors will allow true interoperability of business processes supported by different workflow engines. Below we introduce some of the major initiatives that are working on producing such meta-models.

2

Recently, the RosettaNet [5] initiative has begun to capture and standardize the business processes within different IT industry’s supply chains. The standard captures various business processes and specifies them in terms of Partner Interface Processes (PIPs). Examples of PIPs include product and technical data interchange, management of purchase orders and purchase order status. Through the specifications expected from RosettaNet, participants in a business scenario are expected to use a common set of concepts – this being the basis for their B2B model descriptions.

EDOC (Enterprise standardisation [15].

Distributed

Object

Process Interoperability Standards

Process interchange can be achieved via a commonly adopted process definition language (meta-model) or through an interface layer. The latter is a partial solution as it enables invocation semantics (interaction at the business process level), while the former allows a full interoperability because it enables business processes to interact at the level of any modelling element - as if it were a single organisational business process. These two approaches are described in the following.

2.1

Common Process Definitions

Today’s workflow management systems (WfMS) are far from having a common meta-model for business process definitions [1]. An implication of this is that a business process model of an organisation can become dependent on a meta-model of particular WfMS. For example, when undertaking business process re-engineering for an organisation, one often needs to adapt its processes to meet the requirements of the individual WfMS – while attempting to preserve specifications of organisational and technical structures of a company. Hence, due to the lack of a common meta-model the resulting workflow definitions are often not re-usable for other WfMSs in other companies. Business process descriptions can thus become bound to the organisation in question and also their WfMS. This makes a meaningful exchange of process definitions difficult if not impossible and also prevents having a common business process definition that is valid and

The Workflow Management Coalition (WfMC) standard [6], which includes input from all major workflow vendors, has developed such a meta-model standard. It defines a common meta-model for describing the process definition and also a textual grammar for the interchange of process definitions (Workflow Process Definition Language - WPDL). It also describes APIs for the manipulation of process definition data. Although this standard has been published, there are very few actual implementations that are complying with it at present.

There is currently ongoing work to standardise a business process model as part of UML profile for EDOC (Enterprise Distributed Object Computing) [15]. This work aims at identifying a minimal meta-model for the specification of business processes, irrespective of the underlying technology to support it. The objective is to separate business process specifications from the intricacies of underlying technologies that can be used to support these descriptions, be they WfMS systems, component platforms such as EJB, CCM, COM+, or any other implementation choice. Finally, work has recently initiated within the ebXML.org group [14], with the aim to provide support specifically for the B2B process issues - currently not addressed in detail within the UML profile for EDOC and WfMC standard. However current ebXML Business Process developments are centred on support for simple, two-party interactions. As a result, there is a limited description of flows between business tasks – eg. control flows are only defined between components of a particular requestresponse-type interaction between two partners.

2

2.2

Common Interfaces

As opposed to the process definition standards, the process interoperability standards at the interface layer are more widely supported by industry and workflow vendors. The main standardisation institutions that have published interface definitions for workflow interoperability are the WfMC and the Object Management Group (OMG). They have specified a reference model describing a set of common interfaces for Workflow Management Systems (WfMSs), as depicted in [3], p. 1-13, which is based on [10]. The most important interface for B2B process interoperability is the interoperability interface, which is intended to interconnect the participating workflow enactment services. According to [10], communicationinteroperability between workflow management systems can be realized by: • direct interaction of WfMS via a set of standardized functions, • message passing between WfMS, • use of shared data stores, e.g. commonly accessible repositories. • bridging of systems using gateways to connect different protocols and formats, A direct interaction by means of a common set of APIs of systems is possible, but requires that the involved workflow management systems have a high level of mutual knowledge and trust. An example of message-passing is the WfMC’s specification of standardized workflow information and using MIME (Multipurpose Internet Mail Extensions) encoded emails as carriers. The first of a series of interoperability demonstrations took place in 1996 [12]. Due to the inherent restrictions of the underlying email technology, this cannot be considered as a robust integration of business process management systems for critical business processes. The WfMC has faced this with the interoperability Wf-XML binding specification [11] based on the HTTP protocol. This can be seen as an XML complement to OMG’s CORBA-based Workflow Facility Standard [3]. Shared data stores offer the advantage of commonly accessible data to all partners. This makes data exchange and sharing between the involved systems easier. However, these data stores are not able to actively trigger other WfMSs. The involved systems still need to directly communicate with each other via APIs, messages or gateways.

Gateways offer a wide variety of possibilities and we use them extensively as part of our Business Process Framework Architecture. This will be elaborated in section 5.2 of this paper.

3

Problem Description and Related Work

Organisations that participate in a close B2B relationship face a tension between harmonizing internal processes with their partners and at the same time keeping their business processes confidential. A good and efficient organisation of business processes with the optimal usage of resources is often a competitive advantage against others. These organisational issues are of vital importance for true B2B process interactions but current standards do not address them at present. This paper addresses several such problems, in particular: • •

How to achieve controlled invocation and querying of an organisation’s business process by their partners – according to the organisational policies. How to close the ‘security hole’ associated with the usage of a direct API or message-based communication between systems.

Existing commercial solutions to these questions neglect the heterogeneity of the involved systems and introduce a homogeneous workflow meta-model where the partners’ workflow parts are statically linked. Commercial examples are Extricity Alliance and Microsoft Biztalk. The Crossflow project [13] describes an approach to architect cross-organisational business process interactions. The Crossflow architecture introduces proxy gateways that protect or encapsulate the provider/consumer organisations’ core services. The architecture is workflow management system independent. Crossflow introduces business contracts to describe the business operation between partners. Crossflow requires a direct communication between partner organisations to execute a joint business process. In Crossflow, there is no central instance that has a comprehensive view on the multi-organisational business processes. Riempp [2] follows a similar approach: his work is based upon shared repositories to interchange data between linked business processes. Riempp introduces an additional interface between Process Definition Tools of the involved business partners and assumes joint modelling of business process definitions. In this paper we propose a WfMS-independent distributed workflow architecture to support B2B processes. The

3

execution of the components of this architecture is centrally coordinated in order to provide a high degree of flexibility and reliability. This architecture supports business transactions between organisations without a need that they have full knowledge of the structure of each other’s processes and without expositing confidential data to their partners. It allows this to be done in a flexible and reliable manner.

4

B2B Process Model

This section presents our modelling approach to dealing with the B2B specific problems outlined in the previous section. This description uses key business process modelling concepts as introduced in [15]. These are summarized as follows.

4.1

Key Business Process Modelling Concepts

A business process is decomposed in a number of units of work called tasks, which jointly contribute to produce a result for which this process was created. There may be complex dependencies between tasks that are described in terms of control flows and data flows between tasks. These flows can be used to model parallel and sequential execution of the tasks in a business process. Tasks can represent synchronization points between parallel flows and flows themselves can be split and joined. A compound task represents several tasks that can be grouped for some purpose. An application task denotes some specific function that needs to be executed and, from the point of view of a business process, it can be regarded as a ‘black-box’ – its internals are not of a concern for the business process. In addition, tasks can represent sources and sinks of events of some business significance – business events. Each task can be associated with one or more roles. These will be defined in more detail below.

4.2

Private and Shared Process Tiers

The key idea of our B2B process model is its separation into two tiers - one consisting of business processes that are private to each of the organisations (private tier) and the second one, consisting of business processes that are known to all participating organisations (shared or public tier). Further, one or more private business processes can be grouped into a service. A service represents an external

view of an organisation’s private business processes. They are exposed as interaction points, which can be used by shared business processes to form an overall, B2B process. This interaction can be in terms of: •

the invocation of a private business process exposed via the service, or



the interaction with the selectively exposed individual elements of a private process, such as an individual business task within that process or a role or group of roles within it.

4.2.1

Shared Business Processes

In order to specify dependencies between the elements of business processes from different organisations we introduce a concept of a shared business process. A shared business process references business process services thus connecting private business processes in a cross-enterprise business scenario. To support expression of services, we extend our business process meta-model [15] with the business process service type (see 4.2.2 for a more detailed description of service). A business process service type is a specialized task from our meta-model and is implemented by a Business Process. The service type also specifies the required Business Events (see chapter 4.3) to which a Business Process Service is to be subscribed at runtime. The inter-enterprise coordination thus builds on a distributed business process model where every partner manages its own part of the overall business process. Shared business processes can be specified by the partners involved, or can be offered by a third party (best-practice business processes). A shared business process specifies activities that each of the parties are required to perform as agreed in their contract. The process of the derivation of shared business process from the contract is one of the open issues that we plan to investigate in future. A shared business process instance is created when the execution of a new workflow definition is triggered, e.g. by a customer on a web page.

4.2.2

Private Business Processes and Services

As stated above, business partners in a crossorganisational B2B scenario need to keep their processes confidential. To this end we propose that sensitive and confidential parts of an organisation’s business process (i.e. private business processes) be encapsulated and exposed as Business Process Services. Business Process Services are an abstraction of the actual processes offered

4

by an organisation. Thus, one Business Process Service can consist of several private processes to accomplish it. Figure 1 depicts the separation of an inter-organisational business process definition in private and shared parts. Private business processes are kept confidential within organisations whereas one or more shared business processes interconnect them. In Figure 1 one private and one shared layer are shown. A private activity (the grey circles without contained symbols) can offer its functionality to another private or public business process.

4.4

Integration of Roles in a B2B Process

The description of business processes for B2B from previous sections needs to be extended with the concept of Role. A Role in a business process model is typically used to specify i) who is executing individual tasks or groups of tasks in a business process or ii) what resources are needed for the execution of these tasks. We refer to the former roles as performer roles and to the latter roles as artifact roles. There are at least two possible ways that performer roles from one organisation can be involved in a business process of another organisation.

Private Business Process Enterprise Public Business Process

Service Communication

Service Offer Service Reference

Figure 1 Business Process Tiers Business Process Services consist of input and output data, consumed and emitted events, states, and attributes like for example the service’s expected duration or its costs.

4.3

Business Events

Business Events are used to exchange information between private business tasks (or private business processes) and shared process tasks (or shared business processes). Indirectly this allows an information exchange (and thus collaboration) between private business processes or private business tasks that are executed in different organisations. We define Business Event as a data type: { Sender; Recipient; I/O Data: {Type, Value}; Description; Associated Role; } At the workflow process definition level, Business Events have to be associated with business tasks – which are associated with roles.

One possibility is that a role from one organisation is only given a permission to invoke an exposed private business process of another organisation. This business process can be regarded as a ‘black box’ from the role’s standpoint. In other words, there is no further interaction between the role that invoked the business process and individual tasks within that business process until the process returns its result. Second possibility is that a business process of one organisation specifies one or more performer roles defining behaviour ‘originating’ in another organisation. In other words, these ‘external’ roles will be filled by entities whose responsibilities and liabilities are defined in another domain. For example, a business process of one organisation may define a performer role called user, which can be filled by a person - whose responsibilities and liabilities can be defined by various domains, such as another organisation (on whose behalf this person acts) or the underlying jurisdiction in which the person resides. The user role can also be filled by another organisation (whose responsibilities and liabilities are defined by corporate law of particular country) or by an organisational unit of that organisation (whose responsibilities and liabilities are defined by this organisation).

4.5

Ensuring Competency of Roles in a B2B Process

As discussed above, a shared business process can invoke private business processes defined in other organisations. Similarly, a shared business process can specify roles that ‘reference’ private roles defined in other organisations. This referencing can be through the simple exposition of the roles from a private business process to the shared

5

business process, enabling them to be used in the same way as from the private process (similar to a soft link). On the other hand, the referencing could be achieved through a mechanism of delegation, whereby the public roles can be delegated to one or more roles defined in a private business process. In general, and in order to achieve integrity of business process execution when crossing organisational boundaries, it is necessary to ensure the competency of the performer roles of one organisation interacting with a business process in another organisation. This means that only certain roles from one organisation have authority to invoke private processes of another organisation or be involved in the execution of a task belonging to a business process in another organisation. Consider for example a simple business process that involves signing of a business contract by contract officer roles that act on behalf of other roles in their respective organisations. In order to ensure that a contract officer role in one organisation has an authority to represent that organisation in relation to a particular kind of contract, we have introduced a concept of a competency profile for an

various possible combinations of roles in one organisation whose digital signatures need to be obtained by a contract officer to be able to be engaged in negotiating a contract of certain types. This concept of competency profiles – initially developed for the purpose of ensuring competency aspects of digital contracts can be extended to relate to any modelling artefact in a context of B2B processes. For example, it can be extended to ensure that only certain roles from one organisation have an authority to invoke certain business process type (or a business task type of that process) in another organisation.

4.6

Example of a B2B Process

This example illustrates the use of the B2B modelling concepts introduced so far. This example is revisited in the next section to show how these various concepts were implemented in a true inter-organisational setting. Consider an example of a process for building a house, in which several organisations are involved. A customer can start with accessing a domain-specific and regionalspecific Internet marketplace and entering information

Exposed Role Liaison Officer

Check Regulations Shared Global workflow Subflow decomposition

Liaison Officer

Local workflow

Figure 2: Example of a B2B Process organisation [16]. This is essentially a description of

about the house that he wants to build, e.g. the location of

6

process invoked by the Check Regulations shared task (the first task in this private process is a schema conversion task).

the house, materials, the maximum costs, size, colour, etc. This triggers a business process at the marketplace that checks the marketplace’s business directories and contacts potential companies about their availabilities and schedules. The output of this workflow is a list of companies that are able to perform the customer’s request within various constraints set by the customer.

This role exposition enables all the partners to query the Officer about the state of the verification and also to give some other regulatory details to other parties (e.g. the architect department), while designing the building.

The customer would then decide upon this offer and if accepted, will confirm it and will fill in an order for this house. Another business process will then start that links together the individual companies. This business process takes into account local regulations and authorities. Figure 2 depicts this business process linking the following organisations: an architect department, a building service department, an estimating department, a local authority, the building company and a marketing/sales company. This figure also shows a selection of private business processes that are executed in the respective companies and how they are related to the shared business process. In addition, one role from one organisation is exposed to the shared business process.

5

Business Process Framework Architecture

The Business Process Framework Architecture (BPFA) that we describe in this chapter is based on the two-tier business process model introduced above. The BPFA consists of a set of components that execute instances of an inter-organisational process model. The BPFA extends company’s existing workflow infrastructures and enables process-oriented communication with their partners and customers. The BPFA (Figure 3) consists of a set of components of which we will introduce the below ones in more detail: Business Process Broker that contains a Service Manager, a Service Selector and a Workflow Engine; Business Process Gateway consisting of Business Process Mapper, Private Service Repository, Service Modelling Tool, and Service Supplier. For clarity, Figure 3 depicts one instance of the BPFA components and thus only shows a single

The picture illustrates how certain private roles can be exposed to the shared business process. For example, the role of the Liaison Officer of the local authority is made visible to all partners in the shared business process. This role is assigned to the private task “checkDisabledAccess’ and it verifies whether the building is usable by the disabled people. This private task is a task of a business Enterprise Business Process Gateway Service Modeling Tool

M apping Inform ation

Non-Process-oriented Systems Process-oriented Systems

Private Service Repository

4 invoke Service Supplier

Business Process Mapper

5 respond

Register Service

Marketplace

respond

invoke

0

3

6

Business Process Broker

Services {Events, Attributes, Service Name, if AND {}}

Service Manager

Select Service

Service Selector

W orkflow Engine

1

2

Public Service Repository

invoke

Public W orkflow Definitions

Business Process Repository

Figure 3: Business Process Framework Architecture

7

enterprise that operates with a marketplace.

5.1

Business Process Broker

The Business Process Broker is a central instance that coordinates the interaction of the participating partners. It is a workflow-oriented component that runs shared business processes using a corresponding Workflow Engine. These shared business process definitions are stored in the Broker’s Business Process Repository. The Business Process Broker is responsible for routing business events to the correct recipients. The broker has no knowledge about partner’s internal business processes, but instead selects available services from the Service Manager through the Service Selector. Upon selection of an appropriate service, the broker invokes a business task request at the respective company’s Business Process Gateway.

available Business Process Services Types with the required Business Process Services as defined in a workflow definition. This is a late binding approach that permits the dynamic selection of Business Process Services at runtime.

5.2

Business Process Gateway

This component is the company’s process interface to the outside world. It redirects all ingoing and outgoing process requests serving as a proxy. It hides internal systems from the outer world. This also allows the participation of non process-oriented systems in business processes. Gateways are a frequently used approach to linking different types of components in heterogeneous environments [2]. Some of a gateway’s most important characteristics are:

Using a broker model instead of a peer-to-peer model reduces the number of individual communication paths. Partner companies only have to care about the protocols that are being used by the Broker instead of a possibly high variety in protocols of the different partners. Having one component that manages the cross-organisational business process facilitates the management of communication failures and supports interactions between private workflows. This is because the broker has a general view on a cross-organisational business community. Further, audit data that can be produced by this component can be used to monitor inter-enterprise business relationships.

Confidentiality and access protection: A gateway protects internal systems of an organisation from direct access from the outside, serving as a ’firewall’. Making an API of a system directly accessible to the outside may permit for undesired activities.

The Broker can be owned by the main partner in a company alliance or by a third party like a Marketplace provider. A Marketplace is a central instance that brings together business partners. A Marketplace provides directory services, which enable buyers and sellers to find each other. A Marketplace facilitates information interchange by supplying services, like a business process broker for public workflows or data conversion services.

Format conversion: Gateways should have the ability to convert outgoing message objects from the format used by the internal system to a format that can be understood by the external recipient. Likewise, incoming message objects may have to be converted so that an internal system can handle the information.

Service Manager A service manager is a publicly available component that serves as a repository of business process service offers. It can be compared to a trading service e.g. the OMG Trading Service. Organisations that wish to participate in cross-organisational business processes enrol their service offers into the Service Manager.

Transparency/Routing: Gateways make the communication of systems transparent. Neither does a workflow designer need to know details about an organisation behind the offered service, nor does a performer in a workflow instance need to be concerned about the correct routing of message objects to the correct systems.

Tracking: Using this functionality, the necessary information for monitoring and cross-organisational service billing is supplied. A gateway can have a full log of all services that have been invoked on the systems of an organisation. To allow partner companies a dedicated insight into executed services, subsets of the tracking information can be supplied to them. Error prevention and handling: Gateways can deal with failures in system’s interactions.

Workflow Engine/Service Selector The workflow engine is a typical workflow engine. It is extended by a service selector that binds together

8

Business Process Mapper This component maps Business Process Services to private workflow definitions as defined by the Service Modelling Tool. It provides the following gateway services: confidentiality and access protection, transparency/routing, format conversion, tracking, error prevention and handling. It intercepts incoming service requests and dispatches them according to the service specifications stored in the Private Service Repository.

Private Service Repository All private process definitions are kept in the repository of its respective workflow management systems in a company, and are referred to by the Service Repository of an Enterprise. It supports the Business Process Gateway in the selection of the correct systems for a respective service call and provides the audit information, both for private statistical purposes, but also for crossorganisational business process monitoring and billing.

is handed back from the Service Selector to the Business Process Broker, which then contacts the Business Process Gateway of the participant that provides the service (3). Process-relevant information is handed over to the Business Process Mapper (a component of the Business Process Gateway). The Business Process Mapper translates the request to process a task of a shared business process to a request to process the corresponding task (or tasks) of a private business process. To this end, the corresponding private process definition is read from the Private Service Repository. This finally results in one or multiple requests to those systems that execute the service (4), be they process-oriented or non-process-oriented systems.

This tool can be regarded as an extended business process definition editor. It describes the relationship between exposed Business Process Services and private processes that fulfil them. The resulting mapping data is stored in the Business Process Repository.

A request for further input that is required by the executing systems are made by firing Business Events to the Business Process Mapper (5) that routes them to the Business Process Broker (6). When the execution of a service has finished, the executing systems return back control and data to the Business Process Mapper (5), which returns it to the Business Process Broker (6). Again, this is achieved by using Business Events. It then continues with the execution of further activities and workflows.

Service Supplier

5.4

Service Modelling Tool

This component manages the operations associated with the availability of business process services to the Service Manager.

5.3

Runtime Behaviour and Application

As seen above, Figure 3 illustrates the business process framework architecture and enumerates main tasks that are performed by the components. Here, we describe the steps of operation that are executed at runtime, as follows: Partner companies in a cross-organisational business process publish their service offers to a Service Manager, as shown by the task (0). After the Business Process Broker receives a request to instantiate an inter-enterprise process definition, it loads the definition from its Business Process Repository and starts to process the first task of the shared business process instance. This task references the type of service that is able to process the activity. The Workflow Engine then invokes the Service Selector (1) and hands over the required service characteristic information. The Service Selector then selects a service from the Service Manager (2). A reference to the selected service

Prototype Implementation

A precursor of the described Business Process Framework Architecture has been implemented, applied and successfully demonstrated in the European Union Esprit Project EP 20408, Virtual Enterprises using Groupware Tools and Distributed Architectures, ”VEGA” [7], [8], [9] in an industrial environment. The first author was responsible for designing the workflow aspect of this project. The Vega final demonstration [11, Chapter7] scenario, depicted in figure 2, brought together six different companies in a common virtual enterprise. The implementation built upon OMG’s Workflow Management Facility Specification [3] [4] for interworkflow management interfaces and incorporated existing workflow management systems like Swisscom Process Manager, Compaq Expeditor, Compaq Process Flow, Compaq LinkWorks and SAP R/3. To demonstrate the inclusion of non process-oriented database systems, the EDM Express Data Manager of EPM Norway had been included in a cross-organisational business process scenario. In addition, several other C++, JAVA and JAVA Script applications, web-servers and CAD applications were all linked to the Business Process Framework Architecture.

9

The demonstration realized the scenario of figure 2. Available services were selected at runtime according to their capabilities and their availability. An experience from the demonstration with all these before mentioned components was a fast linkage between existing business processes and reliable communication between the business partners. 6

Conclusions and Future Research

This paper has addressed the problem of modelling and architecting B2B process interactions in the presence of conflicting requirements – ensuring B2B business process integration at the semantic level, while protecting sensitive aspects of organisations business process. This is achieved by selectively exposing private business processes or the elements of these business processes via the concept of service. It is then possible to interconnect these services by using a business process visible to all the participants involved – via the concept of shared business process. The paper has also demonstrated how such a model can be supported by an architecture that builds on a distributed process model, which is centrally coordinated. Applying a service model allows organisations to enable their internal processes to communicate with the outside world without exposing any internal structure or making them directly accessible. There are several open issues in this paper that we plan to address in future. First, we plan to provide a detailed and more comprehensive model for relating roles of private and shared business processes. Second, we plan to further investigate the use of business events and other exchange mechanisms to ensure flow of business documents across organisations. Finally, we plan to relate B2B processes to the specification of business contracts that state what activities each of the parties to the contact are obliged to perform – and to provide a monitoring mechanism to support these. We are currently extending the prototype to include support for implementing an explicit service model and to include inter-organisational roles.

7

8

References

[1] Bussler, C.: Enterprise-Wide Workflow Management, IEEE Concurrency Journal, July 1999. [2] Riempp, G.: Wide Area Workflow Management - Creating Partnerships for the 21st Century, Springer, 1998 [3] Object Management Group: OMG Business Object Domain Task Force RFP#2 Submission - Workflow Management Facility Revised Submission, OMG Document Number: bom/98-06-07, June 1998. [4] Object Management Group: Final Report of the Workflow Management FacilityRevision Task Force 1.2 OMG Document Number dtc/99-07-04, August 1999. [5] RosettaNet: http://www.rosettanet.org/ [6] Workflow Management Coalition: Interface 1: Process Definition Interchange Process Model Specification, Document Number WFMC-TC-1016, Version 1.1, October 1999. [7] Schulz, K. et al.: Implementation of the Distributed Workflow Service, D303 in EP 20408, Vega, http://cic.sop.cstb.fr/ILC/ecprojec/vega/workpack.htm, 1998. [8] Steinmann, R. et al.: Demonstration of Large Scale Engineering Enterprises - VEGA 5th Review Demonstration, D504 in EP 20408, Vega, http://cic.sop.cstb.fr/ILC/ecprojec/vega/workpack.htm, 1999. [9] Steinmann, R. et al.: Public Final Report, Document PFR01 EP 20408,Vega, http://cic.sop.cstb.fr/ILC/ecprojec/ vega/workpack.htm , 1999. [10] Workflow Management Coalition: Workflow Standard Interoperability - Abstract Specification, Document Number WFMC-TC-1012, Version 1.0, October 1996. [11] Workflow Management Coalition: Workflow Standard Interoperability -Wf- XML Binding, Document Number WFMCTC-1023, Draft, 11.January 2000. [12] Workflow Management Coalition: Successful Demonstration of Workflow Interoperability a Major Milestone, Press Release, http://www.aiim.org/wfmc/pr/pr1996-07-09.htm [13] IBM Research, Zurich, Crossflow Architecture Description, EP 28653, 17. May 1999. [14] EBXML http://www.ebxml.org/ [15] UML Profile for Enterprise Distributed Object Computing (EDOC), Initial submission by DSTC, ftp://ftp.omg.org/pub/docs/ad/99-10-07.pdf [16] Milosevic, Z., Arnold, D. and O'Connor, L. "Interenterprise Contract Architecture for Open Distributed Systems: Security Requirements". WET ICE'96 Workshop on Enterprise Security, Stanford, USA, June 1996. [17] Georgakopoulos, D. et al: Managing Processes and Services in Virtual Enterprises”, 1999.

Acknowledgements

The authors would like to thank Kerry Raymond, James Cole and Andrew Wood for their comments on this paper. The work reported in this paper has been funded in part by the Co-operative Research Centre Program through the Department of Industry, Science & Tourism, Australia.

10