Development Support for Specifying and Monitoring ...

Development Support for Specifying and Monitoring Goals of Open Business Processes William N. Robinson Center for Process Innovation Department of Computer Information Systems Georgia State University Atlanta, Georgia 30302-4015, USA [email protected]

Sandeep Purao Enterprise Informatics and Integration Center College of Information Sciences and Technology Penn State University, University Park, PA 16802 [email protected]

Business processes are increasingly complex and open because they rely on services that are distributed geographically and across organizations. As a result, they are prone to several points of failure. Monitoring, therefore, remains an important concern. We describe services monitoring support that integrates monitoring into common development activities. A flexible monitoring toolkit, REQM ON, is the basis of the support. SERMON extends REQ M ON to support commitment-based property specification, which simplifies monitoring of open services. We show how to develop and apply such specialized monitoring as part of the best practices of development.

1

Introduction

Recent developments in web services and associated standards offer the possibility of making composite, service-based systems a reality for many enterprises [1]. As a recent SEI report states [2]: “we have crossed a threshold, where most of our large software systems can no longer be constructed as monoliths … They are now constructed as groups of interoperating systems … made to interoperate through various forms of interfaces.” Building and deploying such systems requires proactive behavior monitoring so that the individual services as well as collaborations among groups of services can evolve in response to changes in the environment. In this paper, we describe a monitoring system for service properties, expressed as goals over service protocols. This work extends our prior work by showing how the specification and analysis of such monitored properties integrates within common software development activities. In particular, the approach is 100 percent compatible with the UML and its Object Constraint Language (OCL). In support of the approach, we have extended standard tools (Eclipse, JUnit) and provided adaptors to standard event management frameworks (CBE, log4j, WMI). Consequently, practitioners can download and apply property-based scenario analysis at design-time, test-time, and run-time.

1.1 Service protocol goals Our service protocol research builds on Desai et. al. [3], who argue for process specifications with commitment semantics. Specifying commitments for roles that participate in a business process provides “a basis for modeling the state of the interaction, thus allowing a variety of possible executions” [3]. Specifying constraints over commitments is more flexible than constraints over concrete protocols because important relationships can be specified while deferring operational details. This view is compatible with research on goal-based requirements engineering (GORE) [4]. Goals represent “prescriptive statements of intent whose satisfaction requires the cooperation of agents (or active components) in the software and its environment… [goals range] from high-level, strategic objectives to fine-grained, technical prescriptions that can be assigned as responsibilities of single agents” [4]. Thus, the agents participating in a business process can be conceptualized as having goals. To satisfy these, agents commit to perform activities. Specifying a business process with agent commitments, then, allows partitioning the larger business process into interactions among agents, thereby improving reuse, semantics, and evolvabilty [3]. The objective of this paper is to show how 1

specifying and monitoring these interactions and commitments integrates with common development activities. Our commitment-based monitoring system, called SERMON, extends REQM ON [5], a general purpose requirements monitoring toolkit. We demonstrate how monitoring can track protocol policies. A detailed example, drawn and extended from prior work, provides the basis for demonstrating the specification and monitoring techniques, and for discussing their benefits.

1.2 Requirements monitoring A requirements monitor is a software system that analyzes the behavior of another (target) system and determines the satisfaction of the target system’s requirements from observing a stream of inputs (INmon). A requirements monitor can be characterized as a function that processes its input data stream to derive the status of requirements satisfaction. MON(INmon) → Sat(REQ) In practice, the monitored data stream, INmon, is comprised of complex objects, such as the XML objects produced by log4j or Common Base Event (CBE). Requirements are expressed as specified relationships among objects, over time. A variety of projects support some form of requirements monitoring [6], including those that address some aspect of web service policy monitoring [5, 7-9]. Our work builds on these efforts by providing an expressive monitoring language within a widely used notation—that of the UML and its Object Constraint Language (OCL), extended with temporal logic. By supporting the UML, our monitoring tools can leverage and integrate with existing tools and techniques that are part of software development best practices.

