Daniel Romero
email: daniel.romero@inria.fr

Context-Aware Middleware: An overview

Keywords: context-awareness, middleware platform, pervasive computing

In this paper we give an overview of context-aware middleware platforms. They are characterized in terms of properties such as communication, context management and adaptation. We present a description of different platforms and their properties.

Introduction

Today is normal to find different computational entities that are part of environments where people develop their daily activities such as home, office and malls. These entities provide services that can help users in their activities. The entities are also characterized by their heterogeneity. This means that they use different communication mechanisms, connection technologies and data representations, and that they provide information with different processing levels. Some of these devices also change constantly of location producing variation in services availability. All these properties are typical of the so-called pervasive environments.

It would be desirable to access the services present in a pervasive environment throw devices like laptops, smart phones, and PDA increasingly powerful. However, they need some kind of mechanism that enable them to do it. Furthermore, it is also required to detect the changes in the context, which could affect the applications been executed in user devices. In computing, there exist a discipline that deals with this kind of concerns, the "context-aware computing". As in [START_REF] Abowd | Towards a better understanding of context and context-awareness[END_REF] is established, the context-aware computing uses the context in order to provide relevant information and services to users. The context is understood as "any information that can be used to characterize the situation of an entity, where an entity can be a person, place, or physical or computation object". Inside of this area, a special kind of application has emerged, the context-aware middleware solutions. In general, they provide the same functionality associated with traditional middleware in terms of communication. However, they also provide context management and adaptation to deal with the different resources present in the environments. In this paper we give an overview about these middleware platforms and their different features.

The rest of this paper is organized as follow. In section 2 we present a motivation scenario. Section 3 describes some relevant properties in this kind of middleware. Section 4 presents some context-aware middleware platforms and their characterization in terms of properties described in section 3. Finally, in section 5 we give some conclusions.

Motivation Scenario

In this section we present a simple scenario to contextualize the use of context-aware middleware platforms. Alice, a philosophy student, goes to the mall. She has a smart phone device with a context-aware middleware previously installed. The first time that she gets in the mall, her mobile device detects an available wireless network and accesses it. Once connected, the middleware platform discovers a location service, advertised with the UPnP [START_REF]Upnp technologythe simple, seamless home network[END_REF], which shows Alice position in a mall map and allows device to locate the different mall stores. In the mall, Alice remembers a letter that she has to sent. She doesn't have the printed letter but she has the document on her smart phone. Using the mobile device, Alice is able to find a printer service, published using Service Location Protocol (SLP) [START_REF] Guttman | Service location protocol, version 2[END_REF], and prints a copy. Using the location service, Alice knows where is the printer that she has used and locates the post office in the mall. After sending the letter, Alice goes to a zone in the mall, where her phone detects a Web Service that provides different day's promotions in bookstores. By the user preferences, Alice smart phone knows that she is interested in books related to philosophy subjects. Using this information, the mobile device is able to inform Alice about promotions related to this kind of books. The promotion service is provided in three ways: text only, text and images and video. The phone selects the video option considering the Alice preferences, the memory capacity and battery level. Alice consults the promotions while she goes to the melt area. In this area, the promotion service is not available, but Alice doesn't note this because her mobile is able to continue using the service. When the device battery is low, the promotion service is change to text only mode.

Context-Aware Middleware: General Characterization

The context-aware middleware platforms are an answer to challenges associated with service discovery, mobility, environmental changes and context retrieval [START_REF] Romero | An sca-based middleware platform for mobile devices[END_REF]. These challenges are typical in ubiquitous computation. Hence, for facing these challenges it is necessary to provide functionality associated with the properties described below.

