Monitoring Service Systems from a Language-Action Perspective

IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011 17

Monitoring Service Systems from
a Language-Action Perspective
William N. Robinson, Member, IEEE, and Sandeep Purao, Member, IEEE

Abstract—Business processes are increasingly distributed and open, making them prone to failure. Monitoring is, therefore, an
important concern not only for the processes themselves but also for the services that comprise these processes. We present a
framework for multilevel monitoring of these service systems. It formalizes interaction protocols, policies, and commitments that
account for standard and extended effects following the language-action perspective, and allows specification of goals and monitors at
varied abstraction levels. We demonstrate how the framework can be implemented and evaluate it with multiple scenarios that include
specifying and monitoring open-service policy commitments.

Index Terms—Monitoring, services, processes, language action, speech acts.

Ç

1 INTRODUCTION
1.1 Monitoring Software Systems
T HE exponential growth in the global economy is being
supported by service systems, realized by recasting
mission-critical applications as services accessed across
Monitoring software systems is closely tied to the monitor-
ing of requirements and how they are realized in software.

t.c om
om
organizational boundaries. Service-oriented architectures A monitor is a software system that “observes and analyzes

po t.c
and associated interoperability standards [1], [2] provide gs po
the behavior of another (target) system, determining
lo s
key enablers for these service systems. Their actual
.b og

qualities of interest, such as the satisfaction of the target
ts .bl

building and deployment, however, continues to be fraught system’s requirements” [8]. A requirements monitor deter-
ec ts

with problems: “most of our large software systems ... are mines the requirements status from a stream of significant
oj c
pr oje

now constructed as groups of interoperating systems (as input events [9]. A monitor is, then, a function that
re r
lo rep

systems of systems) ... made to interoperate through processes its input event stream to derive the status of
various forms of interfaces. Although we can conceive
xp lo

requirements. This characterization of monitors and mon-
ee xp

these large [service systems], we have trouble building itoring assumes an event, that is, “a significant action in
.ie ee

them” [3]. Anecdotal accounts of systems integration efforts
w e

time, typically modeled as instantaneous state change, e.g.,
w .i
w w

(e.g., [4], [5], [6], [7]) point to failures and underscore the completion of a method call, a CPU reaching 90 percent
:// w

need to address the underlying cause: rapidly changing
tp //w

utilization, a shipment arriving at a destination, or a person
ht ttp:

environmental forces. leaving their home” [8]. An event source presents a stream
These changes challenge assumptions, such as stability
h

of software event objects that represent their real-world
and predictability, where well-specified business processes (target) events. The central monitoring issues, therefore,
(with services to perform tasks) are identified in advance include: 1) event acquisition and 2) event analysis [8].
and are insulated from change. Instead, the open and Our research question, related to monitoring of service
distributed processes include tasks that are performed by systems, asks: how can one use service interaction events to
services that are not centrally controlled, and hence, can be understand a service system in terms of service policies? It
unpredictable. As a result, service outcomes themselves represents an instantiation of the more general question:
tend to be uncertain. Service monitoring, therefore, remains how can one use lower level runtime events to understand a
a significant challenge. The goal of this research is to system in terms of higher level requirements? This bridging
develop a framework for monitoring such service systems.
is facilitated by multiple abstraction layers (see Fig. 1). The
This paper presents the framework, establishes its feasi-
lowest layer captures message exchanges with protocols
bility, and evaluates it with scenarios and comparisons
such as SOAP or REST. They represent runtime events that
against existing proposals.
comply with a specification, e.g., the Secure Electronic
Transactions protocol. The middle layers capture event
. W.N. Robinson is with the Computer Information Systems Department, sequences following interaction policies, e.g., a buyer must
Georgia State University, RCB, 35 Broad St, Suite 927, Atlanta, GA provide payment for services. The highest level, then,
30302-4015. E-mail: wrobinson@gsu.edu. represents the monitor, which reports on the state of
. S. Purao is with the Information School, University of Washington, Seattle,
WA 98195, and the College of Information Sciences and Technology, specified policies, e.g., 95 percent of agents comply with
Pennsylvania State University, University Park, PA 16802. the service interaction policies. The selected ontologies and
E-mail: spurao@ist.psu.edu. analysis techniques affect the monitor’s ability to provide
Manuscript received 15 May 2009; revised 25 Feb. 2010; accepted 4 Apr. feedback. Together, these layers provide the potential for
2010; published online 26 Aug. 2010. effective monitoring.
For information on obtaining reprints of this article, please send e-mail to:
tsc@computer.org, and reference IEEECS Log Number TSCSI-2009-05-0134. The key contribution of this paper is the introduction of an
Digital Object Identifier no. 10.1109/TSC.2010.41. ontology of communicative acts into these abstraction layers
1939-1374/11/$26.00 ß 2011 IEEE Published by the IEEE Computer Society

18 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011

TABLE 1
Layered View of Web Service Standards [18]

Fig. 1. Abstraction layers for monitoring service systems.

to enhance policy specification and monitoring of service
systems. We develop this contribution as an extension to
prior work in monitoring, establish its feasibility, and
demonstrate it with multiple scenarios. conversation, thus, describes multistep exchanges of mes-
1.2 Service System Enablers sages performed by participants.
A prerequisite for this model, in the context of service
Service systems build upon the basic idea of software as a
systems, is a conversation policy [20], [21] that allows each
service [10], [11] that allows legacy and new applications to

t.c om
party to maintain its own record of the conversation’s state.

om
declare their capabilities in a machine-readable format [12].

po t.c
Realizing a conversation model, then, requires specification
Once deployed, the services can be linked to support cross- gs po
of conversation policies and the ability to transform these
lo s
functional business processes. Core standards for publish-
.b og

policies into messages that can facilitate the actual con-
ts .bl

ing (WSDL 2001), finding (UDDI 2005), and binding (SOAP versation. The conversations themselves are comparable to
ec ts

2003) provide key enablers for these service systems. discourses, whose elemental units include clauses and
oj c
pr oje

