IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

Monitoring Service Systems from a Language-Action Perspective

William N. Robinson, Member, IEEE, and Sandeep Purao, Member, IEEE
AbstractBusiness 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 TermsMonitoring, services, processes, language action, speech acts.

1 INTRODUCTION
HE

exponential growth in the global economy is being supported by service systems, realized with by recasting mission-critical applications as services accessed across organizational boundaries. Service-oriented architectures and associated interoperability standards [1], [2] provide key enablers for these service systems. Their actual building and deployment, however, continues to be fraught with problems: most of our large software systems ... are now constructed as groups of interoperating systems (as systems of systems) ... made to interoperate through various forms of interfaces. Although we can conceive these large [service systems], we have trouble building them [3]. Anecdotal accounts of systems integration efforts (e.g., [4], [5], [6], [7]) point to failures and underscore the need to address the underlying cause: rapidly changing environmental forces. These changes challenge assumptions, such as stability and predictability, where well-specified business processes (with services to perform tasks) are identified in advance and are insulated from change. Instead, the open and distributed processes include tasks that are performed by services that are not centrally controlled, and hence, can be unpredictable. As a result, service outcomes themselves tend to be uncertain. Service monitoring, therefore, remains a significant challenge. The goal of this research is to develop a framework for monitoring such service systems. This paper presents the framework, establishes its feasibility, and evaluates it with scenarios and comparisons against existing proposals.

. W.N. Robinson is with the Computer Information Systems Department, RCB, 35 Broad St, Suite 927, Georgia State University, Atlanta, GA 30302-4015. E-mail: wrobinson@gsu.edu. . 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: spurao@ist.psu.edu. 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: tsc@computer.org, and reference IEEECS Log Number TSCSI-2009-05-0134. Digital Object Identifier no. 10.1109/TSC.2010.41.
1939-1374/10/$26.00 2010 IEEE

1.1 Monitoring Software Systems Monitoring software systems is closely tied to the monitoring of requirements and how they are realized in software. A monitor is a software system that observes and analyzes the behavior of another (target) system, determining qualities of interest, such as the satisfaction of the target systems requirements [8]. A requirements monitor determines the requirements status from a stream of significant input events [9]. A monitor is, then, a function that processes its input event stream to derive the status of requirements. This characterization of monitors and monitoring assumes an event, that is, a significant action in time, typically modeled as instantaneous state change, e.g., completion of a method call, a CPU reaching 90 percent utilization, a shipment arriving at a destination, or a person leaving their home [8]. An event source presents a stream of 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 service systems, asks: how can one use service interaction events to understand a service system in terms of service policies? It represents an instantiation of the more general question: how can one use lower level runtime events to understand a system in terms of higher level requirements? This bridging is facilitated by multiple abstraction layers (see Fig. 1). The lowest layer captures message exchanges with protocols such as SOAP or REST. They represent runtime events that comply with a specification, e.g., the Secure Electronic Transactions protocol. The middle layers capture event sequences following interaction policies, e.g., a buyer must provide payment for services. The highest level, then, represents the monitor, which reports on the state of specified policies, e.g., 95 percent of agents comply with the service interaction policies. The selected ontologies and analysis techniques affect the monitors ability to provide feedback. Together, these layers provide the potential for effective monitoring. The key contribution of this paper is the introduction of an ontology of communicative acts into these abstraction layers
Published by the IEEE Computer Society

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

TABLE 1 Layered View of Web Service Standards [18]

Fig. 1. Abstraction layers for monitoring service systems.

to enhance policy specification and monitoring of service systems. We develop this contribution as an extension to prior work in monitoring, establish its feasibility, and demonstrate it with multiple scenarios.

1.2 Service System Enablers Service systems build upon the basic idea of software as a service [10], [11] that allows legacy and new applications to declare their capabilities in a machine-readable format [12]. Once deployed, the services can be linked to support crossfunctional business processes. Core standards for publishing (WSDL 2001), finding (UDDI 2005), and binding (SOAP 2003) 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 a speech act. It conceptualizes an utterance as the performance of a purposeful act. Several frameworks have been developed for LAP, such as business model patterns [16] and an aggregative model [17]. Umapathy and Purao [18] synthesize these into a framework for the web services standards space with three layers: a communication platform, the communicative act itself, and the rational discourse. Table 1 maps the web service standardization initiatives against this framework. The table highlights a key sublayer not effectively addressed by existing standards: support for conversations between services, which can provide a loosely coupled, peer-to-peer interaction model. Formalizing and representing such conversations among web services is central to understanding how monitors may be designed for services and business processes in distributed, open environments. 1.3 Conversations among Web Services Current models for interactions among web services use a vending machine metaphor. WSDL port types and operations resemble buttons, levers, and slots on a vending machine [18]. The WSDL does not reveal that one must deposit money in the slot before pushing any buttons. Web Service choreography languages [19] attempt to solve this by giving instructions on which buttons to push in what order. An alternative model is that of a telephone call, where two (or more) parties set up a session, exchange messages in that context, and then, finally, close it. Each message is interpreted in relation to those previously exchanged. A

