SOA-CoM: Building a Correct by Design Service Oriented

Architectural Style

Supporting Structural and Non-functional Properties

Imen Graja, Imen Loulou and Ahmed Hadj Kacem

ReDCAD Laboratory, Department of Computer Science, University of Sfax, B.P. 1088, 3018 Sfax, Tunisia

Keywords:

Correct by Design, Service-oriented Architectural Style, Communication Schemas, Formal Speciﬁcation.

Abstract:

As a piece of software continues to evolve, it inevitably becomes more complicated and harder to understand,

maintain, reuse, evolve and improve. Software architecture has emerged as a solution to these issues particu-

larly for complex systems. Having a correct software architecture is critical to the success of the design and the

development of a system. In order to design a correct software architecture the concept of architectural styles

is used. In this paper, we propose SOA-CoM, a formal approach for the correct modeling of service oriented

architectural styles. We specify a set of communication schemas that deﬁne SOA structural and interaction

properties. These schemas are modeled as UML graphs. In order to reuse them and to build the style, we

deﬁne composition rules that can be applied to them. A software architect can then extend the designed style

with non-functional properties (NFP) using extension rules. To ensure design correctness, we specify these

communication schemas using the formal language ASL (ArchWare Style Language). All speciﬁcations are

implemented and checked using the ASL Toolkit.

1 INTRODUCTION

The ever-changing nature of business requires that

software systems continue to constantly evolve. As

a software system changes, its design can be ana-

lyzed from an architectural style perspective to serve

as a basis for static system analysis. An architectural

style is an approach that simpliﬁes software design

and reuse by capturing and exploiting system design

knowledge (Monroe et al., 1997). Traditionally, the

primary focus of reuse research has been on the reuse

of software entities, such as objects or components.

In most cases, the reuse was at the code-level, even

though these are not the only entities that can be suc-

cessfully reused. Furthermore, there have been sig-

niﬁcant improvements in reuse technology and meth-

ods at more abstract levels. At this level of abstrac-

tion, key issues include the deﬁnition of a methodol-

ogy to design architectural styles that support design

fragments for reuse-driven implementation.

Deﬁning a new style, however, is not an easy task.

In particular, software architects may not be skilled

enough to build correct styles. So the question that

arises is: How can we ensure that the designed style

is correct? To answer this question we require new

foundations that enable architects to reason about and

plan based on reuse-driven and correct by design de-

velopment at an abstract level.

We are interested in a service-oriented architec-

ture that becomes increasingly popular for complex

and dynamic distributed web applications. The build-

ing of a software solution based on SOA typically re-

quires combining existing services using techniques

like choreography and orchestration.

This paper aims to deﬁne a formal approach that

supports the correct modeling of SOA styles. This

approach includes all relevant mechanisms of ser-

vice publication, discovery, connectivity and compo-

sition and provides a modeling solution based on a set

of communication schemas that we propose. These

schemas integrate structural and interaction properties

of SOA. By deﬁning these schemas our approach not

only provides the opportunity for reuse at an abstract

level but also provides a formal guarantee of correct-

ness of representing service-based styles. We also

elaborate composition rules that have to be applied to

these schemas to build the desired architectural style.

The communication schemas and the designed style

are speciﬁed formally in ASL (ArchWare Architec-

ture Style Language) (Leymonerie, 2004). ASL is a

formal language that allows style formalization, de-

ﬁnes families of architectural elements and expresses

172

Graja I., Loulou I. and Hadj Kacem A..

SOA-CoM: Building a Correct by Design Service Oriented Architectural Style - Supporting Structural and Non-functional Properties.

DOI: 10.5220/0004889001720179

In Proceedings of the 9th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2014), pages 172-179

ISBN: 978-989-758-030-7

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

related constraints related to their structure and be-

havior.

The rest of this paper is organized as follows.

We survey related work in section 2. Section 3

provides a general overview on the SO architectural

styles. Sections 4, 5 and 6 present our SOA-CoM

approach. They describe our methodology to de-

sign correct SOA styles and extend them with non-

functional properties. In section 7, we present a

