A Framework for Process-based Collaborative Systems Design

Khoutir Bouchbout, Nassim Iklef and Sara Khaldoun

Computer Science Department, EMP Bordj-El-Bahri, Algiers, Algeria

Keywords: Collaborative Business Process, Model-Driven Approach, B2B, Web Services, E-ordering System.

Abstract: In today’s business world, collaborative systems can be realized by implementing Business-to-Business

(B2B) collaborations that entail a process-oriented integration among heterogeneous and autonomous

organizations. In this paper, we define a model-driven framework to design such collaborative systems. The

framework comprises three layers: an organizational layer, that focuses on business collaboration

requirements, a conceptual layer, to define the business process, and a technology layer, aimed at business

process execution. Hence, the framework combines business process management (BPM) concepts and

Web services technology. To build B2B collaborations both organizations have to provide public parts of

their process models as basis for discussion for collaborative process modelling. The internal private

processes are generated from collaborative process, based on model-driven approach (MDA). At the

execution level, B2B interactions are modeled based on Web services. Finally, we validate our proposition

with the implementation of an e-ordering system.

1 INTRODUCTION

The recent rapid development in the Internet based

communications, business process and information

system integration possibilities have contributed to

the emergence of cross-organizational

collaborations. It covers a broad spectrum of

applications that enable an organization to form

electronic relationships with its suppliers, customers,

and other partners (Bauer et al., 2006). Modern

business process management expands to cover the

partner organizations’ business processes across

organizational boundaries, and thereby supports

organizations to coordinate the flow of information

among organizations and link their business

processes, forming a

Collaborative Business

Processes (CBP). Henceforth, there is a need for

supporting and modelling CBP enabling the joint

execution of business collaboration. In order to

enable CBPs, information exchanges must increase

among all business applications involved to achieve

visibility of collaborative systems.

B2B interactions are declined under different

ways and using different technologies, listed from

old to recent as follows: (1) exchanging data via

traditional means such as fax, phone, and mail; (2)

using Electronic Data Interchange or email for data

interchange; (3) utilizing private or public exchanges

to share business process information; and (4)

deploying Web services and business process

management (BPM) tools to coordinate loosely

coupled services into integrated cross-organizational

processes with real-time data sharing (Chen et al.,

2007). Consequently, designing such collaborative

systems has raised growing interest among

information systems researchers (Lippe, 2005). This

is a hard work task and must be based on standards

and open technologies to support loose coupling,

autonomy, flexibility, and ensuring trust and security

(Bauer et al. 2005, Chebbi et al. 2007).

In this work, we mainly focus on the use of

business process modelling and Web services

standards in support of B2B collaborations. So, we

propose a design framework in a top-down manner,

beginning with the collaborative (inter-enterprise)

level as main business process template and after the

private (intra-enterprise) level as their sub-processes.

The structure of this document is as follows. In

section 2, we discuss the basic concepts of

collaborative business process. Section 3 analyses

the current literature on B2B collaboration design

frameworks. Subsequently, section 4 is the main

contribution of this paper, as it presents the details of

our framework. Next, section 5 assesses the

capabilities of proposed solution. Finally, section 6

draws some conclusions and outlines some further

research activities.

Bouchbout K., Iklef N. and Khaldoun S..

A Framework for Process-based Collaborative Systems Design.

DOI: 10.5220/0004992900900097

In Proceedings of the 9th International Conference on Software Engineering and Applications (ICSOFT-EA-2014), pages 90-97

ISBN: 978-989-758-036-9

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

Figure1: Basic scenario of ordering collaborative business process.

2 COLLABORATIVE BUSINESS

PROCESS

Recently, CBP are turning to be an important issue

of contemporary BPM. To explain specifics of CBP

modelling, we will discuss their requirements.

2.1 Characteristics of Collaborative

Business Process

CBP comprise activities executed by different

organizations that are working together to reach a

common business objective. So, CBP usually do not

have a centralized control instance or process owner

(Chebbi et al., 2006). Besides, it depicts the different

