Monitoring service systems from

Monitoring Service Systems froma 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

THE exponential growth in the global economy is beingsupported by service systems, realized by recasting

mission-critical applications as services accessed acrossorganizational boundaries. Service-oriented architecturesand associated interoperability standards [1], [2] providekey enablers for these service systems. Their actualbuilding and deployment, however, continues to be fraughtwith problems: “most of our large software systems ... arenow constructed as groups of interoperating systems (assystems of systems) ... made to interoperate throughvarious forms of interfaces. Although we can conceivethese large [service systems], we have trouble buildingthem” [3]. Anecdotal accounts of systems integration efforts(e.g., [4], [5], [6], [7]) point to failures and underscore theneed to address the underlying cause: rapidly changingenvironmental forces.

These changes challenge assumptions, such as stabilityand predictability, where well-specified business processes(with services to perform tasks) are identified in advanceand are insulated from change. Instead, the open anddistributed processes include tasks that are performed byservices that are not centrally controlled, and hence, can beunpredictable. As a result, service outcomes themselvestend to be uncertain. Service monitoring, therefore, remainsa significant challenge. The goal of this research is todevelop a framework for monitoring such service systems.This paper presents the framework, establishes its feasi-bility, and evaluates it with scenarios and comparisonsagainst existing proposals.

1.1 Monitoring Software Systems

Monitoring software systems is closely tied to the monitor-ing of requirements and how they are realized in software.A monitor is a software system that “observes and analyzesthe behavior of another (target) system, determiningqualities of interest, such as the satisfaction of the targetsystem’s requirements” [8]. A requirements monitor deter-mines the requirements status from a stream of significantinput events [9]. A monitor is, then, a function thatprocesses its input event stream to derive the status ofrequirements. This characterization of monitors and mon-itoring assumes an event, that is, “a significant action intime, typically modeled as instantaneous state change, e.g.,completion of a method call, a CPU reaching 90 percentutilization, a shipment arriving at a destination, or a personleaving their home” [8]. An event source presents a streamof software event objects that represent their real-world(target) events. The central monitoring issues, therefore,include: 1) event acquisition and 2) event analysis [8].

Our research question, related to monitoring of servicesystems, asks: how can one use service interaction events tounderstand a service system in terms of service policies? Itrepresents an instantiation of the more general question:how can one use lower level runtime events to understand asystem in terms of higher level requirements? This bridgingis facilitated by multiple abstraction layers (see Fig. 1). Thelowest layer captures message exchanges with protocolssuch as SOAP or REST. They represent runtime events thatcomply with a specification, e.g., the Secure ElectronicTransactions protocol. The middle layers capture eventsequences following interaction policies, e.g., a buyer mustprovide payment for services. The highest level, then,represents the monitor, which reports on the state ofspecified policies, e.g., 95 percent of agents comply withthe service interaction policies. The selected ontologies andanalysis techniques affect the monitor’s ability to providefeedback. Together, these layers provide the potential foreffective monitoring.

The key contribution of this paper is the introduction of anontology of communicative acts into these abstraction layers

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

. W.N. Robinson is with the Computer Information Systems Department,Georgia State University, RCB, 35 Broad St, Suite 927, Atlanta, GA30302-4015. E-mail: [email protected].

. S. Purao is with the Information School, University of Washington, Seattle,WA 98195, and the College of Information Sciences and Technology,Pennsylvania State University, University Park, PA 16802.E-mail: [email protected].

Manuscript received 15 May 2009; revised 25 Feb. 2010; accepted 4 Apr.2010; published online 26 Aug. 2010.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TSCSI-2009-05-0134.Digital Object Identifier no. 10.1109/TSC.2010.41.

1939-1374/11/$26.00 � 2011 IEEE Published by the IEEE Computer Society

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http://www.ieeexploreprojects.blogspot.com

to enhance policy specification and monitoring of servicesystems. We develop this contribution as an extension toprior work in monitoring, establish its feasibility, anddemonstrate it with multiple scenarios.

1.2 Service System Enablers

Service systems build upon the basic idea of software as aservice [10], [11] that allows legacy and new applications todeclare their capabilities in a machine-readable format [12].Once deployed, the services can be linked to support cross-functional business processes. Core standards for publish-ing (WSDL 2001), finding (UDDI 2005), and binding (SOAP2003) provide key enablers for these service systems.

Prior work suggests Language-Action Perspective (LAP)as a theoretical foundation for a layered view [13], [14], [15]of these enablers. A building block in this perspective is aspeech act. It conceptualizes an utterance as the performanceof a purposeful act. Several frameworks have been devel-oped for LAP, such as business model patterns [16] and anaggregative model [17]. Umapathy and Purao [18] synthe-size these into a framework for the web services standardsspace with three layers: a communication platform, thecommunicative act itself, and the rational discourse. Table 1maps the web service standardization initiatives againstthis framework.

The table highlights a key sublayer not effectivelyaddressed by existing standards: support for conversationsbetween services, which can provide a loosely coupled,peer-to-peer interaction model. Formalizing and represent-ing such conversations among web services is central tounderstanding how monitors may be designed for servicesand business processes in distributed, open environments.

1.3 Conversations among Web Services

Current models for interactions among web services use avending machine metaphor. WSDL port types and opera-tions resemble buttons, levers, and slots on a vendingmachine [18]. The WSDL does not reveal that one mustdeposit money in the slot before pushing any buttons. WebService choreography languages [19] attempt to solve this bygiving instructions on which buttons to push in what order.An alternative model is that of a telephone call, where two (ormore) parties set up a session, exchange messages in thatcontext, and then, finally, close it. Each message isinterpreted in relation to those previously exchanged. A

conversation, thus, describes multistep exchanges of mes-sages performed by participants.

A prerequisite for this model, in the context of servicesystems, is a conversation policy [20], [21] that allows eachparty to maintain its own record of the conversation’s state.Realizing a conversation model, then, requires specificationof conversation policies and the ability to transform thesepolicies into messages that can facilitate the actual con-versation. The conversations themselves are comparable todiscourses, whose elemental units include clauses anddiscourse operators, i.e., communicative acts [22]. Otherefforts related to this view of conversations include agentcommunications [23] (often restricted in scale), conversationstructures [24] (that ignores the semantic content), andservice interaction and enterprise integration patterns [25](that focus on an operational perspective, relegatingmessage exchanges to a secondary role). Our use ofcommunicative acts is different. We focus on their use formonitoring. The conversation models we envision, there-fore, include communicative acts, which result in standardas well as extended effects, i.e., operations on commitmentsand expectations of responses.

Fig. 2 shows an example of a loan approval process thatuses the services: Customer, LoanApprover, and LoanPro-cessor. The process begins with the Customer sending theloan request. The LoanApprover receives the request andinvokes the LoanProcessor to process the application. TheLoanProcessor sends approval information to the LoanAp-prover, who forwards it to the Customer. The tasks in theprocess are achieved via two conversations between services:1) Customer-LoanApprover, and 2) LoanApprover-Loan-Processor. Specific communicative acts may be specified foreach conversation, e.g., the task “check credit” may require:1) asking for credit information about a customer; 2) re-sponding in the form of prepackaged information or refusingto send the answer; and 3) acknowledging receipt of theanswer. The figure highlights three important points. First,processes can be modeled as a composition of conversations;second, conversation protocols can be specified for services;and third, conversations provide the possibility for monitor-ing at different levels of granularity and temporality. The nextsection elaborates these ideas further.

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

