an architecture description language for dynamic service...

DOI reference number: 10.18293/SEKE2015-217

An Architecture Description Language for Dynamic

Service-Oriented Product Lines

Seza Adjoyan

UMR CNRS 5506 / LIRMM

University of Montpellier

Montpellier, FRANCE

[email protected]

Abdelhak Seriai

UMR CNRS 5506 / LIRMM

University of Montpellier

Montpellier, FRANCE

[email protected]

Abstract- Reconciling Software Product Lines (SPL) and

Service Oriented Architecture (SOA) allows modeling and

implementing systems that systematically adapt their behavior in

respond to surrounding context changes. Both approaches are

complementary with regard to the variability and the dynamicity

properties. Architecture Description Language (ADL), on the

other hand, is recognized as an important element in the

description and analysis of software properties. Different ADLs

have been proposed in SOA or in SPL domains. Nevertheless,

none of these ADLs allows describing variability and dynamicity

features together in the context of service-oriented dynamic

product lines. In this sense, our work attempts to describe the

changing architecture of Dynamic Service-Oriented Product

Lines (DSOPL). We propose an ADL that allows describing three

types of information: architecture's structural elements,

variability elements and system’s configuration. Furthermore, we

introduce context elements on which service reconfiguration is

based.

Keywords—Architecture Description Language (ADL); Service-

Oriented Architecture (SOA); Software Product Lines (SPL);

dynamicity; variability; software architecture; Dynamic Service-

Oriented Product Lines (DSOPL)

I. INTRODUCTION

Software Product Lines (SPL) and Service Oriented Architecture (SOA) have a common goal from a software development point of view; increase the reusability of existing assets rather than rebuilding new systems from scratch. SPL, on the one hand, allows the development of a family of products that share some common set of core assets [1], [2], [3]. Variability has always been a first concern in SPL studies [16]. According to [4], variability is the ability of a software artifact to quickly change and adapt for a specific context in a preplanned manner. SOA, on the other hand, is a special kind of software architecture, where the main architectural elements are coarse grained and loosely coupled services that are dynamically composable and inter-operable [5]. Being able to modify the architecture of a running system at such a high level of abstraction renders the system highly extensible, customizable and powerful [6].

Variability and dynamicity are core properties to develop complex adaptable software systems such as telecommunication, pervasive, crisis management, surveillance and security systems. In such systems, due to environment changes, a dynamic re-configuration should be carried out without having to re-deploy the whole system.

Combining SOA and SPL constitutes the answer to this need [7]. SOA offers, through its encapsulation property and its explicit interfaces, a solution for achieving dynamic product lines. SPL offers, via variability modeling, analysis and design of changing points in service-oriented architectures.

Architecture Description Language (ADL) is a formalism that allows the specification of system’s conceptual architecture [8]. It enables architects to describe and validate systems against stakeholders’ requirements from one side, and ease the development and implementation process of complex systems, from another side. It often has a graphical representation or plain text syntax. Conventional ADLs support only static architecture description [6]. Some ADLs provide special formalism for SOA to describe service dynamicity or for SPL to describe variability. Unfortunately no ADL supports the crosscutting SOA and SPL concepts.

To overcome this limitation, we propose an XML-based ADL that allows describing the architecture of a Dynamic Service-Oriented Product Line (DSOPL). It describes the four following elements: (i) the structural elements of a family of software products (i.e. services and connections), (ii) an architectural variability model (i.e. variability points and alternatives), (iii) context information, in addition to (iv) an architectural configuration model (i.e. reconfiguration rules based on context and variability). We choose to use XML as a description language to facilitate understandability and analysis of the described architecture. In addition, XML-based description facilitates tool-support design and interoperability.

The remainder of this paper is organized as follows: In section 2, we discuss related works regarding variability and dynamicity properties. In section 3, we characterize our proposed DSOPL-ADL’s elements and demonstrate their utility through a running example. Finally, in section 4, we summarize our contribution and provide directions for future research.

II. RELATED WORK

A. ADLs specifying dynamic properties

A software architecture can be classified in terms of its capability of evolution into two categories: static or dynamic. A static architecture reflects the static structure of software and is completely specified at design time [6], whereas in dynamic architecture, system may evolve after its compilation [1]. In this type of architecture, in addition to specifying the