Prior work suggests Language-Action Perspective (LAP) discourse operators, i.e., communicative acts [22]. Other
re r
lo rep

as a theoretical foundation for a layered view [13], [14], [15] efforts related to this view of conversations include agent
xp lo

of these enablers. A building block in this perspective is a communications [23] (often restricted in scale), conversation
ee xp

speech act. It conceptualizes an utterance as the performance structures [24] (that ignores the semantic content), and
.ie ee

of a purposeful act. Several frameworks have been devel-
w e

service interaction and enterprise integration patterns [25]
w .i
w w

oped for LAP, such as business model patterns [16] and an (that focus on an operational perspective, relegating
:// w
tp //w

aggregative model [17]. Umapathy and Purao [18] synthe- message exchanges to a secondary role). Our use of
ht ttp:

size these into a framework for the web services standards communicative acts is different. We focus on their use for
h

space with three layers: a communication platform, the monitoring. The conversation models we envision, there-
communicative act itself, and the rational discourse. Table 1 fore, include communicative acts, which result in standard
maps the web service standardization initiatives against as well as extended effects, i.e., operations on commitments
this framework. and expectations of responses.
The table highlights a key sublayer not effectively Fig. 2 shows an example of a loan approval process that
addressed by existing standards: support for conversations uses the services: Customer, LoanApprover, and LoanPro-
between services, which can provide a loosely coupled, cessor. The process begins with the Customer sending the
peer-to-peer interaction model. Formalizing and represent- loan request. The LoanApprover receives the request and
ing such conversations among web services is central to invokes the LoanProcessor to process the application. The
understanding how monitors may be designed for services LoanProcessor sends approval information to the LoanAp-
and business processes in distributed, open environments. prover, who forwards it to the Customer. The tasks in the
process are achieved via two conversations between services:
1.3 Conversations among Web Services 1) Customer-LoanApprover, and 2) LoanApprover-Loan-
Current models for interactions among web services use a Processor. Specific communicative acts may be specified for
vending machine metaphor. WSDL port types and opera- each conversation, e.g., the task “check credit” may require:
tions resemble buttons, levers, and slots on a vending 1) asking for credit information about a customer; 2) re-
machine [18]. The WSDL does not reveal that one must sponding in the form of prepackaged information or refusing
deposit money in the slot before pushing any buttons. Web to send the answer; and 3) acknowledging receipt of the
Service choreography languages [19] attempt to solve this by answer. The figure highlights three important points. First,
giving instructions on which buttons to push in what order. processes can be modeled as a composition of conversations;
An alternative model is that of a telephone call, where two (or second, conversation protocols can be specified for services;
more) parties set up a session, exchange messages in that and third, conversations provide the possibility for monitor-
context, and then, finally, close it. Each message is ing at different levels of granularity and temporality. The next
interpreted in relation to those previously exchanged. A section elaborates these ideas further.

ROBINSON AND PURAO: MONITORING SERVICE SYSTEMS FROM A LANGUAGE-ACTION PERSPECTIVE 19

t.c om
om
po t.c
gs po
lo s
.b og

Fig. 3. A purchasing process (from [28]).
ts .bl
ec ts

with how a designer might specify the process by combining
oj c

Fig. 2. Service, conversations, and processes.
pr oje

protocols [32].
re r
lo rep

2 BACKGROUND To illustrate protocol specification, we draw on a
xp lo

common business process for purchasing, drawn from the
ee xp

2.1 Service Interaction Protocols Secure Electronic Transactions (SET) standard [33], origin-
.ie ee

The idea of conversations has been explored in the form of
w e

ally described by Desai et al. [28]. Four main roles
w .i
w w

service interactions by a number of researchers [26], [27], collaborate to carry out this process:
:// w
tp //w

[28]. With the exception of Moore [29], Singh and colleagues
1. the Customer, who wants to purchase items,
ht ttp:

[28], and Umapathy and Purao [18], the use of commu-
2. the Merchant, who sells items,
h

nicative acts has, however, not been explicit. Further, the
multilevel frameworks suggested by language action theor- 3. the Shipper, who transports the physical items to the
ists [16], [17] have not been used in this context other than the Customer, and
possibility suggested by Moore [29], and the exploration by 4. the Payment Gateway, who authorizes payments.
Umapathy and Purao [18]. Our definition of service interac- Fig. 3 (adapted from [28]) illustrates how the four agents
tion protocols, therefore, builds on that offered by [30]: An collaborate, denoted as circles. The rectangles at the role’s
interaction protocol is defined as the “rules of engagement” edge denote data transferred via labeled service messages.
among interacting participants. It includes the possible set of The numbers indicate typical sequencing. The ordering on
actions that each may perform, and the order in which these multiple outward edges from a process (e.g., Merchant:
must be performed. Concerns that need resolution for the task 9) is nondeterministic—the implementation can choose
design of interaction protocols, therefore, include: 1) speci- any ordering, including concurrent.
ficity; 2) semantic content; and 3) composability. Execution of the purchase process requires interaction
The first concern deals with specificity-abstraction dimen- protocols, which may be specified with message sequence
sion. For example, an abstract specification may represent diagrams (see Fig. 4). They describe how each message
interactions among services (e.g., racing condition [31]) that (communicative act) results in commitments (CC), which
is domain-independent. On the other hand, a specific are described in the next section. Each sequence specifies a
protocol, e.g., for shipment, may be domain-dependent. protocol (e.g., Payment, Shipment, and Order). A designer
The second concern is semantic content, i.e., the nature of the can compose these to design an operational system:
interactions. For example, a protocol specification may use
just the request-reply mechanism, relying on message Shipping protocol Payment protocol
Order
content (e.g., destination, payment info) to capture content. protocol Purchase process
On the other hand, the message itself may capture the A design mapping specifies how the protocols apply to
semantics to distinguish actions, such as direct, inform, the purchasing process. Part of that mapping is presented
cancel, and others. Finally, composability [31] is concerned here (where x/Y means that x is substituted for variable Y):