conversation, thus, describes multistep exchanges of messages performed by participants. A prerequisite for this model, in the context of service systems, is a conversation policy [20], [21] that allows each party to maintain its own record of the conversations state. Realizing a conversation model, then, requires specification of conversation policies and the ability to transform these policies into messages that can facilitate the actual conversation. The conversations themselves are comparable to discourses, whose elemental units include clauses and discourse operators, i.e., communicative acts [22]. Other efforts related to this view of conversations include agent communications [23] (often restricted in scale), conversation structures [24] (that ignores the semantic content), and service interaction and enterprise integration patterns [25] (that focus on an operational perspective, relegating message exchanges to a secondary role). Our use of communicative acts is different. We focus on their use for monitoring. The conversation models we envision, therefore, include communicative acts, which result in standard as well as extended effects, i.e., operations on commitments and expectations of responses. Fig. 2 shows an example of a loan approval process that uses the services: Customer, LoanApprover, and LoanProcessor. The process begins with the Customer sending the loan request. The LoanApprover receives the request and invokes the LoanProcessor to process the application. The LoanProcessor sends approval information to the LoanApprover, who forward it to the Customer. The tasks in the process are achieved via two conversations between services: 1) Customer-LoanApprover, and 2) LoanApprover-LoanProcessor. Specific communicative acts may be specified for each conversation, e.g., the task check credit may require: 1) asking for credit information about a customer; 2) responding in the form of prepackaged information or refusing to send the answer; and 3) acknowledging receipt of the answer. The figure highlights three important points. First, processes can be modeled as a composition of conversations; second, conversations protocols can be specified for services; and third, conversations provide the possibility for monitoring at different levels of granularity and temporality. The next section elaborates these ideas further.

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

Fig. 3. A purchasing process (from [28]). Fig. 2. Service, conversations, and processes.

BACKGROUND

2.1 Service Interaction Protocols The idea of conversations has been explored in the form of service 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 communicative acts has, however, not been explicit. Further, the multilevel frameworks suggested by language action theorists [16], [17] have not been used in this context other than the possibility suggested by Moore [29], and the exploration by Umapathy and Purao [18]. Our definition of service interaction protocols, therefore, builds on that offered by [30]: An interaction protocol is defined as the rules of engagement among interacting participants. It includes the possible set of actions that each may perform, and the order in which these must be performed. Concerns that need resolution for the design of interaction protocols, therefore, include: 1) specificity; 2) semantic content; and 3) composability. The first concern deals with specificity-abstraction dimension. For example, an abstract specification may represent interactions among services (e.g., racing condition [31]) that is domain-independent. On the other hand, a specific protocol, e.g., for shipment, may be domain-dependent. The second concern is semantic content, i.e., the nature of the interactions. For example, a protocol specification may use just the request-reply mechanism, relying on message content (e.g., destination, payment info) to capture content. On the other hand, the message itself may capture the semantics to distinguish actions, such as direct, inform, cancel, and others. Finally, composability [31] is concerned

with how a designer might specify the process by combining protocols [32]. To illustrate protocol specification, we draw on a common business process for purchasing, drawn from the Secure Electronic Transactions (SET) standard [33], originally described by Desai et al. [28]. Four main roles collaborate to carry out this process: the Customer, who wants to purchase items, the Merchant, who sells items, the Shipper, who transports the physical items to the Customer, and 4. the Payment Gateway, who authorizes payments. Fig. 3 (adapted from [28]) illustrates how the four agents collaborate, denoted as circles. The rectangles at the roles edge denote data transferred via labeled service messages. The numbers indicate typical sequencing. The ordering on multiple outward edges from a process (e.g., Merchant: task 9) is nondeterministicthe implementation can choose any ordering, including concurrent. Execution of the purchase process requires interaction protocols, which may be specified with message sequence diagrams (see Fig. 4). They describe how each message (communicative act) results in commitments (CC), which are described in the next section. Each sequence specifies a protocol (e.g., Payment, Shipment, and Order). A designer can compose these to design an operational system: 1. 2. 3. Shipping protocol  Payment protocol protocol  Purchase process


Order

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

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

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 polices 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 commitmentbased Payment protocol policy may be: after Payer commits to Order, Payer pays for Order (thereby, discharging the commitment). A commitment captures a contractual relationship 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 to agent 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 commitment 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 example, 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: Commitments are associated with protocol specifications. 2. Commitment ordering is not directly specified. For example, the commitment on the quote operation simply indicates that the buyer and seller are mutually committed based on two dependent conditions (pay and deliver). 3. Commitments are referenced only via the concrete operation 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.

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

supporting specification abstractions over agents and their operations, 2. supporting a mapping function from operations to commitments, thereby decoupling the two, 3. supporting reasoning at runtime, and 4. 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. 1.

2.3 The Language-Action Approach The Language-Action Perspective provides the opportunity 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 processes 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

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

portion of a communicative act, and can, therefore, be identified without knowing the content of the message (i.e., the message type is sufficient). For example, an agent that sends a message of type acceptQuote has the effect of committing the agent to a contract. Extended effects occur as a result of the perlocutionary portionthey represent changes in the receivers beliefs and goals, which is important for analyzing commitments. For example, when an agents last commitment causes its obligated effort to reach a threshold, then the agent shall change its state to that of accepting no further requests (i.e., the agent is over committed). The layered views suggested by language action theorists [16], [17] provide a way to consider these extended effects. The ideas presented by Desai et al. provide only partial recognition of these effects. Neither does it use these effects for the purpose of monitoring. We intend to specifically address extended effects, explicitly representing and updating each agents commitments. To the best of our knowledge, there are no frameworks that utilize such an approach for monitoring service systems. The framework we develop next undertakes this challenge.

uses all the core components of REQMON, but the objects manipulated are those specific to the SERMON design. We elaborate the LAP-specific concepts next.

SERMON: A MONITORING FRAMEWORK FOR SERVICE SYSTEMS