1.3 Common development activities Best practices for requirements analysis and software development include: 1. Specifying use cases 2. Elaborating uses cases with object models (class diagrams) and behavioral models (sequence diagrams) 3. Analyzing uses case through scenario analysis Almost all methodologies, including agile methods, apply steps 1 and 3—all UML methodologies also include step 2. Most practitioners apply steps 1 through 3 for at least some portion of their projects. Scenario analysis often entails mental walkthroughs of the specified use cases. Some practitioners go on to derive unit test cases from their use cases[10]. Most development projects do apply unit test cases—derived from uses cases scenarios or not. Formal properties are largely lacking from commonly applied best practices. However, OCL is gaining popularity. A variety of tools is available for the widely used Eclipse IDE. Consequently, we may see further penetration of OCL usage into common software development. One Eclipse plugin, for example, can generate Java code for checking OCL properties at run-time[11]. It does not address temporal properties or abstract properties, such as the commitment-based logic of Desai et. al. [3].

1.4 Article Outline In this article, we show how requirements monitoring for services can be integrated into best practices of software development. In particular, we show how temporal and commitment-based properties can be specified and analyzed with scenario-analysis techniques at design-time, test-time, and run-time using an extension to the REQMON monitoring system. First, service protocols and their OCL-based polices are presented (§2). Next, support for policy specification (§3.2), and then design-time (§3.4), test-time (§3.5), and run-time (§3.6) analyses are presented, along with some details of the monitoring system implementation(§3.7). Finally, we discuss the utility of this approach to supporting requirements monitoring.

2

Service Interaction Protocols

An interaction protocol may be defined as the ‘rules of engagement’ among interacting participants [12]. It can include rules regarding possible actions that each may perform, and the order in which 2

these actions must be performed. It specifies an operational design for communication among two or more roles. An example is UML message sequence diagrams that define a protocol specification as messages, their parameters and ordering, with references to data types, further described in UML classes. Common message semantics can be enriched with communications semantics. To distinguish among different kinds of utterances (actions), communicative acts can follow classifications that can include direct, inform, cancel, acknowledge and others. Communicative acts, such as those based on participant commitments, can simplify the specification of protocols and enrich their analysis.

2.1 Protocol specification We illustrate protocol specifications, enriched with communicative acts, with a common purchasing process drawn from the Secure Electronic Transactions (SET) standard, originally described by Desai et. al. [3]. Four main roles collaborate to carry out the Purchase Process: (1) the Customer who wants to purchase items, (2) the Merchant who sells items, (3) the Shipper who transports the physical items to the Customer, and (4) the Payment Gateway who authorizes payments. Services fulfill the four roles, engaging in pair-wise conversations within the constraints of the protocol specifications. Consider the conversation between the Merchant and the Payment Gateway. It contains the following sequence of steps (among other step orderings [3]). First, the Merchant may Request an authorization from the Payment Gateway. Second, the Payment Gateway may Respond or Refuse. Third, the Merchant may Request the Payment Gateway to capture the payment. Fourth, the Payment Gateway may Inform the Merchant that the payment has been captured. Although protocols may be identified directly, as concrete operational descriptions (from the SET Purchase Process description), a more useful characterization is that of abstract protocols. An abstract protocol specifies common interactions within a family of protocols. Like an objectoriented class, an abstract protocol may be specialized through refinement. For example, the Customer-Merchant interactions may be considered a specialization of an Order Protocol between Buyer and Seller. The interactions among Customer, Merchant, and PaymentGateway may be considered a specialization of Payment Protocol among a Payer, Payee, and Gateway. Such mapping can effectively lead to multiple inheritance for specific roles; for example, the Customer role may inherit interaction responsibilities as Buyer from the Order Protocol and as Payer from the Payment Protocol. Figure 1 presents a role-based UML message sequence diagrams from the Desai et. al., which specify abstract protocols for the SET Purchase Process.

3

Figure 1 Abstract Protocols.

2.2 Policies and commitments A protocol policy specifies the desired goals and commitments of role-based participants. It may be expressed in terms of protocol messages; for example, consider this Payment protocol goal: ‘after Payer sends paymentInfo, eventually Payer receives receipt’. This goal seeks a certain response relationship among sent and received messages. Commitments provide another means to specify polices. One can conceptualize protocols as fulfilling role commitments; that is, interactions within a protocol may be interpreted as manipulating commitments such as creation, cancelation, or fulfillment (discharge). For example, the Payment protocol may lead to the following commitments: ‘after Payer commits to Order, Payer pays for Order (discharging the commitment).’ Desai et. al. view commitments as “a variety of contractual relationships … [that] enable manipulations such as delegation and assignment, which are essential for open systems”[3]. They define commitment as follows: A commitment C(x, y, p) denotes that agent x is obliged to agent y for bringing about condition p.

