MODEL-DRIVEN APPROACH FOR USER-CENTRIC

MASHUPED SOA

Meriem Benhaddi

University of Cadi Ayyad, Faculty of Science Semlalia, Prince My Abdellah boulevard

B.P. 2390, 40000 Marrakech, Morocco

Karim Baïna

University of Mohammed V-Souissi, ENSIAS (Ecole Nationale Supérieure d’Informatique et d’Analyse des Systèmes)

BP. 713, Agdal-Rabat, Morocco

El Hassan Abdelwahed

University of Cadi Ayyad, Faculty of Science Semlalia, Prince My Abdellah boulevard

B.P. 2390, 40000 Marrakech, Morocco

Keywords: SOA, Web 2.0, Mashup, User-centric, SOA user-centric, End User Development, Composition, Model

Driven Approach.

Abstract: The Mashup - a new Web 2.0 technology - has emerged as a new way to promote and to enable the End

User Development approach. In fact, as underlined by (Boris Büchel and al., 2009), the Mashup targets the

inexperienced end-user, and allows him to develop his own applications. The Service Oriented Architecture

(SOA) is enhanced and made user-centric via the Mashup that allows end users, without any technical skills

or advanced knowledge on the SOA, to compose services. However, mixing services with Mashup provide

fragile and non stable solutions; hence the need to convert the Mashup solution into BPEL to benefit from

the ease of composition of Mashup and the strength and the security of the BPEL engine. In Model Driven

Development, an essential idea is to automatically transform models from one modelling domain to another.

In this paper we present a new approach based on the Model Driven Development paradigm to transform

the SOA logic composition from a Mashup script into a BPEL script.

1 INTRODUCTION

The concepts behind the Service Oriented

Architecture have proved that it is the best way to

build a flexible enterprise information system by

modulating applications as interoperable services.

However, The Service Oriented Architecture lacks

the characteristic of being user-centric due to the

neglect of the creative potential of the end user, not

involved in the life cycle of the SOA software. More

particularly, the end user doesn’t have the possibility

to create its own applications or to customize

applications created by other users. In the other

hand, Mashup has emerged as a new technology that

enables the end user development; web resources,

and particularly web services, could be mixed to

create new applications.

The Mashup uses different languages as Java,

PHP or EMML to create scripts. However, Mashup

tools do not provide stable applications; (Amin

Anjomshoaa, 2010) asserts that the solutions

provided by Mashup tools are fragile, neither stable

nor robust (Figure 1). Unlike formal business

process (ex. BPEL solutions), Mashup applications

do not benefit from strong and secured engine as

BPEL engine.

The traditional SOA and mashup solutions may

be complementary in the sense that the Mashup

allows easy creation of situational applications (that

meet a particular need), requiring no technical

advanced knowledge, but suffering from instability.

116

Benhaddi M., Baïna K. and Abdelwahed E..

MODEL-DRIVEN APPROACH FOR USER-CENTRIC MASHUPED SOA.

DOI: 10.5220/0003477401160123

In Proceedings of the 13th International Conference on Enterprise Information Systems (ICEIS-2011), pages 116-123

ISBN: 978-989-8425-56-0

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

Figure 1: SOA Solution vs. Mashup solution (Amin

Anjomshoaa, 2010).

On the other hand, traditional SOA allows

experts to create robust solutions that include a high

level of complexity; end users still remaining outside

the loop of SOA development. To solve this

problem, a key would be to benefit from the

strengths of the two solutions (Mashup and SOA).

This solution would rapidly develop situational

applications using mashup technology and provide a

tool to translate the Mashup logic into the SOA logic

(ex. BPEL) that is more stable and robust. At the

end, the end user will benefit from the ease of

composition of the Mashup and from the power of

classical SOA composition engine. (Anjomshoaa

Amin and al., 2010).

Related work has focused on this problem of

conversion between Mashup solution and SOA

solution, or between Mashup logic and SOA logic.

(Anjomshoaa Amin and al., 2010) proposes a

converter Mashup-BPEL which allows transfering

the Mashup execution process located on the client

browser to a BPEL engine in the server side. This

converter uses the Mashup widgets and the

connections between them to provide the resulting

SOA service as a BPEL file deployable in any BPEL

engine. The Mashup widgets being translated into

"invoke" BPEL operations (Figure 2).



Figure 2: Simple example of a mashup (left) and its

generated BPEL process (right) (Amin Anjomshoaa,

2010).

Another way to transform a mashup into a BPEL

