Event Messages’ Parameters

An XChangeevent messageis an XML document with a root element labelledeventand at least five child elements labelledraising-time,reception-time,sender,recipient, andid. The design decision of representing event messages’ parameters as child elements and not as attributes of the event message’s root is that they may contain complex content. For example, the time point of raising an event message at a Web site might be represented as a time point accompanied by a specification of the calendar used in the respective country. Thus, an event message wraps the event data like in the following:

<?xml version=""1.0?>

<xchange:event xmlns:xchange="http://xcerpt.org/xchange"> <xchange:sender> sender </xchange:sender>

<xchange:recipient> recipient </xchange:recipient>

<xchange:raising-time> raising-time </xchange:raising-time> <xchange:reception-time> reception-time </xchange:reception-time> <xchange:id> id </xchange:id>

event data </xchange:event>

where

• sender is the URI of the Web site where the event has been raised, that is its representation as event message has been constructed and sent to one or more Web sites. The URI of the sender is determined and inserted into the event message by the Web site’s event manager before sending it. • recipient is the URI of the Web site that received the event message. As already explained,

XChange excludes broadcasting of event data, implying that the recipient Web site(s) of an event message must be known before sending it. For an event message, at least one recipient needs to be given in the event message specification used to raise the event.

• raising-timeis the time of the event manager of the Web site raising the event. This is the local raising time of the event message on the machine on which the event manager is running on. • reception-time is the time at which the event manager of the recipient Web site receives the

event message. This is the local reception time of the event message on the machine on which the event manager is running on. Notethat the reception time of an event message might be before its raising time as no global time exists on the Web (proposals exist, such as [128], for models of an approximated global time base for distributed systems; however, this is not realistic in the largest distributed system – the Web).

Event messages’ time stamps (raising time and reception time) are given in XChange by using the ISO 8601 standard format for the representation of dates and times4_.

• id is an event message identifier given at the recipient Web site. Each event message gets at its reception such an identifier for uniquely identifying it in querying. The format and the method (e.g. counting received event messages each day and identifying them with the temporal specification of the actual day followed by the counter) used for event messages’ identifiers are application specific. The current implementation of the XChange event manager uses positive integers for identifying event messages.

• event datais an XML element (having possibly complex structure) containing information about an event that has occurred. How the data about the event is represented is application specific. Reactive applications communicating through XChange event messages are not restricted to XML- based applications. For example, XML serialised RDF data can be also communicated between and processed by XChange programs.

4_{ISO 8601,http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html}

4.3. EVENT MESSAGES

XChange assumes that each event message has a distinctive reception time, that is at each point in time a single event message is retrieved. However, for extensions or future versions of the language where this assumption is lifted, the eventidparameter uniquely identifying event messages has been introduced. Whether this assumption is lifted or not depends on the time granularity used for event reception.

A DTD for the XML representation of event messages is given next. The namespace prefix chosen for the DTD is the one used throughout this thesis (prefixxchangefor namespacehttp://xcerpt.org/xchange). A parameter entity is used in place of the content of an event messages; the content (event data) is applica- tion specific and thus has to be defined depending on the application.

<!DOCTYPE xchange:event [ <!ELEMENT xchange:event ( xchange:sender, xchange:recipient, xchange:raising-time, xchange:reception-time, xchange:id, %event-data)>

<!ATTLIST xchange:event xmlns:xchange CDATA #FIXED "http://xcerpt.org/xchange">

<!ELEMENT xchange:sender (#PCDATA)> <!ELEMENT xchange:recipient (#PCDATA)> <!ELEMENT xchange:raising-time (#PCDATA)> <!ELEMENT xchange:reception-time (#PCDATA)> <!ELEMENT xchange:id (#PCDATA)> ]>

Being XML documents, XChange event messages represent Xcerpt data terms (discussed already in Section 2.4.2) and thus, methods developed for querying persistent data can be also applied for querying incoming event messages. The importance of this note will be made clear in Section 4.4. The examples given in this section use the term syntax to represent event messages, but the reader should keep in mind that XChange programs communicate through XML documents that represent event messages.

Example 4.1 (XChange Event Message Notifying an Exhibition)

The following XChange event message is sent byhttp://artactif.cominforming the travel organiser of Mrs. Smith about an exhibition of the painter G. Barthouil. Notethe use of thexchangenamespace for the keywordeventand for the parameters of an XChange event message.Notealso that the examples abstract away from a particular communication protocol. Here,organiser denotes the communication protocol used by a personalised organiser.

xchange:event { xchange:sender {"http://artactif.com"}, xchange:recipient{"organiser://travelorganiser/Smith"}, xchange:raising-time {"2005-05-05T10:15:00"}, xchange:reception-time {"2005-05-05T10:17:00"}, xchange:id {"5517"}, exhibition {

painter {"G. Barthouil"}, location {"Marseilles"}, time-interval{"[2005-05-08..2005-05-18]"},

visit-hours { from {"10:00"}, until {"18:00"}} }

}

An event message is an envelope for an arbitrary XML content. Thus, multiple event messages can (but not necessarily) be nested making it possible to create trace histories.

CHAPTER 4. PARADIGMS. CONCEPTS. SYNTAX Example 4.2 (Nesting XChange Event Messages)

Mrs. Smith notifies a friend of her about G. Barthouil’s exhibition. The following XChange event message is sent by Mrs. Smith’s travel organiser and contains the received event message from the previous example: xchange:event { xchange:sender {"organiser://travelorganiser/Smith"}, xchange:recipient{"organiser://travelorganiser/myFriend"}, xchange:raising-time {"2005-05-06T11:10:20"}, xchange:reception-time {"2005-05-06T11:11:20"}, xchange:id {"5611"}, content { xchange:event { xchange:sender {"http://artactif.com"}, xchange:recipient{"organiser://travelorganiser/Smith"}, xchange:raising-time {"2005-05-05T10:15:00"}, xchange:reception-time {"2005-05-05T10:21:20"}, xchange:id {"1234"}, exhibition {

painter {"G. Barthouil"}, location {"Marseilles"}, time-interval{"[2005-05-08..2005-05-18]"},

visit-hours { from {"10:00"}, until {"18:00"} } }

} } }

Notethat XChange messages are compatible with the messages and the “message exchange patterns” of SOAP (discussed in Section 2.3.3). XChange event messages can be seen as a very simplified form of SOAP messages, as only the minimum information is required (time stamps, sender, recipient, and id). However, XChange does not preclude the usage of more complex event messages’ parameters. XChange applications can be implemented in such a way to construct such event messages and to understand their meaning properly.