1. Context Management: this property is associated with context retrieval and processing. The context retrieval means to deal with different kinds of context providers, data representation and communication styles. Furthermore, the context information has to be processed, composed and distributed. In our scenario, the middleware has to retrieve information associated with the mobile resources (available memory, battery level), user preferences (reading interests and kind of favorite services) and the wireless network. Events and policies are the principal mechanisms used to deal with context retrieval and processing. 2. Adaptation: it refers to actions that must be triggered when some event occurs in the environment. This means that the middleware platform should react to context changes. This reaction consists in structure and/or behavior changes. In our scenario, the two kinds of adaptation are needed. Structural adaptation (i.e. to load new functionality) can be required in order to use the available services in the mall (location service, promotion service, printer service). In our scenario, behavioral adaptation takes place when the middleware has to decide how to chose the quality of service according to the memory and battery level. But the adaptation is not only required at runtime. Considering the different kind of entities that is possible to find in pervasive environments, the middleware should be flexible enough to support different configurations and to be deployed on diverse devices. Hence, dynamic and static adaptation are required. 3. Communication: this property is necessary to interact with the different entities in the environment. The middleware platform should be able to support different kinds of protocols, interaction paradigms, and communication technologies. The configuration should be not only static but also at runtime when new services can require communication mechanisms not been supported until that moment. 4. Service Discovery: it is the capacity for discovering and invoking available services in the environment. This task is done by means of service discovery protocols. These protocols define how the services have to be advertised, discovered and in some cases accessed. Hence, they are built upon communication protocols. It is possible to find different services discovery protocols developed in the academia, the industry and by software vendors. Examples from academia are Ninja Service Discovery Service (SDS) [START_REF] Adjie-Winoto | The design and implementation of an intentional naming system[END_REF] and Intentional Naming System (INS) [START_REF] Hodes | An architecture for secure wide-area service discovery[END_REF]. Jini [START_REF]Jini specifications and api archive[END_REF], UPnP and Rendezvous [START_REF] Cheshire | Dns-based service discovery[END_REF] were created by software vendors. Salutation, SLP and Bluetooth SDP [START_REF] Sig | Specification of the bluetooth system[END_REF] are industrial standards. However, despite the existence of these protocols, some middleware platforms define its own discovery protocols to support the access of new services. In the scenario, the services are advertised using UPnP and SLP. 5. Persistence: in some cases it can be useful to storage the context because the user movements and connection variations cause changes in services availability. 6. Application Building Support: some approaches provide frameworks that help in the application development and/or adaptation in order to work with the middleware platform. 7. Paradigms used: it is important to select the suitable paradigms to develop the platforms in order to satisfy the adaptation issues.

Platforms

This section presents some existing context-aware middleware. In the table 1 they have been characterized using the properties presented in section 3.

Gaia

Gaia [START_REF] Román | Gaia: A Middleware Infrastructure to Enable Active Spaces[END_REF][START_REF] Henricksen | Middleware for distributed context-aware systems[END_REF] is a distributed middleware that provides similar functionality to an operating system. It allows the coordination of software entities and heterogeneous networked devices in active spaces (physical spaces). Gaia provides services for event management (that means to distribute events in active spaces), context information query (in order applications can adapt to the environment), detection of digital and physical entities, storage of the information associate with entities (space repository), and file management (by means of a context file system that generates a virtual hierarchy associating file to relevant context information). Gaia also provides a framework for building (or to adapt existing) context-aware applications. The Gaia architecture can be seen in figure 1.

Gaia Microserver

Gaia Microserver [START_REF] Chan | Gaia microserver: An extendable mobile middleware platform[END_REF] is a lightweight middleware platform that extends Gaia (see section 4.1) in order to support access to the native capabilities of the mobile devices. The middleware exports the functionality oered by the device to Gaia as components. The Microserver allows interoperate the native C++ code with the java code. Gaia uses the platform to deliver dynamic software components and multimedia contents to users through their mobile devices. The Gaia Microserver components are showed in figure 2. In our scenario, Gaia middleware could be used to detect the different services present in the environment, i.e., the location service, the printer service and the promotion service. Then, those services could be accessed through the mobile device using the Microserver. It will allow device to get the new functionality required in order to use the services.

Aura

