INTERFACE EXPRESSIONS MONITORING FOR BPEL

PROCESSES

Wassim Jendoubi, Guy Tremblay and Aziz Salah

ept. d’informatique, UQAM, C.P. 8888, Succ. Centre-Ville, Montr

eal, QC, H3C 3P8, Canada

Keywords:

BPEL processes, Run-time monitoring, Interface protocols, Regular expressions.

Abstract:

In this paper, we show how Web services descriptions can be extended with simple declarative behavior

speciﬁcation using interface expressions, a form of regular expressions that describe the possible sequences of

externally observable events that a WS-BPEL process can perform.

We describe how a concrete (executable) WS-BPEL process can be monitored with respect to such interface

expressions, to ensure that it satisﬁes its associated abstract speciﬁcation or to detect the occurrence, or non-

occurrence, of some particular sequences of events. More speciﬁcally, we describe the implementation of such

a run-time monitor, called BPEL.RPM, that uses the Open ESB BPEL service engine.

1 INTRODUCTION

In this paper, we show how BPEL Web services de-

scriptions can be extended with simple declarative be-

havior speciﬁcations using a notation, similar to reg-

ular expressions, called “interface expressions.” We

also describe an architecture for monitoring, at run-

time, a BPEL service implementation with respect to

such interface expressions. Such a monitor can detect

the occurrence of particular sequences of operations

with respect to an interface expression, whether this

expression speciﬁes a “complete” contract, a partic-

ular sub-behavior, or a behavior that should not be

observed.

2 WEB SERVICES INTERFACES

AND PROTOCOLS

WS-BPEL (Andrews et al., 2003) is a notation for de-

scribing business processes implemented as orches-

tration of Web services.

A WS-BPEL description consists of two key parts:

static interface and dynamic behavior. The static in-

terface describes the various types of messages ex-

changed by the service as well as the collection of op-

erations provided or required by the service. The dy-

namic behavior is described operationally, using typ-

ical (imperative) control structures.

The static interface describes a service as a col-

lection of operations that can be invoked in any par-

ticular order, much like a Java interface. Thus, it

does not describe the allowable conversations, i.e.,

the sequences of messages that can be ou should be

exchanged between a client and a service. Such a dy-

namic interface speciﬁcation is called a protocol.

Various notations can be used to describe proto-

cols (Clements and al., 2003), e.g., UML’s sequence,

communication or state transition diagrams, regu-

lar expressions, abstract WS-BPEL processes, etc.

Figure 1 shows the key elements of one such no-

tation, called interface expressions (Tremblay and

Chae, 2005).

ˆ Start of process

$ End of process

any Arbitrary message (wildcard)

in:m Reception of m

out:m Sending of m

outIn:m Synchronous invocation of m

e1; e2 Execution of e1 followed by e2

e1 [] e2 Choice between e1 and e2

e1 || e2 Arbitrary interleaving of e1 and e2

e? Optional element (0 or 1 occurrence of e)

e* Repetition (0, 1 or many occurrences of e)

e+ Repetition (1 or many occurrences of e)

Figure 1: Notation for interface expressions.

131

Jendoubi W., Tremblay G. and Salah A..

INTERFACE EXPRESSIONS MONITORING FOR BPEL PROCESSES.

DOI: 10.5220/0003319001310134

In Proceedings of the 7th International Conference on Web Information Systems and Technologies (WEBIST-2011), pages 131-134

ISBN: 978-989-8425-51-5

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

3 AN ARCHITECTURE FOR

MONITORING WEB SERVICES

BEHAVIOR

Run-time software monitoring can be used for various

purposes, e.g., proﬁling, performance analysis, fault-

detection, etc. (Delgado et al., 2004). In this paper,

we propose a run-time monitor for behavior detection

that can also be used for software-fault detection.

Figure 2: Overall architecture of our BPEL run-time moni-

toring system.

Figure 2 shows the overall architecture of our

BPEL run-time monitoring system, expressed in a

style similar to the one used by Delgado et al. Our

architecture allows for the monitoring of various pro-

tocols expressed as interface expressions. The moni-

tor notiﬁes, dynamically, when a speciﬁc behavior has

been detected—or when it cannot be detected.

The architecture we propose is independent of the

speciﬁc BPEL engine used for running the BPEL pro-