3.1 Methodology and Architecture The SERMON methodology uses a tailored approach for specifying service interaction goals that builds on the underlying GORE model. These include: 1) agent service goals and 2) agent protocol goals. Agent service goals describe desired characteristics of an agents behavior during the execution of a protocol, for example, provide timely response to a request. Agent protocol goals describe desired characteristics of an agents behavior as it manages multiple protocols simultaneously, for example, abandon a protocol execution that may not result in a commitment. Based on the goal model, monitors are compiled and the monitoring system is deployed. Once deployed, the monitor updates the runtime status of the goals as the target software system executes. As events arrive, they are stored in the repository, which is analyzed for goal satisfaction. The results may be presented on a dashboard or they may guide active responses, such as selecting alternative services. The SERMON repository stores event data as well as analysis results. It consists of four layers.
Level 0 (events): The lowest layer stores raw data such as, agent x receives message m from agent y. . Level 1 (ontology): The next layer stores an interpretation of the event data using terms from a selected ontology. Herein, a communicative act ontology is used for record events such as agent x commits to do z for agent y. . Level 2 (properties): Properties of level 1 events are stored at layer 2, for example, the property agent x never violates a commitment is true. . Level 3 (metaproperties): Properties about properties are stored at layer 3, for example, property p1 has a 75 percent success to failure ratio over the last 72 hours. Layers 1, 2, and 3 correspond to the instance, domain, and meta layers of the KAOS model [41]; layer 0 is like a physical data layer and is not considered in KAOS model. The SERMON framework, thus, 1) treats services as units that require monitoring, and 2) treats communicative acts performed by services (as part of conversations), as operations on commitments. SERMON does not presume a global view of the overall process. Instead, it monitors behaviors of individual services as they participate in conversations with other services. .

We follow the design science approach [35] to develop the SERMON framework. It embodies our theory of a LanguageAction-based approach to monitoring service systems. A key element of our research is our ontology of communicative acts (CACTS) and its use for multilevel monitoring of service systems. We hypothesize that our LAP-based service system ontology is sufficient for specifying and monitoring service-related commitments of business protocol policies. The CACTS ontology is derived from our work [18] and others [28], who have previously shown the value of formal constructs for protocol policies. Our research evaluation is focused on the sufficiency and utility of CACTS. We apply the Hevner et al. [35] descriptive approach to design science evaluationillustrative scenarios and argumentation. Additionally, we present some performance measures and anecdotes of usage. Thus, we present our design science activities that are essential to realize the CACTS ontology, and evaluate it for specification and monitoring. The SERMON framework extends a requirements monitoring framework REQMON, which supports 1) goal specification; 2) monitor compilation (from goals); and 3) runtime goal evaluation of a software system [36], [37]. REQMON supports GORE (i.e., Goal-oriented requirements engineering) [38] with three phases: 1) identifying goals; 2) refining and formalizing goals; and 3) deriving and assigning operations to agents [39]. It uses goal modeling, which an analyst can refine to derive operational descriptions including pre- and postconditions [40]. REQMON follows a model-driven architecture (MDA). It relies on the Eclipse Modeling Framework (EMF) for its metamodel and the OSGi specifications, which specify Java-managed components. REQMON is implemented with Eclipse (metamodel and user interface tools) and Equinox (component server). SERMON extends REQMON by specifying LAP-oriented types (in EMF) and specifications (in a variant of the Object Constraint Language). Thus, SERMON

3.2 Communicative Acts The SERMON framework relies on a parsimonious set of Communicative Acts based on the approach and outcomes outlined in Umapathy and Purao [42] that subsumes the 23 acts suggested by Moore [43], and 12 acts suggested by Johannesson and Perjons [44]. Their redefinition, elimination, and mapping of these results in nine Communicative Acts, (see [42]) that we use; see Table 2. 3.3 Specification Language Protocol specifications and their associated commitments can be considered from two perspectives:

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

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. OCL uses Flake temporal message semantics [47]. Both sentMessages and receivedMessages return a Sequence of OclMessage objects, and sentMessage and receivedMessage returns the last, most recent message in the sequence. OCL also includes temporal patterns [48] and timeouts; and linear temporal logic operators [41], [49] as shown next (keywords in bold):  (the next state) some time in the future, eventually) t u (always in the future) W (always in the future unless) . (the prior state) ^ (some time in the past, previously) (always in the past, constantly) U (always in the future until)

Specifying with Desais commitment logic and reasoning at design time with the -calculus. 2. Specifying with OCL and reasoning at design-time with LTL (cf., [45]) and runtime with the SERMON analysis tools, which compare the running processes with their specified properties. There is a natural translation from Desais 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], OCL (OCL with Temporal Message logic). The OCL is similar to first-order predicate calculus in that it allows specification of Boolean expressions with logical connectives, with universal and existential quantifiers. For example, one can specify that all employees of a company must be less than 65 years old: 1. 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.

With these, one can express eventually class object obj will receive message msg as follows: context Class inv: msgArrives: eventually(receivedMessage(msg())) The Flake temporal message semantics rely on an event history, which is accessed via the Flake operations defined on OclAny. All sent messages can be accessed as follows: OclAny->allInstances()>forAll (i: OclMessage j i.sentMessages())>collect() Protocol policies are expressed as goals OCL. Fig. 5 illustrates 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 context including classes and operations. The language allows class inheritance, which can be exploited to simplify specification by abstracting goals, agents, and operations. For example, Child and its superclass Parent, can both have associated goals. Here, the Child is associated with both goals goalA and goalB.

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

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

3.4 Interpreting Events as Communicative Acts To relate the theory of LAP-based analysis with an actual running software system, it is important to specify how real-world events are characterized as LAP concepts. For S ERMON, events are stored into the repository (see Section 3.1) as the software system executes at runtime. They are interpreted using the communicative acts (CACTS) ontology (see Table 2). The SERMON framework relies on event adaptors in REQMON. An event is typically created by a logging program. SERMON listens to these log streams. As an event arrives, a chain of event adaptors transform the event, as desired. For example, a common event transformation is:
Log4jEvent ! CommonBaseEvent ! OclMessage The final object is stored into the repository. In the preceding, the object is stored as an OclMessage object. The SERMON framework uses a mapping within the TransformEventAdaptor to map the incoming events to communicative acts (cacts). As events are received by SERMON, the TransformEventAdaptor transforms the received event according to a specified mapping. Based on the preceding, the event of an object receiving a quote request is represented as a Propose event, which is a subclass of CommunicativeAct, which, in turn, is a subclass OclMessage. Thus, the preceding event transformation becomes the following sequence when the SERMON TransformEventAdaptor is applied: Log4jEvent ! CommonBaseEvent ! CommunicativeAct The preceding illustrates a simple mapping, from a method name to a communicative act. However, one can define a mapping that considers the method name, associated sender and receiver, and other contextual information. In such cases, a developer can write additional code or a rule-base system to characterize a received event according to an ontology. Fig. 6 illustrates the communicative acts defined in Table 2. The root of the hierarchy is CommunicativeAct. Its two subclasses, Request and Response, partition the remaining acts. By being a subclass of OclMessage, CommunicativeAct, and its subclasses use the OCL ontology. It also includes some user-defined methods. For example, the correspondsTo method returns true when the two messages take part in a request-response dialog. The tactic of mapping events to communicative acts differs from the Desai et al. approach, which directly associates commitments with operations [28]. In SERMON, policies can be specified in terms of with abstract events, such as those defined in the CACTS (see Fig. 6). The event mapping decouples the specification from the implementation. As new service operations are implemented, only their

