17th international conference on Sciences and Techniques of Automatic control STA'2016-PID4213-TCE

& computer engineering - STA'2016, Sousse, Tunisia, December 19-21, 2016

Feature Model for the Service Provider in the

Service Oriented Architecture
Akram KAMOUN, Mohamed HADJ KACEM, Ahmed HADJ KACEM
Research laboratory on Development and Control of Distributed Applications (ReDCAD),
University of Sfax, ENIS, BP 1173 Sfax, Tunisia.
E-mails: akram.kamoun@redcad.tn, mohamed.hadjkacem@isimsf.rnu.tn and
ahmed.hadjkacem@fsegs.rnu.tn

AbstractA widely used approach to develop a Ser-
vice Provider (SP) in the Service Oriented Architec-
ture (SOA), called contract-rst, consists of designing
service contracts that will be used to generate the SP
source code. The goal of a service contract is expressing
the features (e.g., services and capabilities) of the
required SP. The two most known traditional service
contracts in the literature are: WSDL and WADL.
We identify that these service contracts suer from
several problems, such as they only allow expressing
a limited set of features. In order to overcome such
problems, we propose a Feature Model (FM), named
F MSP , that can be considered as a service contract
for SP. The features of F MSP are designed to generate
valid, customized and fully functional SPs. A key point
in our F MSP is that it relies on SOA Design Patterns
(DPs) to dene its features. The constraints expressed
between the DPs in our F MSP allow to easily developing
valid compound DPs in the SP. Because DPs are proven
solutions, then our F MSP will generate proven SPs as
well. We evaluate our F MSP through a practical case
study. The results show that the advantage of our F MSP
compared with the traditional service contracts is, it
permits to automatically generates valid, customized,
fully functional and based-DP SPs in a short time.
Index TermsService oriented architecture, service
provider, software product line, feature model, design
pattern.
I. Introduction
The Service Oriented Architecture (SOA) is an archi-
tectural model that represents a widely used distributed
computing platform [1]. It uses services as the essential
means through which Service Providers (SPs) and Service
Consumers (SCs) can communicate. In this paper, we
focus on the development of SPs. A SP can be developed
with dierent features. We suppose that features can be
any types of functionalities like services, capabilities, com-
munication technologies (e.g., SOAP, REST and MOM
Middleware oriented Messaging), functional and non
functional requirements, and Design Patterns (DPs).
The SOAP and REST rely on a synchronous communi-
cation for message exchanging. A synchronous communi-
cation can inhibit performance and compromise reliability
as next. It needs that SP and SC must be available during
the message exchanging. It imposes processing overhead
because the SP and SC must wait and continue to consume
resources (e.g., memory) until they nish the message
exchanging. To overcome these problems the MOM is
proposed. The MOM introduces asynchronous, loosely-
coupled, reliable, scalable, and secure communication be-
tween the SC and the SP.
A DP is an appropriate and proven design solution for a
specic problem in a certain context. Dierent SOA DPs
have been presented in the book of Erl [2]. In the practice,
it is frequent to use a compound DP to solve specic
problems. A compound DP is a coarse-grained DP, who
is composed of a set of ner-grained DPs [2].
A widely used approach to develop a SP, called
contract-rst [1], consists of designing service contracts
that include the features of the required SP. Afterwards,
these service contracts will be used to generate the source
code of the corresponding SP. The service contracts [2] are
documents including meta information which often used to
describe the features of the SP. The two most used SOA
traditional service contracts in SOA are: WSDL for SOAP
and WADL for REST.
Erl considers the contract-rst approach as a best
practice and classies the service contract as one of the
fundamental design principles in SOA [1]. By studying
the traditional service contracts WSDL and WADL, we
identify that they suer from several problems, as fol-
lows. First, the traditional service contracts are
dependent of specic communication technologies.
For example, the WSDL only expresses the features of
SOAP and WADL only denes the features of REST.
The problem is that SP developers require to use dierent
syntaxes even to describe the same features (e.g., input
and output data information). This can lead to misin-
terpretation and diculty to understand these contracts.
Second, some communication technologies (e.g.,
MOM) do not oer service contracts. In this case,
using the rst-contract approach to develop SPs cannot be
possible. Third, developing many separated service
contracts can be needed to identify the dierent
features oered by the SP. This decreases the gover-
nance of the SP and makes it dicult for SP developers to
identify these features. Fourth, they allow expressing a
limited set of features. For example, they do not express
the SOA DPs and compound DPs [2]. This prevents to

