Technical Report 2015-001

Integration of Reliability Prediction into
Service Composition Frameworks

Thanh-Trung Pham and Alexander P. Vazhenin
September 14, 2015

School of Computer Science and Engineering
The University of Aizu
Tsuruga, Ikki-machi, Aizu-Wakamatsu City
Fukushima 965-8580, Japan

Technical Report 2015-001
Title:
Integration of Reliability Prediction into Service Composition Frameworks
Authors:
Thanh-Trung Pham and Alexander P. Vazhenin
Key Words and Phrases:
Reliability-aware service compositions, integration support of reliability prediction
Abstract:
Service composition frameworks hide the complexity of the underlying technologies andenable their users to easily compose new services from existing ones. To anticipate thereliability of composed services before their actual operations, it is possible for service
composers to use existing model-based software reliability prediction techniques.
However, such techniques either neglect or have only basic integration support into
service composition frameworks. This limits their applicability because (1) neglecting
integration support leads to high effort and specialist knowledge required to build models
necessary for reliability predictions and (2) basic integration support likely reduces theflexibility and reusability when integrating into different service composition frameworks.
In this paper, we present RMPI-SerComp to offer enhanced integration support into
service composition frameworks for RMPI, a recent model-based software reliability
prediction technique. Our approach enables service composition frameworks to achieve asystematic consideration of service reliability during composing, without the need for any
specialist knowledge of the underlying prediction method. Via a case study, we validate
the applicability of our approach by utilizing RMPI-SerComp to integrate the reliability
prediction capability into a service composition framework.
Report Date:
September 14, 2015

Written Language:
EnglishAny Other Identifying Information of this Report:

Distribution Statement:
First Issue: 3 copies
Supplementary Notes:

Active Knowledge Engineering Laboratory
The University of Aizu
Aizu-Wakamatsu
Fukushima 965-8580
JapanIntegration of Reliability Prediction into Service Composition Frameworks
Thanh-Trung Pham and Alexander P. Vazhenin
School of Computer Science and Engineering
The University of Aizu (UoA)
Aizu-Wakamatsu, Fukushima, Japan
Email: {pttrung,vazhenin}@u-aizu.ac.jp
Abstract—Service composition frameworks hide the complexityof the underlying technologies and enable their users to easily
compose new services from existing ones. To anticipate thereliability of composed services before their actual operations,
it is possible for service composers to use existing model-based
software reliability prediction techniques. However, such techniques either neglect or have only basic integration support into
service composition frameworks. This limits their applicability
because (1) neglecting integration support leads to high effort
and specialist knowledge required to build models necessary forreliability predictions and (2) basic integration support likely
reduces the flexibility and reusability when integrating into
different service composition frameworks.
In this paper, we present RMPI-SerComp to offer enhanced
integration support into service composition frameworks for
RMPI, a recent model-based software reliability prediction technique. Our approach enables service composition frameworks toachieve a systematic consideration of service reliability duringcomposing, without the need for any specialist knowledge ofthe underlying prediction method. Via a case study, we validate
the applicability of our approach by utilizing RMPI-SerComp
to integrate the reliability prediction capability into a service
composition framework.
Index Terms—Reliability-aware service compositions, integration support of reliability prediction.

I. I NTRODUCTION
Software providers and consumers have gained more andmore interest in service-oriented software systems. For bothsides, this can help to reduce build-up time and infrastructure
cost, as well as to advantage management [1]. Besides single
services, service providers also offer composed services on
demand, under customer requests. In order to enable intuitive
creation of composed services without specialist knowledge ofthe underlying technologies, service composition frameworks(e.g. [2]–[4]) have come into view.
Besides functional properties (e.g. correctness), quality
properties (e.g. reliability, performance, security, etc.) arebecoming more important to attain and assure the acceptanceof users. Analyzing reliability of composed services (i.e. theprobability of failure-free operation in a given time span) isapparently a challenge because:
Services can be composed in a dynamic manner, leading
to multiple compositions to be analyzed.
• Creating and testing each possible composition requested
by customers are usually not feasible as it is resource- andtime-consuming to conduct on all compositions and/or
invoking services may be charged.
•

Using existing model-based software reliability prediction
techniques is a potential solution to this problem. Being basedon the service model and its reliability-influencing factors, they
use analytical calculations or simulations to predict the service
reliability, without any actual executions of the service.
However, many existing model-based software reliability
prediction techniques (e.g. [5]–[7]) are missing integration
support into service composition frameworks. As a result,service composers have to apply these prediction techniques
separately, via manually specifying the input informationnecessary for reliability predictions. This manual specificationis laborious, error-prone and not always possible because of
the missing knowledge regarding the inner characteristics ofthe service model. Moreover, for many prediction techniques,
service composers are required to have specialist knowledge(e.g. Markov models) and to understand the details of theprediction techniques (e.g. the mappings of services or theirinternal behavioral states to Markov states). Manual reliability
prediction is ineffective and difficult to accomplish for service
composers, especially when it is to be done repeatedly forcomposed services requested by customers and their possible
composition alternatives. On the other hand, existing techniques (e.g. [8]) that offer basic integration support typicallylack a public Application Programming Interface (API) anda plug-in architecture for their integration support. These two
factors are necessary to achieve the flexibility and reusability
when integrating into different service composition frameworks. By utilizing the public API, integrations can be adapted
according to integration requirements. The plug-in architecture
enables sharing and reusing integration parts.
Contribution: In this paper, we present the RMPI-SerComp1
to offer enhanced integration support into service composition
frameworks for RMPI2 [9], our recent model-based software
reliability prediction technique. With RMPI-SerComp, thestandard service composition process of service composition
frameworks can be enhanced to become a reliability-aware
service composition process, which includes reliability prediction for composed services as well as supports the decision
between different composition alternatives. RMPI-SerComp
offers a public API and a plug-in architecture for flexible
and reusable integrations into service composition frameworks.
RMPI-SerComp is realized via a set of components and their
1 SerComp: Service Compositions
2 RMPI: Reliability Modeling, Prediction, and Improvements