system in terms of components, connectors and configurations, it should also specify how these components and connectors are evolution of architecture at runtime may happen under several formsarchitecture (modifying connectioncomposing elements (substitution of composing elements).

dynamic software architecture.literature, only few of them support dynamic reconfigurationsuch as ACME/Plastikde{condition} do {operations}different choices at runtime. component at runtimeused componentsdynamic since third party services can be discovered and bound to service broker at

B

conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration duringagreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking of changed elements

representing an architecture that encompasses variability xADL architectural elements of software systemsset ofconcepts in the form of three schemas: variantsconcepts within xADL; this approach suffers from limitation between elements of different variation points.defines component. any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.

lines architecture are not based on the serAin terms of services whether in a dynamic or static ADLNevertheless

system in terms of components, connectors and configurations, it should also specify how these components and connectors are evolution of architecture at runtime may happen under several formsarchitecture (modifying connectioncomposing elements (substitution of composing elements).

ADLs are used dynamic software architecture.literature, only few of them support dynamic reconfigurationsuch as ACME/Plastikdescribe a specific {condition} do {operations}different choices at runtime. component at runtimeused componentsdynamic since third party services can be discovered and bound to service broker at

B. ADLs

Dynamic Software Product Line conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration duringagreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking of changed elements

Frepresenting an architecture that encompasses variability xADL architectural elements of software systemsset ofconcepts in the form of three schemas: variantsconcepts within xADL; this approach suffers from limitation between elements of different variation points.defines component. any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.

Otherwise, approaches that describe variability in product lines architecture are not based on the serApproaches in terms of services whether in a dynamic or static ADLNevertheless

system in terms of components, connectors and configurations, it should also specify how these components and connectors are evolution of architecture at runtime may happen under several forms: adding/ removing composing elements, reconfigurarchitecture (modifying connectioncomposing elements (substitution of composing elements).

ADLs are used dynamic software architecture.literature, only few of them support dynamic reconfigurationsuch as ACME/Plastik

scribe a specific {condition} do {operations}different choices at runtime. component at runtimeused in componentsdynamic since third party services can be discovered and bound to service broker at

ADLs

Dynamic Software Product Line conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration during agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking of changed elements

Few existing approaches were corepresenting an architecture that encompasses variability xADL [architectural elements of software systemsset of concepts in the form of three schemas: variantsconcepts within xADL; this approach suffers from limitation between elements of different variation points.defines component. any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.

Otherwise, approaches that describe variability in product lines architecture are not based on the ser

pproaches in terms of services whether in a dynamic or static ADLNevertheless

system in terms of components, connectors and configurations, it should also specify how these components and connectors are evolution of architecture at runtime may happen under several

: adding/ removing composing elements, reconfigurarchitecture (modifying connectioncomposing elements (substitution of composing elements).

ADLs are used dynamic software architecture.literature, only few of them support dynamic reconfigurationsuch as C2ACME/Plastik

scribe a specific {condition} do {operations}different choices at runtime. component at runtime

in operationscomponentsdynamic since third party services can be discovered and bound to service broker at

ADLs spec

Dynamic Software Product Line conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration

runtime agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking of changed elements

ew existing approaches were corepresenting an architecture that encompasses variability

[17]architectural elements of software systems

XML schemasconcepts in the form of three schemas: variants schemas.concepts within xADL; this approach suffers from limitation between elements of different variation points.defines “switchescomponent. any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.


pproaches in terms of services whether in a dynamic or static ADLNevertheless



ADLs are used dynamic software architecture.literature, only few of them support dynamic reconfiguration

C2 [ACME/Plastik


operationscomponents. In dynamic since third party services can be discovered and bound to service broker at

pec




] is an ADL for modeling runtime and designarchitectural elements of software systems

XML schemasconcepts in the form of three schemas:

schemas.concepts within xADL; this approach suffers from

of expressingbetween elements of different variation points.

switchescomponent. The main limitation in Koala is its static nature; any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.


pproaches such in terms of services whether in a dynamic or static ADLNevertheless, these ADLs




[9], DarwinACME/Plastik [13


operationsIn π

dynamic since third party services can be discovered and bound to service broker at

pecifying




is an ADL for modeling runtime and designarchitectural elements of software systems


schemas.concepts within xADL; this approach suffers from


switchesThe main limitation in Koala is its static nature;

any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable for dynamic architectures.


such in terms of services whether in a dynamic or static ADL

these ADLs

system in terms of components, connectors and configurations, it should also specify how these components and connectors are evolvevolution of architecture at runtime may happen under several



, Darwin13]

scribe a specific configuration{condition} do {operations}different choices at runtime. component at runtime

operations π-ADL


fying variability


runtime [15agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking of changed elements




schemas. Concerning the integration of product lines concepts within xADL; this approach suffers from


switches” in order to dynamically bind the selected The main limitation in Koala is its static nature;



such as in terms of services whether in a dynamic or static ADL

these ADLs

system in terms of components, connectors and configurations, it should also specify how these components

evolvevolution of architecture at runtime may happen under several


ADLs are used to describe the propedynamic software architecture.literature, only few of them support dynamic reconfiguration

, Darwin and Dynamic Wrightconfiguration

{condition} do {operations}different choices at runtime. component at runtime, detach

part ADL


variability


15]. agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking

[22]



XML schemas. xADL 2.0 integrates product lines concepts in the form of three schemas:

Concerning the integration of product lines concepts within xADL; this approach suffers from


in order to dynamically bind the selected The main limitation in Koala is its static nature;



as [19in terms of services whether in a dynamic or static ADL

these ADLs


evolved or reconfigured at runtime.evolution of architecture at runtime may happen under several


to describe the propedynamic software architecture.literature, only few of them support dynamic reconfiguration

, Darwin and Dynamic Wright

configuration{condition} do {operations}different choices at runtime.

detachpart

ADL [11dynamic since third party services can be discovered and bound to service broker at runtime

variability


Even though there is no concrete agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common acmanaging the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking

[22].



. xADL 2.0 integrates product lines concepts in the form of three schemas:


of expressing constraints (i.e. between elements of different variation points.




19], [in terms of services whether in a dynamic or static ADL

these ADLs are not able to describe variants.


ed or reconfigured at runtime.evolution of architecture at runtime may happen under several


to describe the propedynamic software architecture.literature, only few of them support dynamic reconfiguration

[10and Dynamic Wright

configuration{condition} do {operations}” different choices at runtime.

detach part to respectively unlink and lin

11], dynamic since third party services can be discovered and

runtime

variability







constraints (i.e. between elements of different variation points.


any deployed configuration cannot be changed at runtimwill require application recompilation, thus it is not suitable


], [20]in terms of services whether in a dynamic or static ADL

are not able to describe variants.




to describe the propedynamic software architecture. Amongliterature, only few of them support dynamic reconfiguration

10], πand Dynamic Wright

configuration ” is used

different choices at runtime. To replace and

to respectively unlink and lin the architecture

dynamic since third party services can be discovered and runtime

properties











] describe system’s architecture in terms of services whether in a dynamic or static ADL




: adding/ removing composing elements, reconfigurarchitecture (modifying connections), composing elements (substitution of composing elements).

to describe the propeAmong

literature, only few of them support dynamic reconfiguration, π-ADL

and Dynamic Wright in [

is used To replace

and attachmentsto respectively unlink and lin

the architecturedynamic since third party services can be discovered and

.

properties











describe system’s architecture in terms of services whether in a dynamic or static ADL




: adding/ removing composing elements, reconfigur), or

composing elements (substitution of composing elements).

to describe the propeAmong existing ADLs in the

literature, only few of them support dynamic reconfigurationADL

and Dynamic Wright[13]

is used To replace

attachmentsto respectively unlink and lin


properties





. xADL 2.0 integrates product lines concepts in the form of three schemas: versions










: adding/ removing composing elements, reconfiguror upgrading existing


to describe the propeexisting ADLs in the

literature, only few of them support dynamic reconfigurationADL [11

and Dynamic Wright ], the expression “

is used to toggle between To replace

attachmentsto respectively unlink and lin


properties


Even though there is no concrete agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which provides the following common activities at runtime: managing the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking


is an ADL for modeling runtime and designarchitectural elements of software systems.

. xADL 2.0 integrates product lines versions


constraints (i.e. requires, excludes) between elements of different variation points.



Otherwise, approaches that describe variability in product lines architecture are not based on the service





: adding/ removing composing elements, reconfigurupgrading existing


to describe the properties of static or existing ADLs in the

literature, only few of them support dynamic reconfiguration11], Rapide [14

, the expression “to toggle between

To replace an instance of attachments

to respectively unlink and linthe architecture

dynamic since third party services can be discovered and

Dynamic Software Product Line (DSPLconventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration

Even though there is no concrete agreement of what aspects a dynamic SPL should exactly treat, most approaches agree that the main characteristic of any dynamic SPL framework is the runtime variability, which

tivities at runtime: managing the dynamic selection of variants, autonomous activation/ deactivation of composing elements, substitution of composing elements and dependency and constraint checking

ew existing approaches were concerned about representing an architecture that encompasses variability

is an ADL for modeling runtime and design It is defined as a

. xADL 2.0 integrates product lines versions


requires, excludes) between elements of different variation points.



Otherwise, approaches that describe variability in product vice-







ties of static or existing ADLs in the

literature, only few of them support dynamic reconfiguration, Rapide

14]. I, the expression “to toggle between

an instance of statements are

to respectively unlink and linthe architecture is considered


DSPLconventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration



ncerned about representing an architecture that encompasses variability

is an ADL for modeling runtime and designis defined as a

. xADL 2.0 integrates product lines versions, options


requires, excludes) between elements of different variation points.



Otherwise, approaches that describe variability in product -oriented style.









In order to , the expression “to toggle between


to respectively unlink and linis considered


DSPL) conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration




is an ADL for modeling runtime and designis defined as a

. xADL 2.0 integrates product lines options


requires, excludes) Koala [



Otherwise, approaches that describe variability in product oriented style.




ed or reconfigured at runtime. evolution of architecture at runtime may happen under several





n order to , the expression “to toggle between




extends conventional SPL perspective by delaying the binding time of product’s composing elements (i.e. features) to runtime. It produces autonomous and reconfigurable products that are able to reconfigure themselves to select a valid configuration




is an ADL for modeling runtime and design-is defined as a

. xADL 2.0 integrates product lines options, and


requires, excludes) Koala [


any deployed configuration cannot be changed at runtime and will require application recompilation, thus it is not suitable





Thievolution of architecture at runtime may happen under several

: adding/ removing composing elements, reconfiguringupgrading existing



literature, only few of them support dynamic reconfiguration [12

n order to , the expression “on to toggle between







ncerned about representing an architecture that encompasses variability [16

-time is defined as a

. xADL 2.0 integrates product lines , and

Concerning the integration of product lines concepts within xADL; this approach suffers from the

requires, excludes) Koala [18


e and will require application recompilation, thus it is not suitable





This evolution of architecture at runtime may happen under several

ing upgrading existing


literature, only few of them support dynamic reconfiguration 12],

n order to on

to toggle between an instance of

statements are to respectively unlink and link

is considered dynamic since third party services can be discovered and




ncerned about 16]. time

is defined as a . xADL 2.0 integrates product lines

, and Concerning the integration of product lines

the requires, excludes)

18] in order to dynamically bind the selected

The main limitation in Koala is its static nature; e and

will require application recompilation, thus it is not suitable


describe system’s architecture in terms of services whether in a dynamic or static ADL.

A

exemplify concepts related to our proposed approachexample is aboutfour actorsserviceretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

B

Sarchitecture levelis structured F

1

2

3

4

III

A. I

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is aboutfour actorsserviceretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

B. The DSOPL

In order to describe the runtime variability of a Servicearchitecture levelis structured Fig.

1. Structural abstract structural entitiesinterfaces, operations)

2. Variability description: here, variationand also all alternative services of each variation pointwith the constraints related to each alternative

3. Context description: vdescriptions are based on information about context. information specific

4. Configuration cohow to configure (generate) on structural,

III.

Illustrative

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is aboutfour actorsservicesretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

The DSOPL

