non-functional properties in the model-driven development...

Softw Syst Model (2011) 10:287–311DOI 10.1007/s10270-010-0155-y

THEME SECTION

Non-functional properties in the model-driven developmentof service-oriented systems

Stephen Gilmore · László Gönczy · Nora Koch ·Philip Mayer · Mirco Tribastone · Dániel Varró

Received: 16 January 2009 / Revised: 5 December 2009 / Accepted: 15 February 2010 / Published online: 9 March 2010© Springer-Verlag 2010

Abstract Systems based on the service-oriented architec-ture (SOA) principles have become an important cornerstoneof the development of enterprise-scale software applica-tions. They are characterized by separating functions intodistinct software units, called services, which can be pub-lished, requested and dynamically combined in the pro-duction of business applications. Service-oriented systems(SOSs) promise high flexibility, improved maintainability,and simple re-use of functionality. Achieving these proper-ties requires an understanding not only of the individual arti-facts of the system but also their integration. In this context,non-functional aspects play an important role and should be

Communicated by Marko Boškovic, Bernhard Schätz, Claus Pahl, andDragan Gasevic.

S. Gilmore · M. TribastoneUniversity of Edinburgh, Edinburgh, UKe-mail: [email protected]

M. Tribastonee-mail: [email protected]

L. Gönczy · D. VarróBudapest University of Technology and Economics,Budapest, Hungarye-mail: [email protected]

D. Varróe-mail: [email protected]

N. Koch · P. MayerLudwig-Maximilians-Universität München,Munich, Germany

P. Mayere-mail: [email protected]

N. Koch (B)Cirquent GmbH, Munich, Germanye-mail: [email protected]

analyzed and modeled as early as possible in the developmentcycle. In this paper, we discuss modeling of non-functionalaspects of service-oriented systems, and the use of thesemodels for analysis and deployment. Our contribution in thispaper is threefold. First, we show how services and servicecompositions may be modeled in UML by using a profilefor SOA (UML4SOA) and how non-functional properties ofservice-oriented systems can be represented using the non-functional extension of UML4SOA (UML4SOA-NFP) andthe MARTE profile. This enables modeling of performance,security and reliable messaging. Second, we discuss formalanalysis of models which respect this design, in particular weconsider performance estimates and reliability analysis usingthe stochastically timed process algebra PEPA as the under-lying analytical engine. Last but not least, our models are thesource for the application of deployment mechanisms whichcomprise model-to-model and model-to-text transformationsimplemented in the framework VIATRA. All techniques pre-sented in this work are illustrated by a running example froman eUniversity case study.

Keywords Non-functional properties · Service-orientedsoftware · SOA · Modeling · Model-driven engineering

1 Introduction

Service-oriented computing (SOC) focuses on the devel-opment and integration of distributed, interoperable sys-tems based on a set of autonomous, platform-independentunits called services. Service-orientation aims at a loosecoupling of these services by means of orchestration ofservices, i.e. combining and re-using the services in the pro-duction of business applications. These characteristics havenow pushed service-oriented systems towards widespread

123

288 S. Gilmore et al.

success, demonstrated by the fact that many large companieshave invested a lot of effort and resources in promoting ser-vice delivery on a variety of computing platforms, mostly inthe form of Web services. Very soon there will be a pleth-ora of new services for e-government, e-business, and e-sci-ence, and other areas within the rapidly evolving InformationSociety, leading to a pressing demand for effective techniquesand automated methods for engineering service-oriented sys-tems.

A range of domain-specific languages and standards arealready available for engineering service-oriented architec-tures (SOAs), such as WSDL, BPEL, WCDL, WS-Policy,and WS-Security. These deal with the various artifacts ofSOA systems, such as service descriptions, orchestrations,policies, and non-functional properties at specification level.However, more systematic and model-based approaches forthe development of service-oriented systems (SOSs) are stillin their infancy. Most of the proposed modeling languagesfocus on the structural aspects of services [2,15,20,22,28].Some represent low-level service constructs, e.g. BPEL [28]and only a few translate the models into platform-indepen-dent models (PIMs) or platform-specific models (PSMs) (e.g.[2,28]).

Achieving the properties of service-oriented systems men-tioned above requires instead (1) an understanding of theindividual artifacts of the system, their specification and theirintegration—in other words, a complete picture of the sys-tem represented at a high level of abstraction, (2) techniquesfor the early estimation and evaluation of quality of service,and (3) mechanisms for the automated generation of appli-cations. Model-driven development (MDD) methods are themost appropriate approaches to support both specification(i.e. 1) and generation (i.e. 3) of SOA software, and to easemodel-based quantitative and qualitative analysis (i.e. 2).

In this paper, we present an MDD-based approach to mod-eling, analysis, and deployment of service-oriented systems,and focus on how to deal with non-functional properties suchas performance, security and reliable messaging. This MDDprocess consists of a chain of model transformations whichstart with the models of the application and produce plat-form-independent models (so-called PIMs in the MDA ter-minology) and generate platform-specific models (PSMs inMDA) by PIM2PSM mappings. Some of the non-functionalaspects can be directly implemented by using WS-standards(e.g., reliable messaging, security, logging, etc.) while othersare effected by the underlying system architecture (e.g. per-formance). Therefore we target the first group by automateddeployment mechanisms based on standards while the latteris the subject of quantitative analysis.

The approach is based on a profile for modeling servicesin UML, called UML4SOA [29,30], which we extend toinclude very generic non-functional specifications which arebound “per contract” to the services in the structural model

(we call this extension UML4SOA-NFP). For modeling thequantitative behavior of service-oriented systems, we optedfor using the specifications offered by the OMG MARTE(Modeling and Analysis of Real-time and Embedded sys-tems) profile [40]. A UML profile is a light-weight exten-sion of the UML frequently used to define a domain-specificmodeling language, which is performed using the exten-sion mechanisms the UML itself offers, i.e. stereotypes,tagged values and constraints. MARTE deals with con-cerns of model-based analysis across the spectrum fromspecification to detailed design of real-time and embeddedsystems. MARTE facilitates the annotation of models withinformation required to perform specific analysis. Specifi-cally, MARTE focuses on performance and schedulabilityanalysis. The models built using the UML4SOA and MAR-TE profile are used on the one hand as source for a set ofmodel-to-model and model-to-code transformations endingup with the deployment of the service-oriented system. Onthe other hand, they allow for software evaluation at designtime providing e.g. a performance analysis in an early phaseof the software development. Our model-driven approach andthe analysis techniques are fully tool-supported.

The paper is structured as follows: In Sect. 2 we presentthe characteristics of the development process of service-ori-ented software; we use a scenario of a distributed eUniversitycourse management system to illustrate the challenges in thedevelopment of this kind of software. This scenario is alsoused as the running example in the remaining sections. Sec-tion 3 describes the UML4SOA modeling approach focusingon the functional aspects. Section 4 presents the extension ofUML4SOA for covering non-functional aspects of service-oriented systems (UML4SOA-NFP). The extension com-prises model elements for specifying non-functional prop-erties in structural and behavioral UML diagrams. Section 5shows how software analysis methods can evaluate the mod-els built with the profiles presented in the previous sectionsto realize a performance analysis. Section 6 completes thedevelopment process presenting model-driven deploymentmechanisms. We compare our approach to related work inSect. 7. Some conclusions and the next steps in our researchon the model-driven development approach for SOAs arepresented in Sect. 8. Figure 1 gives an overview of the maincontributions of this paper for the model-driven developmentof service-oriented systems and shows the role of the non-functional aspects in our approach.

2 Challenges in the development of service-orientedsystems

A Service-Oriented Architecture separates functions intodistinct software units called services which users can com-bine and reuse in the production of business applications.Service descriptions are published by service providers and

123

Non-functional properties in the model-driven development of SOSs 289

UML modelscore, structure

(SoaML)Sec.3.1.

UML modelsnon-functional, structure

(UML4SOA-NFP)Sec.4.2.

UML modelscore, behavior(UML4SOA)

Sec.3.2.

UML modelsnon-functional, behavior

(UML4SOA-NFP/MARTE)Sec.4.3.

Evaluation of non-functional propertiesSec.5.

Automated service deployment by model transformationsSec.6.

Service descriptor(WSDL)

Client stubs(NF extension)

Server-side config(standard NF platforms)

Performance model (PEPA)SLA analysis (throughput...),

sensitivity analysis

re-design

Fig. 1 Overview of the approach

services are invocable by a service requester according to aset of access policies. The service interface describes the setof interactions supported by a service. Service-orientationaims at a loose coupling of these services by means of theorchestration of services, i.e. the description of an executablepattern of invocations that must be followed in order to auto-matically coordinate, manage and arrange the set of services.An orchestration is in our approach also defined as a service.

The advantages offered by service-oriented software oncein production have their costs in the development phaseas complexity increases due to the additional orchestration,compensation, publishing of services, and management ofservice-level agreements which need to be addressed. Thereare primarily two important software engineering mecha-nisms which address the problem of increasing complex-ity and offer mechanisms to ease development. On the onehand, domain-specific languages, in particular domain-spe-cific modeling languages (DSML), focus on the conceptsused in a domain, which are of greatest significance for thework in a specific area. Very often a concept is a pattern-likefeature which allows the users of the languages to reduce thecomplexity of code or models. On the other hand, automaticcode generation based on models—i.e. model-driven devel-opment—eases the production and maintenance of software.Of course, appropriate tool support is required for modeling,transforming the models, and generating code.

Model-driven development makes models predominantartifacts of the development and emphasizes the automa-tion of the engineering process. Cornerstones of the MDDapproaches are modeling languages for the specification

of the applications, and model transformation languagesrequired for generating other models or code. Service-oriented design is a new domain which currently lacks effec-tive and comprehensive domain-specific modeling languagesand code generation tools.

In addition to the traditional class diagram model ofthe domain and the sequence and state diagrams model-ing the behavior of objects and components, in the case ofservice-oriented software we need also to model the orches-tration of services. Here we should consider such compli-cations as compensation for actions in case of any failureduring the process. Non-functional properties such as secu-rity, performance and reliable connection need to be modeledas well. They play a more relevant role in service-orientedcomputing than in traditional software. This is because ser-vices must respect service-level agreements which establishsecurity policies and acceptance levels of performance. It isintuitive then to model the non-functional properties as con-tracts which are associated with the services, i.e. to followa contract-based modeling approach.

