Feature Model based on Design Pattern for the Service Provider in the

Service Oriented Architecture

Akram Kamoun

, Mohamed Hadj Kacem

, Ahmed Hadj Kacem

and Khalil Drira

Laboratory of Development and Control of Distributed Applications (ReDCAD),

National Engineering School of Sfax, Sfax, Tunisia

Universit

e de Toulouse, CNRS, Toulouse, France

Keywords:

Service Oriented Architecture, Service Provider, Service Contract, Design Pattern, Feature Model.

Abstract:

In Service Oriented Architecture (SOA), service contracts are widely used for designing and developing the

features (e.g., services and capabilities) of Service Providers (SPs). Two of the most widely used traditional

service contracts in SOA are: WSDL and WADL. We identify that these service contracts suffer from several

problems, like: they only work for SOAP and REST communication technologies and do not rely on modeling

SOA Design Patterns (DPs). One beneﬁt of using SOA DPs is that they permit developing proven SPs for

different platforms. In order to overcome these problems, we introduce a new DP-based Feature Model (FM),

named FM

, as a service contract that models the variability of SP features including 15 SOA DPs (e.g.,

Event-driven messaging DP) and their corresponding constraints. This permits to easily identify and develop

valid SOA compound DPs. We demonstrate, through a practical case study and a developed tool, that our

allows to automatically generate fully functional, valid, highly customized and DP-based SPs. We also

show that our FM

reduces the required effort and time to develop SPs.

1 INTRODUCTION

Service Oriented Architecture (SOA) (Erl, 2007) is

a widely used distributed computing platform. An

SOA application is composed of Service Providers

(SPs) and Service Consumers (SCs) that communi-

cate through services. In this paper, we focus on

designing and developing SPs. A SP can imple-

ment different features like: capabilities (i.e., op-

erations), services and communication technologies

(e.g., Simple Object Access Protocol “SOAP”, Rep-

resentational state transfer “REST” and Middleware

Oriented Messaging “MOM”). In particular, a feature

can be designed to implement a Design Pattern (DP)

(Erl, 2009) (e.g., Event-driven messaging DP).

The DP is an appropriate and proven design so-

lution for a speciﬁc problem in a certain context. In

the practice, it is frequent to use a compound DP to

solve speciﬁc problems. A compound DP is a coarse-

grained DP, who is composed of a set of ﬁner-grained

DPs. Erl (Erl, 2009) gathers in his book 78 SOA DPs

(e.g., Event-driven messaging DP). In our work,

we focus on studying 15 SOA DPs and their possible

combinations (see Sect. 3).

In SOA, the contract-ﬁrst is a widely used ap-

proach to develop Service Providers (SPs). It consists

in developing service contracts that will be used to

generate the artifacts of the corresponding SP. A ser-

vice contract is a document (e.g., XML) of meta infor-

mation through which the SP features are expressed.

The service contract represents a core part and

one of the fundamental design principles in SOA (Erl,

2007). Two of the most widely used SOA traditional

service contracts are: Web Services Description Lan-

guage (WSDL) (Chinnici et al., 2007) and Web Ap-

plication Description Language (WADL) (Hadley and

Sun Microsystems, 2009). By studying these service

contracts, we identify that they suffer from several

problems, as follows:

P.1 they are dependent on speciﬁc communication

technologies. The WSDL and WADL only work

for the SOAP and REST communication tech-

nologies, respectively;

P.2 they do not use a standardized or common syn-

tax to deﬁne SP features. They use different syn-

taxes even to describe the same SP features (e.g.,

input and output data features). This can lead to

misinterpretation and difﬁculty to understand SP

Kamoun, A., Kacem, M., Kacem, A. and Drira, K.

Feature Model based on Design Pattern for the Service Provider in the Service Oriented Architecture.

DOI: 10.5220/0006332301110120

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 111-120

ISBN: 978-989-758-248-6

111

features;

P.3 they only allow to express a limited set of features.

This prevents the development of complex SPs;

P.4 they do not rely on modeling SOA DPs and

compound DPs (Erl, 2009). This prevents the

development of proven SPs. Developing SOA

DPs and valid compound DPs is not a straight-

forward and easy task and requires a solid core

of expert knowledge. For example, using the

Event-driven messaging DP (Erl, 2009) re-

quires the use of the Service callback DP (Erl,

2009). In this case, if a given compound DP

includes the Event-driven messaging DP but

omits the Service callback DP, then this com-

pound DP is invalid. Hence, the SP developer

must manually develop valid SOA DPs and com-

pound DPs in order to develop a valid SP;

P.5 some communication technologies (e.g., MOM)

do not offer service contracts. In this case, using