code is to use an intermediate language, which

facilitates the transition Mashup-BPEL. (Xiang Fu

and al., 2004) proposes a framework where BPEL

specifications are translated into an intermediate

representation using guarded automata.

In the same idea of using an intermediate

language, (Francisco Curbera and al., 2007)

proposes a minimalist language of choreography and

execution that offers a development model based on

the workflow and dedicated to server-side scripts of

all applications types that interact with client

browsers, REST resources, remote functions

available through URLs, and local functions

available through Java or JavaScript invocation

methods. The process model of this approach

implements a subset of the execution semantics of

BPEL, which is a graph containing atomic actions

(activities) and links between them (Florian

Rosenberg and al., 2009).

2 MODEL DRIVEN

DEVELOPMENT APPROACH

2.1 The Approach Description

Model Driven Development (MDD) is an emerging

technology for software development, focusing on

the role of models and enabling the automatic

creation of code through predefined model

transformations. The Model Driven Architecture

(MDA) is a variant of MDD suggested by the Object

Management Group (OMG), which provides a set of

guidelines for the structuring of specifications

expressed as models and the transformations

between these models.

In this section, we shall present our Model

Driven Development approach whose goal is to

generate a BPEL code from end users specifications

or needs. In fact, using a Mashup platform, the end

users will graphically express their needs that consist

of services to compose, and through automatic

transformations we will generate the BPEL code

(Figure 3).

Our process involves three transformations:

 Transformation 1: when the end user

expresses graphically the services that he wants

to compose and how, the Mashup platform

generates a Mashup script. Then, based on the

Mashup Meta-model, we will automatically

generate the Mashup model (UML class

diagram)

 Transformation 2: this step is the most

important phase of our approach because it

represents the bridge between the Mashup

world and the SOA world. In fact, using rules

MODEL-DRIVEN APPROACH FOR USER-CENTRIC MASHUPED SOA

117

Figure 3: Model Driven Development approach for a Mashuped SOA.

Figure 4: Mashup stack.

that establish the correspondences between the

Mashup elements (Mashup Meta-model) and

the BPEL elements (BPEL Meta-model), we

will automatically generate the BPEL model

(UML class diagram)

 Transformation 3: from the BEPL model

obtained from the previous transformation, we

will use a tool to generate the BPEL code.

Our approach is divided into four stages: 1) The

construction of the Mashup Meta-model, 2) The

construction of the BPEL Meta-model, 3) The

creation of a mapping layer between Mashup and

BPEL Meta-models, 4) The implementation of the

model transformation.

2.2 From PIM to Mashup-PSM

As mentioned in the last section, the end user will

expresses graphically the services that he wants to

compose and how, then the Mashup platform

generates a Mashup script. From this script file, we

will automatically generate the Mashup model based

on the Mashup Meta-model. This section is

dedicated to the construction of the Mashup Meta-

model.

The Mashup is based on a set of languages and

protocols; in (M. Benhaddi and al., 2010) we

presented a Mashup stack model that gathers the

different basic technologies, and which is inspired

by the MVC (Model-View-Controller) design

pattern. This Mashup stack contains an intermediate

layer (API) that binds a resource (service

component) considered as the Model, and its

graphical representation (GUI component)

considered as the View and manipulated by end

users.

The Mashup stack presented below includes

vertical and cross layers.

The six vertical layers stand the process of creating a

Mashup application, and the two cross layers

represent common services to all the company

services.

Concerning the “Mashup Components

Assembly” layer, Mashup technologies use different

techniques to link resources, to manipulate and

transform data. The Mashup composition techniques

also called “increase” by (Matthias Kunze, 2009)

and that specifies the control flow, consist of two

approaches:

 Approach based on the Interaction of

Software Components: this approach defines

how the data of a component are connected to

the data of another, assuming that the

components are ready (Matthias Kunze, 2009)

(Jin Yu et al. , 2008). This approach generally

called Wiring and characterized by performing

aggregation after instantiation of the application,

can be divided into three styles of orchestration:

1- flows-based (sequences of tasks or

components), 2- events-based (components

behavior synchronization), or 3- layout-based

(arrangement of visual components) (Jin Yu et

al., 2008), where the event-based style is the

most used (Matthias Kunze, 2009).

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

118

 Approach based on the Aggregation of Data:

this approach represents the sequence of

operations or functionalities and is characterized

by execution of aggregation before launching

the application by the user. The most used

technique is pipes-and-filter (eg Yahoo Pipes)

which connects filters and applies data