interactions. We validate our approach in a case study where
we utilize RMPI-SerComp to enhance a service composition
framework with the reliability prediction capability.
Structure: The rest of this paper is organized as follows:
Section II introduces the existing foundations of our approach.
Section III surveys related work. Section IV describes ourrecommended reliability-aware service composition process.
Section V describes in detail RMPI-SerComp’s architecture
and its workflow. Section VI demonstrates our approach witha case study. Section VII discusses our assumptions andlimitations, and Section VIII concludes the paper.

Modeler

Tool

1

2

Enriching modelTransforming
model
Annotated
Annotatedsystemsystem model
model
Reliability
analysis model

SystemSystem model
model
3

Analyzing/
Simulating
model

II. F OUNDATIONS

Prediction
resultIn this section, we briefly introduce the main related research areas of our approach: service compositions and modelbased software reliability prediction. Service compositions
provide a flexible way for software creation, but it is also
challenging to assure the reliability of dynamically composedservices. Model-based software reliability prediction offers theability to model and predict the reliability of software systems,
which can be embedded and utilized throughout a software
engineering process.

4
Relating resultsback to modelFig. 1. Model-based software reliability prediction.

In Step 2, the annotated system model is transformed intoa reliability analysis model, e.g. a Markov model, a Bayesian
network. The analysis model is then solved by an analyzer ora simulator to obtain prediction results in Step 3. The set ofavailable results is dependent on the modeling formalisms aswell as its solver.
Finally, the prediction results are related back to the beginning system model in Step 4. This feedback is supposed tosupport the modeler in answering evaluation questions, e.g.
which parts of the system are most likely to cause failures?.
The last three steps should be performed automatically bytools.

A. Service Compositions
Software service is a self-describing entity that encapsulates
its contents (i.e. functionalities and data) and is accessible
via its interface [1]. This information is sufficient for service
compositions, i.e. orchestrating existing services to provide
more functionalities as new services. A workflow3 is often
used to describe the composition of services, using programming or modeling languages such as WS-BPEL (WebServices Business Process Execution Language) [1]. In recent
years, service composition frameworks (e.g. BizTalk Server[2], Oracle BPM [3], jBPM [4]) have been developing to
make service compositions easier for users with little or evenzero programming experience through intuitive and flexible
development environments. In order to assess the value ofcomposed services, it is necessary to evaluate not only theirfunctional properties but also their quality properties [12].

III. R ELATED W ORK
Seminal work in software reliability engineering [16] focuses on system testing and reliability growth models treating
systems as black boxes. Recently, many model-based software reliability prediction approaches have been proposed[13]–[15], treating systems as compositions of components
or services. In the following, we examine these approacheswith respect to integration support into service composition
frameworks, targeting at automated and transparent-to-servicecomposers reliability predictions in these frameworks.
Cheung’s approach [17], a well-known representative of the
field, expresses the control flow between components in asoftware system using an absorbing Discrete-Time Markov
Chain (DTMC) and encodes the usage profile of the system into their transition probabilities. The approaches ofCortellessa et al. [18] and Filieri et al. [19] build on thesame formalism and superimpose error propagation models.
The approach of Wang et al. [20] extends the formalism
to capture heterogeneous software architectures incorporating
different architectural styles. Further approaches building on
the Cheung’s model include the approach of Sharma et al. [21]which takes into consideration the possibilities of component

B. Model-based Software Reliability Prediction
Fig. 1 depicts a general model-based reliability prediction
process [13]–[15]. It starts with the model of a softwaresystem. Usually, this model exists as a part of a software
engineering process and typically, is expressed using designoriented modeling languages, e.g. UML (Unified Modeling
Language), ADL (Architecture Description Language).
Predicting reliability requires additional data which is not
yet present in the system model. Therefore, in Step 1, themodeler needs to annotate the system model with reliabilityrelevant data. The amount of additional data is highly dependent on the concrete prediction approaches. In general,
the annotations include failure possibilities in the system andusage characteristics of the system.
3 Basically, any other kinds of glue code could also be used, e.g. [10], [11].

2restarts and application retries, the approach of Sharma et al.
[22] which offers combined predictions of multiple quality
attributes, the approach of Lipton et al. [23] which conducts reliability optimization. These approaches are tailored tocomponent-based software systems and disregard integration
support into service composition frameworks.
The approach of Reussner et al. [24] is based on Rich
Architecture Definition Language (RADL) but employs thesame underlying theory as Cheung’s approach for reliability
predictions. The approach of Reussner et al. can be seen as aprecursor of the approach of Brosch et al. [25] which offers aparameterized reliability prediction taking into consideration
the influences of the system’s usage profile and the system’s
execution environment. The approach of Cheung et al. [26]is specifically tailored to component-level reliability prediction. These approaches also disregard integration support into
service composition frameworks.
Scenario-based approaches such as the approach of Yacoub
et al. [27] which constructs component dependency graphsfrom component sequence diagrams as a basic for reliability
predictions, the approaches of Cortellessa et al. [28], Popic etal. [29], and Goseva et al. [30] which employ UML diagrams
annotated with reliability properties, the approach of Rodrigues et al. [31] which is based on message sequence charts,
also disregard integration support into service composition
frameworks.
The approaches of Grassi [5], Cortellessa et al. [6], andZheng et al. [7] aim at reliability prediction for serviceoriented architectures (SOA). The approaches of Grassi andCortellessa et al. consider recursively composed services,where each service may invoke multiple external services
in order to complete its own execution. The approach of
Zheng et al. employs a workflow description for composite
services with sequential, looping, and parallel structures. The
approach of Grassi et al. [32] reuses a number of conceptsof the approach of Grassi [5] and proposes the Kernal Language for Performance and Reliability Analysis (KLAPER).
However, these approaches do not consider automated andtransparent-to-service-composers predictions in service composition frameworks.
The approach of Klatt et al. [8] considers integration support
into service composition framework and is currently basedon the approach of Brosch et al. for reliability predictions.
However, it does not consider a public API and a plug-inarchitecture for their integration support, which are the two
important factors to offer the flexibility and reusability when
integrating into different service composition framework.
We described RMPI, which is our recent model-based
software reliability prediction technique and do not related tointegration support into service composition frameworks, in
our former work [9], [33].