Fig. 1. Abstraction layers for monitoring service systems.

TABLE 1Layered View of Web Service Standards [18]

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


2 BACKGROUND

2.1 Service Interaction Protocols

The idea of conversations has been explored in the form ofservice interactions by a number of researchers [26], [27],[28]. With the exception of Moore [29], Singh and colleagues[28], and Umapathy and Purao [18], the use of commu-nicative acts has, however, not been explicit. Further, themultilevel frameworks suggested by language action theor-ists [16], [17] have not been used in this context other than thepossibility suggested by Moore [29], and the exploration byUmapathy and Purao [18]. Our definition of service interac-tion protocols, therefore, builds on that offered by [30]: Aninteraction protocol is defined as the “rules of engagement”among interacting participants. It includes the possible set ofactions that each may perform, and the order in which thesemust be performed. Concerns that need resolution for thedesign of interaction protocols, therefore, include: 1) speci-ficity; 2) semantic content; and 3) composability.

The first concern deals with specificity-abstraction dimen-sion. For example, an abstract specification may representinteractions among services (e.g., racing condition [31]) thatis domain-independent. On the other hand, a specificprotocol, e.g., for shipment, may be domain-dependent.The second concern is semantic content, i.e., the nature of theinteractions. For example, a protocol specification may usejust the request-reply mechanism, relying on messagecontent (e.g., destination, payment info) to capture content.On the other hand, the message itself may capture thesemantics to distinguish actions, such as direct, inform,cancel, and others. Finally, composability [31] is concerned

with how a designer might specify the process by combiningprotocols [32].

To illustrate protocol specification, we draw on acommon business process for purchasing, drawn from theSecure Electronic Transactions (SET) standard [33], origin-ally described by Desai et al. [28]. Four main rolescollaborate to carry out this process:

1. the Customer, who wants to purchase items,2. the Merchant, who sells items,3. the Shipper, who transports the physical items to the

Customer, and4. the Payment Gateway, who authorizes payments.

Fig. 3 (adapted from [28]) illustrates how the four agentscollaborate, denoted as circles. The rectangles at the role’sedge denote data transferred via labeled service messages.The numbers indicate typical sequencing. The ordering onmultiple outward edges from a process (e.g., Merchant:task 9) is nondeterministic—the implementation can chooseany ordering, including concurrent.

Execution of the purchase process requires interactionprotocols, which may be specified with message sequencediagrams (see Fig. 4). They describe how each message(communicative act) results in commitments (CC), whichare described in the next section. Each sequence specifies aprotocol (e.g., Payment, Shipment, and Order). A designercan compose these to design an operational system:

Shipping protocol � Payment protocol � Order

protocol � Purchase process

A design mapping specifies how the protocols apply tothe purchasing process. Part of that mapping is presentedhere (where x/Y means that x is substituted for variable Y):

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

Fig. 2. Service, conversations, and processes.

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

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


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].

A commitment C(x; y; p) denotes that agent x is obliged toagent y for bringing about condition p.

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

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

operations on commitments such as: create, cancel, release,

assign, delegate, and discharge. They also specify commit-

ment rules, such as C(x; y; p) ^ p � ! discharge(x, C(x; y; p)),

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

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

framework also supports the specification of protocol

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

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

that a request for quote is eventually followed by a quote and

a conditional commitment (to deliver goods for a payment).

As Desai et al. illustrate that the �-calculus (a process algebra)

can be used to formalize the protocol specifications in terms

of operations and their associated commitments. For exam-

ple, an informal translation of a �-calculus specification of the

Seller process is: the seller receives itemID, consults its policy for

quoting and sends the quote price itemPrice, and receives either

accept-Quote or reject-Quote. Their approach to specifying

protocol policies has these characteristics:

1. Commitments are associated with protocol specifi-cations.

2. Commitment ordering is not directly specified. Forexample, the commitment on the quote operationsimply indicates that the buyer and seller aremutually committed based on two dependent con-ditions (pay and deliver).

3. Commitments are referenced only via the concreteoperation with which they are associated.

4. Reasoning is only supported at design-time.

We find this approach appealing. Our work extends the

Desai et al. approach by:

1. supporting specification abstractions over agentsand their operations,

2. supporting a mapping function from operations tocommitments, thereby decoupling the two,

3. supporting reasoning at runtime, and4. supporting the commonplace language of UML and

its OCL.

These extensions are on our research path, which uses a

Language-Action Perspective. We turn next to describing

how our work uses these theories.

2.3 The Language-Action Approach

The Language-Action Perspective provides the opportu-

nity to characterize messages in conversation protocols as

actions. A key foundation for LAP is the Communicative

Acts [13]: it suggests that an utterance is the performance

of a purposeful act, a speech act or communicative act.

LAP emphasizes that the performance of business pro-

cesses can be regarded as inter-related Communicative

Acts [34], each with standard effects and extended effects.

Standard effects occur as a result of the illocutionary


Fig. 4. Protocols for the purchase process (from [28]).http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


portion of a communicative act, and can, therefore, beidentified without knowing the content of the message(i.e., the message type is sufficient). For example, an agentthat sends a message of type acceptQuote has the effect ofcommitting the agent to a contract. Extended effects occuras a result of the perlocutionary portion—they representchanges in the receiver’s beliefs and goals, which isimportant for analyzing commitments. For example, whenan agent’s last commitment causes its obligated effort toreach a threshold, then the agent shall change its state tothat of accepting no further requests (i.e., the agent is overcommitted). The layered views suggested by languageaction theorists [16], [17] provide a way to consider theseextended effects. The ideas presented by Desai et al.provide only partial recognition of these effects. Neitherdoes it use these effects for the purpose of monitoring. Weintend to specifically address extended effects, explicitlyrepresenting and updating each agent’s commitments. Tothe best of our knowledge, there are no frameworks thatutilize such an approach for monitoring service systems.The framework we develop next undertakes this challenge.

3 SERMON: A MONITORING FRAMEWORK FOR

SERVICE SYSTEMS

We follow the design science approach [35] to develop theSERMON framework. It embodies our theory of a Language-Action-based approach to monitoring service systems. Akey element of our research is our ontology of commu-nicative acts (CACTS) and its use for multilevel monitoringof service systems. We hypothesize that our LAP-basedservice system ontology is sufficient for specifying andmonitoring service-related commitments of business proto-col policies. The CACTS ontology is derived from our work[18] and others [28], who have previously shown the valueof formal constructs for protocol policies. Our researchevaluation is focused on the sufficiency and utility ofCACTS. We apply the Hevner et al. [35] descriptive approachto design science evaluation—illustrative scenarios andargumentation. Additionally, we present some performancemeasures and anecdotes of usage. Thus, we present ourdesign science activities that are essential to realize theCACTS ontology, and evaluate it for specification andmonitoring.

The SERMON framework extends a requirements mon-itoring framework REQMON, which supports 1) goalspecification; 2) monitor compilation (from goals); and3) runtime goal evaluation of a software system [36], [37].REQMON supports GORE (i.e., Goal-oriented requirementsengineering) [38] with three phases: 1) identifying goals;2) refining and formalizing goals; and 3) deriving andassigning operations to agents [39]. It uses goal modeling,which an analyst can refine to derive operational descrip-tions including pre- and postconditions [40]. REQMON