3 Modeling service-oriented systems

The UML [34] is the most well-known and mature languagefor modeling software systems. However, plain UML lacksnative support for the specification of structural and behav-ioral aspects of services. Service modeling introduces a newset of key distinguishing concepts, for example partner ser-vices, message passing among requester and provider of ser-vices, long-running transactions, compensation, and events.Without specific support for those concepts in the modelinglanguage, diagrams quickly get overloaded with technicalconstructs, degrading their readability.

Several attempts have been made to add service function-ality to the UML. Most notably, SoaML [36] is an upcomingstandard UML profile of the OMG for structural specificationof service-oriented architectures. Our own contribution to thefield of UML service modeling is UML4SOA [30], a pro-file for specifying behavior of services, in particular serviceorchestrations, a feature which distinguishes service-orientedsoftware from traditional application software. UML4SOAis based on the structural part of SoaML, adding the dynamicparts.

In the following sections we present our running exampleand give an overview of SoaML and UML4SOA conceptsand discuss how to apply them to the case study scenario.We describe the structure of the service-oriented system and,finally, the service orchestration behavior. In each of thesesections, we introduce the relevant SoaML and UML4SOAstereotypes used.

In later sections, the elements introduced here will beextended with a package of stereotypes for dealing with non-functional properties (Sect. 4).

123


Table 1 SoaML profile (excerpt)

UML4SOA metaclass Stereotype UML metaclass Description

Participant «Participant» Class Represents some (possibly concrete) entity or component thatprovides and/or consumes services

ServicePoint «ServicePoint» Port Is the offer of a service by one participant to others using welldefined terms, conditions and interfaces. It defines theconnection point through which a participant provides aservice to clients

RequestPoint «RequestPoint» Port Models the use of a service by a participant and defines theconnection point through which a participant makes requestsand uses or consumes services

ServiceInterface «ServiceInterface» Class Is the type of a «ServicePoint» or «RequestPoint», specifyingprovided and required operations

MessageType «MessageType» DataType, Class Is the specification of information exchanged between servicerequesters and providers

3.1 The eUniversity case study

As a running example throughout this paper, we will considermodeling and implementing an all-electronic university (aneUniversity), in which all courses and paperwork are han-dled online. We will focus on the processing of a studentapplication for a course of studies. This example has beentaken from one of the case studies of the Sensoria project[39,46].

In this scenario, the student uses a website to apply for acertain course of studies. That is, the eUniversity website actsas a client to a service providing the functionality for han-dling a student application. This functionality is provided byan entity called the ApplicationCreator. Implementing thisfunctionality requires the combination (orchestration) of aset of different external services, e.g. student office, a ser-vice for the upload of documents, and a service to checkthe application (validation service). This validation service,implemented by an entity called the ApplicationValidator, isitself also a composition of other services.

In the student application scenario of our eUniversitycase study, the following non-functional requirements aredefined:

– The Client and the ApplicationCreator should commu-nicate via a secure and reliable connection.

– The document UploadService might be under heavyworkload, therefore its throughput should be at least 10requests/second with a 4 s average response time.

– All requests sent to the ApplicationValidator should beacknowledged.

– As the validation service handles confidential data, allrequests should be encrypted in order to protect the pri-vacy of the students.

– Messages sent by the ApplicationValidator must beclearly accountable, i.e. non-repudiation of messagesmust be guaranteed.

We will detail the model of the case study in the next twosubsections and come back to the above requirements in latersections.

3.2 Modeling structural aspects

For modeling the structural aspects of our case study, weemploy the basic UML mechanisms for modeling compositestructures, enhanced with stereotypes from the SoaML pro-file—«Participant», «ServicePoint», «RequestPoint», «Ser-viceInterface» and «MessageType» (listed in Table 1). Withregard to the structure of our case study, we talk about ser-vices, service interfaces, and service participants. The basicunit for implementing service functionality is a service partic-ipant, modeled as a class with the stereotype «Participant».A participant may provide or request services through ports,which are stereotyped with «RequestPoint» or «Service-Point», respectively. Each port has a type, which is a «Servi-ceInterface» implementing or using operations as defined ina standard UML interface definition.

The components of the eUniversity case study which arerelevant for the student application scenario are shown inFig. 2. It represents the overall composition of a SOA systemmodeled as a UML component diagram using SoaML modelelements. As can be seen, each of our two participants offersor requires multiple services; for example, the Application-Creator is invoked by the client for the creation of a newapplication, but invokes several other services as well, suchas the validationService and the statusService.

The eUniversity case study scenario includes two ser-vices which are defined as an orchestration of other ser-vices, the ApplicationCreator and the ApplicationValida-tor (see colored components in Fig. 2). The behavior ofeach of these is modeled as an activity diagram which usesUML4SOA extensions. The objective of the ApplicationVal-idator is to verify whether the application follows the poli-cies of the university. The actual implementation of the two

123


+checkRequirements( app : Application, documents : Documents, admission : AdmissionData, studentFormalData : FormalStudentData) : ValidationResult

AdmissionDecisionInterface

+registerStudent( app : Application )+deregisterStudent( app : Application )+getFormalStudentData( app : Application ) : FormalStudentData

OfficeInterface

+initializeApplicationStatus( app : Application ) : Status+applicationStatusInvalid( st : Status )+applicationStatusSuccess( st : Status )+applicationStatusCancel()

StatusInterface

+initializeUploading( app : Application )+getUploadedDocuments( app : Application ) : Documents

UploadInterface

+newApplication( app : Application ) : Status+completeApplication() : Status+cancelApplication() : Status

ClientInterface

+getAdmissionInformation( app : Application ) : AdmissionData

AdmissionInterface

+startValidation( app : Application )+completeValidation( docs : Documents ) : ValidationResult+cancelValidation()

ValidationInterface

<<ServiceInterface>>AdmissionDecissionRequestInterface

<<ServiceInterface>>ValidationRequestServiceInterface

<<ServiceInterface>>ClientServiceInterface

<<ServiceInterface>>OfficeRequestInterface

<<ServiceInterface>>AdmissionRequestInterface

<<ServiceInterface>>StatusRequestInterface

<<ServiceInterface>>UploadRequestInterface

<<Participant>>ApplicationCreator

<<ServicePoint>>creationService

<<RequestPoint>>statusService

<<RequestPoint>>uploadService

<<RequestPoint>>officeService

<<RequestPoint>>validationService

<<Participant>>ApplicationValidator

<<ServicePoint>>validationService

<<RequestPoint>>admissionService

<<RequestPoint>>decisionService

<<RequestPoint>>officeService

<<type>>

<<type>>

<<type>>

<<type>>

<<type>>

<<type>>

<<type>>

<<type>>

<<type>>

Fig. 2 The eUniversity student application scenario

orchestrations further refines the behavior of this scenario,and is detailed in Sect. 3.3. The other services, includingthe client service, are atomic and implemented in a standardprogramming language (for example, in Java).

Overall, the scenario works as follows: A student uses thewebsite to apply for a certain course of studies. The web-site (not shown) contacts the ApplicationCreator throughits creationService service port. The ApplicationCreator,in turn, calls other entities through the uploadService, theofficeService, and the statusService ports. Last but not least,it also contacts the ApplicationValidator through the valida-tionService port for checking the student data and setting thestatus of the application. Being implemented as an orches-tration itself, ApplicationCreator works with other entitiesitself—through the officeService (again), the admissionSer-vice, and finally the decisionService ports to carry out thevalidation task. After a review of the application by the vari-ous services, the student is notified whether he was acceptedat the university.

Summarizing, services are defined as ports. Depending onwhether they are provided or required, the stereotypes «Ser-vicePoint» or «RequestPoint» are used. Ports belong to «Par-ticipant»s, which may require or provide multiple services.

3.3 Modeling behavioral aspects

More challenging than modelling the structural aspects ofSOAs is the task of modeling behaviour—in particular the

orchestration of services. To enable developers to model suchbehaviour in an easy fashion, we have introduced UML4SOA[30], which is defined as a high-level domain-specific mod-eling language (DSML) for modeling service orchestrationsas extensions of UML activity diagrams.

An excerpt of the UML4SOA metamodel is shown inFig. 3, which includes the main concepts of our DSMLand the relationships among these concepts. For eachnon-abstract class of this metamodel, we have defined astereotype with the objective of producing semanticallyenriched but still readable models of service-oriented sys-tems. Tables 2 and 3 provide a summary of the elementsof the metamodel, the stereotypes that are defined for thesemetamodel elements (they comprise the profile UML4SOA),the UML metaclasses they extend, and a brief description. Forfurther details on UML4SOA, including the full metamodel,the reader is referred to [30].

UML4SOA proposes the use of UML activity diagramsfor modeling service behavior, in particular for modelingorchestrations which coordinate other services. We assumethat business modelers are most familiar with this kind ofnotation to show dynamic behavior of business workflows.

The two processes ApplicationCreator and Application-Validator from Fig. 2 are modeled as UML4SOA orches-trations. The first one is shown in Fig. 4. It illustrates howthe creator interacts with its partner entities through ports.It starts with a receipt («receive») of the call newAppli-cation through the creationService service port, receiving

123


Fig. 3 Excerpt of theUML4SOA metamodel(includes some colored UMLmetaclasses)

ServiceElement

ServiceSend&ReceiveAction

Pin

CompensateAction

ActivityEdge Action

CompensateAllAction

ServiceActivityNode

ServiceInteractionAction

Element

ServiceReceiveAction

LinkPin

ServiceReplyAction

ServiceSendAction

EventEdge

CompensationEdge

OutputPin

ReceivePinSendPin

InputPin

eventBaseElement1

eventHandler0..*

0..*

compensatedElement 1

compensationHandler

1

0..*

partner

1

0..*

compensationTarget1

Table 2 UML4SOA profile (1)


ServiceActivity Node «serviceActivity» Activity, Structured ActivityNode Represents a special activity for service behavior or agrouping element for service-related actions

ServiceSendAction «send» CallOperationAction Is an action that invokes an operation of a target serviceasynchronously, i.e. without waiting for a reply. Theargument values are data to be transmitted asparameters of the operation call. There is no returnvalue

ServiceReceiveAction «receive» AcceptCallAction Is an action representing the receipt of an operation callfrom an external partner. No answer is given to theexternal partner