cesses. This architecture is also customizable and ex-

tensible with respect to how the monitor reacts when

a behavior is detected.

We allow the monitoring of a process against var-

ious interface expressions, possibly all independently

and simultaneously. Thus, given a process and a

speciﬁc interface expression, there will be a speciﬁc

monitor instance whose role will be to monitor the

expected behavior.

4 MONITORING WS-BPEL

PROCESSES USING BPEL.RPM

Figure 3 shows the overall structure of BPEL.RPM

(BPEL Run-time Process Monitoring), a concrete im-

plementation of the run-time monitoring architecture

described earlier.

BPEL.RPM is composed of three key compo-

nents:

• An Event Observer, which is speciﬁc to a particu-

lar execution engine.

• An Analyzer, which analyzes the various events

as they occur and match them with respect to a

speciﬁed interface expression.

• An Action Handler, which reacts according to

some user-deﬁned policy when a speciﬁc behav-

ior is detected.

4.1 Interface Expression Speciﬁcation

We showed earlier (Figure 1) an abstract notation for

interface expressions, used to specify behavior proto-

cols. In BPEL.RPM, we use a mixed regular expres-

sions and XML representation, where a Protocol is

characterized by two key elements:

• MonitoredActivities: The set of activities from

the BPEL process which are monitored. Thus, an

event associated with a BPEL activity not in this

set is ignored.

• InterfaceExpr: The interface expression repre-

senting the behavior to be monitored. The out-

come (verdict) of monitoring depends on the

value of the Excludes attribute:

– Excludes="no": Monitoring succeeds when

an instance of the behavior speciﬁed by the

InterfaceExpr is detected, and fails when it

deﬁnitively cannot satisfy it. This case is typi-

cally associated with an explicit contract spec-

iﬁcation, but can also be used for identifying

interesting sub-sequence of events, e.g., as re-

quired for intrusion detection.

– Excludes="yes": Monitoring succeeds when

the observed behavior does not match the in-

terface expression, and fails when it matches.

Monitoring using interface expression is simi-

lar, although not identical, to searching a stream

using grep. The key difference is that whereas

grep processes a stream of independent lines, the

monitor behaves as though it processes a stream of

incrementally-built sequences of events; that is, each

new event is added to the trace, which is then matched

against the pattern. Also, when the pattern does not

contain an explicit “end of process” marker (“$”), an

occurrence of the match will be signaled as soon as an

appropriate sequence of events is encountered. Thus,

an interface expression such as “a;b;c” is not exactly

the same as “ˆ.*;a; b;c;.*$”—in the latter case, a

success (as well as a failure) would be signaled only

when the monitored process terminates—, whereas

they would be equivalent in the grep case.

Both are instances of safety properties (Schneider,

2000), as the interface expression and the trace are ﬁnite.

WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies

132

Event Observer

Analyzer

socket

Observer

Server

Protocol

Analyzer

Event

Analyzer

Action

Handler

BPEL

Protocol

<.../>

Xml

event

message

--->Started :

in:SimpleAuctionServiceOp...

--->Stepped :

outIn:bidingSeller@Seller...

--->Stepped :

outIn:getBuyerOffer@Buyer...

--->Stepped :

outIn:bidingSeller@Seller...

BPEL.RPM

automaton

event

Observer

Client

Open ESB

Figure 3: Concrete implementation of BPEL.RPM.

4.2 Event Observer

The event observer component identiﬁes the concrete

events from the BPEL process that might be of inter-

est, and then transmits those events to the analyzer

component. Its implementation depends on the spe-

ciﬁc BPEL engine being used. In BPEL.RPM, we

use BPELSE, the Open ESB (Open Enterprise Ser-

vice Bus)

BPEL Service Engine.

BPELSE allows to dynamically register informa-

tion about running BPEL process instances. This in-

formation is registered in bpelseDB, a database asso-

ciated with the BPEL process engine. To use this

database, we deﬁned a database trigger, so that when-

ever information about an event is written in the

database, an associated stored procedure is executed.

This procedure transmits the information about the

event to the monitoring component, using a socket

connection, as illustrated in Figure 4, information

which is then mapped into an appropriate BPEL ac-

tivity.

BPEL SE

BPEL Event

bpelseDB

Trigger

UDF

Observer

Client

Socket