follows a model-driven architecture (MDA). It relies on theEclipse Modeling Framework (EMF) for its metamodel andthe OSGi specifications, which specify Java-managedcomponents. REQMON is implemented with Eclipse(metamodel and user interface tools) and Equinox (com-ponent server). SERMON extends REQMON by specifyingLAP-oriented types (in EMF) and specifications (in avariant of the Object Constraint Language). Thus, SERMON

uses all the core components of REQMON, but the objectsmanipulated are those specific to the SERMON design. Weelaborate the LAP-specific concepts next.

3.1 Methodology and Architecture

The SERMON methodology uses a tailored approach forspecifying service interaction goals that builds on theunderlying GORE model. These include: 1) agent servicegoals and 2) agent protocol goals. Agent service goalsdescribe desired characteristics of an agent’s behaviorduring the execution of a protocol, for example, “providetimely response to a request.” Agent protocol goals describedesired characteristics of an agent’s behavior as it managesmultiple protocols simultaneously, for example, “abandon aprotocol execution that may not result in a commitment.” Basedon the goal model, monitors are compiled and themonitoring system is deployed. Once deployed, the monitorupdates the runtime status of the goals as the targetsoftware system executes.

As events arrive, they are stored in the repository, whichis analyzed for goal satisfaction. The results may bepresented on a dashboard or they may guide activeresponses, such as selecting alternative services. TheSERMON repository stores event data as well as analysisresults. It consists of four layers.

. Level 0 (events): The lowest layer stores raw datasuch as, “agent x receives message m from agent y.”

. Level 1 (ontology): The next layer stores an inter-pretation of the event data using terms from aselected ontology. Herein, a communicative actontology is used for record events such as “agent xcommits to do z for agent y.”

. Level 2 (properties): Properties of level 1 events arestored at layer 2, for example, the property “agent xnever violates a commitment” is true.

. Level 3 (metaproperties): Properties about propertiesare stored at layer 3, for example, “property p1 has a75 percent success to failure ratio over the last 72 hours.”

Layers 1, 2, and 3 correspond to the instance, domain, andmeta layers of the KAOS model [41]; layer 0 is like aphysical data layer and is not considered in KAOS model.

The SERMON framework, thus, 1) treats services as unitsthat require monitoring, and 2) treats communicative actsperformed by services (as part of conversations), asoperations on commitments. SERMON does not presume aglobal view of the overall process. Instead, it monitorsbehaviors of individual services as they participate inconversations with other services.

3.2 Communicative Acts

The SERMON framework relies on a parsimonious set ofCommunicative Acts based on the approach and outcomesoutlined in Umapathy and Purao [42] that subsumes the23 acts suggested by Moore [43], and 12 acts suggested byJohannesson and Perjons [44]. Their redefinition, elimina-tion, and mapping of these results in nine CommunicativeActs, (see [42]) that we use; see Table 2.

3.3 Specification Language

Protocol specifications and their associated commitmentscan be considered from two perspectives:


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


1. Specifying with Desai’s commitment logic andreasoning at design time with the �-calculus.

2. Specifying with OCL and reasoning at design-timewith LTL (cf., [45]) and runtime with the SERMON

analysis tools, which compare the running processeswith their specified properties.

There is a natural translation from Desai’s specification to

our OCL specifications. We generally specify directly in

OCL rather than translate from Desai specifications, in part,

because OCL simplifies specification with its support of

abstractions over agents and their operations. Our OCL

specifications have the advantage of being monitored at

runtime, which we demonstrate in Sections 3.4 and 4.SERMON employs a variant of the Object Constraint

Language (OCL) 2.0 [46], OCLTM (OCL with Temporal

Message logic). The OCL is similar to first-order predicate

calculus in that it allows specification of Boolean expres-

sions with logical connectives, with universal and existen-

tial quantifiers. For example, one can specify that all

employees of a company must be less than 65 years old:

context Company

inv: employee->forAll(p: Person j p.age < 65)

The expression is an invariant of the context Company, a

UML class. The OCL uses the familiar object-oriented dot

notation to navigate object graphs, and the arrow (�> ) to

navigate an object collection. Collection operations, such as

forAll and exists, have their own specific parameters.

In the preceding expression, elements in the employeecollection are designated p, a Person object, which isconstrained to have an age value less than 65.

OCLTM uses Flake temporal message semantics [47].Both sentMessages and receivedMessages return a

Sequence of OclMessage objects, and sentMessage andreceivedMessage returns the last, most recent messagein the sequence. OCLTM also includes temporal patterns[48] and timeouts; and linear temporal logic operators [41],[49] as shown next (keywords in bold):

� (the next state) . (the prior state)

� some time in the future, ^ (some time in the past,

eventually) previously)

ut (always in the future) (always in the past,constantly)

W (always in the future U (always in the future

unless) until)

With these, one can express “eventually class object objwill receive message msg” as follows:

context Class

inv: msgArrives:

eventually(receivedMessage(msg()))

The Flake temporal message semantics rely on an eventhistory, which is accessed via the Flake operations definedon OclAny. All sent messages can be accessed as follows:

OclAny->allInstances()�>forAll(i: OclMessage j i.sentMessages())�>collect()

Protocol policies are expressed as goals in OCLTM. Fig. 5illustrates a goal hierarchy in the OCL. The goal,goalRoot1,expresses the root with goals g1 through g3 as subgoals.The entire hierarchy is associated with the class MyClass.The hierarchy can be associated with any UML contextincluding classes and operations.

The language allows class inheritance, which can beexploited to simplify specification by abstracting goals,agents, and operations. For example, Child and its super-class Parent, can both have associated goals. Here, the Childis associated with both goals goalA and goalB.


TABLE 2A Parsimonious Set of Communicative Acts [42]

Fig. 5. A goal hierarchy in OCL.

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


context Parent

inv: goalA: - - ...

context Child

inv: goalB: - - ...

A properly annotated class hierarchy provides a means todescribe requirements at multiple levels of abstraction. Thelanguage, thus, allows specification at varying levels ofspecificity, and thereby, supports monitoring at varied levels.

3.4 Interpreting Events as Communicative Acts

To relate the theory of LAP-based analysis with an actualrunning software system, it is important to specify howreal-world events are characterized as LAP concepts. ForSERMON, events are stored into the repository (seeSection 3.1) as the software system executes at runtime.They are interpreted using the communicative acts(CACTS) ontology (see Table 2). The SERMON frameworkrelies on event adaptors in REQMON. An event is typicallycreated by a logging program. SERMON listens to these logstreams. As an event arrives, a chain of event adaptorstransform the event, as desired. For example, a commonevent transformation is:

Log4jEvent ! CommonBaseEvent ! OclMessage

The final object is stored into the repository. In thepreceding, the object is stored as an OclMessage object.The SERMON framework uses a mapping within theTransformEventAdaptor to map the incoming eventsto communicative acts (cacts).

As events are received by SERMON, the Transform-

EventAdaptor transforms the received event according toa specified mapping. Based on the preceding, the event of anobject receiving a quote request is represented as a Proposeevent, which is a subclass of CommunicativeAct, which,in turn, is a subclass OclMessage. Thus, the precedingevent transformation becomes the following sequence whenthe SERMON TransformEventAdaptor is applied:

Log4jEvent ! CommonBaseEvent !CommunicativeAct