the ﬁrst-contract approach to develop SPs cannot

be possible.

In order to overcome the enumerated SOA tra-

ditional service contract problems, we propose in

this paper, a DP-based Feature Model (FM), named

. The latter is designed as a service contract

which models different SP features including SOA

DPs and valid compound DPs. It is also designed

to generate fully functional, valid and highly cus-

tomized SPs for different communication technolo-

gies (SOAP, REST and MOM). In the literature, sev-

eral FMs (Parra and Joya, 2015), (Fantinato et al.,

2008), (Wada et al., 2007), (Ed-douibi et al., 2016)

have been proposed to model the SP features. How-

ever, these FMs do not permit to generate fully func-

tional SPs and do not model DPs and compound DPs.

The rest of this paper is structured as follows. In

Sect. 2, we provide a brief overview of the FM. In

Sect. 3, we introduce our FM

. In Sect. 4, we eval-

uate our FM

through a practical case study. In

Sect. 5, we discuss some related works. This paper

is concluded in Sect. 6.

2 A BRIEF OVERVIEW OF THE

FEATURE MODEL

The Software Product Line (SPL) (Pohl et al., 2005)

is a paradigm whose goal is the mass-customization

of applications that ﬁt individual customer needs. In

this context, it relies on the variability modeling of

the application artifacts (e.g., source code and design)

to develop customized applications. The variability

consists in the ability of an artifact to be customized

or conﬁgured in a particular context.

The FM (Czarnecki et al., 2005) is the defacto

standard for variability modeling in SPL. It permits to

model the customized applications, based on features,

that the SPL offers to generate. The FM expresses the

legal combination of features to derive customized ap-

plications (e.g., see Fig. 1). An end user can derive

from this FM, an Application Model (AM), by select-

ing the required features and deselecting the others, in

line with the constraints of the FM (e.g., see Fig. 3).

Based on the features of this AM, the SPL will gener-

ate the artifacts of the corresponding application.

The structure of the FM is a rooted tree of features

that can be deﬁned through different notations (Czar-

necki et al., 2005). Many FM metamodels (Kang and

Lee, 2013), (Czarnecki et al., 2005) have been pro-

posed in the literature that offer different notations.

In this work, we rely on the FM metamodel of Czar-

necki et al. (Czarnecki et al., 2005) because its nota-

tions (see Fig. 1) allow to efﬁciently express the SP

features.

We present in Fig. 1, these notations that will be

brieﬂy presented in the following. The feature can be

either mandatory or optional. The feature attribute al-

lows to add an attribute value (e.g., integer) to specify

extra-functional information for features. The feature

[min, max] deﬁnes the lower and upper bounds of in-

stances of a given feature. The “requires” constraint

is in the form: if a feature A requires a feature B, then

the selection of A in the AM requires the selection of

B. The “excludes” constraint is in the form: if a fea-

ture A excludes a feature B, then both features cannot

be selected in the same AM. The feature group XOR

[1, 1] allows selecting exactly one out of its child fea-

tures which can be called as alternative exclusive fea-

tures. The feature group OR [1, n] allows selecting

one or many of its child features which can be called

as alternative inclusive features. The FM allows to

deﬁne complex constraints between features (e.g., see

the propositional constraints in Fig. 1).

3 FEATURE MODEL FOR THE

SERVICE PROVIDER F

In this paper, we propose a new DP-based FM,

named FM

(see Fig. 1), which allows to generate

fully functional, valid and highly customized Service

Providers (SPs) for different communication tech-

nologies (SOAP, REST and MOM). Our FM

is de-

signed as a service contract, which models 46 SP fea-

tures, that permits to overcome the SOA traditional

service contract problems (see Problems P.1, P.2, P.3,

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

112

P.4 and P.5 in the introduction). We present in Table 1

the descriptions of these features.

We rely on 15 SOA DPs (Erl, 2009) to

develop our FM

, which are: Contract

centralization DP, Service messaging DP,

Direct authentication DP, Service agent DP,

Intermediate routing DP, Service callback

DP, Asynchronous queue DP, Event-driven

messaging DP, Reliable messaging DP, Atomic

service transaction DP, Dual protocols

DP, State messaging DP, Stateful services

DP, Service instance routing DP and State

repository DP. These DPs are described as features

in our FM

Mathematically, there exist 2

compound DPs

that represent the existence or the non-existence of the

15 DPs. However, not all of these compound DPs are

valid. For example, in order to use the Event-driven

messaging DP, it is necessary to use the Service

callback DP (see Sect. 3.2). Hence, if a given com-

pound DP includes the Event-driven messaging

DP but omits the Service callback DP, then this

compound DP is invalid. One of the main challenges