ServiceSend&Receive «send&receive» CallOperationAction Is a shorthand for a sequential order of send and receiveactions

ServiceReplyAction «reply» ReplyAction Is an action that accepts a return value and a valuecontaining return information produced by a previousServiceReceiveAction action

the application. After the receipt of this call, statusSer-vice and uploadService are initialized (both times with syn-chronous calls, i.e. using «send&receive»), and the initalcall is returned with a «reply». Completing the initalizationphase, the startValidation call is sent (using an asynchro-

nous «send») to the ApplicationValidator to request the startof the validation. After having done so, the process waitsfor another call («receive») from the client. The student willeither press the button to complete the application, or anotherone to cancel it.

123


Table 3 UML4SOA profile (2)


CompensationEdge «compensation» ActivityEdge Is an edge which connects an orchestration element to becompensated with the one specifying a compensation. It isused to associate compensation handlers to activities andscopes

EventEdge «event» ActivityEdge Is an edge connecting event handlers with an orchestrationelement during which the event may occur. An event handlermust start with a receive, and runs in parallel and in thecontext of the attached scope

CompensateAction «compensate» Action Triggers the execution of the compensation defined for a(defined) scope or activity. Can only be used in compensationor event handlers

CompensateAllAction «compensateAll» Action Triggers compensation of the scope attached to the handler inwhich the action is invoked, and all subscopes in reverseorder of their completion. Can only be used in compensationor event handlers

LinkPin «lnk» InputPin Holds a reference to the partner service by indicating thecorresponding service point or request point involved in theinteraction

SendPin «snd» InputPin Is used in send actions to denote the data to be sent to anexternal service

ReceivePin «rcv» OutputPin Is used in receive actions to denote the data to be received froman external service

If a cancelApplication call is received, the validation ser-vice is instructed to cancel the validation («send&receive»),and the status service is notified that the application hasbeen canceled («send»). If, on the other hand, the studentchose to complete the application, the uploaded documentsare retrieved from the uploadService with a synchronous«send&receive» and a final validation is requested fromthe ApplicationValidator, using the completeValidation call(synchronous, «send&receive»). If the result is okay, the stu-dent is registered at the studentOffice with registerStudent(«send»). In any case, the initial call is replied to with a«reply» action.

Besides the normal flow of the activity, the diagram alsoshows a second structured activity node—a compensationhandler. The actions defined within CompensationHandlerare executed if the main activity has been completedsuccessfully, but needs to be undone. This functionality canbe triggered externally after the orchestration has been com-pleted. If the application has been completed successfullybefore, the student is removed from the list of applicants byusing a deregisterStudent call on the officeService.

Note that the activity diagram in Fig. 4 makes use of twodistinct sets of stereotypes. The first set of stereotypes ispart of the UML4SOA profile as defined above – i.e., the«send», the «receive», the «send&receive» and the «reply»stereotypes. The second set of stereotypes in Fig. 4 is part ofthe OMG MARTE profile, for example the «PaStep» or the«GaWorkloadEvent» stereotypes. Those are used for perfor-mance evaluation and will be discussed in the next section.

The second activity diagram, modeling the Application-Validator, is shown in Fig. 5. This service acts as supplier to

the creation service, starting with the receipt of the startVali-dation call («receive») from the ApplicationCreator throughthe validationService port. Afterwards, both the officeServiceand the admissionService are contacted simultaneously andsynchronously («send&receive») to check admission of thestudent, and to check the student data.

Subsequently, the process waits (using «receive») for thecompleteValidation call from ApplicationCreator. After it isreceived, all the information gathered so far is checked withthe help of the decisionService, and the result is returned via«reply» to the ApplicationCreator.

4 Enhanced modeling with non-functional properties

The previous section has shown how the UML4SOA profilemay be used to model (functional) static and dynamic aspectsof a service-oriented system. In this section we extend theUML4SOA modeling approach for non-functional proper-ties. We call the extension UML4SOA-NFP. First, we discussnon-functional aspects and standards of service-oriented sys-tems, then we present the modeling elements for the struc-tural and behavioral aspects and the corresponding stereo-types. Finally, non-functional properties of the case studyintroduced in Sect. 2 are modeled.

4.1 Non-functional aspects of services

Performance characteristics describe the timely behavior ofa service, such as response time, throughput, etc. Typicallyaverage and maximum/minimum values of these parameters

123


Fig. 4 UML4SOA activitydiagram showing theApplicationCreator

123


Fig. 5 UML4SOA activitydiagram showing theApplicationValidator

are defined in service-level agreements (SLAs). In this paper,we present an analysis method on service level performance,however, middleware characteristics (e.g. maximum trans-mission time) can also be considered.

Dependability characteristics describe the behavior of thesystem in the presence of faults. Availability refers to thereadiness of the service to be used while reliability of a ser-vice prescribes the capability of maintaining service quality(i.e., correct operation) [3].

Dependability can be defined at different levels in SOSs.Application level dependability describes requirements onthe component behavior while middleware level depend-ability is related to the (Web) service layer and the mes-

sage communication. The latter also hides the network levelproperties which can often change and typically are out of aservice engineer’s scope. UML4SOA-NFP can model bothlevels, however, the analysis and deployment methods pre-sented here target the middleware level.

Reliable messaging in the field of traditional distributed sys-tems is closely related to the guaranteed semantics of mes-sage delivery. Typical delivery modes are the following:

– At least once delivery. In the case of normal operation,every message is transferred at least once, with the possi-bility of sending multiple instances of the same message.

123


This can only be allowed in systems where this does nothave an undesired side-effect.

– At most once delivery guarantees that no message will besent multiple times to the receiver, but their successfultransmission is not ensured.

– Exactly once delivery is the strongest delivery semantics,guaranteeing both the successful message delivery (usu-ally acknowledgements are required for each message)and the filtering of duplicate messages.

The following low-level attributes are required for the con-figuration of reliable messaging (besides messagingSeman-tics, which selects the messaging mode as described earlier):

– inactivityTimeout: (integer, seconds), after this periodof time if no acknowledgment message has arrived, theconnection is closed;

– exponentialBackoff: (boolean), if it is set to true, timeamounts between retransmissions follow an exponentialdistribution;

– acknowledgementInterval: (integer, seconds), amountof time which should elapse before sending an acknowl-edgement message;

– retransmissionInterval: (integer, seconds), after thistime a request is resent by the client if no acknowledge-ment has arrived.

Security The notion of security covers properties related toconfidentiality (no unauthorized subject can access the con-tent of a message), integrity (the message content cannot bealtered), non-repudiation (which refers to the accountabilityof the communicating parties) and privacy (the identity andpersonal data of a client is not revealed to non-authorizedbodies). Concepts such as authentication (checking the iden-tity of a client) and authorization (checking whether a clientmight invoke a certain operation) are also of concern here.

In service-oriented systems, security should be guaran-teed between service endpoints, independently from networklevel properties. This can be achieved using secure web ser-vices middleware. Message security is based on digital sig-natures and encryption of messages; here we distinguishthe message header and body, however, further (application-specific) separation of message parts is also possible.

The following security parameters are used as a basis forconfiguration generation for secure communication middle-ware:

– encryptBody, encryptHeader, signBody, signHeaderdescribe whether a security method is applied on (partsof) messages between client and service respectively

– signAlgorithm and encryptionAlgorithm determinethe security algorithms

– authTokenType determines the type of the securitytoken (e.g. username or binary)

– useTimestamp allows the user to specify timestamps formessages

Note that the executable set of security configurations isrestricted in current middleware to certain combinations ofthe above parameters, therefore we propose default values inthe profile which conform to the actual deployment possibil-ities.

4.2 Extending structural models with non-functionalproperties

This section describes the UML extension for modeling non-functional parameters related to structural models of ser-vices. On the one hand, these models rely upon the GeneralResource Model (which is part of the UML Profile for Sched-ulability and Time [32]) and UML Profile for Modeling QoSand Fault Tolerance Characteristics and Mechanisms [33].However, the way UML4SOA-NFP handles these parametersalso conforms to the service management of typical businessapplications using Service Level Agreements (SLA).

A metamodel for non-functional properties. Figure 6 showsthe metamodel of non-functional concepts and their relation-ships. For each additional concept we define a UML stereo-type.

Since in real service configurations, service properties canvary for different classes of clients, we follow a contract-based approach, where non-functional properties of servicesare defined between two «Participant» components, namely,the service provider and the service requester. These con-tracts are modeled by «nfContracts».

Different non-functional aspects (performance, security,etc.) are modelled in corresponding «nfCharacteristics»which group different properties (e.g., response time) in«nfDimensions» (where a «runTimeValue» is associated toeach dimension). The reason for creating separate classesfor measureable values instead of actually storing them inattributes is to correlate real SLAs where most parametersare typically bound to a range of allowed values. Moreover,concepts like average values, deviation, etc. need to be mod-eled in a uniform way.

During a negotiation process, participants create an agreedcontract of their provided and requested contract specifica-tions.

Finally, properties of services need to be monitored atruntime (modeled as «monitor») either by the participatingparties or by involving a separate entity.

Modeling non-functional properties in UML4SOA-NFP. Onthe UML class level, each contract is modelled using a UML

123


Fig. 6 Metamodel ofnon-functional extension

NFContract

NFCharcteristic

Participant

NFDimension

ServiceInterface

RunTimeValue

Monitor

monitors

1..*

*

*-requester

1

values

1..*

*-provider

*

monitoredContract

* *

-agreed*

-dimensions1..*

-guaranteedCharacteristiscs1..*

Table 4 UML4SOA-NFP profile

UML4SOA-NFP metaclass Stereotype UML metaclass Description

NFContract «nfContract» Class Represents a non-functional contract between a serviceprovider and a service requester

NFCharacteristic «nfCharacteristic» Class Represents a non-functional aspect such as performance,security, reliable messaging, etc.

NFDimension «nfDimension» Class Groups non-functional properties within a non-functionalaspect (characteristics)

RunTimeValue «runTimeValue» Attribute An actual non-functional property

Monitor «monitor» Class A run-time service to monitor a contract (not used in the paper)

class with the stereotype «nfContract». Each characteristic(tagged by «nfCharacteristic») is another UML class associ-ated to the respective contract. Each dimension is also definedby a UML class stereotyped as «nfDimension». The actualruntime values of each dimension are defined as UML prop-erties. Stereotype usage is summarized in Table 4.