The preceding illustrates a simple mapping, from amethod name to a communicative act. However, one candefine a mapping that considers the method name,associated sender and receiver, and other contextualinformation. In such cases, a developer can write additionalcode or a rule-base system to characterize a received eventaccording to an ontology. Fig. 6 illustrates the commu-nicative acts defined in Table 2.

The root of the hierarchy is CommunicativeAct. Itstwo subclasses, Request and Response, partition theremaining acts. By being a subclass of OclMessage,CommunicativeAct, and its subclasses use the OCLontology. It also includes some user-defined methods. Forexample, the correspondsTo method returns true whenthe two messages take part in a request-response dialog.

The tactic of mapping events to communicative actsdiffers from the Desai et al. approach, which directlyassociates commitments with operations [28]. In SERMON,policies can be specified in terms of abstract events, such asthose defined in the CACTS (see Fig. 6). The event mappingdecouples the specification from the implementation. Asnew service operations are implemented, only their CACTS

mapping is needed, because the policies remain associatedwith the abstract CACTS operations. Section 4 illustratessuch abstract policy specification.

3.5 Goal Monitor Compilation

Each goal specification is automatically compiled into a goal

monitor by translating each specification into a property

evaluation tree, where each node is a rule set [50]. Consider

the following simple property as an illustration:

context ContextClasss

def: m1 : OclMessage =

receivedMessage(message1())

def: m2 : OclMessage =

receivedMessage(message2())

inv: prop:

after(eventually(m1),eventually(m2))

A simple compilation of prop generates three main rules:

1) evaluate (eventually m1); 2) evaluate (eventually m2);

and 3) the root of the tree: evaluate (after(eventually

m1) (eventually m2)).

3.6 Event Stream Interpretation

Finally, at runtime, the compiled property rules interpretthe event stream. The monitor acquires events fromthe instrumented program. As events arrive, rules evaluatethe property evaluation trees. For example, for the leaf nodeeventually m1, the rule’s left-hand side (LHS) matches arepository assertion representing a received message1;other LHS expressions may further constrain the evaluation.As nodes are satisfied, their values are propagated up thetree, until finally, the entire prop expression is evaluated.

4 SCENARIO-BASED EVALUATION

The SERMON framework specifies a novel approach formonitoring that relies on an ontology of communicative acts


Fig. 6. Communicative acts as an EMF model.

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


for multilevel monitoring of service systems. Here, weillustrate an implementation of the framework and applica-tion to the purchase process example (see Fig. 3).

We hypothesized that the CACTS ontology is sufficientfor specifying and monitoring service-related commitments.To evaluate sufficiency of expression, we created over 50specification expressions derived from policy specificationsfound in the related literature (summarized in Section 5.3);in particular, Dwyer reviewed 555 specifications, 92 percentof which match the temporal patterns that are part ofOCLTM [36], [48]. Next, we specified business protocolpolicies, derived from the literature, using CACTS. Finally,we created and ran programs that satisfied and violated thepolicies. The success of specifying and monitoring manypolicies from the literature suggests that the CACTSontology is indeed sufficient for specifying and monitoringservice-related commitments.

The next two sections illustrate some specifications fromour literature-based collection of test scenarios, using thecontext of the purchase process example (see Fig. 3).The scenarios are intended to: 1) establish the feasibility ofthe framework and 2) demonstrate expressiveness ofCACTS. Together, these techniques provide an evaluationof the SERMON framework following an approachedrecommended by Hevner et al. [35].

4.1 Scenarios Demonstrating Agent Service Goals

Agent service goals describe desired characteristics of anagent’s behavior during protocol execution (see Section 3.1).Many agents share common goals, such as “be responsive.”The purchase process example illustrates such commongoals. The following formulas illustrate common goals. Inthe formulas, highlighted words are OCL keywords,including temporal patterns, such as after, before,between, response, etc. [48].

We begin our scenarios with the agent goal of “receivequote after query,” shown in Formula 1. The first two agentdefinitions designate the receipt of a Query message withmethod name requestForQuote and a Propose messagewith method name quote, by an agent. The quoted

invariant constrains how these messages can be related. Itstates that after the query is received, then eventually, acorresponding proposal shall be received. (The temporalpatterns accept a Boolean argument; thus, the idiomeventually(query<>null) is used to check existence.)Placing this invariant on the Agent class, rather than itssubclasses (e.g., Buyer and Seller), simplifies the expression.Formula 1 states that, no matter which agent is involved, anagent’s Query shall be followed by a correspondingPropose.

Formula 1. Must respond to a Query with a Propose.

Formula 1 represents the standard effects of LAP—onemessage type (Query) shall be followed by anothermessage type (Propose). Not all formulae, however, needbe specified in this manner. We may also specify theextended effects, which describes changes in the commit-ment state of the receiver [28]; later, Formula 6 illustrates anextended effects specification.

Formula 2 is similar to Formula 1. However, it introducesa timeout that the response must meet. Additionally, itinterprets the two messages as abstract types (Request andResponse, respectively). This formula acknowledges theexistence of a commitment over a time period.

Formula 2. Timely response expressed with timeout.

Formula 3 provides another variation. Here, a messagequeue query limits the kinds of messages selected to becompatible with Request and Response types.

Formula 3. Timely response expressed with queue query.

As a final variation, we present Formula 4. It does notreference the method name. Instead, it characterizes themessages as being compatible with Commit and Fulfill

types. Thus, property expressions can rely on agent andmessage type hierarchies, as well as common databaseexpressions over their properties.

Formula 4. Timely response expressed with message type.

We can also express simple properties, such as eachfulfillment shall be compensated, as Formula 5 shows. Itassumes that compensation is provided through a fulfillmentcommunicative act, which can result from discharging acommitment [28].


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


Formula 5. Provides compensation expressed with acommunicative act (CACTS) operation.

The preceding demonstrates concise constraints overagent and message abstractions, important for expressingprotocol goals. The customer, merchant, and paymentgateway are all subclasses of agent. Thus, each inheritsanalysis of the superclass Agent properties. Of course, theagent subclasses can add more specialized goals. Over-riding (or hiding) properties is unnecessary for monitoredproperties. The monitor simply reports on the satisfaction ofproperties. It is possible to specify inconsistent properties aswell because the monitor does not enforce these constraints.

4.2 Scenarios Demonstrating Agent Protocol Goals

The formulas so far demonstrate goals associated with two-agent dialogs. Next, we demonstrate protocol shared goalsof the purchase process agents. The properties specify howan agent can participate in multiple conversations.

Formula 6 limits unfulfilled commitments. If placed in theAgent, it is only satisfied when the number of all committed-but-unfulfilled acts is less than Agent.commitLimit

(which may have different values for different subclasses).In effect, it recognizes the LAP extended effect of creating acommitment, while limiting the effort to which an agent maycommit.

Formula 6. Limit unfulfilled commitments.

Formula 7. illustrates a protocol transition property.Eventually, after a commitment, the commitment must befulfilled or canceled. This is an LAP extended effect policyabout agent commitments.

Formula 7. Property specifies transition to a final state.

Formula 8 specifies that an agent must consider theremaining resources and required resources before re-sponding to a request. This is another extended effectpolicy, which specifies the internal workings of an agent. Inparticular, the resources required of a new request shall notexceed the remaining resources. The resource methods havedefault definitions on the Agent class, but its subclasses canoverride the method. Again, such methods are part of thespecification of the ontology (see Section 3.2).

Formula 8. A constraint between an Agent’s resourcesand responses limits committed resources.