Aura [START_REF] Garlan | Aura: an architectural framework for user mobility in ubiquitous computing environments[END_REF] is an architectural framework for ubiquitous computing applications. It provides services for managing tasks, applications and context. In Aura, the tasks are abstract representations of a collection of services. When a user moves to another environment, the task representation is migrated and the service providers associated are instantiated in the new location. The services are provided by existing applications. Aura gives supports for registry and access of services. Context observers provide the context information and it is used to derive user intents. In the scenario, the service providers can be considered like the applications that provide the Aura services. The sending of the letter and the searching of book promotions can be considered as Aura tasks. The task concerning the letter includes the location service and the printer service. The task associated with the books comprises only the promotion service. In this last task, the task migration of Aura can be used in order to continue using the promotion service in the melt area. Figure 3 shows the Aura architecture.

CORTEX

CORTEX [START_REF] Sorensen | A context-aware middleware for applications in mobile ad hoc environments[END_REF][START_REF] Blair | Research directions in reflective middleware: the lancaster experience[END_REF] is a context-aware middleware for pervasive and ad hoc environments. The platform is based on concepts of sentient objects (SOs) and component frameworks. SOs are autonomous entities that can get data from the environment and share information between them. They consume and produce events. SOs are able to make decisions and perform actions based on the information sensed. The component frameworks offer services (to the SOs) such as publish-subscribe (used for discovery), group communication, context retrieval, and QoS management. CORTEX can be reconfiguration at runtime using a reflection API. In our scenario, each service discovery protocol (SLP, UPnP and Web Services) could be associated to an specific SO. This SO has the responsibility to enable the device in order to discover and access the services. Another SO could consolidate all services (filtering them using the Alice preferences) and a CORTEX application could use this SO in order to show the available services (by categories), which would allow Alice to send the letter and to knows the book promotions. QoS management service could be used to select the correct promotion service considering the battery level and the available memory. This QoS management could also be used to monitoring those resources (battery and memory) in order to adapt the QoS. The CORTEX platform is illustrated in figure 4 The idea is to customize the platform considering the applications needs. In order to do that the middleware behavior, with respect to an application, is reified as meta-data in an application profile. This profile contains the description of associations between the service that the middleware customizes, the policies that can be used in the service invocation and the context configuration that allows the use of the policies. In each service invocation, the client application passes its profile to the platform and it determines the policies that can be applied according to the current context. CARISMA provides a reflective API that allows, at runtime, to modify the associations describes in the profile. The conflicts that may arise between profiles are resolved using a micro-economic approach. In this approach, the system is modeled as an economy where the consumers (applications) reach an agreement about a limited set of goods (the policies) using the middleware platform like auctioneer. In the scenario, it would be possible to have a CARISMA application that accesses the promotion service. In the profile associated with this application, a policy could express the conditions (battery level and available memory) that allow the device to invoke the different kinds of the promotion service.

MobiPADS

MobiPADS [START_REF] Chan | Mobipads: a reflective middleware for context-aware mobile computing[END_REF] (Mobile Platform for Actively Deployable Service) is a system for mobile environments. In MobiPADS the services are called mobilets. They can migrate between MobiPADS environments. Each mobilet is divided in slave and master. The slave resides in the server side, and the master in the client side. The mobilets are configured as chained objects to provide augmented services and protocols to the mobile applications. MobiPADS achieves context-awareness with the utilization of an event notification model. It monitors the status of the interested context and notifies the changes to the subscribed entities. The event notification model allows the composition of primitive events into an event graph. In this way, when an event service is built and subscribed, it has to monitor and analyze the basic events and match them according to the event graph structure. The adaptation can be made in the platform, based on system profiles, or in the mobilets, allowing them to change according to the events that they receive. The figure 5 shows the platform architecture. Using the MobiPADS platform in the scenario, the location service, printer service and promotion service could be encapsulated in mobilet objects. Of course, the slaves would reside in the MobiPADS side and the masters in the user's mobile device. The migration property of the mobilets would be used to make available the promotion service in the meal area. The event model of MobiPADS could be used to monitoring the battery level and memory capacity in order to detect when it is necessary to change the promotion service to the text only mode.

MiddleWhere