The actual non-functional parameters within a contractare set by using an object diagram instantiating these classes(and attributes).

Modeling non-functional properties of the eUniversity. Fig-ure 7 illustrates how the non-functional requirements pre-sented in Sect. 2 are captured in a UML4SOA model bydefining a non-functional contract between ApplicationCre-ator and ApplicationValidator.

The requirements of Sect. 2 are mapped to three «nfChar-acteristics», namely Performance, Reliable Messaging andSecurity (as discussed in Sect. 4.1).

– Performance aspects include two «nfDimension»elements, namely response time and throughput.Throughput definition consists of defining a guaran-teed throughput and a maximal throughput, while for

response time, the contract contains an average valueand a maximum value.

– Reliable messaging parameters first contain the requiredmessage semantics by stating whether acknowledgementis required or duplicate messages are allowed. Timingdimensions include the timeout for considering a mes-sage lost and the retransmission interval.

– Security aspects are composed of dimensions encryp-tion, digital signature, timestamp and authentication. Inour example, the latter is simplified to contain only theauthentication token type.

A concrete non-functional service configuration (on theobject level) is shown in Fig. 8. This instantiates Fig. 7,and assigns concrete values to the run-time values of non-functional parameters.

For instance, MsgSemanticsInstance prescribes that eachmessage between the two orchestrators needs an acknowl-edgement and the system can resend each message at mostthree times. Moreover, duplicate messages also need tobe filtered. On the security level, timestamps are requiredto be used (TimestampInstance), while users are authen-ticated by their username (AuthenticationInstance). Later,

123


Fig. 7 Elements of the contractbetween ApplicationCreationand ApplicationValidationservices

<<nfCharacteristics>>ReliableMessagingCharacteristics

<<nfCharacteristics>>PerformanceCharacteristics

<<nfCharacteristics>>SecurityCharacteristics

<<nfContract>>CreationValidationContract

+guaranteedThroughput : Integer+maxThroughput : Integer

<<nfDimension>>Throughput

+timeout : Integer+retransmissionInterval : Integer

<<nfDimension>>Timing

+needsAck : Boolean+filterDuplicates : Boolean+maxNumberofRetrans : Integer

<<nfDimension>>MsgSemantics

+encryptAlgorithm : String+encryptBody : Boolean+encryptSignature : Boolean+encryptHeader : Boolean

<<nfDimension>>Encryption

+averageRespTime : Integer+maxRespTime : Integer

<<nfDimension>>ResponseTime

+useTimestamp : Boolean

<<nfDimension>>Timestamp

+signBody : Boolean+signHeader : Boolean+signAlgorithm : String

<<nfDimension>>DigitalSignature

+authToken : String

<<nfDimension>>Authentication

these reliable messaging and security specifications will beused by deployment transformations of Sect. 6.

4.3 Extending behavior models with non-functionalproperties

We make use of the MARTE profile for to annotate UMLmodels with non-functional properties required for perfor-mance evaluation. In addition to being useful for documen-tation purposes, these models will be subject to automaticextraction of quantitative estimates.

Performance models offer insights into the dynamicunderstanding of complex service-oriented systems whichare complementary to those which can be obtained throughmeasurement and profiling. Measurement allows us to under-stand the system as it is today: modeling allows us to under-stand how it could be tomorrow. Predictive performancemodeling considers alternative designs or improvements, andevaluates these to identify the adaptation of the system whichwill give the greatest improvement with respect to a givenperformance goal (such as reducing response time). Mea-

surement and modeling are intimately linked because accu-rate measurement provides the parameter data which modelsneed in order to make valuable predictions.

In order to build a coherent performance model for per-formance analysis we must describe the workload placed onthe system and the cost of the individual units of execution(activities) which make up the events of the model. Perfor-mance evaluation may be carried out on activities stereotypedwith «GaScenario». Its cause property allows the extrac-tion of workload specification, stereotyped with «GaWork-loadEvent». Closed patterns are supported, which define theworkload as a population of users which interpose somethinking time between successive, cyclic executions of theactivity. Workloads (defined by «GaWorkloadEvent») in thefollowing form are accepted:

pattern = closed(population=M,

extDelay=(exp(1/r),s))

which indicates a closed workload of M users whichcyclically execute the activity. An exponentially distributed

123


Fig. 8 Instance model withnon-functional properties

<<nfCharacteristics>>performanceCharacteristicsInstance :

PerformanceCharacteristics

<<nfCharacteristics>>reliableMessagingCharacterists :

ReliableMessagingCharacteristics

<<nfContract>>creationValidationContractInstance2

: CreationValidationContract

<<serviceInterface>>ApplicationValidatorServiceInstance

: ApplicationValidationService

<<participant>>ApplicationValidatorInstance

: ApplicationValidator

securityCharacteristicsInstance : SecurityCharacteristics

<<nfCharacteristics>>

<<participant>>ApplicationCreatorInstance :

ApplicationCreator

retransmissionInterval = 10000timeout = 60

<<nfDimension>>timingInstance : Timing

averageRespTime = 4maxRespTime = 8

<<nfDimension>>responseTimeInstance :

ResponseTime

guaranteedThroughput = 10maxThroughput = 20

<<nfDimension>>ThroughputInstance :

Throughput

encryptAlgorithm = "default"encryptBody = trueencryptHeader = falseencryptSignature = false

<<nfDimension>>encryptionInstance :

Encryption

filterDuplicates = truemaxNumberofRetrans = 3needsAck = true

<<nfDimension>>msgSemanticsInstance :

MsgSemantics

authToken = "username"

<<nfDimension>>authenticationInstance :

Authentication

signAlgorithm = "default"signBody = truesignHeader = false

<<nfDimension>>digitalSignatureInstance

: DigitalSignature

useTimestamp = true

<<nfDimension>>timestampInstance :

Timestamp

providerrequester

agreed

thinking time with mean duration 1/r seconds is interposedbetween successive requests.

The atomic units of execution are stereotyped with «Pa-Step». To denote the amount of time taken by a step we use itshostDemand attribute. Meaningful applications will typicallyhave hostDemand = (exp(<time>), s) to indicatean exponentially distributed delay with mean <time> sec-onds. The execution rate of an action will be extracted fromthe «PaStep» application.

The use of these stereotypes can be observed in the activitydiagrams of ApplicationCreator (Fig. 4) and ApplicationVal-idator (Fig. 5).

5 Early estimation and evaluation of non-functionalproperties

For the quantitative analysis of non-functional service attri-butes, the timed process algebra PEPA can be employed as

the intermediate formalism derived from UML models ofservices annotated with UML4SOA and MARTE. The cur-rent section provides a brief (and high-level) overview ofhow formal performance models are derived from servicemodels with a special focus on insights gained by analysisspecific to our case study. For a detailed presentation of thetransformation, the reader is referred to [40].

5.1 Overview of PEPA

5.1.1 Language elements

PEPA is a formal language which allows the definition ofmodels as a composition of interacting automata (sequentialcomponents). Sequential components may carry out activi-ties independently of the rest of the system, or in cooperation(i.e., synchronization) with other automata. The operatorssupported by the language are informally introduced below.For a complete formal definition the reader is referred to [21].

123


Prefix (α, r).P denotes a process which performs anaction of type α and behaves as P sub-sequently.

Choice P + Q specifies a component which behaveseither as P or as Q. The activitiesof both operands are enabled andthe choice will (stochastically) behaveas the component which first com-pletes.

Constant Adef= P is used for recursion. Cyclic defini-

tions are central in the characterisa-tion of the underlying continuous-timeMarkov chain derived from a PEPAmodel.

Cooperation P ��L

Q is the compositional operator of PEPA.Components P and Q synchronizeover the set of action types in set L;other actions are performed indepen-dently. For example, (α, r1).(β, s).P��{α} (α, r2).(γ, t).Q is a composition

of two processes which execute α

cooperatively. Then, they performaction β and γ independently andbehave as P and Q, respectively.The operator ‖ is sometimes used asshorthand notation for a cooperationover an empty set, i.e., ��

∅ . Inde-pendent copies of a component areindicated by the notation P[N ] ≡P ‖ P ‖ · · · ‖ P︸︷︷︸

N

5.1.2 Rates of activities

An activity is associated with an exponential distributionwith mean duration 1/r time units. Generally distributedactivities can be obtained by using suitable phase-typedistributions, although these will not be discussed fur-ther in this paper. The symbol � specifies a passive ratewhich may be used to model unbounded capacity. Theduration of an activity involving passive rates is deter-mined by the active rate of the synchronizing compo-nents.

Cooperating components need not have a common viewof the duration of shared actions. The semantics of PEPAspecifies that the rate of a shared action is the slowest ofthe individual rates of the synchronizing components, e.g.,min(r1, r2) in the example above.

In order to carry out a quantitative analysis, PEPAmodels are interpreted as continuous-time Markov chains.In particular, in Sect. 5.5, we will give examples of anal-

ysis of the long-run behaviour of a system (steady-stateanalysis).

5.2 From UML activity models to PEPA

5.2.1 Overview of system equation and workload

The transformation from service models captured usingUML4SOA and MARTE profiles gives rise to a system equa-tion of the target PEPA model in the following form:

Systemdef= Workload ��

{α} A[K ]Here Workload represents the (abstract) behavior of M

independent users of an activity. An individual workloadcomponent is modeled as a two-state automaton

Thinkdef= (think, r).Start

Startdef= (α,�).Think (1)

where the passive activity (α,�) captures the fact that theaction type α represents the first unit of computation per-formed by the system, and the rate is determined by the othersynchronizing components. Thus, the overall PEPA sub-system for an array of M independent users is:

Workloaddef= Think[M]. (2)

The notation A[K] represents an array of concurrent flowsderived by a model transformation from UML activity dia-grams of service models, which is discussed below.

5.2.2 Basic transformation blocks

For space considerations, we only present a high-level over-view of the main blocks of the transformation (Fig. 9), andinterested readers are referred to [40] for further details.

5.2.3 PEPA model of the running example

The translation algorithm can be applied to the activity dia-grams in Figs. 4 and 5. The corresponding sub-systems ofthe performance model are shown in Figs. 10 and 11, respec-tively.