Purchase.Customer/Order.Buyer
Purchase.Merchant/Order.Seller

Purchase.Customer/Payment.Payer
Purchase.Merchant/Payment.Payee
Purchase.Payment Gateway/Payment.Gateway

Shipment.shipmentProp/Order.goods

2.2 Protocol Policies and Commitments
A protocol policy specifies outcomes that satisfy the
protocol goals. For example, a policy for the Payment
protocol may be: “after Payer sends paymentInfo, eventually
Payer receives receipt.” Protocol policies can also be specified
in nonprotocol terms. For example, one can conceptualize
protocols as manipulation of commitments, e.g., creation,
cancelation, fulfillment (discharge), etc. A commitment-
based Payment protocol policy may be: “after Payer commits
to Order, Payer pays for Order” (thereby, discharging the
commitment). A commitment captures a contractual rela-
tionship that enables “manipulations, such as delegation
and assignment, which are essential for open systems” [28].

t.c om
om
po t.c
A commitment C(x; y; p) denotes that agent x is obliged to
agent y for bringing about condition p. gs po
lo s
.b og

Desai et al. define a conditional commitment: CC(x, y, p, q)
ts .bl
ec ts

as: x is committed to y to bring about q if p holds; and specify
oj c
pr oje

operations on commitments such as: create, cancel, release,
re r
lo rep

assign, delegate, and discharge. They also specify commit-
ment rules, such as C(x; y; p) ^ p ! discharge(x, C(x; y; p)),
xp lo
ee xp

which states that if the condition p holds, then in the next
.ie ee

state, agent x is discharged of its commitment C(x; y; p). Their
w e
w .i
w w

framework also supports the specification of protocol
:// w
tp //w

assertions. For example, in one scenario of the Order protocol
ht ttp:

of Fig. 4: reqForQuote(...) } ! quote(...) ^ CC(...)—meaning
h

that a request for quote is eventually followed by a quote and Fig. 4. Protocols for the purchase process (from [28]).
a conditional commitment (to deliver goods for a payment).
As Desai et al. illustrate that the -calculus (a process algebra) 1. supporting specification abstractions over agents
can be used to formalize the protocol specifications in terms and their operations,
of operations and their associated commitments. For exam- 2. supporting a mapping function from operations to
ple, an informal translation of a -calculus specification of the commitments, thereby decoupling the two,
Seller process is: the seller receives itemID, consults its policy for 3. supporting reasoning at runtime, and
4. supporting the commonplace language of UML and
quoting and sends the quote price itemPrice, and receives either
its OCL.
accept-Quote or reject-Quote. Their approach to specifying
These extensions are on our research path, which uses a
protocol policies has these characteristics:
Language-Action Perspective. We turn next to describing
1.Commitments are associated with protocol specifi- how our work uses these theories.
cations.
2. Commitment ordering is not directly specified. For 2.3 The Language-Action Approach
example, the commitment on the quote operation The Language-Action Perspective provides the opportu-
simply indicates that the buyer and seller are nity to characterize messages in conversation protocols as
mutually committed based on two dependent con- actions. A key foundation for LAP is the Communicative
ditions (pay and deliver). Acts [13]: it suggests that an utterance is the performance
3. Commitments are referenced only via the concrete of a purposeful act, a speech act or communicative act.
operation with which they are associated. LAP emphasizes that the performance of business pro-
4. Reasoning is only supported at design-time.
cesses can be regarded as inter-related Communicative
We find this approach appealing. Our work extends the Acts [34], each with standard effects and extended effects.
Desai et al. approach by: Standard effects occur as a result of the illocutionary


portion of a communicative act, and can, therefore, be uses all the core components of REQMON, but the objects
identified without knowing the content of the message manipulated are those specific to the SERMON design. We
(i.e., the message type is sufficient). For example, an agent elaborate the LAP-specific concepts next.
that sends a message of type acceptQuote has the effect of
3.1 Methodology and Architecture
committing the agent to a contract. Extended effects occur
as a result of the perlocutionary portion—they represent The SERMON methodology uses a tailored approach for
changes in the receiver’s beliefs and goals, which is specifying service interaction goals that builds on the
underlying GORE model. These include: 1) agent service
important for analyzing commitments. For example, when
goals and 2) agent protocol goals. Agent service goals
an agent’s last commitment causes its obligated effort to
describe desired characteristics of an agent’s behavior
reach a threshold, then the agent shall change its state to
during the execution of a protocol, for example, “provide
that of accepting no further requests (i.e., the agent is over
timely response to a request.” Agent protocol goals describe
committed). The layered views suggested by language
desired characteristics of an agent’s behavior as it manages
action theorists [16], [17] provide a way to consider these multiple protocols simultaneously, for example, “abandon a
extended effects. The ideas presented by Desai et al. protocol execution that may not result in a commitment.” Based
provide only partial recognition of these effects. Neither on the goal model, monitors are compiled and the
does it use these effects for the purpose of monitoring. We monitoring system is deployed. Once deployed, the monitor
intend to specifically address extended effects, explicitly updates the runtime status of the goals as the target
representing and updating each agent’s commitments. To software system executes.
the best of our knowledge, there are no frameworks that As events arrive, they are stored in the repository, which
utilize such an approach for monitoring service systems. is analyzed for goal satisfaction. The results may be
The framework we develop next undertakes this challenge. presented on a dashboard or they may guide active
responses, such as selecting alternative services. The
SERMON repository stores event data as well as analysis
3 SERMON: A MONITORING FRAMEWORK FOR

t.c om
om
results. It consists of four layers.
SERVICE SYSTEMS
po t.c
We follow the design science approach [35] to develop the . gs po
Level 0 (events): The lowest layer stores raw data
lo s
.b og

SERMON framework. It embodies our theory of a Language- such as, “agent x receives message m from agent y.”
ts .bl

Action-based approach to monitoring service systems. A . Level 1 (ontology): The next layer stores an inter-
ec ts
oj c