MiddleWhere [START_REF] Ranganathan | Middlewhere: a middleware for location awareness in ubiquitous computing applications[END_REF] is a distributed middleware architecture for location. The platform separates applications from location detection technologies. It allows the addition of different kinds of sensing technologies and determines the location information quality. The applications can make queries about the objects location or they can subscribe to be notified when a location condition becomes true. The location model applied in MiddleWhere is hierarchical and it uses three kinds of location: points, lines, and polygons. The location can be expressed in coordinates and a symbolic way. MiddleWhere also determines the quality of the location information according to its freshness (as time goes on, the quality of location data reduces). The platform also provides persistence for the location information. MiddleWhere has a reasoning engine that deduces spatial relationships between mobile objects and the physical environment. The architecture of the platform is showed in figure 6. MiddleWhere could be useful in the scenario in order to provide the location service that Alice use to know where is she and where are the printer and post services. In order to that, the UI allows three different techniques: abstract UIs (XML), plug-in UIs (downloadable Java code) and Web-based UIs (HTML). The media components provide functionality to capture images, audio and video, facilitating the portability and scalability of native media capabilities across the various devices. The CAPNET platform is illustrated in figure 8. In the scenario, CAPNET could be used to discover the services but it will required to have some kind of adapter that allow to use the services as Jini services. The multimedia CAPNET capabilities could be used to provide the best video quality according to the resources in Alice's smart phone.

RCSM

Reconfigurable Context-Sensitive Middleware [START_REF] Yau | Development and runtime support for situationaware application software in ubiquitous computing environments[END_REF][START_REF] Yau | Reconfigurable context-sensitive middleware for pervasive computing[END_REF] (RCSM) has been developed to provide development and runtime support for situation-aware (SA) software in ubiquitous computing. It provides a SA-IDL that allows the specification of context-situation relevant for an application, the actions to be triggered, and when these actions has to be executed. The SA-IDL specifications are compiled to generate application skeletons. These skeletons interact at runtime with the RCSM Object Request Broker (R-ORB) and the SA processor. R-ORB deals with the context discovery, collection and propagation. To do that, R-ORB has a context manager that uses a context discovery protocol to register local sensors and to discover remote sensors. When an application starts up, the discovery protocol is used to find the sensors (local or remote) that satisfy the context requirements. The SA processors manage the SA requirement specifications, stores the context, recognize the situation based in the context and determine when the actions have to be triggered.

Conclusions

In this article we have presented several context-aware middleware platforms. They are characterized in terms of some relevant properties for this kind of application. Furthermore, the applicability of context-aware middleware is illustrated with a simple scenario.

All the context-aware middleware platforms reviewed allow devices to recover and process context information. The platforms also offer different mechanism to detect changes in the environment and trigger adaptations (in the application and/or middleware level) associated with these changes. However each one focuses in a specific aspect of pervasive environments. For example, Aura deals with user tasks and the migration and adaptation of them according to the current user context. Gaia offers access to heterogenous resources available in active spaces. MiddleWhere is focused in location-awarennes. MobiPADS offers service migration and adaptation of the service composition represented by the mobilets. Then, the selection of the more suitable platform will depend on the requirements of applications that are being built.

Although all middleware platforms could be used in the scenario proposed, it is not always straightforward. In some cases, it is necessary to create some kind of representation for the service providers in order to use all the capabilities of the platforms. Besides, some platforms do not consider the dynamic load of functionality to use services that are discovered at runtime, limiting their use in pervasive environments.

Finally, in spite of the existence of different context-aware middleware platforms, there is not a definitive solution for all the challenges associated with pervasive computing. In fact, there are some projects that continue the research in this area, such as the Cappucino Project1 (from Inria Laboratory) and the MUSIC Project2 .

Fig. 1 .

 1 Fig. 1. Gaia Platform Architecture

Fig. 2 .

 2 Fig. 2. Gaia Microserver Components

Fig. 3 .

 3 Fig. 3. Aura Framework Architecture

Fig. 4 .

 4 Fig. 4. CORTEX Platform Architecture

Fig. 5 .

 5 Fig. 5. MobiPADS Architecture

