Due to the rapid increase in the number of available web services, more and more emphasis is put on their reliability, availability, security, etc. These non-functional requirements are frequently captured in service-level agreements between service requesters and providers. In order to meet such non-functional requirements, a service needs to be designed for reliability by making design decisions on a high, architectural level. In the paper, we present a model-driven approach for the precise analysis of service con gurations with reliable messaging. Starting from high-level UML models of service con gurations captured by a UML pro le dedicated to service design, performability models are derived by automated model transformations for the PEPA toolkit in order to assess the cost of fault tolerance techniques in terms of performance.
Service-Oriented Architectures (SOA) provide a exible and dynamic platform for implementing business services. Due to the rapid increase in the number of available services, more emphasis is put on their reliability, availability, security, etc. In order to meet such non-functional requirements, a service needs to be designed for reliability by making design decisions on an architectural level.
Recently, various non-functional parameters of services have been identi ed by various XML-based web service standards such as WS-Reliability, WS-RM, WS-Security, etc. While these properties are attached to business-level web services, they, in fact, specify the con guration and behavior of the service infrastructure, i.e. services that are not part of a speci c application, but play a dedicated role in the underlying service middleware. A focal issue in the service infrastructure is to provide reliable messaging between services where the delivery of a message can be transparently guaranteed by the underlying platform.
Unfortunately, service con gurations are typically set up in a rather ad hoc
way. While non-functional requirements are precisely captured in service-level
? This work was partially supported by the SENSORIA European project
(IST-3016004). The third author was also supported by the Janos Bolyai Scholarship.
agreements, there is no guarantee that the service con gurations will actually
meet these requirements. One of the reasons for this is that \design for reliability"
is a complex task as performance and reliability requirements are contradicting:
an inappropriate setup of reliability attributes may cause signi cant decrease in
performance. As a consequence, performability analysis is necessitated to assess
the cost of using fault-tolerant techniques in terms of performance.
To tackle these problems, we propose a model-driven approach (illustrated
in Fig. 1) to e ciently design, analyze and deploy standards-compliant service
con gurations with reliable messaging. Our approach is strictly in line with the
model-driven service engineering framework being developed within the
SENSORIA EU FP6 research project [
Modeling of service con gurations. In order to raise the level of abstraction
for service engineers when designing the con guration of the service
infrastructure, we rely on high-level UML models conforming to the UML4SOA pro le
(developed within SENSORIA), which uses the standard extensibility
mechanism of UML for modeling service-oriented applications. This pro le is closely
related to the core SOA metamodel presented in [
Model-based performability analysis. From such service con guration
models, automated model transformations generate formal process models for the
PEPA framework (Performance Evaluation Process Algebra, [
Analysis models serve also as the basis of deployment code generation to
reliable messaging middleware (see Fig. 1). The basic method for this has already
been described in [
In the current section, we present how service con gurations can be modeled
using a high-level UML model dedicated to service design by a corresponding
UML pro le, which was designed as part of the SENSORIA project. This pro le
is conceptual follow up of [
In this paper we will use the "On Road Assistance" scenario developed in scope
of the Automotive Case Study [
This scenario raises several non-functional requirements against the system,
as collected in [
(a) Main concepts of UML4SOA (b) Metamodel of non-functional properties of services
The UML4SOA pro le [
On a very abstract level, we de ne Services which are provided by Components. Each service de nes two Interfaces, a provided interface and a required interface. Each service de nes a Protocol while each component has an Implementation.
Non-functional aspects are included in the UML4SOA pro le by generalizing Service Level Agreements. Attributes of a service are described by NFDimensions which are collected to NFCharacteristics, which represent logical groups of properties, such as security, performance or reliable communication. These characteristics are contained within an NFSpeci cation.
During the operation lifecycle of services, provided and requested properties
of services are negotiated (which process is out of the scope of the current paper).
After the negotiation, a contract with an agreement of the agreed speci cation
is created. Ful llment of the contract is monitored by a dedicated component.
Case study. An extract of the components of the \On Road Assistance"
scenario [
(a) Core components of the OnRoadAs- (b) Extension of non-functionalconcepts sistance scenario for reliable messaging
There are various industrial standards re ecting the emerging need for reliable Web services middleware from which we focus on reliable messaging standards (e.g., WS-Reliability and WS-ReliableMessaging) in this paper.
The main importance of these reliable messaging standards lies in the fact that they are expected to replace the current mainstream messaging middleware (such as Message Queuing servers or JMS) which are now used together with SOAP to provide a reliable asynchronous communication service.
Reliable messaging in the elds traditional distributed systems is closely related to the guaranteed semantics of message delivery. Usual delivery classes are the following: 1. At least once delivery. In the case of normal operation, every message is transferred at least once, with the possibility of sending multiple instances of the same message. This can only be allowed in systems where this does not have an undesired side-e ect. 2. At most once delivery guarantees that no message will be sent multiple times to the receiver, but their successful transmission is not ensured. 3. Exactly once delivery is the strongest delivery semantics, guaranteeing both the successful message delivery (usually acknowledgements are required for each message) and the ltering of duplicate messages.
The following attributes are required for the con guration of reliable messaging (besides messagingSemantics, which selects the messaging mode as described earlier): { inactivityTimeout: (integer, seconds), after this period of time if no acknowledgment message has arrived, the connection is closed; { exponentialBacko : (boolean), if it is set to true, time amounts between retransmissions are following an exponential distribution; { acknowledgementInterval: (integer, seconds), amount of time elapsed before sending acknowledgement message; { retransmissionInterval: (integer, seconds), after this time a request is resent by client if no acknowledgement arrived.
As reliable messaging PIM, we use the metamodel of reliable messaging in
service con gurations was created in [
We incorporate these attributes to the UML4SOA pro le by prescribing that the NFCharacteristic of an NFSpeci cation should contain an NFDimension speci c to reliable messaging ReliableMessaging (when reliable messaging is required by a contract). The relationship between concepts is illustrated in Fig. 3(b). Case study. We now demonstrate how the non-functional extensions of the UML4SOA pro le can be used to capture reliable messaging speci cations in Fig. 4(a) (for charging the bank account of the driver) and Fig. 4(b) (for the Global Positioning System).
For instance, communicating with the bank requires both reliable and secure message communication, of which here we concentrate on the rst. Note that here we are at the class level, a concrete instance of this system is shown later in Fig. 8.
NFSpeci cations are de ned to describe the relevant properties of communication between GPSSystem and Vehicle Communication Gateway etc. These specication can contain di erent characteristics like availability, performance or reliable messaging. Certain parameters can be de ned for non-functional attributes (averageResponseTime, messageSemantics etc.) in course of modeling which can be used for example for generation of con guration les as can be seen later.
In the current paper, we illustrate our approach by using the at-least-once reliable messaging semantics as a communication model. However, using other reliable messaging semantics would not cause signi cant complications for the presented approach.
(a) Non-functional speci cation of the (b) Non-functional speci cation of the bank service GPS service
As the main contribution, we present a model-driven technique for the
performability analysis of service con gurations with reliable messaging. Performability
refers to the behavior of the system in the presence of faults, in other words, the
cost of fault-handling (or fault-tolerant) techniques in terms of response time.
For our investigations, we use the PEPA (Performance Evaluation Process
Algebra) toolkit [
Essentially, automatic model transformations derive PEPA processes from the UML models of service con gurations extended with reliable messaging attributes. This transformation takes various inputs: { Service con guration models, which only contain the architectural design, i.e. the dependencies between services being relevant for performability analysis. For performability analysis, we identify the main roles of service providers and requesters potentially chained to incorporate third party services. { Prede ned library of component behavior, which captures the core, performability related behavior of reliable messaging for each party (e.g. service provider, requester). This library should include technology-related behavior, which is typically observable but not controllable (in case of a reliable messaging middleware, the overhead of access to stored message content before generating new message instances). { Reliable messaging parameters, which a ect both the structure and the dynamic behavior of performability models. This includes quantitative characteristics of faults of message transmission (encoded implicitly into rates of transitions) to estimate the e ect of unreliable communication layer. 3.1
For capturing the performability model of the basic components (in our case, the client and the server), we use a visualized version of the process algebra notation of PEPA. Each process is visualized as an automaton. Rectangles represent states, while transitions between states correspond to communication actions. ! stands for sending a message and ? means receiving a message. Sending and receiving messages is carried out by synchronization between the two processes. Internal actions without communication between processes are also distinguished (e.g., timeout trigger events). The ring frequency of transition in PEPA are considered to follow an exponential distribution.
Fig. 5 shows the stochastic performability model created as a combination of some core processes. The model represents the behavior of a service provider (Bank) and a service requester Vehicle Communication Gateway when reliable messaging is required between them.
The service provider (shortly, server) component is either processing a request or waiting for a new one, with the action of sending an acknowledgement to the client once the message was successfully received.
The service requester (or shortly, client) is assumed to behave according to the at-east-once semantics (with an upper limit of three on the number of messages). The automaton of the service requester represents that after sending a message, it waits for an acknowledgement until a timeout occurs. Then it resends the request until the maximum number of retransmission is reached. This is represented by the non-trivial multiplication of a basic automaton as many times as the maximum number of allowed retransmissions. If an acknowledgement arrives, the message transmission is considered successful.
It is worth pointing out that the handling of exactly-once delivery semantics
prescribing the ltering of duplicate messages is quite similar from a
performability perspective. Furthermore, note that this process model is an abstraction
of the graph transformation system presented in [
Reliable messaging parameters have di erent impact on the structure of this
model. The number of service providers and requesters can be altered by
changing the system equation (e.g. ClientIdle[
Values of parameters inactivityTimeout, exponentialBacko , acknowledgementInterval and retransmissionInterval serve as a basis for deriving the actual ring rates of the transitions in Fig. 5. Note that ring times follow an exponential distribution speci ed by these rates, i.e. a larger rate means that the corresponding operation will be executed faster. Below we describe how the rates in the PEPA model were derived from the reliable messaging parameters in Sec. 2.3.
{ acknowledgement rate (rateAck): it depends on the acknowledgement interval:
ack = 1=acknowledgementInterval; On calculating this formula the prospective value of exponential distribution with ack parameter will be equal to acknowledgementInterval. { timeout rate (rateTimeout): Similar to the previous formula: timeout = 1=retransmissionInterval; but if exponentialBacko is true the next timeout is:
timeout = timeout=2; thus between resend messages exponential amount of time elapses; { send rate (rateSend): it can be considered as an input parameter of sensitivity analysis so a service con guration can be tested under di erent workload. Alternatively, it can be derived from maximum throughput parameter in a service level agreement, which expresses the number of requests received from the user. { resend rate (rateResend): it should be a high value (compared to other parameters) because when timeout occurs, resent message should be sent as soon as possible. { reset rate (rateReset): like resend rate, it gets a high value in order to model the transition to ClientIdle state after successful transmission.
Note again that the number of allowed retransmissions (retransmission number) changes the state space of the client automaton, i.e. additional retransmission states are introduced (FailNx and SentNx). This number is determined in the following way: retransmissionN b =
inactivityT imeout retransmissionInterval This expresses that the clients tries to resend the request until the inactivity timeout is exceeded. 3.3
The typical questions for the PEPA solvers investigate passage time (i.e., the
expected response time of the system as a function of stochastic parameters),
utilization of states (what percentage of total operating time is spent in a
particular state). In addition, sensitivity analysis can also be performed to estimate
the e ect of changing transition rates on system-level performability attributes.
The number of possible retransmissions is also an interesting parameter to
investigate, however, this needs the modi cation of the structure of the performability
model (by re-executing the transformation), while tuning of other parameters
requires to modify only the rates in the generated PEPA model. Core examples
for using PEPA are available in [
We can investigate the utilization of states in order to answer questions like "What percentage of time is spent waiting for the answer of the request?" The result obtained from executing PEPA is listed in the pie chart of Fig. 6.
With the parameter settings of our running example (described in Fig. 5), PEPA derives that in a steady state, the system spends 23% of the time within states MsgSentX and FailX, which are exactly the states required for providing reliable messaging. In other terms, the system spends 23% of the time with fault handling. Sensitivity analysis. Fig. 7 shows the (relative) change of failure rate as a function of RAMP related parameters acknowledgement time and retransmission interval based upon PEPA calculation. For the failure rate, utilization of Failure state has been used. X-axis shows di erent values of acknowledgment time while the di erent curves plot di erent timeout thresholds.
Our analysis results can be interpreted as early prediction of performability. For instance, one can deduce from Fig. 7 that if the rateAck rate is increased from 0.2 to 0.3 (namely acknowledgement interval decreases), then there is about 100% decrease in the frequency of errors. So it is worth improving performance of the provider if its cost is linear. Decreasing rateTimeout rate (curves with di erent colors) also leads to the improvement of failure rate.
Now we extend our performability model to handle service con gurations where a service provider itself needs to call some other (third-party) service in order to serve its own request. This intermediate (mediator) component acts as a server and a client at the same time, thus we derive its behavior by combining the basic elements of our performability model (exempli ed in Fig. 5) by synchronizing the core automata on send and ack messages.
For our investigations, we have bounded such a transitive behavior by a depth limitation of 3, while we assume that potential cyclic service invocation is ltered out by formal model checking.
In the sample service con guration of Fig. 8 Orchestrator invokes Vehicle Communication Gateway (VCG) that acts both as a service provider and service requester. The worst performance is observed when the VCG needs to call both
GPS and Bank components to ful ll a
Fig. 8. Multiple parties request.
Sensitivity analysis. For this scenario, we carried out a sensitivity analysis to measure the throughput of the acknowledgement action of the system. The results are depicted in Fig. 9 where the rates rateSendVC and rateSendVG stand for the sending rate between VCG - Bank and VCG - GPS components, respectively. Increasing these rates results in a faster operation of the Bank and GPS services. Observing the lower curve we can deduce that it is useless to increase the performance of Bank component if the GPS operates slowly (0.2). However the upper curve shows that it is worth increasing the speed of Bank service as it results in signi cant increase in acknowledgement rate, thus it decreases the acknowledgement time of the system.
The translation of the UML model to PEPA code was implemented in multiple steps shown in Fig. 10 using Model2Model and Model2Code transformations. The input of the transformation chain is a UML model using UML4SOa for modeling services and non-functional parameters of messaging. This model is imported to the internal representation of the VIATRA2 tool.
First, uml2soa transformation takes out the relevant parts of the model. This
transformation is used to collect relevant information from the model
representation and generates a compact model (which is semantically similar to a Domain
Speci c Model). This model is also used in other work as a basis of con guration
generation for Web services [
Then uml2pepa is executed to transform relevant parts of this model (from the performance aspect) to the concepts of the PEPA tool by taking the contracts attached to the model and generating PEPA automaton. This transformation also uses a 'parameter library' (currently encoded as a set of constants) which represent typical settings of the reliable middleware. These are also used to set default values for parameters which were uninitialized in the high level model. This transformation can be considered as a "PIM-to-PSM mapping" following the MDA conventions.
Finally, pepa2out is a syntactical transformation which generates textual code from the PEPA model. Separating the syntax generation from the semantical mapping enables to develop transformations which are easier to maintain; moreover, the abstract performance model can also serve as the basis of creating input to other stochastic analysis tools.
Model transformations are also captured in a textual way by using a combination of (i) graph patterns for querying models, (ii) graph transformation rules for elementary model manipulations, and (iii) abstract state machines for assembling complex transformations from simple rules.
Creating transformation work ow The transformation work ow has also been
integrated to the SENSORIA Development Environment (SDE) (it will be
available for public download soon). SDE is an Eclipse-based tool which integrates
SOA development and analysis tools in a "SOA-style" [
Using our transformations and the SENSORIA tools, the developer can perform complex design tasks of SOA systems where analysis questions have to be answered (for instance, whether it is worth using reliable messaging considering expected failure rate and performance constraints). All models and tools can be managed within the same Eclipse environment. Extended with deployment transformations and references to component implementations, the service con guration can directly generated to target execution environments. 4
A framework for automated WSDL generation from UML models is described
in [
Non-functional aspects of e-business applications are discussed among others
in [
Integration of non-functional aspects in the development by model
transformations is also investigated in [
In a service-oriented environment, PEPA has already been used to analyze
(application-speci c) high-level UML models or work ow-like descriptions of
services with Service Level Agreement attributes [
Concerning previous work of the same authors, veri cation of the behavior of
the system (i.e., checking the conformance to requirements on reliable
messaging) was performed in [
In the paper, we presented an integrated model-driven framework for the design and analysis of standards-compliant service con gurations supporting reliable messaging. Starting from high-level, platform independent service con guration models (captured by service engineers using a UML Pro le or a domain-speci c editor) performability analysis was carried out by generating stochastic process models for the PEPA toolkit. We used an SLA-like description and (in contrary to existing methods were the original source model had to be enriched by performability parameters) we created a quantitative model which is the basis of precise analysis, helping the designer to estimate the cost and bene t of using reliable middleware.
Transformations were implemented using the VIATRA model transformation
framework [
A thorough scalability analysis of our approach on a real-life example is also part of our research activities. We will compare the provided performance characteristics of the normal message communication and that of the reliable messaging middleware. Here we anticipate that from the user point of view the average response time will be increased because of the overhead of acknowledgement and possible resending of messages, however, the number of failed messages will obviously decrease.
We also plan to work on the back-annotation of the results to the engineering model. Finally, the same model representation is used as the basis of deployment transformations to standard-compliant platform, such as IBM RAMP, Apache Axis2 extended with Sandesha module and SCA environments with implementations of the Policy framework.