The model of ApplicationCreator, denoted by ACS::StartCreation, consists of a single sequential component withtwo choices ACS::Pick and ACS::CheckResult, correspond-ing to the decision nodes pick and d1, respectively. The modelof ApplicationValidator, denoted by AVS::StartVal, has twoconcurrent flows of execution. The second flow performs theaction checkData and synchronize with the first flow at nodesparallelFlowStart and parallelFlowEnd. Thus, the secondflow is mapped onto the three-state sequential componentevolving through local states AVS::Fork2, AVS::CheckData,

123


Fig. 9 Overview ofUML-to-PEPA transformation

and AVS::Join2. Additional (message buffer) componentswill be discussed in the sequel.

5.3 Handling interaction between orchestrators

Now we aim at capturing the interplay between the twoorchestrations as specified by the stereotype applications ofUML4SOA. For this purpose, we model the transmission ofa message between two orchestrators using message buffers.Cooperation is modeled by exploiting the compositional-ity of the PEPA language as the core building blocks (dis-cussed in Sect. 5.2) are gradually extended by message buffercomponents.

In other words, our aim is to extract a PEPA model in theform:


L

(

ACS[K AC S] ��MBB[SB ] ��MC

C[SC ] · · ·)

��M

(

AVS[K AV S] ��MDD[SD] ��ME

E[SE ] · · ·)

where L contains the initial action executed in the sce-nario and the cooperation set M has the action typeswhich correspond to the exchange of messages between thetwo orchestrators. The core building blocks of a compo-nent are extended with components B, C, . . . and D, E, . . .,which model message buffers for asynchronous communi-cation between the two orchestrators ACS and AVS. Thesizes of the message buffers, i.e., SB, SC , SD, SE , . . . are

123


Fig. 10 PEPA model of ApplicationCreator

Fig. 11 PEPA model of ApplicationValidator

extracted from MARTE annotations. The cooperation setsMB,MC ,MD,ME , . . . contain the activities which causean asynchronous delay to be sent.

5.3.1 Extraction of message buffers

The components for message buffers are extracted from aComposite Structure diagram such as that in Fig. 2.

The transformation of an action node takes account ofthe input and output pins as well as the UML4SOA ste-reotype application to the node itself: «send», «receive»,«send&receive», or «reply».

If the «lnk» pin references an element which is notan orchestration, it is handled as an action node. That is,although the UML4SOA profile indicates communicationwith other participants the exchange is abstracted away withan atomic activity in the performance model, because theconcrete behaviour of the link is not available. Conversely,if «lnk» references an orchestrator Oi , then the messageexchange is modeled as a shared action between the twoactivities. The set of such shared action types is called theinterface of an activity, denoted by Ii . Interfaces will be usedduring the generation of the overall system equation. In thefollowing, we only describe the treatment of a pair of «send»and «receive» action nodes in detail.

«send» node Let O1 be the orchestrator which has a «send»node. The synchronizing orchestrator, O2, can be retrievedby the reference node.lnk. According to the semantics ofUML4SOA introduced in Sect. 3.3, the matching nodeof O2 must be stereotyped with either «receive» or with«receive&send». The algorithm also requires that the refer-ence of «rcv» in the receiving node be equal to the referenceof «snd» in the sending node. Thus a shared action type maybe constructed by inspecting node.lnk and node.snd. Thisshared action will be added to I1. The rate extracted fromthe application of «PaStep» indicates the local rate of theshared activity. Notice that the translation of the action nodedoes not require the traversal of the cooperating orchestra-tor’s activity. The pattern of transformation is shown in Fig. 9.

The UML4SOA profiles states that «send» indicatesasynchronous communication. In PEPA, this is captured byassociating a message buffer of finite size with each «send»node, and each place in the buffer is modeled as a two-statesequential component. The first state (i.e., Buff1) of the com-ponent observes the execution of the action that precedesthe asynchronous send. Observation is modeled as a pas-sive cooperation between a sender’s flow and a buffer place.The second state (i.e., Buff2) models the transmission tothe remote orchestrator. The non-blocking behavior of thesender’s flow is expressed by the fact that the flow is notinvolved in the transmission of the message—it behaves asthe process which follows the «send» node after the preced-ing activity is completed.

«receive» node A «receive» is blocking, hence the sharedaction denoting the communication with the remote

123


orchestrator is performed by the receiving flow. (see bot-tom component of Fig. 9). In this case the shared action typeis constructed by traversing the pins stereotyped with «rcv»and «lnk».

5.3.2 Communication between orchestrators

The communication of ApplicationCreator (see bottompart of Fig. 10) with the orchestrator ApplicationValida-tor (Fig. 11) is handled by three message buffers, i.e.,ACS::MBuffer1, ACS::MBuffer2, and ACS::MBuffer3. Thefirst state of the buffer observes the execution of one actionof the main flow, and the second state performs the transmis-sion of the message. The shared action types are named byusing the format lnk :: snd (similarly, lnk :: rcvis used for action nodes stereotyped with «receive»). Com-ponents ACS::CompValSnd and ACS::CompValRcv modelthe two-phase PEPA behavior of the node compVal, ste-reotyped with «send&receive». Notice that cooperationoccurs over distinct action types AVS::appDocs (send) andAVS::results (receive). The matching underlying sequentialcomponents of ApplicationValidator are AVS::CompValRcvand AVS::CompValRep, between which the independentaction checkReq is performed.

The overall system equation is


{rcvNewApp}

(

ACS ��M AVS

��{compensate} Compensator

)

(3)

where M = I(ACS) ∪ I(AVS) ∪ {compensate}, and

I(ACS) = I(AVS) = {AVS::application,

AVS::appDocs, AVS::results, AVS::cancel}.

5.4 Compensation and exception handling

Compensation and exception handling represent reactionsto adverse situations during the course of an orchestration.From a performance standpoint, these events can be treatedsimilarly—the current flow of control halts and passes on tosome handler which performs a series of activities to restorethe system. The performance model introduces failure in theorchestrations as activities competing with the business logicactivities. Failure activities are represented by a choice oper-ator which is added to all the local states of the PEPA sub-systems underlying the orchestrations.

When a failure occurs, the business logic flows of all theorchestrators are reset to their initial conditions (by synchro-nization of the flows over the failure action type) and thecontrol is passed on to a sequential component which mod-els the handler, according to the behavior described in thehandling scope. The failure rate is attached as a MARTEannotation to the edge which triggers the handler.

Fig. 12 PEPA model of Compensator

For our running example, the compensator sequentialcomponent (Fig. 12) is triggered by the execution of thecompensate action and is defined in Fig. 12.

5.5 Performance evaluation of the case study

To gain insight into the behavior of a system a common prac-tice is to carry out sensitivity analysis, which studies theimpact that certain parameters have on the overall perfor-mance. In this section, the performance metric of interestwill be steady-state throughput, which gives the frequencyat which an activity is performed in the system at equilib-rium. As with most performance studies, throughput analy-sis is a useful approach because it summarises effectively thedynamic behavior of the system, accounting for delays dueto fork/join synchronisation mechanisms, message passing,and computation cost associated with each basic activity ofthe system.

5.5.1 Sensitivity analysis: fixed rates, varying workload

An interesting sensitivity analysis is concerned with estab-lishing how varying workload intensities affect system-levelnon-functional parameters. For instance, in our case study asuitable index to be measured is the throughput of the actionappSuccess in the underlying PEPA model.

The set-up for workload analysis consists in the solutionof the model for increasing population levels of users, rep-resented by the array Think[M]. The analysis is specified byusing MARTE annotations in the UML model containing aroot activity stereotyped as «GaWorkloadEvent»:

pattern = closed(population=in:M,

extDelay=(exp(1/r),s))

where in:M indicates an input variable for the performancemodel, which is bound to an integer before the model isanalyzed. The performance metric is specified by settingthe following property in the «PaStep» application of nodeapplicationStatusSuccess:

throughput=out:appSuccessTh

Figure 13 shows a typical result for this form of analysis.Under low intensity, the throughput of the system increases

123


0 20 40 60 80 1000

5

10

15

20

25

30

35

Number of users

Thr

ough

put o

f app

Suc

cess

Fig. 13 Workload analysis studies how the user population affects per-formance of the system. Here, the performance metric of interest isthe steady-state throughput of processing applications to e-Universitycourses. Non-degrading performance is observed for population sizesless than 93

with the number of users. This is the behavior observedfor our model for M < 93. However, the system’s concur-rency levels cannot meet higher demands as the population isincreased further. This degradation corresponds in the graphto a flat throughput for 93 ≤ M ≤ 100.

5.5.2 Sensitivity analysis: fixed workload, varying rates

An orthogonal analysis approach may concern the sensitivityof the system performance to a specific activity rate. Here allthe other parameters of the system, including the workloadspecification, are fixed. The activity under study is variedacross a range of suitable rate values and the correspond-ing performance measures are calculated. In our example,the activity node checkProgramRequirements in Applica-tionValidator may play a crucial role. This activity is inter-posed between two nodes which represent communicationwith ApplicationCreator. Therefore ApplicationCreator isblocked during the course of the activity. Intuitively, one mayconclude that increasing the activity rate corresponds to anincrease in the system performance. Although this holds true,the relationship is not linear thus it is interesting to determinethe range of values in which the relative gain is the highest.

Figure 14 shows the sensitivity analysis of rcheckReq inthe interval [10,200] with respect to the previously discussedsystem throughput. Indeed, the graph reveals that an opti-mal relative gain is obtained for values around 50 and fur-ther increases—for instance, doubling the rate from 100 to200—yield smaller and smaller improvement. Similarly tothe previous case, sensitivity analysis may be specified inthe UML model by using the following property for the

0 50 100 150 20075

80

85

90

95

100

105

rcheckReq

Thr

ough

put o

f app

Suc

cess

Fig. 14 Sensitivity analysis of rcheckReq

«PaStep» application to node checkProgramRequirements:

hostDemand=(exp(1/in:r_checkReq),s)

6 Automating service deployment by modeltransformations

Due to the rapid increase in the number of available services,greater emphasis is put on their non-functional aspects asdescribed in Sect. 1. In order to meet such non-functionalrequirements, a service needs to be designed for reliability bymaking design decisions on an architectural level. However,this often conflicts with the current tool support for servicedevelopment which has a relatively low level of function-ality (merely creating appropriate XML descriptors, serviceconfiguration files, etc.).