Fig. 6 .

 6 Fig. 6. MiddleWhere Architecture

  Figure 7 shows the SOCAM architecture. Applying SOCAM to the scenario, service providers would be represented by context providers in the Context Middleware Layer that allows the detection and invocations of services. The memory, battery and user preferences would be associated to Context Providers and Context Interpreters in order to adapt the services that depend on them. In Context Application Layer each service (promotion, service and location) would also have a context-aware service representation. It would be useful in the promotion service case to adapt the mode according to the battery and memory changes.

Fig. 7 .

 7 Fig. 7. SOCAM Architecture

Fig. 8 .

 8 Fig. 8. CAPNET Architecture

Table 1 .

 1 Context-Aware Middleware

	Middleware	Developer	Paradigm	Adaptation	Context	Service Communication Persistency Application
	Platform		Used	Static Dynamic	Management	Discovery		Data Context	B. S
	Gaia	University of Illinois Components	AL	AL	First order logic	Events	Events	X	X	Framework
		at Urbana-Campaign				and boolean algebra		and RPC
	Gaia	University of Illinois Components		AL	Services provided	GAIA	Events
	Microserver at Urbana-Campaign				by Gaia	Proxy	and RPC
	CORTEX	Lancaster	Reflection,	ML	ML	SOs	SLP, UPnP	Events-		X
		University	components, SOs				SOS	SOAP
			component
			frameworks
	Aura	Carnegie Mellon	Components		ML	Situation	Aura	Connectors	X	X
		University				recognition,	suppliers
						proxies
	CARISMA University College	Reflection		ML	Policies associated	Not	According
		London				with each	supported to applications
						application		needs
	Middlewhere University of Illinois Components			Algorithm for		Events
		at Urbana-Campaign				multisensor
						location fusion
	MobiPADS	HK Polytechnic	Components,		AL, ML	Events,	Mobilets	Events
		University	reflection			mobilets
	SOCAM National University	Ontologies,		AL	Situation recognition, SLM service	Events		X
		of Singapore	SOA			ontologies	discovery
	RCSM	Arizona State	Components	ML	AL	Situation	R-CDP	Messages		X
		University				recognition	protocol
	CAPNET University of Oulu	Components	ML		Wrappers for	Service	Events		X	Framework
						context sensors	discovery	asynchronous
							component	messages,
							that locates	RPC,
							service	TCP/UDP,
							provides	HTTP,
							by other	multicast
							components

Cappucino Project: http://cappucino.oqube.com/

MUSIC Project: http://www.ist-music.eu/


Unit testing for the Web

Testing a Web application: User operations:

• Get the welcome page

• Click on a link

• Fill a form

• Check the pages

• etc

Features expected:

• Support of Javascript/AJAX <wunit:fill-form form="{$wunit:document//FORM[@name='login']}"> <xcl:param name="user" value="Bill"/> <xcl:param name="password" value="Sesame"/> </wunit:fill-form>

▪POST datas:

<wunit:POST url="http://www.example.com/login.html"> <xcl:param name="user" value="Bill"/> <xcl:param name="password" value="Sesame"/> </wunit:POST> ▪Check HTTP headers (and cookies):

<xunit:assert-number-equals expected="200" result="{value($wunit:frame/@wunit:response-code)}"/> <xunit:assert-string-equals expected="text/html" result="{string($wunit:frame/@wunit:mime-type)}"/> Tag libraries available (from Active Tags and RefleX): ▪WUnit: <wunit:GET>, <wunit:click>, $wunit:document, etc ▪XUnit: <xunit:test-case>, <xunit:assert-node-equals>, etc ▪XCL (the XML Control Language): <xcl:if>, <xcl:then>, <xcl:else>, <xcl:parse>, <xcl:transform> (XSLT), etc ▪I/O: io:file(), #io:input, etc ▪Web: <web:mapping>, $web:session, #web:x-session, web:mime-type() ▪etc (SQL, XQuery...)

Hundreds of active materials are available

Modules in Active Tags and RefleX