standard service composition process [1] to include general
steps to create composed services that satisfy the given reliability requirements and to regard generic reliability-influencing
factors of composed services.
At the generic level, the reliability of a composed service isdependent on: (1) its composition workflow (i.e. the control
and data flow between involved services), (2) the failure
possibilities of required external services, and (3) its usage
profiles (e.g. how often the composed service is used).
At the essence level, similar to any other kinds of softwaresystems, faults in the implementations of required external
services are the root causes for failures of the composedservice and error propagation in the composition workflow is
crucial in the chain leading to failures of the composed service[34]. Besides basic control flow structures (i.e. sequential,
branching, or looping structures), the composition workflow
of a composed service can employ parallel structures andfault tolerance structures to improve the service performanceand the service reliability, respectively. Employing parallel
structures could lead to concurrent error propagation paths
as well as concurrently present errors and employing fault
tolerance structures could involve non-trivial error detection,
error handling, and fault handling activities [9].
Notice that the underlying model-based software reliability
method should be chosen in such a way that it explicitly takeall the factors mentioned above into consideration for accurate
prediction results.
Fig. 2 describes our recommended process with six steps,
including familiar steps of the standard service composition
process (shown in grays). The service composer (i.e. theuser of a service composition framework) is responsible toconduct these steps. The top of the figure shows the customer’s
requirements that the composed service must satisfy under
the given usage profiles. Artifacts related to external services(e.g. their descriptions and failure models expressing failure
possibilities) are shown at the bottom of the figure.
Step 1 is to create an abstract service composition workflow
starting from the scratch or selecting from a repository of
existing workflows. To realize the composed service, theabstract composition workflow includes abstract dependencies
on external services and possibly sets of candidates that matchthese dependencies. There might be multiple candidates available for each dependency but with different failure models.
Fig. 3a shows an example of a simple abstract composition
workflow, including a set of abstract service dependencies(asd1 , ..., asd4 ), their candidates, and basic control flow
structures (a sequential structure, a branching structure with
branching conditions, and a looping structure with a loop
count).
From the abstract workflow, the service composer selects a
candidate for each abstract dependency, yielding the concrete
service composition workflow in Step 2. Fig. 3b shows anexample of a simple concrete composition workflow withselected external services (s11 , ..., s42 ).
In Step 3, from all the relevant information in the usage
profiles, the concrete service composition workflow, the failure

IV. R ELIABILITY-AWARE S ERVICE C OMPOSITIONP ROCESSIn this section, we present our recommended reliabilityaware service composition process. It is enhanced from the3Service requirements(incl reliability requirements)

Usage profiles

5
Feedback

Revising service selection,
composition workflow( Prediction results vsreliability requirements)

1

2
Creating abstract
composition workflow

ServicecomposerYes

3
Selecting external
service candidates

Predicting reliability

OK?

4

Feasible?
No

No

Rejecting customer
requestYes
Abstract composition
workflow6

Concretecomposition workflow

Binding and publishingcomposed service

Service descriptions(incl service failure models)

Abstract service
composition workflow

Fig. 2. Reliability-aware service composition process.

identifying the most critical parts of the composition workflow.
All of these may be repeated multiple times, without any actual
executions of the composed service. If the composer cannot
create any feasible offers in reply to the customer’s request,
he rejects the request as in Step 4.

asd2[X=true]

...

asd1

Y

START

[X=false]
Candidates:{s11, s12, …}

asd4
END

asd3

Candidates:{s41, s42, …}...

V. RMPI-S ER C OMP
In this section, we describe RMPI-SerComp. It offers enhanced integration support into service composition frameworks for RMPI [9]. With RMPI-SerComp, service composition frameworks can achieve a systematic considerationof service reliability during composing, according to ourrecommended reliability-aware service composition process.
Initially, RMPI was tailored towards component-based software systems. However, it can also be used to provide reliability modeling and prediction for composed services, explicitly
taking into consideration all the reliability-influencing factors
mentioned in Section IV. It has been realized in RMPISchema
and RMPITool. RMPISchema is a developer-friendly reliability modeling language to capture comprehensively different
reliability-influencing factors into a reliability model of thesystem under study. RMPITool offers an automated evaluationof the system reliability model to obtain prediction results.
RMPI has been successfully evaluated in several case studies[9], [33].

Concrete service
composition workflow

(a)

s23
[X=true]
s42

s11
START

Y
[X=false]

END

s31

(b)
Fig. 3. Service composition workflows: (a) Abstract and (b) Concrete.

models of external services, and the reliability requirements,
it is possible to automatically derive a reliability prediction
model which, in turn, is used by an automated reliability
prediction to provide feedback regarding the possibility ofthe service composition to satisfy the customer’s reliability
requirements. Because of these automations, the service composer does not need to have any specialist knowledge of theunderlying reliability prediction method.
If the feedback shows that the customer’s reliability requirements can be met, Step 6, binding and publishing the composed service, is performed. Otherwise, the service composer
can revise the service selection (e.g. selecting other external
service candidates with different failure models), or the composition workflow (e.g. introducing fault tolerance structures)in Step 5 and then repeat the prediction. The feedback canalso include information to guide the revising process, e.g.