key element of our research is our ontology of commu- pretation of the event data using terms from a
pr oje

nicative acts (CACTS) and its use for multilevel monitoring selected ontology. Herein, a communicative act
re r
lo rep

of service systems. We hypothesize that our LAP-based ontology is used for record events such as “agent x
xp lo

service system ontology is sufficient for specifying and commits to do z for agent y.”
ee xp
.ie ee

monitoring service-related commitments of business proto- . Level 2 (properties): Properties of level 1 events are
w e

col policies. The CACTS ontology is derived from our work stored at layer 2, for example, the property “agent x
w .i
w w

[18] and others [28], who have previously shown the value never violates a commitment” is true.
:// w
tp //w

of formal constructs for protocol policies. Our research . Level 3 (metaproperties): Properties about properties
ht ttp:

evaluation is focused on the sufficiency and utility of are stored at layer 3, for example, “property p1 has a
h

CACTS. We apply the Hevner et al. [35] descriptive approach 75 percent success to failure ratio over the last 72 hours.”
to design science evaluation—illustrative scenarios and Layers 1, 2, and 3 correspond to the instance, domain, and
argumentation. Additionally, we present some performance meta layers of the KAOS model [41]; layer 0 is like a
measures and anecdotes of usage. Thus, we present our physical data layer and is not considered in KAOS model.
design science activities that are essential to realize the The SERMON framework, thus, 1) treats services as units
CACTS ontology, and evaluate it for specification and that require monitoring, and 2) treats communicative acts
monitoring. performed by services (as part of conversations), as
The SERMON framework extends a requirements mon- operations on commitments. SERMON does not presume a
itoring framework REQMON, which supports 1) goal
global view of the overall process. Instead, it monitors
specification; 2) monitor compilation (from goals); and
behaviors of individual services as they participate in
3) runtime goal evaluation of a software system [36], [37].
conversations with other services.
REQMON supports GORE (i.e., Goal-oriented requirements
engineering) [38] with three phases: 1) identifying goals; 3.2 Communicative Acts
2) refining and formalizing goals; and 3) deriving and The SERMON framework relies on a parsimonious set of
assigning operations to agents [39]. It uses goal modeling,
Communicative Acts based on the approach and outcomes
which an analyst can refine to derive operational descrip-
outlined in Umapathy and Purao [42] that subsumes the
tions including pre- and postconditions [40]. REQMON
follows a model-driven architecture (MDA). It relies on the 23 acts suggested by Moore [43], and 12 acts suggested by
Eclipse Modeling Framework (EMF) for its metamodel and Johannesson and Perjons [44]. Their redefinition, elimina-
the OSGi specifications, which specify Java-managed tion, and mapping of these results in nine Communicative
components. REQMON is implemented with Eclipse Acts, (see [42]) that we use; see Table 2.
(metamodel and user interface tools) and Equinox (com-
3.3 Specification Language
ponent server). SERMON extends REQMON by specifying
LAP-oriented types (in EMF) and specifications (in a Protocol specifications and their associated commitments
variant of the Object Constraint Language). Thus, SERMON can be considered from two perspectives:


TABLE 2
A Parsimonious Set of Communicative Acts [42]

Fig. 5. A goal hierarchy in OCL.

In the preceding expression, elements in the employee
collection are designated p, a Person object, which is
constrained to have an age value less than 65.
OCLTM uses Flake temporal message semantics [47].

t.c om
om
Both sentMessages and receivedMessages return a

po t.c
gs po
Sequence of OclMessage objects, and sentMessage and
lo s
receivedMessage returns the last, most recent message
.b og
ts .bl

in the sequence. OCLTM also includes temporal patterns
ec ts

[48] and timeouts; and linear temporal logic operators [41],
oj c
pr oje

[49] as shown next (keywords in bold):
re r
lo rep

(the next state) . (the prior state)
xp lo
ee xp

Å some time in the future, ^ (some time in the past,
.ie ee

1. Specifying with Desai’s commitment logic and eventually) previously)
w e

reasoning at design time with the -calculus.
w .i

t
u (always in the future) (always in the past,
w w

2. Specifying with OCL and reasoning at design-time
:// w

constantly)
tp //w

with LTL (cf., [45]) and runtime with the SERMON
W (always in the future U (always in the future
ht ttp:

analysis tools, which compare the running processes
unless) until)
h

with their specified properties.
There is a natural translation from Desai’s specification to With these, one can express “eventually class object obj
our OCL specifications. We generally specify directly in will receive message msg” as follows:
OCL rather than translate from Desai specifications, in part, context Class
because OCL simplifies specification with its support of inv: msgArrives:
abstractions over agents and their operations. Our OCL eventually(receivedMessage(msg()))
specifications have the advantage of being monitored at
The Flake temporal message semantics rely on an event
runtime, which we demonstrate in Sections 3.4 and 4.
history, which is accessed via the Flake operations defined
SERMON employs a variant of the Object Constraint
on OclAny. All sent messages can be accessed as follows:
Language (OCL) 2.0 [46], OCLTM (OCL with Temporal
Message logic). The OCL is similar to first-order predicate OclAny-allInstances()ÀforAll
calculus in that it allows specification of Boolean expres- (i: OclMessage j i.sentMessages())Àcollect()
sions with logical connectives, with universal and existen- Protocol policies are expressed as goals in OCLTM . Fig. 5
tial quantifiers. For example, one can specify that all illustrates a goal hierarchy in the OCL. The goal, goalRoot1,
employees of a company must be less than 65 years old: expresses the root with goals g1 through g3 as subgoals.
The entire hierarchy is associated with the class MyClass.
context Company
The hierarchy can be associated with any UML context
inv: employee-forAll(p: Person j p.age 65)
including classes and operations.
The expression is an invariant of the context Company, a The language allows class inheritance, which can be
UML class. The OCL uses the familiar object-oriented dot exploited to simplify specification by abstracting goals,
notation to navigate object graphs, and the arrow (À ) to agents, and operations. For example, Child and its super-
navigate an object collection. Collection operations, such as class Parent, can both have associated goals. Here, the Child
forAll and exists, have their own specific parameters. is associated with both goals goalA and goalB.