978-1-5090-3407-9/16/$31.00 2016 IEEE 705

develop proven and complex SPs.
In order to overcome these problems, we propose, in this
paper, designing a Feature Model (FM), named F MSP ,
as a service contract for SP. The FM [3] is the defacto
standard for modeling the variability in Software Product
Line (SPL) [4]. The latter is a paradigm allowing the mass
customization of applications. The variability consists of
the ability of an artifact to be customized or congured
in a particular context. In the literature, several FMs [5],
[6], [7], [8], [9] have been proposed to model the features
of SP. However, the problem is that these FMs are not
complete in a way that they do not permit to generate
fully functional SPs and most of them do not consider
DPs.
The rest of this paper is structured as follows. In section
II, we provide a brief overview of the FM. In section III,
we introduce our F MSP . In section IV, we evaluate our
F MSP through a practical case study. In section V, we
discuss some related works. This paper is concluded in
section VI.
II. A brief overview of the feature model
The Software Product Line (SPL) [4] is a paradigm
proposing advanced techniques for the mass customization
of applications using as an essential means the concept of
variability modeling. The Feature Model (FM) [3] is the
defact standard for modeling variability in SPL. It permits
to model the customized applications, based on features,
that the SPL oers to generate. We present in Fig. 1,
a FM that expresses the legal combination of features
to derive customized SPs. An end user can derive from
this FM, an Application Model (AM), by selecting the
required features and deselecting the others, in line with
the constraints of the FM. In Fig. 1, we present an AM
that expresses the features of a given customized SP which
is derived from the FM illustrated in Fig. 1. Based on the
features of this AM, the SPL will generate the artifacts of
the corresponding SP.
The structure of an FM is a rooted tree of features
that can be dened through dierent notations [3] (see
Fig. 1). Many FM approaches [10], [3] have been proposed
in the literature that oer dierent notations. In this
work, we use the FM approach of Czarnecki et al. [3]
because its notations allow to express all the features of
the SP. We present in Fig. 1, these notations which will be
briey presented in the following. Features can be either
mandatory or optional. The feature attribute allows to add
an attribute value (e.g., integer) to specify extra-functional
information for features. The feature [min, max] denes a
lower and an upper bounds of instances of a given feature
that can be expressed in an AM. 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 feature A excludes
a feature B, then both features cannot be selected in the
same AM. Two widely used types of feature group can
706
be identied: the feature group XOR [1, 1] and the feature
group OR [1, n]. A feature group XOR [1, 1] allows selecting
exactly one out of its child features which can be called
as alternative exclusive features. A 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 dene complex constraints between features (see the
propositional constraints in Fig. 1).
III. Feature model for the service provider
F MSP
A. Advantages of F MSP
We have demonstrated in the introduction that the
traditional service contracts (WSDL and WADL) suer
from several problems, like they support a limited features
of SP and do not support SOA Design Patterns (DPs)
[2] and compound DPs . In order to overcome these
problems, we propose in Fig. 1, a FM, named F MSP , that
models the features of the SP and allows generating valid,
customized and fully functional SP. our F MSP can be
considered a service contract for SP that is generic, inde-
pendent of the communication technologies, DP-based and
provide mechanisms to express SP features and complex
constraints (i.e., propositional constraints). our F MSP
expresses the variability of 38 features of the SP. Some
of them are mandatory (e.g., information about services
and capabilities) and some other are optional (e.g., service
state). We present in Table I, the descriptions of these
features.
We express in F MSP eight SOA Design Patterns (DPs)
[2], which are: Event driven messaging DP, Asynchronous
queue DP, State messaging DP, Direct authentication DP,
Atomic service transaction DP, Reliable messaging DP,
State repository DP and Stateful service DP. A DP is
an appropriate and proven design solution for a specic
problem in a certain context. It is frequent to use a
compound DP to solve specic problems. A compound DP
is a coarse-grained DP, who is composed of a set of ner-
grained DPs. The advantage of integrating DPs in F MSP
is that the SPs that can be derived will be based on proven
solutions.
Mathematically, 28 (256) compound DPs can exist be-
tween these eight SOA DPs. However, not all of these
compound DPs are valid. For example, in the context
of the MOM communication technology, using the Event
driven messaging DP [2] requires the use of the Asyn-
chronous queue DP [2]. In this case, if a given compound
DP includes the Event driven messaging DP but omit
the Asynchronous queue DP, then this compound DP is
invalid. The challenge is to nd and model the valid com-
pound DPs in our F MSP . In this context, it is necessary
to nd and model the constraints between DPs in F MSP .
Erl presents several constraints between these DPs [2].
However, he illustrates them in many dispersed diagrams
which make dicult to interpret the existing constraints.
 Service contract
Address
Service name
[0,n] [0,n] Communication
Output Input technology
OName IName
REST SOAP
OType IType
OData class IData class Get Put
name name 1.1 1.2 Reliable
Post Delete
messaging DP
Persistent delivery Acknowledgement
Propositional constraints:
(MOM Output) (Atomic service transaction DP Acknowledgement)
Fig. 1: Feature model F MSP (readers of the electronic version can zoom in)
This makes dicult to know the existing valid compound
DPs.
Our F MSP permits to model the constraints between
these eight DPs and their possible compositions, accord-
ingly (see Fig. 1). This allows to facilitate nding and
developing these SOA DPs and their compositions. It
also permits to separate the development of compound
DPs from that of the business logic of the SP. In other
words, it helps the SP developer to focus on developing
the business logic of his/her SP. The compound DPs
that he/she wants to use will be automatically generated
from the F MSP . Furthermore, our F MSP can be used
as a documentation to learn the existing dependencies
and constraints between the DPs and compound DPs. In
order to concretely generate a SP, the SP developer only
needs to derive an AMSP (e.g., see Fig. 3) from F MSP
(see Fig. 1) that includes the required SP features (e.g.,
the required compound DP). The constraints presented in
F MSP ensure that all its possible AMSP are valid.
B. Design patterns constraints in F MSP
We discuss here the constraints between the eight DPs
expressed in F MSP .
The feature Output in F MSP represents the two way
communication between the SP and SC. If this feature
is omitted when deriving an AMSP , then then the result
type of the capability is void and the communication type
is considered as in way, i.e., from the SC to SP. Otherwise,
the communication type is two way.
The features Atomic service transaction DP, Reliable
messaging DP, State messaging DP and Event driven
messaging DP require the selection of the feature Output.
Thus, we dene requires constraints from them to the
feature Output. The reason is that these features can be
707
[1,n]
Service
[1,n]
Capability
Capability Direct authentication DP Service state
name
MOM State Stateful
messaging DP service DP
Atomic service Asynchronous Event driven
transaction DP queue DP messaging DP
State Temporary
repository DP memory
Durable
only applied for the outgoing messages from the SP to the
SC [2].
It is important to dene the features Acknowledgement
and Atomic service transaction DP as mutually exclu-
sive [2], [11]. We also dene the following propositional
constraint which it is required by MOM [11]: (MOM
Output) (Atomic service transaction DP Acknowl-
edgement).
By using the FAMILIAR tool [12], we identify, from the
constraints between the eight DPs presented in F MSP ,
that there are 108 valid compound DPs from 28 (256)
possible ones.
IV. Evaluation
In this section, we explore the use of our F MSP (see
Fig. 1) for developing valid, customized and fully func-
tional SP. In this context, we consider the case study
of Emergency Response and Crisis Management Systems
(ERCMS) [6] which is illustrated in Fig. 2. The ERCMS
is a structured group of participants who communicating
through services to achieve a common mission (e.g. save
human lives and ght against huge res). Many partici-
pants are involved: a supervisor, managers, coordinators
and investigators. All of these participants are SPs which
can oer dierent features (see Table I).
The supervisor monitors the works of managers. Each
manager sends automatically and periodically its work
report to the supervisor. It also broadcasts the places of
incidence to the coordinators. In this regard, a manager
should implement a MOM and congure it to support
the Event-driven messaging DP in the oered capabilities
for broadcasting. Also, it should make sure to store the
messages in a database for the coordinators if the latter
disconnect. We need also to implement a the Atomic
service transaction DP between these participants. An
TABLE I: Descriptions of the features of F MSP (see authentication process is also required for the coordinators
Fig. 1) to communicate with the managers. The objective of the
Feature name Description
coordinator consists in taking tasks and orders from the
managers and diusing them to its investigators. Each
Service contract Root feature
Address Address of the SP coordinator should implement a MOM which is congured
Service [1, n] Services of the SP as an asynchronous queue feature to send tasks to the ap-
Service name Service name propriate investigators. Also, it is necessary that each task
Capability [1, n] Capabilities of the SP
Capability name Capability name should be acknowledged (i.e., via ACK messages) by the
Input [0, n] Input data of a given capability manager as soon as the investigator gets it. Furthermore,
IName Input name of a given capability we must ensure that all the messages sent from the coor-
IType Input type of a given capability
IData class name Input data class name of a given capability dinators to the investigators (and vice-versa) are persisted
(e.g., Java class) to a database so they are not lost if these participants fail.
Output [0, n] Output data of a given capability Some capabilities of the managers require authentication
OName Output name of a given capability
OType Output type of a given capability and some others do not. The investigators must be SPs
OData class name Output data class name of a given capability to keep the coordinators updated about their situations.
Communication Communication technologies of capabilities Therefore, they implement capabilities using SOAP and
technology
REST REST communication technology REST which can be invoked without authentication.
Get HTTP get method for REST As illustrated in the introduction, the traditional ser-
Post HTTP post method for REST vice contracts (WSDL and WADL) suer from several
Put HTTP put method for REST
Delete HTTP delete method for REST problems in order to develop SPs, such as: they support
SOAP SOAP communication technology a limited features of SP and do not consider SOA DPs
1.1 SOAP version 1.1 [2] and compound DPs. Thus, these traditional service
1.2 SOAP version 1.2
MOM Middleware oriented messaging communica- contracts cannot implement the variability of the SPs of
tion technology the participants of the case study ERCMS (see Fig. 2). In
Event driven mes- Automatically sending the response messages order to overcome these problems, we propose deriving for
saging DP of the SP, when ready, to the corresponding
subscribers (i.e., SCs) in an asynchronous each SP an AMSP from our F MSP (see Fig. 1). We note
communication that our F MSP permits to implement all the variability
Durable It allows the publisher (i.e., the SP) to store of the case study ERCMS.
messages for the subscriber (i.e., SC) if the
latter disconnects. Upon reconnecting, the We present in Fig. 3 an example of a derived AMSP
subscriber will receive all these messages from our F MSP . This AMSP contains 30 SP features. The
from the SP address of this SP is http://localhost:8080/SP. This SP
Asynchronous Deploying an intermediary MOM allowing
queue DP SPs and SCs to asynchronously communicate includes a single service, named User, which is composed
and to independently process messages by of a single capability, named login. The signature of this
remaining temporally decoupled capability has a single input data, named id, with a
State messaging Delegating the storage of state data to the
DP outgoing messages of SP instead to its inter- String type and included in the class Session (e.g., Java
nal memory. class). It also has a single output data, named ok, with a
Direct authentica- Requiring that SCs provide authentication Boolean type and included in the class Session. The goal
tion DP credentials (username and password) to in-
voke capabilities. of this capability is to enable a user to login to his/her
Atomic service Treating a group of exchanging messages be- account.
transaction DP tween the SP and SC as a single work unit. This capability implements a compound DP that is
The latter is wrapped in a transaction with
a rollback feature that resets all actions and composed of the eight DPs discussed in Table I (e.g., Event
changes if exchanging messages fail driven messaging DP). In fact, the constraints presented
Reliable messaging Adding a reliability mechanism between the in F MSP only allows to derive valid compound DPs from
DP SP and SC to ensure message delivery. In this
context, we rely on acknowledging messages these eight DPs (see Fig 1). For example, if the feature
and on persisting messages in a data store State repository DP is selected, then the feature Stateful
Persistent delivery Persists the received messages so they are service DP must be selected because the former feature is
not lost if the MOM fails. Therefore, we
ensure that the messages are delivered to the the child of the latter feature.
receiver (i.e., SC). We developed a tool [13], [14], that allows to generate
Acknowledgement Acknowledges the senders SP about the re- the source code of the corresponding SPs of a given
ceived messages
State repository Deferring storing state data from a tempo- AMSP derived from F MSP (see Fig. 1). Our tool is based
DP rary memory to a state repository essentially on Java EE technologies and the FAMILIAR
Temporary Storing and managing the state data in a [12] tool. We propose that the generated SP is based on
memory temporary memory
Service state It gathers techniques that handle the state the Enterprise Service Bus (ESB) Switchyard 2 [15].
data of capabilities in the SP From the AMSP which is illustrated in Fig. 3, our
Stateful service DP Managing and storing state data by inten- tool succeed to automatically generate a valid and fully
tionally stateful utility services
functional SP that is composed of approximately 400 Java