In order to describe the runtime variability of a ervice

architecture levelis structured

2:

Structural abstract structural entitiesinterfaces, operations)

Variability description: here, variationand also all alternative services of each variation pointwith the constraints related to each alternative

Context description: vdescriptions are based on information about context. information specific

Configuration concrete services how to configure (generate) on structural,

Figure

D

llustrative

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is aboutfour actors

s, as mretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

The DSOPL

In order to describe the runtime variability of a ervice-Oriented

architecture levelis structured



Context description: vdescriptions are based on information about context. information specific

Configuration ncrete services

how to configure (generate) on structural,

Figure

DYNAMIC

llustrative

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is aboutfour actors;

, as mretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

The DSOPL

In order to describe the runtime variability of a riented

architecture levelis structured in



Context description: vdescriptions are based on information about context. information specific section


how to configure (generate) on structural,

Figure 1. Illustrative example:

YNAMIC

llustrative example

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is about

customer, retailer, warehouse and shipment , as modeled in

retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

The DSOPL-ADL structure

In order to describe the runtime variability of a riented

architecture level, in four sections

Structural element descriptionabstract structural entitiesinterfaces, operations)


Context description: vdescriptions are based on information about context. information about

section


how to configure (generate) on structural, variability and context elements

Illustrative example:

YNAMIC S

xample

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approachexample is about a simplified online sales scenario between

customer, retailer, warehouse and shipment odeled in

retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

ADL structure

In order to describe the runtime variability of a riented P

, we propose anfour sections

element descriptionabstract structural entitiesinterfaces, operations)


Context description: vdescriptions are based on information about context.

about section of

Configuration descriptionncrete services

how to configure (generate) variability and context elements


Figure

SERVICE

xample

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approach

a simplified online sales scenario between customer, retailer, warehouse and shipment

odeled in retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

ADL structure

In order to describe the runtime variability of a Product

we propose anfour sections

element descriptionabstract structural entitiesinterfaces, operations)



about of the ADL.

descriptionncrete services and



Figure 2

ERVICE



odeled in retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

ADL structure

In order to describe the runtime variability of a roduct

we propose anfour sections

element descriptionabstract structural entitiesinterfaces, operations).



about context elements isthe ADL.

descriptionand connections are



2. Modular DSOPL

ERVICE O



odeled in Figretailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is preparthe delivery of items to the customer.

ADL structure

In order to describe the runtime variability of a roduct

we propose anfour sections, as

element descriptionabstract structural entities


Context description: variability and configuration descriptions are based on information about context.

context elements isthe ADL.

description: here, connections are



Modular DSOPL

ORIENTED



Fig. retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the order. Once the order is prepared, the shipping service handles the delivery of items to the customer.

ADL structure

In order to describe the runtime variability of a Line

we propose an XMLas summarized in the

element descriptionabstract structural entities


ariability and configuration descriptions are based on information about context.

context elements isthe ADL.

: here, connections are

how to configure (generate) concrete architecturevariability and context elements

Illustrative example: online sales scenario architecture

Modular DSOPL

RIENTED



. 1. retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the

ed, the shipping service handles the delivery of items to the customer.

In order to describe the runtime variability of a ine XMLsummarized in the

element description: defines of the system



context elements is

: here, connections are

concrete architecturevariability and context elements

nline sales scenario architecture

Modular DSOPL

RIENTED P



The customer accesses retailer’s website, browses the catalog, selects some items and commands an order. The retailer fulfills customer’s order request and inquires the warehouse to prepare all items of the

ed, the shipping service handles the delivery of items to the customer.

In order to describe the runtime variability of a (D

XML-based summarized in the

: defines of the system



context elements is

: here, the rules used to create connections are



Modular DSOPL-ADL

PRODUCT




ed, the shipping service handles

In order to describe the runtime variability of a DSOPLbased

summarized in the

: defines of the system

Variability description: here, variation points are defined and also all alternative services of each variation pointwith the constraints related to each alternative


context elements is

the rules used to create connections are specified



ADL

RODUCT





In order to describe the runtime variability of a SOPL)

based ADL.summarized in the

: defines all types of of the system

points are defined and also all alternative services of each variation pointwith the constraints related to each alternative


context elements is described

the rules used to create specified



RODUCT L





In order to describe the runtime variability of a )

ADL.summarized in the

all types of of the system

points are defined and also all alternative services of each variation pointwith the constraints related to each alternative.


described

the rules used to create specified

concrete architecturevariability and context elements.


LINE





In order to describe the runtime variability of a Dynamic system

ADL. This ADL summarized in the schema

all types of of the system (services,

points are defined and also all alternative services of each variation point


described

the rules used to create specified to

concrete architecture


INE ADL

We will use throughout the paper an illustrative example to exemplify concepts related to our proposed approach.




Dynamic system

This ADL schema

all types of (services,


ariability and configuration descriptions are based on information about context. Thus

described

the rules used to create to describe

concrete architectures based


ADL

We will use throughout the paper an illustrative example to . This




Dynamic system

This ADL schema of

all types of the (services,


ariability and configuration Thus

described in

the rules used to create describe

based

We will use throughout the paper an illustrative example to This




Dynamic at

This ADL of

the (services,


ariability and configuration Thus,

n a

the rules used to create describe

based

architectural concerndescription of architecture in four sections, each of them specifying one type of architectural description hasfollowing advantages:

of the

by sepa

and

of information among several abstraction levels. For example,

the variability described in feature model at requirement level

is translated at architec

C

interactsitself is ainto finerservicesconsidered implement any functionalitytodescribed as sub

require a number ofcollection of methods or operationsservicefuture exploiting systems, they should defined intoperations.or interface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ requiredAn interface

metaarchitectural has a name specified by

Our approach architectural concerndescription of architecture in four sections, each of them specifying one type of architectural description hasfollowing advantages:

1)

of the

2)

by sepa

and configuration).

3)




C. Structural

Ainteractsitself is ainto finerservicesconsidered implement any functionalityto one ofdescribed as sub

Each service require a number ofcollection of methods or operationsservicefuture exploiting systems, they should defined intoperations.or required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ requiredAn interface

The structural description of a semetaarchitectural has a name specified by


) It facilitates the modification and re

of the four

) It allows the description and anal

by sepa

configuration).

) It allows controlling the traceability links of each type




Structural

A serviceinteractsitself is ainto finerservicesconsidered implement any functionality

one ofdescribed as sub

Each service require a number ofcollection of methods or operationsservice. future exploiting systems, they should defined intoperations.

required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ requiredAn interface

The structural description of a semeta-model. architectural has a name specified by

Figure


t facilitates the modification and re

four

t allows the description and anal

by separating the four concerns (structure, variability, context

configuration).

t allows controlling the traceability links of each type




Structural

serviceinteracts with other services throughitself is a composite into finer-grained services. All other services in the hierarchical tree are considered implement any functionality

one of its composing services.described as sub

Each service require a number ofcollection of methods or operations

. Since services future exploiting systems, they should defined intoperations.

required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ requiredAn interface

The structural description of a semodel.

architectural has a name specified by

Figure



sections of ADL.


rating the four concerns (structure, variability, context

configuration).





Structural

service with other services throughcomposite grained

. All other services in the hierarchical tree are considered compositeimplement any functionality

its composing services.described as sub

Each service require a number ofcollection of methods or operations

Since services future exploiting systems, they should defined interfaces that describe theiroperations. Interfaces are two types, either

required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ requiredAn interface has

The structural description of a semodel. A service

architectural attributeshas a name specified by

Figure 3. Structural description meta



sections of ADL.



configuration).





Structural elements

is an encapsulated and selfwith other services throughcomposite grained

. All other services in the hierarchical tree are composite

implement any functionalityits composing services.

described as sub-architecture.

Each service hasrequire a number ofcollection of methods or operations

Since services future exploiting systems, they should

erfaces that describe theirInterfaces are two types, either

required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

has a

The structural description of a seA serviceattributes

has a name specified by

. Structural description meta

Our approach implicitly architectural concerndescription of architecture in four sections, each of them specifying one type of architectural description hasfollowing advantages:


sections of ADL.



configuration).





elements

is an encapsulated and selfwith other services throughcomposite grained services

. All other services in the hierarchical tree are composite