Fig. 6. Communicative acts as an EMF model.

CACTS mapping is needed, because the policies remain associated with the abstract CACTS operations. Section 4 illustrates such 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 interpret the event stream. The monitor acquires events from the instrumented program. As events arrive, rules evaluate the property evaluation trees. For example, for the leaf node eventually m1, the rules left-hand side (LHS) matches a repository assertion representing a received message1; other LHS expressions may further constrain the evaluation. As nodes are satisfied, their values are propagated up the tree, until finally, the entire prop expression is evaluated.

SCENARIO-BASED EVALUATION

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

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

for multilevel monitoring of service systems. Here, we illustrate frameworks implementation and application to the purchase process example (see Fig. 3). We hypothesized that the CACTS ontology is sufficient for specifying and monitoring service-related commitments. To evaluate sufficiency of expression, we created over 50 specification expressions derived from policy specifications found in the related literature (summarized in Section 5.3); in particular, Dwyer reviewed 555 specifications, 92 percent of which match the temporal patterns that are part of OCL [36], [48]. Next, we specified business protocol policies, derived from the literature, using CACTS. Finally, we created and ran programs that satisfied and violated the policies. The success of specifying and monitoring many polices from the literature suggests that the CACTS ontology is indeed sufficient for specifying and monitoring service-related commitments. The next two sections illustrate some specifications from our literature-based collection of test scenarios, using the context of the purchase process example (see Fig. 3). The scenarios are intended to: 1) establish the feasibility of the framework and 2) demonstrate expressiveness of CACTS. Together, these techniques provide an evaluation of the SERMON framework following an approached recommended by Hevner et al. [35].

Formula 1 represents the standard effects of LAPone message type (Query) shall be followed by another message type (Propose). Not all formulae, however, need be specified in this manner. We may also specify the extended effects, which describes changes in the commitment state of the receiver [28]; later, Formula 6 illustrates an extended effects specification. Formula 2 is similar to Formula 1. However, it introduces a timeout that the response must meet. Additionally, it interprets the two messages as abstract types (Request and Response, respectively). This formula acknowledges the existence of a commitment over a time period. Formula 2. Timely response expressed with timeout.

4.1 Scenarios Demonstrating Agent Service Goals Agent service goals describe desired characteristics of an agents behavior during protocol execution (see Section 3.1). Many agents share common goals, such as be responsive. The purchase process example illustrates such common goals. The following formulas illustrate common goals. In the 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 receive quote after query, shown in Formula 1. The first two agent definitions designate the receipt of a Query message with method name requestForQuote and a Propose message with method name quote, by an agent. The quoted invariant constrains how these messages can be related. It states that after the query is received, then eventually, a corresponding proposal shall be received. (The temporal patterns accept a Boolean argument; thus, the idiom eventually(query<>null) is used to check existence.) Placing this invariant on the Agent class, rather than its subclasses (e.g., Buyer and Seller), simplifies the expression. Formula 1 states that, no matter which agent is involved, an agents Query shall be followed by a corresponding Propose. Formula 1. Must respond to a Query with a Propose.

Formula 3 provides another variation. Here, a message queue query limits the kinds of messages selected to be compatible with Request and Response types. Formula 3. Timely response expressed with queue query.

As a final variation, we present Formula 4. It does not reference the method name. Instead, it characterizes the messages as being compatible with Commit and Fulfill types. Thus, property expressions can rely on agent and message type hierarchies, as well as common database expressions over their properties. Formula 4. Timely response expressed with message type.

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

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

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

Formula 8. A constraint between an Agents resources and responses limits committed resources.

The preceding demonstrates concise constraints over agent and message abstractions, important for expressing protocol goals. The customer, merchant, and payment gateway are all subclasses of agent. Thus, each inherits analysis of the superclass Agent properties. Of course, the agent subclasses can add more specialized goals. Overriding (or hiding) properties is unnecessary for monitored properties. The monitor simply reports on the satisfaction of properties. It is possible to specify inconsistent properties as well because the monitor does not enforce these constraints.

4.2 Scenarios Demonstrating Agent Protocol Goals The formulas so far demonstrate goals associated with twoagent dialogs. Next, we demonstrate protocol shared goals of the purchase process agents. The properties specify how an agent can participate in multiple conversations. Formula 6 limits unfulfilled commitments. If placed in the Agent, it is only satisfied when the number of all committedbut-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 a commitment, while limiting the effort to which an agent may commit. Formula 6. Limit unfulfilled commitments.