tackled in this work is to identify and model the valid

compound DPs in our FM

. In this context, it is

crucial to identify and model the constraints between

DPs in FM

(see Sect. 3.2). Erl presents several

constraints between these DPs (Erl, 2009). However,

he illustrates them in many dispersed diagrams. This

makes difﬁcult to identify properly these constraints.

Also, many constraints are missing.

3.1 Beneﬁts

Our FM

is designed to overcome the SOA tradi-

tional service contract problems (see Problems P.1,

P.2, P.3, P.4 and P.5 in the introduction). We present

in the following the beneﬁts of our FM

and which

problems they consider:

1. it relies on the FM notations which permit to

efﬁciently model the features and complex con-

straints (i.e., propositional constraints) of the SP.

Also, the FM graphical presentation can be eas-

ily interpreted and facilitate deriving customized

and valid SPs. In order to generate a valid SP,

the SP developer only needs to derive an AM

(e.g., see Fig. 3), by selecting the required fea-

tures and deselecting the others, from FM

(see

Fig. 1). This facilitates the mass-customization of

SPs. The constraints presented in FM

allow to

guide the SP developer to derive valid AM

(con-

sidering Problems P.1, P.2, P.3 and P.5);

2. it is designed as a service contract for SP which

is generic and independent of the communication

technologies. It can be considered as a refer-

ence model (Galster et al., 2013) which reﬂects

the variability of practical SP features (consider-

ing Problems P.1, P.2, P.3 and P.5);

3. it includes the required features to generate fully

functional, valid and highly customized SPs. This

reduces the required effort and time to develop

SPs (considering Problems P.1, P.2, P.3 and P.5);

4. it models 15 DPs and their corresponding con-

straints (see Sect. 3.2). This permits to easily

identify and derive the valid compound DPs. By

using the FAMILIAR tool (Acher et al., 2013),

we identify, from the DPs constraints modeled in

, that there are 406 valid compound DPs

from 2

possible ones (considering Problem P.4);

5. many beneﬁts can be enumerated when express-

ing DPs as features in our FM

. DPs are in-

troduced by veteran problem solvers in order to

provide appropriate and proven design solutions.

A DP shows the right level of abstraction to de-

scribe a certain solution in a generic context, i.e.,

independently of the programming languages and

platforms. It also has a major beneﬁt of providing

a common language which it is understandable by

the developers instead of using terminologies re-

lated to a certain context. For example, simply

saying the Event-driven messaging DP (Erl,

2009) is more efﬁcient and easier than to explain

it in details. Hence, integrating DPs in our FM

allows to ensure that the SPs that can be derived

are based on proven solutions and can be used to

generate the artifacts for different contexts (con-

sidering Problems P.1, P.2, P.3, P.4 and P.5);

3.2 Constraints of the Design Patterns

We discuss here the constraints between the 15 DPs

modeled in our FM

(see Fig. 1). These constraints

have been identiﬁed from theoretical and practical

studies that we have led which are essentially based

on these works (Erl, 2009), (Ibsen and Anstey, 2011),

(Giacomelli, 2012), (Switchyard, 2016).

We express the feature Contract

centralization DP as mandatory because our

is designed as a service contract that models

the SP features, like the SOAP, REST and MOM commu-

nication technology features. In the introduction, we

mention that the MOM does not offer a service contract

(see Problem P.5). Because our FM

models the

MOM features, then it can be considered as a service

contract for MOM. Hence, it would be possible to use

the ﬁrst-contract approach to develop SPs based on

the MOM features.

Feature Model based on Design Pattern for the Service Provider in the Service Oriented Architecture

113

Asynchronous

queue DP

Atomic service

transaction DP

Acknowledgement

Persistent delivery

Event-driven

messaging DP

MOM

Reliable

messaging DP

Durable

Service callback

Intermediate

routing DP

Service agent DP

State

Stateful

services DP

State messaging

Service instance

routing DP

Internal

memrory

Storage

mode

Communication

technology

SOAP

1.1 1.2

Post

Get

Put

Delete

REST

Input

Output

OName

OType

OData class

name

Capability

name

Capability

Service

Service name

Service contract

[1,n]

Address

State repository DP

Temporary memory

Propositional constraints:

1: Dual protocols DP ↔ ((MOM ∧ REST) ∨ (MOM ∧ SOAP) ∨ (REST ∧ SOAP) ∨ (MOM ∧ REST ∧ SOAP))

2: (MOM ∧ Output) → (Atomic service transaction DP ∨ Acknowledgement)

Direct authentication

Dual protocols

Service

messaging DP

Contract

centralization DP

OData

[1,n]

IName

IType

IData class

name

IData