architecture.

has require a number ofcollection of methods or operations

Since services future exploiting systems, they should


required interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

a set of

The structural description of a seA serviceattributes



implicitly architectural concerns description of architecture in four sections, each of them specifying one type of architectural description hasfollowing advantages:


sections of ADL.






is translated at architecture level through

elements description

is an encapsulated and selfwith other services throughcomposite service

services. All other services in the hierarchical tree are

composite. A implement any functionality

its composing services.architecture.

a number of require a number of required interfaces. collection of methods or operations

Since services are developed independently from their future exploiting systems, they should


required interface. Provided interface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

set of

The structural description of a seA service attributes, as shown in Fig



implicitly from each other

description of architecture in four sections, each of them specifying one type of architectural description has


sections of ADL.






ure level through

description

is an encapsulated and selfwith other services through

ervice services.

. All other services in the hierarchical tree are A composite service


architecture.

a number of required interfaces.

collection of methods or operationsare developed independently from their

future exploiting systems, they should erfaces that describe theirInterfaces are two types, either

Provided interface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

set of operations

The structural description of a se is described based on

, as shown in Fighas a name specified by service_name


implicitly separatefrom each other



sections of ADL.






ure level through

description


ervice and . Leaf services are called

. All other services in the hierarchical tree are composite service

implement any functionality byits composing services.

architecture.

a number of required interfaces.



Provided interface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

operations

The structural description of a seis described based on

, as shown in Figservice_name


separatefrom each other








ure level through

description


and is Leaf services are called


by itselfits composing services.

a number of provided interfaces and may required interfaces.



Provided interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

operations

The structural description of a seis described based on



separates from each other








ure level through

description


is hierarchically Leaf services are called


itself,its composing services. Each

provided interfaces and may required interfaces.

collection of methods or operations that areare developed independently from their


interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

operations.

The structural description of a seris described based on


. Structural description meta-model of DSOPL

the from each other



t allows the description and analysis of the architecture





ure level through

is an encapsulated and selfwith other services through interfaces

hierarchically Leaf services are called


, but it delegates thisEach

provided interfaces and may required interfaces.

that areare developed independently from their


interfaceinterface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

rvice reflectis described based on

, as shown in Fig.service_name

model of DSOPL

the four from each other


t facilitates the modification and re-utilization of each

ysis of the architecture





ure level through its variabi

is an encapsulated and self-interfaces


. All other services in the hierarchical tree are composite service doesn’

but it delegates thisEach composite service is

provided interfaces and may required interfaces. Interfaces

that areare developed independently from their

future exploiting systems, they should haveerfaces that describe their functionalities Interfaces are two types, either provided interface

interface of a service is an interface that the service realizes, whereas is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

vice reflectis described based on

. 3: (1) Every attribute. (

model of DSOPL

four aforementioned from each other.


utilization of each






variabi

-contained unit. It interfaces


. All other services in the hierarchical tree are doesn’

but it delegates thiscomposite service is

provided interfaces and may Interfaces

that are supported by the are developed independently from their

have solid and wellfunctionalities provided interfaceof a service is an

interface that the service realizes, whereas required interfaceis an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

vice reflectis described based on

: (1) Every attribute. (

model of DSOPL

aforementioned . The modular


utilization of each






variabi

contained unit. It interfaces. The system

hierarchically deLeaf services are called

. All other services in the hierarchical tree are doesn’t execute


provided interfaces and may Interfaces

supported by the are developed independently from their

solid and wellfunctionalities provided interfaceof a service is an required interface

is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required

vice reflects is described based on the following

: (1) Every attribute. (

model of DSOPL

aforementioned The modular


utilization of each






lity section.

contained unit. It The system decomposed

Leaf services are called . All other services in the hierarchical tree are

t execute but it delegates this

composite service is

provided interfaces and may Interfaces define



is an interface that the service needs in order to operate.Services communicate to each other through provides/ consumes relationship via their provided/ required interfaces.

this service the following

: (1) Every attribute. (2) It has a

-ADL



utilization of each






lity section.

contained unit. It The system

composed Leaf services are called atomic

. All other services in the hierarchical tree are t execute


provided interfaces and may define



is an interface that the service needs in order to operate.Services communicate to each other through provides/

interfaces.


: (1) Every service) It has a

ADL


description of architecture in four sections, each of them specifying one type of architectural description has the

utilization of each






lity section.


composed atomic

. All other services in the hierarchical tree are t execute or

but it delegates this task composite service is

provided interfaces and may define


solid and wellfunctionalities andprovided interfaceof a service is an required interface

is an interface that the service needs in order to operate.Services communicate to each other through provides/

interfaces.


service) It has a


description of architecture in four sections, each of them the

utilization of each






lity section.


composed atomic

. All other services in the hierarchical tree are or

task composite service is

provided interfaces and may a


solid and well-and

provided interface of a service is an required interface

is an interface that the service needs in order to operate. Services communicate to each other through provides/

interfaces.


service ) It has a

textual_description

functionalities of the service, its inputs and expected outputs. (3) service is atomic or composite. section example.

<

</interface>

</

D

making changes to system’s architecture. types of

preexample, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically addition to other environmental conditions such as the existence of a relay point service in customer’s city, depicted in

s

textual_description

functionalities of the service, its inputs and expected outputs. (3) service is atomic or composite. section example.

<DSOPL

<structural_

<service

</interface>

</service>

<service name="customer_service"

</service>

<service name="relay

</service>

<service name="home_delivery_shipping_service"

</service>

</structural_

<variability_

<context

<configuration_description

</DSOPL

D. Variability

Variability making changes to system’s architecture. types of

1)

It represents pre-example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically addition to other environmental conditions such as the existence of a relay point service in customer’s city, depicted in

2)

It may exist several services.

textual_description

functionalities of the service, its inputs and expected outputs. (3) is_atservice is atomic or composite. section example.

SOPL-ADL>

<structural_

<service

<interfaces>

...

</interfaces>

<sub

<service name="retailer_service"

<interfaces>

</interface>

</interfaces>

</service>

<service name="warehouse_service"

<interfaces>

</service>

</sub

</service>


...

</service>


...

</service>


...

</service>

</structural_

<variability_

<context

configuration_description

SOPL-ADL>

Variability

Variability making changes to system’s architecture. types of

) S

It represents -conditioned constraints on runtime

example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically addition to other environmental conditions such as the existence of a relay point service in customer’s city, depicted in

) Variability of connection

It may exist several ervices.

textual_description

functionalities of the service, its inputs and expected outputs. is_atomic

service is atomic or composite. section description example.

ADL>

<structural_

<service

<interfaces>

...

</interfaces>

<sub-architecture>


<interfaces>

<interface name="i_order" role="provides">

<operation

</operations>

</interface>

<interface

</interface>

</interfaces>

</service>


<interfaces>

</service>

</sub-architecture>

</service>


</service>


</service>


</service>

</structural_

<variability_

<context_description


ADL>

Variability

Variability making changes to system’s architecture. types of variability:

Service variability

It represents conditioned constraints on runtime

example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically addition to other environmental conditions such as the existence of a relay point service in customer’s city, depicted in

Variability of connection

It may exist several ervices. The selection of the appropriate connection is done

Figure 5

textual_description

functionalities of the service, its inputs and expected outputs. omic

service is atomic or composite. description

<structural_description

<service name="

<interfaces>

</interfaces>

architecture>


<interfaces>


<operation

<operation name="submit_order_request"

<operation name="get_catalog"

</operations>

</interface>

<interface

</interface>

</interfaces>

</service>


<interfaces>

</service>

architecture>

</service>


</service>


</service>


</service>

</structural_description

<variability_description

description


ADL>

Figure 4. Structural

Variability

Variability making changes to system’s architecture.

variability:

ervice variability


example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically addition to other environmental conditions such as the existence of a relay point service in customer’s city, depicted in Fig


It may exist several The selection of the appropriate connection is done

Figure 5

textual_description

functionalities of the service, its inputs and expected outputs. omic has a Boolean value to indicate whether the

service is atomic or composite. description

description

name="supply_chain_management_service"

<interfaces>

</interfaces>

architecture>


<interfaces>


<operation



</operations>

</interface>

<interface

</interfaces>