A. Architecture and Prediction Workflow
Fig. 4 shows the architecture of RMPI-SerComp, including
existing components of RMPI (shown in gray) and newly
added components. For standalone reliability predictions, thesoftware architect uses RMPISchema to create a reliability
model of the system under study. Based on the created system
reliability model, he manually interacts with RMPITool via
a command line interface (CLI) (provided by component
RMPICLI) to validate the model and then to obtain prediction results by activating analytical calculations (provided
4

SerComp
API

SerCompTranslators

out automatically by component SerCompMediator. First, theinputs provided by the composition framework and its user aretranslated by the chosen translator plug-in into an input modelfor RMPI. As a translator plug-in can produce an unexpected
input model, it is necessary for this input model to be adjusted(optionally) and validated to make sure that it is in a valid form
with all the relevant information.
Based on the valid input model, prediction results are
obtained by conducting predictions via analytical calculations
or simulations. Because it is possible to use any of the two
methods, as well as to use simulations multiple times, the next
step is to check and process these results (e.g. computing meanvalues) before delivering them to generator plug-ins to create
presentations of prediction results as feedback for the service
composer.
Remark: With its public API and plug-in architecture,
RMPI-SerComp allows developing and employing different
input translators and feedback generators, offering flexible
and reusable integrations into service composition frameworks
for RMPI. This plug-in architecture also decouples service
composition frameworks from RMPI, supporting individualchanges from both sides. For example, if the format of the
inputs from a service composition framework changes, only
the corresponding input translator needs to be updated while
RMPI stays unchanged. As another example, if prediction
results from RMPI change their formats, it is required to
update only feedback generators.

RMPI
CLI

RMPI
Controller

SerComp
Mediator

SerComp
Generators

RMPI
Modeler

RMPI
Calculator

RMPI
Simulator

Fig. 4. RMPI-SerComp’s architecture.
1

TranslatorPlugin1
TranslatorPlugin2
...

Input

5

Feedback

Translating
inputsGenerating
feedback
GeneratorPlugin1
GeneratorPlugin2
...

2

3

4

Adjusting,validating model

Conducting
predictions
Checking,
processing results

Fig. 5. RMPI-SerComp’s prediction workflow.

B. TranslatorPlug-ins

by component RMPICalulator) or simulations (provided bycomponent RMPISimulator). As an alternative to the manualinteraction, component SerCompAPI has been developed tooffer a public API covering all the capabilities of RMPI (i.e.
generating and validating system reliability models, conducting predictions, and obtaining prediction results).
As a user of service composition frameworks, the service
composer expects the transparency of reliability prediction
details. From his viewpoint, the inputs necessary for theprediction are specified in a user-friendly way via the userinterfaces of the service composition frameworks. Internally,
these inputs are translated into a valid input format for theunderlying reliability prediction method. In case of RMPISerComp, in order to enable multiple framework integrations,different input translators can be developed by utilizing the
API provided by component SerCompAPI and then registeredas plug-ins in component SerCompTranslators via component
SerCompMediator.
The service composer also expects that the prediction results
are returned as feedback in a understandable and expressive
form, e.g. saying that the given reliability requirements cannot
be met, representing prediction results as a graph. Therefore,
similar to the case of input translators, it is possible to develop
multiple feedback generators for different presentations ofprediction results as feedback for the service composer andregister them as plug-ins in component SerCompGenerators.
Fig. 5 shows the prediction workflow of RMPI-SerComp
with five internal steps. These steps are controlled and carried

An input translator plug-in is to translate inputs from aservice composition framework into a valid input model for
RMPI (i.e. input model of an equivalent component-based
software system). These inputs include: (1) reliability requirements for the composed service, (2) usage profiles for thecomposed service, (3) the concrete service composition workflow of the composed service, (4) failure models of external
services required by the composition workflow, and (5) run
configuration settings, e.g. method for reliability predictions(analytical calculation or simulation), maximum simulation
time. Formats of these inputs depend on concrete service
composition frameworks and can be proprietary or standard
formats (e.g. XML - eXtensible Markup Language, BPMN
- Business Process Model and Notation). It is the task offramework integrators to develop input translator plug-ins.
Let SR be the set of reliability requirements for thecomposed service, UP = {upi } with i ∈ {1, 2, ..., m} bethe set of m usage profiles for the composed service, sn be
the composed service’s name, CW be the concrete service
composition workflow of the composed service, X S = {sj }with j ∈ {1, 2, ..., n} be the set of n required external
services for the composed service, and FM = {f mj } withj ∈ {1, 2, ..., n} be the failure models of the required external
services where f mj is the failure model of required external
service sj , RCS be the set of run configuration settings.
Then, an input translator plug-in translates these inputs into
an input model of an equivalent component-based software5Inputs

Input model

SR

SR
...

<<ServiceImplementation>>
sn

...

START

UP

...

...

<<CallingActivity>>-calledService: sj

...

upi
END

...
CW

<<SystemArchitecture>>
START<<UsageProfile>>

...

...
...

sn

sj

...

...

<<UsageProfile
Part>>
upi

END

sn

<<Component
Instance>>
C

...

...
sj

...

sj

...

<<Component
Instance>>
Cj

...

XS
...

<<ServiceImplementation>>
sj

sj

FM

...

<<Internal
Activity>>

...

START
<<FailureModel>>
fmj

fmj

...
RCS

END

RCS
...

...

Fig. 6. A translator plug-in’s translation.