context Parent
inv: goalA: - - ...
context Child
inv: goalB: - - ...
A properly annotated class hierarchy provides a means to
describe requirements at multiple levels of abstraction. The
language, thus, allows specification at varying levels of
specificity, and thereby, supports monitoring at varied levels.

3.4 Interpreting Events as Communicative Acts
To relate the theory of LAP-based analysis with an actual
running software system, it is important to specify how
real-world events are characterized as LAP concepts. For
S ERMON, events are stored into the repository (see
Section 3.1) as the software system executes at runtime.
They are interpreted using the communicative acts
(CACTS) ontology (see Table 2). The SERMON framework
relies on event adaptors in REQMON. An event is typically
created by a logging program. SERMON listens to these log
streams. As an event arrives, a chain of event adaptors
transform the event, as desired. For example, a common
event transformation is:
Fig. 6. Communicative acts as an EMF model.
Log4jEvent ! CommonBaseEvent ! OclMessage

t.c om
om
mapping is needed, because the policies remain associated

po t.c
The final object is stored into the repository. In the
preceding, the object is stored as an OclMessage object. with the abstract CACTS operations. Section 4 illustrates
gs po
lo s
such abstract policy specification.
.b og

The SERMON framework uses a mapping within the
ts .bl

TransformEventAdaptor to map the incoming events 3.5 Goal Monitor Compilation
ec ts

to communicative acts (cacts).
oj c
pr oje

As events are received by SERMON, the Transform- Each goal specification is automatically compiled into a goal
re r

monitor by translating each specification into a property
lo rep

EventAdaptor transforms the received event according to
evaluation tree, where each node is a rule set [50]. Consider
xp lo

a specified mapping. Based on the preceding, the event of an
ee xp

object receiving a quote request is represented as a Propose the following simple property as an illustration:
.ie ee

event, which is a subclass of CommunicativeAct, which,
w e
w .i

context ContextClasss
in turn, is a subclass OclMessage. Thus, the preceding
w w
:// w

event transformation becomes the following sequence when def: m1 : OclMessage =
tp //w

the SERMON TransformEventAdaptor is applied: receivedMessage(message1())
ht ttp:

def: m2 : OclMessage =
h

Log4jEvent ! CommonBaseEvent ! receivedMessage(message2())
CommunicativeAct inv: prop:
The preceding illustrates a simple mapping, from a after(eventually(m1),eventually(m2))
method name to a communicative act. However, one can A simple compilation of prop generates three main rules:
define a mapping that considers the method name,
1) evaluate (eventually m1); 2) evaluate (eventually m2);
associated sender and receiver, and other contextual
and 3) the root of the tree: evaluate (after(eventually
information. In such cases, a developer can write additional
code or a rule-base system to characterize a received event m1) (eventually m2)).
according to an ontology. Fig. 6 illustrates the commu- 3.6 Event Stream Interpretation
nicative acts defined in Table 2.
Finally, at runtime, the compiled property rules interpret
The root of the hierarchy is CommunicativeAct. Its
two subclasses, Request and Response, partition the the event stream. The monitor acquires events from
remaining acts. By being a subclass of OclMessage, the instrumented program. As events arrive, rules evaluate
CommunicativeAct, and its subclasses use the OCL the property evaluation trees. For example, for the leaf node
ontology. It also includes some user-defined methods. For eventually m1, the rule’s left-hand side (LHS) matches a
example, the correspondsTo method returns true when repository assertion representing a received message1;
the two messages take part in a request-response dialog. other LHS expressions may further constrain the evaluation.
The tactic of mapping events to communicative acts As nodes are satisfied, their values are propagated up the
differs from the Desai et al. approach, which directly tree, until finally, the entire prop expression is evaluated.
associates commitments with operations [28]. In SERMON,
policies can be specified in terms of abstract events, such as
those defined in the CACTS (see Fig. 6). The event mapping 4 SCENARIO-BASED EVALUATION
decouples the specification from the implementation. As The SERMON framework specifies a novel approach for
new service operations are implemented, only their CACTS monitoring that relies on an ontology of communicative acts


for multilevel monitoring of service systems. Here, we Formula 1 represents the standard effects of LAP—one
illustrate an implementation of the framework and applica- message type (Query) shall be followed by another
tion to the purchase process example (see Fig. 3). message type (Propose). Not all formulae, however, need
We hypothesized that the CACTS ontology is sufficient be specified in this manner. We may also specify the
for specifying and monitoring service-related commitments. extended effects, which describes changes in the commit-
To evaluate sufficiency of expression, we created over 50 ment state of the receiver [28]; later, Formula 6 illustrates an
specification expressions derived from policy specifications extended effects specification.
found in the related literature (summarized in Section 5.3); Formula 2 is similar to Formula 1. However, it introduces
in particular, Dwyer reviewed 555 specifications, 92 percent a timeout that the response must meet. Additionally, it
of which match the temporal patterns that are part of interprets the two messages as abstract types (Request and
OCLTM [36], [48]. Next, we specified business protocol Response, respectively). This formula acknowledges the
policies, derived from the literature, using CACTS. Finally, existence of a commitment over a time period.
we created and ran programs that satisfied and violated the Formula 2. Timely response expressed with timeout.
policies. The success of specifying and monitoring many
policies from the literature suggests that the CACTS
ontology is indeed sufficient for specifying and monitoring
service-related commitments.
The next two sections illustrate some specifications from
our literature-based collection of test scenarios, using the
context of the purchase process example (see Fig. 3).
The scenarios are intended to: 1) establish the feasibility of
the framework and 2) demonstrate expressiveness of
CACTS. Together, these techniques provide an evaluation
of the SERMON framework following an approached

t.c om
Formula 3 provides another variation. Here, a message

om
recommended by Hevner et al. [35].

