Active XML (AXML) provides an elegant platform to integrate the power of XML, Web services and Peer to Peer (P2P) paradigms by allowing (active) Web service calls to be embedded within XML documents. In this chapter, the authors present some interesting aspects encountered while investigating a transactional framework for AXML systems. They present an integrated locking protocol for the scenario where the structure of both data and transactions are nested. They show how to construct the undo operations dynamically, and outline an algorithm to compute a correct optimum undo order in the presence of nesting and parallelism. Finally, to overcome the inherent problem of peer disconnection, the authors propose an innovative solution based on ”chaining” the active peers for early detection and recovery from peer disconnection.
TopIntroduction
Active XML (AXML) (Abiteboul et. al., 2003) systems provide an elegant way to combine the power of XML, Web services and Peer to Peer (P2P) paradigms by allowing (active) Web service calls to be embedded within XML documents. An AXML system consists of the following main components:
- •
AXML documents: XML documents with embedded AXML service calls (defined below). For example, the AXML snippet in Box 1 is an AXML document with the embedded service call ‘getGrandSlamsWon’. The function of the service getGrandSlamsWon is basically to retrieve the Grand Slams won by a tennis player, and the abbreviations A, F, W and U correspond to the Australian, French, Wimbledon and US Grand Slams respectively.
- •
AXML Services: AXML services are basically Web services, defined as queries/updates over local AXML documents. Note that while AXML services can be invoked remotely, the operations they encapsulate are local, that is, defined on AXML documents hosted on the same peer.
- •
Peers where both the AXML documents and services are hosted. AXML peers also provide a user interface to query/update the stored AXML documents locally.
An embedded service call may need to be materialized: 1) in response to a query on the AXML document (the materialization results are required to evaluate the query) or 2) periodically as specified by the ‘frequency’ attribute of the AXML service call tag <axml:sc>. We illustrate materialization with the following example: Let the AXML document D corresponding to Box 1 be hosted on peer AP1, and the service getGrandSlamsWon hosted on another peer AP2. Now, assuming the embedded service call getGrandSlamsWon needs to be materialized, the following sequence of steps takes place:
Box 1. Sample AXML document with embedded service call getGrandSlamsWon
<?xml version = “1.0” encoding = “UTF-8”?>
<ATPList date = “18042005”>
<player rank = 1>
<name>
<firstname>Roger</firstname> <lastname>Federer</lastname>
</name>
<citizenship>Swiss</citizenship>
<points>475</points>
<axml:sc mode = “merge” serviceNameSpace = “getGrandSlamsWon”
serviceURL = “…” methodName = “getGrandSlamsWon”>
<axml:params>
<axml:param name = “name”>
<axml:value>Roger Federer</axml:value>
<axml:param name = “year”>
<axml:value>$year</axml:value>
</axml:params>
<grandslamswon year = “2003”>A, W</grandslamswon>
</axml:sc>
</player>
…
</ATPList>
- 1.
Figure 1(a). AP1 invokes the service getGrandSlamsWon of AP2 with the parameter value children nodes of the service call getGrandSlamsWon node of D. Note that a service call’s parameters may themselves be defined as service calls. Given such a scenario, AP1 needs to first materialize the parameter service calls, and then invoke the service getGrandSlamsWon.
Figure 1. Materialization of the embedded service call getGrandSlamsWon
- 2.
Figure 1(b). On receiving the invocation results (an XML subtree), AP1 does one of the following based on the ‘mode’ of the embedded service call getGrandSlamsWon. A service call can have the following modes: a) replace: the previous results are replaced by the current materialization results, or b) merge: the current results are appended as siblings of the previous results. The resulting AXML document, after a materialization of getGrandSlamsWon of D with parameter value “$year = 2004”, is shown in Box 2. Analogous to parameter inputs, the invocation results may also be static XML or another service call. If the invocation results contain another service call, then AP1 needs to materialize them first before inserting the results in D.