roles involved in the collaboration and their specific

responsibilities with regard to the collaboration

scenario. Hence, it requires an agreement on how to

interact and exchange information, business

documents and messages between business partners.

In addition, the privacy and autonomy

requirements are at the top priority of participant’s

organizations. Having this concern in mind, each

involved organization has to implement not only its

private processes but also its external behavior,

allowing better separation of the information density

of different areas of concern. So, three different

concepts are defined: Private (internal), Public

(abstract or view) and Collaborative (cross- or inter-

organizational) processes. In order to illustrate these

different process categories, Figure 1 presents

Business Process Modeling Notation (BPMN)

activities of an ordering process where buyer and

seller businesses collaborate together.

2.2 Collaborative Business Process

Modelling Languages

Although modeling CBP is a complex task, many

research efforts have been based on approaches for

distributed Workflow management, e.g. (Aalst et al.,

2001, Chebbi et al. 2006, Lippe et al. 2005), current

extensions of process language (Touzi et al., 2008),

and B2B standards like ebXML- electronic business

using eXtensible Markup Language (Dorn, 2007),

but has been limited to a single view point at time

(e.g. process layer) and they do not fulfill the

collaborative interactions issues with multiple view

points (both business and technological levels). This

is so because they should represent multiple actors

participating in each collaborative task while

keeping consistency of the overall processes. Hence,

most of the process languages such as UML AD –

UML Activity Diagrams, EPC – Event-driven

Process Chain, BPMN (OMG, 2011), BPEL –

Business Process Execution Language (Peltz, 2003)

and Web Service Choreography Description

Language (Dorn et al., 2007) provide insufficient

support for modelling CBP and do not offer a

collaborative and integrated modelling framework

comprising all levels of abstraction.

Having these considerations in mind, our

approach provides an UML profile (Dorn et al.,

2007) ensuring more expressive power for CBP

modeling. It provides a high level of abstraction on

which the partners first agree on the business goals

of their collaboration. It should cover comprehensive

aspects of CBP specifics such as interaction flow,

partner’s role, message exchanges, public and

private activities.

Receive

Request

for Quote

Send

Request

for quote

Send quote

information/

Rejection

Send

purchase

Order

Receive quote

information/

Rejection

Receive

Purchase

Order

Send order

Acceptation/

Rejection

Receive Order

Acceptation/

Rejection

Collaborative

Process

(global view)

Seller ‘s

Private

Process

Receive

Request

for Quote

Check

Product

availability

Prepare

Quote

Send quote

information/

Rejection

Receive

Purchase

Order

Check

Customer

Credibility

Send Order

Acceptation/

Rejection

Send

Request

for Quote

Send

Purchase

Order

Receive Quote

information/

Rejection

Receive order

Acceptation/

Rejection

Buyer’s

Private

Process

Purchase

Requisition

Evaluate

Quotation

Receive

Request

for Quote

Send Quote

information/

Rejection

Receive

Purchase

Order

Send order

Acceptation/

Rejection

Seller ‘s

Public

Process

Send

Request

for Quote

Send

Purchase

Order

Receive Quote

Information/

Rejection

Receive Order

Acceptation/

Rejection

Buyer ‘s

Public

Process

AFrameworkforProcess-basedCollaborativeSystemsDesign

3 RELATED WORK

The recent years brought a vast number of

publications around the collaborative systems topic.

We will briefly refer to some of them which are

achieved in the field of inter-organizational

Workflows or B2B collaborations (Aalst et al. 2001,

Lippe 2005, Greiner et al. 2006, Ziemann et al.

2007, Huemer et al. 2008, Legner et al. 2008, Touzi

et al. 2009). However, in contrast to this paper, they

miss some research clearly addressing holistically

the collaborative systems design at business, process

and technological levels. They are also rather vague.

Legner et al. (2008) have presented a method for

modelling inter-organizational processes and

deriving business services in three steps. A

framework of conceptual inter-organizational

business modelling is then defined containing a