po t.c
queue query limits the kinds of messages selected to be
4.1 Scenarios Demonstrating Agent Service Goals gs po
compatible with Request and Response types.
lo s
.b og

Agent service goals describe desired characteristics of an Formula 3. Timely response expressed with queue query.
ts .bl

agent’s behavior during protocol execution (see Section 3.1).
ec ts
oj c

Many agents share common goals, such as “be responsive.”
pr oje

The purchase process example illustrates such common
re r
lo rep

goals. The following formulas illustrate common goals. In
xp lo

the formulas, highlighted words are OCL keywords,
ee xp
.ie ee

including temporal patterns, such as after, before,
w e

between, response, etc. [48].
w .i
w w

We begin our scenarios with the agent goal of “receive
:// w
tp //w

quote after query,” shown in Formula 1. The first two agent
ht ttp:

definitions designate the receipt of a Query message with
h

method name requestForQuote and a Propose message
with method name quote, by an agent. The quoted As a final variation, we present Formula 4. It does not
invariant constrains how these messages can be related. It reference the method name. Instead, it characterizes the
states that after the query is received, then eventually, a messages as being compatible with Commit and Fulfill
corresponding proposal shall be received. (The temporal types. Thus, property expressions can rely on agent and
patterns accept a Boolean argument; thus, the idiom message type hierarchies, as well as common database
eventually(querynull) is used to check existence.) expressions over their properties.
Placing this invariant on the Agent class, rather than its Formula 4. Timely response expressed with message type.
subclasses (e.g., Buyer and Seller), simplifies the expression.
Formula 1 states that, no matter which agent is involved, an
agent’s Query shall be followed by a corresponding
Propose.
Formula 1. Must respond to a Query with a Propose.

We can also express simple properties, such as each
fulfillment shall be compensated, as Formula 5 shows. It
assumes that compensation is provided through a fulfillment
communicative act, which can result from discharging a
commitment [28].


Formula 5. Provides compensation expressed with a Formula 8. A constraint between an Agent’s resources
communicative act (CACTS) operation. and responses limits committed resources.

The preceding demonstrates concise constraints over
agent and message abstractions, important for expressing
protocol goals. The customer, merchant, and payment A variety of protocol policies can be specified in this
gateway are all subclasses of agent. Thus, each inherits manner. These policies seamlessly integrate standard and
analysis of the superclass Agent properties. Of course, the extended effects over agent and operation-type hierar-
agent subclasses can add more specialized goals. Over- chies. As further illustration, consider the following
riding (or hiding) properties is unnecessary for monitored (informally specified) policies, each in effect, representing
properties. The monitor simply reports on the satisfaction of an aggregation of extended effects, which contribute to
properties. It is possible to specify inconsistent properties as the state of an agent.
well because the monitor does not enforce these constraints. If the agent’s commitment level is higher than a thresh-
old, then do not start new conversations.

t.c om
4.2 Scenarios Demonstrating Agent Protocol Goals If the agent’s commitment level is approaching a thresh-

om
po t.c
The formulas so far demonstrate goals associated with two- old, then complete high-value conversations.
agent dialogs. Next, we demonstrate protocol shared goals gs po
If the agent’s commitment-level is approaching a thresh-
lo s
.b og

of the purchase process agents. The properties specify how old, complete conversations with high-value customers.
ts .bl

an agent can participate in multiple conversations. Increase priorities of conversations that require an action
ec ts

Formula 6 limits unfulfilled commitments. If placed in the of Commit as opposed to those requiring other actions, such
oj c
pr oje

Agent, it is only satisfied when the number of all committed- as Inform.
re r
lo rep

but-unfulfilled acts is less than Agent.commitLimit
4.3 Scenario Demonstrating Goal Monitoring
xp lo

(which may have different values for different subclasses).
ee xp

In effect, it recognizes the LAP extended effect of creating a The runtime evaluation of goals is illustrated in Formula 9.
.ie ee

commitment, while limiting the effort to which an agent may Reconsider the purchasing process example of Section 2.
w e
w .i
w w

commit. To evaluate the Agent goals quoted (Formula 1) and
:// w
tp //w

Formula 6. Limit unfulfilled commitments. timelyResponse (Formula 2) in the Order protocol of
ht ttp:

Fig. 4, we followed these activities:
h

1. The target SET service system, containing the Buyer,
Seller, etc., was implemented as a multithreaded
Java program.
2. The target system was instrumented, using Eclipse
TPTP, to output selected method calls.
Formula 7. illustrates a protocol transition property. 3. The SERMON server was started, with the Order
Eventually, after a commitment, the commitment must be polices loaded.
4. The target service system was executed.
fulfilled or canceled. This is an LAP extended effect policy
5. The SERMON server received event stream of
about agent commitments.
method calls from execution of the Order protocol.
Formula 7. Property specifies transition to a final state.
6. The SERMON server analyzed the event stream,
evaluating and reporting on property satisfaction.
With each new monitored input, the monitor analyzes and
updates property evaluations. Primitive (nested) properties
are evaluated first, and their values are propagated for
Formula 8 specifies that an agent must consider the composite properties.
remaining resources and required resources before re- The subscenario between the Buyer and Seller in the
sponding to a request. This is another extended effect purchasing process (from Section 2) is initiated as a thread.
policy, which specifies the internal workings of an agent. In The resulting property evaluation uses Agent goals quoted
particular, the resources required of a new request shall not (Formula 1) and timelyResponse (Formula 2). The monitor
exceed the remaining resources. The resource methods have input data consists of two significant events in sequence. The
default definitions on the Agent class, but its subclasses can first input event occurs when the Buyer object sends a request
override the method. Again, such methods are part of the for quote, which is interpreted both as a Query commu-
specification of the ontology (see Section 3.2). nicative act and as a Request. The monitor processes the