</service>


<interfaces>

</service>

architecture>




description

description

description



Variability description

Variability in making changes to system’s architecture.

variability:

ervice variability


example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to chautomatically at ruaddition to other environmental conditions such as the existence of a relay point service in customer’s city,

Fig. 9



Figure 5. Example of service variability in sales scenario

textual_description

functionalities of the service, its inputs and expected outputs. has a Boolean value to indicate whether the

service is atomic or composite. description of the architecture related to our illustrative

description

supply_chain_management_service"

architecture>


<interfaces>


<operations>



</operations>

</interface>

<interface name="i_goods_request"

</interfaces>


<interfaces> ...

architecture>




description

description

description>



escription

in SPL making changes to system’s architecture.

variability:

ervice variability

It represents binding an alternative service that satisfies conditioned constraints on runtime

example, there are two alternatives of shipment; either a relay point shipment or home delivery shipmentThe decision of which alternative to ch

runtime depending on customer’s selection in addition to other environmental conditions such as the existence of a relay point service in customer’s city,

9.



. Example of service variability in sales scenario

textual_description functionalities of the service, its inputs and expected outputs.

has a Boolean value to indicate whether the service is atomic or composite.

of the architecture related to our illustrative

description>






</operations>

name="i_goods_request"


... </interfaces>

architecture>


<service name="relay_point_shipping_service"


description>

description>

> ... </



escription

SPL making changes to system’s architecture.

ervice variability

binding an alternative service that satisfies conditioned constraints on runtime


ntime depending on customer’s selection in addition to other environmental conditions such as the existence of a relay point service in customer’s city,




that explains in plain text the main functionalities of the service, its inputs and expected outputs.










</interfaces>


_point_shipping_service"


...

</context

configuration_description> ...


escription

SPL architecture making changes to system’s architecture.

ervice variability

















</interfaces>




... </variability_

context

... </

Figure 4. Structural description

architecture making changes to system’s architecture.





It may exist several alternative The selection of the appropriate connection is done












</interfaces>

<service name="customer_service" ...



</variability_

context_description

</configuration_description

description






alternative The selection of the appropriate connection is done



has a Boolean value to indicate whether the service is atomic or composite. Fig



<service name="retailer_service" ...





<service name="warehouse_service" ...

... is_atomic="Y">



</variability_

description


description





alternative The selection of the appropriate connection is done



has a Boolean value to indicate whether the ig. 4 shows the structural



... is_atomic="Y">



<operation name="get_catalog" ...


... is_atomic="Y">

is_atomic="Y">



</variability_description

description


of sales scenario

architecture refers to the ability of making changes to system’s architecture.




alternative connections between The selection of the appropriate connection is done



has a Boolean value to indicate whether the 4 shows the structural



is_atomic="Y">



...> </operation>

role="consumes">

is_atomic="Y">

is_atomic="Y">

_point_shipping_service" ...


description

description>


of sales scenario

refers to the ability of making changes to system’s architecture.

binding an alternative service that satisfies conditioned constraints on runtime. Back to

example, there are two alternatives of shipment; either a relay point shipment or home delivery shipment, as The decision of which alternative to ch


connections between The selection of the appropriate connection is done





supply_chain_management_service" ...

is_atomic="Y">


<operation name="submit_order_request" ...

</operation>

role="consumes">

is_atomic="Y">

is_atomic="Y">

... is_atomic="Y">

<service name="home_delivery_shipping_service" ...

description


of sales scenario

refers to the ability of making changes to system’s architecture. We

binding an alternative service that satisfies . Back to

example, there are two alternatives of shipment; either a relay , as shown

The decision of which alternative to chontime depending on customer’s selection in

addition to other environmental conditions such as the existence of a relay point service in customer’s city,






... is_atomic="N">

is_atomic="Y">

...> </operation>

</operation>

role="consumes">

is_atomic="Y">

is_atomic="Y">

is_atomic="Y">

... is_atomic="Y">

description>


of sales scenario

refers to the ability of e distinct

binding an alternative service that satisfies . Back to

example, there are two alternatives of shipment; either a relay shown oose is taken







is_atomic="N">

is_atomic="Y">

</operation>

</operation>

role="consumes">

is_atomic="Y">

is_atomic="Y">

is_atomic="Y">

>


refers to the ability of distinct

binding an alternative service that satisfies . Back to our sales

example, there are two alternatives of shipment; either a relay shown in Fig

ose is taken ntime depending on customer’s selection in







is_atomic="N">

</operation>

role="consumes">

is_atomic="Y">

is_atomic="Y">

configuration_description>

refers to the ability of distinct

binding an alternative service that satisfies our sales

example, there are two alternatives of shipment; either a relay in Fig







is_atomic="N">

</operation>

...

is_atomic="Y">

is_atomic="Y">

refers to the ability of distinct three


example, there are two alternatives of shipment; either a relay in Fig.


addition to other environmental conditions such as the existence of a relay point service in customer’s city, as





is_atomic="N">

</operation>

...

is_atomic="Y">

refers to the ability of three


example, there are two alternatives of shipment; either a relay 5.


addition to other environmental conditions such as the as


automatically at runtime according to constraintsFor example, the customer retailer service and thus connectioconnection for a VIP customer which normally has some extra privileges.Fig

service or a connectionservices by another set of interconnected servicescocomposition one in warehouse services, requested

8exist in the systemspecifies the part of the architecture that can be variable. variationvariation

variation_type

Possiblconnection

whether this variation may occur at runtimeapproaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative during points overhead of loading the entire configuration at velementshas a unique name priority

determine which architectural element is chosen in case there is more than one valid configuration at a given time.alternative with the highest

automatically at runtime according to constraintsFor example, the customer retailer service and thus connectioconnection for a VIP customer which normally has some extra privileges.Fig.

3)

This type of variability concerns replacing not only a service or a connectionservices by another set of interconnected servicescomposite architecturecomposition one in warehouse services, requested

T8. Wexist in the systemspecifies the part of the architecture that can be variable. variationvariation

variation_type

Possiblconnection

whether this variation may occur at runtimeapproaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative during points overhead of loading the entire configuration at variation point has severalelementshas a unique name priority


automatically at runtime according to constraintsFor example, the customer retailer service and thus connectioconnection for a VIP customer which normally has some extra privileges.

9 is an example of variability of connection.

) Variability of composition

This type of variability concerns replacing not only a service or a connectionservices by another set of interconnected services

mposite architecturecomposition one in warehouse services, requested

The metaWe specify

exist in the systemspecifies the part of the architecture that can be variable. variationvariation

variation_type

Possible values of connection

whether this variation may occur at runtimeapproaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative during points coverhead of loading the entire configuration at

ariation point has severalelementshas a unique name priority


Figure 6

Figure 7

automatically at runtime according to constraintsFor example, the customer retailer service and thus connections; either a connection for a regular customer or a connection for a VIP customer which normally has some extra privileges.

is an example of variability of connection.

Variability of composition


mposite architecturecomposition one in Figwarehouse services, requested items

he metae specify

exist in the systemspecifies the part of the architecture that can be variable. variation variation_name

variation_type

e values of connection

whether this variation may occur at runtime) or at approaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative during runtime

could be soverhead of loading the entire configuration at

ariation point has severalelements to fill the selectedhas a unique name priority. determine which architectural element is chosen in case there is more than one valid configuration at a given time.alternative with the highest

Figure 6

Figure 7

automatically at runtime according to constraintsFor example, the customer retailer service and thus

ns; either a connection for a regular customer or a connection for a VIP customer which normally has some extra

The is an example of variability of connection.



mposite architecturecomposition of

Fig. 1.warehouse services,

items

he meta-model of variability e specify

exist in the systemspecifies the part of the architecture that can be variable.

point_name

variation_type

e values of connection or whether this variation may occur at

) or at approaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative

runtimeould be s

overhead of loading the entire configuration at ariation point has several

to fill the selectedhas a unique name

This attribute helps the system automatically determine which architectural element is chosen in case there is more than one valid configuration at a given time.alternative with the highest

Figure 6. Example of connection variability in sales scenario

Figure 7. Example of composition variability in sales scenario



The variation_pointis an example of variability of connection.



mposite architectureof supply_chain_management_service. Here