public process model which serves as reference for

the participating organizations (Step 1). Then, the

existing private processes have to be assigned and

eventually aligned to the agreed public process

model (Step 2). After that, the public process

interface is realized by business services leveraging

web service technology (Step 3). The business

process model is used to derive XML-based business

documents that are exchanged between business

services. In addition, private process modules are

transformed into workflows for business process

automation which can be implemented using BPEL.

Another relevant contribution in this area is the

proposal made by Huemer et al. (2008). They have

developed a methodology dealing with collaborative

processes called United Nations/CEFACT

Modelling Methodology (UMM). UMM specifies

collaborative business processes involving

information exchange in a technology neutral,

implementation-independent manner. UMM is a

UML modelling approach for global choreographies

of B2B scenarios. It is a top-down approach that

makes use of worksheets to capture domain

requirements. UMM do not provide a complete

development process to generate CBP executions. It

only provides a development process for modelling

technology-independent CBP.

The work of Touzi et al. (2009), has proposed a

model-driven approach to design a collaborative

information system (CIS) dedicated to deal with

exchanged data, shared services and collaborative

processes. The CIS design crosses the different

abstraction layers (business, logic and technological)

and exploits at each level the associated models to

build the models of the next level. The model of a

CBP is BPMN-oriented and based on the SOA

(Service Oriented Architecture). Its meta-model has

been defined by referencing the BPMN

specifications as well as the CBP aspects.

The framework proposed by Ziemann et al.

(2007) presents a method for the creation of

collaborative process on a conceptual level. They

described how cross-organizational business

processes can be modelled and transformed to

technical process models in the form of Web Service

protocols. Their framework can be instantiated using

EPCs (design phase) and BPEL (implementation

phase) to describe models in different life cycle

phases and demonstrated the transitions between

these phases. However, a description of how

organizational roles can be communicated to

partners is missed.

Greiner et al.’s work (2006) describes the

designing and the implementing of cross-

organizational business processes including different

levels of technical detail: the business level, the

technical level and the execution level. They identify

how the mappings and the transformations are

needed among private process, view process and

CBP among the different levels. The business level

models illustrate the organizational business aspects.

The technical model secures the technical realization

of the process integration and represents the bridge

to the process execution.

Though significant research efforts, collaborative

systems design is neither taken up broadly nor can it

be considered a solved problem. Yet, while the

proposed solutions strive to enable the operation of a

CBP, no explicit consideration of generic business

process requirements, as viewed by the different

involved stakeholders (business analysts, process

designers and IT specialists), is made to relate to

generic collaborative scenarios by combining

business process and Web services. To the best of

our knowledge, generic business process modeling

and execution as Web services in the realm of

collaborative systems design as given in this paper

have not been published before.

4 THE PROPOSED MDA-BASED

FRAMEWORK

In order to establish B2B collaborations one may

start “bottom-up” from the private processes or “top-

down” from the CBP. In top-down design approach,

we note that the business requirements drive the

technology. It starts with a global view on the

collaboration efforts. This requires that the agreed

CBP was defined jointly, before, by the partners.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

In this work, we follow the top-down approach

because it is more appropriate for an e-Ordering

system. Hence, our approach helps to develop

partner’s public processes that are compliant to each

other. This is guaranteed by the fact that each

partner derives its public process consistently to a

commonly agreed CBP. It enables a process-based

collaborative systems development at both business

and technological levels, based on a MDA (Model-

Driven Architecture) approach (Bauer et al. 2005,

Frankel 2003). To define a valid separation between

business, software and technological platforms in the

information systems, MDA uses different kind of

models: (1) Computation Independent Model (CIM);

(2) Platform Independent Model (PIM); (3) Platform

Specific Model (PSM).

In addition, MDA approach is characterized by a

set of vertical transformations across different

phases (PIM to PSM and PSM to Code) using model

transformation languages like ATL - Atlas

Transformations Language (Bézivin et al. 2003,

Santos et al. 2013). A transformation definition is a