A variety of protocol policies can be specified in thismanner. These policies seamlessly integrate standard andextended effects over agent and operation-type hierar-chies. As further illustration, consider the following(informally specified) policies, each in effect, representingan aggregation of extended effects, which contribute tothe state of an agent.

If the agent’s commitment level is higher than a thresh-old, then do not start new conversations.

If the agent’s commitment level is approaching a thresh-old, then complete high-value conversations.

If the agent’s commitment-level is approaching a thresh-old, complete conversations with high-value customers.

Increase priorities of conversations that require an actionof Commit as opposed to those requiring other actions, suchas Inform.

4.3 Scenario Demonstrating Goal Monitoring

The runtime evaluation of goals is illustrated in Formula 9.Reconsider the purchasing process example of Section 2.To evaluate the Agent goals quoted (Formula 1) andtimelyResponse (Formula 2) in the Order protocol ofFig. 4, we followed these activities:

1. The target SET service system, containing the Buyer,Seller, etc., was implemented as a multithreadedJava program.

2. The target system was instrumented, using EclipseTPTP, to output selected method calls.

3. The SERMON server was started, with the Orderpolices loaded.

4. The target service system was executed.5. The SERMON server received event stream of

method calls from execution of the Order protocol.6. The SERMON server analyzed the event stream,

evaluating and reporting on property satisfaction.

With each new monitored input, the monitor analyzes andupdates property evaluations. Primitive (nested) propertiesare evaluated first, and their values are propagated forcomposite properties.

The subscenario between the Buyer and Seller in thepurchasing process (from Section 2) is initiated as a thread.The resulting property evaluation uses Agent goals quoted(Formula 1) andtimelyResponse (Formula 2). The monitorinput data consists of two significant events in sequence. Thefirst input event occurs when the Buyer object sends a requestfor quote, which is interpreted both as a Query commu-nicative act and as a Request. The monitor processes the


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


event, asserting that the first eventually subproperties ofquoted (Formula 1) and timelyResponse (Formula 2) aretrue. Thus, all invariants are processes simultaneously, andthe same event can be interpreted in multiple ways; here, as aQuery in Formula 1 and as its superclass Request inFormula 2. For each formula, this propagates the state of theirscopes after to be open. The second eventually sub-property of quoted (Formula 1) and timelyResponse

(Formula 2) becomes true with the assertion of the quote fromthe Seller. These values propagate to each property.

Formula 9. SERMON output as Proof-of-Concept.

Note: Properties quoted and timelyResponse. SA

means scope activation, p@ is a property prefix, and s@ is ascope prefix. The brackets “[]” include object references.The first scope activation SA@db4fa2 is the global scope.

All service and protocol goals are monitored with thisapproach. Thus, as the service system executes, SERMON

provides notification as each goal is satisfied or violated.Therefore, business analysts can understand the current stateof their systems in terms of high-level service and protocolgoals. Through such analysis, SERMON provides notificationof policy compliance (or violation) for service systems.

4.4 Monitor Performance

Monitoring has little impact on the target system, mostlybecause the target system and monitor typically run onseparate computers. The TPTP Probekit provides optimizedbyte-code instrumentation, which adds little overhead tosome (selected) method calls in the target system. Thelogging of significant events consumes no more than5 percent, and typically less than 1 percent overhead.

For real-time monitoring, it is important to determine ifthe target events can overwhelm the monitoring system. Aperformance analysis of REQMON was conducted bycomparing the total monitoring runtime versus withoutmonitoring using 40 combinations of the Dwyer temporalpatterns [48]. (This is pertinent because SERMON executesthe same LTL property monitoring algorithm, but withdifferent objects (see Section 3)—the monitoring primitiveconstructs are the same, and thus, the performance isessentially the same.) For data, a simple two-event sequencewas the basis of the test datum; for context, considerthe events as an arriving email and its subsequent reply.

These pairs were continuously sent to the server 10,000 times.In the experiment, the event generator and REQMON ran inthe same multithreaded process. The test ran as a JUnit testcase within Eclipse on a Windows Server 2003 dual core2.8 GHz with 1 G memory. The results suggest that, withinthe test configuration, sequential properties (of length 2) areprocessed at 137 event pairs per second [51]. This indicatesthat REQMON is reasonably efficient for many monitoringproblems.

4.5 SERMON Application

Our application of SERMON and REQMON to monitoringproblems suggests that the approach is useful. Like anysoftware system, monitor system development can becomplex and time-consuming. By limiting the specificationlanguage to DSLs based on OCL, much of the developmentprocess is automated. Yet, this raises the concern that themonitor specification may be too limiting to express somedesired policies. Our experience within the service systemsis the basis for the following insights.

Our experience is that typical policies and their monitorsare simplified in CACTS. The underlying REQMON

language includes temporal patterns and timeouts, whichseemed to simplify property specifications according toDwyer et al. [48], which has also been our experience for theemailing domain [51], and now for the service-policydomain. Moreover, the CACTS DSL simplifies the expres-sion of common communication patterns in service policies.It was relatively simple to specify, for example, “after anagent commits to an action type, that agent shall fulfill that actionwithin a specified period”—see Section 4.1. CACTS simplifiessuch expressions by providing commitment logic over classhierarchies with temporal and real-time constraints. Asfurther validation, we reviewed property expressions fromrelated monitoring systems (see Section 5.2) and found thatthey all can be represented in SERMON. Our success,however, does not suggest that all the properties kinds forthe service-system domain can be represented, only that wefound it reasonable for many common service policies.Finally, our findings may not generalize to other monitoringprojects. Nevertheless, given the service system propertycomplexity, it does suggest that this approach may beutilized in a variety of application domains.

5 DISCUSSION

Our approach for specifying and monitoring participantactions and their effects on commitments extends andaugments recent work that has begun to recognize theincreasingly distributed nature of business processes in openenvironments. To overcome the shortcomings of centralizedbusiness-process specifications, we reconceptualize businessprocess specifications in terms of conversations amongparticipants. These conversations contain communicativeacts, which result in manipulation of commitments. Here, wecompare our work with other research efforts.

5.1 Interaction Protocols in Service Systems

Barros et al. [27], Decker et al. [26], and more recently, Desaiet. al. [28] have argued that interactions among servicesconstitute an important design element. Barros et al. [27]along with Decker et al. [26] propose a number of


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


archetypal interactions among services, and formalize thesewith Pi-calculus. The dimensions they consider includenumber of participants, exchanges, and routing of mes-sages; but stops short of adding semantics to the messages.

Another early effort is Moore [29], who envisions asystem of conversations (with Bach and Harnish’s [52] set ofcommunicative acts) as a reactive system, modeled withstate transition nets. His work represents a departure fromthe ideas of Barros et al. because it attempts to addsemantics to messages. He outlines the possibility ofconsidering conversations as a central abstraction. Uma-pathy and Purao [18], [42] build on this work, suggestingthat interactions among web services may allow us tobridge the gap between design knowledge and executablespecifications [25].

Maximilien and Singh [53] explore possibilities formodeling and execution of service systems as a set ofinteractions in the context of multiagent systems. Theseinclude process adaptations [54], specifying preferences[55], and deviations to protocols [56]. Desai et. al. [57]describe an approach that builds on the establishment anddischarge of commitments. They do not, however, explorethe possibilities for monitoring suggested by messagesequences and aggregating extended effects.

