Software Engineering Group Department of Computer Science Nanjing University http://seg.nju.edu.cn

Technical Report No. NJU-SEG- 2007-IJ-001

A model-driven development framework for

enterprise Web services

Xiaofeng Yu, Yan Zhang, Tian Zhang, Linzhang Wang,

Jun Hu, JianHua Zhao, Xuandong Li

Postprint Version. Originally Published in: Information Systems Frontiers,

Vol.9, No.4, Springer, 2007, pp.391-409.

Most of the papers available from this document appear in print, and the corresponding copyright is held by the

publisher. While the papers can be used for personal use, redistribution or reprinting for commercial purposes is

prohibited.

Inf Syst Front (2007) 9:391–409DOI 10.1007/s10796-007-9042-7

A model-driven development framework for enterpriseWeb services

Xiaofeng Yu · Yan Zhang · Tian Zhang ·Linzhang Wang · Jun Hu · JianHua Zhao ·Xuandong Li

Published online: 21 July 2007© Springer Science + Business Media, LLC 2007

Abstract The growing scale and complexity of the en-terprise computing systems under distributed and het-erogeneous environments present new challenges tosystem development, integration, and maintenance. Inthis paper, we present a model driven Web servicedevelopment framework to combat these challenges.The framework capitalizes on the unified modelinglanguage (UML) profile for enterprise distributed ob-ject computing (EDOC), MDA (model-driven archi-tecture) and Web services. Within the framework,firstly, a general PIM (platform independent models) iscreated using the EDOC CCA structural specificationand CCA choreography specification which defines thegeneral functions of a system. Secondly, the generalPIM is broken down into sub-PIMs according to func-tional decomposition, each of which can provide serviceindependently and will be implemented in a Web ser-vice. Thirdly, all of the PIMs are transformed to Webservice interface models for publication and invoking.Afterward, transform each PIM to a BPEL specifiedWeb service orchestration model. Finally, supported bymodel transform techniques, the sub EDOC PIMs areimplemented into Web services on specific platforms.Automatic model transformation is the key to thisframework, therefore, the transformation from EDOC

X. Yu (B) · Y. Zhang · T. Zhang · L. Wang · J. Hu ·J.-H. Zhao · X. Li (B)State Key Laboratory for Novel Software Technology,Department of Computer Science and Technology,Nanjing University, Nanjing 210093, P.R. Chinae-mail: yuxiaofeng@seg.nju.edu.cn

X. Lie-mail: lxd@nju.edu.cn

CCA models to WSDL specified Web service inter-face models and the transformation from EDOC CCAmodels to BPEL specified Web service orchestrationmodels are deeply discussed, and the detailed trans-formation rules are proposed. A case study is alsoprovided to demonstrate the effectiveness of these rulesand the merits of this framework.

Keywords Model-driven development · EDOC ·Web services

1 Introduction

The scale and complexity of the enterprise informationsystems (EISs) have grown rapidly in recent years,and the system environments have become much morecomplicated than before. Nowadays, it is a huge chal-lenge to solve the problems such as system interaction,system portability and system reuse, under distributedand heterogeneous environments. Nevertheless, it istoo hard and expensive to solve these problems basedon only one of the existing technologies. A possible wayto deal with these problems may be the synthesizeduse of software modelling, software architectures andsoftware methodologies.

The model-driven architecture (MDA; OMG 2001b)initiated by Object Management Group (OMG) is anew software development method which can improvesoftware portability (Soley and the OMG Staff StrategyGroup 2000). The UML profile for EDOC (OMG2001c) is a modeling language which conforms to MDAand provides facilities to model distributed componentbased enterprise computing. Web services technologiesintroduce a new software paradigm which can improve

For Research Only

392 Inf Syst Front (2007) 9:391–409

software reuse effectively. Therefore, we propose amodel driven development framework in this work,based on the EDOC profile, MDA and Web services.The framework can provide a realistic and economicalsolution to EISs under distributed and heterogeneousenvironments. The main point of the framework is:Firstly, a PIM expressed using the EDOC profile isbuilt at the design stage to specify general businessfunctions of an EIS. Secondly, the general PIM is bro-ken down according to functional decomposition intosub PIMs each of which can provide computing serviceindependently and will be implemented in a Web ser-vice. Thirdly, transform each sub PIM to the interfacemodel of its corresponding Web service. Then, trans-form each sub PIM into BPEL specified Web serviceorchestration model. Finally, implement each sub PIM,through model transformation, on specific platformswhich support Web services development. Automatictransformation from EDOC models to WSDL speci-fied Web services interface models and BPEL specifiedWeb services orchestration models is the pivotal tech-nology of this framework and is deeply discussed.

The rest of this work is structured as follows.Section 2 gives an overview of the research back-ground. Section 3 presents the model driven develop-ment framework for Web services based EISs. Section 4analyzes the transformation from EDOC models toWeb services interface models and provides the de-tailed transformation rules. Section 5 proposes trans-formation rules from EDOC models to Web servicesorchestration models. Section 6 chooses an E-Store sys-tem as a case study exemplifying the usage and merits ofthe framework and transformation rules. The last twosections discuss the related work and concludes.

2 Background

Currently, MDA and Web services are hot issues inboth academia and industry. MDA is a framework forthe creation, implementation, evolution and deploy-ment of systems driven by models. Web services areemerging as promising technologies and architecturesfor implementing distributed EISs and performingapplication integration within and across enterpriseboundaries. Web services are becoming important tar-get models of MDA. Modeling and model trans-formation are vital to the success of MDA. UMLis a reasonable candidate modeling language in thecontext of MDA. In order to extend UML to modeldistributed component based computing, OMG adopt-ed the EDOC profile. The EDOC profile extendsUML 1.4 and conforms to MDA, and provides

facilities to model distributed enterprise computing.To define a standard model transformation language,OMG initiated in 2002 the standardization process formeta-object facility (MOF) 2.0 Query/ Views/ Transfor-mations (QVT) (OMG 2002). Driven by practical needsand the OMG’s request, many approaches to modeltransformation have been proposed, such as Braunand Marschall (2002), QVT Partners (2003), Patrascoiu(2004b), ATLAS Group (2005) and DSTC and IBM.In 2005, OMG published the MOF QVT final adoptedspecification (OMG 2005). This specification will be astandard approach for defining model transformation.

2.1 MDA (model-driven architecture)

MDA is a new way of developing applications and writ-ing specifications. MDA focuses on separating systemfunctions from the platforms that the system will beimplemented on. In order to divorce business functionsfrom implementation details, MDA makes models thefirst entities in systems, and makes model transforma-tion the key technology. There are two main kinds ofmodels in the context of MDA which are platform in-dependent models (PIMs) and platform specific models(PSMs). PIMs specify the functions of a system withouttaking into consideration of the technology platformsof the system. Whereas PSMs specify technical detailsof the platform that the system will be implemented on.In a MDA conformed model driven software develop-ment process, PIMs are created at first, then PIMs aretransformed into PSMs, finally, PSMs are transformedinto implementation code on specific platforms. Au-tomatic model transformation is the core technologyof MDA.

With MDA, functionality and behavior are modeledonce and only once, and the same PIM can be usedmany times to generate models on different platformsthrough automatic or semi-automatic model transfor-mation. MDA brings the benefits of increasing softwareportability (Klepper et al. 2003), improving softwarereuse (Gerber et al. 2002), and easing the task of sup-porting new or different technologies.

2.2 Web services

Service-oriented computing (SOC) is a new paradigmfor distributed computing and e-business processing.SOC enables building agile networks of collaboratingbusiness applications distributed within and across or-ganizational boundaries. Web services are the currentmost promising technologies based on the idea of SOC,and are self-describing, self-contained, modular com-ponents that can be published, located, and invoked

For Research Only

Inf Syst Front (2007) 9:391–409 393

across the web via standard interfaces and protocols.The key technologies of Web services are XML (ex-tensible markup language; Birbeck 2001), Web ServicesDescription Language (WSDL; W3C 2004a), Univer-sal Description, Discovery, and Integration (UDDI;UDDI 2004), and Simple Object Access Protocol(SOAP; SOAP 2004b). XML is used to define datatypes for Web services. WSDL is a XML based defi-nition language which is used to describe the abstractinterfaces for Web services. WSDL defines the syn-tax necessary for customers to call up a Web service.UDDI defines how to register, publish and find a Webservice. SOAP is a XML based light weight protocolto exchange information in decentralized and distri-buted systems.

There has been many research on some aspects ofWeb services, such as service modeling (Cao et al.2003), service composition (Yang 2003) and servicesecurity (Tang et al. 2006) and searching (Dong et al.2004). However, we use Web services as the targetmodels of our model driven development framework.

2.3 The UML profile for EDOC

The UML Profile for EDOC (OMG 2001c) conformsto MDA and provides facilities to model distributedcomponent based enterprise computing. The EDOCprofile consists of several profiles each of which isconstituted by a set of profile elements. The componentcollaboration architecture (CCA) is the core profileelement of the EDOC Profile. CCA models the struc-ture and behavior of the components that comprise asystem in a platform independent way. In our approach,the structural aspects PIMs are specified with CCAstructural specification, whereas the behavioral aspectsof PIMs are specified with CCA choreographies.

2.4 QVT (Query/Views/Transformations)

Because queries, views and transformations are sub-jects that will be vital to the success of the MDAinitiative, OMG initiated in 2002 the standardizationprocess for MOF 2.0 Query/Views/Transformations(OMG 2002). Since then, a large number of approachesto model transformation have been proposed, such asBraun and Marschall (2002), QVT Partners (2003),Patrascoiu (2004b), ATLAS Group (2005). In 2005,OMG published the MOF QVT final adopted speci-fication (OMG 2005). Because the MOF QVT FinalAdopted Specification is currently an OMG standardfor defining model transformations, we define transfor-mation rules in our framework using this specification.

The QVT Final Adopted Specification has a hybriddeclarative and imperative nature which is caused bythree QVT languages. These languages are Relations,Core and Operational Mappings. Relations and Coreare declarative languages which are at two differentlevels of abstraction. Operational Mappings is an im-perative language that extends Relations and Core lan-guages. To make a trade off between expressivenessand simplicity, the transformation rules are definedusing the Operational Mappings language in this work.The details of the QVT specification and the Opera-tional Mappings language references to OMG (2005).