A variety of protocol policies can be specified in this manner. These policies seamlessly integrate standard and extended effects over agent and operation-type hierarchies. As further illustration, consider the following (informally specified) policies, each in effect, representing an aggregation of extended effects, which contribute to the state of an agent. If the agents commitment level is higher than a threshold, then do not start new conversations. If the agents commitment level is approaching a threshold, then complete high-value conversations. If the agents commitment-level is approaching a threshold, complete conversations with high-value customers. Increase priorities of conversations that require an action of Commit as opposed to those requiring other actions, such as 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) and timelyResponse (Formula 2) in the Order protocol of Fig. 4, we followed these activities:
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. 3. The SERMON server was started, with the Order polices 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 and updates property evaluations. Primitive (nested) properties are evaluated first, and their values are propagated for composite properties. The subscenario between the Buyer and Seller in the purchasing process (from Section 2) is initiated as a thread. The resulting property evaluation uses Agent goals quoted (Formula 1) and timelyResponse (Formula 2). The monitor input data consists of two significant events in sequence. The first input event occurs when the Buyer object sends a request for quote, which is interpreted both as a Query communicative act and as a Request. The monitor processes the 1.

Formula 7. illustrates a protocol transition property. Eventually, after a commitment, the commitment must be fulfilled or canceled. This is an LAP extended effect policy about agent commitments. Formula 7. Property specifies transition to a final state.

Formula 8 specifies that an agent must consider the remaining resources and required resources before responding to a request. This is another extended effect policy, which specifies the internal workings of an agent. In particular, the resources required of a new request shall not exceed the remaining resources. The resource methods have default definitions on the Agent class, but its subclasses can override the method. Again, such methods are part of the specification of the ontology (see Section 3.2).

10

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

event, asserting that the first eventually subproperties of quoted (Formula 1) and timelyResponse (Formula 2) are true. Thus, all invariants are processes simultaneously, and the same event can be interpreted in multiple ways; here, as a Query in Formula 1 and as its superclass Request in Formula 2. For each formula, this propagates the state of their scopes after to be open. The second eventually subproperty of quoted (Formula 1) and timelyResponse (Formula 2) becomes true with the assertion of the quote from the Seller. These values propagate to each property. Formula 9. SERMON output as Proof-of-Concept.

pairs were continuously sent to the server 10,000 times. In the experiment, the event generator and REQMON ran in the same multithreaded process. The test ran as a JUnit test case within Eclipse on a Windows Server 2003 dual core 2.8 GHz with 1 G memory. The results suggest that, within the test configuration, sequential properties (of length 2) are processed at 137 event pairs per second [51]. This indicates that REQMON is reasonably efficient for many monitoring problems.

Note: Properties quoted and timelyResponse. SA means scope activation, p@ is a property prefix, and s@ is a scope prefix. The brackets [] include object references. The first scope activation SA@db4fa2 is the global scope. All service and protocol goals are monitored with this approach. Thus, as the service system executes, SERMON provides notification as each goal is satisfied or violated. Therefore, business analysts can understand the current state of their systems in terms of high-level service and protocol goals. Through such analysis, SERMON provides notification of policy compliance (or violation) for service systems.

4.4 Monitor Performance Monitoring has little impact on the target system, mostly because the target system and monitor typically run on separate computers. The TPTP Probekit provides optimized byte-code instrumentation, which adds little overhead to some (selected) method calls in the target system. The logging of significant events consumes no more than 5 percent, and typically less than 1 percent overhead. For real-time monitoring, it is important to determine if the target events can overwhelm the monitoring system. A performance analysis of REQMON was conducted by comparing the total monitoring runtime versus without monitoring using 40 combinations of the Dwyer temporal patterns [48]. (This is pertinent because SERMON executes the same LTL property monitoring algorithm, but with different objects (see Section 3)the monitoring primitive constructs are the same, and thus, the performance is essentially the same.) For data, a simple two-event sequence was the basis of the test datum; for context, consider the events as an arriving email and its subsequent reply. These

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 our 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 Dwyer et al. [48], which has also been our experience for the emailing domain [51], and now for the service-policy domain. Moreover, the CACTS DSL simplifies the expression of common communication patterns in service policies. It was relatively simple to specify, for example, after an agent commits to an action type, that agent shall fulfill that action within a specified periodsee Section 4.1. CACTS simplifies such expressions by providing commitment logic over class hierarchies with temporal and real-time constraints. As further validation, we reviewed property expressions from related monitoring systems (see Section 5.2) and found that they all can be represented in SERMON. Our success, however, does not suggest that all the properties kinds for the service-system domain can be represented only that we found it reasonable for many common service policies. Finally, our findings may not generalize to other monitoring projects. Nevertheless, given the service system property complexity, it does suggest that this approach may be utilized in a variety of application domains.

DISCUSSION

Our approach for specifying and monitoring participant actions and their effects on commitments extends and augments recent work that has begun to recognize the increasingly distributed nature of business processes in open environments. To overcome the shortcomings of centralized business-process specifications, we reconceptualize business process specifications in terms of conversations among participants. These conversations contain communicative acts, which result in manipulation of commitments. Here, we compare our work with other research efforts.

5.1 Interaction Protocols in Service Systems Barros et al. [27], Decker et al. [26], and more recently, Desai et. al. [28] have argued that interactions among services constitute an important design element. Barros et al. [27] along with Decker et al. [26] propose a number of

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

11

archetypal interactions among services, and formalize these with Pi-calculus. The dimensions they consider include number of participants, exchanges, and routing of messages; but stops short of adding semantics to the messages. Another early effort is Moore [29], who envisions a system of conversations (with Bach and Harnishs [52] set of communicative acts) as a reactive system, modeled with state transition nets. His work represents a departure from the ideas of Barros et al. because it attempts to add semantics to messages. He outlines the possibility of considering conversations as a central abstraction. Umapathy and Purao [18], [42] build on this work, suggesting that interactions among web services may allow us to bridge the gap between design knowledge and executable specifications [25]. Maximilien and Singh [53] explore possibilities for modeling and execution of service systems as a set of interactions in the context of multiagent systems. These include process adaptations [54], specifying preferences [55], and deviations to protocols [56]. Desai et. al. [57] describe an approach that builds on the establishment and discharge of commitments. They do not, however, explore the possibilities for monitoring suggested by message sequences and aggregating extended effects. The database and software engineering researchers address 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 preand postconditions to specify process deviations. Lazovik et al. [60] suggest a service request language, building on prior work in a service assertion language [61]. Pistore et al. [62] suggest protocol combinations to monitor web service compositions. Xu and Jeusfeld [63] describe an approach for monitoring contracts. Taken together, these efforts provide a first step toward monitoring but do not suggest a comprehensive, multilevel framework for monitoring. Our work draws on and extends these efforts, and ensures integration with practice with the help of OCL. The framework we outline is also independent of SOAP versus REST styles [64]. The intention to treat a message as a specific communicative act resides in the sender (as an illocutionary act, and is communicated to the receiver along with the content). The consequences of the communicative act are witnessed as an extended effect on the receiver. The packaging of the communicative act (as SOAP- or a REST-) does not affect viability of the SERMON framework.