system for RMPI by utilizing the public API of RMPISerComp as follows (see also Fig. 6):

A usage profile is created in the resulting input model.
It has upi ∈ U P as its usage profile part for all i ∈{1, 2, ..., m}. All of the usage profile parts refer to theuser interface.
• The set of reliability requirements for the composedservice, SR, and the set of run configuration settings,
RCS, are simply passed through.
Remark: The expressiveness of the public API of RMPISerComp is equal to that of RMPISchema (i.e. the reliability
modeling language of RMPI) with regard to control flow
structures, failure models, and usage profiles. Therefore, it ispossible to support the translation for multiple control flow
structures (including sequential, branching, looping, parallel,and different fault tolerance structures) in service composition
workflows, comprehensive failure models (with multiple failure types, concurrent present errors, error propagation, etc.)
of external services, and flexible usage profiles of composedservices. The case study in Section VI shows several examples
of inputs from a service composition frameworks.
•

For each required external service sj ∈ X S, one component Cj is created in the resulting input model. Component Cj provides one service sj . The implementationof provided service sj includes one internal activity. The
activity has f mj ∈ FM as its failure model.
• One component C is created in the resulting input model.
Component C requires n services sj with all j ∈{1, 2, ..., n} and provides one service sn. The implementation of provided service sn has its flow similar to theflow of composition workflow CW . For each dependency
on external service sj in composition workflow CW ,there is a calling activity at the corresponding position in
the implementation of provided service sn to call required
service sj of component C.
• A system architecture is created in the resulting input
model. Within it, there are one component instance ofcomponent C and n component instances of n component
Cj for all j ∈ {1, 2, ..., n}. There are also component
connectors from provided service sj of the instance ofcomponent Cj to required service sj of the instance ofcomponent C for all j ∈ {1, 2, ..., n}. Provided service
sn of the instance of component C is exposed as a userinterface for users.
•

C. GeneratorPlug-ins
A feedback generator plug-in is to generate a presentationof prediction results as feedback for the service composer.
Framework integrators are responsible to develop feedback
generator plug-ins. Prediction results delivered to a generator
6

Reliability requirements

F1 and F2 ), SR including three reliability requirements isshown in column 1, and PR including four prediction results
is shown in column 3. There is no requirement related to
the failure probability of failure types {F1 , F2 } (a blank cellat column 1 row 5). Column 2 shows satisfaction states ofreliability requirements. Because all requirements are satisfied,
SR is satisfied as summarized in the last row. The case study
in Section VI also shows different possible presentations ofprediction results.
Remark: Besides the standard integration scenario described above, based on the inputs from service composition
frameworks, multiple input models for RMPI can be createdby an input translator plug-in to reflect a family of similar
service compositions or to vary values of the parameters in the
inputs, accounting for existing uncertainties of the parameters.
As a result, multiple corresponding sets of prediction results
are delivered to feedback generator plug-ins, which can bebased on to generate presentations for supporting the decision
between the similar service compositions or studying theeffects of the variations of the parameters in the inputs tothe prediction results (a.k.a sensitivity analyses).

Prediction results

Reliability

>

0.993

(o)

0.994

=

Reliability

Failureprobabilityof {F1}

<

0.003

(o)

0.002

=

Failureprobabilityof {F1}

Failureprobabilityof {F2}

≤

0.002

(o)

0.001

=

Failureprobabilityof {F2}

0.003=

Failureprobabilityof {F1,F2}

All reliability
requirements are
satisfied.
2

Satisfy?

(o)Fig. 7. A tabular presentation of prediction results.