travel reservation system case study to illustrate our

methodology. Then in section 8 we prove the consis-

tency of these speciﬁcations. Finally, section 9 con-

cludes our work and discusses future works.

2 RELATED WORK

The work presented in this paper focuses on the gen-

eral research area of architectural styles and the mod-

eling of SOA styles in particular.

Shaw and Garlan in (Shaw and Garlan, 1996)

deﬁne software architectural styles as a vocabulary

of the type of components and connectors, and a set

of constraints on how they can be combined. Fur-

ther, they codify structural, behavioral, interaction,

and composition guidelines that are likely to result in

software systems with desired properties. We base

our work on these same concepts and aim to deﬁne

an architectural style modeling approach that allows

software architects to work at a much more abstract

level.

There are several architectural styles; the pipe and

ﬁlter, client-server, peer-to-peer, publish/subscribe

and service-oriented architecture.

One of the beneﬁts of SOA is that it improves

reusability in a distributed environment with indepen-

dent services. Thus, the main components of SOAs

are services that provide operations (software func-

tionalities) to their consumers. In order to publish ser-

vices and to allow these consumers to access to them,

a service registry must be used.

A lot of works have been published in the

area of the modeling and validation of SOA ap-

plications (IBM, 2005) and, SOA Meta-Model

based on the UML proﬁle and Pattern-Oriented SOA

model (Baresi et al., 2006; Wada et al., 2011; Amir

and Zeid, 2004; Sanz and Marcos, 2012). However,

all these models are not abstracted as an architectural

style. Although, Tang et al (Tang et al., 2010) for-

mally deﬁne Enterprise SOA style model which is a

special type of SOA for enterprise.

The proposal of Baresi in (Baresi et al., 2006)

deﬁnes the SOA style as graph transformation sys-

tems from the abstract business level style to the SOA

speciﬁc-style. Nevertheless, these approaches are es-

pecially interested in service discovery mechanism

and they do not focus on service composition (chore-

ography and orchestration).

In the same context, Wada et al (Wada et al., 2011)

describe a solution based on UML proﬁle which con-

siders only non-functional aspects while Amir and

Zeid in (Amir and Zeid, 2004) deﬁne a SOA mod-

eling approach that considers functional and non-

functional aspects. Moreover, Lopez-Sanz and Mar-

cos in (Sanz and Marcos, 2012) deﬁne a framework

called ArchiMeDes that follows the MDA approach

for the speciﬁcation of software architectures using

the concepts behind SOA. These works center their

attention in the deﬁnition of the architectural model

and they do not support service discovery mechanism.

In (Zhao et al., 2010) Zhao et al deﬁne SOA archi-

tectural styles based on graph grammars but, this ap-

proach considers only the concept of service compo-

sition.

Other works that focus on correct modeling by

design of architectural styles like P/S-CoM (Loulou

et al., 2010). This work is interested in formal mod-

eling of event-based style using the communication

schemas coded in Z notation. Once the style is ob-

tained the behavioral properties can be added like

presented in (Krichen et al., 2012). This work pro-

poses P/S-CoM+ approach as an extension of the P/S-

CoM with behavioral properties. We are inspired by

these approaches to deﬁne a correct modeling of SOA

styles.

To conclude our literature review, we can say that

there is a need to complement these contributions

by taking into account the service compositional as-

pect, dynamic service discovery and correct model-

ing by design. The approaches mentioned above are

interesting and helpful in deﬁning and achieving our

goal. We develop a visual and formal approach which

aims to help an architect design correct SOA architec-

tural styles based on a set of reusable communication

schemas and composition rules. The designed style

can later be extended using extension rules with non-

functional properties.

In general we are not in an ad-hoc solution that

represents an arbitrary solution where the architect

will be free in its design. However, our methodol-

ogy guides the architect to have as a result an SOA

style. Such approach cannot be considered as an ar-

bitrary solution. In particular our solution ensures the

correctness and the reliability of the designed style

using the composition rules and the proved commu-

nication schemas that integrate the SOA properties.

This makes our work considered as correct-by design

approach.