The database and software engineering researchersaddress interaction protocols for extending web services.For example, Baresi et al. [58] and Baresi and Guinea [59]suggest use of a web service constraint language and pre-and postconditions to specify process deviations. Lazoviket al. [60] suggest a service request language, building onprior work in a service assertion language [61]. Pistore et al.[62] suggest protocol combinations to monitor web servicecompositions. Xu and Jeusfeld [63] describe an approach formonitoring contracts. Taken together, these efforts providea first step toward monitoring but do not suggest acomprehensive, multilevel framework for monitoring.

Our work draws on and extends these efforts, andensures integration with practice with the help of OCL. Theframework we outline is also independent of SOAP versusREST styles [64]. The intention to treat a message as aspecific communicative act resides in the sender (as anillocutionary act, and is communicated to the receiver alongwith the content). The consequences of the communicativeact are witnessed as an extended effect on the receiver. Thepackaging of the communicative act (as SOAP- or a REST-)does not affect viability of the SERMON framework.

5.2 Monitoring Service Systems

Our approach may also be compared with prior researchin monitoring ([65], [66], [67], [68], [69]). Baresi et al.suggest an assertion annotation approach [70] to monitor-ing [71], [72] that includes a weaving mechanism tointegrate service execution with property monitoring. Themonitor they suggest intercepts communications to checkproperties using the Xpath-like queries. Yan et al. describehow to monitor web services using model-based diagnoses[73]. Researchers at Trento define an algorithmic frame-work in which a monitor controls an interleaved planner[10], [74] that replans when web service failures areobserved. Roth et al. define and implement extensions toBPEL to support monitoring [75]. Ludwig et al. outline a

general architecture for creation and monitoring of webservice agreements [76].

Our work extends this stream. It is focused on meeting

monitoring needs via an independent monitor and an

expressive language:

1. that allows domain-specific extensions from stan-dard OCL and user-defined library extensions;

2. that supports property inheritance with expressionsbased on standard OCL and associated UML;

3. that extends OCL with relational, temporal, and real-time expressions; and

4. that supports metarequirements with properties asUML classes, directly manipulated as “first-class”

constructs.

The examples of Section 4 illustrate how OCL supportsthese expressions. As an illustration of a metaproperty,consider the following expression:

Formula 10. Agent meta property.

The property mostlySatisfied references thetimelyResponse (defined in Section 4.1). In OCL,invariants are (implicitly) subclasses of the UML classRM::Property. Therefore, properties and their instancescan be referenced using standard OCL constructs. Thus,mostlySatisfied is satisfied when the ratio of satisfiedto total timelyResponse evaluations is greater than75 percent. Of course, mostlySatisfied is itself aproperty, and thus, can also be analyzed.

Our work also seeks monitor independence. Thus, the

monitoring system is defined independent of any parti-

cular target system. Therefore, the monitoring system can

work equally well for standard programs, web services,

or grid applications. The only requirement is that the

target programs provide events that can be filtered, and

then, analyzed.

5.3 Semantics of Service Interaction Policies

SERMON supports reasoning with communicative acts and

operations on commitments. To illustrate, consider the (last)

three invariants of Formula 11.

1. sendQuote illustrates a message-based property. Inthis representation, relationships among web ser-

vices messages are directly specified.2. quoteCommit illustrates a communicative-act-

based property. In this representation, messages

are mapped to Communicative Acts, whose relation-

ships are constrained.

dischargeCommitments illustrates a commitment-based

property. In this representation, commitment operations

are specified for communicative acts.


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


Each subsequent representation builds on the prior toadvance the kinds of analyses possible. In contrast toSERMON, other monitoring systems are message-based only.

Formula 11. Three kinds of specifications.

More generally, consider the relationship betweenCommunicative Acts to specify message semantics andservice commitments. Following Desai et al., “commitmentscapture a variety of contractual relationships, whileenabling manipulations, such as delegation and assign-ment” [28]. Manipulations of commitments, thus, representconsequences of message exchanges. Following the lan-guage-action perspective we suggest, these operationsrepresent extended effects of communicative acts. Forexample, a request may not lead to the creation ofcommitment depending upon the state of the conversationas well as other current commitments for the service. Thisdistinction is analogous to standard effects and extendedeffects following the language-action perspective, and isimportant for our approach. Table 3 describes these and

maps them against possible conversations. Further work tomap these is needed.

The SERMON approach supports message semantics(especially extended effects), which is unique in the growingresearch on service-policy monitoring. Unlike other projectsthat are specialized, our work focuses on monitoring ageneric service system with the help of language actionprimitives. Table 4 compares our work against relatedservice-policy monitoring systems with respect to threemain characteristics:

1. Ontology: Table 4 shows the most specificationsconcern web services (in their terms), while fewerconsider commitments. SERMON addresses bothand the underlying metamodel support additionaluser-defined terms.

2. Properties: Prior efforts provide logical propertydescriptions; most characterize these as classeswithout utilizing inheritance. Fewer include tempor-al or real-time properties. Only SERMON allowsinheritance and metaproperties.

3. Scope: In prior efforts, policies apply to servicemessages. Few consider conversation as a unit forpolicies. Only SERMON applies to conversationsand their aggregation with consideration of ex-tended effects.

6 CONCLUSION

We have presented a framework and an approach formultilevel monitoring of service systems. It draws inspira-tion from the language-action perspective and extendsrecent work related to commitments. The key contributions,specific to the use of language-action perspective, includethe following:

. Specification of an ontology of communicative actsthat adds semantic content to messages.

. Support for the specification of policies that addressstandard and extended effects of communicativeeffects for multilevel monitoring.

In addition, the framework specified supports the

following:


TABLE 3Mapping Operations on Commitments [28]

against Communicative Acts

TABLE 4Comparison with Policy Monitoring Systems

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


. Support for the specification of abstractions overagents and their operations, and decoupling opera-tions from commitments via a mapping specification.

. Service system specifications for an arbitrary num-ber of services and processes.

. Specification of message semantics.

. Specification of local service behaviors that contri-bute to the participation in multiple conversations.

Following the design-science approach [35], the frameworkembodies our working theory for multilevel monitoring,which we evaluate by

. demonstrating feasibility (Section 3.3),

. application to scenarios (Section 4),

. comparison against prior efforts (see Table 4).

The evaluation demonstrates comparative advantages ofthe framework against similar approaches, and how thecapabilities of the framework address the needs of multi-level monitoring of service systems. Future work is focusedon applying the framework to real-world case studies, andextending the approach to encompass additional levelssuggested by LAP frameworks, such as contracts andmultiple contracts that require ongoing relationships. Forexample, the goal hierarchy we have outlined contains twogoal categories (agent service and agent protocol goals). Weanticipate additional goal categories to account for complexservice systems. The framework we have outlined providesan important foundation for these later investigations.

REFERENCES

[1] Gartner-Group, “SOBAs Will Revolutionize Application Integra-tion,” http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci965822,00.html, 2002.

[2] J. Dang and M.N. Huhns, “Coalition Deal Negotiation forServices,” Proc. First Int’l Workshop Rational, Robust, and SecureNegotiations in Multi-Agent Systems (RRS ’05), p. 67, 2005.

[3] L. Brownsword et al., “System-of-Systems Navigator: An Ap-proach for Managing System-of-Systems Interoperability,” Tech-nical Note CMU/SEI-2006-TN-019, http://www.sei.cmu.edu/publications/documents/06.reports/06tn019.html, Oct. 2006.