▪WUnit is just a module (a library) from a larger framework called Active Tags that allows to design XML-based applications.

▪RefleX is an implementation of Active Tags in Java.

Each module can define active tags <my:elem>, XPath functions my:funct(), XPath variables $my:var, foreign attributes @my:attr, data types #my:data-types

Screenshots of our Web application: an image gallery

AJAX autocompleter

Intrusive unit testing for Web applications by Philippe Poulard 8 <!--set the boundary of the test case--> <xunit:test-case name="report/1-gallery-welcome" label="[Web] Welcome page"> <!--start to discuss with the servlet emulator--> <wunit:conversation application="../webapp/WEB-INF/web.xml" uri="http://www.example.com/"> <!--get the welcome page hosted in our server emulator--> <wunit:GET url="http://www.example.com/"/> <!--do we have it ?

we ask to the $wunit:frame predefined property what is the HTTP response code--> <xunit:assert-number-equals result="{ value( $wunit:frame/@wunit:response-code ) }" expected="200"/> <!--is it an HTML page ?--> <xunit:assert-string-equals result="{ string( $wunit:frame/@wunit:mime-type ) }" expected="text/html"/> <!--parse the static welcome page from the file system...--> <xcl:parse-html source="../webapp/index.html" name="expected"/> <!--...and compare it with those returned by the server.

$wunit:document is a predefined property that refers to the DOM of the HTML document of the current page--> <xunit:assert-node-equals result="{ $wunit:document }" expected="{ $expected }"/> </wunit:conversation> </xunit:test-case> result="{ value( $wunit:frame/@wunit:response-code ) }" expected="200"/> <xunit:assert-string-equals result="{ string( $wunit:frame/@wunit:mime-type ) }" expected="text/html"/> <!--we should have 2 rows--> <xunit:assert-number-equals result="{ count( $wunit:document//TR ) }" expected="2"/> <!--first row--> <xunit:assert-string-equals result="{ $wunit:document//TR[1]/TD[1] }" expected="item1"/> <xunit:assert-string-equals result="{ $wunit:document//TR[1]/TD[2]/IMG/@src }" expected="images/item1"/> <!--second row--> <xunit:assert-string-equals result="{ $wunit:document//TR[2]/TD[1] }" expected="item2"/> <xunit:assert-string-equals result="{ $wunit:document//TR[2]/TD[2]/IMG/@src }" expected="images/item2"/> </wunit:conversation>

Other tests

Upload a file and test if it's in the Web server Other tests to consider: ▪The AJAX autocompleter (please refer to the RefleX web site) ▪A complete scenario (please refer to the RefleX web site) ▪Checking database updates: this could be perform with a direct SQL or XQuery query to the database.

Error report

Tools for running all the test cases, aggregating the results in a single XML report, and an XSLT styleshet are supplied

Feature not (yet) covered ▪SSL and certificates: Could use a dummy certificate server-side ▪JNDI support: Would allow to have a testing environment that includes test databases (SQL, XQuery, etc) that could be initialized by the test suite Right now: use the production database or duplicate the Web application ▪WUnit/XUnit as an output language for Selenium ? ▪A better error report (with HTML rendered fragments in the output)

Test of the Welcome page

	by Philippe Poulard by Philippe Poulard	Test of the gallery (1) Test of the gallery (2)
	Intrusive unit testing for Web applications Intrusive unit testing for Web applications	But, it is empty !?! Yes, but let's store authoritatively some images in the user session (because this application works like this), and check how is rendered the page <!--.../... --> <!--check what we GET:--> <xunit:assert-number-equals
	9 10

The implementation

•110,000 lines of code (stripped from comments and blank lines)

•Jar size: 1.3MB

Questions ?

Free, open source


Why the Active Tags suite ? •SAX to DOM •DOM to SAX <xcl:parse-stylesheet name="myXslt" source="file:///path/to/stylesheet.xsl"/> <xcl:parse-filter name="xinclude" source="http://www.w3.org/2001/XInclude"/> <xcl:parse name="myDoc" type="SAX" source="file:///path/to/document.xml"/> <xcl:filter name="included" source="{ $myDoc }" filter="{ $xinclude }"/> <xcl:transform source="{ $included }" stylesheet="{ $myXslt }" output="file:///path/to/output.html"/> Built-in filters The name of the file name()