event, asserting that the first eventually subproperties of These pairs were continuously sent to the server 10,000 times.
quoted (Formula 1) and timelyResponse (Formula 2) are In the experiment, the event generator and REQMON ran in
true. Thus, all invariants are processes simultaneously, and the same multithreaded process. The test ran as a JUnit test
the same event can be interpreted in multiple ways; here, as a case within Eclipse on a Windows Server 2003 dual core
Query in Formula 1 and as its superclass Request in 2.8 GHz with 1 G memory. The results suggest that, within
Formula 2. For each formula, this propagates the state of their the test configuration, sequential properties (of length 2) are
scopes after to be open. The second eventually sub- processed at 137 event pairs per second [51]. This indicates
property of quoted (Formula 1) and timelyResponse
that REQMON is reasonably efficient for many monitoring
(Formula 2) becomes true with the assertion of the quote from
problems.
the Seller. These values propagate to each property.
Formula 9. SERMON output as Proof-of-Concept. 4.5 SERMON Application
Our application of SERMON and REQMON to monitoring
problems suggests that the approach is useful. Like any
software system, monitor system development can be
complex and time-consuming. By limiting the specification
language to DSLs based on OCL, much of the development
process is automated. Yet, this raises the concern that the
monitor specification may be too limiting to express some
desired policies. Our experience within the service systems
is the basis for the following insights.
Our experience is that typical policies and their monitors
are simplified in CACTS. The underlying R EQ MON
language includes temporal patterns and timeouts, which
seemed to simplify property specifications according to

t.c om
om
Dwyer et al. [48], which has also been our experience for the

po t.c
emailing domain [51], and now for the service-policy
gs po
lo s
domain. Moreover, the CACTS DSL simplifies the expres-
.b og

sion of common communication patterns in service policies.
ts .bl
ec ts

It was relatively simple to specify, for example, “after an
oj c
pr oje

agent commits to an action type, that agent shall fulfill that action
Note: Properties quoted and timelyResponse. SA
re r

within a specified period”—see Section 4.1. CACTS simplifies
lo rep

means scope activation, p@ is a property prefix, and s@ is a such expressions by providing commitment logic over class
xp lo

scope prefix. The brackets “[]” include object references.
ee xp

hierarchies with temporal and real-time constraints. As
.ie ee

The first scope activation SA@db4fa2 is the global scope. further validation, we reviewed property expressions from
w e

All service and protocol goals are monitored with this
w .i

related monitoring systems (see Section 5.2) and found that
w w

approach. Thus, as the service system executes, SERMON
:// w

they all can be represented in SERMON. Our success,
tp //w

provides notification as each goal is satisfied or violated. however, does not suggest that all the properties kinds for
ht ttp:

Therefore, business analysts can understand the current state the service-system domain can be represented, only that we
h

of their systems in terms of high-level service and protocol found it reasonable for many common service policies.
goals. Through such analysis, SERMON provides notification Finally, our findings may not generalize to other monitoring
of policy compliance (or violation) for service systems. projects. Nevertheless, given the service system property
complexity, it does suggest that this approach may be
4.4 Monitor Performance utilized in a variety of application domains.
Monitoring has little impact on the target system, mostly
because the target system and monitor typically run on
separate computers. The TPTP Probekit provides optimized 5 DISCUSSION
byte-code instrumentation, which adds little overhead to Our approach for specifying and monitoring participant
some (selected) method calls in the target system. The actions and their effects on commitments extends and
logging of significant events consumes no more than augments recent work that has begun to recognize the
5 percent, and typically less than 1 percent overhead. increasingly distributed nature of business processes in open
For real-time monitoring, it is important to determine if environments. To overcome the shortcomings of centralized
the target events can overwhelm the monitoring system. A business-process specifications, we reconceptualize business
performance analysis of REQMON was conducted by process specifications in terms of conversations among
comparing the total monitoring runtime versus without participants. These conversations contain communicative
monitoring using 40 combinations of the Dwyer temporal acts, which result in manipulation of commitments. Here, we
patterns [48]. (This is pertinent because SERMON executes compare our work with other research efforts.
the same LTL property monitoring algorithm, but with
different objects (see Section 3)—the monitoring primitive 5.1 Interaction Protocols in Service Systems
constructs are the same, and thus, the performance is Barros et al. [27], Decker et al. [26], and more recently, Desai
essentially the same.) For data, a simple two-event sequence et. al. [28] have argued that interactions among services
was the basis of the test datum; for context, consider constitute an important design element. Barros et al. [27]
the events as an arriving email and its subsequent reply. along with Decker et al. [26] propose a number of


archetypal interactions among services, and formalize these general architecture for creation and monitoring of web
with Pi-calculus. The dimensions they consider include service agreements [76].
number of participants, exchanges, and routing of mes- Our work extends this stream. It is focused on meeting
sages; but stops short of adding semantics to the messages. monitoring needs via an independent monitor and an
Another early effort is Moore [29], who envisions a expressive language:
system of conversations (with Bach and Harnish’s [52] set of
communicative acts) as a reactive system, modeled with 1. that allows domain-specific extensions from stan-
state transition nets. His work represents a departure from dard OCL and user-defined library extensions;
the ideas of Barros et al. because it attempts to add 2. that supports property inheritance with expressions
semantics to messages. He outlines the possibility of based on standard OCL and associated UML;
considering conversations as a central abstraction. Uma- 3. that extends OCL with relational, temporal, and real-
pathy and Purao [18], [42] build on this work, suggesting time expressions; and
that interactions among web services may allow us to 4. that supports metarequirements with properties as
bridge the gap between design knowledge and executable UML classes, directly manipulated as “first-class”
specifications [25]. constructs.
Maximilien and Singh [53] explore possibilities for The examples of Section 4 illustrate how OCL supports
modeling and execution of service systems as a set of these expressions. As an illustration of a metaproperty,
interactions in the context of multiagent systems. These consider the following expression:
include process adaptations [54], specifying preferences Formula 10. Agent meta property.
[55], and deviations to protocols [56]. Desai et. al. [57]
describe an approach that builds on the establishment and
discharge of commitments. They do not, however, explore
the possibilities for monitoring suggested by message

t.c om
om
sequences and aggregating extended effects.