processing. Query languages are also a data

agregation technique that is aligned with this

approach (Matthias Kunze, 2009).

(Nick Russell and al., 2004) divided the

workflow from the data point of view into four

groups: data visibility, data interaction, data transfer

and data-based routing. The mashup uses only the

last three groups of patterns and does not cover the

data visibility patterns group (Lai Xu and al., 2010).

Most popular operators are: union, join, sort, and

filter (Lai Xu and al., 2010) (Giusy Di Lorenzo and

al., 2009). The ''Data Interaction – Task to Task''

pattern belongs to the patterns group ''Data

Interaction' and contains the two approaches or

styles (Nick Russell and al., 2004) (Jin Yu and al.,

2008):

 Blackboard Approach: this approach uses

variables (assimilated to programming

languages). Data flow is done implicitly.

 Data Channels Approach: this is the most

used approach; data flow is done explicitly.

From the Mashup stack and the component

assembly layer description, we could build the

Mashup Meta-model. Figure 5 presents the UML

classes’ diagram of Mashup entities.

As we considered that the PIM is the end user

business needs in terms of services composition, the

implementation of these needs is the responsibility

of the « Mashup component assembly » layer (figure

4); consequently, the corresponding PSM will be

represented by an instance of the « Composition

Logic » entity.

In the Meta-model above, the entity called

« Composition Logic » represents the different links

used to connect the resources participating in the

Mashup application. This « Composition Logic »

entity has a control flow type and a data flow type;

however, it represents a general entity common to all

Mashup platforms, and thus the Meta-model of

figure 5 cannot represent the Meta-model of a PSM,

as the PSM is related to a specific platform. As

depicted in figure 6, many Mashup platforms exist

with a different Mashup language for each platform.

To specify the « Composition Logic » entity, a

specific Mashup platform (or language) should be

considered, which allows looking deeply

Figure 5: Mashup stack Meta-model.

at the elements that construct the Mashup

application. The « Composition Logic » entity will

be an instance of a specific platform Meta-model (a

specific Mashup composition model).

Figure 6: Multitude of models (Mashup platforms and

languages) for the Mashup composition logic.

The Mashup language that we consider is the

Enterprise Mashup Markup Language (EMML),

which we chose to use to benefit from its

advantages: it’s an XML language created in 2006

and promoted by the Open Mashup Alliance (OMA)

(OMA Faq) that has the objective of submitting the

specification to a recognized industry standards

body. EMML is free to use, including technologies

that embed or use it.

EMML is characterized by:

 Control Flow Type: software components

interaction approach or wiring. In fact, the

aggregation is performed after instantiation of the

application. The style of aggregation is flow-

based (sequences of tasks or components).

 Data Flow Type: blackboard approach. In fact,

EMML uses Variables to manipulate data (input,

output or intermediary data)

MODEL-DRIVEN APPROACH FOR USER-CENTRIC MASHUPED SOA

119

Figure 7: EMML Meta-model.

The official EMML web site (OMA EMML

documentation) lists the syntax and the different tags

used to create a Mashup script. From this

specification, we could build the EMML Meta-

model represented by the UML classes diagram in

figure 7.

We shall explain some of the Meta-model

elements. The root element of a Mashup script is

‘mashup’ element. ‘macros’ element is the root node

for macro libraries that contain macro definitions for

use in any mashup. Other EMML elements are

classified in four groups: declarations group,

macroincludes group, statements group and

variables group.

Elements of statements and variables groups are

allowed in ‘mashup’, ‘else’, ‘elseif’, ‘for’, ‘foreach’,

‘if’, ‘macro’, ‘operation’, ‘sequence’ or ‘while’

element. Elements of declarations and

macroincludes groups are allowed in ‘mashup’,

‘operation’ or ‘macros’ element. ‘invoke’ and

‘directinvoke’ elements are used to invoke a service

or a resource. Figure 7 depicts various attributes of

‘invoke’ element; for example, the name of the

service and the specific operation to invoke, the

names list of input variables and the name of the

variable that will hold the invocation result.

2.3 From Mashup-PSM to BPEL-PSM

As shown in figure 3, once we generate the Mashup

model from end users specifications, we will create

the link between the mashup application and BPEL.

This transformation establishes a bridge between the

Mashup world and the SOA world, and it is based on

the BPEL Meta-model and the mapping rules. As

output of this stage, the BPEL model will be

automatically generated, which will be used to

create the BPEL code.

2.3.1 BPEL 2.0 Meta-model