[1,n]

Figure 1: Feature model FM

(design pattern features are

colored).

Table 1: Descriptions of the features of FM

Feature name Description

Service contract Root feature

Address Address of the SP

Service [1, n] Services of the SP

Service name Service name

Capability [1, n] Capabilities of the SP

Capability name Capability name

Input Input data of a given capability

IData [1, n] Gathering input data features

IName Input data name

IType Input data type

IData class name Input data class name (e.g., Java

class name)

Output Output data of a given capability

OData [1, n] Gathering output data features

OName Output data name

OType Output data type

OData class

name

Output data class name (e.g., Java

class name)

Communication

technology

Gathering the communication

technologies

SOAP SOAP communication technology

1.1 SOAP version 1.1

1.2 SOAP version 1.2

REST REST communication technology

Get HTTP get method for REST

Post HTTP post method for REST

Put HTTP put method for REST

Delete HTTP delete method for REST

MOM Middleware oriented messaging

communication technology

Durable The MOM stores the messages of

the publisher (i.e., SP) for the sub-

scribers (i.e., SCs) if the latter dis-

connect. Upon reconnecting, the

subscribers will receive all these

messages

Acknowledgem-

ent

The MOM acknowledges the SP

about the received messages

Persistent deliv-

ery

Persisting the SP messages in a

data store so they are not lost if the

MOM fails. Therefore, we ensure

that the SP messages are delivered

to the SC

Contract central-

ization DP

Gathering the SP features within

the service contract so it will be

used by the SC as the sole entry

point to communicate with the SP

Direct authenti-

cation DP

Requiring that the SCs must pro-

vide authentication credentials to

invoke a capability

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

114

Table 1: Descriptions of the features of FM

(cont.).

Service messag-

ing DP

Using a messaging-based com-

munication technology which re-

moves the need for persistent con-

nections and reduces coupling re-

quirements between the SP and

Service agent DP Deferring some logic (e.g., log-

ging messages) from services to

event-driven programs to reduce

the size and performance strain of

services

Intermediate

routing DP

Dynamically routing messages

through the use of a service agent

Service callback

Redirecting the SP response mes-

sages to a callback address that

can be different of the requester

SC address

Asynchronous

queue DP

Deploying an intermediary MOM

allowing the SP and SC to asyn-

chronously communicate and to

independently process messages

by remaining temporally decou-

pled

Event-driven

messaging DP

Asynchronously sending the re-

sponse messages of the publisher

(i.e., SP), when ready, to its corre-

sponding subscribers (i.e., SCs)

Reliable messag-

ing DP

Adding a reliability mechanism to

the SP response messages in order

to ensure message delivery. This

mechanism relies on acknowledg-

ing the SP messages and persist-

ing them in a data store

Atomic service

transaction DP

Treating a group of the SP re-

sponse messages as a single work

unit. The latter is wrapped in a

transaction with a rollback feature

that resets all actions and changes

if the exchanging messages fails

Dual protocols

The capability is designed to sup-

port two or more communication

technologies

State Gathering the techniques that han-

dle the state data of capabilities

Stateful services

Managing and storing state data

by intentionally stateful utility ser-

vices

Service instance

routing DP

Supplementing the exchanged

messages with an instance identi-

ﬁer, given by the SP as messaging

metadata, so the SC uses it to

communicate with the same

instance of a given capability

Table 1: Descriptions of the features of FM

(cont.).

State messaging

Delegating the storage of state

data to the SP response messages

instead to the SP internal memory

State repository

Deferring storing state data from

a temporary memory to a state

repository

Internal memory Storing the state data in the SP in-

ternal memory

Storage mode Gathering the modes of how the

state data are stored

Temporary

memory

Storing and managing the state

data in a temporary memory

3.2.1 Constraints between the Design Patterns

with the Communication Types

The SC needs to send a request message to the SP in

order to invoke a capability. This communication type

is called one-way. If this capability returns a response

message, then the communication type is called two-

way. In FM

, the feature Output represents the two-

way communication type. If this feature is omitted

when deriving an AM

, then the result type of the

capability is void and the communication type is con-

sidered as one-way.

The features Service callback DP, Atomic

service transaction DP, Reliable messaging

DP and State messaging DP can be only applied for

the SP response messages, i.e., for the two-way com-

munication type (see Table 1). Thus, we deﬁne “re-

quires” constraints from these features to the feature

Output.

3.2.2 Constraints of the Communication Design

Patterns

We express the feature Service messaging DP as

mandatory because the three communication tech-

nologies (SOAP, REST and MOM) expressed in the FM

are messaging-based.

The Dual protocols DP requires that a given

capability must support two or more communication