Recently, the identification of non-functional parametersof services has been addressed by various XML-based stan-dards related to web services. As web service communicationassumes unreliable transfer by default, some standards (suchas WS-ReliableMessaging [49] and WS-Reliability [48]) aimat ensuring reliable message communication. Security-spe-cific configuration parameters are described in the WS-Secu-rity standard [45]. A brief summary of the contents of thesestandards were provided in Sects. 4.1 and 4.2.

Unfortunately, the manual creation of such service con-figuration files is typically an error-prone task during thedeployment of services as XML parsers do not protect usagainst setting a syntactically correct but semantically incor-rect value within a configuration file. Moreover, web servicesstandards capture different subsets of non-functional param-eters making even closely related standards incompatiblewith each other. Furthermore, unsurprisingly, each specificmiddleware implements the standard slightly differently.

123


In addition to that, non-functional properties are captured at alow implementation-level by using dedicated XML deploy-ment descriptors. As a consequence (i) service configura-tions cannot be designed at a high architectural level and (ii)the portability of service configurations is problematic. Asthe support of non-functional aspects in service platforms ischanging rapidly, we propose an approach compliant with theModel-Driven Architecture (MDA) principles for the deploy-ment of service configurations [24].

6.1 Target deployment languages and transformation flow

For this purpose, we created PIM2PSM and model-to-codetransformations to facilitate service development for reli-able and secure middleware. These transformations currentlyhandle reliable message communication and security in ser-vice-oriented systems. Our transformation suite enables theautomated generation of structural service descriptors anddeployable policy files which determine the runtime behav-ior of services w.r.t. reliability and security requirements. Itsmodular implementation allows for future extension in othernon-functional domains (e.g., logging) and other service plat-forms (e.g., SCA) as well. Standards-compliant non-func-tional service configurations make it necessary to synthesizeone or more XML configuration files as deployment descrip-tors.

The actual model transformations can be realized throughseveral steps. Below we exemplify one possible workflowfor obtaining the models in the complex chains of modeltransformations.

– PIM models: The input of the chain is a standard UML2model developed using EMF and serialized as XMI,which uses the UML4SOA(-NFP) Profile.

– PSM models: After the extraction of relevant modelparts, internal service models are generated withinthe model transformation tool (describing core ser-vices «SOA model», reliable messaging setup «SOA RMmodel», security «SOA security», etc.). These are thenprocessed in order to create descriptor models (e.g.«WSDLmodel», «RAMP model», «Sandesha model»)which conform to industrial standards. These can be con-sidered as PIM2PSM mappings in the MDA terminology.

– Target XML files: These descriptor models are the basisof XML file generation. These files are directly usable asconfiguration descriptors on standard platforms. Besidesthe server-side configuration XMLs (namely one for reli-able messaging and one for security aspects), WSDL filesof the services are also created. These are PSM2CODEtransformations.

– Glue code for deployment: In case of the Apache Axisplatform, deployable server-side projects are also created

by Java applications. These have to be extended with theimplementation (source files) of the services.

An overview of the core model transformation problem forderiving server-side configuration files of the Apache plat-form is presented with a description of transformation steps inFig. 15. The trace model we use creates connections betweensource and target elements (objects) in the form of typed rela-tions to ease transformation development. Moreover, suchmodels also can be used to trace requirements from the high-level models to the code.

This transformation scheme is uniformly applicable to dif-ferent «nfCharacteristics» (with minor adjustments to handlenames of elements in case of «$name»). As a further techni-cal detail, it is worth pointing out that certain default valuescan be set by the transformation itself (i.e. the source UMLmodel does not need to contain them as in case of «expo-nentialBackoff »). Finally, certain configuration parametersin the model might not be required by the underlying mid-dleware.

6.2 Transformation implementation in VIATRA2

Transformations were implemented in the VIATRA2framework [42] which is a modular, open source modeltransformation framework built on Eclipse, which supportsthe efficient design and execution of model transformations.Transformations are defined by graph transformation rules(i.e., declarative description of model patterns) and AbstractState Machines, which provide an intuitive yet precise way ofcapturing complex transformations. The choice of the VIA-TRA2 framework can also be explained by the support forgeneric transformations [43], which significantly reduces thenumber of transformation rules.

The transformation implementation process for ourdeployment transformations consists of the following con-ceptual steps:

1. Create metamodels for source and target domain. Anexample is the domain of UML as source domain and asimple representation of services, connections and reli-able messaging constraints as target.

2. Graph patterns describe fragments of directed, typedgraphs which represent a coherent unit of the model(e.g., a service with a specification). “Atomic units” oftransformations will be encoded in such patterns.

3. Graph transformation provides a high-level rule andpattern-based manipulation language to implement basicmappings between graphs. See e.g. [14] for a detaileddefinition of the semantics of graph transformations.

4. Complex transformations can be assembled usingAbstract State Machine [8] rules defined on graph

123


Fig. 15 Overview of deployment transformations

patterns and transformation rules (e.g. “Create a portin a WSDL document for all ports of a service”).

6.3 Derived deployment descriptor for the eUniversity casestudy

Figure 16 shows an extract of the deployment descrip-tor («services.xml») file of the ApplicationCreation servicederived by our model transformation. This configuration filedescribes the security and reliable messaging characteristicsof the provided service. The generation of the actual XMLdocument is based upon the source model of Fig. 7 and thetransformation rules of Fig. 15.

This configuration file is an extract of a WS-Policy-compliant descriptor which can be parsed by any Web servicestack implementation which adheres to WS-Policy, WS-Security and WS-ReliableMessaging standards (although areference is included to Apache’s Sandesha reliable mes-

saging platform, no semantic restrictions apply to the pol-icy). Parameters in the configuration file are related to oneWeb service port. Boolean attributes which are marked inthe model as true will be mapped to policy elements whileconcrete values (such as retransmission interval) will befilled with the specified value, respectively. Some techni-cal details have been suppressed (such as schema URI).(ExactlyOne here refers to the policy semantics and not themessaging mode.) Note that this target language is exten-sible (e.g. logging can added easily) due to the nature ofWS-Policy.

Note that according to the implementation of WS-Secu-rity standard (Rampart module), if a service is available via asecure connection, it cannot be accessed in plain text mode,moreover, the security settings (e.g. authentication token)of a port must be fixed. This implies that for clients withdifferent security requirements, the service should be avail-able at different URIs. Currently, the transformation creates

123


<?xml version='1.0'?><service name="ApplicationValidationService">

<operations></operations><wsp:Policy wsu:Id="ApplicationValidationServiceSecurityPolicy"

xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"

xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">

<wsp:ExactlyOne><wsp:All>

<sp:Authenticationxmlns:sp="http://schemas.xmlsoap.org/ws/

2005/07/securitypolicy"><wsp:Policy>

<wsp:authToken><wsp:Policy>

<sp:Username/></wsp:Policy>

</wsp:authToken></wsp:Policy>

</sp:Authentication><sp:Encryption ...

<wsp:Policy><wsp:encryptBody/><wsp:encryptAlgorithm><wsp:Policy>

<sp:Default/></wsp:Policy>

</wsp:encryptAlgorithm></wsp:Policy>

</sp:Encryption><sp:DigitalSignature ...

<wsp:Policy><wsp:signBody/><wsp:signAlgorithm><wsp:Policy>

<sp:Default/></wsp:Policy>

</wsp:signAlgorithm></wsp:Policy>

</sp:DigitalSignature><sp:Timestamp ..

<wsp:Policy><wsp:useTimestamp/>

</wsp:Policy></sp:Timestamp>

</wsp:All></wsp:ExactlyOne>

</wsp:Policy><wsp:Policy wsu:Id="ApplicationValidationServiceRMPolicy"xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"xmlns:wsrm="http://ws.apache.org/sandesha2/policy"><wsp:ExactlyOne>

<wsp:All><wsrm:filterDuplicates>true</wsrm:filterDuplicates><wsrm:needsAck>true</wsrm:needsAck><wsrm:maxNumberOfRetrans>3</wsrm:maxNumberOfRetrans><wsrm:retransInterval>10000</wsrm:retransInterval><wsrm:timeout>60</wsrm:timeout>

</wsp:All></wsp:ExactlyOne>

</wsp:Policy></service>

Fig. 16 Fragments of services.xml of ApplicationCreation service

a separate URI for every client–server (participant) pair withnon-functional specifications.

7 Related work

The development of service-oriented systems has recentlygained a lot of attention, and several approaches for mod-eling, generating and analyzing these software systemshave been published or announced. However, most of theseapproaches focus mainly on functional requirements of SOSwhile non-functional aspects are neglected. We present the

related work grouping them into the topics of modeling, per-formance analysis and deployment techniques.

7.1 UML modeling approaches

Several other attempts exist to define UML extensions forservice-oriented systems and some approaches also are usedfor the automated transformation from UML to BPEL. Mostof them, however, do not cover all three aspects types ofmodel elements for structural, behavioral and non-functionalaspects of SOAs. For example the UML 2.0 profile for soft-ware services [22] provides an extension for the specifica-tion of services addressing only structural aspects. Similarly,the current version of the UML profile and metamodel forservices (SoaML) [36] supports the structural concepts ofservice components, service specifications, service interfacesand contracts for services. SoaML is the result of the stan-dardization efforts started by the OMG in 2006. The UMLextension for service-oriented architectures described byBaresi et al. [6] focuses mainly on modeling SOAs by refiningbusiness-oriented architectures. The refinement is based onconceptual models of the platforms involved as architecturalstyles, formalized by formal graph transformation systems.The extension is also limited to stereotypes for the structuralspecification of services.

Other modeling approaches require very detailed UMLdiagrams from designers trying to force service-oriented lan-guages (like BPEL) on top of UML in order to facilitateautomated transformation from UML to BPEL. For exam-ple, the work of Skogan et al. [20] has a similar focus to ourapproach, i.e. a model-driven approach for services based onUML models. However, the approach lacks an appropriateUML profile preventing building models at a high level ofabstraction; thus producing overloaded diagrams. Anotherexample is the very detailed UML profile [2] that introducesstereotypes for almost all BPEL 1.0 activities—even for thosealready supported in plain UML, which makes the diagramsdrawn with this profile hard to read. Some other extensionsdo not cover vital parts of service orchestrations such as com-pensation handling, e.g. the UML profile described in [28].In a recently published article, Ermagan and Krüger [15]extend the UML2 with components for modeling services.Collaboration and interaction diagrams are used for model-ing the behavior of such components. Neither compensationnor exception handling is explicitly treated in this approach.

