next up previous
Next: Reference Implementation: xEvents Up: An Extensible and Interoperable Previous: Requirement Specifications

Subsections

Proposed Event System: Grid SOAP Events

SOAP [6] is an object-oriented, Internet based protocol for exchanging information between applications in a distributed environment. The SOAP specification defines the format of data to be in XML. SOAP has the advantage that many programming languages and component frameworks can support it. Since XML is a canonical way of representing data in a tree oriented structure, it lends itself to self-describing and extensible formats. It is to be noted that high performance distributed applications can depend on real-time events and scientific visualization environments often need events with multi-media information. These requirements can be met by highly specialized implementations and cannot be addressed by a generalized framework designed for the Grid environment. SOAP by itself is not efficient for large scale scientific applications but can be effectively used for sending signals and small size information packets in a platform and language independent manner [13]. Thus SOAP seems like an attractive format to specify a event system in a Grid based environment.

Core Features

The core requirement of Grid SOAP Events consists of a definition for the base SOAP event type and a specification of a SOAP RPC call to an event listener.

Base SOAP Event Type

Figure 1: The base type event described in XML Schema
\begin{figure}\begin{center}
\begin{boxedverbatim}<schema targetNamespace = ''...
...sequence>
</complexType>
</element>\end{boxedverbatim}\end{center}\end{figure}

Figure 1 represents an XML-Schema for a base event type. It draws from the essential features of events in the Jini system. It represents the minimal information that any event is expected to contain. The eventNamespace field along with eventType uniquely identifies the event. The eventType hierarchy is differentiated with dots: for example an event of type notebook.experiment.LinearSolver is a subtype of notebook.experiment. The source identifies the originating point of the event while the timestamp represents the elapsed time in milliseconds since midnight, 1 January 1970. The seqNo helps in providing support for different delivery protocols.

Figure 2: An example Resource-Event in XML.
\begin{figure}\begin{center}
\begin{boxedverbatim}<MachineUtilizationEvent>
<...
...moryUsed>
</MachineUtilizationEvent >\end{boxedverbatim}\end{center}\end{figure}

The event type is also described using an event schema. Figure 2 shows an example of a resource event encoded in XML. The schema definition for this event derives from the base event type. Figure 3 shows the definition of the XML-schema that provides a formal specification for the derived event type instance. We plan to use RDDL (Resource Directory Description Language) [11] to associate metadata information with SOAP event types.

Figure 3: An XML-schema for a specialized event type.
\begin{figure}\begin{center}
\begin{boxedverbatim}<schema targetNamespace=''ht...
... </complexType>
</element>
</schema>\end{boxedverbatim}\end{center}\end{figure}

When an event is received from the wire its type needs to determined so that the values of the elements in the XML payload can be extracted. To achieve this a mapping needs to exist between an XML-Schema and a C++ or Java class in the runtime environment. The event system can then query the class to obtain the values of its fields. If such a mapping doesn't exist for the specified schema type then the event system should throw an exception which in turn should be represented on the wire as a SOAP-Fault element.

Event Listener

Figure 4: API for an event listener.
\begin{figure}\begin{center}
\begin{boxedverbatim}interface EventListener {
v...
...leEvent(Event ev) throws Exception;
}\end{boxedverbatim}\end{center}\end{figure}

Figure 4 shows a simple API for a listener of SOAP events. Note that the type specified in the event is the base type. However, since SOAP supports polymorphism through the XML-Schema Instance type attribute (xsi:type), a derived type can be sent. Mapping events to classes specific to the runtime environment is required only at the receiving end. A run time mapping to the language specific event object can be established as the type of event is read from the xsi:type in the XML payload.

Figure 5: Simple Publisher using pre-formatted SOAP-RPC template for events
\begin{figure}\begin{center}
\epsfig{file=events_simple3.eps}\end{center}\end{figure}

Event Publisher

The generator of events need not have a full implementation of SOAP. An event publisher can just write pre-formatted strings into the socket layer (see figure 5). This makes the proposed event model practical for embedded systems and other applications which need a small footprint, like resource performance sensors [18]. Therefore a formal specification for a publisher is not required, and it suffices to formally state how events should be consumed. Minimal requirements for a simple publisher and listener make it simple to use events in a SOAP-enabled environment.

Additional Features

As described in Section 3.2 services should be readily constructed on top of the core SOAP event requirements. A few specialized features such as storing of remote references, leasing and event channels greatly enhance the functionality of a distributed application in which the event system is embedded. For an actual implementation, these specialized features require additional interface specifications.

Event Channel

Figure 6: SOAP API for Event Channel.
\begin{figure}\begin{boxedverbatim}public interface EventPublisher {
}
public ...
...s EventChannel, LeasingFilteredEventPublisher {
}\end{boxedverbatim}\end{figure}

An event channel in our proposed system can be used to connect event listeners and event publishers. Figure 6 shows the SOAP API for an event channel.

Remote References

Figure 7: An Example of a SOAP based Remote Reference.
\begin{figure}\begin{boxedverbatim}<Port>
<endpoint>
<location>http://192.16...
...gFilteredEventChannel</name>
</portType>
</Port>\end{boxedverbatim}\end{figure}