technologies and vice-versa. The ﬁrst propositional

constraint deﬁned in FM

implements this require-

ment.

The SOAP and REST rely on a synchronous com-

munication for the message exchanging between the

SP and SC. The problem of the synchronous commu-

nication is that it forces processing overhead because

the SP and SC must wait and continue to consume re-

sources (e.g., memory) until they ﬁnish the message

exchanging. To overcome this problem, the asyn-

chronous communication is used as a solution. Also,

Feature Model based on Design Pattern for the Service Provider in the Service Oriented Architecture

115

in certain cases, it is necessary to implement (i.e., de-

velop the artifacts of) the features Atomic service

transaction DP and Reliable messaging DP.

In this context, it is possible to conﬁgure the SOAP

and REST to implement the features Atomic service

transaction DP and Reliable messaging DP

and to support the asynchronous communication by

implementing the feature Service callback DP.

However, this requires signiﬁcant costs associated

with necessary infrastructure upgrades in the SP and

also in the SC (Erl, 2009). In the other hand, the MOM

offers advanced functionalities to implement these

features in both the SP and SC. Thus, we propose

implementing these features with the feature MOM.

Hence, we express the three asynchronous communi-

cation DPs (Service callback DP, Asynchronous

queue DP and Event-driven messaging DP),

the Atomic service transaction DP and the

Reliable messaging DP as child features of the

feature MOM.

In the MOM, the SC request messages are always

carried on by an asynchronous queue (Giacomelli,

2012) which it is an implementation of the feature

Asynchronous queue DP. This is the reason why we

deﬁne this feature as mandatory. In order to im-

plement the feature Event-driven messaging DP,

we use an asynchronous topic (Giacomelli, 2012).

The latter is used to send asynchronously the SP re-

sponse messages as notiﬁcations to its subscribers

(i.e., SCs). The addresses of the asynchronous queue

and topic are different. In this context, we deﬁne a

“requires” constraint from the feature Event-driven

messaging DP to the feature Service callback

DP because one need redirecting the SP response mes-

sages to the asynchronous topic address.

In the case where the features Asynchronous

queue DP and Service callback DP are selected

and the feature Event-driven messaging DP is

omitted when deriving an AM

, then the SC request

and SP response messages are handled by two differ-

ent asynchronous queues with different addresses. If

the Service callback DP is omitted, then all mes-

sages are handled by a single asynchronous queue.

Because the MOM communication technology en-

sures a loosely coupled and an asynchronous commu-

nication between the SP and SC, then it should inform

the SP and SC if their outgoing messages have been

successfully received. In this context, the MOM should

use either the features Acknowledgement or Atomic

service transaction DP (Erl, 2009), (Giacomelli,

2012). This requirement is considered in our FM

by deﬁning these two features as mutually exclusive

and by deﬁning the second propositional constraint in

Fig. 1.

3.2.3 Constraints of the Service Agent Design

Patterns

The feature Intermediate routing DP is imple-

mented through a service agent (see Table 1). Thus,

we deﬁne the Intermediate routing DP as an op-

tional child feature of the feature Service agent

DP.

In contrast of SOAP and REST, the SC request

messages which are dedicated to MOM do not explic-

itly contain information about which capability the

SC wants to invoke. As a consequence, it would

be not possible to invoke the required capability.

As a solution, we propose implementing the feature

Intermediate routing DP that dynamically rout-

ing the SC request messages to the required ca-

pability. Hence, we deﬁne, in our FM

, a “re-

quires” constraint from the feature MOM to the feature

Intermediate routing DP.

3.2.4 Constraints of the Service State Design

Patterns

Erl reports that the service state DPs (Service

instance routing DP, State messaging DP,

Stateful services DP and State repository

DP) can be implemented in conjunction in the SP

(Erl, 2009). This requirement is implemented in our

by deﬁning these DPs as alternative inclusive

features.

The goal of the State messaging DP is dele-

gating the storage of state data to the SP response

messages. In this context, we propose implement-

ing the Service agent DP to automatically per-

form this delegation. Hence, we deﬁne, in our

, a “requires” constraint from the feature State

messaging DP to the feature Service agent DP.

4 EVALUATION

In order to show the merits and evaluate our FM

(see Fig. 1) in practice, we propose to use the case

study of the Integrated Air Defense (IAD) (see Fig. 2).

The IAD is a command and control compound of geo-

graphically dispersed force elements already in peace

time as well as in crisis. In Fig. 2, we illustrate 17

force elements which are grouped into three main

forces: ground force (command and control system,

radars, anti-aircrafts and infantry), air force (drones,

helicopters and jet aircrafts) and maritime force (air-

craft carriers and submarines). These force elements