general architecture for creation and monitoring of web service agreements [76]. Our work extends this stream. It is focused on meeting monitoring needs via an independent monitor and an expressive language: that allows domain-specific extensions from standard OCL and user-defined library extensions; 2. that supports property inheritance with expressions based on standard OCL and associated UML; 3. that extends OCL with relational, temporal, and realtime expressions; and 4. that supports metarequirements with properties as UML classes, directly manipulated as first-class constructs. The examples of Section 4 illustrate how OCL supports these expressions. As an illustration of a metaproperty, consider the following expression: Formula 10. Agent meta property. 1.

The property mostlySatisfied references the timelyResponse (defined in Section 4.1). In OCL, invariants are (implicitly) subclasses of the UML class RM::Property. Therefore, properties and their instances can be referenced using standard OCL constructs. Thus, mostlySatisfied is satisfied when the ratio of satisfied to total timelyResponse evaluations is greater than 75 percent. Of course, mostlySatisfied is itself a property, and thus, can also be analyzed. Our work also seeks monitor independence. Thus, the monitoring system is defined independent of any particular 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.2 Monitoring Service Systems Our approach may also be compared with prior research in monitoring ([65], [66], [67], [68], [69]). Baresi et al. suggest an assertion annotation approach [70] to monitoring [71], [72] that includes a weaving mechanism to integrate service execution with property monitoring. The monitor they suggest intercepts communications to check properties using the Xpath-like queries. Yan et al. describe how to monitor web services using model-based diagnoses [73]. Researchers at Trento define an algorithmic framework in which a monitor controls an interleaved planner [10], [74] that replans when web service failures are observed. Roth et al. define and implement extensions to BPEL to support monitoring [75]. Ludwig et al. outline a

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.
sendQuote illustrates a message-based property. In this representation, relationships among web services messages are directly specified. 2. quoteCommit illustrates a communicative-actbased property. In this representation, messages are mapped to Communicative Acts, whose relationships are constrained. dischargeCommitments illustrates a commitment-based property. In this representation, commitment operations are specified for communicative acts. Each subsequent representation builds on the prior to advance the kinds of analyses possible. In contrast to 1.

12

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

TABLE 3 Mapping Operations on Commitments [28] against Communicative Acts

TABLE 4 Comparison with Policy Monitoring Systems

SERMON, other monitoring systems are message-based property only. Formula 11. Three kinds of specifications.

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 research on service-policy monitoring. Unlike other projects that are specialized, our work focuses on monitoring a generic service system with the help of language action primitives. Table 4 compares our work against related service-policy monitoring systems with respect to three main characteristics: 1. Ontology: Table 4 shows the most specifications concern web services (in their terms), while fewer consider commitments. SERMON addresses both and the underlying metamodel support additional user-defined terms. Properties: Prior efforts provide logical property descriptions; most characterize these as classes without utilizing inheritance. Fewer include temporal or real-time properties. Only SERMON allows inheritance and metaproperties. 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 extended effects.

2.

3.

More generally, consider the relationship between Communicative Acts to specify message semantics and service commitments. Following Desai et al., commitments capture a variety of contractual relationships, while enabling manipulations, such as delegation and assignment [28]. Manipulations of commitments, thus, represent consequences of message exchanges. Following the language-action perspective we suggest, these operations represent extended effects of communicative acts. For example, a request may not lead to the creation of commitment depending upon the state of the conversation as well as other current commitments for the service. This distinction is analogous to standard effects and extended effects following the language-action perspective, and is important for our approach. Table 3 describes these and

CONCLUSION

We have presented a framework and an approach for multilevel monitoring of service systems. It draws inspiration from the language-action perspective and extends recent work related to commitments. The key contributions, specific to the use of language-action perspective, include the following: Specification of an ontology of communicative acts that adds semantic content to messages. . Support for the specification of policies that address standard and extended effects of communicative effects for multilevel monitoring. In addition, the framework specified supports the following: .

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

13

Support for the specification abstractions over agents and their operations, and decoupling operations from commitments via a mapping specification. . Service system specifications for an arbitrary number of services and processes. . Specification of message semantics. . Specification of local service behaviors that contribute to the participation in multiple conversations. Following the design-science approach [35], the framework embodies 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 of the framework against similar approaches, and how the capabilities of the framework address the needs of multilevel monitoring of service systems. Future work is focused on applying the framework to real-world case studies, and extending the approach to encompass additional levels suggested by LAP frameworks, such as contracts and multiple contracts that require ongoing relationships. For example, the goal hierarchy we have outlined contains two goal categories (agent service and agent protocol goals). We anticipate additional goal categories to account for complex service systems. The framework we have outlined provides an important foundation for these later investigations.