Approaches addressing modeling of non-functional prop-erties of services are quite rare. Examples are the OMGMARTE profile [35], and the extension proposed by Wadaet al. [44], but conversely to the profile we presented in thiswork, none of them provides a “per contract” approach. Con-versely to these approaches, UML4SOA(-NFP) focuses onthe improvement of the expressive power of UML by defin-ing a small set of stereotypes for structural and behavioral

123


aspects of SOAs, focusing on service-oriented features asorchestrations and the non-functional aspects of service-ori-ented systems as shown in this article. For a more thoroughdiscussion of UML4SOA, see [16].

7.2 Methods for analyzing non-functional properties

Performance evaluation of software models has gainedincreased attention over the last decade (see [5] for a review ofthis field). Given the centrality of the UML, many approacheshave dealt with the extraction of performance models fromactivity diagrams [10,27], sequence diagrams [7] and statemachine diagrams [31]. The use of an intermediate meta-model to facilitate these translations has been proposed in[37,47], in which concrete application to layered queueingnetworks and stochastic Petri nets have been given. A workclosely related to ours is [12], in which the performance pre-diction of service compositions is carried out on BPEL mod-els. A BPEL workflow is expressed as a single annotatedactivity diagram, which is translated into a layered queueingnetwork for the analysis. The semantics of the translationand the profiles used for the performance annotations arevery similar, however our work extends the scope of applica-bility of performance prediction to a more general scenario inwhich interdependency between orchestrations is taken intoaccount.

Alternatively to formal analysis models, the dependabilityand robustness of services can be also investigated by usingfault injection techniques as discussed in [26]. The authorsof [25] use monitoring and testing techniques to evaluate thedependability of web services by using statistical real-timedata. [1] aims to develop a dependable web services frame-work, which relies on extended proxies. However, this needsa modification at the client side in order to handle exceptionsand find new service instances. Moreover, the reconfigurationof client side proxies uses non-standard WSDL extensionswhile we concentrated on standards-compliant solutions.

7.3 Deployment mechanisms for non-functional properties

A framework for automated WSDL generation from UMLmodels is described in [41], using the UML extensions ofMIDAS [9]. In [19], web service descriptions are mapped toUML models, and (after using visual modeling techniques)a composite service can be created for which the descriptoris automatically generated. However, none of these worksconsiders non-functional properties of web services.

Non-functional aspects of e-business applications are dis-cussed among others in [4], having some description ofdeployment optimization for J2EE applications, but withoutdiscussing details of model-based deployment. Integration ofnon-functional aspects in the development by model trans-formations is also investigated in [11,38] and [23], focusing

on parts of the engineering process, although using differentunderlying transformation techniques for model analysis anddeployment. An early version of the deployment transforma-tion suite was presented in [17].

8 Conclusions and future work

Despite the advantage of coherent, separable componentswith well-defined interfaces, service-oriented systems canbecome as complex as any other. For this reason, model-driven development is invaluable in the creation and mainte-nance of service-oriented systems. High-level models allowus to retain intellectual control of complex systems whichwould otherwise defeat our attempts to understand them ineither static or dynamic terms. Making these models an inte-gral part of the development process means that they growand change as the system grows and changes and they areavailable to support the extension and adaptation of the sys-tem in response to perceived need or demand.

While model-driven development has gained great accep-tance in documenting the static structure of systems in termsof components, packages, classes and interfaces, modeling offunctional properties has received less attention and model-ing of non-functional properties has received much too little.Non-functional properties such as responsiveness, availabil-ity, scalability and security have a direct impact on whetherthe system is accepted and valued by end users. In contrast,the internal organization of the codebase into packages andclasses is entirely invisible and irrelevant to end users. Fromthis perspective the current emphasis on modeling of staticsoftware structure seems misplaced, to say the least.

In this paper, we have presented a model-driven approachfor the development of service-oriented systems with explicitsupport for the specification of non-functional properties.Our main contributions are

– the ability to specify non-functional properties rightwithin the model of the SOA system, enabling model-ing of performance and security,

– model-based support for performance analysis, in partic-ular performance estimates and reliability analysis, basedon the timed process algebra PEPA,

– and the introduction of deployment mechanisms thatcomprise model-to-model and model-to-text transforma-tions.

We also created a method for analyzing the performability-reliability versus performance of services with non-func-tional parameters as described in [18], but which is notincluded in this work.

We plan to extend the current UML4SOA-NFP approachto cover system’s reliability at architecture level. Future work

123


will necessarily encompass further validation of the approachpresented against larger projects. We plan to apply it to morecomplex case studies in collaboration with industry.

References

1. Alwagait, E., Ghandeharizadeh, S.: DeW: a dependable web ser-vices framework. RIDE 01, 111–118 (2004)

2. Amsden, J., Gardner, T., Griffin, C., Iyengar, S.: Draft UML1.4 Profile for Automated Business Processes with a Map-ping to BPEL 1.0. Specification, IBM. http://www.ibm.com/developerworks/rational/library/content/04April/3103/3103_UMLProfileForBusinessProcesses1.1.pdf (2003), Last visited:10.12.2008

3. Avizienis, A., Laprie, J.-C., Randell, B., Landwehr, C.: Basic con-cepts and taxonomy of dependable and secure computing. IEEETrans. Dependable Secure Comput. 1(1), 11–33 (2004)

4. Balogh, A., Varró, D., Pataricza, A.: Model-based optimization ofenterprise application and service deployment. In: ISAS, pp. 84–98, (2005)

5. Balsamo, S., Marco, A.D., Inverardi, P., Simeoni, M.: Model-basedperformance prediction in software development: a survey. IEEETrans. Softw. Eng. 30(5), 295–310 (2004)

6. Baresi, L., Heckel, R., Thöne, S., Varró, D.: Style-based modelingand refinement of service-oriented architectures. J. Softw. Syst.Model. (SOSYM) 5(2), 187–200 (2005)

7. Bernardi, S., Donatelli, S., Merseguer, J.: From UML sequencediagrams and statecharts to analysable Petri Net models.In: Inverardi, P., Balsamo, S., Selic, B. (eds.) Proceedings ofthe Third International Workshop on Software and Performance,pp.35–45. ACM, Rome, Italy, (2002)

8. Börger, E., Stärk, R.: Abstract State Machines. A Method for High-Level System Design and Analysis. Springer, Berlin (2003)

9. Caceres, P., Marcos, E., Vera, B.: A MDA-based approach for webinformation system development. In: Workshop in Software ModelEngineering (WiSME@UML2003) (2003)

10. Canevet, C., Gilmore, S., Hillston, J., Kloul, L., Stevens, P.: Ana-lysing UML 2.0 activity diagrams in the software performanceengineering process. In: Dujmovic, J.J., et al. (eds.) Proceedings ofthe Fourth International Workshop on Software and Performance,WOSP 2004, Redwood Shores, California, USA, January 14–16,2004, pp. 74–78 (2004)

11. Cortellessa, V., Marco, A.D., Inverardi, P.: Software performancemodel-driven architecture. In: SAC ’06: Proceedings of the 2006ACM symposium on Applied computing, pp. 1218–1223. ACMPress, New York (2006)

12. D’Ambrogio, A., Bocciarelli, P. : A model-driven approach todescribe and predict the performance of composite ser-vices. In: Cortellessa, V., Uchitel, S., Yankelevich, D. (eds.)WOSP, pp. 78–89. ACM, New York (2007)

13. Dujmovic, J.J., Almeida, V.A.F., Lea, D. (eds.): Proceedings ofthe Fourth International Workshop on Software and Performance,WOSP 2004, Redwood Shores, California, USA, January 14–16,2004. ACM, New York (2004)

14. Ehrig, H., Engels, G., Kreowski, H.-J., Rozenberg, G. (eds.):Handbook on Graph Grammars and Computing by Graph Trans-formation, volume 2: Applications, Languages and Tools. WorldScientific, Singapore (1999)

15. Ermagan, V., Krüger, I.: A UML2 profile for service modeling. In:International Conference on Model Driven Engineering Languagesand Systems. LNCS, vol. 4735, IEEE, pp. 360–374. Springer,Berlin (2007)

16. Foster, H., Göczy, L., Koch, N., Mayer, P., Montangero, C., Varró,D.: D1.4b: UML for Service-Oriented Systems. Specification,SENSORIA Project 016004 (2010)

17. Gönczy, L., Ávéd, J., Varró, D.: Model-based deployment ofweb services to standards-compliant middleware. In: Isaias, P.,Nunes, M.B., Martinez, I. (eds.) Proceedings of WWW/Internet2006(ICWI2006). Iadis Press (2006)

18. Gönczy, L., Déri, Z., Varró, D.: Model-Based Performability Anal-ysis of Service Configurations with Reliable Messaging. In: Koch,N., Vallecillo, A., Houben, G.-J. (eds.) Proceedings of the ModelDriven Web Engineering (MDWE), CEUR, vol. 389 (2008)

19. Grønmo, R., Skogan, D., Solheim, I., Oldevik, J.: Model-DrivenWeb Services Development. In: Proceedings of the IEEE Inter-national Conference on e-Technology, e-Commerce and e-Service(EEE’04), pp. 42–45. IEEE, Los Alamitos, CA, USA (2004)

20. Gronmo, R., Skogan, D., Solheim, I., Oldevik, J.: Style-based mod-eling and refinement of service-oriented architectures. In: EighthIEEE International Enterprise Distributed Object Computing Con-ference (EDOC’04), IEEE, pp. 47–57. IEEE (2004)

21. Hillston, J.: A Compositional Approach to Performance Model-ling. Cambridge University Press, Cambridge (1996)

22. Johnson, S.: UML 2.0 Profile for Software Services. Specifica-tion, IBM (2005) http://www.ibm.com/developerworks/rational/library/05/419_soa, Last visited: 10.12.2008

23. Jonkers, H., Iacob, M.-E., Lankhorst, M.M., Strating, P.: Integra-tion and Analysis of Functional and Non-Functional Aspects inModel-Driven E-Service Development. In: EDOC, pp. 229–238(2005)

