Runtime Monitoring of Web Service Choreographies Using Streaming XML
Total Page:16
File Type:pdf, Size:1020Kb
Runtime Monitoring of Web Service Choreographies Using Streaming XML ∗ Sylvain Hall´e Roger Villemaire University of California, Santa Barbara Universit´edu Qu´ebec `aMontr´eal Department of Computer Science C.P. 8888, Succ. Centre-ville Santa Barbara, CA 9310-65110 Montreal, Canada H3C 3P8 [email protected] [email protected] ABSTRACT web services. Since most web services exchange XML mes- A wide range of web service choreography constraints on sages, one can refer to a recorded trace as an XML “docu- the content and sequentiality of messages can be translated ment” that can be analyzed using standard XML tools, us- into Linear Temporal Logic (LTL). Although they can be ing for example the XML Query Language (XQuery) [19,28]. checked statically on abstractions of actual services, it is However, most works attempting to tap on the resources desirable that violations of these specifications be also de- available in XQuery engines operate in a post mortem fash- tected at runtime. In this paper, we show that, given a ion: an instance of a choreography must be finished be- suitable translation of LTL formulæ into XQuery expres- fore analysis can take place on a complete XML document. sions, such runtime monitoring of choreography constraints While in some cases, a post mortem analysis on recorded is possible by feeding the trace of messages to a streaming traces is appropriate, there exist situations where violations XQuery processor. The forward-only fragment of LTL is in- of a specification must be addressed as soon as they are troduced; it represents the fragment of LTL supported by discovered. available streaming engines. The recent years have seen the rise of a new form of XML evaluation called streaming XML: an XML stream is a linear sequence of events generated by the parsing of a document. Categories and Subject Descriptors Streaming XML engines evaluate XPath or XQuery expres- D.2.5 [Software Engineering]: Testing and Debugging— sions by taking as input only that stream of events. These monitors; F.4.1 [Mathematical Logic and Formal Lan- engines have been developed with the intent of processing guages]: Mathematical Logic—temporal logic; H.3.5 [In- very large XML documents that could not fit in the memory formation Storage and Retrieval]: Online Information of traditional tools. In this paper, we show how streaming Services—web-based services; I.7.2 [Document and Text XML engines can be used for a second, perhaps unexpected Processing]: Document Preparation—XML purpose, by turning them into runtime monitors for web service interactions. In Section 2, we show by means of a General Terms simple e-commerce example how a trace of XML messages exchanged by web services can be fed progressively to an Theory, verification XQuery engine, which reads and processes it as a streaming “document”. Keywords This principle is formalized in Section 3, where we recall Runtime monitoring, web services, streaming XML how Linear Temporal Logic can be used to express a wide range of interaction properties. We then provide a mapping between LTL and XQuery expressions suitable for streaming 1. INTRODUCTION XML, and study some extensions of LTL that can also be A web service choreography specification can loosely be translated into XQuery at no additional cost. seen as a set of constraints on the messages exchanged by We put a special care in porting our runtime monitor- ∗ ing approach to a practical context; this is why in Section This work was done when Sylvain Hall´ewas at Univer- 4, we survey readily-available XQuery engines with respect sit´edu Qu´ebec `aMontr´eal. We gratefully acknowledge the financial support of the Natural Sciences and Engineering to their streaming capabilities and show that most existing Research Council of Canada on this research. products cannot be used to monitor full-fledged Linear Tem- poral Logic. We introduce LTL→, the forward-only fragment of LTL, which corresponds to the “least-common denomina- tor” that can be monitored on engines with limited stream- Permission to make digital or hard copies of all or part of this work for ing capabilities. Experimental findings indicate that the use personal or classroom use is granted without fee provided that copies are of a streaming XQuery engine to perform runtime monitor- → not made or distributed for profit or commercial advantage and that copies ing of LTL can be implemented with negligible additional bear this notice and the full citation on the first page. To copy otherwise, to load on existing web service execution environments, while republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. providing for immediate, real-time detection of a substantial SAC’09 March 8-12, 2009, Honolulu, Hawaii, U.S.A. class of choreography violations. Copyright 2009 ACM 978-1-60558-166-8/09/03 ...$5.00. 2. MOTIVATION 2.2 In-memory vs. Streaming XML In this section, we provide an example of a web service sce- There exist two main modes of representing and process- nario where choreography constraints must be monitored at ing XML documents by XPath and XQuery engines. In the runtime. In particular, we focus on the subset of choreogra- Document Object Model (DOM) [2], the nested tag struc- phies which constrain the sequence of messages exchanged ture of the original document is translated in memory into by one specific partner with its peers. This form of interac- a tree model; to process a query, the engine can retrieve ar- tion can be seen as a “contract” to be locally monitored and bitrary parts of of the document by specifying the path to enforced. Assuming that web services interact by exchang- the desired nodes. Although relatively straightforward, this ing structured XML messages, as is the case for a substantial method suffers from the fact that the whole document must portion of existing resources, we then show informally how be loaded in memory in order to be processed. Experimen- streaming XML engines can be used to perform that moni- tal benchmarks showed that, as a consequence, DOM-based toring. XQuery engines are unable to process large documents [22]. An alternate approach consists of representing an XML 2.1 Runtime Monitoring of Web Services document as a sequence of events generated as it is parsed. Consider an e-commerce scenario where a shop offers users Only this sequence of events is fed to the engine, which to buy products through a web service interface. A client consumes them in their order of arrival and updates its state service first logs into the system by providing a user name. to compute the desired query result. The shop offers a discount if a user connects with the com- Streaming XML shifts the processing burden from the mitment to buy at least one product, which is signalled with parser, which is relieved from building a tree structure from the commitToBuy element. The shop responds to the login XML code, to the query engine, which is forced to update with a loginConfirmation, providing a unique ID for the its state based on a linearized version of the document. De- session. Additionally, if the user’s commitment to buy a veloping such an engine is generally more complex than for product has been accepted by the shop, a maximum delay a DOM-based solution: it involves tracking the nesting of in minutes before which the first transaction must take place elements and carefully memorizing whatever parts of the is given in the expiration element. document are required to compute a result. In counterpart, The user can then retrieve the product list, ask for details because streaming query engines do not require the whole about specific products, and eventually send a buyOrder document to be loaded at once in memory, they can process message indicating the products and respective quantities documents orders of magnitude larger than DOM engines. that it wishes to buy. Several such messages can be sent, and the transaction is concluded by sending a confirmPayment 2.3 Monitoring With Streaming XML message, providing as a safety measure the unique ID given A second, crucial advantage of streaming XML is that the by the shop at the start of the session. query results are also streamed: whenever possible, the en- There exist several interaction constraints that should be gine sends its results progressively to an output pipe, while monitored at runtime under such a scenario. For example, the input document is being read, and without having to from the online shop point of view, one might want to make wait until the end of document has been reached. This fea- sure that users committing to buy actually do so eventually. ture of streaming XML can be put to good use to perform basic monitoring of web service choreographies at runtime. Contract Specification 1. A user whose commitment For example, suppose a sequence of messages M1, M2,... to buy has been accepted by the shop will eventually send a is streamed to an XQuery engine as the following “docu- buyOrder message. ment”: <trace> <message> M1 </message><message> M2 · · · < /message> · · · < /trace>, where Mi is the XML To prevent clients from buying products with outdated body of the i-th message. Then consider the following ex- information, the shop might require that no buyOrder be pression Q: sent before first asking for the latest product listing: every $x in /trace/message[2] satisfies Contract Specification 2. No buyOrder can be sent before first receiving a product list. (not($x/commitAccepted = “true”) or some $y in $x/following-sibling::* satisfies To make sure that the safety measure is enforced, one $y/name = “buyOrder” might also want to monitor that the unique session ID sent at the start of the session be present in every confirmation.