REFERENCES
[1] [2] [3] Gartner-Group, SOBAs Will Revolutionize Application Integration, http://searchwebservices.techtarget.com/originalContent/ 0,289142,sid26_gci965822,00.html, 2002. J. Dang and M.N. Huhns, Coalition Deal Negotiation for Services, Proc. First Intl Workshop Rational, Robust, and Secure Negotiations in Multi-Agent Systems (RRS 05), p. 67, 2005. L. Brownsword et al., System-of-Systems Navigator: An Approach for Managing System-of-Systems Interoperability, Technical Note CMU/SEI-2006-TN-019, http://www.sei.cmu.edu/ publications/documents/06.reports/06tn019.html, Oct. 2006. J. Lee, K. Siau, and S. Hong, Enterprise Integration with ERP and EAI, Comm. ACM, vol. 46, no. 2, pp. 54-60, 2003. D. Robey, D.L. Farrow, C. Franz, and R. Franz, Group Process and Conflict in Systems Development, Management Science, vol. 35, no. 10, pp. 1172-1191, Oct. 1989. C. Brown and I. Vessey, Managing the Next Wave of Enterprise Systems: Leveraging Lessons from ERP, MIS Quarterly Executive, vol. 2, no. 1, pp. 65-77, 2003. M. Hellinger and S. Fingerhut, Business Activity Monitoring: EAI Meets Data Warehousing, Business Integration J., 2002. W.N. Robinson, A Roadmap for Comprehensive Requirements Monitoring, Computer, pp. 64-72, vol. 43, no. 5, May 2010. D.K. Peters and D.L. Parnas, Requirements-Based Monitors for Real-Time Systems, IEEE Trans. Software Eng., vol. 28, no. 2, pp. 146-158, Feb. 2002. A. Lazovik et al., Associating Assertions with Business Processes and Monitoring Their Execution, Proc. Second Intl Conf. Service Oriented Computing, pp. 94-104, 2004. S. Turner et al., Distributed Supply Chain Simulation Using High Level Architecture, Trans. Soc. of Computer Simulation, vol. 18, no. 2, pp. 98-108, 2001. F. Curbera et al., Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI, IEEE Internet Computing, vol. 6, no. 2, pp. 86-93, 2002. J.L. Austin, How to do Things with Words. Oxford, 1962. J. Searle, Speech Acts: An Essay in the Philosophy of Language. Cambridge Univ., 1969. J. Habermas, The Theory of Communicative Action, p. 465. Beacon, 1984.

[4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15]

[16] M. Lind and G. Goldkuhl, Generic Layered Patterns for Business Modelling, Proc. Intl Working Conf. Language-Action Perspective on Comm. Modelling (LAP), 2001. [17] J.L.G. Dietz, The Atoms, Molecules and Matter of Organizations, Proc. Intl Working Conf. Language-Action Perspective on Comm. Modelling (LAP), 2002. [18] K. Umapathy and S. Purao, A Theoretical Investigation of the Emerging Standards for Web Services, Information Systems Frontiers, Special Issue of Information Systems Frontier (ISF) From Web Services to Services Computing: Technologies and Applications, vol. 9, pp. 119-134, 2006. [19] C. Peltz, Web Services OrchestrationA Review of Emerging Technologies, Tools, and Standards, technical paper, Hewlett Packard Labs, 2003. [20] J.E. Hanson et al., Conversation Support for Business Process Integration, Proc. IEEE Intl Enterprise Distributed Object Computing Conf. (EDOC), pp. 65-74, 2002. [21] J.E. Hanson et al., Conversation-Enabled Web Services for Agents and e-Business, Proc. Intl 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 Information Exchange in Agent Teamwork, Artificial Intelligence, vol. 169, pp. 23-97, 2005. [24] P. Stone and M. Veloso, Task Decomposition, Dynamic Role Assignment, and Low-Bandwidth Communication for Real-Time Strategic 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. Fourth Intl Conf. Business Process Management (BPM 06), pp. 414-419, 2006. [27] A. Barros et al., Service Interaction Patterns, Proc. Third Intl Conf. Business Process Management, pp. 302-318, 2005. [28] N. Desai et al., Interaction Protocols as Design Abstractions for Business Processes, IEEE Trans. Software Eng., vol. 31, no. 12, pp. 1015-1027, Dec. 2005. [29] S.A. Moore, On Conversation Policies and the Need for Exception, Proc. Autonomous Agents Special Workshop Conversation Policies, pp. 19-28, 1999. [30] K. Umapathy and S. Purao, Exploring Alternatives for Representing and Accessing Design Knowledge about Enterprise Integration, Proc. 26th Intl Conf. Conceptual Modeling (ER 07), 2007. [31] G. Decker and F. Puhlmann, Formalizing Service Interactions, Proc. Fourth Intl Conf. Business Process Management (BPM 06), 2006. [32] S. Purao et al., Improving Reuse-Based Design: Augmenting Analysis Patterns Reuse with Learning, Information Systems Research, 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. Intl Task Force Meeting Decision Support SystemsIssues and Challenges, vol. 11, pp. 95-118, 1980. [35] A.R. Hevner et al., Decision Science in Information Systems Research, MIS Quarterly, vol. 28, no. 1, p. 75, 2004. [36] W.N. Robinson, Extended OCL for Goal Monitoring, Electronic Comm. EASST, vol. 9, pp. 1-12, 2008. [37] W.N. Robinson, A Requirements Monitoring Framework for Enterprise 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 Intl Requirements Eng. Conf., pp. 4-8, 2004. [39] A. van Lamsweerde et al., Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learned, Proc. IEEE Second Intl Symp. Requirements Eng., pp. 194203, 1995. [40] A. van Lamsweerde, From System Goals to Software Architecture, 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.

14

IEEE TRANSACTIONS ON SERVICES COMPUTING,

VOL. 3,

NO. X,

XXXXXXX 2010