SOA-CoM:BuildingaCorrectbyDesignServiceOrientedArchitecturalStyle-SupportingStructuralandNon-functional

Properties

173

3 SERVICE-ORIENTED

ARCHITECTURAL STYLE

Service-oriented architectures are an important kind

of dynamic architectures (Baresi et al., 2006). The

service is their central concept. It supports different

roles depending on the functionality given by the sys-

tem. Moreover, depending on the atomicity of the ser-

vice, it can be classiﬁed as a simple service (atomic

service) or a composite one.

There are two types of service composition ap-

proaches. One approach is the choreography and the

second one is the orchestration that deﬁnes one ser-

vice which assumes the coordination role named ”Or-

chestrator”.

Additionally, services need user invocation to in-

teract with each other or to modify their behav-

ior (Sanz et al., 2008). To that end, the business pro-

cess must be initiated by the user which can be an

application front-end, a web portal or another service.

For this reason, our approach contains a component

representing the user of the application. This compo-

nent can have the role of a consumer or consumer and

provider in the same time.

Since service consumers can invoke services di-

rectly or through an intermediary. We deﬁne a bro-

ker that can be used as an intermediary between con-

sumers and their services. This component performs

tasks needed to convert the data format, route mes-

sages and save data as a buffer (Endrei et al., 2004).

This broker (resp. network of brokers) can build

distributed applications that require asynchronous,

multi-cast interaction like publish-subscribe mod-

els (Cugola and Nitto, 2008) in SOA.

Services communicate and interact with each

other through an asymmetric connection based on re-

quest/reply message exchanges. So, we choose to rep-

resent this connector by a straight line (using UML

connector) used for call-return style. However, we

give for the composition link a dependency notation

between required and provided interface that was rep-

resented by a lollipop notation (UML1).

To make services accessible to users; they must

be published, then searched in registries. Compo-

nents and service discovery can interact in either a

pull or push mode. In (Zisman et al., 2008), the au-

thor supports a proactive runtime service discovery

using pull and push modes. On the one hand, the reg-

istry can be passive and allow only service publica-

tion thus requiring the consumer to support pull run-

time service discovery. On the other hand, the registry

can be active so the client can be notiﬁed when a re-

quired service is published (Cugola and Nitto, 2008).

In both cases, the register can allow both active and

passive discovery (pull and push). As we have al-

ready mentioned, interactions between components

and service discovery are speciﬁed for architectures

that can use a centralized or a distributed registry. In

this context, there are various approaches that have

been deﬁned concerning service publishing and dis-

covery model. In (Verma et al., 2005; Yulin et al.,

2010) the authors describe a peer-to-peer network of

UDDI registries like MWSDI that was built by the

Meteor-S project. However, other approaches pre-

sented in (Cugola and Nitto, 2008; Baresi and Miraz,

2006) support a distributed service registries using a

publish/subscribe network. Hence, we determine that

the distributed service discovery can follow either a

peer-to-peer topology or a publish/subscribe one.

4 A METHODOLOGY TO

DESIGN A CORRECT SOA

STYLE

In this section, we deﬁne a set of reusable and sim-

ple communication schemas that integrate structural

and interaction properties of SOA. They can be com-

posed to have as a result a correct service-oriented

architecture style. Next, this style can be extended

by non-functional properties using extension rules.

These steps are represented in ﬁg.1. In order to ensure

the correctness of the designed style, some properties

have to be deﬁned.

Figure 1: The steps for designing a SOA style.

4.1 Structural and Interaction

Properties

The communication schemas represent the basic

blocks that can be composed to build correct SOA

styles. They integrate structural aspects and the prop-

erties of interaction between the components. These

properties are deﬁned as follows: 1)The service must

be published in a registry service, after being created.

2)The client discovers the desired service through

a registry service. 3)The client receives and saves

the description of the relevant service. 4)The com-

munication with the service discovery is established

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

174

through the push and/or the pull mode. 5)The dis-

tributed service discovery can follow either a peer-to-

peer or publish/subscribe topology. 6)Services can

be composed using orchestration or choreography.

7)With the central composition, all the communica-

tions between services must be through an orchestra-

tor. 8)The distributed composition is based on P2P

style that can be classiﬁed into three sub-styles: a

static, mobile or hybrid (Dillon et al., 2007) 9)The

communication between services must be triggered

by the consumer. 10)The consumer communicates

directly or through a broker with services. 11)The

broker utilizes a callback or publish/subscribe inter-

action mechanisms. 12)The broker-based communi-

cation can be through a single broker or through a dis-

tributed number of brokers. 13)The interconnection

topology of the distributed brokers can be peer-to-

peer or hierarchical. 14)In hierarchical structure, the

communication between brokers can be facilitated by

their parents broker where sub-brokers are controlled

by the parent broker. 15)SOA supports bidirectional

communication between services. 16)The consumer

can interact with more than one component.

4.2 Non-functional Properties

Most of the existing works deal with the modeling of

functional aspects and a few of them consider non-

functional requirements in their proposals. In order

to induce certain desired properties that can be func-

tional or non-functional(Sterritt and Cahill, 2008), ar-

chitectural styles place certain constraints. However,

each instance of a software family will have similar

constraints but different non-functional requirements.

Therefore after designing a style, it can be reﬁned

simply by adding non-functional properties (NFPs).

The semantic of messages transmission and mes-

sage processing can be speciﬁed for each connec-

tor (Wada et al., 2006) through three properties. The

ﬁrst property is the synchrony semantic of message

transmissions between the source and its destination

that can be: synchronous or asynchronous. The sec-

ond property is the assurance level of message de-

livery where three different semantics are deﬁned: at

most once, at least once or exactly once. Finally, to

specify how to order messages, we extend the style

with the following policies: FIFO, LIFO, highest pri-

ority ﬁrst or earliest deadline ﬁrst.

These properties- synchrony, the assurance level

of message delivery and how to order messages- are

deductible from the experimentations and from our

research in the related works. They can be integrated

in the designed style using extension rules that were

deﬁned later.

4.3 Generic Communication Schemas

We elaborate a reusable set of proved communication

schemas which are used to integrate structural and in-

teraction properties of SOA. They facilitate the task of

the architect because they can be used for reuse and

they ensure the compliance with these properties.

The communication schemas are characterized ac-

cording to different phases: the publication phase, the

discovery phase, the invocation phase and the compo-

sition phase.

To deﬁne our proposal, a service is described with

a node that contains a stereotype ≪Service≫ and

three labels: Role, Type and Var (Variable: service

instances). First, the label Role can be either ”Prov”

(Provider) that denotes a set of operation being exe-

cuted to achieve the system functionality, or ”Orch-

est” (Orchestrator) which represents the process re-

sponsible for service composition.

In addition, a service discovery, a com-

posed service and a broker are represented with

nodes that contain respectively the stereotype

≪ServiceDiscovery≫, ≪ServiceComp≫ and

≪Broker≫ and two labels: Type and Var. A

service discovery can also be found in a distributed

environment but in this case, it is described with a

stereotype ≪DistServiceDiscovery≫ and with tree

labels: Type, Var and Topology that can be either P2P

or P/S.

Further, a component that represents the ap-

plication user can be speciﬁed with a stereotype

≪Component≫ and three labels: Role, Type and Var.

In this case, two possible roles were identiﬁed: Con-

sumer (Cons) and Provider/Consumer (PrCons).

Each component contains two types of ports: the

ﬁnd and publish port that are deﬁned to the central-

ized or a distributed service discovery and, the pro-

vided and required port that are described for other

components.

In order to characterize communication schemas,

we model interactions between components accord-

ing to each phase in the next section.

4.3.1 The Publication Phase

In the publication phase, we deﬁne interactions be-

tween services and a service discovery through the

push mode. In this case, the service is the initia-

tor of the communication. It can have the provider

role, the orchestrator role or it can be a composed ser-

vice. In addition, these services can publish their in-

formation to a centralized service discovery or a dis-

tributed one through the push mode from services to

the service discovery. We deﬁne six communication

SOA-CoM:BuildingaCorrectbyDesignServiceOrientedArchitecturalStyle-SupportingStructuralandNon-functional

Properties

175

schemas, three of them with centralized service dis-

covery named Re pub S and the others with the dis-

tributed one named ReD

pub D. For example, ﬁg.2

represents the communication schema between a ser-

vice that has the role Prov and a single service discov-

ery.

Figure 2: The communication schema Re pub S.

4.3.2 The Discovery Phase

In the discovery part, we deﬁne two communication

links between components: pull and push. First, we

can establish the push mode between the service dis-

covery and components (like the service that has the

role Prov or Orchest, the composed service, and com-

ponent that has the role Cons or PrCons). In this

case, the set of communication schemas is named

push C. Likewise, the same mode of communi-

cation is used between these previous components

and the distributed service discovery. Here, the set

of communication schemas is named ReD

push C. In

fact, with the push mode, the initiator of the com-

munication is the centralized service discovery or

the distributed one. In addition, we can attribute

the pull mode between the service discovery and the

above components that play the role of the initiator

of the communication. Consequently, we have de-

ﬁned two sets of communication schemas. The ﬁrst

set is named Re pull C with a centralized service

discovery and the second one is named ReD pull C

with a distributed service discovery. Finally, be-

tween the above elements we can consider these two

links ”pull and push” involving one communication

schema. To illustrate, a communication schema from

the set Re

pull push C with a composed service and

with a service discovery using the pull and push

mode is depicted in ﬁg.3. Moreover, we develop

a set of schemas with a distributed register named

ReD

pull push C. Thus, we declare ﬁfteen commu-

nication schemas with centralized service discovery

and ﬁfteen others with distributed one.

Figure 3: The communication schema Re pull push C.

4.3.3 The Invocation Phase

In this part, we take into consideration the fact that

the communication between users and services can

be done directly or through a broker. Services (that

have the role Prov, Orchest or that can be a composite

service) communicate with their users (Components

that can have the role Cons or PrCons) through a con-

nection based on bidirectional message exchanges. In

this context, we deﬁne nine communication schemas

with direct invocation and ten others with brokered

one. Thus we characterize, in the ﬁg.4, an example

of a communication schema of direct invocation with

a consumer and with a service orchestrator named

Dir CS. In this set, the requestor is the consumer

(resp. PrCons). But when this latter is the provider of

information then we elaborate another set of commu-

nication schemas named Li

Dir SC.

Figure 4: The communication schema Li Dir CS.

Fig.5 illustrates an example of communication

schema Li Ind CB using a Broker and a consumer.

The difference between the set Li Ind CB and the set

Ind BC is that the broker in the ﬁrst example rep-

resents the requester of information. However, in the

second one, it represents the provider of information.

Figure 5: The communication schema Li Ind CB.

4.3.4 The Composition Phase

As we have previously stated that there are two dif-

ferent types of composition. For each type, we deﬁne

their corresponding communication schemas. In the

context of an orchestration, we deﬁne ﬁve communi-

cation schemas which represent the interactions be-

tween a service orchestrator and other services (ser-

vice that has the role Prov, another orchestrator or

a composed service). When the requester is an or-

chestrator, then the set of communication schemas is

named Orchest

SOC. However, when the orchestrator

represents the provider of information, then the set of

schemas is named Orchest

CSO. Fig6 illustrates an

example of communication schema from the set Or-

chest

SOC that shows the interaction between an or-

chestrator and a service which has the role ”Prov”.

Figure 6: The communication schema Orchest CSO.

In the context of a choreography, we presented

only two communication schemas named Chor

SCS

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

176

that contain a composition link between a composed

service and either a service having the role Prov or an-

other composed service. Fig.7 represents an example

of a Chor

SCS with a service provider.

Figure 7: The communication schema Chor SCS.

Each of these communication schemas is formally

speciﬁed using ASL (ArchWare Architecture Style

Language)which allowsthe deﬁnition of architectural

styles. As illustration, we represent the Re

pull C

speciﬁcation.