We were based on BPEL 2.0 specification (BPEL

2.0) to build the BPEL 2.0 Meta-model (figure 8).

A BPEL process contains variables declarations,

fault handlers, partner links (links to services) and

activities. Fault handlers contain ‘catch’ or

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

120

‘catchAll’ elements. A ’partnerLink’ element

characterizes the services with which the business

process interacts. Each ’partnerLink’ is

characterized by a ‘partnerLinkType’. The name of

the ’partnerLink’ is used for all service interactions.

The role of the business process is indicated by the

attribute ‘myRole’ and the role of the partner is

indicated by the attribute ‘partnerRole’. BPEL

activities are various and are allowed in ‘process’,

‘compensationHandler’ or ‘terminationHandler’

element; each activity has optional containers

<sources> and <targets>, which contain standard

elements <source> and <target> respectively, which

are used to establish synchronization relationships

through links (BPEL 2.0). The ‘invoke’ activity

allows calling Web Services, and can enclose other

activities, inlined in fault handlers.

2.3.2 Mapping of Elements

The following table depicts the correspondence

between some of the EMML and BPEL Meta-model

elements. For example, ‘mashup’ in EMML, the

element representing the root node of an EMML

script, is mapped to a BPEL Process. The mapping

also includes the generation of a number of other

BPEL elements so that the content of the output

model corresponds entirely to that of the input. In

addition to the main Process element, variables,

partnerLinks, receive, reply and activities elements

must be generated. ‘invoke’ and ‘directinvoke’

EMML elements are converted to both ‘invoke’ and

‘partnerLink’ BPEL elements. ‘input’ EMMl

element is converted to either ‘receive’, ‘pick’ or

‘onAlarm’ BPEL element. ‘output’ EMML element

is converted to ‘reply’ BPEL element. ‘parallel’,

‘assign’, ‘for’, ‘sequence’, ‘if’, ‘elseif’, ‘else’,

‘foreach’, ‘while’ and ‘variable’ elements have the

same homologous in BPEL elements. ‘break’

EMML element is converted to ‘exit’ BPEL

element.

2.3.3 Model Transformation

For the implementation of the mapping between

Mashup and BPEL elements, we need a model

transformation language that will take the Mashup

Meta-model, the BPEL Meta-model, the mapping

rules and the Mashup Model (a Mashup-SOA

application), and will generate the BPEL Model

(Figure 9). Nowadays, there are many industrial and

academic case tools supporting model

transformation (Kermeta) (QVT) (SiTra). Simple

Transformer (SiTra) (Akehurst and al., 2006) is a

model transformation minimal framework, which

Figure 8: Relevant fragment of the BPEL 2.0 Meta-model.

Table 1: Mapping of EMML and BPEL elements.

EMML BPEL

<input>

<receive variable= >, or