Remote references are handles to objects that reside on remote machines. Direct connections using sockets are not reliable as access may be blocked by firewalls. Remote references allow communication between publishers and subscribers using proxy servers or direct connections. Remote references can be stored in LDAP and can be used to implement third party objects as is done in Jini.

Figure 7 shows an XML representation of a remote reference. The remote reference contains the location of the remote endpoint (web service) for an event service. The port type that describes the kind of event service provided is uniquely identified by the uri of its interface and its name. However, the port type may even point to a Web Services Description Language (WSDL) [5] instance. To interoperate with Apache SOAP [1] the URI of the endpoint is also required. The endpoint may have bindings that specify how the parameters of the payload should be interpreted. The representation of a remote reference as an XML string makes it easy to store it in a directory service.

Event Publisher: Subscription and Leasing

Although an event publisher can be as light-weight as a simple embedded system inserting text into preformatted strings, robustness may require more utility. When a publisher restarts after a crash, it may not be able to recover the entire list of listeners that were subscribed to it. Persistence of an event channel in the face of failures and location independent mechanism to find new location of event channel is a well known problem. The straightforward solution of each publisher keeping a persistent database of listeners is not viable. For example, ``resource sensors'' run on host machines and report utilization to remote monitors. Resource sensors are barely-tolerated guest processes on remote machines and must have a small footprint - ruling out using heavy weight persistence.

A widely accepted solution in this case is to use a leasing mechanism. A subscription to an event channel must be periodically renewed so that robustness of the event system can be maintained. To achieve this the event channel grants a lease to its subscribers and each subscriber holds the responsibility of renewing its lease. When the event channel has to be restarted, all listeners eventually resubscribe (when renewing their lease) and event distribution resumes after a temporary lapse.

Figure 8: API for Leasing-Event Publisher.
\begin{figure}\begin{boxedverbatim}interface LeasingFilteredEventPublisher {
...
...uration,
String handback)
throws Exception;
}\end{boxedverbatim}\end{figure}

Figure 9: Schema for Event Lease Object.
\begin{figure}\begin{center}
\begin{boxedverbatim}<schema targetNamespace = ''...
...sequence>
</complexType>
</element>\end{boxedverbatim}\end{center}\end{figure}

Figure 8 shows the SOAP API for a Leasing-Event publisher. The subscription call accepts a remote reference as a parameter along with a lease duration. The publisher returns a lease object (see Figure  9) indicating the lease that has been provided. This lease duration may or may not be the same as what was requested. The filter argument can be used to indicate filtering requirements. The handback argument is sent back to the listener along with the event. The listener can use it to identify the event and use to determine how to react to the event.

Figure 10: HTTP header for a subscribeLease call.
\begin{figure}\begin{boxedverbatim}POST /leasing-filtered-event-channel HTTP/1...
...-event-channel ...

Figure 11: A Remote Reference on the Wire.
\begin{figure}\begin{boxedverbatim}<p1 id='id1' xsi:type='ns1:soaprmi.port.Por...
...<userName xsi:type='xsd:string'></userName>
</p1>\end{boxedverbatim}\end{figure}

Figure 10 shows the HTTP header in a SOAP call to a lease-publisher. The wire representation of a remote reference is shown in figure 11. The SOAPAction header can be required for some SOAP based applications and firewalls, and indicates the intent of the message as to what service it wants to invoke the method on.

Naming

Event producers and consumers need to find each other on the Grid. The LDAP hierarchical model allows us to provide meaningful names to event channels and model dependencies (see figure  12). Local event channels can connect to higher level group channels which in turn can be connected to an organization level event channel. It is even possible to have a direct connection between event channels at startup time or dynamically at runtime (see Figure 13)

Firewall

SOAP RPC uses HTTP as the underlying transport protocol. HTTP protocol is ``firewall friendly'' since port 80 on which HTTP traffic flows is guaranteed to be open in all systems running httpd. The SOAP specification states that data on the wire should be transmitted as plain text. This helps in easy inspection of the data that is received on the firewall-port.

Summary

Grid SOAP event framework specifies simple and minimal requirements for an event and form the foundation for an extensible framework for subscribers and listeners. By specializing the publisher and event channel to provide leasing, SOAP events can be deployed on the Internet and provide robustness in the face of intrinsic failures and crashes of subscribers and listeners. Basing the naming and directory service support for SOAP events on LDAP lends scalability in wide area networks such as the Grid or Internet. To work in both Intranet and Internet environments it is important for an event system to be firewall-aware.

Figure 12: Example of advanced SOAP Events system
\begin{figure}\begin{center}
\epsfig{file=events_advanced3.eps}\end{center}\end{figure}

Figure 13: LDAP based hierarchical event channel setup
\begin{figure}\begin{center}
\epsfig{file=events_naming3.eps}\end{center}\end{figure}


next up previous
Next: Reference Implementation: xEvents Up: An Extensible and Interoperable Previous: Requirement Specifications
Aleksander Andrzej Slominski 2002-02-23