Re_pull_C is style where {

constructors{

Re_pull_C is constructor( consumer: Alias,

discovery : Alias,c : set[ Component ],

d: Component, pullrc: Connector);{

d is discovery;i is consumer;

iterate c by i : consumer do {

new pllrc;

attach i˜RE1˜input to

pullrc#last˜comp_conn_port˜output;

........}}}

constraints {

only_Cons_SP_SO_SC is constraint {..},

only_pull_connector is constraint {..}}}}}

The ASL language has the ability to specify structural

and behavioral constraints. So all the properties are

deﬁned in the ”constraint” part in the ASL code. Fi-

nally, to design a correct SOA style and to have a for-

mal speciﬁcation of the designed style, we must de-

ﬁne some composition rules.

5 COMPOSITION RULES

Based on communication schemas, we construct the

global designed style by applying some composition

rules. These rules ensure the correctness of the de-

ﬁned properties and help the architect to instantiate

and to compose the selected schemas to have as a re-

sult the designed style. This style meets the require-

ments of the user and respects the correctness of SOA

properties.

◦ Adding

schema: in this step, the architect

chooses the adequate communication schemas

that meet their needs. For each node, the archi-

tect can modify the instantiable labels like Type,

Var (variable) and the Topology that can be either

P2P or P/S with a distributed service discovery. In

addition, he must rename the pull and push mode

used with keeping the preﬁx Pull or Push depend-

ing on the mode. For example, the link ”Pull” can

have the name ”Pull

CD”.

◦ Merge

nodes: In order to be merged, two nodes

must have the same type and role. They must also

communicate in the same manner with other com-

ponents. In particular, the nodes that contain the

stereotype ≪DistServiceDiscovery≫ must have

the same topology. In other words, giving two

communication schemas, we can merge their con-

sumers (resp. PrCons) and their services which

have the role Prov (resp. Orchest) only if they

have the same role and type. But, if they are Bork-

ers or ServicesDiscovery they must have only the

same type to be merged. In the same way, we

can apply this rule on distributed service discov-

ery if they have the same type and the same topol-

ogy. In all these cases, it was necessary to make

sure that nodes which are connected to the same

type of component will be merged only if they

interact with the same types of links. To illus-

trate, in ﬁg.8 we apply the rule Merge nodes on

the service discovery nodes from communication

schemas Re

pull C and Re pub S.

Figure 8: Graph obtained by composition of two communi-

cation schemas.

6 EXTENSION RULES

Once the style is designed progressively, the architect

can extend it by adding non-functional properties. As

a result, a new style can be formed by adding these

properties to an existing style. This section makes our

methodology to design a correct style more extensible

and facilitates reuse. Then, a style can be described

relative to its parent by applying one or more exten-

sion rules.

◦ Synchrony

Ext: this rule extends one connector

in the style with the synchrony property.

◦ DeliveryAssurance Ext: Each connector also

can be extended with delivery assurance seman-

tic by applying this rule.

◦ OrderingPolicy

Ext: During a communication

between two components, a queue is used for stor-

ing messages in storage. So by applying this rule,

we specify the connector’s ordering technique.

SOA-CoM:BuildingaCorrectbyDesignServiceOrientedArchitecturalStyle-SupportingStructuralandNon-functional

Properties

177

7 CASE STUDY

To illustrate our work, we use a simple travel reser-

vation system as represented in ﬁg.9. This system in-

volves four different participants: client wishes to use

the travel agency service that in turn, contacts hotels,

to perform its work. In fact, the hotel service is re-

sponsible for reserving the available rooms. Finally,

the last participant is the register that contains all ser-

vice descriptions. In this example, the travel agency is

a composed service and we choose to deﬁne a register

as a centralized service discovery.

Figure 9: The travel reservation system.

According to our methodology, in order to design

a correct SOA style, we start by applying the ﬁrst

composition rule named Adding

schema. This rule

allows the architect to choose and to instantiate all

necessary schemas according to each phase.

◦ Publication Phase: In this phase, two communica-

tion schemas are chosen from Re

pub S. The ﬁrst

one is represented with a composed service and

the second one is picked with a service that has

the role Prov. These schemas integrate the ﬁrst

and the fourth property.

◦ Discovery Phase: from Re pull C, two schemas

