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
SP
, 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
SP
.
Mathematically, there exist 2
15
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
SP
. In this context, it is
crucial to identify and model the constraints between
DPs in FM
SP
(see Sect. 3.2). Erl presents several
constraints between these DPs (Erl, 2009). However,
he illustrates them in many dispersed diagrams. This
makes difficult to identify properly these constraints.
Also, many constraints are missing.
3.1 Benefits
Our FM
SP
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 benefits of our FM
SP
and which
problems they consider:
1. it relies on the FM notations which permit to
efficiently 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
SP
(e.g., see Fig. 3), by selecting the required fea-
tures and deselecting the others, from FM
SP
(see
Fig. 1). This facilitates the mass-customization of
SPs. The constraints presented in FM
SP
allow to
guide the SP developer to derive valid AM
SP
(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 reflects
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
FM
SP
, that there are 406 valid compound DPs
from 2
15
possible ones (considering Problem P.4);
5. many benefits can be enumerated when express-
ing DPs as features in our FM
SP
. 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 benefit 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 efficient and easier than to explain
it in details. Hence, integrating DPs in our FM
SP
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
SP
(see Fig. 1). These constraints
have been identified 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
FM
SP
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
SP
models the
MOM features, then it can be considered as a service
contract for MOM. Hence, it would be possible to use
the first-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