They extend the definition to include a conditional commitment: CC(x, y, p, q), which means that x is committed to y to bring about p if q holds. Desai et. al. elaborate operations on commitments that include: create, cancel, release, assign, delegate, and discharge. Their perspective, therefore, requires annotating the protocols of Figure 1 with commitments. For example, the Order protocol shows that the quote message commits the Seller to providing the Buyer goods on the condition that the Buyer pays. Conversely, the Order protocol shows that the acceptQuote message commits the Buyer to 4

paying the Seller on the condition that the Seller delivers the goods. The Order protocol does not specify an ordering on the pay and goods-delivery events—it simply indicates that they are mutually committed based on two dependent conditions (pay and goods), leaving the resolution to the designer or the programmer but ensuring that mutual commitments are satisfied.

3

Supporting Development Activities for Monitoring

Requirements monitoring can be used to analyze service interactions and commitment-based protocol policies. These policies specify desired outcomes based on interactions among software systems (e.g., web services). Seen in this manner, these protocol policies represent software requirements, which can be analyzed at design-, test-, and run-time[5, 6]. Such requirements analyses can be integrated into common development activities, as we show next.

3.1 Requirements monitoring activities Requirements monitoring continually evaluates requirements satisfaction by a target system. Consider the Purchase Process example: the Payee is responsible for the Payment protocol requirement: ‘after Payer sends paymentInfo, eventually Payer receives receipt’. This requirement can be evaluated by a monitor. We may observe that after a single transaction, the requirement is satisfied; after monitoring a number of transactions, we may observe that the requirement is satisfied 90 percent of time. Requirements monitoring, thus, provides a view of how well a target system complies with its stated requirements. SERMON extends REQMON[5] to support the specification and monitoring of protocol policies. SERMON is engaged through the following activities. 1. An Analyst defines protocol policies as goal models, and assigns goals to agents (e.g., web services). For example, our analyst specifies as ppayFine: ‘after an authorization is disallowed, eventually pay a fine’. 2. An Analyst applies tools to analyze, compile, and deploy requirements for the goals: o A complier translates formal goal specifications into rule-based monitors, which evaluate the target system events to determine goal satisfaction. o Deployment includes instrumentation of the software to provide the run-time notification of significant events to the SERMON server. 3. As the protocols are enacted at run-time, the instrumentation sends event notifications to the SERMON server. A translator converts sourced service events into model events; for example, an XML event, from the event-layer, is translated as a UML message in the model. 4. The SERMON server evaluates requirements satisfaction against events and sends updates to subscribers. A ‘requirements dashboard’ allows users to see how well protocol goals are being satisfied in real-time. In analyzing the SET Purchase Process, of Figure 1, our analyst (1) specifies the object model in a class diagram, (2) specifies the protocols in three sequence diagrams, and (3) specifies the protocol goals in the OCL. Our analyst then applies static and dynamic scenarios analysis before monitoring the running system. These activities are described in the next subsections.

3.2 Specifying properties SERM ON properties are specified using OCLTM[13], which is the UML Object Constraint Language with R EQM ON’s extensions for real-time operators and temporal message logic. The OCL is similar to first order predicate calculus. Boolean expressions are specified with logical connectives, which may include universal and existential quantifiers. OCLTM includes operators from linear temporal logic as expressed by the Dwyer patterns. Generalizing from an empirical study [14], Dwyer et. al. define five temporal scopes over eight temporal patterns, and suggest that such distinction between scoping properties from other properties simplifies property specifications. Figure 2 illustrates some of the OCLTM operators, which are defined using the standard OCL library mechanism. The extensions are defined as an Eclipse Modeling Framework model for the IBM 5