warehouse services, items and returns

model of variability e specify in this section

exist in the systemspecifies the part of the architecture that can be variable.

point _name

variation_type e values of

or compositionwhether this variation may occur at

) or at approaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative

runtime is totally possould be s




. Example of connection variability in sales scenario

. Example of composition variability in sales scenario



variation_pointis an example of variability of connection.



mposite architecturesupply_chain_management_service

ere,warehouse services,

and returns

model of variability in this section

exist in the system specifies the part of the architecture that can be variable.

has indicating that specifies the type of this variation.

e values of composition

whether this variation may occur at ) or at runtime

approaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative

is totally possould be specifi










This type of variability concerns replacing not only a service or a connection, but services by another set of interconnected services

mposite architecture. supply_chain_management_service

, in addition to the roles of retailer and warehouse services, the manufacturer service

and returns


at architectural levelspecifies the part of the architecture that can be variable.

has indicating

that specifies the type of this variation. e values of variation_type

composition

whether this variation may occur at runtime

approaches where variability is clearly and completely specified at design time important in SOA systems, where selection of an alternative

is totally posspecified at compile


to fill the selectedhas a unique name alternative




automatically at runtime according to constraintsFor example, the customer retailer service and thus command




This type of variability concerns replacing not only a , but

services by another set of interconnected services Fig

supply_chain_management_service

in addition to the roles of retailer and the manufacturer service

and returns



has the followingindicating

that specifies the type of this variation. variation_type

composition

whether this variation may occur at runtime

approaches where variability is clearly and completely specified at design time [important in SOA systems, where selection of an alternative

is totally possed at compile


to fill the selectedalternative




automatically at runtime according to constraintsFor example, the customer service

commandns; either a connection for a regular customer or a

connection for a VIP customer which normally has some extra variation_point



This type of variability concerns replacing not only a , but replacing

services by another set of interconnected servicesFig. 7



and returns them to

model of variability in this section the different


the followingindicating


composition. whether this variation may occur at

. Contrary to traditional SPL approaches where variability is clearly and completely

[21],important in SOA systems, where selection of an alternative

is totally possed at compile

overhead of loading the entire configuration at ariation point has several alternatives

to fill the selected variation poialternative




automatically at runtime according to constraintsservice

commandns; either a connection for a regular customer or a

connection for a VIP customer which normally has some extra variation_point "customer_variation_point



This type of variability concerns replacing not only a replacing

services by another set of interconnected services7 illustrates another alternative



them to

model of variability the different


the followingindicating its unique name


. (3) whether this variation may occur at

Contrary to traditional SPL approaches where variability is clearly and completely

], variation_timeimportant in SOA systems, where selection of an alternative

is totally possible. ed at compile

overhead of loading the entire configuration at alternativesvariation poi

alternative

This attribute helps the system automatically determine which architectural element is chosen in case there is more than one valid configuration at a given time.

priority



automatically at runtime according to constraintsservice in Fig

command an order via ns; either a connection for a regular customer or a

connection for a VIP customer which normally has some extra customer_variation_point


This type of variability concerns replacing not only a replacing

services by another set of interconnected servicesillustrates another alternative



them to the warehouse service.

model of variability description the different


the followingits unique name


) variation_timewhether this variation may occur at compile


variation_time

important in SOA systems, where selection of an alternative ible. However,

ed at compileoverhead of loading the entire configuration at

alternativesvariation poi

alternative_name


priority



automatically at runtime according to constraintsin Fig

an order via ns; either a connection for a regular customer or a



This type of variability concerns replacing not only a replacing a set of interconnected




the warehouse service.

description the different


the followingits unique name


variation_time

compile


variation_time

important in SOA systems, where selection of an alternative However,

ed at compile-timeoverhead of loading the entire configuration at

alternativesvariation poi

_name


priority priority



automatically at runtime according to constraintsin Fig.




This type of variability concerns replacing not only a a set of interconnected





description the different variation points

at architectural level. A specifies the part of the architecture that can be variable.

the following its unique name

that specifies the type of this variation. are either

variation_time

compile


variation_time

important in SOA systems, where selection of an alternative However,

time. This reduces the overhead of loading the entire configuration at

alternatives, which are variation point. Each alternative

_name and This attribute helps the system automatically

determine which architectural element is chosen in case there is more than one valid configuration at a given time.

priority



automatically at runtime according to constraints 6 can access the









description is variation points

A variation pointspecifies the part of the architecture that can be variable.

attributes: its unique name


variation_time

compile-time


variation_time

important in SOA systems, where selection of an alternative However, some

. This reduces the overhead of loading the entire configuration at

which are nt. Each alternative

and This attribute helps the system automatically


priority



automatically at runtime according to constraints’ satisfaction. can access the

an order via twons; either a connection for a regular customer or a








is givenvariation points

variation pointspecifies the part of the architecture that can be variable.



variation_time

time Contrary to traditional SPL

approaches where variability is clearly and completely variation_time

important in SOA systems, where selection of an alternative some

. This reduces the overhead of loading the entire configuration at runtime

which are nt. Each alternative

and an order of This attribute helps the system automatically


priority=



satisfaction. can access the

two different ns; either a connection for a regular customer or a



services by another set of interconnected services within a illustrates another alternative

supply_chain_management_service than the in addition to the roles of retailer and

the manufacturer service the warehouse service.

givenvariation points

variation pointspecifies the part of the architecture that can be variable.


that specifies the type of this variation. are either service