set of rules that, all together, describe how a model,

expressed in a source language, can be mapped into

a model in a target language.

Therefore, in Figure 2 we depict the proposed

framework which supports: the design of CBP

independent of particular process model standard;

and the automatic generation of each partner’s side

specifications based on a process model standard (in

our case BPMN and BPEL) from CBP models

(using UML AD profile). It is mainly based on the

technique of meta-model transformations

(Hammoudi et al., 2010)

.The proposed framework is

organized into three levels from the abstract

conceptual level (collaborative interactions) to the

technical execution level (Web services executed via

partner’s web sites).

The main benefits of our holistic framework are:

increase of the abstraction level, since the focus is

on the design of technology-independent CBP;

reduction of development costs and time and

guarantee of alignment of a business solution with a

technological solution, since process executions are

generated automatically from process models. We

present below in detail the different design phases

composing our framework.

4.1 Collaborative Business Agreement

Definition Phase

The collaborative business requirements phase at

CIM level consists in analyzing the problem domain

and identifying the collaborative business

requirements. This is jointly carried out by the

involved enterprises. CBP usually do not have a

centralized control instance or process owner.

Hence, it depicts the different roles involved in the

collaboration and their specific responsibilities with

regard to the collaboration scenario.

So, it needs close coordination among networking

partners which requires an agreement (common

objective that partners agree on) on how to interact

and exchange information, business documents and

messages.

Enterprise A: Seller

Enterprise B: Buyer

Transformation

Rules

Collaborative Business P rocess model definition

1-BPMN public process:

public view, behaviour

2- BPMN private process:

private activities, internal

business logic

3- BPMN formal verification

1- SOA/WS-BPEL, WSDL:

internal techno. Standards

2- BPEL formal verification

3- Internal code execution,

4- Buyer’s web application

1- SOA/WS-BPEL, WSDL:

internal techno. Standards

2- BPEL formal verification

3- Internal code execution,

4- Seller’s web application

1-BPMN public process:

public view, behaviour

2- BPMN private process:

private activities, internal

business logic

3- BPMN formal verification

Message’s Exchange

Invocation of services

CSF for B2B collaboration adoption, collaborative

requirements environnement, common objective,

interactions p rotocol, informations exchange

Derivation

Rules

Transformation

Rules

CIM: Collaborative

business layer

PIM:

Collaborative

process layer

PIM: Public &

Private partner’s

processes layer

PSM: Partner’s

internal code

execution layer

Business

level

Process

level

Technology

level

Figure 2: MDA-based method for B2B systems development.

AFrameworkforProcess-basedCollaborativeSystemsDesign

4.2 Collaborative Process Modelling

Phase

In this work, modelling CBP follows an MDA-based

approach (Santos et al., 2013), proposing a set of

models at different levels of abstraction and model

transformations to connect them, as depicted in

Figure 3.

At the PIM level, we model CBP using an

UML AD profile based on extended process meta-

model. The use of this meta-model and UML profile

add semantics and constraints to the UML AD meta-

model (with stereotypes, constraints and tagged

values) and provide a vocabulary more suitable to

model CBP. In addition, this language encourages a

top-down approach to model CBP and provides the

conceptual elements to support the modelling of

CBP main aspects:

- Definition of the participants (partners and their

collaboration roles) of a CBP with their

communication relationships with description of the

common objective that partners agree on.

- Definition of collaborative business processes

(interorganizational) as informal specifications of a

set of activities performed by partners.

- Representation of business documents to be

exchanged in CBP with providing the concepts to

define their syntactic and semantics structure.

- Description of the public interfaces of each

collaboration role performed by partners. A public

business process contains business operations that

support the asynchronous message exchange of

interactions between partners.

However, it is essential to enable partners to

make sure the correctness of the execution of CBP.

This formal verification task is concerned to check

the process model is free of logical errors such as

deadlocks, livelocks, etc. (Aalst et al., 2010). Hence,

in order to verify the correct execution of the process