708
 Supervisor

Managers

Plane Walker
coordinator Robot Fireman coordinator
coordinator coordinator

Plane Robot Fireman Walker

investigators investigators investigators investigators

Fig. 2: Case study of emergency response and crisis management systems

Service contract

Address Service

Service name Capability

Communication Capability Direct authentication DP Service state

Input Output
technology name

IName OName
IType OType REST SOAP MOM State Stateful
messaging DP service DP
IData class OData class
name name
Get Atomic service
1.2 Reliable Asynchronous Event driven
messaging DP transaction DP queue DP messaging DP
State repository
DP
Persistent delivery

Feature attribute values:

Address = "http://localhost:8080/SP"
Service name = "User"
Capability name = "login"
IName = "id"
Itype = "String"
IData class name = "Session"
OName = "ok"
Otype = "Boolean"
OData class name = "Session"

Fig. 3: Application model AMSP (readers of the electronic version can zoom in)

line code and ve XMLs. The latter permit to congure expert engineer can require approximately 30 minutes to
SOAP and MOM technologies and to congure the ESB develop this SP and needs many manual interventions.
Switchyard 2. The time required to generate this SP is In order to validate the correctness of our F MSP ,
several seconds. Using the traditional service contracts, an including the correctness of the possible 108 compound

709
DPS, we generate all the possible SPs from all the possible
AMs of F MSP . The results show that the generated SPs
are completely valid and no errors have appeared.
V. Related work
Wada et al. [8] propose a model-driven development
framework to model several constraints and dependencies
between non-functional aspects of the SP. In this context,
the authors elaborate an FM that expresses the variability
of these aspects. Their FM can be used to extend our
F MSP (see Fig. 1) in order to express more the variability
of non-functional aspects of SP. In contrast, our F MSP
permits to generate fully functional SPs and consider DPs
and compound DPs.
Ed-douibi et al. [9] propose a based-MDE approach,
called EMF-REST, that takes EMF data models as input
to generate their corresponding REST services. In our
work, we propose F MSP to model the features of REST.
Their approach supports generating more REST features
(e.g., security features) than ours. In contrast, our F MSP
permits to generate services with dierent communication
technologies (SOAP, REST and MOM) and consider SOA
DPs and compound DPs.
The approach proposed by Kajsa and Nvrat [16] uses
SPL techniques to handle variability in DPs. The goal is
to support the instantiation and the evolution which occur
to the DPs. This work helps to generate the source code
of a specic DP in the desired location in the code via
annotations and FMs. The advantage of our F MSP is that
it allows to generate the source code of DPs and also of
compound DPs.
Street Fant et al. [17] introduce a pattern-based model-
ing approach for SPL engineering using extended UML
models. The authors elaborate a FM that gathers the
components of a set of variable distributed real-time and
embedded architectural DPs. They elaborate a collabora-
tion diagram, a interaction diagram, a component diagram
and a state machine diagram for each DP to identify its
variability and to specify its behavior. Then, they create a
mapping between their FM and these diagrams. Therefore,
it would be possible to generate specic UML diagrams for
each application. In our work, we focus on generating valid
code of the SP DPs rather than generating their designs.
VI. Conclusion
The service contract is one of the fundamental design
principles in the Service Oriented Architecture (SOA) to
develop a Service Provider (SP). We have identied that
traditional service contracts (WSDL and WADL) suer
from several problems like, they work only for specic
communication technologies (SOAP and REST). In order
to solve such problems, we have introduced, in this paper,
a Feature Model (FM), named F MSP , that can be consid-
ered as a generic service contract that permits to generate
valid, customized and fully functional SPs. An important
advantage of our F MSP is that it integrates eight SOA
710
DPs and their existing constraints. This allows to easily
generate the possible valid compound DPs between these
DPs. From our F MSP , we have identied that there are
108 valid compound DPs from 28 (256) possible ones.
We have demonstrated through a practical case study
and based on a developed tool, that our F MSP only
generates valid, customized and fully functional SPs in
several seconds.
For future research, we plan to extend our F MSP by
other features, including other DPs, in order to generate
more complete and complex SPs.
References
[1] T. Erl, SOA Principles of Service Design. Prentice Hall, 2007.
[2] , SOA Design Patterns. Prentice Hall, 2009.
[3] K. Czarnecki, S. Helsen, and E. Ulrich, Staged conguration
through specialization and multilevel conguration of feature
models, Software Process: Improvement and Practice, vol. 10,
no. 2, pp. 143169, 2005.
[4] K. Pohl, G. Bckle, and F. Van Der Linden, Software Product
Line Engineering. Springer, 2005.
[5] C. Parra and D. Joya, SPLIT: an automated approach for en-
terprise product line adoption through SOA, Internet Services
and Information Security, vol. 5, no. 1, 2015.
[6] A. Kamoun, M. Hadj Kacem, and A. Hadj Kacem, Feature
model for modeling compound SOA design patterns, in Pro-
ceedings of the 11th ACS/IEEE International Conference on
Computer Systems and Applications (AICCSA2014), Doha,
Qatar, Nov. 2014, pp. 381388.
[7] M. Fantinato, D. M. B. Felgar, and D. I. Maria, WS-contract
establishment with QOS: an approach based on feature mod-
eling, Cooperative Information Systems, vol. 17, no. 03, pp.
373407, 2008.
[8] H. Wada, J. Suzuki, and K. Oba, A feature modeling support
for non-functional constraints in service oriented architecture,
in Proceedings of the 4th IEEE International Conference on
Services Computing (SCC2007), Salt Lake City, Utah, USA,
Jul. 2007, pp. 187195.
[9] H. Ed-douibi, J. L. C. Izquierdo, A. Gmez, M. Tisi, and
J. Cabot, EMF-REST: generation of RESTful APIs from mod-
els, in Proceedings of the 31st Annual ACM Symposium on
Applied Computing (SAC2016), Pisa, Italy, 2016, pp. 1446
1453.
[10] K. C. Kang and H. Lee, Systems and Software Variability
Management: Concepts, Tools and Experiences. Springer,
2013, ch. 2: Variability Modeling, pp. 2542.
[11] P. Giacomelli, HornetQ Messaging Developers Guide. Packt
Publishing, 2012.
[12] M. Acher, P. Collet, P. Lahire, and R. B. France, FAMILIAR: a
domain-specic language for large scale management of feature
models, Science of Computer Programming, vol. 78, no. 6, pp.
657681, 2013.
[13] MSPL4SOA tool, https://mspl4soa.github.io.
[14] A. Kamoun, M. Hadj Kacem, and A. Hadj Kacem, Multi-
ple software product lines for software oriented architecture,
in Proceedings of the 25th IEEE International Conference on
Enabling Technologies: Infrastructure for Collaborative Enter-
prises (WETICE2016), Paris, France, Jun. 2016, pp. 5661.
[15] Switchyard tool, http://switchyard.jboss.org.
[16] P. Kajsa and P. Nvrat, Design pattern support based on the
source code annotations and feature models, in Proceedings of
the 38th International Conference on Current Trends in The-
ory and Practice of Computer Science on SOFtware SEMinar
(SOFSEM2012), pindlerv Mln, Czech Republic, Jan. 2012,
pp. 467478.
[17] H. Gomaa, J. Street Fant, and R. G Pettit IV, A pattern-
based modeling approach for software product line engineering,
in Proceedings of the 46th Hawaii International Conference on
System Sciences (HICSS2013), Maui, Hawaii, USA, Jan 2013,
pp. 49854994.