Eclipse OCL implementation. Operator syntax is defined with XML; thus, SERM ON’s extension of commitment operators is easily specified. Operator semantics are defined in Java code. Most operators define the Dwyer patterns. The receivedMessages operator returns a Sequence of OclMessage objects, as defined by Flake temporal message semantics [15]. The newPEval operator allows for the direct assertion of property evaluations. In contrast, OCL does not support object manipulations; however, direct property assertion is important at run-time, as the following example will demonstrate.

Figure 2 OCL extensions specified as an EMF model.

As an example, consider the following OCL expression. The invariant, payFine, is defined in the context of the Payer class. It specifies that after an authorization is disallowed, eventually a pay-fine message will be sent in response. context Payee def: sPayFine: OclMessage = sendMesssage('payFine') def: rAuthNOK: OclMessage = receiveMesssage('authNOK') inv: payFine: after(rAuthNOK,eventually(sPayFine and sPayFine.arguments('payee') = rAuthNOK.arguments('payee')))

An OclMessage represents an operation call. Thus, the preceding can be used to interpret a sequence of method calls that include messages to Payee objects.

3.3 Specifying protocol commitments The commitments of the protocol policies specified by Desai et. al. (in Figure 1) associate with messages in role-based sequence diagrams[3]. Each commitment can be translated to an OCLTM invariant on the class receiving (or sending) the message. In general, a protocol commitment policy can be represented as one or more OCLTM invariants over the classes related through the policy. 6

For example, consider the Payer’s OCLTM context, in which the payFine invariant represents the Payer’s commitment in the Payment protocol of Figure 1. CC(payer, payee, authNOKProp(error), payFine(fine))

The first invariant of Figure 3 specifies that after the Payer receives a message indicating that its payment was not properly authorized (authNOK), then the Payer shall pay a fine to the Payee.

Figure 3 Payer and Buyer OCL constraints.

The last two Payer invariants provide an alternate representation, in which commitments are directly asserted. The commitToFine invariant specifies that after a Payer receives an authNOK message for a payment, the Payer is committed to paying the fine. The last invariant, committedFine , asserts the committed relation when the fine is paid, thereby, satisfying the commitToFine invariant. Both representations, message invariants and commitment invariants, are reasonable representations. The former is efficient, while the later abstracts messages as commitments, which simplifies specification and run-time commitment reasoning, and increases flexibility. For example, commitments can be delegated. Therefore, the Payer may delegate the payment commitment to another agent to fulfill its responsibility. SERM ON can monitor such commitment chains, when such relationships are specified.

7

3.4 Analyzing protocol scenarios Having specified the object model, protocols, and protocol goals, our analyst goes on to simulate typical scenarios to better understand the evolving specification. A scenario is a sequence of actions by the objects in the protocol. An action sequence can be specified in a script to simulate a scenario. Each step in the scenario is represented by the state of the objects, including their message history. Property evaluation of simulated and real protocols enactments are presented in the following subsections. Here, we show how a snapshot of the objects can be interpreted according to specified properties. Figure 4 presents two kinds of information. First, the state of the objects and their message history is specified in the upper and left parts of Figure 4. The analyst can directly edit this information, which specifies the protocol classes and their instances. Second, the bottom part of Figure 4 shows the interpreter. The analyst can enter new OCLTM expressions or reference existing ones. After doing so, the interpreter presents the expression evaluation. With the specified objects, the Payer’s payFine invariant evaluates as true in Figure 4. When the evaluation of an expression returns an unexpected result, the analyst reconsiders the objects or their requirements, eventually rewriting requirements or fixing the scenario.

Figure 4 Design-time evaluation of goals for specified scenarios objects.

3.5 Unit testing protocol goals Based on the object interpretation of the previous section, our analyst believes that the protocols are correctly specified. Now, our analyst tests the protocols with scenario scripts. The top part of Figure 5 presents a typical unit test script, written for JUnit. For the payment protocol of Figure 1, the script creates the three objects, sets their protocol, and then starts their execution threads. The last script line uses R EQM ON’s JUnit extension to assert that there shall be one instance of the payFine 8

property true. The standard JUnit 4 timing attribute (@5000 ) specifies that the assertion must hold within the 5 seconds after the start of the test case. The bottom part of Figure 5 presents the resulting JUnit output, showing that the test passed. Together, this shows how OCLTM properties can be testing using REQM ON’s JUnit extension.