models, we developed a formal verification software

tool using Petri Nets. So, we can easily verify UML

AD, BPMN and BPEL business process models.

4.3 Generation of Partner’s Public

Processes Phase

As we are shown before, CBPs are not executable.

Hence, CBP requires the definition of public and

private processes each organization has to

implement for executing collaborative process. A

public process defines the public behavior of the role

an organization performs in a CBP at PIM layer. It

defines the externally visible behavior of a business

partner in terms of the activities that support the

receiving and sending of messages and business

documents with each other.

By deriving public process from the CBP, we

ensure that the semantics of each CBP element is

represented in terms of the elements and semantics

provided by BPMN from one partner’s viewpoint

(e.g. seller or buyer) as depicted before in Figure 2.

This is represented by the fact that UML AD model

applies UML AD profile as depicted in Figure 3 (by

means of discontinued red arrow).



conforms‐to

model‐to‐model

transformation

edit

applies

Ecore

Eclipse UML2

Editor

Intalio BPMN

Editor

Eclipse UML2

Metamodel

UML2 Activity

Diagram Model

Eclipse UML2

Profile

UML2 Activity

Diagram Procurement 

Eclipse BPMN

Metamodel

ATL

Metamodel

UML2BPMN.atl

BPEL & WSDL

metamodels



Seller.bpmn

Buyer.bpmn

Ecore



BPEL Model

WSDL Model

Buyer & Seller.bpel

Buyer & Seller.wsdl

BPEL & WSDL

Editor

BPMN2BPEL

Eclipse

BPMN Model

conforms‐to

applies

model‐to‐modeltransformation

edit

Figure 3: Process model transformations engine.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

For this purpose, we define automated process

model transformation engine (see Figure 3).

Henceforth, UML Activity Diagram and BPMN

models have some elements share the same semantic

meaning. These elements are transformed directly

without considering about the element context or

neighbourhood elements (one-to-one transformation

rule). In addition, some UML Activity Diagram

element types cannot be transferred directly to

BPMN elements. To be able to remain the same

semantic meaning, two or more elements in BPMN

will be translated to one UML Activity Diagram

element (many-to-one transformation rule).

4.4 Definition of Partner’s Private

Processes Phase

The private executable process is derived from a

public process at each partner’s side (see Figure 3).

It adds the private logic of the enterprise required to

achieve the role within a global CBP. The internal

business logic includes the activities for producing

and processing the exchanged information/

documents as well as data transformations and

invocations to internal systems. Internal or private

activities (see the seller’s private activities of Figure

1), which are required for generating the information

to be sent and processing the information to be

received from partners, have to be added to the

public process to define the private process.

In our case, in order to realize the BPMN-to-

BPEL process model transformation, we implement

an algorithm inspired from Ouyang et al. (2009),

namely BPMN2BPEL. It takes as input a BPD

(BPMN Business Process Diagram) represented in

XML format and produces the correspondent BPEL

code as an XML file.

However, it is difficult to develop complete

translation rules, so the result of the translation

needs validation from process modeler.

Consequently, we can use the transformation rules

as a semi-automation translation method to reduce

the time for him when translating the process models

manually.

Beside the process model transformation engine,

we consider the business processes as the key focal

point of Web services design. Henceforth, each of

the activities in the process model must be

implemented with one or more services. Below we

describe this task in two steps:

Step1: Determine objectives and describe the

business process structure: The first step in the

service design is to determine the business process

objectives and describe the business structure and

the functions of the business process. The business

process structure refers to the logical flow or

progression of the business process. The functions of

a business process are expressed in terms of the

activities or the services that need to be performed

by a specific business process.

Step2: Describe business activity responsibilities

(roles): The second step in the service design is to

identify responsibilities associated with business

process activities and the service providers that are

responsible for performing them. Each activity

within a business process is associated with a

particular Web service provider who fulfils a defined

role (responsibility) within the process. Each service

provider is expected to properly fulfill the business

responsibility of implementing the Web service, or