plug-in by RMPI-SerComp include not only the predicted
reliability of the composed service but also its predicted failure
probabilities of different failure types.
Let AS be the set of all possible sets of failure types of thecomposed service, f p (F : F ∈ AS) be the predicted failure
probability of failure types F of the composed service, R be
the predicted reliability of the composed service, PR be theset of prediction results for the composed
Pservice, then PR ={R, f p (F ) : ∀F ∈ AS} such that R + ∀F ∈AS f p (F ) = 1.
Considering reliability requirement sr ∈ SR for the composed service, then sr belongs to either Type I or Type II:• Type I - A requirement for the reliability of the composedservice: Reliability > / ≥ cR with 0 ≤ cR ≤ 1 (i.e.
the reliability of the composed service is required to begreater than/greater than or equal to cR , respectively).
• Type II - A requirement for the failure probability of failure types F of the composed service:
F ailure probability of F < / ≤ cF with 0 ≤ cF ≤ 1(i.e. the failure probability of failure types F of thecomposed service is required to be less than/less thanor equal to cF , respectively).
Then, by comparisons between reliability requirements sr ∈SR with the corresponding prediction results pr ∈ PR, it ispossible for a feedback generator plug-in to derive different
presentations of prediction results (e.g. textual, tabular, orgraphical presentation):• In case sr belongs to Type I: if R > / ≥ cR (i.e. thepredicted reliability of the composed service is greaterthan/greater than or equal to cR , respectively), sr is
satisfied. Otherwise, sr cannot be met.
• In case sr belongs to Type II: if f p(F ) < / ≤ cF (i.e.
the predicted failure probability of failure types F of thecomposed service is less than/less than or equal to cF ,respectively), sr is satisfied. Otherwise, sr cannot be met.
• The set of reliability requirements SR is satisfied if all
sr ∈ SR are satisfied. Otherwise, SR cannot be met.
Fig. 7 shows an example of a tabular presentation of prediction results. In this example, AS = {{F1 } , {F2 } , {F1 , F2 }}(where {F1 , F2 } is the concurrent presence of two failure types

D. Implementation
We have implemented RMPI-SerComp as a Java library. As
described above, framework integrators can utilize this library
to develop different translator and generator plug-ins as wellas to programmatically trigger RMPI-SerComp’s prediction
workflow. The library also supports publishing the prediction
workflow as a SOAP-based web service. This service canbe invoked remotely and returns presentations of prediction
results to its callers.
The implementations of RMPI-SerComp is open source andavailable at our project website [35].
VI. C ASE S TUDY E VALUATION
A. Evaluation Goals
This section serves to validate the applicability of ourapproach. The goals of the validation are to (i) demonstrate
RMPI-SerComp’s capability in integrating the reliability prediction according our recommended process (see Section IV)
into a service composition framework and (ii) provide a rationale for the validity of RMPI-SerComp’s prediction workflow.
B. Framework Integration
The system chosen for the case study is a workflow system. It allows designing and executing workflows in which
different activities (e.g. web services, Java objects, publishedworkflows, ...) are orchestrated to solve business problems.
Although different activity types can be employed in aworkflow, in this case study, we focus on the parts of thesystem (i.e. its architecture and functionality) that are involvedin compositions of web services and therefore describe only
these parts. Fig. 8 shows an extract of the involved systemarchitecture. Component ActivityRepository manages information about the existing web services including external web
services as well as internal ones (i.e. workflows published as
7

START

SolutionBuilder

WorkflowEngine

END
inputReliabilityRequirements
AndUsageProfiles

ExternalService ...

Reliability
requirements

Usage profiles

ActivityRepository

Different presentationsof prediction results

Fig. 8. The workflow system’s architecture3

web services). In addition to the workflow management capability, component WorkflowEngine also provides an execution
environment for executing, testing, and debugging workflows.
Component SolutionBuilder enables composing from existing
web services via its user interface.
The workflow system does not include any support for
reliability predictions. We utilized the capability of the systemitself to develop two supporting workflows:• Workflow inputFailureModels is used to provide additionally failure models for existing web services.
• Workflow inputReliabilityRequirementsAndUsageProfiles
is used to provide additionally reliability requirements
and usage profiles for the composed service.
Utilizing RMPI-SerComp as the Java library4 , we developed
and then registered with the library four prototype plug-ins:
one input translator plug-in, named WorkflowTranslator, andthree feedback generator plug-ins, named TextualGenerator,
TabularGenerator, and HybridGenerator. The translator plugin is to translate XML-based inputs (see Section V-B) fromthe workflow system into a valid input model for RMPI. The
three generator plug-ins are to generate textual, tabular, andhybrid presentations of the prediction results, respectively (seealso Section VI-C).
We also utilized the library to publish RMPI-SerComp’s
prediction workflow as a SOAP-based web service and developed one more supporting workflow, named predictReliability,
for invoking this web service to obtain different presentationsof prediction results. With all the there supporting workflows, our recommended reliability-aware service composition
process (see Section IV) has been realized in the workflow
system as shown in Fig. 9 (Several parts of the process areomitted for the sake of clarity). In the process, the service
composer uses workflow predictReliability to obtain a textual,tabular, or hybrid presentation of prediction results of thecomposed service as feedback. In other words, the workflow
system has been integrated with the reliability prediction
capability. As a result, RMPI-SerComp has demonstrated its
capability in integrating the reliability prediction according ourrecommended process into a service composition framework(Goal (i) in Section VI-A).

predictingReliability

...

...

START

Servicecomposer

END

Concretecomposition workflow

Service failure
modelsinputFailureModels
START

END

Fig. 9. Reliability-aware service composition process in the workflow system.

S4
1
Fork

Join

[aboutPendingDocuments=true]
S5
1

S8

?

Decision2\2

S3[requestType=generate]?

S6
Decision1

S1
Start

End

!

\
FailureHandlingNode

S7
numberOfRecentReports
2
S2
BeginLoop

EndLoop

Fig. 10. The reporting service in the workflow system’s modeling notation.

generating reports about pending or released documents. The
reliability of this service and its variants has been analyzed in
our former study [9] using RMPI.
Using the modeling notation of the workflow system (i.e.
using service composition workflows), Fig. 10 presents thereporting service’s variant in which only the multi-try-catch
fault tolerance mechanism is used (i.e. variant Only MTCS
in the former study) as an example. Services from S1 to S8
in this service composition workflow correspond to internal
activities from a1 to a8 in component implementations of thereporting service when modeled using RMPI.
Service S1 handles incoming report requests from clients.

C. Validity of RMPI-SerComp’s Prediction Workflow
To achieve Goal (ii) in Section VI-A, we take the reporting service of a document exchange server, which allows
4 For a full documentation and examples, refer to our project website [35]8TABLE I
T WO U SAGE P ROFILES FOR THE R EPORTING S ERVICE .
No.
1Probability
0.8

2

0.2

Informationp(requestType=generate)=0.78
p(aboutPendingDocuments=true)=0.56
average(numberOfRecentReports)=2p(requestType=generate)=0.25
p(aboutPendingDocuments=true)=0.47
average(numberOfRecentReports)=4

TABLE IIR ELIABILITY R EQUIREMENTS FOR THE R EPORTING S ERVICE .
Reliability requirements
Reliability >= 0.996
Failure probability of {FP1,FP2} < 0.0006
Failure probability of {FS2} <= 0.0006

Gateway Decision1 operates as a branching structure: if an
incoming request is about generating a new report (requestType=generate), the gateway directs the control and data flow
along its above link; otherwise (i.e. the incoming request isabout viewing recently generated reports), the gateway directs
the flow along its below link. Two gateways BeginLoop and
EndLoop form a looping structure with numberOfRecentReports as its loop count and using service S2 to get a recently
generated report. Service S3 generates the skeleton for therequested report. Gateway Decision2 directs the control anddata flow along its above link if the requested report is aboutpending documents (aboutPendingDocument=true); otherwise
the gateway directs the flow along its below link. Gateways
Fork and Join form a parallel structure using services S4 and
S5 to get information about pending documents which areattached in emails and stored in file systems, respectively.
Service S6 gets information about released documents fromthe logs. Gateway FailureHandlingNode has the ability tohandle a signaled failure of service S6 and then directs thecontrol and data flow to service S7 to get information about
released documents from the database instead. With all thenecessary information about documents, service S8 fills thecontent for the requested report.
For this case study, we reused the failure models of corresponding internal activities from the former study as the failure
models for services from S1 to S8 . We also created two usage
profiles to model the same usage scenarios of the reporting
service as in the former study. Table I shows these usage
profiles. They mean that with probability 0.8, clients access thereporting service with usage profile 1 and with probability 0.2,
they access with usage profile 2. Each usage profile contains
two probabilities and one average to determine the branchingprobabilities at two gateways Decision1 and Decision2 , andthe average number of loops at gateway BeginLoop.
We set the reliability requirements for reporting service as
in Table II. The reliability of the reporting service is required
to be greater than or equal to 0.996. It is required that failure
probability of failure types {FP1,FP2} is less than 0.0006.
The failure probability of failure type {FS2} is required to be

Fig. 11. Hybrid presentation of the prediction results of the reporting service.

less than or equal to 0.0006.
By following the process in Fig. 9, we obtained different
presentations of the prediction results of the reporting service’svariant. Fig. 11 shows the hybrid (including textual, tabular,
and graphical) presentation as an example. All the prediction
results are exactly the same as those of the former study. As
the predicted reliability of the reporting service’s variant is
0.995938266 < 0.996, the first requirement cannot be satisfied,leading to a conclusion that “Given reliability requirements
cannot be met.”. {FS1} and {FS3} are the most frequent failure types, therefore, in order to achieve the first requirement,
the service composer may recognize the need to introduce fault
tolerance mechanisms for these failure types or to exchange
services S1 , S3 , or S8 , which cause these failure types, withmore reliable candidates.
All of the above results give evidence that RMPI-SerComp’s
prediction workflow, along with the plug-ins, gives accuratepresentations of prediction results in this case.
VII. A SSUMPTIONS AND L IMITATIONS
The reliability prediction integrated into service composition
frameworks via utilizing RMPI-SerComp is entirely poweredby RMPI. Therefore, it shares the same set of assumptions
and limitations with RMPI. For example, RMPI assumed that
reliability-related behaviors of parallel branches of a parallel
structure are independent, hence if the composition workflow
of a composed service includes a parallel structure where theassumption is violated, then the integrated reliability prediction
could lead to incorrect prediction results. We refer to ourformer work [9] for a detailed discussion of the assumptions
and limitations of RMPI as well as techniques to relax them.
9

VIII. C ONCLUSION[15] A. Immonen and E. Niemelä, “Survey of reliability and availability prediction methods from the viewpoint of software architecture,” Softwareand Systems Modeling, vol. 7, no. 1, pp. 49–65, 2008.
[16] M. Lyu, Handbook of software reliability engineering. IEEE Computer
Society Press, 1996.
[17] R. C. Cheung, “A user-oriented software reliability model,” IEEE Trans.
Softw. Eng., vol. 6, no. 2, pp. 118–125, 1980.
[18] V. Cortellessa and V. Grassi, “A modeling approach to analyze theimpact of error propagation on reliability of component-based systems,”
in CBSE, 2007, pp. 140–156.
[19] A. Filieri, C. Ghezzi, V. Grassi, and R. Mirandola, “Reliability analysis
of component-based systems with multiple failure modes,” in Proceedings of the 13th international conference on Component-Based Software
Engineering, ser. CBSE’10, 2010, pp. 1–20.
[20] W.-L. Wang, D. Pan, and M.-H. Chen, “Architecture-based software
reliability modeling,” J. Syst. Softw., vol. 79, no. 1, pp. 132–146, 2006.
[21] V. S. Sharma and K. S. Trivedi, “Reliability and performance of component based software systems with restarts, retries, reboots and repairs,” inProceedings of the 17th International Symposium on Software Reliability
Engineering. IEEE Computer Society, 2006, pp. 299–310.
[22] ——, “Quantifying software performance, reliability and security: An
architecture-based approach,” J. Syst. Softw., vol. 80, no. 4, pp. 493–509,
2007.
[23] M. W. Lipton and S. S. Gokhale, “Heuristic component placement
for maximizing software reliability,” in Recent Advances in Reliability
and Quality in Design, ser. Springer Series in Reliability Engineering.
Springer London, 2008, pp. 309–330.
[24] R. H. Reussner, H. W. Schmidt, and I. H. Poernomo, “Reliability
prediction for component-based software architectures,” J. Syst. Softw.,
vol. 66, no. 3, pp. 241–252, 2003.
[25] F. Brosch, H. Koziolek, B. Buhnova, and R. Reussner, “Architecturebased reliability prediction with the Palladio Component Model,” IEEE
Transactions on Software Engineering, vol. 38, no. 6, pp. 1319–1339,
2012.
[26] L. Cheung, R. Roshandel, N. Medvidovic, and L. Golubchik, “Early
prediction of software component reliability,” in Proceedings of the 30th
international conference on Software engineering. Leipzig, Germany:
ACM, 2008, pp. 111–120.
[27] S. Yacoub, B. Cukic, and H. H. Ammar, “A scenario-based reliability
analysis approach for component-based software,” IEEE Trans. on
Reliability, vol. 53, pp. 465–480, 2004.
[28] V. Cortellessa, H. Singh, and B. Cukic, “Early reliability assessment of
UML based software models,” in Proceedings of the 3rd international
workshop on Software and performance. Rome, Italy: ACM, 2002, pp.
302–309.
[29] P. Popic, D. Desovski, W. Abdelmoez, and B. Cukic, “Error propagationin the reliability analysis of component based systems,” in 16th IEEE
International Symposium on Software Reliability Engineering (ISSRE
2005)., 2005, pp. 53–62.
[30] K. Goseva-Popstojanova, A. Hassan, A. Guedem, W. Abdelmoez,
D. Nassar, H. Ammar, and A. Mili, “Architectural-level risk analysis
using UML,” IEEE Transactions on Software Engineering, vol. 29,
no. 10, pp. 946 – 960, 2003.
[31] G. Rodrigues, D. Rosenblum, and S. Uchitel, “Using scenarios topredict the reliability of concurrent component-based software systems,”
in Proceedings of the 8th international conference on Fundamental
Approaches to Software Engineering. Berlin, Heidelberg: SpringerVerlag, 2005, pp. 111–126.
[32] V. Grassi, R. Mirandola, and A. Sabetta, “Filling the gap between
design and performance/reliability models of component-based systems:
A model-driven approach,” Journal of Systems and Software, vol. 80,
no. 4, pp. 528–558, 2007.
[33] T.-T. Pham, F. Bonnet, and X. Défago, “Reliability prediction forcomponent-based software systems with architectural-level fault tolerance mechanisms (Extended version),” Journal of Wireless Mobile
Networks, Ubiquitous Computing, and Dependable Applications, vol. 5,
no. 1, pp. 4–36, 2014.
[34] A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr, “Basic concepts
and taxonomy of dependable and secure computing,” IEEE Trans.
Dependable Secur. Comput., vol. 1, no. 1, pp. 11–33, 2004.
[35] (2015) Reliability modeling, prediction, and improvements. [Online].
Available: http://rmpi.codeplex.com/

In this paper, we presented RMPI-SerComp to offer enhanced integration support into service composition frameworks for RMPI, our recent model-based reliability prediction
technique. With RMPI-SerComp, service composition frameworks can realize our recommended reliability-aware service
composition process, enabling a systematic consideration ofservice reliability during composing without requiring specialist knowledge of the underlying prediction method. RMPISerComp offers a public API and a plug-in architecture forflexible and reusable integrations into service composition
frameworks. Via a case study, we demonstrated the applicability of our approach by utilizing RMPI-SerComp to enhance a
service composition framework with the reliability prediction
capability according to our recommended process.
We plan to continue enhancing RMPI-SerComp, to include pre-installed translator and generator plug-ins for RMPISerComp, and to validate further our approach. These extensions will further increase the applicability of our approach.
ACKNOWLEDGMENTS
We are grateful to François Bonnet, JAIST, for his invaluable comments that greatly helped improve this manuscript.
R EFERENCES[1] T. Erl, P. Chelliah, C. Gee, J. Kress, B. Maier, H. Normann, L. Shuster,B. Trops, C. Utschig, P. Wik et al., Next Generation SOA: A Concise
Introduction to Service Technology & Service-Orientation. Pearson
Education, 2014.
[2] Microsoft.
(2013)
BizTalk
Server.
[Online].
Available:
http://www.microsoft.com/biztalk/[3] Oracle.
(2014)
OracleBPM.
[Online].
Available:
http://www.oracle.com/us/technologies/bpm/[4] JBoss. (2015) jBPM. [Online]. Available: http://jboss.org/jbpm/[5] V. Grassi, “Architecture-based reliability prediction for service-oriented
computing,” in Architecting Dependable Systems III, ser. Lecture Notes
in Computer Science. Springer Berlin Heidelberg, 2005, vol. 3549, pp.
279–299.
[6] V. Cortellessa and V. Grassi, “Reliability modeling and analysis ofservice-oriented architectures,” in Test and Analysis of Web Services.
Springer Berlin Heidelberg, 2007, pp. 339–362.
[7] Z. Zheng and M. R. Lyu, “Collaborative reliability prediction of serviceoriented systems,” in Proceedings of the 32nd ACM/IEEE International
Conference on Software Engineering - Volume 1. Cape Town, South
Africa: ACM, 2010, pp. 35–44.
[8] B. Klatt, F. Brosch, Z. Durdik, and C. Rathfelder, “Quality prediction
in service composition frameworks,” in Service-Oriented Computing- ICSOC 2011 Workshops, ser. Lecture Notes in Computer Science.
Springer Berlin Heidelberg, 2012, vol. 7221, pp. 131–146.
[9] T.-T. Pham, X. Défago, and Q.-T. Huynh, “Reliability prediction forcomponent-based software systems: Dealing with concurrent and propagating errors,” Science of Computer Programming, vol. 97, Part 4, no. 0,
pp. 426 – 457, 2015.
[10] M. Edwards. (2011) Service component architecture. [Online].
Available: http://www.oasis-opencsa.org/sca/[11] R. Cortez and A. Vazhenin, “Virtual model-view-controller design
pattern: Extended mvc for service oriented architecture,” IEEJ Trans.
on Electronics, Sec. TEEE C, Info. and Sys., vol. 10, no. 4, 2015.
[12] A. Strunk, “QoS-Aware Service Composition: A Survey,” in IEEE 8th
European Conference on Web Services (ECOWS), 2010, pp. 67–74.
[13] K. Goseva-Popstojanova and K. S. Trivedi, “Architecture-based approaches to software reliability prediction,” Computers and Mathematics
with Applications, vol. 46, no. 7, pp. 1023–1036, 2003.
[14] S. S. Gokhale, “Architecture-based software reliability analysis:
Overview and limitations,” IEEE Trans. Dependable Secur. Comput.,vol. 4, no. 1, pp. 32–40, 2007.

10