Figure 5 JUnit testing of protocol goals.

3.6 Usage monitoring protocol goals To illustrate the run-time evaluation of requirements with monitors, again consider the example of the Payer’s payFine property. • The target system containing the Payer class executes • The monitor acquires the input data, INmon, including updates about Payer objects • The monitored input data, INmon, is analyzed by the monitor • The monitor evaluates requirements satisfaction The monitor acquires its input data, INmon, using available instrumentation techniques (e.g. [7-9]) from executing software; REQ M ON relies mostly on TPTP. With each input, the monitor analyzes and updates requirements evaluations using an algorithm to evaluate primitive (nested) properties first, followed by propagating values for composite properties. Table 1 shows the results.

9

Table 1 Incremental evaluation of the Payer property, payFine.

Input data event

Resulting property evaluation

E1 = Payer.authNOK()

P1 = payFine.after.rAuthNOK(global,E1,satisfied) SA1 = ScopeActivation(after, P1, open) P2 = payFine.eventually.sPayFine(SA1,E2, satisfied) P3 = payFine((global, (P1, P2), satisfied)

E2 = Payer.payFine()

Table 1 illustrates the property evaluation process for an input sequence that satisfies the messagebased Payer requirement, payFine. The monitor input data, INmon, consists of two significant events in sequence. The first input event occurs when the Payer object receives a rAuthNOK message. The monitor processes the event, asserting that the rAuthNOK property, P1 , is satisfied, which then causes the after scope, SA1, to become open. The next input event, payFine, satisfies the eventually clause, and given that the after scope is still open, P2 is satisfied, and with it the entire payFine property, P3, is satisfied. If the commitment-based requirement, committedFine, is considered, then when P3 is satisfied, then the Payer’s fulfillment of their commitment is asserted.

3.7 Implementation The R EQM ON system is implemented as a set of Equinox plugins. The first three comprise the system core, while the latter are REQM ON extensions. 1. The OCLTM parser and compiler are extensions to the IBM Eclipse OCL technology (org.eclipse.ocl). The temporal patterns (and the commitment patterns extension of SERM ON) are defined as operators on existing OCL types, and thus are entirely OCL compatible. Our parser gains the syntactic and semantic checks completed by the existing technology. For example, editors provide code completion to fill in operators or attributes, and errors are raised when an undefined type is referenced. (A prior version of our compiler was written in Antlr because the OCL extensions were not compatible with standard OCL syntax[13].) The compiler applies the visitor pattern to annotate the parse tree and then output monitor rules, which are then compiled by Jess. 2. The event stream interpreter is a set of Jess rules. Kernel rules handle timeouts, propagate property evaluations, and notify listening clients. Together, the kernel rules and the generated monitor rules form an event stream interpreter for specified properties. When an event enters the rule-based system (RBS), the rules execute in response, incrementally updating property evaluations. The system in reasonably efficient, in part, because of the factoring and partial result sharing provide by the RETE RBS algorithm[16]. 3. Instrumentation and event acquisition is provided by standard technologies. Eclipse TPTP automatically instruments a Java program to output a stream of Common Base Events (CBE), a standard for event management. Users may also manually instrument their program using log4j or other technologies. REQM ON can listen to and adapt such common event streams, translating their events into its native event repository, which fulfills OclMessage and CBE interface specifications. 4. A client API allows for new applications to be written against the REQM ON system. The OCLTM interpreter (of Figure 4) is a client that sends objects to the server and then executes a query for their evaluation. Our JUnit extension is a simple REQM ON client. A Java program under test runs with TPTP and REQM ON ’s JUnit extension to output CBE events, heard by the REQM ON event stream interpreter, running as a server. REQM ON ’s JUnit extension queries the R EQM ON server about the properties and asserts their results, as shown in the last line of Figure 5. The plugin architecture of REQM ON allows variants, like SERM ON, to be defined with plugins.

4

Discussion

Practitioners may find value in our approach to monitoring. In this paper, we have demonstrated (1) how REQM ON can be extended to support commitment-based property extensions, (2) how REQM ON-based monitoring can integrate into common development activities, and (3) how such monitoring applies to service-protocol goal analysis. 10

The flexibly of our monitoring approach arises, in part, from the flexibility of the components on which we build. The UML and its OCL define an extension framework, which supports the specification of our OCLTM design-, test-, and run-time event-stream interpreter. Although REQM ON directly supports OCLTM, developers may define their own monitoring language as an extension of OCL. SERM ON demonstrates how message-based properties can be characterized as commitmentbased properties, which increases specification and monitoring flexibility, and enriches message semantics. We have applied REQM ON to assess the satisfaction of clinical goals for a small group of emailing patients[17]. Our extensions in S ERM ON have been applied to web service systems, including the SET Purchase Process demonstrated in this paper. Our future work will introduce new tools for developing and applying monitors, as well as specialized monitors, like SERM ON but for other domains. References [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17]

K. Umapathy and S. Purao, "A Theoretical Investigation of the Emerging Standards for Web Services," Special Issue of Information Systems Frontier (ISF) - From Web Services to Services Computing: Technologies and Applications (Forthcoming), 2006. L. Brownsword, D. Fisher, E. Morris, J. Smith, and P. Kirwan, "System-of-Systems Navigator: An Approach for Managing System-of-Systems Interoperability," in Technical Note CMU/SEI-2006-TN-019, 2006. N. Desai, A. K. Mallya, A. K. Chopra, and M. P. Singh, "Interaction protocols as design abstractions for business processes," IEEE Transactions on Software Engineering, vol. 31, pp. 1015-1027, 2005. A. van Lamsweerde, "Goal-oriented requirements engineering: a roundtrip from research to practice," Requirements Engineering Conference, 2004. Proceedings. 12th IEEE International, pp. 4-7, 2004. W. N. Robinson, "A requirements monitoring framework for enterprise systems," Requirements Engineering Journal, vol. 11, pp. 17-41, 2006. N. Delgado, A. Q. Gates, and S. Roach, "A Taxonomy and Catalog of Runtime Software-Fault Monitoring Tools," IEEE Transactions on Software Engineering, vol. 30, pp. 859-872, December 2004. L. Baresi and S. Guinea, "Towards Dynamic Monitoring of WS-BPEL Processes," Proceedings of the 3rd International Conference on Service Oriented Computing, 2005. G. Spanoudakis and K. Mahbub, "Requirements monitoring for service-based systems: towards a framework based on event calculus," Automated Software Engineering, 2004. Proceedings. 19th International Conference on, pp. 379-384, 2004. F. Barbon, P. Traverso, and M. Pistore, "Run-Time Monitoring of Instances and Classes of Web Service Compositions," Proceedings of the IEEE International Conference on Web Services (ICWS'06)-Volume 00, pp. 63-71, 2006. F. Basanieri and A. Bertolino, "A Practical Approach to UML-based Derivation of Integration Tests," 4th International Quality Week Europe, 2000. C. W. Damus, "Implementing Model Integrity in EMF with MDT OCL," Eclipse Corner Articles, February 9 2007. K. Umapathy and S. Purao, "Exploring Alternatives for Representing and Accessing Design Knowledge about Enterprise Integration," in 26th International Conference on Conceptual Modeling (ER 2007), Auckland, New Zealand, 2007. W. N. Robinson, "Extended OCL for goal monitoring," Electronic Communications of the EASST, vol. 9, pp. 1-12, January 2008. M. B. Dwyer, G. S. Avrunin, and J. C. Corbett, "Patterns in property specifications for finite-state verification," in Twenty-First International Conference on Software Engineering, pages, Los Angeles, 1999, pp. 411-420. S. Flake, "Enhancing the Message Concept of the Object Constraint Language," in In Sixteenth International Conference on Software Engineering and Knowledge Engineering (SEKE 2004), Banff, Canada, 2004, pp. 161-166. C. L. Forgy, "Rete: A fast algorithm for the many pattern/many object pattern match problem," Artificial Intelligence, vol. 19, pp. 17-37, 1982. S. Fickas, W. Robinson, and M. Sohlberg, "The Role of Deferred Requirements: A Case Study," in International Conference on Requirements Engineering (RE'05), Paris, France, 2005.

11