Open ESBBPEL.RPM

Observer Server

Event Observer

Figure 4: Implementation of BPEL.RPM event observer

component.

http://open-esb.java.net/

4.3 Analyzer

The analyzer is BPEL.RPM’s key component. Its

role is to keep track of the various events as they oc-

cur and to verify the correspondence between those

events and the patterns to be detected, as expressed

by the interface expressions. To perform this task, the

component proceeds as described in the following—

Figure 5 shows its overall implementation.

Analyzer

Event

Analyzer

Protocol

Analyzer

dk.brics

.autom

aton

monitored event

regular

expression

automaton

protocol

Figure 5: Implementation of BPEL.RPM analyzer.

First, the interface expression relative to which a

process is to be monitored is transformed into an ap-

propriate ﬁnite state automaton. A mapping of the

automaton symbols into process activities is also cre-

ated. These steps are performed by the protocol an-

alyzer (Figure 5). The automata is created using the

dk.brics.automaton

Java package, which provides

deterministic as well as non-deterministic automata

implementation with support for standard regular ex-

pression operations.

Once the automata has been created, event ana-

lyzing and monitoring can then begin. Whenever an

http://www.brics.dk/automaton

INTERFACE EXPRESSIONS MONITORING FOR BPEL PROCESSES

133

event occurs, the analyzer proceeds as follows:

• The analyzer retrieves the activity associated with

the event;

• If the event activity is not one of the activities to

be monitored, the event is simply ignored. Other-

wise, if the activity is indeed one of those being

monitored, then:

– The event is added to the execution trace;

– The state of the automata is advanced according

to the received event;

– Based on the resulting automata state, callbacks

to the action handlers are performed.

Various action handlers (i.e., views) can be asso-

ciated with a speciﬁc monitor instance (i.e., model).

We use the “Observer Pattern” to decouple the ac-

tion handlers from the monitor per se, where the re-

quired callbacks are performed through an appropri-

ate MonitorListener interface.

4.4 Action Handler

The run-time action handler component’s purpose is

to encapsulate a speciﬁc reaction strategy with respect

to the monitored protocol. We allow four different

types of responses (notiﬁcations) depending on the

state of the protocol:

• When monitoring of the protocol is initiated;

• When an event occurs so that the protocol state

must be changed;

• When the protocol successfully reaches comple-

tion;

• When the protocol fails.

In our current prototype implementation, we use

a simple reaction strategy, namely, we simply log

the various events. However, more complex reaction

strategies are possible, including interacting with the

BPEL engine through the BPEL Management API

5 CONCLUSIONS AND FUTURE

WORK

In this paper, we presented a concrete implementa-

tion of a run-time monitor for WS-BPEL concrete

processes. Monitoring is performed with respect to

interface expressions, a form of regular expressions

that emphasize externally observable behavior, much

like behavior protocols allow for software compo-

nents (Plasil and Visnovsky, 2002). Such interface

http://ode.apache.org/bpel-management-api-

speciﬁcation.html

expressions can express the overall dynamic inter-

face speciﬁcation of a process as well as particular

sequences of events of interest.

A limitation of interface expressions is that they

abstract from the operations’ arguments. Thus, all in-

vocations (resp., reception) of a given operation from

a speciﬁc partner link are represented by the same

symbol. As future work, we plan to extend our ex-

pressions with message arguments speciﬁcation.

REFERENCES

Andrews, T., et al. (2003). Business process execution

language for web services (BPEL4WS) version 1.1.

http://www-128.ibm.com/developerworks/library/ws-

bpel.

Clements, P. and al. (2003). Documenting Software Archi-

tectures: Views and Beyond. Addison-Wesley.

Delgado, N., Gates, A., and Roach, S. (2004). A taxon-

omy and catalog of runtime software-fault monitoring

tools. IEEE Transactions on Software Engineering,

30(12):859–872.

Plasil, F. and Visnovsky, S. (2002). Behavior protocols

for software components. IEEE Tran. Soft. Eng.,

28(11):1056–1076.

Schneider, F. (2000). Enforceable security policies. ACM

Trans. Inf. Syst. Secur., 3(1):30–50.

Tremblay, G. and Chae, J. (2005). Towards specifying con-

tracts and protocols for Web services. In MCETECH

’05, pages 73–85.

WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies

134