communicate with services to achieve their missions.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

116

Infantary

Command and

control system

Radars

Anti-crafts

Ground force

Jet aircrafts

Helicopters

Drones

Air force

Maritime force

Aircraft carriers

Submarines

Figure 2: Case study of the integrated air defense.

One main requirement must be satisﬁed to realize this

IAD case study:

Requirement 1. Each of the 17 force elements illus-

trated in the IAD case study is a SP, named SP

, which

it is responsible to implement its own features (see

Fig. 1).

As illustrated in the introduction (see Problems

P.1, P.2, P.3, P.4 and P.5), the SOA traditional service

contracts WSDL (Chinnici et al., 2007) and WADL

(Hadley and Sun Microsystems, 2009) suffer from

several problems to develop SPs which prevent to ef-

ﬁciently realize the Requirement 1. In order to over-

come these problems and to efﬁciently realize the Re-

quirement 1, we propose deriving for each SP

the 17 IAD force elements a speciﬁc AM

(e.g., see

Fig. 3) from our FM

(see Fig. 1). For example, in

Fig. 2, the AM

includes the SP features of the com-

mand and control system force element.

Using our FM

has several beneﬁts as mentioned

in Sect. 3.1 like it facilitates the mass-customization

of SPs. This is important especially when we have

an important SP count to develop which it is the case

of our IAD case study (17 SPs to develop). Pohl et

al. (Pohl et al., 2005) show, from empirical investi-

gations, that a given SPL is necessary and efﬁcient if

there are more than three or four systems to develop

which it is our case.

In fact, Erl (Erl, 2009) reports that the U.S. De-

partment of Defense (DoD) has decided to plan and

manage its business IT (Information Technology) via

an architectural approach based upon SOA. The IAD

system presented in Fig. 2 is a part of the DoD’s busi-

ness IT. He also reports that due to the scale, complex-

ity and diversity of the DoDs business IT, the DoD

developed a strategy with guiding principles which

relies on the SOA DPs (Erl, 2009). In this context,

because our FM

relies on the SOA DPs, it can help

contribute to develop the DoDs business IT.

We present in Fig. 3 an example of a derived AM

that contains 40 SP features. We note that this AM

implements a valid compound DP that is composed of

15 DPs. It is possible that an AM

contains different

services and capabilities (see Fig. 1). For the sake of

simplicity, we illustrate in Fig. 3, an AM

that con-

tains a single service, named “Personal”, which it is

composed of a single capability, named “login”. The

Feature Model based on Design Pattern for the Service Provider in the Service Oriented Architecture

117

Asynchronous

queue DP

Atomic service

transaction DP

Persistent delivery

Event-driven

messaging DP

MOM

Reliable

messaging DP

Durable

Service callback

Intermediate

routing DP

Service agent DP

State

Stateful

services DP

State messaging

Service instance

routing DP

Internal

memrory

Storage

mode

Communication

technology

SOAP

1.2

Get

REST

Capability

name

Capability

Service

Service name

Service contract

Address

State repository DP

Direct authentication

Dual protocols

Service

messaging DP

Contract

centralization DP

Feature attribute values:

Address = ”http://localhost:8080/SP”

Service name = ”Personal”

Capability name = ”login”

IName = ”id”

Itype = ”String”

IData class name = ”Session”

OName = ”ok”

Otype = ”Boolean”

OData class name = ”SessionResponse”

Input

Output

OName

OType

OData class

name

OData

IName

IType

IData class

name

IData

Figure 3: Application model AM

(design pattern features

are colored).

signature of this capability has a single input data,

named “id”, with a String type and included in the

class “Session” (Java class). It also has a single out-

put data, named “ok”, with a Boolean type and in-

cluded in the class “SessionResponse” (Java class).

The goal of this capability is to enable a user to lo-

gin to his/her account. We deﬁne the SP address as

“http://localhost:8080/SP”.

We developed a tool (MSPL4SOA tool, 2017),

(Kamoun et al., 2016) that relies on the Apache Veloc-

ity

tool (a “model to code” template engine) in order

to transform a given AM

to the artifacts of the corre-

sponding SP. Our tool generates SPs based on the En-

terprise Service Bus (ESB) Switchyard (Switchyard,

2016). Switchyard is a recent free software ESB that

includes different technologies, such as the Service

Component Architecture (SCA), HornetQ (a MOM

implementation) (Giacomelli, 2012), SOAP, REST,

Spring and Apache Camel (Ibsen and Anstey, 2011).

These technologies are integrated on demand in the

generated SP depending on the features of AM

. Our

tool also relies on the FAMILIAR tool (Acher et al.,

2013) to develop and manage the FM

and AM