24. Kelly, S., Tolvanen, J.-P.: Domain-Specific Modeling. Wiley-Interscience, IEEE Computer Society, USA (2008)

25. Li, P., Chen, Y., Romanovsky, A.: Measuring the Dependability ofWeb Services for Use in e-Science Experiments. In: Penkler, D.,Reitenspieß, M., Tam, F. (eds.) Service Availability, Third Interna-tional Service Availability Symposium, ISAS 2006, Helsinki, Fin-land, May 15–16, 2006, Revised Selected Papers. Lecture Notes inComputer Science, vol. 4328, pp. 193–205. Springer, Berlin (2006)

26. Looker, N., Xu, J.: Dependability assessment of grid middleware.In: Proceedings of the 37th Annual IEEE/IFIP International Con-ference on Dependable Systems and Networks, DSN 2007, 25–28June 2007, Edinburgh, UK, pp. 125–130. IEEE Computer Society,USA (2007)

27. López-Grao, J.P., Merseguer, J., Campos, J.: From UML ActivityDiagrams to Stochastic Petri Nets: Application to Software Perfor-mance Engineering. In Dujmovic, J.J., et al. (eds.) Proceedings ofthe Fourth International Workshop on Software and Performance,WOSP 2004, Redwood Shores, California, USA, January 14-16,2004, pp. 25–36 (2004)

28. Mantell, K.: From UML to BPEL. Specification, IBM. http://www.ibm.com/developerworks/webservices/library/ws-uml2bpel/(2005). Last visited: 10.12.2008

29. Mayer P., Schroeder A., Koch N.: A model-driven approach toservice orchestration. In: SCC’08, IEEE, pp. 1–6. IEEE, USA(2008)

30. Mayer, P., Schroeder, A., Koch, N.: MDD4SOA: model-driven ser-vice orchestration. In: The 12th IEEE International EDOC Con-ference (EDOC 2008), pp. 203–212. IEEE Computer Society,Munich, Germany (2008)

31. Merseguer, J., Bernardi, S., Campos, J., Donatelli, S.: A compo-sitional semantics for UML state machines aimed at performanceevaluation. In: Silva, M., Giua, A., Colom, J. (eds.) Proceedingsof the 6th International Workshop on Discrete Event Systems,pp. 295–302. IEEE Computer Society Press, Zaragoza, Spain(2002)

32. Object Management Group: UML Profile for Schedulabili-ty, Performance and Time Specification. http://www.omg.org/technology/documents/formal/schedulability.htm (2005)

123

http://www.ibm.com/developerworks/rational/library/content/04April/3103/3103_UMLProfileForBusinessProcesses1.1.pdf



http://www.ibm.com/developerworks/rational/library/05/419_soa

http://www.ibm.com/developerworks/rational/library/05/419_soa

http://www.ibm.com/developerworks/webservices/library/ws-uml2bpel/

http://www.ibm.com/developerworks/webservices/library/ws-uml2bpel/

http://www.omg.org/technology/documents/formal/schedulability.htm

http://www.omg.org/technology/documents/formal/schedulability.htm


33. Object Management Group: UML for Modeling Quality of Serviceand Fault Tolerance Characteristics and Mechanisms, v1.1. http://www.omg.org/spec/QFTP/1.1/ (2008)

34. Object Management Group (OMG). Unified Modeling Language:Superstructure, version 2.1.2. Specification, OMG. http://www.omg.org/docs/formal/07-11-02.pdf (2007)

35. Object Management Group (OMG): UML Profile for MAR-TE, Beta 2. Specification, OMG. http://www.omgmarte.org/Documents/Specifications/08-06-09.pdf (2008)

36. Object Management Group (OMG). Service Oriented Architec-ture Modeling Language (SoaML)—Specification for the UMLProfile and Metamodel for Services (UPMS), revised submission.Specification, OMG. http://www.omg.org/cgi-bin/doc?ptc/09-04-01 (2009). Last visited: 30.08.2009

37. Petriu D., Woodside, C.: An intermediate metamodel with scenar-ios and resources for generating performance models from UMLdesigns. Softw. Syst. Model. 6, 163–184 (2007)

38. Röttger, S., Zschaler, S.: Model-driven development for non-func-tional properties: refinement through model transformation. In:Proceedings of the Unified Modeling Language (UML 2004).LNCS, vol. 3273, pp. 275–289. Springer, Berlin (2004)

39. Software Engineering for Service-Oriented Overlay Computers.http://www.sensoria-ist.eu

40. Tribastone M., Gilmore, S.: Automatic extraction of PEPA per-formance models from UML activity diagrams annotated withthe MARTE profile. In: Proceedings of the Seventh InternationalWorkshop on Software and Performance (WOSP). ACM, Prince-ton, New Jersey, USA (2008)

41. Vara, J.M., de Castro, V., Marcos, E.: WSDL automatic generationfrom UML models in a MDA framework. In: NWESP 2005, pp.319. IEEE, USA (2005)

42. Varró, D., Balogh, A.: The model transformation language ofthe VIATRA2 framework. Sci. Comput. Program. 68(3), 214–234 (2007)

43. Varró, D., Pataricza, A.: Generic and meta-transformations formodel transformation engineering. In: Baar, T., Strohmeier, A.,Moreira, A., Mellor, S. (eds.) Proceedings of the UML 2004:7th International Conference on the Unified Modeling Language.LNCS, vol. 3273, pp. 290–304. Springer, Lisbon (2004)

44. Wada, H., Suzuki, J., Oba, K.: Modeling non-functional aspects inservice oriented architecture. In: IEEE International Conference onService Computing, Chicago, IL, pp. 222–229. IEEE, USA (2006)

45. Web Services Security: SOAP Message Security 1.1 (WS-Security2004). http://docs.oasis-open.org/wss/v1.1/

46. Wirsing, M., Hölzl, M., Acciai, L., Clark, A., Banti, F. Fantechi,A., Gilmore, S., Gnesi, S., Gönczy, L., Koch, N., Lapadula, A.,Mayer, P., Mazzanti, F., Pugliese, R., Schroeder, A., Tiezzi, F.,Tribastone, M., Varró, D.: A pattern-based approach to augment-ing service engineering with formal analysis, transformation anddynamicity. In: Proceedings of 3rd International Symposium onLeveraging Applications of Formal Methods, Verification and Val-idation (ISOLA 2008), Porto Sani, Greece, LNCS. Springer, Berlin(2008)

47. Woodside, C.M., Petriu, D.C., Petriu, D.B., Shen, H., Israr, T.,Meseguer, J.: Performance by unified model analysis (PUMA). In:WOSP, pp. 1–12. ACM, New York (2005)

48. WS-Reliability 1.1 specification. http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf

49. WS-ReliableMessaging 1.1 specification. http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf

Author Biographies

Stephen Gilmore is a Reader inComputer Science at The Uni-versity of Edinburgh, Scotlandwhere he is a member of the Lab-oratory for Foundations of Com-puter Science. He received hisPhD from the Queen’s Universityof Belfast in Northern Ireland.His interests include quantitativemodelling of software systemsand biological processes. Thefocus of his work is on using pro-cess algebra to model systemsand to derive analysis resultswhich guide the modification or

optimisation of systems according to formally specified performancemetrics.

László Gönczy completed hisPhD studies at Budapest Univer-sity of Technology and Econom-ics (BUTE) where he is workingas a research associate. He is alsothe Director of Services and Edu-cation at the OptXware Researchand Development Ltd. He holdsan MSc in Software Engineer-ing from BUTE and a MSc inEngineer-Economics from Cor-vinus University of Budapest.His professional interest includesmodel-driven development ofService-Oriented Architecturesand dependability analysis based

on high level system models. He was involved in several research andindustrial R+D projects and published articles in these fields. He iscurrently working on SENSORIA EU FP6 and CoMiFin FP7 projects.

Nora Koch is a research assis-tant at the Ludwig-Maximilians-Universität (LMU) of Munichand works as project managerat Cirquent GmbH. Her mainresearch interests focus on soft-ware engineering methods for thedevelopment of web applicationsand personalized RIAs, and ser-vice-oriented systems, in partic-ular model-driven engineering.Nora is the leader of the WebEngineering Group at the LMU,responsible for the developmentof the UML-based Web Engi-

neering (UWE) methodology and CASE tool support. Nora has beeninvolved in several national and European projects, and works in theEU project SENSORIA since 2005.

123

http://www.omg.org/spec/QFTP/1.1/

http://www.omg.org/spec/QFTP/1.1/

http://www.omg.org/docs/formal/07-11-02.pdf

http://www.omg.org/docs/formal/07-11-02.pdf

http://www.omgmarte.org/Documents/Specifications/08-06-09.pdf

http://www.omgmarte.org/Documents/Specifications/08-06-09.pdf

http://www.omg.org/cgi-bin/doc?ptc/09-04-01

http://www.omg.org/cgi-bin/doc?ptc/09-04-01

http://www.sensoria-ist.eu

http://docs.oasis-open.org/wss/v1.1/

http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf

http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf

http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf

http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf


Philip Mayer is a research asso-ciate and doctoral candidate inthe research group on Program-ming and Software Engineer-ing at LMU Munich, Germany.He has received his masters incomputer science at the Univer-sity of Hannover in 2006. Mainresearch interests of Philip liein the area of program analy-sis and refactoring, service-ori-ented software systems, MDA,and software development tool-ing. Philip is currently workingin the EU research project SEN-

SORIA on development of service-oriented software systems.

Mirco Tribastone holds a degreein Computer Engineering fromthe University of Catania, Italy.He is currently working towardhis PhD in Informatics at theLaboratory for Foundations ofComputer Science at The Uni-versity of Edinburgh. He hisinterested in analytical tech-niques for performance evalua-tion, with focus on performanceprediction of computer systemsusing process-algebraic specifi-cations.

Dániel Varró is an associate pro-fessor at the Budapest Universityof Technology and Economics.His main research interest ismodel-driven systems and soft-ware engineering with specialfocus on model transformations.He regularly serves in the pro-gramme committee of variousinternational conferences in thefield. He is the founder of theVIATRA2 model transformationframework, and the principalinvestigator at his university ofthe SENSORIA, DIANA and Se-

cureChange European Projects. Previously, he was a visiting researcherat SRI International, at the University of Paderborn and TU Berlin. Heis a three time recipient of the IBM Faculty Award.

123