io:x-file

The parent directory of this file parent:: adt:list of io:x-file

The files contained in this directory child::

xs:integer

The length of this file @io:length

xs:date

The last date when this file was modified @io:last-modified xs:boolean Indicates whether or not this is a file. @io:is-file <xcl:update referent="{ $dir/@io:last-modified }" operand="{ $newDate }"/>

  details (DOM,SAX) Connexions with the environment (SYSTEM, I/O, SQL, Web...)

{$now/@year} Can't compute expressions , can only refer to values {$price * $discount} Shell-fashioned references

  :parse> parse an XML document or fragment <xcl:document> create an XML document or fragment can be SAX or DOM

	by Philippe Poulard	A self-descriptive system Handling XML documents
		a convenient root the engine "knows" which tag is an action and which tag is a literal with XCL : the XML Contol Language
		an Active Catalog is plugged to the engine
		<?xml version="1.0" encoding="iso-8859-1"?>
	Active Tags	<xcl:active-sheet xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> can be accessed <xcl:parse name="myDoc" source="file:///path/to/document.xml"/> <xcl:parse-stylesheet name="myXslt" XPath expression but : Module Extensibility bind <asl:element name="xcl:parse"... instruction that creates the property named « myDoc » Like « AVT » in XSLT <asl:schema target="xcl"> <exp:module target="xcl"> <exp:element name="xcl:parse"... <xcl:parse> Active tag XML catalog : map URI URIs Active Catalog : map URI + selector with XPath <xcl:parse name="myDom" type="DOM"/> compatible <xcl:document name="mySax" type="SAX"> resources (URI, module, schema, catalog, active-sheet...) How is it resolved ? resource management facilities (caching policy) <wrapper> can be filtered with { $myDom } XPath patterns </wrapper> </xcl:document>
		Active Schema Comparison with Ant/Jelly/JSTL... <document time="${now}"> validate	•can occur in text content •is not cast to string •can refer to objects bind supply validate supply
		Welcome ${user.name} to Jelly! </document> <cat:catalog> <exp:module>	Active Catalog
		Can't extend to path expressions <asl:schema> are resolved in	<cat:catalog> <cat:uri name="http://www.inria.fr...
	6	the same manner

source="file:///path/to/stylesheet.xsl"/> <xcl:transform source="{ $myDoc }"

