Professional Documents
Culture Documents
State of The Art
State of The Art
Le Duc Bao
This document presents the research and development state of the subject mon-
itoring composition of services.
1 Introduction:
In recent years, the rising of Service Oriented Computing brings researchers
to new challenges diversity from message exchange format to composition of
services, from infrastructure to quality of services. This emerging approach
addresses the requirements of loosely coupled, standards-based, and protocol-
independent distributed computing. It requires functional as well as non-functional
characteristics. Functional characteristics include operational characteristics
that dene the overall behavior of the service while non-functional character-
istics include service availability, reliability, scalability, security, authorization,
authentication, integrity, performance characteristics.
In the SOA paradigm, being the atomic unit, the service is self-contained soft-
ware module that performs a single business task. It is described in terms
of a service description language, e.g., WSDL. The composition of services is
integration of heterogeneous services to conduct the business processes. It is
orchestrated in a business process language which focuses in the functional as-
pect of business requirements. The lack of non-functional description in the
language is the separation of concerns which keeps its simplicity. A runtime
monitoring, being used to observe system healthy, to serve a automated process
or to evaluate business contract between partners, is required to ll this gap[8].
Monitoring problem
In high-level architecture of monitoring composition of services (gure 1), the
composed services is dened in business process modeling language (BPML),
e.g., BPEL, which allows one to tailor the distributed services. It is executed
by the process execution engine (PEE), e.g., ActiveBPEL[12], which invokes the
distributed services specied in the description of composition and follows the
dened business process. The monitoring service, concentrates in the control
aspect of SOA, consists of the monitoring requirement and monitoring engine.
The monitoring language allows one to represent the monitoring requirement
which is a part of the business contract. Monitoring requirements, such as QoS
1
Figure 1: High level architecture
Criteria
1. Separation of concerns and non-intrusiveness : the monitoring language
should be well separated from functional (what composition does) and
non-functional (how composition works) aspects (separation of concerns).
Further, the monitoring engine should be independent from the BPM ex-
ecution engines (levels of abstraction), from the contract denitions.
2. Expressiveness : it allows to monitor the business contract in dierent
levels[1]. It also has sensors to capture dierent events and characteris-
tics (functional/non-functional/temporal) for any need of the monitoring
requirements.
3. Autonomic capacity : it should provide a (intelligent) mechanism, a strat-
egy to feedback/react the process execution engine or negotiate with other
participants in runtime. It works in the way self-conguration, self-adaptation
and self-healing, self-monitoring and self-tuning, and so on, often under
the ag of self-*.
2
Figure 2: The activity diagram of TBS
2 Case study
This case study is extracted from[9] with some minor modication. Consider
a Web-based travel booking system (TBS) that acts as a broker oering its
customers the ability to book all aspects of a trip. The workow of TBS in-
cludes credit validation, ight/hotel/car reservation, and communication with
the client. Customers can submit data about their desired travel plans and re-
ceive either a conrmation number or a failure message depending on whether
the travel arrangements have been made successfully.
The activity diagram in gure 2 shows high-level steps that are executed during
the travel booking process. To fulll its business goal, TBS needs to interact
with several partners: FlightReservationService, which books a ight, Hotel-
ReservationService, which reserves a hotel room, CarReservationService, which
3
makes a car reservation, CreditCardCheckingService, which validates the cus-
tomer's credit card data, and the CustomerService which enables to get travel
data, inform and conrm booking status to customer. In a typical scenario, an
Internet customer begins an interaction with TBS by entering data for his/her
travel arrangements. The system then invokes recursively three reservations,
for the car, hotel and ight for each vacation stage. If all of the reservations
are completed successfully, it invokes the CreditCardCheckingService. If the
credit card is valid, then a conrmation number is generated and returned to
the customer.
The table 1 shows requirements for TBS
Id Requirement
R1 If the execution time from getTravelData to the success of Credit
Card Checking Service (CCCS) is greater than 40 seconds then
alert to admin.
R2 If average execution time from getTravelData to the success of
CCCS is greater than 30 seconds then stop the TBS process and
call the reporting service.
R3 The credit service starts if and only if there is at least one reser-
vation service (ight, hotel or car) successfully complete.
3 P. Traverso et al
This approach[2, 14] proposes a solution to monitor web services implemented in
BPEL. The monitoring language is the Runtime Monitor specication Language
(RTML) solidly based on Past Linear Temporal Logics (LTL). The architecture
supports message-level monitoring.
4
R1:time(cause(check_credit.state = SUCC) S msg(get_travel_data.input
= startBooking)) > 40
R2:avrg (time(cause(check_credit.state = SUCC) S msg(get_travel_data.input
= startBooking))) > 30
msg (check_credit.input = startPayment) implies O (cause(ight_reservation.state
R3:
= SUCC)) | O (cause(hotel_reservation.state = SUCC)) | O (cause(car_reservation.state
= SUCC))
Denoted that the "cause(link.var = val)" means all events that cause variable
var of BPEL process link to assume value val. This language does not allow to
express the reaction (then clause) when the monitoring expression is reached.
Discussion: This approach allows for a clear separation of the service business
logic from the monitoring functionalities. The mediator separate the monitoring
architecture and process execution engine. Further, it provides monitoring in
message-level with a set of events, runtime properties and statistical properties.
This approach also presents some drawbacks such as the small set of build-in
functions is not extensible and can be dicult to express all situations of real
business requirements. It lacks the autonomic capacity and the extensibility.
4 L. Baresi et al
The approach[3] proposes two Domain Specic Languages (DSL) for the de-
nition of constraints (WSCol) and recovery strategies (WSRel) to express the
monitoring requirement and a monitoring engine which is an AOP-based imple-
mented, a part of Dynamo project[6], as an extension for ActiveBPEL[12].
5
Figure 3: Traverso's Active BPEL engine extended with the runtime monitor
environment
6
we dene:
R1: post-condition :
let $t_get_tra_da = retrieve (processID, userID, instanceID, 0, get_travel_data/location,
$response_time, 1);
let $t_i_res = retrieve (processID, userID, instanceID, 0, ight_reservation/location,
$response_time, 1);
let $t_hol_res = retrieve (processID, userID, instanceID, 0, hotel_reservation/location,
$response_time, 1);
let $t_car_res = retrieve (processID, userID, instanceID, 0, car_reservation/location,
$response_time, 1);
let $t_chk_crd = retrieve (processID, userID, instanceID, 0, check_credit/location,
$response_time, 1);
$t_get_tra_da + max($t_i_res, $t_hol_res, $t_car_res) + $t_chk_crd
> 40;
recovery strategy : notify (notify_message, email);
R2: post condition : By the same way, replacing the last parameter of
retrieve function by a number of recent invoking of services and using the
avg function (e.g. avg ($rt in retrieve(processID, userID, instanceID, 0,
check_credit/location, $response_time, 20); $rt)).
recovery strategy : halt() & call (reporting_service_XSDL);
R3: This requirement can be done by using the dynamic invoker to retrieve
internal variable of BPEL process.
Monitoring engine: The monitoring engine[4] consists of: the AOP module
which is injected in process execution engine (e.g. ActiveBPEL) allows to dene
certain point-cuts which can capture runtime data and interfere the process
execution engine; external services collect external information; the translator
which translates monitoring rules and recovery strategies to JBoss Rule Engine
and monitoring objects; the recovery manager manages recovery tasks; the rule
storage contains the rule knowledge bases; and the monitor manager which
connects previous elements.
7
data collector. The DSL is strength to express dierent monitoring aspects. The
recovery mechanism presents the rst step to autonomic system. Moreover, the
declarative language WSCol is transformable to XML based language which is
compliant the standard WS-Policy framework[5].
Beside that, there are several disadvantages. The recovery language is limited
to certain pre-dened functions which can not satisfy the self-adaptation due to
runtime faults or violation of monitoring expression[7]. Further, the AOE-based
module presents a higher inter-module dependency with the PEE.
5 ORQOS
TODO
6 ConFract
ConFract[16, 17] aims to specify and to verify properties between Fractal soft-
ware components through several types of contract. The system divides contrac-
tual process in three phases. In the specication phase, a contract specication
is incrementally dened in Component Constraint Language for Java (CCL-J)
based on component composition specication. In the static verication phase,
the system dynamically builds contracts from specications and updates them
according to the dynamic reconguration. The cloture of contracts occurs when
all participants of contract are assembled. Then the system turns to dynamic
verication phase where contracts are observed by a contracting mecanisme
which takes in charge of monitoring and evaluation them. Therefore, these con-
tracts are rst classes entities during assembly and execution time. In the case
if a contract is violated, the system allows to (re)negotiate, or to dynamically
recongure, or to deal with particular strategies.
CCL-J, inspired by OCL[18] and enhanced to adapt Fractal component model, is
a executable assertion language. A design by contract-like[13] language, it sup-
ports pre-condition, post-condition, invariant. It also supports both functional
and non-functional properties in a contract. Contracts are divided into three
types which correspond to Fractal model: interface contracts are established on
the connection between two components, internal and external composition con-
tracts are respectively served to internal and external behaviour of components.
Participants of contracts take dierent roles, such as guarantor, contributor,
beneciary.
Implementation of ConFract replies on Fractal implementation and has inte-
grated at Julia - a Fractal implementation. It employes mixins technology to
intervene Fractal controller and certain intercepters to capture runtime data
which need for contract evaluation.
The framework clearly separates between composition aspects and contract as-
pects of a component system, and between contract specication and contract
execution. Beside that, it has some shortcoming: it does not support historical
8
data; it does support component instance, but "component class"; and it does
not support inheritance and less reusable contract.
There are many eort inspiring SLAs to SOA application in dierent levels:
WSOL
SWLA
SLAng
WS-Agreement
WS-Negotiation
8 Summary
Several researches have focused in the supervision of composed services while
concentrating in the separation of the functional and non-functional aspects.
The need of monitoring system, which adds non-functional services, is evident.
In both above studies, specic monitoring languages are dened to facilitate
the denition of non-functional business contract as well as to keep the BPML
9
clearly dedicated to process denition. Monitoring engines manage monitor-
ing requirements dened in monitoring language and cooperate with PEE to
accomplish its goals.
This two works do not attack elements of business process language such as
scopes and partners. The scope, provides a way to organize the activities within
the business process, is studied in [10]. The partner can be used to group certain
participants with the same policy. The Baresi's study provides a bit facilities
to work with such as priorities and trusted providers.
The monitoring language should be capable to work with runtime information
and to express business contracts. Runtime data varies from runtime process
events, runtime process properties, system properties that are required by the
business contract. The language should be exible to facilitate contract deni-
tions in dierent levels of complexity.
The monitoring engine should be well separated from the PEE. Architecturally,
it requires cooperation with the PEE in dierent levels in order to probe events,
non-functional data and to interfere business processes. Its coupling levels de-
pend on supports of the PEE. Moreover, the other concerns of the monitoring
engine, such as monitoring knowledge management, contract evaluation, and
external sensors, should be completely separated from PEE.
10
Figure 4: ws-gen architecture
4. ws-animator, an Eclipse plugin, plays the role actors to interact with the
composite process. It is useful at developing phase.
11
Figure 6: Example scenario of Composite Probes monitoring a clustered system.
</ p r o p e r t y>
<p r o p e r t y>
<property_type> c l a s s</ property_type>
<property_name>R2</ property_name>
<p r o p e r t y _ s p e c>
avg ( time ( c a u s e ( c h e c k _ c r e d i t . s t a t e = SUCC) S
msg ( g e t _ t r a v e l _ d a t a . i n p u t=s t a r t B o o k i n g ) ) ) > 30
</ p r o p e r t y _ s p e c>
<p r o p e r t y _ d e s c r i p t i o n>s e e R2</ p r o p e r t y _ d e s c r i p t i o n>
<process_name>TBS</ process_name>
</ p r o p e r t y>
</ monitor>
12
which is provided through external interfaces of a probe, is propagated down-
ward from to lower probes. A lter, being a sub-component of a probe, species
how the local data is processing for probe's outgoing data. It is useful for shar-
ing a sub-probe among its parents. A scheduler, being another sub-component
of a probe, triggers a process when a criterion, e.g. an interval, and threshold,
is reached.
Furthermore, CPs supports dierent communication protocols and management
protocols such as JMX, RMI.
CPs is implemented solidly based on Fractal model and CLIF moni-
toring framework.
CPs, an alternative solution behind at monitoring framework, facilitates col-
lecting and managing of probed data. It leaves the data manipulation due to
its exibility and extensibility.
References
[1] A. Beugnard, J.M. Jézéquel, N. Plouzeau, D. Watkins. Making Components
Contract Aware, Computer, July 1999
[3] L. Baresi and S. Guinea. Dynamo, Self-healing BPEL processes with Dy-
namo and the JBoss rule engine, International workshop on Engineering of
software services for pervasive environments, p.11-20, 2007
13
[9] Y. Gan, M. Chechik, S. Nejati, J. Bennett, B. O'Farrell, J. Waterhouse.
Runtime monitoring of web service conversations, IBM Centre for Advanced
Studies Conference archive, p.42 - 57, 2007
14