[4] J. Lee, K. Siau, and S. Hong, “Enterprise Integration with ERP andEAI,” Comm. ACM, vol. 46, no. 2, pp. 54-60, 2003.

[5] D. Robey, D.L. Farrow, C. Franz, and R. Franz, “Group Processand Conflict in Systems Development,” Management Science,vol. 35, no. 10, pp. 1172-1191, Oct. 1989.

[6] C. Brown and I. Vessey, “Managing the Next Wave of EnterpriseSystems: Leveraging Lessons from ERP,” MIS Quarterly Executive,vol. 2, no. 1, pp. 65-77, 2003.

[7] M. Hellinger and S. Fingerhut, “Business Activity Monitoring: EAIMeets Data Warehousing,” Business Integration J., 2002.

[8] W.N. Robinson, “A Roadmap for Comprehensive RequirementsMonitoring,” Computer, pp. 64-72, vol. 43, no. 5, May 2010.

[9] D.K. Peters and D.L. Parnas, “Requirements-Based Monitors forReal-Time Systems,” IEEE Trans. Software Eng., vol. 28, no. 2,pp. 146-158, Feb. 2002.

[10] A. Lazovik et al., “Associating Assertions with Business Processesand Monitoring Their Execution,“ Proc. Second Int’l Conf. ServiceOriented Computing, pp. 94-104, 2004.

[11] S. Turner et al., “Distributed Supply Chain Simulation Using HighLevel Architecture,” Trans. Soc. of Computer Simulation, vol. 18,no. 2, pp. 98-108, 2001.

[12] F. Curbera et al., “Unraveling the Web Services Web: AnIntroduction to SOAP, WSDL, and UDDI,” IEEE Internet Comput-ing, vol. 6, no. 2, pp. 86-93, 2002.

[13] J.L. Austin, How to do Things with Words. Oxford, 1962.[14] J. Searle, Speech Acts: An Essay in the Philosophy of Language.

Cambridge Univ., 1969.[15] J. Habermas, The Theory of Communicative Action, p. 465. Beacon,

1984.

[16] M. Lind and G. Goldkuhl, “Generic Layered Patterns for BusinessModelling,” Proc. Int’l Working Conf. Language-Action Perspective onComm. Modelling (LAP), 2001.

[17] J.L.G. Dietz, “The Atoms, Molecules and Matter of Organiza-tions,” Proc. Int’l Working Conf. Language-Action Perspective onComm. Modelling (LAP), 2002.

[18] K. Umapathy and S. Purao, “A Theoretical Investigation of theEmerging Standards for Web Services,” Information SystemsFrontiers, Special Issue of Information Systems Frontier (ISF)—From Web Services to Services Computing: Technologies andApplications, vol. 9, pp. 119-134, 2006.

[19] C. Peltz, “Web Services Orchestration—A Review of EmergingTechnologies, Tools, and Standards,” technical paper, HewlettPackard Labs, 2003.

[20] J.E. Hanson et al., “Conversation Support for Business ProcessIntegration,” Proc. IEEE Int’l Enterprise Distributed Object Comput-ing Conf. (EDOC), pp. 65-74, 2002.

[21] J.E. Hanson et al., “Conversation-Enabled Web Services forAgents and e-Business,” Proc. Int’l Conf. Internet Computing (IC),pp. 791-796, 2002.

[22] L. Polanyi, “A Formal Model of the Structure of Discourse,”J. Pragmatics, vol. 12, pp. 601-638, 1988.

[23] X. Fan et al., “A Theoretical Framework for Proactive InformationExchange in Agent Teamwork,” Artificial Intelligence, vol. 169,pp. 23-97, 2005.

[24] P. Stone and M. Veloso, “Task Decomposition, Dynamic RoleAssignment, and Low-Bandwidth Communication for Real-TimeStrategic Teamwork,” Artificial Intelligence, vol. 110, pp. 241-273,1991.

[25] G. Hohpe and B. Woolf, Enterprise Integration Patterns: Designing,Building and Deploying Messaging Solutions. Addison-Wesley,2003.

[26] G. Decker et al., “Formalizing Service Interactions,” Proc. FourthInt’l Conf. Business Process Management (BPM ’06), pp. 414-419,2006.

[27] A. Barros et al., “Service Interaction Patterns,” Proc. Third Int’lConf. Business Process Management, pp. 302-318, 2005.

[28] N. Desai et al., “Interaction Protocols as Design Abstractions forBusiness Processes,” IEEE Trans. Software Eng., vol. 31, no. 12,pp. 1015-1027, Dec. 2005.

[29] S.A. Moore, “On Conversation Policies and the Need forException,” Proc. Autonomous Agents Special Workshop ConversationPolicies, pp. 19-28, 1999.

[30] K. Umapathy and S. Purao, “Exploring Alternatives for Repre-senting and Accessing Design Knowledge about EnterpriseIntegration,” Proc. 26th Int’l Conf. Conceptual Modeling (ER ’07),2007.

[31] G. Decker and F. Puhlmann, “Formalizing Service Interactions,”Proc. Fourth Int’l Conf. Business Process Management (BPM ’06), 2006.

[32] S. Purao et al., “Improving Reuse-Based Design: AugmentingAnalysis Patterns Reuse with Learning,” Information SystemsResearch, vol. 14, no. 3, pp. 269-290, 2003.

[33] SET, “Secure Electronic Transactions (SET) Specifications,”http://www.setco.org/set_specifications.html, 2003.

[34] F. Flores and J. Ludlow, “Doing and Speaking in the Office,” Proc.Int’l Task Force Meeting Decision Support Systems—Issues andChallenges, vol. 11, pp. 95-118, 1980.

[35] A.R. Hevner et al., “Decision Science in Information SystemsResearch,” MIS Quarterly, vol. 28, no. 1, p. 75, 2004.

[36] W.N. Robinson, “Extended OCL for Goal Monitoring,” ElectronicComm. EASST, vol. 9, pp. 1-12, 2008.

[37] W.N. Robinson, “A Requirements Monitoring Framework forEnterprise Systems,” Requirements Eng. J., vol. 11, no. 1, pp. 17-41,2006.

[38] A. van Lamsweerde, “Goal-Oriented Requirements Engineering:A Roundtrip from Research to Practice,” Proc. IEEE Int’lRequirements Eng. Conf., pp. 4-8, 2004.

[39] A. van Lamsweerde et al., “Goal-Directed Elaboration ofRequirements for a Meeting Scheduler: Problems and LessonsLearned,” Proc. IEEE Second Int’l Symp. Requirements Eng., pp. 194-203, 1995.

[40] A. van Lamsweerde, “From System Goals to Software Architec-ture,” Formal Methods for Software Architectures, pp. 25-43,Springer-Verlag, 2003.

[41] A. Dardenne et al., “Goal-Directed Requirements Acquisition,”Science of Computing Programming, vol. 20, pp. 3-50, 1993.


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


[42] K. Umapathy and S. Purao, “Exploring Alternatives for Repre-senting Design Knowledge about Enterprise Integration,” Proc.Int’l Conf. Conceptual Modeling, 2007.

[43] S.A. Moore, “A Foundation for Flexible Automated ElectronicCommunication,” Information Systems Research, vol. 12, pp. 34-62,2001.

[44] P. Johannesson and E. Perjons, “Design Principles for ProcessModelling in Enterprise Application Integration,” InformationSystems, vol. 26, pp. 165-184, 2001.