stylesheet="{ $myXslt }" output="file:///path/to/output.html"/> </xcl:active-sheet> <xcl

  Philippe.Poulard@sophia.inria.fr http://reflex.gforge.inria.fr http://disc.inria.fr/perso/philippe.poulard/xml/active-tags.pdf

	by Philippe Poulard by Philippe Poulard	A Web application X-Operable objects Modularization Modularization And now ?
		incoming URL : http://www.acme.com/index.xml <?xml version="1.0" encoding="iso-8859-1"?> incoming URL : http://www.acme.com/user.html?userName=Poulard (cross-operable objects) <?xml version="1.0" encoding="iso-8859-1"?> <xcl:active-sheet Use/define a custom module Objects type are identified by QNames like web:x-response, io:x-file, io:output, io:input, <web:service xmlns:web="http://www.inria.fr/xml/active-tags/web" xmlns:acme="http://tags.acme.org/usersInfo" xmlns:sys="http://www.inria.fr/xml/active-tags/sys" To go further :
	Active Tags Active Tags	In the documentation of the I/O module <?xml version="1.0" encoding="iso-8859-1"?> <web:service xmlns:web="http://www.inria.fr/xml/active-tags/web" xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <web:mapping match="^/(.+)\.html$" mime-type="text/html"> <xcl:parse name="myDoc" source="web:///{ $web:match/node()[1] }.xml"/> <xcl:transform source="{ $myDoc }" stylesheet="web:///WEB-INF/transform.xsl" output="{ value( $web:response/@web:output ) }"/> </web:mapping> <web:mapping match="..."> <!--other web stuff--> </web:mapping> </web:service> type : io:output regexp captured group <web:response web:output="[io:output@189c036]" web:mime-type="text/html"> <Cache-Control>no-cache</Cache-Control> <Date>Tue, 15 Nov 1994 08:12:31 GMT</Date> </web:response> internal representation Avoid round-trip Objects are not necessary representable in XML : •what would be the XML representation of an (I'm not talking about the content, but about the container, as an object) <xcl:document name="userDoc"/> <user userName="{ $sys:env/userName }"> <user userName="{ $exp:params/@name }"> { $dsml } (« macro tag ») instance of io:input or io:output ? xs:string, xs:integer, xml:document, etc Not necessary represented with tags xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <web:mapping match="^/user\.html$"> <?xml version="1.0" encoding="iso-8859-1"?> xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <acme:user-info name="{ $sys:env/userName }"/> •read carefully the slides ! <web:service <xcl:transform source="{ $acme:userInfo }" <xcl:set name="ldap" xmlns:acme="http://tags.acme.org/usersInfo" stylesheet="file:///path/to/userStylesheet.xsl" value="ldap://ldap.acme.org:9009/dc=acme,dc=org xmlns:web="http://www.inria.fr/xml/active-tags/web" output="{ $sys:out }"/> ??sub?(&(sn~={ $web:request/userName })"/> <xcl:parse name="dsml" source="{ $ldap }"/> xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <web:mapping match="^/user\.html$"> </xcl:active-sheet> •email-me <xcl:document name="userDoc"/> <user userName="{ $web:request/userName }"> { $dsml } </user> </xcl:document> <xcl:transform source="{ $userDoc }" stylesheet="web:///WEB-INF/userStylesheet.xsl" output="{ value( $web:response/@web:output ) }"/> </web:mapping> <?xml version="1.0" encoding="iso-8859-1"?> <xcl:active-sheet xmlns:sys="http://www.inria.fr/xml/active-tags/sys" Batch script <acme:user-info name="{ $web:request/userName }"/> <xcl:transform source="{ $acme:userInfo }" stylesheet="web:///WEB-INF/userStylesheet.xsl" output="{ value( $web:response/@web:output ) }"/> </web:mapping> </web:service> <?xml version="1.0" encoding="iso-8859-1"?> <exp:module target="acme" xmlns:acme="http://tags.acme.org/usersInfo" xmlns:exp="http://www.inria.fr/xml/active-tags/exp" xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <exp:element name="acme:user-info"> EXP : Extensible XML Processor •discuss about Active Tags on the XML-dev list •download the engine </web:service> xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"> <xcl:set name="ldap" value="ldap://ldap.acme.org:9009/dc=acme,dc=org ??sub?(&(sn~={ $sys:env/userName })"/> <xcl:parse name="dsml" source="{ $ldap }"/> <xcl:set name="ldap" •try the tutorials value="ldap://ldap.acme.org:9009/dc=acme,dc=org Web application ??sub?(&(sn~={ $exp:params/@name })"/> <xcl:parse name="dsml" source="{ $ldap }"/> <xcl:document name="userDoc"/> implementation of the tag •send me some money ☺
	12 13	<xcl:update> <xcl:rename> <xcl:append> ...etc web:output="[io:output@189c036]" <web:response web:mime-type="text/html"/> type : web:x-response { $dsml } </user> bound to an object Big objects, binary object : high-cost for XML encoding/decoding XML view Incomplete objects : the content is computed only when it is accessed (late binding) </user> </xcl:document> <xcl:transform source="{ $userDoc }" stylesheet="file:///path/to/userStylesheet.xsl" output="{ $sys:out }"/> </xcl:active-sheet> expose as a single tag (externalization inside a custom module) </xcl:document> <exp:exports> <exp:export name="acme:userInfo" value="{userDoc}"/> </exp:exports> </exp:element> </exp:module> be defined with macros property properties can also exported XPath functions and predefined Questions ?