are selected. One of them is represented with a

consumer and the other one is picked with a com-

posed service. In this phase, we promote the sec-

ond and the third property.

◦ Invocation Phase: the architect chooses only the

direct communication between the user (client)

and the travel agency service. So, he instan-

tiates the communication schema, from the set

Dir CS, with a consumer and a composed ser-

vice. This schema integrates the ninth and the six-

teenth property.

◦ Composition Phase: the eighth and the ﬁfteenth

property was depicted in the following added

schemas. The service choreography is repre-

sented by the schema Chor SCS using the hotel

as an atomic service and the travel agency as a

composite service.

Next, we apply the Merge

nodes rule as explained

previously. In the ASL code we were just calling

each communication schema constructor used in the

previous step. Then, we deﬁne, in the constructor pa-

rameters, the necessary values. Finally, we obtain our

global style represented in ﬁg.10 and its associated

code ASL.

Figure 10: Graph obtained by composition of communica-

tion schemas.

To summarize, we provide to the architect the pos-

sibility to build a correct by design SOA styles that

were generated by applying our methodology based

on both semantic and visual representation. This style

integrates structural and interaction properties. Next,

to extend it with non-functional properties, we ap-

ply the extension rules. For example, the architect

can specify the synchrony semantic of message trans-

missions between the client and the service ”Travel

agency” that can be in an asynchronous way. And it

can specify the at least once as delivery assurance se-

mantic with applying the Synch

Ext and DeliveryAs-

surance

Ext rules.

8 ANALYZING

ARCHITECTURAL STYLE

The supported analysis includes checking the consis-

tency (Mateescu and Oquendo, 2006). In Archware,

The analysis covers the description and veriﬁcation

of properties using the Archware Architecture Anal-

ysis Language (AAL). It enables automated veriﬁca-

tion by model checking or theorem proving.

8.1 Checking the Consistency

A schema speciﬁcation is consistent if at least one

model exists. This instance must be conform to the

schema that means it must satisfy its constraints. So

this consistency can be checked simply using the

property veriﬁcation tool which is the Analyzer. To

do so, it must ensure that all properties are veriﬁed.

Otherwise, an error message is sent to the designer.

So, if an instance of the schema is found, we say that

the schema is consistent. But if no instance can be

found the schema cannot be satisﬁed by any other

model. According to this analysis, all schema spec-

iﬁcations are consistent. While consistency checking

formally establishes the existence of initial model for

each schema speciﬁcation, in most cases this is not

as strong a check as we would like. We also need

to show that all the composition rule speciﬁcations

ENASE2014-9thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

178

preserve consistency. In order to accomplish that, we

need to check certain properties of a model after the

composition of schema instances.

9 CONCLUSION

In this paper we presented a formal approach for cor-

rect modeling of SOA styles named SOA-CoM. Our

aim was to deﬁne a formal methodology based on a

reusable set of communication schemas and compo-

sition rules that can be applied to generate the global

architectural style. These schemas include all struc-

tural and interaction properties of an SOA. Then, we

formally designed the NFPs of the SOA which can

be integrated into the architectural style based on

the extension rules. To ensure the style correctness,

we speciﬁed the semantics of these schemas using

the formal language ASL. As the style was designed

based on the applied composition rules, the speciﬁca-

tion of this style will be built progressivelyin ASL. As

an extension to our work, we can add other NFPs ac-

cording to the user need in order to complement our

approach. Then, our ongoing work will extend our

SOA-CoM approach by reasoning about foundations

regarding architectural evolution.

REFERENCES

Amir, R. and Zeid, A. (2004). A uml proﬁle for service

oriented architectures. In OOPSLA Companion, pages

192–193. ACM.

Baresi, L., Heckel, R., Th”one, S., and Varr’o, D. (2006).

Style-based modeling and reﬁnement of service-

oriented architectures. Software and System Model-

ing, 5(2):187–207.

Baresi, L. and Miraz, M. (2006). A distributed approach for

the federation of heterogeneous registries. In ICSOC,

pages 240–251.