[45] S. Morimoto, “A Survey of Formal Verification for BusinessProcess Modeling,” Lecture Notes in Computer Science, pp. 514-524,Springer, 2008.

[46] Object Constraint Language Version 2.0, Object Management Group(OMG), 2006.

[47] S. Flake, “Enhancing the Message Concept of the ObjectConstraint Language,” Proc. 16th Int’l Conf. Software Eng. andKnowledge Eng. (SEKE ’04), pp. 161-166, 2004.

[48] M.B. Dwyer et al., “Patterns in Property Specifications for Finite-State Verification,” Proc. 21st Int’l Conf. Software Eng., pp. 411-420, 1999.

[49] Z. Manna and A. Prueli, The Temporal Logic of Reactive andConcurrent Systems. Springer-Verlag, 1992.

[50] E. Friedman-Hill, Jess in Action. Manning, 2003.[51] W.N. Robinson and S. Fickas, “Talking Designs: A Case of

Feedback for Design Evolution in Assistive Technology,” DesignRequirements Engineering: A Ten-Year Perspective, K. Lyytinen et al.,eds., pp. 215-237, Springer-Verlag, 2009.

[52] K. Bach and R.M. Harnish, Linguistic Communication and SpeechActs. MIT, 1979.

[53] E.M. Maximilien and M. Singh, “Toward Web Services InteractionStyles,” Proc. Second IEEE Int’l Conf. Services Computing (SCC),2005.

[54] N. Desai et al., “Business Process Adaptations via Protocols,” Proc.IEEE Int’l Conf. Services Computing, pp. 103-110, 2006.

[55] A. Mallya and M. Singh, “Specifying and Resolving Preferencesamong Agent Interaction Patterns,” Proc. Int’l Conf. AutonomousAgents and Multiagent Systems (AAMAS ’06), 2006.

[56] A. Chopra and M. Singh, “Producing Compliant Interactions:Conformance, Coverage, and Interoperability,” Proc. FourthInt’l Workshop Declarative Agent Languages and Technologies,pp. 1-15, 2006.

[57] N. Desai et al., “Engineering Foreign Exchange Processes viaCommitment Protocols,” Proc. Fourth IEEE Int’l Conf. ServicesComputing (SCC), 2007.

[58] L. Baresi et al., “Smart Monitors for Composed Services,” Proc.Second Int’l Conf. Service Oriented Computing, pp. 193-202, 2004.

[59] L. Baresi and S. Guinea, “Towards Dynamic Monitoring of WS-BPEL Processes,” Proc. Int’l Conf. Service Oriented Computing,pp. 269-282, 2005.

[60] A. Lazovik et al., “Planning and Monitoring the Execution of WebService Requests,” Int’l J. Digital Libraries, vol. 6, pp. 235-246, 2006.

[61] A. Lazovik et al., “Associating Assertions with Business Processesand Monitoring Their Execution,” Proc. Second Int’l Conf. ServiceOriented Computing, pp. 94-104, 2004.

[62] M. Pistore et al., “Planning and Monitoring Web ServiceComposition,” Proc. Workshop Planning and Scheduling for Weband Grid Services, 2004.

[63] L. Xu and M. Jeusfeld, “Pro-Active Monitoring of ElectronicContracts,” Proc. Conf. Advanced Information Systems Eng., 2003.

[64] M. zur Muehlen et al., “Developing Web Services ChoreographyStandards—The Case of REST vs. SOAP,” Decision SupportSystems, vol. 40, no. 1, pp. 9-29, 2005.

[65] M.S. Feather et al., “Reconciling System Requirements andRuntime Behavior,” Proc. Int’l Workshop Software Specification andDesign (IWSSD ’98), 1998.

[66] W.N. Robinson, “Requirements Monitoring for Enterprise Sys-tems,” Requirements Eng. J., vol. 11, no. 1, pp. 17-41, 2006.

[67] W.N. Robinson, “Monitoring Web Service Requirements,” Proc.11th IEEE Int’l Conf. Requirements Eng., pp. 65-74, 2003.

[68] W.N. Robinson, “Monitoring Software Requirements UsingInstrumented Code,” Proc. 35th IEEE Ann. Hawaii Int’l Conf.Systems Sciences, 2002.

[69] W.N. Robinson, “Monitoring Software Requirements UsingInstrumented Code,” Proc. First Symp. Requirements Eng. forInformation Security, 2001.

[70] S. Sankar and M. Mandal, “Concurrent Runtime Monitoring ofFormally Specified Programs. I,” Computer, vol. 26, no. 3, pp. 32-41, Mar. 1993.

[71] L. Baresi and S. Guinea, “Towards Dynamic Monitoring of WS-BPEL Processes,” Proc.Third Int’l Conf. Service Oriented Computing,2005.

[72] L. Baresi et al., “Smart Monitors for Composed Services,” Proc.Second Int’l Conf. Service Oriented Computing, pp. 193-202, 2004.

[73] Y. Yan et al., “Monitoring Web Service Networks in a Model-Based Approach,” Proc. Third IEEE European Conf. Web Services(ECOWS ’05), pp. 192-203, 2005.

[74] A. Lazovik et al., “Planning and Monitoring the Execution of WebService Requests,” J. Digital Libraries, 2005.

[75] H. Roth et al., “Probing and Monitoring of WSBPEL Processeswith Web Services,” Proc. Eighth IEEE Int’l Conf. E-CommerceTechnology, p. 30, 2006.

[76] H. Ludwig et al., “Crona: An Architecture and Library forCreation and Monitoring of WS-Agreents,” Proc. Second Int’l Conf.Service Oriented Computing, pp. 65-74, 2004.

William N. Robinson is a member of theComputer Information Systems Faculty, GeorgiaState University, Atlanta. He has served theRequirements Engineering community as secre-tary of the International Federation for Informa-tion Processing Working Group (IFIP) 2.9 onRequirements Engineering, chair of the Require-ments Engineering Conference in 1999 and2009, and editor-in-chief of the RequirementsEngineering Journal. His research interests

include requirements monitoring and analysis, agent simulation, andsupply-chain analysis. He is a member of the IEEE and the IEEEComputer Society.

Sandeep Purao received the PhD degree inmanagement information systems from theUniversity of Wisconsin. He is on the faculty atthe College of Information Sciences and Tech-nology, Pennsylvania State University, Univer-sity Park. Prior to joining Penn State, he was onthe faculty at Georgia State University. Hisresearch interests include the design, evolution,and management of complex techno-organiza-tional systems. His current projects include

design knowledge reuse, process automation and monitoring, riskmitigation in large-scale projects, and technology standardizationprocesses. His work has been published in journals such as Commu-nications of the ACM, the IEEE Transactions on Systems, Man andCybernetics-A, ACM Computing Surveys, and Information SystemsResearch, and conferences such as the International Conference onInformation Systems, the IEEE Service-Oriented Computing Confer-ence, and the International Conference on Conceptual Modeling. Heserves as an associate editor for MIS Quarterly and is on the editorialboards of the Journal of the AIS and the Journal of DatabaseManagement-Milwaukee. He is a member of the AIS, the ACM, theIEEE, and the IEEE Computer Society.


http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com

http

://www.ie

eexp

lorep

rojec

ts.blo

gspo

t.com


Monitoring service systems from

Education

service monitoring

service interaction

terms of service policies

large software systems

multilevel monitoring

event acquisition

event source

event analysis