(e.g., to check that AM

is in conformity with FM

From the AM

illustrated in Fig. 3, our tool suc-

ceeds to automatically generate a valid and fully func-

tional SP. This generated SP has been successfully

deployed in the JBoss Java server without any fur-

ther manual interventions. It should be noted that

the SP developer can manually adapt the generated

SP to his/her application requirements (e.g., deﬁn-

ing the business logic of the SP). The generated SP

is composed of 333 Java code instructions and ﬁve

XMLs

. These XMLs permit to conﬁgure the SOAP

and MOM technologies and to conﬁgure the ESB

Switchyard. The time required to derive the AM

(see Fig. 3) and generate its corresponding SP is sev-

eral seconds. By using the SOA traditional approach

(i.e., using the SOA traditional service contracts and

relying on the tools offered by the ESB Switchyard),

we require more than 20 minutes to develop the same

SP and we need many manual interventions. Hence,

we can say that using our FM

(see Fig. 1) reduces

the required effort and time to develop valid and fully

functional SPs.

5 RELATED WORK

Many works have been proposed to model the SP fea-

tures (Wada et al., 2007), (Fantinato et al., 2008), (Ed-

http://velocity.apache.org

https://github.com/MSPL4SOA/MSPL4SOA-

tool/tree/master/generated SPs SCs/conf/sp

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

118

douibi et al., 2016), (Parra and Joya, 2015), (Kajsa

and N

avrat, 2012), (Kamoun et al., 2014). In this sec-

tion, we discuss these works and compare them with

our FM

(see Table 2).

Table 2: Comparing our FM

with related work (FGC:

Functionality of the Generated Code, CT: Communication

Technology; CDP: Compound DP).

Approach Tool FGC CT DP CDP

WSDL XML Fully SOAP - -

WADL XML Fully REST - -

Wada et al.,

2007

FM Semi n/a - -

Fantinato et

al., 2008

FM Semi SOAP - -

Ed-douibi et

al., 2016

EMF Semi REST - -

Parra and

Joya, 2015

FM Semi Generic - -

Kajsa and

avrat, 2012

FM Semi - + -

Our F

FM Fully Generic + +

Wada et al. (Wada et al., 2007) propose a FM that

expresses the variability of non-functional aspects of

the SP. Although their FM includes communication

features, it does not explicitly specify which commu-

nication technologies it supports. That is why we put

the symbol “n/a” in Table 2. Their FM can be used

to extend our FM

(see Fig. 1) in order to express

the variability of SP non-functional aspects. In con-

trast, our FM

permits to generate fully functional

SPs and models DPs and compound DPs.

Fantinato et al. (Fantinato et al., 2008) elaborate a

FM that models the variability of WSDL service con-

tract of SOAP. Our FM

is more complete than theirs

in a way that it contains the required features (e.g., the

features of the input and output data) to generate fully

functional SPs. As reported by Fantinato et al., the

input and output data features are absent in their FM.

Another advantage of our FM

is that it expresses

the variability of different communication technolo-

gies (SOAP, REST and MOM) and models DPs and

compound DPs.

Ed-douibi et al. (Ed-douibi et al., 2016) intro-

duce a MDE-based approach, called EMF-REST, that

takes EMF data models as input to generate their cor-

responding REST services. In our work, we propose

to model the REST features. Their approach

supports generating more REST features (e.g., secu-

rity features) than ours. In contrast, our FM

per-

mits to generate services with different communica-

tion technologies (SOAP, REST and MOM) and mod-

els SOA DPs and compound DPs.

Parra and Joya (Parra and Joya, 2015) propose an

approach that generates a FM (using reverse engineer-

ing techniques) from current JEE artifacts. The latter,

as afﬁrmed by the authors, can support only limited

features (e.g., the input and output data features and

the MOM features are missing). The advantage of

our FM

is that it permits to generate fully func-

tional and highly customized SPs and models SOA

DPs and compound DPs. Parra and Joya report that

their approach should be extended to generate fully

functional SPs.

Kajsa and N

avrat (Kajsa and N

avrat, 2012) intro-

duce a FM to handle the variability of the object ori-

ented DPs. The goal is to support the instantiation and

the evolution which occur to these DPs. Their work

helps to generate the artifacts of a speciﬁc DP. The ad-

vantage of our FM

is that it allows to generate the

artifacts of DPs and also of compound DPs.

6 CONCLUSION

In Service Oriented Architecture (SOA), the service

contract is one of the fundamental design principles

used to develop Service Providers (SPs). In this pa-

per, we have proposed, based on SOA Design Pat-

terns (DPs), a Feature Model (FM) for SP, named

. The latter is designed as a service contract

for SP that is generic and independent of the com-

munication technologies. We have modeled in our

15 SOA DPs (e.g., Event-driven messaging)

and their corresponding constraints. This allows to

easily identify and generate the possible valid com-

pound DPs which permits to develop valid SPs, ac-

cordingly. Based on our FM

, we have identiﬁed

that there are 406 valid compound DPs from 2

pos-

sible ones. We have demonstrated through a practical

case study and based on a developed tool, that our

permits to automatically generate valid, highly

customized, fully functional, proven and DP-based

SPs. We have shown that using our FM

reduces

the required effort and time to develop SPs. We have

also demonstrated the efﬁciency of our FM

com-

pared with related works notably the SOA traditional

service contracts WSDL and WADL.

For future research, we plan to extend our FM

by other features, including other DPs, in order to

generate more complex SPs.

REFERENCES

Acher, M., Collet, P., Lahire, P., and France, R. B. (2013).

FAMILIAR: a domain-speciﬁc language for large

Feature Model based on Design Pattern for the Service Provider in the Service Oriented Architecture

119

scale management of feature models. Science of Com-

puter Programming, 78(6):657–681.

Chinnici, R., Moreau, J.-J., Ryman, A., and Weer-

awarana, S. (2007). WSDL 2.0. https://www.w3.org/

TR/wsdl20.

Czarnecki, K., Helsen, S., and Ulrich, E. (2005). Staged

conﬁguration through specialization and multilevel

conﬁguration of feature models. Software Process:

Improvement and Practice, 10(2):143–169.

Ed-douibi, H., Izquierdo, J. L. C., G

omez, A., Tisi, M., and

Cabot, J. (2016). EMF-REST: generation of RESTful

APIs from models. In Proceedings of the 31st Annual

ACM Symposium on Applied Computing (SAC’2016),

pages 1446–1453, Pisa, Italy.

Erl, T. (2007). SOA Principles of Service Design. Prentice

Hall.

Erl, T. (2009). SOA Design Patterns. Prentice Hall.

Fantinato, M., Felgar, D. M. B., and Maria, D. I. (2008).

WS-contract establishment with QOS: an approach

based on feature modeling. Cooperative Information

Systems, 17(03):373–407.

Galster, M., Avgeriou, P., and Tofan, D. (2013). Constraints

for the design of variability-intensive service-oriented

reference architectures – an industrial case study. In-

formation and Software Technology, 55(2):428–441.

Giacomelli, P. (2012). HornetQ Messaging Developer’s

Guide. Packt Publishing.

Hadley, M. and Sun Microsystems (2009). WADL.

https://www.w3.org/Submission/wadl.

Ibsen, C. and Anstey, J. (2011). Camel in Action. Manning

Publications Corporation.

Kajsa, P. and N

avrat, P. (2012). Design pattern support

based on the source code annotations and feature mod-

els. In Proceedings of the 38th International Con-

ference on Current Trends in Theory and Practice

of Computer Science on SOFtware SEMinar (SOF-

SEM’2012), pages 467–478,

Spindler

uv Ml

yn, Czech

Republic.

Kamoun, A., Hadj Kacem, M., and Hadj Kacem, A. (2014).

Feature model for modeling compound SOA design

patterns. In Proceedings of the 11th ACS/IEEE Inter-

national Conference on Computer Systems and Appli-

cations (AICCSA’2014), pages 381–388, Doha, Qatar.

Kamoun, A., Hadj Kacem, M., and Hadj Kacem, A. (2016).

Multiple software product lines for software oriented

architecture. In Proceedings of the 25th IEEE In-

ternational Conference on Enabling Technologies:

Infrastructure for Collaborative Enterprises (WET-

ICE’2016), pages 56–61, Paris, France.

Kang, K. C. and Lee, H. (2013). Systems and Software

Variability Management: Concepts, Tools and Expe-

riences. chapter 2: Variability Modeling, pages 25–42.

Springer.

MSPL4SOA tool (2017). https://mspl4soa.github.io.

Parra, C. and Joya, D. (2015). SPLIT: an automated ap-

proach for enterprise product line adoption through

SOA. Internet Services and Information Security,

5(1).

Pohl, K., B

ockle, G., and Van Der Linden, F. (2005). Soft-

ware Product Line Engineering. Springer.

Switchyard (2016). Switchyard tool. http://switchyard.

jboss.org.

Wada, H., Suzuki, J., and Oba, K. (2007). A feature mod-

eling support for non-functional constraints in ser-

vice oriented architecture. In Proceedings of the 4th

IEEE International Conference on Services Comput-

ing (SCC’2007), pages 187–195, Salt Lake City, Utah,

USA.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

120