set of Web services, which perform that activity

within the process under the role that the provider is

expected to undertake.

4.5 Code Execution and User

Interfaces Phase

CBP provides a global or public view on participants

collaborating in a peer-to-peer fashion by offering

distributed Web services in order to achieve a

common business goal. This step deals with the user

interface applications development for the “seller”

and the “buyer” roles in an ordering system.

Furthermore, on the execution layer these internal

processes are used e. g. for the orchestration of Web

services (Peltz, 2003). It consists on the generation

of the XML-based specifications of business

processes and the collaborative systems’ interfaces

of an organization from its platform-specific IT

model, which contains the necessary information for

the code generation.

To this aim, we have implemented a direct

connection with the business applications of the

buyer organization communicating directly with a

seller's web application to send and receive

information. After collaborating, both of the two

partners’ applications progress independently.

5 IMPLEMENTATION OF A

COLLABORATIVE SYSTEM

In order to validate our approach, a tool support is

essential. For this purpose, we have implemented an

e-Ordering system. The main objective of the order

fulfillment process that buyer expected is supplier

can deliver qualified products to fulfill its orders at

AFrameworkforProcess-basedCollaborativeSystemsDesign

the right time and right place. So, buyer and supplier

have to collaborate by sharing and exchanging

business information.

To this aim, we use an Eclipse-based integrated

platform (Eclipse, 2011) to guarantee the

interoperability of the different plug-ins, tools and

ATL transformation languages. Thus, we develop an

Eclipse-based ATL code for the building of process

model transformations (e.g. from collaborative to

specific BPMN). In this way, the derivation of the

private process (e.g. seller) from the CBP ordering

process is carried out with this ATL tool.

In this work, we implement the basic

collaborative process scenario, where a buyer

(University) makes an online order to a seller

(Suppliers), who processes and fulfils the order, as

shown in Figure 4. Hence, we implemented an e-

Ordering application for each partner’s side,

representing activities of executable business

processes as Web services. So, interactions between

seller and buyer are achieved as invocation of

partner’s services.

FIREWALL

Intranet

e-Ordering system platform architecture

Solicitation

Automation

E-Procurement

University’s procurement dept. Suppliers

Procurement

Agents

Requests

Responses

HTML

Campus

Agents

Internet

FIREWALL

On-line Seller Organizations

Figure 4: Architecture of e-ordering system.

Figure 5 shows the process model transformation

to executable BPEL code generation implementing

web services as mentioned before in section 4.5.

In addition, we have developed in parallel a

software tool implementing formal verification

techniques which have to be applied to

corresponding Petri Nets representation of business

process. This tool is applied at the three framework

levels (verification of UML AD, BPMN and BPEL

business process models). Four verification

properties (Deadlock, bounded, liveness and quasi-

liveness) are implemented as shown in the right side

of Figure 6 of the process of the example depicted

before in Figure 1.

6 CONCLUSION

In the frame of this work, we have proposed a

MDA-based framework for designing collaborative

systems. It combines the concepts of BPM and Web

services technologies. We defined collaborative

business process model. Thereafter, the specific

partner’s processes are derived from the

collaborative process. Moreover, the collaborative

B2B interactions between partners are represented,

using Web services technology, at executable level.

Finally, there are several open issues to address

in the future. Thus, we plan to evaluate our

framework through a scenario with three business

partners (enterprise, supplier and shipper) in order to

verify the completeness and generality of the

proposed concepts and artifacts. Another aspect that

requires further research is to investigate the explicit

support of heterogeneity of data formats and

messages using the ontology concepts.

The input ATL query (sample):

The generated executable BPEL code (sample) from the Eclipse file ‘bpel2code.atl’:

Figure 5: Process model transformation to executable BPEL code.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

Figure 6: Verification of ordering process properties using Petri Net based software tool.

REFERENCES

Aalst Van der W.M.P. and Weske M. 2001. The P2P

approach to Interorganizational Workflows. In Proc.

of CAiSE'01, LNCS Vol. 2068, pp.140-156. Springer.