[42] K. Umapathy and S. Purao, Exploring Alternatives for Representing Design Knowledge about Enterprise Integration, Proc. Intl Conf. Conceptual Modeling, 2007. [43] S.A. Moore, A Foundation for Flexible Automated Electronic Communication, Information Systems Research, vol. 12, pp. 34-62, 2001. [44] P. Johannesson and E. Perjons, Design Principles for Process Modelling in Enterprise Application Integration, Information Systems, vol. 26, pp. 165-184, 2001. [45] S. Morimoto, A Survey of Formal Verification for Business Process 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 Object Constraint Language, Proc. 16th Intl Conf. Software Eng. and Knowledge Eng. (SEKE 04), pp. 161-166, 2004. [48] M.B. Dwyer et al., Patterns in Property Specifications for FiniteState Verification, Proc. 21st Intl Conf. Software Eng., pp. 411420, 1999. [49] Z. Manna and A. Prueli, The Temporal Logic of Reactive and Concurrent 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, Design Requirements 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 Speech Acts. MIT, 1979. [53] E.M. Maximilien and M. Singh, Toward Web Services Interaction Styles, Proc. Second IEEE Intl Conf. Services Computing (SCC), 2005. [54] N. Desai et al., Business Process Adaptations via Protocols, Proc. IEEE Intl Conf. Services Computing, pp. 103-110, 2006. [55] A. Mallya and M. Singh, Specifying and Resolving Preferences among Agent Interaction Patterns, Proc. Intl Conf. Autonomous Agents and Multiagent Systems (AAMAS 06), 2006. [56] A. Chopra and M. Singh, Producing Compliant Interactions: Conformance, Coverage, and Interoperability, Proc. Fourth Intl Workshop Declarative Agent Languages and Technologies, pp. 1-15, 2006. [57] N. Desai et al., Engineering Foreign Exchange Processes via Commitment Protocols, Proc. Fourth IEEE Intl Conf. Services Computing (SCC), 2007. [58] L. Baresi et al., Smart Monitors for Composed Services, Proc. Second Intl Conf. Service Oriented Computing, pp. 193-202, 2004. [59] L. Baresi and S. Guinea, Towards Dynamic Monitoring of WSBPEL Processes, Proc. Intl Conf. Service Oriented Computing, pp. 269-282, 2005. [60] A. Lazovik et al., Planning and Monitoring the Execution of Web Service Requests, Intl J. Digital Libraries, vol. 6, pp. 235-246, 2006. [61] A. Lazovik et al., Associating Assertions with Business Processes and Monitoring Their Execution, Proc. Second Intl Conf. Service Oriented Computing, pp. 94-104, 2004. [62] M. Pistore et al., Planning and Monitoring Web Service Composition, Proc. Workshop Planning and Scheduling for Web and Grid Services, 2004. [63] L. Xu and M. Jeusfeld, Pro-Active Monitoring of Electronic Contracts, Proc. Conf. Advanced Information Systems Eng., 2003. [64] M. zur Muehlen et al., Developing Web Services Choreography StandardsThe Case of REST vs. SOAP, Decision Support Systems, vol. 40, no. 1, pp. 9-29, 2005. [65] M.S. Feather et al., Reconciling System Requirements and Runtime Behavior, Proc. Intl Workshop Software Specification and Design (IWSSD 98), 1998. [66] W.N. Robinson, Requirements Monitoring for Enterprise Systems, Requirements Eng. J., vol. 11, no. 1, pp. 17-41, 2006. [67] W.N. Robinson, Monitoring Web Service Requirements, Proc. 11th IEEE Intl Conf. Requirements Eng., pp. 65-74, 2003. [68] W.N. Robinson, Monitoring Software Requirements Using Instrumented Code, Proc. 35th IEEE Ann. Hawaii Intl Conf. Systems Sciences, 2002. [69] W.N. Robinson, Monitoring Software Requirements Using Instrumented Code, Proc. First Symp. Requirements Eng. for Information Security, 2001.

[70] S. Sankar and M. Mandal, Concurrent Runtime Monitoring of Formally Specified Programs. I, Computer, vol. 26, no. 3, pp. 3241, Mar. 1993. [71] L. Baresi and S. Guinea, Towards Dynamic Monitoring of WSBPEL Processes, Proc.Third Intl Conf. Service Oriented Computing, 2005. [72] L. Baresi et al., Smart Monitors for Composed Services, Proc. Second Intl Conf. Service Oriented Computing, pp. 193-202, 2004. [73] Y. Yan et al., Monitoring Web Service Networks in a ModelBased 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 Web Service Requests, J. Digital Libraries, 2005. [75] H. Roth et al., Probing and Monitoring of WSBPEL Processes with Web Services, Proc. Eighth IEEE Intl Conf. E-Commerce Technology, p. 30, 2006. [76] H. Ludwig et al., Crona: An Architecture and Library for Creation and Monitoring of WS-Agreents, Proc. Second Intl Conf. Service Oriented Computing, pp. 65-74, 2004. William N. Robinson is a member of the Computer Information Systems Faculty, Georgia State University, Atlanta. He has served the Requirements Engineering community as secretary of the International Federation for Information Processing Working Group (IFIP) 2.9 on Requirements Engineering, chair of the Requirements Engineering Conference in 1999 and 2009, and editor-in-chief of the Requirements Engineering Journal. His research interests include requirements monitoring and analysis, agent simulation, and supply-chain analysis. He is a member of the IEEE and the IEEE Computer Society. Sandeep Purao received the PhD degree in management information systems from the University of Wisconsin. He is on the faculty at the College of Information Sciences and Technology, Pennsylvania State University, University Park. Prior to joining Penn State, he was on the faculty at Georgia State University. His research interests include the design, evolution, and management of complex techno-organizational systems. His current projects include design knowledge reuse, process automation and monitoring, risk mitigation in large-scale projects, and technology standardization processes. His work has been published in journals such as Communications of the ACM, the IEEE Transactions on Systems, Man and Cybernetics-A, ACM Computing Surveys, and Information Systems Research, and conferences such as the International Conference on Information Systems, the IEEE Service-Oriented Computing Conference, and the International Conference on Conceptual Modeling. He serves as an associate editor for MIS Quarterly and is on the editorial boards of the Journal of the AIS and the Journal of Database Management-Milwaukee. He is a member of the AIS, the ACM, the IEEE, and the IEEE Computer Society.