variation_time specifies (i.e. before


attribute is important in SOA systems, where selection of an alternative

some variation . This reduces the

runtimewhich are nt. Each alternative

an order of This attribute helps the system automatically


=“1”




different ns; either a connection for a regular customer or a



within a illustrates another alternative

than the in addition to the roles of retailer and

the manufacturer service realizes the warehouse service.

given in Figvariation points

variation pointspecifies the part of the architecture that can be variable. Each

attributes: its unique name, (2)

that specifies the type of this variation. service

specifies (i.e. before



variation . This reduces the

runtime. Each which are possible nt. Each alternative



“1” is the





connection for a VIP customer which normally has some extra customer_variation_point" in




realizes the warehouse service.

in Figvariation points that

variation pointEach

attributes: (1) , (2)

that specifies the type of this variation. service

specifies (i.e. before



variation . This reduces the

Each possible

nt. Each alternative an order of

This attribute helps the system automatically determine which architectural element is chosen in case there

The is the



connection for a VIP customer which normally has some extra in




realizes

in Fig. that

variation point Each

(1) , (2)

that specifies the type of this variation. service, specifies

(i.e. before Contrary to traditional SPL

approaches where variability is clearly and completely attribute is

important in SOA systems, where selection of an alternative variation

. This reduces the Each

possible nt. Each alternative


determine which architectural element is chosen in case there The

is the

preferred one in a variation point. constraintsoperate properly.conditions selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed successfully.crosscutting “Fcondition that states that in order to choose the alternative ““Fig. 9)constraint“condition=

constraint in FM.

variation_type="service" variation_time="runtime">

reference_element="

reference_element="relay_point_shipping_service" priority="2">

element="relaying_point_service_in_city" condition="available"/>

calculculate_total_amount" condi

variation_type="connection" variation_time="runtime">

reference_element="i_customer_order" priority="1">

reference_element="i_VIP_customer_order" priority="2">

preferred one in a variation point. constraintsoperate properly.conditions selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed successfully.crosscutting “Feature condition that states that in order to choose the alternative “relay_point_delivery_alternative“relaying_point_service_in_cityFig. 9)constraint“relaying_point_in_citycondition=

constraint in FM.

<variability_

<variation_point name="shipping_variation_point"


reference_element="




</variation_point>

<variation_point name="customer_variation_point"




</alternative>

</variation_point>

</variability_

preferred one in a variation point. constraintsoperate properly.conditions selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed successfully.crosscutting “

eature condition that states that in order to choose the alternative relay_point_delivery_alternative

relaying_point_service_in_city

Fig. 9), this statement is equivalent constraintrelaying_point_in_city

condition=

constraint in FM.

<variability_



<alternatives>

<alternative name="home_delivery_alternative"

reference_element="

<contraints>

</alternative>

<alternative name="relay_point_delivery_alternative"


<contraints>



</contraints>

</alternative>

</alternatives>

</variation_point>



<alternatives>

<alternative name="regular_customer_alternative"


<alternative name="VIP_customer_alternative"


</alternative>

</alternativ

</variation_point>

</variability_

preferred one in a variation point. constraintsoperate properly.conditions selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed successfully.crosscutting “

eature Mcondition that states that in order to choose the alternative relay_point_delivery_alternative


, this statement is equivalent constraint relaying_point_in_city

condition=

constraint in FM.

<variability_



<alternatives>


reference_element="

<contraints>

</alternative>



<contraints>

<pre

<pre


</pre

<post

<post


</post

</contraints>

</alternative>

</alternatives>

</variation_point>



<alternatives>

alternative name="regular_customer_alternative"




</alternative>

</alternativ

</variation_point>

</variability_

Figure 8

preferred one in a variation point. constraints, in forms of operate properly.conditions that selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed successfully. crosscutting “

Modelcondition that states that in order to choose the alternative relay_point_delivery_alternative


, this statement is equivalent from “

relaying_point_in_city

condition=”unavailable

constraint in FM.

<variability_description



<alternatives>


reference_element="

<contraints>

</alternative>



<contraints>

<pre-condit

<pre-


</pre-conditions>

<post-condidtions>

<post


</post-

</contraints>

</alternative>

</alternatives>

</variation_point>



<alternatives>





</alternative>

</alternativ

</variation_point>

</variability_description

Figure

Figure 8

preferred one in a variation point. , in forms of

operate properly.that

selected alternative (i.e. alternative can be selected, only if all constraints of prerepresents desirable outcomes when process is completed

Pre and Pcrosscutting “requires

odel FM condition that states that in order to choose the alternative relay_point_delivery_alternative




unavailable

constraint in FM.

description



<alternatives>


reference_element="home_delivery_shipping_service" priority="1">

<contraints>

</alternative>



<contraints>

condit

-condition element_type="service"


conditions>

condidtions>

<post-condition element_type="method" element="re


-condidtions>

</contraints>

</alternative>

</alternatives>

</variation_point>



<alternatives>





</alternatives>

</variation_point>

description

Figure

Figure 8. Variability description meta


operate properly. that should be satisfied before executi

selected alternative (i.e. alternative can be selected, only if all constraints of pre-conditions are satisfied)represents desirable outcomes when process is completed

Pre and Prequires

FM condition that states that in order to choose the alternative relay_point_delivery_alternative




unavailable

description




home_delivery_shipping_service" priority="1">

<contraints> ...

</alternative>



<contraints>

conditions>

condition element_type="service"


conditions>

condidtions>

condition element_type="method" element="re


condidtions>

</contraints>

</alternative>

</alternatives>

</variation_point>







es>

</variation_point> ...

description

Figure 9. Variability description of sales scenario

Variability description meta


Preshould be satisfied before executi

selected alternative (i.e. alternative can be selected, only if all conditions are satisfied)

represents desirable outcomes when process is completed Pre and Prequires”,

in SPL paradigmcondition that states that in order to choose the alternative relay_point_delivery_alternative


, this statement is equivalent from “relay_point


unavailable

description>





... </contraints>



ions>



conditions>

condidtions>



condidtions>







...

description>

Variability description of sales scenario


preferred one in a variation point. , in forms of pre

Pre-conditions specify should be satisfied before executi


represents desirable outcomes when process is completed Pre and Post

, “excludesin SPL paradigm

condition that states that in order to choose the alternative relay_point_delivery_alternative


, this statement is equivalent relay_point


unavailable”





</contraints>





condidtions>



condidtions>







>



preferred one in a variation point. pre-conditions

conditions specify should be satisfied before executi


represents desirable outcomes when process is completed ost-con

excludesin SPL paradigm




relaying_point_in_city” ” is equivalent





</contraints>






calculculate_total_amount" condition="execute"/>









preferred one in a variation point. conditions



represents desirable outcomes when process is completed conditions are the equivalent of

excludesin SPL paradigm




feature.is equivalent





</contraints>






tion="execute"/>









preferred one in a variation point. Eachconditions



represents desirable outcomes when process is completed ditions are the equivalent of

excludes” and “in SPL paradigm


relaying_point_service_in_city” should be available, this statement is equivalent

relay_point_delivery

feature.is equivalent










tion="execute"/>









Each alternative has a set of conditions and




and “in SPL paradigm. For example, the pre

condition that states that in order to choose the alternative relay_point_delivery_alternative”, the service

” should be available, this statement is equivalent in

_delivery

feature. is equivalent










tion="execute"/>








Variability description meta-model of DSOPL

alternative has a set of and post




and “andFor example, the pre

condition that states that in order to choose the alternative ”, the service

” should be availablein FM

_delivery

On the contrary, is equivalent










tion="execute"/>








model of DSOPL

alternative has a set of post


selected alternative (i.e. alternative can be selected, only if all conditions are satisfied). Post


and” For example, the pre


” should be availableFM to a

_delivery” On the contrary,

is equivalent to












reference_element="i_customer_order" priority="1"> ...




model of DSOPL

alternative has a set of post-conditions

conditions specify a should be satisfied before executi

selected alternative (i.e. alternative can be selected, only if all . Post


” constraints in For example, the pre


” should be availableto a feature

On the contrary, to








... </alternative>

reference_element="i_VIP_customer_order" priority="2"> ...


model of DSOPL

alternative has a set of conditionsa group of

should be satisfied before executiselected alternative (i.e. alternative can be selected, only if all

. Post-condition represents desirable outcomes when process is completed

ditions are the equivalent of constraints in

For example, the precondition that states that in order to choose the alternative

”, the service ” should be available

to a “requiresfeature

On the contrary, to “exclude





condition element_type="method" element="re-

</alternative>

...


model of DSOPL-ADL

alternative has a set of conditions

group of should be satisfied before executing

selected alternative (i.e. alternative can be selected, only if all condition


constraints in For example, the pre


” should be availablerequires

featureOn the contrary,

exclude




-

</alternative>

ADL

alternative has a set of conditions, to

group of ng the



constraints in For example, the pre


” should be available (see requires

feature to On the contrary,

excludes

</alternative>

ADL

alternative has a set of to

group of the



constraints in For example, the pre-


(see requires”

to On the contrary,

s”

</alternative>

E. Context description

Architecture reconfiguration is based on context changes. The context consists of any element that influences the behavior and/or the structure of the architecture. It can be related either to system’s environment (e.g. escalator state in the case of crisis management software), evaluated quality of service (e.g. time to response to a query), hardware architecture changes (e.g. server failure), etc. Thus, context element needs to be described in a dynamic ADL. We include these context elements as part of the architecture description to allow context-aware configurations (i.e. autonomous run-time adaptation according to context changes). A context element could capture raw data from a single information source such as a GPS locator that locates customer’s current location to search for a nearby relay point for the shipping service in our sales example. In this case, context element is considered as a primitive_context. In some other cases, a single information source could not be sufficient to take decisions; in that case, different atomic information sources’ values are collected, combined and analyzed in order to give sufficient and more accurate information about the context value. We call this context as composite_context. We can consider the weather forecast example, where the weather is considered hot when both temperature and humidity sensors exceed a certain threshold.

A simplified meta-model of context is illustrated in Fig. 10. Any context element has a unique name and a context_type to indicate to which family of contexts it belongs (e.g. contexts related to environment, user preferences, etc.). Context element also has values_type that indicates the type of its values, either primitive types such as integer, double, etc. or user-defined types. In Fig. 11, we show two primitive context descriptions from our sales scenario.

<context_description>

<context_type name="environment">

<context is_aggregate="N">

<name> location </name>

<values_type> double </values_type>

</context>

<context is_aggregate="N">

<name> shipping </name>

<values_type> enumeration </values_type>

<permitted_values>

<possible_value> home </possible_value>

<possible_value> relay_point </possible_value>

</permitted_values>

</context> ...

</context_type> ...

</context_description>

Figure 11. Some context descriptions from sales scenario

F. Configuration description

In traditional architectures, where environment is considered stable, services are selected and composed at design time. In contrast, in dynamic environment, parts of the

software can be instantiated or evolved at runtime. Therefore, we need to maintain, in addition to structural information, architectural information of the running system. The configuration section of DSOPL-ADL allows describing all the configuration rules to generate valid architectures. A valid architecture is a concrete architecture whose services and connections comply with configuration rules.

The configuration description section of DSOPL-ADL has an initialization sub-section, where all static elements (services and connections) in addition to alternatives, whose variation_time=”compile_time”, are instantiated. The connection part has two references to two different service interfaces, the one that calls the information consumer_interface and the one that provides the information provider_interface. The configuration description also has a dynamic_configuration sub-section where architectural configurations are triggered based on runtime context conditions. In other words, a concrete architecture is selected through two consecutive execution levels: (1) static bind where core services are selected and bound then (2) late-binding where remaining services and variation points are bound.

In initialization sub-section, we first bind static services to the configuration in addition to their connections. In dynamic_configuration sub-section, we integrate selected instances of services by observing context changes that are specified in the condition part of the configuration rule. Fig. 12 illustrates the architectural configuration meta-model. Any partial_configuration has a name and an attribute called priority of type integer, which determines which configuration to choose in case more than one partial_configuration satisfies current conditions. At that time, the one with the higher priority is privileged. Each partial_configuration is composed of two parts; condition part and dynamic_action part. In the condition part, we specify conditions that are driven by context elements. In the dynamic_action part, we specify all dynamic activities that will be realized. Every action concerns an architectural element which can either be a service or a connection. Action_type defines the type of change that will apply on the selected element. Its values are limited to bind, unbind, activate or deactivate concerned elements. Figure 10. Context description meta-model of DSOPL-ADL

Figure 12. Configuration description meta-model of DSOPL-ADL

In our illustrative example, customer and supply chain management services are instantiated at design time, as depicted in Fig. 13, whereas the relay point shipping service or home delivery shipping service are instantiated dynamically depending on environment’s conditions.

<configuration_description>

<initialization>

<services>

<deployable_service_instance

service_instance_name="customer_service_instance" ...>

</deployable_service_instance>

<deployable_service_instance

service_instance_name="supply_chain_management_service_instance" ...>

</deployable_service_instance> 

</services>

<connections>

<connection consumer_interface="i_goods_request"

provider_interface="i_goods_response">

</connection>

...

</connections>

</initialization>

<dynamic_configuration>

...

<partial_configuration name="home_delivery_configuration"

priority="2">

<condition>

<context_element name="shipping"/>

<expression operator="equals"> home </expression>

</condition>

<dynamic_actions>

<architecture_element element_type="service"

name="home_delivery_shipping_service_instance" action_type="bind"/>

<architecture_element element_type="connection"

consumer_interface="i_home_delivery"

provider_interface="i_shipment_ready_delegation"

action_type="activate"/>

</dynamic_actions>

</partial_configuration>

...

</dynamic_configuration>

</configuration_description>

Figure 13. Configuration description of sales scenario

IV. CONCLUSION AND PERSPECTIVES

We have presented DSOPL-ADL, an architectural language that allows the runtime variability of a service based product lines system to be modeled. To manage the runtime variability of such service based systems at architectural level, we have proposed a modular language called DSOPL-ADL which is structured and composed of four sections; structural, variability, context and configuration. For each part, its meta-model was presented and discussed in detail through an illustrative example.

It is worth noting that we have perceived variability in this work from a spatial perspective and not temporal, that is why we have only considered describing variation points and alternatives and have intentionally eliminated versioning aspect. Another point is that during late binding, we do not use any real-time configuration verification mechanisms. However, we assume that pre-conditions and post-conditions assure a valid configuration.

We are working on generating BPEL process from DSOPL architecture. As a future work; we intend to build a modeling tool for DSOPL-ADL and to conduct more experiments in order to completely evaluate our approach.

REFERENCES

[1] P. Clements, D. Garlan, F. Bachmann, J. Ivers, J. Stafford, L. Bass, P.

Merson. Documenting software architectures: views and beyond, 2nd

edition. Addison-Wesley Professional, 2010.

[2] B. Mohabbati, B. Asadi, D. Gašević, J. Lee. Software Product Line

Engineering to Develop Variant-Rich Web Services. In Web Services

Foundations, pp. 535-562. Springer New York, 2014.

[3] P. Clements, L. Northrop. Software product lines: Practices and Patterns.

Addison-Wesley, 2001.

[4] M. Galster, P. Avgeriou, D. Weyns, T. Männistö. Variability in software

architecture: current practice and challenges. SIGSOFT Softw. Eng.

Notes, vol. 36, no. 5, pp. 30-32, September 2011.

[5] M. P. Papazoglou, W.-J. Heuvel. Service oriented architectures:

approaches, technologies and research issues. The VLDB Journal, vol.

16, no. 3, pp. 389–415, 2007.

[6] N. Medvidovic. ADLs and dynamic architecture changes. In Joint

proceedings of ISAW-2 & Viewpoints '96 on SIGSOFT '96.

[7] J. Lee, G. Kotonya, D. Robinson. Engineering Service-Based Dynamic

Software Product Lines. Computer, vol.45, no.10, pp. 49-55, Oct, 2012.

[8] N. Medvidovic, R.N. Taylor. A classification and comparison

framework for software architecture description languages. IEEE

Transactions on Software Engineering, vol.26, no.1, pp.70-93, Jan 2000.

[9] N. Medvidovic, P. Oreizy, J. E. Robbins, R.N. Taylor. Using object-

oriented typing to support architectural design in the C2 style.

In Proceedings of SIGSOFT '96, pp. 24-32, 1996.

[10] J. Magee, N. Dulay, S. Eisenbach, J. Kramer. Specifying Distributed

Software Architectures. In Proceedings of the 5th European Software

Engineering Conference, pp. 137-153, 1995.

[11] F. Oquendo. π-ADL: An architecture description language based on the

higher-order typed π-calculus for specifying dynamic and mobile

software architectures. ACM SIGSOFT, pp. 1-14, 2004.

[12] D.C. Luckham, J.J. Kenney, L.M. Augustin, J. Vera, D. Bryan, W.

Mann. Specification and Analysis of System Architecture Using Rapide.

IEEE Trans. Software Eng., vol. 21, no. 4, pp. 336-355, Apr. 1995.

[13] A. Joolia, T. Batista, G. Coulson, A.T.A. Gomes. Mapping ADL

Specifications to an Efficient and Reconfigurable Runtime Component

Platform. WICSA’05, pp.131-140, 2005.

[14] R. Allen, R. Douence, D. Garlan. Specifying dynamism in software

architectures. In Proceedings of the Workshop on Foundations of

Component-Based Systems, Zurich, Switzerland, pp. 11–22. 1997.

[15] C. Cetina, P. Trinidad, V. Pelechano, A. Ruiz-Corts. An Architectural

Discussion on DSPL. 2nd International Workshop on Dynamic Software

Product Lines (DSPL08). Limerick, Ireland, 2008.

[16] E.Y. Nakagawa. Reference architectures and variability: current status

and future perspectives. In Proceedings of the WICSA/ECSA, 2012.

[17] E.M. Dashofy, A. van der Hoek, R.N. Taylor. An Infrastructure for the

Rapid Development of XML-based Architecture Description Languages.

In ICSE2002, Orlando, Florida, 2002.

[18] R. van Ommering, F. van der Linden, J. Kramer, J. Magee. The Koala

Component Model for Consumer Electronics Software. Computer 33, 3,

pp. 78-85, March 2000.

[19] F. Oquendo. π-ADL for WS-Composition: A Service-Oriented

Architecture Description Language for the Formal Development of

Dynamic Web Service Compositions. In: SBCARS, pp. 52–66, 2008.

[20] X. Jia, S. Ying, H. Cao, D. Xie. A New Architecture Description

Language for Service-Oriented Architecture. In Sixth International Conf.

on Grid and Cooperative Computing GCC, pp. 96-103, 2007.

[21] M. Galster. Describing variability in service-oriented software product

lines. In Proceedings of the ECSA’10, pp. 344–350, 2010.

[22] R. Capilla, et al. An overview of Dynamic Software Product Line

architectures and techniques: Observations from research and industry.

Journal of Systems and Software, vol. 91, pp. 3-23, May 2014.

an architecture description language for dynamic service...

Documents