3 Model-driven development framework

In order to explore a systematic solution to EISs, wepropose a model driven development framework as de-picted in Fig. 1. The development process that conformsto this framework is: Firstly, a PIM describing generalbusiness functions of an information system is builtusing the EDOC profile. Secondly, the general PIMis broken down according to functional decompositioninto sub PIMs each of which can provide computingservice independently, and will be implemented in aWeb service. Thirdly, transform each sub EDOC PIMto a WSDL file which defines the interface of the Webservice corresponding to this PIM. Then transform eachsub EDOC PIM to a BPEL process for service com-position. Afterward, implement each sub EDOC PIMinto a Web service, through a series of model trans-formations, on specific platforms that support Webservices development. Finally, deploy and publish allthe generated services. In this way, a distributed andheterogenous EIS is implemented by several Web ser-vices transformed from those sub EDOC PIMs. Theframework provides systems with the ability to achieveheterogeneous interaction, portability, and high levels

...

EDOC PIM

Web Service 1

EDOCPIM1

WSDLWeb Service 2

Implementation Platform 1

Functional Decomposition

Web Service n

EDOCPIM2

EDOCPIMn

mapping mapping

Implementation Platform 2 Implementation Platform n

BPEL

WSDL

BPELmapping

WSDL

BPEL

mappingmappingWSDL BPEL

map

pin

g

map

pin

g

map

pin

g

Fig. 1 The model driven development framework

For Research Only

394 Inf Syst Front (2007) 9:391–409

of software reuse due to the fact that it is based onMDA, and Web services.

The transformation from EDOC models to Web ser-vices interface models, the transformation from EDOCmodels to BPEL specified Web services orchestrationmodels, and the transformation from EDOC modelsto Web services implementation models on specificplatforms, are pivotal to the development framework.Because Web services can be implemented by EJBsand we have already mapped EDOC models to EJBsin Jiang et al. (2005), the transformation from EDOCmodels to Web services implementation models isstraight forward. However, there has not been sys-tematic research on the transformation from EDOCmodels to Web services interface models and BPELspecified orchestration models. Therefore, we willdeeply discuss these two kinds of transformations andgive detailed transformation rules in the upcomingsections.

4 From EDOC models to Web servicesinterface models

The interface models of Web services are describedwith WSDL, and the EDOC models in the devel-opment framework are mainly described with theCCA structural specification in this work, thereforethe transformation from EDOC models to Web ser-vices interface models is mapping from CCA structuralspecification meta-model to WSDL meta-model. Wedivide this mapping into two steps in order to reusetransformation rules: the first step is to map CCA datatypes to WSDL data types, and the second step is tomap CCA structural elements to WSDL elements.

4.1 From Document Model to W3C XML schema

In the EDOC profile, the information manipulatedor exchanged during a business process is describedusing Document Model, however, the information inWeb services is described using W3C XML schema.Therefore, the first step in the mapping from CCAto WSDL is to map Model Document to W3C XMLschema. For the purpose of clarity, we do not coverall the elements of CCA Structural Specification andWSDL in this article, but focus on the primary elementsof them.

Figure 2 shows the central elements of Docu-ment model: DataElement, DataType, Enumerationand CompositeData. DataElement is the abstract su-pertype of all data types. DataType is a primitive datatype, such as an integer and string. Enumeration defines

PortOwner

Port

DataElement

CompositeData

+type

+type

0..*+attrs

Document Model

EnumerationValue

+initial

1

1 *

+enumeration

+values

+owner1

0..* +features

1

1..*

+owner

+ports

ProtocalPort

OperationPort

FlowPort

DataType

Enumeration

Attribute

ProcessComponent

Protocol

uses

1

Fig. 2 A simplified CCA meta-model

a type that may have a fixed set of values. Composite-Data is a data type composed of other types in the formof attributes.

Figure 3 shows the primary elements of XMLschema:PrimitiveDataType,SimpleType, andComplex-Type. PrimitiveDataType is a type, such as string andfloat, that is not defined in terms of other data types.SimpleType is a type with a set of constraints on stringsand information about the values they encode. TheComplexType is a type with a set of attribute declara-tions and a content type.

Based on semantic equivalence analysis, we proposethree transformation rules implementing the transfor-mation from all the data types in Document Modelto XML Schema data types. The description of theserules are depicted in Table 1 in which DM represents

1

1

+services

0..*

1

+parts

0..*

1

Definition

Binding PortPortType

+portTypes +bindings0..* 0..*

PortTypeOperation BindingOperation

WSDLElement

ExtensibleElementMessagePart

1

+restrictions* 1

1*

TypePrimitiveDataType

ComplextType

Enumeration

Attribute

Restriction

1

+type

SimpleType

XML Schema

+operations0..*

1

+operations0..*

1

OperationInput

-name : String-message : Message

Output

-name : String-message : Message

Fault

-name : String-message : Message

Service

+ports0..*

1

0..10..1 0..1

+messages

+types0..*

Fig. 3 A simplified WSDL meta-model

For Research Only

Inf Syst Front (2007) 9:391–409 395

Table 1 The rules mapping from DM to WXS

Rule Name Input (DM) Output (WXS)

dt2pdt DataType PrimitiveDataTypeString stringInteger intFloat floatDecimal decimalBoolean BooleanDate date

en2st Enumeration SimpleTypecd2ct CompositeData ComplexType

document model, and WXS represents W3C XMLSchema. The QVT specified implementation of theserules are shown in Figs. 4, 5 and 6 respectively.

4.2 From CCA to WSDL

Mapping from CCA to WSDL is the second step imple-menting the transformation from CCA models to Webservices interface models. This mapping is implementedvia a set of transformation rules which make the CCAStructural Specification meta-model (see Fig. 2) as thesource model and the WSDL meta-model (Fig. 3) asthe target model. To simplify writing transformationrules, we need to preprocess the elements of the CCAStructural Specification meta-model at first. Then wewill propose transformation rules according to semanticequivalence analysis.

Figure 2 shows the main elements of the CCA Struc-tural Specification meta-model:

– ProcessComponent - It describes the contract fora component which performs actions via a set ofPorts.

transformation dt2pdt(in dm:DM, out wxs:WXS)main(){

dm.objectsOfType(DataType)→ map dt to pdt();}mapping DataType::dt to pdt():PrimitiveDataType{

if self.name = ’String’name := ’string’;

elsif self.name = ’Integer’name := ’int’;

elsif self.name = ’Float’name := ’float’;

elsif self.name = ’Decimal’name := ’decimal’;

elsif self.name = ’Boolean’name := ’Boolean’;

endif;elsif self.name := ’Date’;name := ’date’;

endif;}

Fig. 4 The transformation rule dt2pdt

transformation en2st(in dm:DM, out wxs:WXS)main(){

dm.objectsOfType(Enumeration)→map en to st();}mapping Enumeration::en to st(): SimpleType{

var evs := self.values();var wen : WXS::Enumeration;var rs : WXS::Restriction;evs→forEach(ev){

wen.value := ev.name;rs.enumeration := rs.enumeration→ including(wen);rs.base := this.initial.type;

}name := this.name;restriction := rs;

}

Fig. 5 The transformation rule en2st

– Port - It represents a point of interaction betweenProcessComponents.

– FlowPort - It is a Port which produces or consumesa single data type.

– OperationPort - It represents the typical call/returnpattern of an operation. It is a PortOwner con-strained to contain only two FlowPorts, exactly oneof which must have its direction set to ‘initiates’,and exactly one of which must have its direction setto ‘responds’ and have its postcondition set to ‘suc-cess’. An OperationPort may contain several otherFlowPorts with ‘responds’ direction and have itspostcondition not set to ‘success’. Such FlowPortsare used in fault handling.

– ProtocolPort - It defines complex two-way interac-tions between components.

The primary elements of the WSDL meta-model areshown in Fig. 3:

– Definition - A container for WSDL components andtype system components.

– Type - The abstract data types used to definemessages.

– Message - It describes the structure of a messageexchanged in a Web service.

– Part - It describes a portion of a particular message.