<break> (only in for,

<exit>

consists of a very small and simple API that is

suitable for use by academic researchers to

experiment transformation prototypes. SiTra uses

Java for transformations specification, which avoid

the programmer from learning a new language for

the specification of transformations (Akehurst and

al., 2006). To use SiTra, the Meta-models should be

implemented in Java; this could be created manually

or using UML to Java tools.

The future implementation of our work will use

SiTra, and will experiment some Mashup scripts that

invoke Web Services.

MODEL-DRIVEN APPROACH FOR USER-CENTRIC MASHUPED SOA

121

Figure 9: Model transformation (inspired from (Hubert

Kadima, 2005)).

3 CONCLUSIONS AND FUTURE

WORK

In the last years, there was a big focus on the

convergence between the Mashup and the Service

Oriented Architecture. In fact, the Mashup has

proven to be an effective solution to promote the

SOA user-centric. However, a SOA composition

solution that will use Mashup technologies and

platforms will suffer from fragility and non stability,

unlike SOA platforms that offer robustness and

stability (ex. BPEL engine). In this paper, we

presented a Model Driven Development approach to

establish the link between a Mashup platform using

EMML (Enterprise Mashup Markup Language), and

a SOA-BPEL platform, so to convert a Mashup

EMML script that mash Web services into a BPEL

script.

The advantages of this Model Driven

Development approach compared to previously

presented approaches (Related work in

“Introduction” section) consist of:

 Dynamic and Flexible Nature: all the

transformations in related work are performed

directly and statically between the Mashup and

BPEL, and any changes in the Mashup or BPEL

specification will make the framework

unusable. Our approach puts the transformation

in a high level, where any changes in the

languages specifications (EMML or BPEL) or

in the mapping rules layer will be rapidly

handled by the framework

 Benefits from Model Generation: the SiTra

engine will provide a BPEL model that could be

used to generate a BPEL code (BPEL script or

file) executed by a BPEL engine, or as a part of

other transformations and other platforms.

While other approaches don’t provide

intermediaries results or offer intermediate

scripts using a language without a high

interoperability level.

Our future work consists of:

 Producing Mashup-EMML Model from the

Mashup-EMML script based on the EMML

Meta-model

 Implementing the Mapping Layer using

SiTra (Simple Transformer) engine and based

on the BPEL Meta-model and the mapping

rules; and experimenting Mashup scripts that

invoke Web Services

 Producing BPEL Code from the generated

BPEL model

REFERENCES

Amin Anjomshoaa, Gerald Bader, A Min Tjoa (2009).

Exploiting Mashup Architecture in Business Use

Cases. Institute of Software Technology and

Interactive Systems Vienna University of Technology,

Vienna, Austria.

Boris Büchel, Till Janner, Christoph Schroth, and Volker

Hoyer (2009). Enterprise Mashup vs. Service

Composition: What fits to reach the next stage in End-

User Development?.

BPEL 2.0. OASIS. Web Services Business Process

Execution Language Version 2.0 (April 2007),

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-

OS.html

LaiXu, Paul de Vrieze, Keith Phalp, Sheridan Jeary, and

Peng Liang (2010). Lightweight Process Modeling for

Virtual Enterprise Process Collaboration. IFIP

Advances in Information and Communication

Technology, 2010, Volume 336/2010, 501-508.

Florian Rosenberg, Rania Khalaf, Matthew Duftler,

Francisco Curbera and Paula Austel (2009). End-to-

end Security for Enterprise Mashups. International

Joint Conference on Service-Oriented Computing. Pp.

389 – 403. 2009.

Francisco Curbera, Matthew Duftler, Rania Khalaf and

Douglas Lovell (2007). Bite : Workflow Composition

for the Web. ICSOC, Vol. 4749Springer (2007), p. 94-

106. 2007. Gurpreet Singh Modi (2007). Service

Oriented Architecture & Web 2.0.

Giusy Di Lorenzo, Hakim Hacid, Hye-young Paik and

Boualem Benatallah. (2009). Data Integration in

Mashups. ACM SIGMOD Record , Volume 38 Issue 1.

Hubert Kadima (2005). MDA conception orientée objet

guidée par les modèles. Collection: InfoPro, Dunod

2005 - 240 pages, EAN13 : 9782100073566.

Kermeta. http://www.kermeta.org/. Last visit: 01/04/2011

M. Benhaddi, Karim Baïna, El Hassan Abdelwahed

(2010). Towards an approach for a user centric SOA.

The third International Conference on Web &

Information Technologies, April 2010.

ICEIS 2011 - 13th International Conference on Enterprise Information Systems

122

Matthias Kunze, (2009). Master’s Thesis, Business

Process Mashups An Analysis of Mashups and their

Value Proposition for Business Process Management.

Jin Yu, Boualem Benatallah, Fabio Casati and Florian

Daniel (2008). Understanding Mashup Development.

Journal IEEE Internet Computing, Volume 12 Issue 5.

Nick Russell, Arthur H.M. Ter Hofstede1, David Edmond

(2004). Workflow DataPatterns. Proceedings of the

24th International Conference on Conceptual

Modeling, pp. 353-368.

OMA Faq.: http://www.openmashup.org/faq/#4. Last

visit :01/04/2011

OMA EMML Documentation. http://www.openmashup.

org/omadocs/v1.0/index.html. Last visit: 01/04/2011

QVT. http://www.omg.org/spec/QVT/1.0/. Last visit:

01/04/2011

SiTra. http://www.cs.bham.ac.uk/~bxb/SiTra.html. Last

visit: 01/04/2011

Akehurst, D. H., Bordbar, B., Evans, M. J., Howells, W.

G. J., McDonald-Maier, K. D. (2006). SiTra: Simple

Transformations in Java. ACM/IEEE 9TH

International Conference on Model Driven

Engineering Languages and Systems, Vol. 4199, pp.

351–364 (2006)

Xiang Fu, Tevfiq Bultan and Jianwen Su (2004). Analysis

of Interacting BPEL Web Services. The 13th

international conference on World Wide Web, pp. 621-

630. 2004.

MODEL-DRIVEN APPROACH FOR USER-CENTRIC MASHUPED SOA

123