po t.c
The database and software engineering researchers
gs po
address interaction protocols for extending web services.
lo s
.b og

For example, Baresi et al. [58] and Baresi and Guinea [59]
ts .bl

suggest use of a web service constraint language and pre-
ec ts
oj c

The property mostlySatisfied references the
pr oje

and postconditions to specify process deviations. Lazovik
timelyResponse (defined in Section 4.1). In OCL,
re r

et al. [60] suggest a service request language, building on
lo rep

prior work in a service assertion language [61]. Pistore et al. invariants are (implicitly) subclasses of the UML class
xp lo

RM::Property. Therefore, properties and their instances
ee xp

[62] suggest protocol combinations to monitor web service
.ie ee

compositions. Xu and Jeusfeld [63] describe an approach for can be referenced using standard OCL constructs. Thus,
w e

mostlySatisfied is satisfied when the ratio of satisfied
w .i

monitoring contracts. Taken together, these efforts provide
w w
:// w

a first step toward monitoring but do not suggest a to total timelyResponse evaluations is greater than
tp //w

comprehensive, multilevel framework for monitoring. 75 percent. Of course, mostlySatisfied is itself a
ht ttp:

Our work draws on and extends these efforts, and property, and thus, can also be analyzed.
h

ensures integration with practice with the help of OCL. The Our work also seeks monitor independence. Thus, the
framework we outline is also independent of SOAP versus monitoring system is defined independent of any parti-
REST styles [64]. The intention to treat a message as a cular target system. Therefore, the monitoring system can
specific communicative act resides in the sender (as an work equally well for standard programs, web services,
illocutionary act, and is communicated to the receiver along or grid applications. The only requirement is that the
with the content). The consequences of the communicative target programs provide events that can be filtered, and
act are witnessed as an extended effect on the receiver. The then, analyzed.
packaging of the communicative act (as SOAP- or a REST-)
does not affect viability of the SERMON framework. 5.3 Semantics of Service Interaction Policies
SERMON supports reasoning with communicative acts and
5.2 Monitoring Service Systems
operations on commitments. To illustrate, consider the (last)
Our approach may also be compared with prior research three invariants of Formula 11.
in monitoring ([65], [66], [67], [68], [69]). Baresi et al.
suggest an assertion annotation approach [70] to monitor- 1. sendQuote illustrates a message-based property. In
ing [71], [72] that includes a weaving mechanism to this representation, relationships among web ser-
integrate service execution with property monitoring. The vices messages are directly specified.
monitor they suggest intercepts communications to check 2. quoteCommit illustrates a communicative-act-
properties using the Xpath-like queries. Yan et al. describe based property. In this representation, messages
how to monitor web services using model-based diagnoses
are mapped to Communicative Acts, whose relation-
[73]. Researchers at Trento define an algorithmic frame-
ships are constrained.
work in which a monitor controls an interleaved planner
[10], [74] that replans when web service failures are dischargeCommitments illustrates a commitment-based
observed. Roth et al. define and implement extensions to property. In this representation, commitment operations
BPEL to support monitoring [75]. Ludwig et al. outline a are specified for communicative acts.


TABLE 3 TABLE 4
Mapping Operations on Commitments [28] Comparison with Policy Monitoring Systems
against Communicative Acts

maps them against possible conversations. Further work to
map these is needed.
The SERMON approach supports message semantics
(especially extended effects), which is unique in the growing

t.c om
research on service-policy monitoring. Unlike other projects

om
Each subsequent representation builds on the prior to

po t.c
that are specialized, our work focuses on monitoring a
advance the kinds of analyses possible. In contrast to gs po
generic service system with the help of language action
lo s
SERMON, other monitoring systems are message-based only.
.b og

primitives. Table 4 compares our work against related
ts .bl

Formula 11. Three kinds of specifications. service-policy monitoring systems with respect to three
ec ts
oj c

main characteristics:
pr oje
re r
lo rep

1. Ontology: Table 4 shows the most specifications
xp lo

concern web services (in their terms), while fewer
ee xp

consider commitments. SERMON addresses both
.ie ee

and the underlying metamodel support additional
w e
w .i

user-defined terms.
w w
:// w

2. Properties: Prior efforts provide logical property
tp //w

descriptions; most characterize these as classes
ht ttp:

without utilizing inheritance. Fewer include tempor-
h

al or real-time properties. Only SERMON allows
inheritance and metaproperties.
3. Scope: In prior efforts, policies apply to service
messages. Few consider conversation as a unit for
policies. Only SERMON applies to conversations
and their aggregation with consideration of ex-
tended effects.

6 CONCLUSION
More generally, consider the relationship between
We have presented a framework and an approach for
Communicative Acts to specify message semantics and
multilevel monitoring of service systems. It draws inspira-
service commitments. Following Desai et al., “commitments
tion from the language-action perspective and extends
capture a variety of contractual relationships, while
recent work related to commitments. The key contributions,
enabling manipulations, such as delegation and assign-
specific to the use of language-action perspective, include
ment” [28]. Manipulations of commitments, thus, represent
consequences of message exchanges. Following the lan- the following:
guage-action perspective we suggest, these operations . Specification of an ontology of communicative acts
represent extended effects of communicative acts. For that adds semantic content to messages.
example, a request may not lead to the creation of . Support for the specification of policies that address
commitment depending upon the state of the conversation standard and extended effects of communicative
as well as other current commitments for the service. This effects for multilevel monitoring.
distinction is analogous to standard effects and extended
In addition, the framework specified supports the
effects following the language-action perspective, and is
important for our approach. Table 3 describes these and following:

Monitoring Service Systems from a Language-Action Perspective

Monitoring Service Systems from a Language-Action Perspective

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Viewers also liked

Viewers also liked (20)

Similar to Monitoring Service Systems from a Language-Action Perspective

Similar to Monitoring Service Systems from a Language-Action Perspective (20)

More from ingenioustech

More from ingenioustech (20)

Recently uploaded

Recently uploaded (20)

Monitoring Service Systems from a Language-Action Perspective