Cugola, G. and Nitto, E. D. (2008). On adopting content-

based routing in service-oriented architectures. Infor-

mation & Software Technology, 50:22–35.

Dillon, T. S., Wu, C., and Chang, E. (2007). Reference ar-

chitectural styles for service-oriented computing. In

Proceedings of the 2007 IFIP international confer-

ence on Network and parallel computing, NPC’07,

pages 543–555, Berlin, Heidelberg. Springer-Verlag.

Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P.,

Krogdahl, P., Luo, M., and Newling, T. (2004). Pat-

terns: service-oriented architecture and web services.

IBM Corp. Riverton, NJ, USA.

IBM (2005). Ibm’s soa foundation an architectural intro-

duction and overview. Version 1.0.

Krichen, I., Loulou, I., Dhouib, H., and Kacem, A. H.

(2012). P/s-com+: A formal approach to design cor-

rect publish/subscribe architectural styles. In Perseil,

I., Breitman, K., and Pouzet, M., editors, ICECCS,

pages 179–188. IEEE Computer Society.

Leymonerie, F. (December 2004). ASL language and tools

for architectural styles. PhD thesis, University of

Savoie.

Loulou, I., Jmail, M., Drira, K., and Hadj Kacem, A.

(March 2010). P/s-com : Building correct by de-

sign publish/subscribe architectural styles with safe

reconﬁguration. Journal of Systems and Software,

83(3):412-428.

Mateescu, R. and Oquendo, F. (2006). Pi-aal: an ar-

chitecture analysis language for formally specifying

and verifying structural and behavioural properties of

software architectures. SIGSOFT Softw. Eng. Notes,

31(2):1–19.

Monroe, R. T., Kompanek, A., Melton, R., and Garlan, D.

(1997). Architectural styles, design patterns, and ob-

jects. Software, IEEE, 14(1):43–52.

Sanz, M. L., Acu˜na, C. J., Cuesta, C. E., and Marcos, E.

(2008). Deﬁning service-oriented software architec-

ture models for a mda-based development process at

the pim level. In WICSA, pages 309–312.

Sanz, M. L. and Marcos, E. (2012). Archimedes: A model-

driven framework for the speciﬁcation of service-

oriented architectures. Inf. Syst., 37(3):257–268.

Shaw, M. and Garlan, D. (1996). Software architecture.

Perspectives on an emerging discipline. Prentice Hall

Publishing.

Tang, L., Dong, J., Peng, T., and Tsai, W.-T. (2010).

Modeling enterprise service-oriented architectural

styles. Service Oriented Computing and Applications,

4(2):81–107.

Verma, K., Sivashanmugam, K., Sheth, A., Patil, A., Ound-

hakar, S., and Miller, J. (2005). Meteor-s wsdi: A

scalable p2p infrastructure of registries for semantic

publication and discovery of web services. Informa-

tion Technology and Management, 6(1):17–39.

Wada, H., Suzuki, J., and Oba, K. (2006). Modeling non-

functional aspects in service oriented architecture. In

Proceedings of the 2006 IEEE International Confer-

ence on Service Computing, pages 222–229, Chicago,

IL.

Wada, H., Suzuki, J., and Oba, K. (2011). Leveraging early

aspects in end-to-end model driven development for

non-functional properties in service oriented architec-

ture. J. Database Manag., 22(2):93–123.

Yulin, N., Huayou, S., Weiping, L., and Zhong, C. (2010).

Pdus: P2p-based distributed uddi service discovery

approach. Service Sciences, International Conference

on, 0:3–8.

Zhao, Y., Zhao, B., Liu, M., Hu, C., and Ma, D. (2010).

Towards a graph grammar based veriﬁcation approach

for runtime constrained evolution of service-oriented

architectures. In SOSE, pages 159–164. IEEE.

Zisman, A., Dooley, J., and Spanoudakis, G. (2008). Proac-

tive runtime service discovery. IEEE International

Conference on Services Computing (July 2008), pages

237–245.

SOA-CoM:BuildingaCorrectbyDesignServiceOrientedArchitecturalStyle-SupportingStructuralandNon-functional

Properties

179