Aalst van der W. M. P., Van Hee K., ter Hofstede A.,

Sidorova N., Verbeek H., 2010. Soundness of

Workflow Nets: classification, decidability, and

analysis. Formal Aspects of Computing, pp. 1-31.

Adam, Hofer, Zhang, 2004. Cross-Enterprise Business

Process Management Architecture – Methods and

Tools for Flexible Collaboration, In Proc. of MIOS.

Bauer B., Müller P., and Roser S., 2006. A Decentralized

Broker Architecture for Collaborative Business

Process Modelling and Enactment, In Proc. of the 2nd

Int. Conference IESA’2006, pp. 115-126.

Bauer B. Muller J.P ., Roser S., 2005. A model-driven

approach to designing cross-enterprise business

processes, Volume 3292 of LNCS, Springer,.

Bézivin, J., Dupé, G., Jouault F., 2003. First Experiments

with the ATL Model Transf. Language: Transforming

XSLT into XQuery, In proc. of 2nd OOPSLA.

Chebbi I., Dustdar S., Tata S., 2006. The view-based

approach to dynamic inter-organizational workflow

cooperation, DKE, Vol. 56, pp.139-173.

Chen M., Zhang D., Zhou L., 2007. Empowering

collaborative commerce with Web services enabled

business process management systems, Decision

Support Systems, Vol.43, pp. 530-546.

Dorn J., Grün C., Werthner H., and Zapletal M. 2007. A

Survey of B2B Methodologies and Technologies:

From Business Models towards Deployment Artifacts.

Proceedings of HICSS’07, USA.

Eclipse Oranisation: Eclipse Platform, URL:

http://www.eclipse.org , accessed on June 2012.

Frankel D.S., 2003. Model Driven Architecture –

Applying MDA to Enterprise Computing. Wiley.

Greiner, U., Lippe, S., Kahl, T., Ziemann, J. 2006.

Designing and implementing cross-organizational

business processes. In Proc. of I-ESA’2006.

Hammoudi S., Alouini W., Lopes D., Huchard M.

2010. Towards A Semi-Automatic Transformation

Process in MDA: Architecture, Methodology and First

Experiments. IJISMD, Vol.1 Issue 4, pp. 48-76.

Huemer C., Liegl P., Schuster R., Werthner H., and

Zapletal M., 2008. Inter-organizational Systems: From

Business Values over Business Processes to

Deployment. Proc. of DEST’2008.

Legner C., Vogel Tobias, Löhe Jan, 2008. Transforming

Inter-Organizational Business Processes into Service-

Oriented Architectures. Method and Application, In

Proc. of KiVS’2007, Switzerland.

Lippe, Greiner, Barros, 2005. A Survey on State of the Art

to Facilitate Modelling of Cross-Organisational

Business Processes. In Proc. of XML4BPM 2005.

Santos N., Duarte F.J., 2013. A Transformation of

Business Process Models into Software-Executable

Models Using MDA, LNBIP Vol.133, pp 147-167.

OMG: BPMN 2.0, 2011. available at:

http://www.omg.org/BPMN/, accessed on June 2012.

Ouyang, C., Dumas, M., Aalst, W. M. P., Ter Hofstede,

A.H.M., 2009. “From business process models to

process-oriented software systems”, ACM Trans. on

Software Eng. Methodology, Vol. 19(1), pp.1-37.

Peltz Chris, 2003. Web services Orchestration and

Choreography, IEEE Computer, 36(10), pp.45-52,

Touzi J., Bénaben F., 2009. A Model-driven approach for

collaborative service-oriented architecture, Int. J. of

Production Economics, Vol. 121 No 1, pp. 5-20.

Ziemann Jorg, Matheis Thomas, Freiheit Jorn, 2007.

Modelling of Cross-Organizational Business

Processes, Proceedings EMISA’2007, LNI, Vol.119,

pp.87-100.

AFrameworkforProcess-basedCollaborativeSystemsDesign