transformation cd2ct(in dm:DM, out wxs:WXS)main(){

dm.objectsOfType(CompositeData)→map cd to ct();}mapping CompositeData::cd to ct(): ComplexType{

var ats := cd.feature→ select(e |e.oclIsTypeOf(DM::Attribute));var att : WXS::Attribute;var seq := WXS::Sequence;ats→forEach(at){

att.name := at.name;att.type := at.type.resolveone(#WXS::Type);seq := seq→ including(att);

}name := this.name;sequence := seq;

}

Fig. 6 The transformation rule cd2ct

For Research Only

396 Inf Syst Front (2007) 9:391–409

Table 2 The rules mappingfrom CCA to WSDL Rule Input(CCA) Constraint Output(WSDL)

fp2mg FlowPort Messagefp2ptop FlowPort not in <PortTypeOperation>

OperationPort with only <input>op2pto OperationPort dir = responds <PortTypeOperation>

with<input>,<output>pp2ptt ProtocolPort directly in PC <PortType>pp2bd ProtocolPort directly in PC <Binding>pp2pt ProtocolPort directly in PC <Port>pc2s PC <Service>pc2d PC <Definition>cca2wsdl PC WSDL file

– PortType - It specifies a subset of abstract opera-tions of a Web service.

– PortTypeOperation - An operation of a givenPortType.

– Binding - It describes the way a service is accessed.– BindingOperation - It describes a concrete binding

for a particular operation of a PortType to a partic-ular concrete Message format.

– Service - It describes the set of Ports a serviceprovides.

– Port - It defines a specific end-point at which a givenservice is available.

A CCA FlowPort or OperationPort maybe di-rectly contained in a ProcessComponent, or indirectlycontained via a containing ProtocolPort. Therefore,to simplify the transformation process, we assign acognominal ProtocolPort to contain the FlowPort orOperationPort which is directly contained in a Process-Component.

In CCA, a FlowPort which is directly containedin a ProcessComponent or a ProtocolPort repre-sents a Port which manipulates a single input or out-put dataflow. However, a FlowPort contained in anOperationPort only represents an input dataflow or anoutput dataflow. In WSDL, Message describes theinformation a Web service sends or receives, and Port-TypeOperation describes an operation on this infor-mation. Although the base WSDL structure supportsdefinitions for four operations, WSDL only definesbindings for the One-way and Request-response oper-ations. Therefore, for a CCA FlowPort not containedin an OperationPort: if its direction is ‘responds’, itis equivalent in semantic to a WSDL Message anda PortTypeOperation, otherwise, it is only equivalentto a WSDL Message. Nevertheless, a CCA FlowPortcontained in an OperationPort is only equivalent toa WSDL Message no matter its direction is ‘initi-ates’ or ‘responds’. A CCA OperationPort representsthe typical call/return pattern of an operation, hence,it is equivalent to a WSDL PortTypeOperation. The

interface of a CCA ProcessComponent is provided byits directly owned ProtocolPorts after transformationpreprocessing. The interface of a Web service is de-scribed by the combination of PortTypes, Bindings andPorts. Consequently, a CCA ProtocolPort is equivalentto a combination of a WSDL PortType, a Binding and aPort. System functions are implemented by interactiveProcessComponents in CCA. The Service componentcontained in a WSDL Definition represents functionsa Web service provides to customers. Thus, a CCAProcessComponent is equivalent to a combination ofa WSDL Service and its container Definition.

Based on above analysis, we design the transforma-tion rules which maps the CCA structural specificationelements to semantic equivalent WSDL elements (see.Table 2, dir is short for direction, PC is short for ProcessComponent). To aid these rules to implement the trans-formation process, three helper functions are designed(see Table 3).

– The rule fp2mg maps a FlowPort to a WSDL-Message.

– The rule fp2ptop maps a non-OperationPort-owned FlowPort to a WSDL <PortType-Operation> which only has <input> attribute.

– The rule op2ptop maps a CCA ‘responds’OperationPort to a WSDL <PortTypeOperation>

which has <input>, <output> and <fault>attributes.

Table 3 The helper functions for the mapping from CCA toWSDL

Function Description

getAllFlowPorts Retrieves all FlowPorts directlyor indirectly contained in a ProtocolPort

getAllOperationPorts Retrieves all OperationPorts directlyor indirectly contained in a ProtocolPort

getFlowPorts Retrieves all non-OperationPort-ownedFlowPorts contained in a ProtocolPort

For Research Only

Inf Syst Front (2007) 9:391–409 397

transformation fp2mg(in cca:CCA, out wsdl:WSDL)main(){

cca.objectsOfType(FlowPort)→map fp to mg();}mapping FlowPort::fp to mg(): Message{

object part:CCA::Part{name := this.name;type := this.type.resolveone(#WXS::Type);

}if(not this.owner.oclIsTypeOf(CCA::OperationPort)){

name := this.name;parts := parts→ including(part);

}else{

if (this.direction = ’initiates’){name := this.name;parts := parts→including(part);

}else{

name := this.name;parts := parts→ including(part);

}endif;

}endif;

}

Fig. 7 The transformation rule fp2mg

– The rule pp2ptt maps a ProtocolPort directly in aProcessComponent to a WSDL <PortType>.

– The rule pp2bd maps a ProtocolPort directly in aProcessComponent to a WSDL <Binding>.

– The rule pp2pt maps a ProtocolPort directly in aProcessComponent to a WSDL <Port>.

– The rule pc2s maps a CCA ProcessComponent toa WSDL <Service>.

– The rule pc2d maps a CCA ProcessComponent toa WSDL <Definition>.

– The rule cca2wsdl is a main transformation rulewhich calls all the other rules in sequence to gen-erate an output WSDL file from an input CCAProcessComponent.

Instead of listing all the details, we only show partof these QVT specified rules and helper functions forconciseness:

– The rule fp2mg is depicted in Fig. 7.– The rule op2pto is listed in Fig. 8: This rule creates

an instance of WSDL <PortTypeOperation> with<input>, <output> and <fault> for each CCA ‘re-sponds’ OperationPort. The <input> message is setwith the message mapped from the ‘initiates’ Flow-Port contained in the source OperationPort. The<output> message is set with the message mappedfrom the ‘responds’ FlowPort which is containedin this OperationPort and have its postconditionset to ‘success’. The <fault> message is set withthe message mapped from the ‘responds’ FlowPortwhich is contained in the source OperationPort andhave its postcondition not set to ‘success’.

transformation op2pto(in cca:CCA, out wsdl:WSDL)main(){

cca.objectsOfType(OperationPort)→map op to ptop();}mapping OperationPort::op to ptop(): PortTypeOperation{

when{this.direction = ’responds’;

}var iPort := this.ports→ select(fp | fp.direction = ’initiates’);var oPort := this.ports→ select(fp | fp.direction = ’responds’ and

fp.postcondition = ’success’);var fPort := this.ports→ select(fp | fp.direction = ’responds’ and

fp.postcondition < > ’success’);object inputMsg:CCA::PortTypeOperationInput{

message := iPort.resolveone(#WSDL::Message);}object outputMsg:CCA::PortTypeOperationOutput{

message := oPort.resolveone(#WSDL::Message);}object faultMsg:CCA::PortTypeOperationFault{

message := fPort.resolveone(#WSDL::Message);}name := this.name;input := inputMsg;output := outputMsg;fault := faultMsg;

}

Fig. 8 The transformation rule op2pto

– The rule pp2ptt is shown in Fig. 9: This rulecreates an instance of a WSDL <PortType> foreach CCA ProtocolPort which is directly con-tained in a ProcessComponent. Then add the<PortTypeOperations> mapped from the Flow-Ports and OperationPorts contained in the sourceProtocolPort to the newly created <PortType>.

– The rule pc2s is illustrated in Fig. 10: This rulecreates a WSDL <Service>, and initializes its at-tributes with the artifacts transformed from thePorts contained in the source ProcessComponent.

transformation pp2ptt(in cca:CCA, out wsdl:WSDL)main(){

cca.objectsOfType(ProtocolPort)→map pp to ptt();}mapping ProtocolPort::pp to ptt(): PortType{

when{this.owner.oclIsTypeOf(CCA::ProcessComponent);

}var ptop : WSDL::PortTypeOperation;var fps := this.getFlowPorts();var ops := this.getAllOperationPorts();fps→ forEach(fp){

if fp.direction = ’responds’{ptop := fp.resolveone(#WSDL::PortTypeOperation);result.operations := result.operations→ including(ptop);

}endif;

}ops→forEach(op){

if op.direction = ’responds’{ptop := op.resolveone(#WSDL::PortTypeOperation);result.operations := result.operations→ including(ptop);

}endif;

}result.name := this.name.concat(’PortType’);

}

Fig. 9 The transformation rule pp2ptt

For Research Only

398 Inf Syst Front (2007) 9:391–409

transformation pc2svc(in cca:CCA, out wsdl:WSDL)main(){

cca.objectsOfType(ProcessComponent)→ map pc to s();}mapping ProcessComponent::pc to s(): Service{

var pps := this.ports→select(e |e.oclIsKindOf(ProtocolPort));

var pts : Set(WSDL::Port) = Set{} ;pps→forEach(pp){

pts := pts→ including(pp.resolveone(#WSDL::Port));}name := this.name;port := pts→ asSequence();

}

Fig. 10 The transformation rule pc2s

– The transformation rule cca2wsdl is illustrated inFig. 11).

– The helper function getAllFlowPorts is listedin Fig. 12): Firstly, retrieve all the FlowPortsdirectly contained in the current ProtocolPort.Then retrieve all the FlowPorts contained in theOperationPorts which are directly contained in thecurrent ProtocolPort. Thirdly, retrieve all the Flow-Ports contained in the inner ProtocolPorts whichare contained in the current ProtocolPort by recur-sion call.

5 From EDOC models to Web servicesorchestration models

In our framework, all sub PIMs will be implementedin Web services which will be orchestrated togetherto construct an information system. Therefore, af-ter a WSDL interface is generated from a sub PIM,the sub-PIM should be mapped according to its

transformation cca2wsdl(in cca:CCA, out wsdl:WSDL)extends transformation dt2pdt(DM, WXS);extends transformation en2st(DM, WXS);extends transformation cd2ct(DM, WXS);extends transformation fp2mg(CCA, WSDL);extends transformation fp2ptop(CCA, WSDL);extends transformation op2ptop(CCA, WSDL);extends transformation pp2ptt(CCA, WSDL);extends transformation pp2bd(CCA, WSDL);extends transformation pp2pt(CCA, WSDL);extends transformation pc2s(CCA, WSDL);extends transformation pc2d(CCA, WSDL);main(){

cca.objectsOfType(DataType)→ map dt to pdt();cca.objectsOfType(Enumeration)→ map en to st();cca.objectsOfType(CompositeData)→ map cd to ct();cca.objectsOfType(FlowPort)→ map fp to mg();cca.objectsOfType(FlowPort)→ map fp to ptop();cca.objectsOfType(OperationPort)→ map op to ptop();cca.objectsOfType(ProtocolPort)→ map pp to ptt();cca.objectsOfType(ProtocolPort)→ map pp to bd();cca.objectsOfType(ProtocolPort)→ map pp to pt();cca.objectsOfType(ProcessComponent)→ map pc to s();cca.objectsOfType(ProcessComponent)→ map pc to d();

}

Fig. 11 The transformation rule cca2wsdl

helper ProtocolPort::getAllFlowPorts() : Set(CCA::FlowPort){var fps := this.owner.ports→select(e |e.oclIsTypeOf(FlowPort));var ops := this.owner.ports→

select(e |e.oclIsTypeOf(OperationPort));var pps := this.owner.ports→

select(e |e.oclIsTypeOf(ProtocolPort));if ops→ notEmpty(){

ops→ forEach(op){fps := fps→union(op.ports);

}}endif;if pps→notEmpty(){

pps→forEach(pp){fps := fps→union(pp.getAllFlowPorts());

}}endif;return fps;

}

Fig. 12 The helper function getAllFlowPorts

dynamic behaviors specifying the contract it will havewith other components, to a Web service orchestra-tion model. The dynamic aspects of EDOC mod-els are specified using CCA Choreography, and Webservices orchestration models are specified usingBPEL. Automatic transformation from CCA Chore-ography to BPEL is another key technology of ourframework.

5.1 Overview of CCA Choreography

A CCA Choreography specifies how messages willflow between PortUsages. We use Choreography tospecify how a EDOC PIM communicates with otherPIMs. Each choreography of a PIM will be mappedto a BPEL process for Web service orchestration. The

1 1Nodes

+nodes n

Connections

Target

Source

+target

+source

+incoming

+outging

n

n

1

1

Generalization

0:1

n

+subtypes

+supertype

1

nRepresents

+represents

PseduoState

-kind:PseudostateKind

PortUsage

Port

-name:String-isSync:Boolean-isTransactional:Boolean-direction:DirectionType-postCondition:Status

<<enumeration>>PseudostateKind

+choice+fork+initial+join+failure

Transition

-preCondition

AbstractTransitionNode

-name:String

Choreography

Fig. 13 CCA choreography meta-model

For Research Only

Inf Syst Front (2007) 9:391–409 399

cental elements of the CCA Choreography meta-modelare shown in Fig. 13:

– Choreography - It is an abstract class inherited byProtocol and ProcessComponent which expressesthe behavior of ProcessComponents. A Chore-ography specifies how messages will flow betweenPortUsages.

– Node - It is an abstract element that specifies some-thing that can be the source and/or target of a tran-sition and thus ordered within the choreographedprocess.

– PortUsage - It expresses the usage of a Port as partof a Choreography.

– PseudoState - It specifies starting, ending orintermediate states in the Choreography. APseudoState depends on it’s kind attribute whichcan be one of the following enumeration values:choice, fork, initial, join, success and failure.

– Transition - It specifies the ordering that the relatednodes will activate.

5.2 Overview of BPEL

In most cases, Web services do not exist in isolation, butrather as part of a process via orchestration. Up to now,several orchestration languages have been proposed forWeb services orchestration, such as BPEL (Andrews2003), BPML (Arkin 2002) and WSCI (Arkin et al.2002). But none of them has been declared as thewinner. In this framework, we choose BPEL to specifyWeb services orchestration. BPEL is an XML-basedlanguage for orchestrating Web services. Figure 14 de-picts the simplified meta-model for BPEL based on(Andrews 2003).

Partnername

name

Operation

TargetlinkName

Source

linkNametransitionCondition

Linkname

Sequence

FlowInvokepartnerLinkoperationinputVariableoutputVariable

ReceivepartnerLinkportTypeoperationvariablecreateInstance

ReplypartnerLinkportTypeoperationvariablefaultName

ProcessnametargetNamespacequeryLanguageexpressionLanguagesuppressJoinFailureenableInstanceCompensationabstractProcess

1..*Resposibility 1

myrole 1

PartnerRole 1

0..* 0..*

partnerLinkType

partners0..*

PartnerLink

PortTypename

variables

0..*

1 do activity1

0..1 faultHandlers0..* catches

1..* cases

do activity

1..*

PartnerLink

namepartnerLinkTypemyrolepartnerRole

PartnerLinkTypename

Rolename

Varaible

ActivitynamejoinConditionsupressJoinFailuresourcetarget

Catch

faultNamefaultVarialbe

FaultHandler

Rolename

Switch

1

Casecondition

Fig. 14 A simplified meta-model for BPEL

The BPEL concepts that are relevant for the pro-posed mapping from CCA are briefly sketched asfollows:

– Process - It is the root in the BPEL specification.– PartnerLink - It represents a bilateral message ex-

change between two parties via a reference to aPartnerLinkType.

– PartnerLinkType - It defines the roles and Port-Types of two partner services.

– Variable - It holds workflow data and messagesexchanged between parties.

– FaultHandler - It provides a way to define customfault-handling activities.

– Invoke - It denotes a synchronous request/responseor an asynchronous one-way operation to invoke aWeb service.

– Receive - It denotes receiving a request from otherWeb services.

– Reply - It denotes sending a response to a requestpreviously accepted via a synchronous Receiveactivity.

– Sequence - It specifies that Activities are executedsequentially.

– Flow - It specifies that Activities are executed inparallel, possibly with some synchronous Links.

– Switch - It specifies that alternative branches arechosen to be executed based on the value of someVariables.

5.3 From CCA choreography to BPEL

Automatic transformation from CCA Choreography toBPEL is another key technology of our framework.To simplify transformation process, we need to makesome assumptions, add some constraints, propertiesand operations to the CCA meta-model. However, itdoes not mean that we intend to alter the CCA profile.On the contrary, we add these new features to theinput CCA models by a plugin before transformation.Based on these newly added elements, QVT specifiedtransformation rules are proposed which implementthe mapping from CCA choreography to BPEL.

The assumptions we have made are as follows:

– MultiPort is not used in system modeling.– If a FlowPort or an OperationPort is directly con-

tained in aProcessComponent, we assume that thisFlowPort or OperationPort is contained by a cog-nominal ProtocolPort which is directly contained inthe ProcessComponent.

For Research Only

400 Inf Syst Front (2007) 9:391–409

context: CCA::Protocolinv: validProtocol;

let childProtocolPort:Set(ProtocolPort) =self.generation.child→select(c |c.oclIsTypeOf(ProtocolPort)) inchildProtocolPort→size = 2 andchildProtocolPort→select(c1, c2 |c1.owner <> c2.owner)

Fig. 15 The constraint validProtocol

The constraint validProtocol is added to the CCAmeta-model which specifies that a Protocol can be in-herited by only one pair of ProtocolPorts. Thus we cannavigate between ProtocolPorts which use the sameProtocol. This constraint is defined using the objectconstraint Language (OCL; see Fig. 15)

The following properties are added to the CCAmeta-model to facilitate the transformation process(the OCL expression of these properties is omitted):

– outermostPP: It represents the ProtocolPort whichcontains the current Port and is directly owned by aProcessComponent.

– partnerPt: It represents the Port which interactswith the current Port.

– ownPt: It represents the Ports with respect to the‘responder’ role of the Protocol that the currentProtocolPort uses.

– lastNodeType: It represents the types of the lastnodes of all branches of the current ChoiceState. Itis a set which consists of SucessState, FailureState,MergeState, and JoinState

– isSync: It is a Boolean value which indicateswhether the current Transition is used as a synchro-nous control between two concurrent Nodes. If thecurrent Transition works as a synchronous control,this property must be set with ‘true’. Otherwise thevalue of this property is ‘false’. The default value ofthis property is ‘false’.

The operations we add to the CCA meta-model islisted below (OCL code of these operations is very big,so we omit the details):

– getNextNode: It returns the next Node to the cur-rent Node.

– getPreviousNode: It returns the previous Node tothe current Node.

– getMatchJoinState: It returns the matching Join-State of the current ForkState.

– getMatchForkState: It returns the matching Fork-State of the current JoinState.

– getSyncTrans: It returns the synchronous controlTransitionswhich will be mapped to BPEL <links>in a corresponding BPEL <flow>.

Table 4 The rules mapping from CCA choreography to BPEL

Rule Input Constraint Output

fp2var FP <variable>fp2ch FP in OP <catch>

pstc !=’success’dir =’responds’owner.dir =’initiates’

fp2inv FP not in OP <invoke> withdir =’initiates’ <inputVariable>

fp2rec FP not in OP <receive>dir = ’responds’ orin OPdir =’responds’owner.dir =’responds’

fp2rep FP in OP <reply>dir =’initiates’owner.dir =’responds’

op2inv OP dir =’initiates’ <invoke> with<inputVariable>and<outputVariable>

proPort2x PP <PartnerLinkType>and<PartnerLink>

fs2fl FS <flow>

pc2def PC WSDL <definition>cca2bpel CG <process>

– getRootTrans: It checks whether a Transition is di-rectly nested in a ForkState.

– getLinks: It returns the <links> which are mappedfrom the synchronous control Transitions directlynested in the current ForkState.

Besides, we define a PseudoState named Merge-State. A MergeState has one outgoing Transition andseveral optional incoming Transitions only one of whichcan be enabled at a time. A MergeState is used tomerge the outgoing Transitions of a correspondingChoiceState.

Based on semantic equivalence and the new featureswe defined for the CCA meta-model, we propose therules mapping from CCA Choreography to BPEL (seeTable 4, FP is short for FlowPort, OP is short for

transformation fp2rep(in cca:CCA, out bpel:BPEL)main(){cca.objectsOfType(FlowPort)→map fp to rep();}mapping FlowPort::fp to rep():Reply{

when{this.owner.oclIsTypeOf(OperationPort) andthis.owner.direction=’responds’and this.direction=’initiates’

}partnerLink := this.outermostPP.resolveone(#BPEL::PartnerLink);portType:=this.partnerPt.outermostPP.resolveone(#BPEL::PortType);operation := this.owner.resolveone(#BPEL::PortTypeOperation);Variable := this.resolveone(#BPEL::Variable);}

Fig. 16 The transformation rule fp2rep

For Research Only

Inf Syst Front (2007) 9:391–409 401

transformation op2inv(in cca:CCA, out bpel:BPEL)main(){

cca.objectsOfType(OperationPort)→ map op to inv();}mapping OperationPort::op to inv():Invoke{

when{ this.direction = ’initiates’}var iPort := this.ports→ select(fp | fp.direction=’initiates’);var oPort := this.ports→ select(fp |fp.direction = ’responds’ and

fp.postcondition = ’success’);partnerLink := this.outermostPP.resolveone(#BPEL::PartnerLink);portType:=this.partnerPt.outermostPP.resolveone(#WSDL::PortType);operation:=this.partnerPt.resolveone(#BPEL::PortTypeOperation);inputVariable := iPort.resolveone(#BPEL::Variable);outputVariable := oPort.resolveone(#BPEL::Variable);

}

Fig. 17 The transformation rule op2inv

OperationPort, PC is short for ProcessComponent,pstc is short for postcondition, dir is short for di-rection, FS is short for ForkState, CG is short forChoreography):

Table 4 shows that not all the BPEL concepts canbe transformed from CCA models. For those BPELelements, such as <assign>, <pick>, <correlations>,there are no corresponding elements in CCA that haveequivalent semantic to them. The complete descriptionof all these rules in Table 4 is very big, therefore we onlygive the code for rule fp2rep, op2inv, fs2fl and cca2bpel.The code for other rules can reference our previouswork in (Yu et al. 2007).

The rule fp2rep (see Fig. 16) maps a FlowPort toa BPEL <reply> activity. If an ‘initiates’ FlowPortis owned by a ‘responds’ OperationPort, it is used toreturn messages to synchronous calls from otherProcessComponents. Such a FlowPort can be mappedto a BPEL <reply> activity.

The rule op2inv (see Fig. 17) maps an ‘initiates’OperationPort to a BPEL <invoke> operation. Sincean OperationPort represents a synchronous call/returnoperation, the generated <invoke> activity has boththe <inputVariable> and <outputVariable>.

The rule fs2fl (see Fig. 18) maps a CCA ForkStateto a BPEL <flow> activity. Each outgoing branch ofthe ForkState is mapped to a BPEL <sequence> which

transformation fs2fl(in cca:CCA, out bpel:BPEL)main(){

cca.objectsOfType(ForkState)→ map fs to fl();}mapping ForkState::fs to fl():Flow{

links := this.getLinks();activity := this.outgoing.iterate(og; acc:Set(BPEL::Sequence)|

var seq : BPEL::Sequence;var nd : CCA::Node := og.target;while (nd <> this.getMatchJoinState){

seq.activity→ append(nd.resolveone(#BPEL::Activity););nd := nd.getNextNode()} ;

acc→ including(seq);)}

Fig. 18 The rule fs2fl

transformation cca2bpel(in cca:CCA, out wsdl:WSDL, out bpel:BPEL)extends transformation dt2pdt(DM, WXS);extends transformation en2st(DM, WXS);extends transformation cd2ct(DM, WXS);extends transformation fp2x(CCA, WSDL);extends transformation opp2ptop(CCA, WSDL);extends transformation fp2var(CCA, WSDL);extends transformation fp2ch(CCA, WSDL);extends transformation fp2inv(CCA, WSDL);extends transformation fp2rec(CCA, WSDL);extends transformation fp2rep(CCA, WSDL);extends transformation op2inv(CCA, WSDL);extends transformation protocolPort2x(CCA, WSDL);extends transformation syncTran2lk(CCA, WSDL);extends transformation cs2sw(CCA, WSDL);extends transformation fs2fl(CCA, WSDL);extends transformation pc2definition(CCA, WSDL);extends transformation choreography2bpel (CCA, BPEL);main(){

cca.objectsOfType(DataType)→ map dt to pdt();cca.objectsOfType(EnumerationType)→ map en to st();cca.objectsOfType(FlowPort)→ map fp to x();cca.objectsOfType(OperationPort)→ map opp to ptop();cca.objectsOfType(FlowPort)→ map fp to var();cca.objectsOfType(FlowPort)→ map fp to ch();cca.objectsOfType(FlowPort)→ map fp to inv();cca.objectsOfType(FlowPort)→ map fp to rec();cca.objectsOfType(FlowPort)→ map fp to rep();cca.objectsOfType(OperationPort)→ map op to inv();cca.objectsOfType(ProtocolPort)→ map protocolPort to x();cca.objectsOfType(Transition)→ map syncTran to lk();cca.objectsOfType(ChoiceState)→ map cs to sw();cca.objectsOfType(ForkState)→ map fs to fl();cca.objectsOfType(ProcessComponent)→ map pc to definition);cca.objectsOfType(Choreography)→ map choreography to bpel(); }

Fig. 19 The rule cca2bpel

will be added into the corresponding BEPEL <flow>.The transitions that are used to express synchronizationdependencies are mapped to <links>.

The rule cca2bpel (see Fig. 19) is a main transforma-tion rule which call other rules in sequence to imple-ment mapping from CCA Choreography to BPEL.

6 The illustrative example

To exemplify how to use our framework to developa Web services based enterprise information system,we chose an illustrative example of an E-Store. TheE-Store provides customers with on line purchasing

E-Store

invoiceCallback

sendInvoice

sendShippingPrice

shippingCallback

requestShipping

shipping

shippingMsg

orderDenied

selling

sendOrder

invoice

orderDenied

order

Shipping

shipping

requestShipping

shippingMsg

orderDenied

shipping

sendSchedule

Invoice

sendShippingPrice

sendInvoice

initiatePriceCalc

computePrice

Customer

buying

sendOrder

order

invoice

orderDenied

sendSchedule

scheduling

sendSchedule

requestSchedule

Scheduling

requestSchedule

sendSchedule

scheduling

initiatePriceCalc

Fig. 20 The PIMs of the E-Store

For Research Only

402 Inf Syst Front (2007) 9:391–409

<<Protocol>>invoicing

<<Protocol>>scheduling

<<ProtocolPort>>shipping

<<ProtocolPort>>scheduling

<<ProtocolPort>>computePrice

<<Protocol>>shipping

<<ProtocolPort>>shippingCallback

<<Protocol>>purchasing

<<ProcessComponent>>Customer

<<ProcessComponent>>

E-Store

<<ProcessComponent>>Shipping

<<ProcessComponent>>Invoice

<<ProcessComponent>>Scheduling

<<ProtocolPort>>buying

<<ProtocolPort>>scheduling

<<ProtocolPort>>selling

<<ProtocolPort>>invoiceCallback

Fig. 21 The contracts for the E-Store ProcessComponent

service. A customer sends an order to the E-Store, thenthe E-Store calculates the price, arranges the shipmentand the shipping schedule. Finally, the E-Store sends aninvoice to the customer.

Firstly, build a PIM using the EDOC CCA Process-Component to describe the general functions ofthe E-Store. The general PIM is expressed by theProcessComponent E-Store as illustrated in Fig. 20.Secondly, break down the general PIM into sub PIMseach of which can provide service independently. Ac-cording to this decomposition principle, four sub PIMsare created, which are the ProcessComponent Cus-tomer, Scheduling, Shipping and Invoice (see Fig. 20).The general PIM interacts with all the sub PIMs toimplement the platform independent functions for theE-Store system . Thirdly, preprocess each PIM andadd necessary details to it. Fourthly, transform eachof these PIMs into a WSDL file and a BPEL process.Afterward, implement each sub PIM into a Web serviceon specific platforms. Finally, deploy all of the servicesand BPEL processes transformed from these PIMs.Therefore, at the end of the development process, theE-Store system is composed of several Web servicesand BPEL processes.

In consideration of conciseness, we only take thegeneral PIM, that is the E-Store ProcessComponentas an example to show the process of generatingWSDL and BPEL via model transformation. Figure 20shows that the E-Store ProcessComponent includesfour ProtocolPorts which are selling, scheduling,

E-Store

invoiceCallback

sendInvoice

sendShippingPrice

shippingCallback

requestShipping

shipping

shippingMsg

selling

sendOrder

invoice

orderDenied

order

sendSchedule

scheduling

sendSchedule

initiatePriceCalc

<<CompositeData>>Invoice

<<CompositeData>>CustomerOrder

custInfo:CustomerInfo order: PuchaseOrder

<<CompositeData>>OrderFault

problemInfo: String

<<CompositeData>>CustomerOrder

<<CompositeData>>ScheduleInfo

<<CompositeData>>CustomerInfo

<<CompositeData>>OrderFault

<<CompositeData>>ShippingInfo

<<CompositeData>>ScheduleInfo

<<CompositeData>>CustomerOrder

<<CompositeData>>ShippingInfo

<<CompositeData>>Invoice

orderDenied

requestSchedule

Fig. 22 Data types for the E-Store ProcessComponent

shippingCallBack and invoiceCallback. The Ports thatsend information are represented as boxes filled withblack, and the Ports that receive information arerepresented as boxes not filled. The ProtocolPortselling has an ‘responds’ OperationPort sendOrder,shippingCallback has an ‘initiates’ OperationPort re-questShipping and a non-OperationPort-owned Flow-Port sendSchedule, ProcessComponent schedulingand invoiceCallback only contain non-OperationPort-owned FlowPorts. Each of these ProtocolPorts interactwith its partner port using a corresponding Protocol(see Fig. 21).

Before generating WSDL and BPEL from the E-Store ProcessComponent, we need to add necessarystatic and dynamic information to this component.Figure 22 depicts the detailed static structure of theE-Store ProcessComponent which shows all the datatypes that each port sends or receives. Figure 23 depictsthe Choreography of the E-Store ProcessComponentwhich specifies dynamic interactions between E-Storeand its partners.

After preprocessing, we can apply the transforma-tion rule cca2wsdl to the E-Store ProcessComponent

selling <<responds>>

<<initiates>> invoiceCallback

<<initiates>>initiatePriceCalc

<<initiates>>sendShippingPrice

buying <<initiates>>

<<initiates>> sendOrder

<<responds>>invoice

<<responds>>orderDenied

<<responds>> sendOrder

<<responds>>order

<<initiates>>invoice

<<initiates>>orderDenied

<<initiates>> shippingCallback

<<initiates>> requestShipping

<<initiates>>shipping

<<responds>>shippingMsg

<<responds>>orderDenied

<<responds>>sendSchedule

<<responds>>sendInvoice

<<responds>> scheduling

<<initiates>>requestSchedule

<<initiates>>sendSchedule

<<responds>> shipping

<<responds>> requestShipping

<<responds>>shipping

<<initiates>>shippingMsg

<<initiates>>sendSchedule

<<responds>> computePrice

<<initiates>>sendInvoice

<<responds>>initiatePriceCalc

<<responds>>sendShippingPrice

<<initiates>> scheduling

<<responds>>requestSchedule

<<responds>>sendSchedule

Success

<<initiates>>orderDenied

Failure

Customer E-Store

Shipping

Invoice

Scheduling

<<initiates>>order

Fig. 23 Choreography of the E-Store ProcessComponent

For Research Only

Inf Syst Front (2007) 9:391–409 403

to generate a WSDL file. The steps of the rule cca2wsdland the artifacts of the steps are as follows:

1. Apply the rules dt2pdt, en2st and cd2ct, then thefollowing XML Schema type is generated automat-ically:

<xs:complexType name = ”CustomerInfo”>

<xs:elemente name = ”author” type= ”xs:string”/>

<xs:elemente name = ”keyword” type= ”xs:string”/>

<xs:elemente name = ”ID” type= ”xs:string”/¿>

<xs:elemente name = ”type” type= ”LiteratureType”/>

</xs:complexType> <xs:complexType name = ”ShippingInfo”>

<xs:elemente name = ”problem” type = ”xs:string”/>

<xs:elemente name = ”keyword” type = ”xs:string”/>

</xs:complexType >

<xs:complexType name = ”OrderFault”>

<xs:elemente name = ”problemInfo” type = ”xs:string”/>

</xs:complexType >

<xs:complexType name = ”ScheduleInfo”>

<xs:elemente name = ”author” type = ”xs:string”/>

</xs:complexType >

<xs:complexType name = ”CustomerOrder”>

<xs:elemente name = ”custInfo” type = ”CustomerInfo”/>

<xs:elemente name = ”order” type = ”PurchaseOrder”/>

</xs:complexType >

<xs:complexType name = ”Invoice”>

<xs:elemente name = ”custInfo” type = ”CustomerInfo”/>

</xs:complexType>

2. Apply the rule fp2mg, then the following WSDLartifacts are generated automatically:

<message name = ”order”>

<part name=”order” type=”CustomerOrder”/>

</message >

<message name = ”invoice” >

<part name=”invoice” type=”Invoice”/>

</message >

<message name = ”orderDenied”>

<part name=”orderDenied” type=”OrderFault”/>

</message >

<message name = ”shipping”>

<part name=”shipping” type=”CustomerInfo”/>

</message >

<message name = ”shippingMsg”>

<part name=”shippingMsg” type=”ShippingInfo”/>

</message >

<message name = ”sendSchedule”>

<part name=”sendSchedule” type=”ScheduleInfo”/>

</message >

<message name = ”initiatePriceCalc”>

<part name=”initiatePriceCalc” type=”CustomerOrder”/>

</message >

<message name = ”sendShippingPrice”>

<part name=”sendShippingPrice” type=”shippingInfo”/>

</message >

<message name = ”sendInvoice”>

<part name=”sendInvoice” type=”Invoice”/>

</message >

<message name = ”requestSchedule”>

<part name=”requestSchedule” type=”CustomerOrder”/>

</message >

<message name = ”sendSchedule”>

<part name=”sendSchedule” type=”ScheduleInfo”/>

</message >

3. Apply the rules fp2ptop, op2pto and pp2pptthen the following WSDL artifacts are generatedautomatically:

<portType name = ”sellingPT”>

<operation name = ”sendOrder”>

<input message = ”order”/>

<output message=”invoice”/>

<fault name=”orderDenied” message=”orderDenied”/>

</operation>

<portType name = ”shippingCallbackPT”>

<operation name = ”sendSchedule”>

<input message = ”sendSchedule”/>

</operation>

</portType>

<portType name = ”invoiceCallbackPT”>

<operation name = ”sendInvoice”>

<input message = ”sendInvoice”/>

</operation>

</portType>

4. Apply the rule pc2d, then a WSDL Definitions isgenerated, to which the artifacts generated fromstep 1 to 3 will be added, thus making a com-plete WSDL file (we only show an excerpt of thewhole file).

<definitions name = ”E-Store”

targetNamespace = ”urn://. . . /”;

xmlns:tns = ”urn://. . . /”;

xmlns = ”http://schemas.xmlsoap.org/wsdl/”;

<types>

<schema targetNamespace = ”urn//. . . /”

xmlns = ”http://www.w3.org/2000/10/XMLSchema”>

<xs:complexType name = ”ShippingInfo”>

<xs:elemente name = ”problem” type = ”xs:string”/>

<xs:elemente name = ”keyword” type = ”xs:string”/>

</xs:complexType >

...

</types>

For Research Only

404 Inf Syst Front (2007) 9:391–409

<message name = ”order”>

<part name=”order” type=”CustomerOrder”/>

</message>

...

<portType name = ”sellingPT”>

<operation name = ”sendOrder”>

<input message = ”order”/>

<output message=”invoice”/>

<fault name=”orderDenied” message=”orderDenied”/>

</portType>

...

</definitions>

After a WSDL file is generated from the E-StoreProcessComponent, we can apply the rule cca2bpelto the Choreography of this component in order togenerate a BPEL Process as depicted in Listing 1.

Listing 1 BPEL process for the E-Store ProcessComponent<process name=''E−Store'' targetNamespace='' ''

...<partnerLinks><partnerLink name=''purchasingLK'' partnerLinkType=''purchasingLT''

myRole=''selling ''/><partnerLink name=''invoicingLK'' partnerLinkType=''invoicingLT ''

myRole=''invoiceCallback'' partnerRole='' invoice ''/><partnerLink name=''shippingLK'' partnerLinkType=''shippingLT''

myRole=''shippingCallback'' partnerRole=''shipping ''/><partnerLink name=''schedulingLK'' partnerLinkType=''schedulingLT''

partnerRole=''scheduling ''/></partnerLinks>

<variables><variable name=''order'' messageType=''order''/><variable name=''invoice '' messageType=''invoice''/><variable name=''orderDenied'' messageType=''orderDenied''/><variable name=''shipping'' messageType=''shipping''/><variable name=''shippingMsg'' messageType=''shippingMsg''/><variable name=''sendSchedule'' messageType=''sendSchedule''/><variable name=''initiatePriceCalc '' messageType=''initiatePriceCalc ''/><variable name=''sendInvoice'' messageType=''sendInvoice''/><variable name=''requestSchedule'' messageType=''requestSchedule''/>...

</variables><faultHandlers><catch faultName=''orderDenied''

faultVariable ='' orderDenied''><reply partnerLink='' selling ''

portType=''sellingPT ''operation='' sendOrder''variable ='' orderDenied''faultName=''orderDenied''/>

</catch></faultHandlers>

<sequence><receive partnerLink='' purchasingLK''

portType=''sendOrderPT''operation='' order ''variable ='' PO''>

</receive><flow><links><link name=''requestShipping_to_sendShippingPrice''/><link name=''sendSchedule_to_sendSchedule''/>

</ links><sequence><invoke partnerLink=''shippingLK''

portType=''shippingPT''operation='' requestShipping''inputVariable ='' shipping ''outputVariable='' shippingMsg''>

<source linkName=''requestShipping_to_sendShippingPrice''/>

</invoke><receive partnerLink='' shippingLK''

portType=''shippingCallbackPT''operation='' sendSchedule''variable ='' sendSchedule''>

<source linkName=''sendSchedule_to_sendSchedule''/></receive>

</sequence>

<sequence><invoke partnerLink='' invoicingLK ''

portType=''computePricePT''operation='' initiatePriceCalc ''inputVariable ='' initiatePriceCalc ''>

</invoke><invoke partnerLink='' invoicingLK ''

portType=''computePricePT''operation='' sendShippingPrice''inputVariable ='' sendShippingPrice''>

<target linkName=''requestShipping_to_sendShippingPrice''/></invoke><receive partnerLink='' invoicingLK ''

portType=''invoiceCallbackPT''operation='' sendInvoice''variable ='' sendInvoice ''/>

</sequence>

<sequence><invoke partnerLink=''schedulingLK''

portType=''schedulingPT''operation='' requestSchedule''inputVariable ='' requestSchedule''>

</invoke><invoke partnerLink=''schedulingLK''

portType=''schedulingPT''operation='' sendSchedule''inputVariable ='' sendSchedule''>

<target linkName=''sendSchedule_to_sendSchedule''/></invoke>

</sequence></flow><switch><case condition = '' order is denied''></case><otherwise></otherwise>

</switch><reply partnerLink='' purchasingLK''

portType=''sellingPT ''operation='' sendOrder''variable ='' order ''/>

</sequence></process>

During the process of generating a BPEL Processfor the E-Store ProcessComponent, the artifacts inListing 2 are generated automatically via applying thetransformation rule proPort2x. These artifacts are thenadded to the WSDL file transformed from the E-StorePrcocessComponent.

Listing 2 Artifacts from E-Store component via ProPort2x<plnk:partnerLinkType name=purchasingLT''>

<plnk:role name=''selling ''><plnk:portType name=''sellingPT''/>

</plnk: role></plnk:partnerLinkType>

<plnk:partnerLinkType name=''invoicingLT''><plnk:role name=''invoice''><plnk:portType name=''computePricePT''/>

</plnk: role><plnk:role name=''invoiceCallback''><plnk:portType name=''invoiceCallbackPT''/>

</plnk: role></plnk:partnerLinkType>

<plnk:partnerLinkType name=''shippingLT''><plnk:role name=''shipping''><plnk:portType name=''shippingPT''/>

For Research Only

Inf Syst Front (2007) 9:391–409 405

Scheduling_Service

Invoice_Service

Shpping_Service

E-Store.wsdlE-Store.bpel

Scheduling.wsdlScheduling.bpel

Implementation code

Invoice.wsdlInvoice.bpel

Implementation code

Shipping.wsdlShipping.bpel

Implementation code

E-Store_Service

Fig. 24 The deployment diagram of the E-Store system

</plnk: role><plnk:role name=''shippingCallback''><plnk:portType name=''shippingCallbackPT''/>

</plnk: role></plnk:partnerLinkType>

<plnk:partnerLinkType name=''schedulingLT''><plnk:role name=''scheduling''>plnk:portType name=''schedulingPT''/>

</plnk: role></plnk:partnerLinkType>

After all the sub PIMs are transformed using abovesteps, we can transform each sub PIM to EJB basedWeb services implementation code (the transformationprocess is omitted here) in a similar way to (Jiang et al.2005). Finally, deploy these Web services and processesto make a complete enterprise information system asdepicted in Fig. 24. A customer sends a purchasing or-der to the E-Store service, then this service orchestratesthose sub Web services to process the order, finally,the E-Store service returns the processing results tothe customer.

7 Related work

Model driven Web services development has been thesubject of intensive research in software engineering.In most cases, Web services do not exist in isolation,but rather as part of a process that can be defined inan orchestration language such as BPEL. Therefore,automatic model transformation from PIMs to WSDLand Web services orchestration models (such as BPELProcesses) is the key technology of model driven Webservices development. However, most of the currentapproaches on applying MDA to Web services only fo-cus on transformation of static aspects of Web servicesmodeling.

Grønmo et al. (2004) gives a pure UML based ap-proach for model driven Web services development,which aims at creating composite Web services by reuseof existing Web services. Grønmo et al. (2004) recom-mends developers to model Web services as conceptualUML models without using WSDL specific constructs.

However, Grønmo et al. (2004) does not provideexplicit transformation rules as we have done in thiswork. Besides, Grønmo et al. (2004) is based on pureUML, while our framework is based on the EDOC pro-file. Since the EDOC profile can provide a better rep-resentation of the functionalities and behavior patternsfor a distributed system, our approach can generate amore complete target model than that obtained withpure UML.

In Lopes et al. (2005), once mappings in Lopeset al. (2005) are specified between meta-models ofUML and WSDL, then transformation code writtenin ATL Bézivin et al. (2003) is generated automat-ically to achieve transformation from UML to Webservices. What distinguishes our approach and Lopeset al. (2005) is that we use the EDOC profile to modelPIMs, and use the stand transformation language tospecify transformation rules.

Bézivin et al. (2004) presents the development ofan illustrative example of e-business based on MDA.But the transformation from EDOC PIM to WSDLin Bézivin et al. (2004) is just an example illustratingthat ATL is a good transformation language. Besides,Bézivin et al. (2004) does not provide a frameworkthat support top-down model driven Web services de-velopment as we presented. Moreover, Bézivin et al.(2004) maps all FlowPorts to WSDL Parts withoutconsidering embedded FlowPorts, OperationPorts andProtocolPorts.

In Patrascoiu (2004a), an experiment transformingEDOC to Web services is presented. The transforma-tion process in Patrascoiu (2004a) consists of mappingfrom Document Model to XML Schema and map-ping from CCA to WSDL, which is the same as wehave proposed in our framework. However, Patrascoiu(2004a) maps all FlowPorts to WSDL Messages withno consideration of embedded CCA Ports.

None of above mentioned related research dealswith the transformation from behavioral aspects ofPIMs to Web services orchestration models, however,we present transformation rules mapping from CCAChoreography specified behavioral aspects of PIMsto BPEL specified orchestration models. This makesfurther difference between our work and the abovementioned related work.

Anzbök and Dustdar (2005) presents a modeldriven approach to semi automatically generate BPELfrom healthcare domain workflows. However, our ap-proach of generating BPEL is independent of appli-cation domains.

Mendling and Hafner (2006) shows how BPELprocess definitions for parties involved in a choreog-raphy can be derived from a global WS-CDL (Barros

For Research Only

406 Inf Syst Front (2007) 9:391–409

et al. 2005) choreography model. However, WS-CDLis not a modeling language, hence, mapping from WS-CDL to BPEL is not usable during the analysis anddesign phases of the development cycle. In contrast,this article generates BPEL from EDOC CCA mod-els. Since the EDOC profile is a standard modelinglanguage, our approach is applicable to both the analy-sis and design phases.

BPMN (White 2004) provide a business processmodeling notation that is readily usable by businessanalysts, technical developers and business people.Ouyang et al. (2006) provides a technique which cangenerate BPEL from BPMN automatically. Since UMLis the most widely used modeling language and weuse a standard UML profile (the EDOC profile) tospecify the source models in transformation, our ap-proach is more widely applicable than that of Ouyanget al. (2006). In the OMG BPMN specification (OMG2001a), a mapping between BPMN and BPEL is alsoprovided. On one hand, BPMN does not to provide anexecutable business process and no system can directlyexecute BPMN models, but BPEL processes can bedirectly executed by many engines. On the other hand,we intend to directly generate a Web services basedexecutable system from design models. Therefore, wechoose to specify a mapping between CCA and BPELinstead of between CCA and BPMN.

Skogan et al. (2004) proposes a method to generateBPEL from UML 1.4 Activity models. However, thismethod depends on their own profile which is not astandard UML profile. In addition, (Skogan et al. 2004)does not provide formal transformation rules. On thecontrary, our approach sits on the top of the ECOCprofile which is a standard UML profile, furthermore,we give detailed formal transformation rules.

Bézivin et al. (2004) presents a mapping from UMLActivity diagrams to BPEL without any author addedconstructs, but the authors do not provide completetransformation rules. Bauer and Müller (2004) showshow PIMs specified by UML 2.0 Sequence diagramscan be transformed to BPEL, and gives informal de-finition of the transformation rules. Bordbar andStaikopoulos (2004) provides the transformation fromUML 2.0 Activity diagrams to BPEL, and shows fewtransformation rules. The difference between our ap-proach and [Bézivin et al. (2004); Bauer and Müller(2004); Bordbar and Staikopoulos (2004)] is twofold.First, this work aims to support model driven develop-ment for component based enterprise distributed com-puting systems, therefore, we use the EDOC profileinstead of the pure UML 1.4 or UML 2.0 to specifyPIMs. Second, we present much more complete formaltransformation rules.

One of the focuses of Kath et al. (2004) is totransform EDOC behavior models to BPEL. However,Kath et al. (2004) does not give any concrete transfor-mation rules.

There are several development platforms and toolk-its related to our work that can support generatingWSDL files from Web services implementation code.But there are at least three shortcomings for theseplatforms and toolkits: Firstly, the process generatingWSDL files is specific to the programming languageused to implement a Web service. Secondly, there areno WSDL files before Web services are implemented,which does not support testing or checking Web serviceinteractions simultaneously while developing. Thirdly,WSDL files are tightly coupled with code, which causesadditional complexity and work to maintain WSDLfiles. However, there are no such problems in this pa-per, because we generate WSDL files from PIMs at thedesign stage.

Though there are CASE tools such as IBMWebsphere (IBM), Oracle BPEL Process Manager(Oracle) which offer a user-friendly visual interfacefor designing and creating orchestration specification,these tools are specific to orchestration languages.Unfortunately, more than one orchestration languagesexist currently, such as BPEL, BPML (Arkin 2002)and WSCI (Arkin et al. 2002). Moreover, eachorchestration engine can execute only one language.Therefore, developers using such tools have to facethe risk of exhausting migration between different or-chestration languages and execution engines. However,in our approach, the same orchestration model canbe transformed to different orchestration language de-fined specifications by applying different rules, thus lib-erating developers from migration nightmare. Thoughwe make BPEL as the target orchestration languagewhen mapping dynamic behaviors of PIMs, the ap-proach is applicable to other orchestration languages.

Jiang et al. (2005) is one of our previous workin which we have developed a tool named ME4ETwhich can generate EJB code from EDOC PIMs. SinceWeb services can be implemented in EJBs, Jiang et al.(2005) is a good reference to generate Web servicesimplementation code from EDOC PIMs. However, wedo not pay much attention to generate Web servicesimplementation in this article.

In order to automatize the transformation processin our framework, we are engaged in developing antransformation execution engine and a plugin whichadds the new features we proposed to the input CCAmodels. The transformation process with the executionengine and the plugin is shown in Fig. 25. Firstly, a CCAmodel expressed in XMI (XML Metadata Interchange)

For Research Only

Inf Syst Front (2007) 9:391–409 407

Transformation

Engine

XMI LabellingPlugin

CCA

modelXMI

New

Features

Transformation

Rules

WSDLInterface

BPELProcess

altered CCAmodel

Fig. 25 The transformation process with an execution engine anda labelling plugin

is input into the labelling plugin. Secondly, the pluginadds new features to the CCA model and transmit thealtered CCA model into the execution engine. Finally,the engine executes transformation rules to generatea BPEL process and a WSDL file for the alteredCCA model.

8 Conclusions

Our motivation is to provide an economical and fea-sible solution to deal with the difficult problems thatthe enterprise computing systems are faced with un-der distributed and heterogeneous environments. Toachieve this goal, we propose a model driven devel-opment framework which sits on the top of MDA,Web services, and the EDOC profile. This frameworkcan support the complete process of top-down modeldriven enterprise Web services development.

This work proposes complete transformation rulesfrom EDOC CCA models to WSDL specified Webservices interfaces and BPEL specified Web servicesorchestration specification. Though currently we donot provide formal proof for semantic consistency intransformation, we have implemented a prototype ofthese rules as a proof of concept. Besides, this workoffers a substantial approach to leverage the reuse ofdesign artifacts advocated in the MDA, because wecan apply this approach to generate Web services or-chestration specifications on different target platforms(BPML, WSCI, etc), by revising the transformationrules. In general, due to the advantages of MDA andWeb services, this work liberates application develop-ers from such nightmares as distributed heterogeneousintegration, migration and software reuse.

This work reveals that not all the elements of CCAcan be transformed to BPEL, and not all the ele-ments of BPEL can be transformed from CCA meta-models. In CCA, a MultiPort combines a set of portswhich are behaviorally related and each of them will"buffer" information sent to it until all of them havereceived data. However, there is no such an elementin BPEL corresponding to CCA MulitPort. In BPEL,the <assign> activity copies data from one variable

to another. Nevertheless, there is no element in CCAcorresponding to BPEL <assign>. If we want to gen-erate a BPEL Process which includes all the elementsof BPEL specification, either we need to add BPELrelated elements to the CCA meta-model, or we needto add some elements to the generated BPEL Processmanually. Because on one hand, adding BPEL relatedelements to CCA meta-model will make the EDOCprofile more BPEL specific, and on the hand, mostof the BPEL elements can be generated automaticallyusing our approach, we choose to alter the Processmanually if needed.

Two-way transformation is not supported in ourcurrent approach, because when one CCA element ismapped to more than one BPEL elements, the reversemapping is impossible. Integrating nonfunctional arti-facts into this framework is our current consideration.

Some researchers may consider that the EDOC pro-file is outdated by the introduction of UML 2.0, whichintroduces concepts replacing those of the EDOCCCA. However, in our opinion, UML 2.0 is no morethan a general modeling language, and it must be tai-lored to satisfy requirements of specific domains, suchas the EDOC domain and the real time domain. UML2.0 can not replace the EDOC profile but coexistswith it. On the other hand, our framework can supportmodel driven Web services development with UML2.0 specifying PIMs, if we propose transformation rulesfrom UML 2.0 to WSDL and BPEL.

Acknowledgements Supported by the National Natural ScienceFoundation of China (No. 60673125 and No. 60425204), theNational Grand Fundamental Research 973 Program of China(No. 2002CB312001), and by the Jiangsu Province ResearchFoundation (No. BK2007714).

References

Arkin, A., Askary, S., Fordin, S., & Kawaguchi, K. (2002). Webservice choreography interface (WSCI) 1.0

Anzbök, R., & Dustdar, S. (2005). Semi-automatic generation ofWeb services and bpel processes—a model-driven approach.LNCS, vol. 3649 (pp. 64–79). Berlin: Springer.

Andrews, T. (2003). Business process execution language for Webservices, Version 1.1.

Arkin, A. (2002). Business process modeling language (BPML).Specification.

ATLAS Group (February 2005). ATLAS transformation lan-guage. Retrieved from http://www.sciences.univ-nantes.fr/lina/

Bézivin, J., Dupé, G., Jouault, F., Pitette, G., & Rougui, J. E.(2003). First experiments with the ATL model transforma-tion language: Transforming XSLT into Xquery. In Proceed-ings of the 2nd OOPSLA Workshop on Generative Tech-niques in the Context of Model Driven Architecture.

For Research Only

408 Inf Syst Front (2007) 9:391–409

Barros, A., Dumas, M., & Oaks, P. (2005). A critical overviewof the Web service choreography description language(WS-CDL). BPTrends Newsletter, vol. 3.

Bézivin, J., Hammoudi, S., Hammoudi, S., Lopes, D., & Jouault, F.(2004). Applying MDA approach for Web service platform.In Proceedings of the 8th IEEE international enterprise dis-tributed object computing conference (EDOC’04).

Birbeck, M. (2001). Professional XML (2nd ed.), France: Wrox.Braun, P., & Marschall, F. (2002) Transforming object models

with Botl. Electronic Notes on Theoretical Computer Science,72(3).

Bauer, B., & Müller, J. P. (2004). MDA applied: From sequencediagrams to Web service choreography. In Proceedings ofICWE 2004, LNCS, vol. 3140 (pp. 132–136). Berlin: Springer.

Bordbar, B., & Staikopoulos, A. (2004). On behaviouralmodel transformation in Web services. LNCS, vol. 3289(pp. 667–678). Berlin Heidelberg: Springer-Verlag.

Cao, F., Bryant, B., Gray, J., Burt, C., Raje, R., Olson, A. et al.(2003). Modeling Web services: Toward system integrationin uniframe. In Proceedings of the 7th World Conference onIntegrated Design and Process Technology.

Dong, X., Halevy, A., Madhavan, J., Nemes, E., & Zhang, J.(2004). Similarity search for Web services. In Proceedings ofthe 30th VLDB Conference.

Gerber, A., Lawley, M., Raymond, K., Steel, J., & Wood, A.(2002). Transformation: The missing link of MDA. In Pro-ceedings of the first international conference on graph trans-formation, Barcelona, Spain.

Grønmo, R., Skogan, D., Solheim, I., & Oldevik, J. (2004).Model-driven Web services development. InternationalJounal of Web services Research, 1(4).

IBM. Websphere. Available at http://www-306.ibm.com/software/websphere/.

Jiang, Q., Zhao, J. H., Li, X. D., & Zheng, G. L. (2005). A MDAmodel transformation tool for EDOC ER models. Journal ofNanjing University, 41, 512–520.

Kath, O., Blazarenas, A., Born, M., Funabashi, M., & Hirai, C.(2004). Towards executable models: transforming edocbehavior models to CORBA and BPEL. In Proceedingsof the 8th IEEE International Enterprise Distributed ObjectComputing Conferenc (EDOC’04). IEEE Computer Society(pp. 267–274).

Klepper, A., Warmer, J., & Bast, W. (April 2003). The modeldriven architechure: Practice and promise. Redwood City,CA: Addision Wesley.

Lopes, D., Hammoudi, S., Bézivin, J., & Jouault, F. (2005).Generating transformation definition from mapping specifi-cation: Application to Web service platform. In Advancedinformation systems engineering: Proceedings of the 17thInternational Conference, CAiSE 2005. LNCS, vol. 3520(pp. 309–325). Berlin: Springer.

Mendling, J., & Hafner, M. (2006). From WS-CDL choreogra-phy to BPEL process orchestration. Technical report, ViennaUniversity of Economics and Business Administration.

OMG (2001a). Business process modeling notation specifi-cation.

OMG (July 2001b). Model driven architecture (MDA),document number ormsc/2001-07-01.

OMG (December 2001c). UML profile for enterprise distrib-uted object computing specification(EDOC). OMG docu-ment number: ptc/2001-12-04.

OMG (April 2002). MOF 2.0 Query/Views/TransformationsRFP, OMG document: ad/2002-04-10.

OMG (November 2005). Meta Object Facility (MOF) 2.0Query/View/Transformation specification, final adoptedspecification, ptc/05-11-01.

Oracle. BPEL Process Manager. Available at http://www.oracle.com/technology/products/ias.

Ouyang, C., van der Aalst, WMP., & Dumas, AHM.ter Hofstede M. (2006). Translating BPMN to BPEL. Tech-nical report. Retrieved from http://www.BPMcenter.org.

Patrascoiu, O. (2004a). Mapping EDOC to Web serviceusing YATL. In Proceedings of the 8th IEEE Interna-tional Enterprise Distributed Object Computing Conference(EDOC’04). IEEE Computer Society, pp. 286–297.

Patrascoiu, O. (2004b). YATL: Yet another transformation lan-guage. In Proceedings of the First European WorkshopMDA-IA.

QVT Partners (2003). MOF Query/Views/Transformations(revised submission).

Skogan, D., Grønmo, R., & Solheim, I. (2004). Web service com-position in UML. In Proceedings of the 8th IEEE Interna-tional Enterprise Distributed Object Computing Conference(EDOC’04). IEEE Computer Society, pp. 47–57.

Soley, R. and the OMG Staff Strategy Group (November 2000).Model driven architecture. Object Management Group whitepaper.

Tang, K., Chen, S., Levy, D., Zic, J., & Yan, B. (2006). A per-formance evaluation of Web service security. In Proceedingsof the 10th IEEE International Enterprise Distributed ObjectComputing Conference (EDOC’06).

UDDI.org (September 2004). Retrieved from http://www.uddi.org/.

W3C (September 2004a). Retrieved from http://www.w3.org/TR/wsdl/.

W3C (September 2004b). Retrieved from http://www.w3.org/TR/SOAP/.

White, S. A. (May 2004). Business process modeling notation(BPMN), version 1.0.

Yang, J. (2003). Web service componentization: towards servicereuse and specialization. Communications of ACM, 46(10),35–40.

Yu, X., Zhang, Y., Zhang, T., Wang, L., Zhao, J., Guoliangzheng,Z. et al. (2007). Towards a model driven approach toautomatic bpel generation. In Proceedings of EuropeanConference on Model-driven Architecture: Foundations andApplications (ECMDA-FA) 2007. Berlin:Springer.

Xiaofeng Yu is currently a Ph.D. candidate in Computer Scienceat Nanjing University. He received a B.S. and M.S. in AircraftManufacturing Engineering at Nanjing University of Aeronauticsand Astronautics in 1998 and 2003. His research interests in-clude software engineering, Model Driven Engineering, ServiceOriented Computing and E-business.

Yan Zhang is currently a postDoc in Computer Science atPeking University. He received a Ph.D. in Computer Sciencefrom Nanjing University in 2007. His research interests includeModel Driven Engineering, Service Oriented Computing andsofter architecture.

Tian Zhang is a PhD candidate in the Department of ComputerScience & Technology, Nanjing University. HIs main researchinterests are concerning to model driven engineering. Currently,he is conducting work to promote MDA by introducing designpatterns as modeling and model transforming units to MDAdevelopment.

For Research Only

Inf Syst Front (2007) 9:391–409 409

Dr. Linzhang Wang is an assistant professor at the Departmentof Computer Science and Technique in Nanjing University. Hisresearch is on model-driven software testing and verification,as well as automatic software testing and verification tools. Dr.Wang received a B.S. in Computer Application at ShenyangUniversity of Technology in 1995, and a Ph.D. in ComputerScience at Nanjing University in 2005.

Jun Hu is now a lecturer in Department of Computer Scienceand Technology at Nanjing University of Aeronautics and Astro-nautics. He received a B.S. in Automation Control at NanjingUniversity of Aeronautics and Astronautics in 1994, a M.S. inCivil Aviation at Nanjing University of Aeronautics and Astro-nautics in 2002, and a Ph.D. in Computer Science at NanjingUniversity in 2006. His research interests include software engi-neering, model checking for real-time and embedded systems andcontrol theory and engineering.

Jianhua Zhao is a professor in the Department of ComputerScience and Technology at Nanjing University. He received hisPh.D. from Nanjing University in 1999. His research interestsinclude software engineering, formal method, especially modelchecking technique for real-time systems. He has directed oranticipated several Chinese National Natural Science Foundationprojects, and Chinese Hi-Tech projects. He has published over 20research papers in journals and international conferences.

Xuandong Li received the BS, MS, and PhD degree in ComputerScience from Nanjing University in 1985, 1991 and 1994. Since1994 he has been in the Department of Computer Science andTechnology at the Nanjing University where he is currentlya professor. His research interests include formal support fordesign and analysis of reactive, disturbed, real-time, and hybridsystems, software testing and verification, and service orientedcomputing.

For Research Only