Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Monitoring service systems from


Published on

Dear Students
Ingenious techno Solution offers an expertise guidance on you Final Year IEEE & Non- IEEE Projects on the following domain
For further details contact us:
044-42046028 or 8428302179.

Ingenious Techno Solution
#241/85, 4th floor
Rangarajapuram main road,
Kodambakkam (Power House)

Published in: Education, Technology, Business
  • Be the first to comment

  • Be the first to like this

Monitoring service systems from

  1. 1. 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 SystemsT HE exponential growth in the global economy is being supported by service systems, realized by recastingmission-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 omorganizational boundaries. Service-oriented architectures A monitor is a software system that “observes and analyzes po t.cand associated interoperability standards [1], [2] provide gs po the behavior of another (target) system, determining lo skey enablers for these service systems. Their actual .b og qualities of interest, such as the satisfaction of the target ts .blbuilding and deployment, however, continues to be fraught system’s requirements” [8]. A requirements monitor deter- ec tswith problems: “most of our large software systems ... are mines the requirements status from a stream of significant oj c pr ojenow constructed as groups of interoperating systems (as input events [9]. A monitor is, then, a function that re r lo repsystems of systems) ... made to interoperate through processes its input event stream to derive the status ofvarious forms of interfaces. Although we can conceive xp lo requirements. This characterization of monitors and mon- ee xpthese large [service systems], we have trouble building itoring assumes an event, that is, “a significant action in .ie eethem” [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 :// wneed 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-worldand 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 servicedistributed processes include tasks that are performed by systems, asks: how can one use service interaction events toservices that are not centrally controlled, and hence, can be understand a service system in terms of service policies? Itunpredictable. 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 aa significant challenge. The goal of this research is to system in terms of higher level requirements? This bridgingdevelop a framework for monitoring such service systems. is facilitated by multiple abstraction layers (see Fig. 1). TheThis paper presents the framework, establishes its feasi- lowest layer captures message exchanges with protocolsbility, and evaluates it with scenarios and comparisons such as SOAP or REST. They represent runtime events thatagainst 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: 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: analysis techniques affect the monitor’s ability to provideManuscript received 15 May 2009; revised 25 Feb. 2010; accepted 4 Apr. feedback. Together, these layers provide the potential for2010; published online 26 Aug. 2010. effective monitoring.For information on obtaining reprints of this article, please send e-mail, and reference IEEECS Log Number TSCSI-2009-05-0134. The key contribution of this paper is the introduction of anDigital 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
  2. 2. 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 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. 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 serviceService systems build upon the basic idea of software as a systems, is a conversation policy [20], [21] that allows eachservice [10], [11] that allows legacy and new applications to t.c om party to maintain its own record of the conversation’s state. omdeclare their capabilities in a machine-readable format [12]. po t.c Realizing a conversation model, then, requires specificationOnce deployed, the services can be linked to support cross- gs po of conversation policies and the ability to transform these lo sfunctional business processes. Core standards for publish- .b og policies into messages that can facilitate the actual con- ts .bling (WSDL 2001), finding (UDDI 2005), and binding (SOAP versation. The conversations themselves are comparable to ec ts2003) 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 repas a theoretical foundation for a layered view [13], [14], [15] efforts related to this view of conversations include agent xp loof these enablers. A building block in this perspective is a communications [23] (often restricted in scale), conversation ee xpspeech act. It conceptualizes an utterance as the performance structures [24] (that ignores the semantic content), and .ie eeof a purposeful act. Several frameworks have been devel- w e service interaction and enterprise integration patterns [25] w .i w woped for LAP, such as business model patterns [16] and an (that focus on an operational perspective, relegating :// w tp //waggregative 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 hspace 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 standardmaps the web service standardization initiatives against as well as extended effects, i.e., operations on commitmentsthis framework. and expectations of responses. The table highlights a key sublayer not effectively Fig. 2 shows an example of a loan approval process thataddressed 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 thepeer-to-peer interaction model. Formalizing and represent- loan request. The LoanApprover receives the request anding such conversations among web services is central to invokes the LoanProcessor to process the application. Theunderstanding 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 forvending 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 refusingdeposit money in the slot before pushing any buttons. Web to send the answer; and 3) acknowledging receipt of theService 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 nextinterpreted in relation to those previously exchanged. A section elaborates these ideas further.
  3. 3. 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 cFig. 2. Service, conversations, and processes. pr oje protocols [32]. re r lo rep2 BACKGROUND To illustrate protocol specification, we draw on a xp lo common business process for purchasing, drawn from the ee xp2.1 Service Interaction Protocols Secure Electronic Transactions (SET) standard [33], origin- .ie eeThe 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 wservice 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, hnicative acts has, however, not been explicit. Further, themultilevel frameworks suggested by language action theor- 3. the Shipper, who transports the physical items to theists [16], [17] have not been used in this context other than the Customer, andpossibility 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 agentstion protocols, therefore, builds on that offered by [30]: An collaborate, denoted as circles. The rectangles at the role’sinteraction 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 onactions 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 choosedesign 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 sequencesion. For example, an abstract specification may represent diagrams (see Fig. 4). They describe how each messageinteractions among services (e.g., racing condition [31]) that (communicative act) results in commitments (CC), whichis domain-independent. On the other hand, a specific are described in the next section. Each sequence specifies aprotocol, e.g., for shipment, may be domain-dependent. protocol (e.g., Payment, Shipment, and Order). A designerThe 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 usejust the request-reply mechanism, relying on message Shipping protocol Payment protocol Ordercontent (e.g., destination, payment info) to capture content. protocol Purchase processOn the other hand, the message itself may capture the A design mapping specifies how the protocols apply tosemantics to distinguish actions, such as direct, inform, the purchasing process. Part of that mapping is presentedcancel, and others. Finally, composability [31] is concerned here (where x/Y means that x is substituted for variable Y):
  4. 4. 20 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011Purchase.Customer/Order.BuyerPurchase.Merchant/Order.SellerPurchase.Customer/Payment.PayerPurchase.Merchant/Payment.PayeePurchase.Payment Gateway/Payment.GatewayShipment.shipmentProp/Order.goods2.2 Protocol Policies and CommitmentsA protocol policy specifies outcomes that satisfy theprotocol goals. For example, a policy for the Paymentprotocol may be: “after Payer sends paymentInfo, eventuallyPayer receives receipt.” Protocol policies can also be specifiedin nonprotocol terms. For example, one can conceptualizeprotocols as manipulation of commitments, e.g., creation,cancelation, fulfillment (discharge), etc. A commitment-based Payment protocol policy may be: “after Payer commitsto Order, Payer pays for Order” (thereby, discharging thecommitment). A commitment captures a contractual rela-tionship that enables “manipulations, such as delegationand assignment, which are essential for open systems” [28]. t.c om om po t.cA commitment C(x; y; p) denotes that agent x is obliged toagent 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 tsas: x is committed to y to bring about q if p holds; and specify oj c pr ojeoperations on commitments such as: create, cancel, release, re r lo repassign, 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 xpwhich states that if the condition p holds, then in the next .ie eestate, agent x is discharged of its commitment C(x; y; p). Their w e w .i w wframework also supports the specification of protocol :// w tp //wassertions. For example, in one scenario of the Order protocol ht ttp:of Fig. 4: reqForQuote(...) } ! quote(...) ^ CC(...)—meaning hthat 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 agentscan 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 tople, 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 andquoting 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 aprotocol 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 CommunicativeWe 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
  5. 5. ROBINSON AND PURAO: MONITORING SERVICE SYSTEMS FROM A LANGUAGE-ACTION PERSPECTIVE 21portion of a communicative act, and can, therefore, be uses all the core components of REQMON, but the objectsidentified 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 Architecturecommitting the agent to a contract. Extended effects occuras a result of the perlocutionary portion—they represent The SERMON methodology uses a tailored approach forchanges in the receiver’s beliefs and goals, which is specifying service interaction goals that builds on the underlying GORE model. These include: 1) agent serviceimportant for analyzing commitments. For example, when goals and 2) agent protocol goals. Agent service goalsan agent’s last commitment causes its obligated effort to describe desired characteristics of an agent’s behaviorreach a threshold, then the agent shall change its state to during the execution of a protocol, for example, “providethat of accepting no further requests (i.e., the agent is over timely response to a request.” Agent protocol goals describecommitted). The layered views suggested by language desired characteristics of an agent’s behavior as it managesaction theorists [16], [17] provide a way to consider these multiple protocols simultaneously, for example, “abandon aextended effects. The ideas presented by Desai et al. protocol execution that may not result in a commitment.” Basedprovide only partial recognition of these effects. Neither on the goal model, monitors are compiled and thedoes it use these effects for the purpose of monitoring. We monitoring system is deployed. Once deployed, the monitorintend to specifically address extended effects, explicitly updates the runtime status of the goals as the targetrepresenting 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, whichutilize such an approach for monitoring service systems. is analyzed for goal satisfaction. The results may beThe 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 analysis3 SERMON: A MONITORING FRAMEWORK FOR t.c om om results. It consists of four layers. SERVICE SYSTEMS po t.cWe follow the design science approach [35] to develop the . gs po Level 0 (events): The lowest layer stores raw data lo s .b ogSERMON framework. It embodies our theory of a Language- such as, “agent x receives message m from agent y.” ts .blAction-based approach to monitoring service systems. A . Level 1 (ontology): The next layer stores an inter- ec ts oj ckey element of our research is our ontology of commu- pretation of the event data using terms from a pr ojenicative acts (CACTS) and its use for multilevel monitoring selected ontology. Herein, a communicative act re r lo repof service systems. We hypothesize that our LAP-based ontology is used for record events such as “agent x xp loservice system ontology is sufficient for specifying and commits to do z for agent y.” ee xp .ie eemonitoring service-related commitments of business proto- . Level 2 (properties): Properties of level 1 events are w ecol 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 //wof 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 hCACTS. 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, andargumentation. Additionally, we present some performance meta layers of the KAOS model [41]; layer 0 is like ameasures and anecdotes of usage. Thus, we present our physical data layer and is not considered in KAOS science activities that are essential to realize the The SERMON framework, thus, 1) treats services as unitsCACTS ontology, and evaluate it for specification and that require monitoring, and 2) treats communicative actsmonitoring. performed by services (as part of conversations), as The SERMON framework extends a requirements mon- operations on commitments. SERMON does not presume aitoring framework REQMON, which supports 1) goal global view of the overall process. Instead, it monitorsspecification; 2) monitor compilation (from goals); and behaviors of individual services as they participate in3) runtime goal evaluation of a software system [36], [37]. conversations with other services.REQMON supports GORE (i.e., Goal-oriented requirementsengineering) [38] with three phases: 1) identifying goals; 3.2 Communicative Acts2) refining and formalizing goals; and 3) deriving and The SERMON framework relies on a parsimonious set ofassigning operations to agents [39]. It uses goal modeling, Communicative Acts based on the approach and outcomeswhich an analyst can refine to derive operational descrip- outlined in Umapathy and Purao [42] that subsumes thetions including pre- and postconditions [40]. REQMONfollows a model-driven architecture (MDA). It relies on the 23 acts suggested by Moore [43], and 12 acts suggested byEclipse 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 Communicativecomponents. 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 Languageponent server). SERMON extends REQMON by specifyingLAP-oriented types (in EMF) and specifications (in a Protocol specifications and their associated commitmentsvariant of the Object Constraint Language). Thus, SERMON can be considered from two perspectives:
  6. 6. 22 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011 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 objour OCL specifications. We generally specify directly in will receive message msg” as follows:OCL rather than translate from Desai specifications, in part, context Classbecause 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 eventruntime, 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 TemporalMessage logic). The OCL is similar to first-order predicate OclAny-allInstances()ÀforAllcalculus 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. 5tial 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 beUML 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 ChildforAll and exists, have their own specific parameters. is associated with both goals goalA and goalB.
  7. 7. ROBINSON AND PURAO: MONITORING SERVICE SYSTEMS FROM A LANGUAGE-ACTION PERSPECTIVE 23context 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 ActsTo 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. ForS ERMON, 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: 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.cThe final object is stored into the repository. In thepreceding, 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 ogThe SERMON framework uses a mapping within the ts .blTransformEventAdaptor to map the incoming events 3.5 Goal Monitor Compilation ec tsto 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 repEventAdaptor transforms the received event according to evaluation tree, where each node is a rule set [50]. Consider xp loa specified mapping. Based on the preceding, the event of an ee xpobject receiving a quote request is represented as a Propose the following simple property as an illustration: .ie eeevent, which is a subclass of CommunicativeAct, which, w e w .i context ContextClasssin turn, is a subclass OclMessage. Thus, the preceding w w :// wevent transformation becomes the following sequence when def: m1 : OclMessage = tp //wthe SERMON TransformEventAdaptor is applied: receivedMessage(message1()) ht ttp: def: m2 : OclMessage = hLog4jEvent ! 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(eventuallyinformation. In such cases, a developer can write additionalcode 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 Interpretationnicative acts defined in Table 2. Finally, at runtime, the compiled property rules interpret The root of the hierarchy is CommunicativeAct. Itstwo subclasses, Request and Response, partition the the event stream. The monitor acquires events fromremaining acts. By being a subclass of OclMessage, the instrumented program. As events arrive, rules evaluateCommunicativeAct, and its subclasses use the OCL the property evaluation trees. For example, for the leaf nodeontology. It also includes some user-defined methods. For eventually m1, the rule’s left-hand side (LHS) matches aexample, 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 thediffers from the Desai et al. approach, which directly tree, until finally, the entire prop expression is 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 mapping 4 SCENARIO-BASED EVALUATIONdecouples the specification from the implementation. As The SERMON framework specifies a novel approach fornew service operations are implemented, only their CACTS monitoring that relies on an ontology of communicative acts
  8. 8. 24 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011for multilevel monitoring of service systems. Here, we Formula 1 represents the standard effects of LAP—oneillustrate an implementation of the framework and applica- message type (Query) shall be followed by anothertion 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 thefor 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 anspecification 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 introducesin particular, Dwyer reviewed 555 specifications, 92 percent a timeout that the response must meet. Additionally, itof which match the temporal patterns that are part of interprets the two messages as abstract types (Request andOCLTM [36], [48]. Next, we specified business protocol Response, respectively). This formula acknowledges thepolicies, 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 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 approached t.c om Formula 3 provides another variation. Here, a message omrecommended by Hevner et al. [35]. po t.c queue query limits the kinds of messages selected to be4.1 Scenarios Demonstrating Agent Service Goals gs po compatible with Request and Response types. lo s .b ogAgent service goals describe desired characteristics of an Formula 3. Timely response expressed with queue query. ts .blagent’s behavior during protocol execution (see Section 3.1). ec ts oj cMany agents share common goals, such as “be responsive.” pr ojeThe purchase process example illustrates such common re r lo repgoals. The following formulas illustrate common goals. In xp lothe formulas, highlighted words are OCL keywords, ee xp .ie eeincluding temporal patterns, such as after, before, w ebetween, response, etc. [48]. w .i w w We begin our scenarios with the agent goal of “receive :// w tp //wquote after query,” shown in Formula 1. The first two agent ht ttp:definitions designate the receipt of a Query message with hmethod name requestForQuote and a Propose messagewith method name quote, by an agent. The quoted As a final variation, we present Formula 4. It does notinvariant constrains how these messages can be related. It reference the method name. Instead, it characterizes thestates that after the query is received, then eventually, a messages as being compatible with Commit and Fulfillcorresponding proposal shall be received. (The temporal types. Thus, property expressions can rely on agent andpatterns accept a Boolean argument; thus, the idiom message type hierarchies, as well as common databaseeventually(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, anagent’s Query shall be followed by a correspondingPropose. 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].
  9. 9. ROBINSON AND PURAO: MONITORING SERVICE SYSTEMS FROM A LANGUAGE-ACTION PERSPECTIVE 25 Formula 5. Provides compensation expressed with a Formula 8. A constraint between an Agent’s resourcescommunicative act (CACTS) operation. and responses limits committed resources. The preceding demonstrates concise constraints overagent and message abstractions, important for expressingprotocol goals. The customer, merchant, and payment A variety of protocol policies can be specified in thisgateway are all subclasses of agent. Thus, each inherits manner. These policies seamlessly integrate standard andanalysis 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 followingriding (or hiding) properties is unnecessary for monitored (informally specified) policies, each in effect, representingproperties. The monitor simply reports on the satisfaction of an aggregation of extended effects, which contribute toproperties. 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 om4.2 Scenarios Demonstrating Agent Protocol Goals If the agent’s commitment level is approaching a thresh- om po t.cThe 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 ogof the purchase process agents. The properties specify how old, complete conversations with high-value customers. ts .blan 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 ojeAgent, it is only satisfied when the number of all committed- as Inform. re r lo repbut-unfulfilled acts is less than Agent.commitLimit 4.3 Scenario Demonstrating Goal Monitoring xp lo(which may have different values for different subclasses). ee xpIn effect, it recognizes the LAP extended effect of creating a The runtime evaluation of goals is illustrated in Formula 9. .ie eecommitment, while limiting the effort to which an agent may Reconsider the purchasing process example of Section 2. w e w .i w wcommit. 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 OrderEventually, 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 ofabout 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 thesponding 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 quotedparticular, the resources required of a new request shall not (Formula 1) and timelyResponse (Formula 2). The monitorexceed the remaining resources. The resource methods have input data consists of two significant events in sequence. Thedefault definitions on the Agent class, but its subclasses can first input event occurs when the Buyer object sends a requestoverride 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
  10. 10. 26 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011event, 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 intrue. Thus, all invariants are processes simultaneously, and the same multithreaded process. The test ran as a JUnit testthe same event can be interpreted in multiple ways; here, as a case within Eclipse on a Windows Server 2003 dual coreQuery in Formula 1 and as its superclass Request in 2.8 GHz with 1 G memory. The results suggest that, withinFormula 2. For each formula, this propagates the state of their the test configuration, sequential properties (of length 2) arescopes after to be open. The second eventually sub- processed at 137 event pairs per second [51]. This indicatesproperty 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 repmeans scope activation, p@ is a property prefix, and s@ is a such expressions by providing commitment logic over class xp loscope prefix. The brackets “[]” include object references. ee xp hierarchies with temporal and real-time constraints. As .ie eeThe 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 wapproach. Thus, as the service system executes, SERMON :// w they all can be represented in SERMON. Our success, tp //wprovides 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 hof 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 monitoringof policy compliance (or violation) for service systems. projects. Nevertheless, given the service system property complexity, it does suggest that this approach may be4.4 Monitor Performance utilized in a variety of application domains.Monitoring has little impact on the target system, mostlybecause the target system and monitor typically run onseparate computers. The TPTP Probekit provides optimized 5 DISCUSSIONbyte-code instrumentation, which adds little overhead to Our approach for specifying and monitoring participantsome (selected) method calls in the target system. The actions and their effects on commitments extends andlogging of significant events consumes no more than augments recent work that has begun to recognize the5 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 centralizedthe target events can overwhelm the monitoring system. A business-process specifications, we reconceptualize businessperformance analysis of REQMON was conducted by process specifications in terms of conversations amongcomparing the total monitoring runtime versus without participants. These conversations contain communicativemonitoring using 40 combinations of the Dwyer temporal acts, which result in manipulation of commitments. Here, wepatterns [48]. (This is pertinent because SERMON executes compare our work with other research efforts.the same LTL property monitoring algorithm, but withdifferent objects (see Section 3)—the monitoring primitive 5.1 Interaction Protocols in Service Systemsconstructs are the same, and thus, the performance is Barros et al. [27], Decker et al. [26], and more recently, Desaiessentially the same.) For data, a simple two-event sequence et. al. [28] have argued that interactions among serviceswas 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
  11. 11. ROBINSON AND PURAO: MONITORING SERVICE SYSTEMS FROM A LANGUAGE-ACTION PERSPECTIVE 27archetypal interactions among services, and formalize these general architecture for creation and monitoring of webwith 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 meetingsages; 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 ofcommunicative 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 expressionssemantics 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; andthat interactions among web services may allow us to 4. that supports metarequirements with properties asbridge 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 supportsmodeling 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 anddischarge of commitments. They do not, however, explorethe possibilities for monitoring suggested by message t.c om omsequences and aggregating extended effects. po t.c The database and software engineering researchers gs poaddress interaction protocols for extending web services. lo s .b ogFor example, Baresi et al. [58] and Baresi and Guinea [59] ts .blsuggest use of a web service constraint language and pre- ec ts oj c The property mostlySatisfied references the pr ojeand postconditions to specify process deviations. Lazovik timelyResponse (defined in Section 4.1). In OCL, re ret al. [60] suggest a service request language, building on lo repprior 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 eecompositions. 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 .imonitoring contracts. Taken together, these efforts provide w w :// wa first step toward monitoring but do not suggest a to total timelyResponse evaluations is greater than tp //wcomprehensive, 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. hensures integration with practice with the help of OCL. The Our work also seeks monitor independence. Thus, theframework 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 canspecific 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 thewith the content). The consequences of the communicative target programs provide events that can be filtered, andact 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 and5.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 monitoring ([65], [66], [67], [68], [69]). Baresi et al.suggest an assertion annotation approach [70] to monitor- 1. sendQuote illustrates a message-based property. Ining [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, messageshow 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 in which a monitor controls an interleaved planner[10], [74] that replans when web service failures are dischargeCommitments illustrates a commitment-basedobserved. Roth et al. define and implement extensions to property. In this representation, commitment operationsBPEL to support monitoring [75]. Ludwig et al. outline a are specified for communicative acts.
  12. 12. 28 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 4, NO. 1, JANUARY-MARCH 2011 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 aadvance the kinds of analyses possible. In contrast to gs po generic service system with the help of language action lo sSERMON, 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 forCommunicative 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 extendscapture 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, includement” [28]. Manipulations of commitments, thus, representconsequences of message exchanges. Following the lan- the following:guage-action perspective we suggest, these operations . Specification of an ontology of communicative actsrepresent 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 addresscommitment depending upon the state of the conversation standard and extended effects of communicativeas 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 theeffects following the language-action perspective, and isimportant for our approach. Table 3 describes these and following: