Further Work

There is potential for extending the current design to provide more functionality. We describe some of the further work that is in progress to expand the features of the framework.

Enhanced querying support

The SQL querying available currently is sufficient for basic retrieval needs. But there is scope for adding other types of query objects for both general purpose requirements like name-value pair matching to special applications that require the making of complex decisions using scripts. We see a place for a JINI like template filtering presently and other filtering and querying methods can be added as and when required in particular situations.

Handling generic messages

XMessages considers all messages to be just a valid XML structure. So it parses the message to verify the correctness of the XML but does not try to interpret it. To do so, it would have to be aware of the XML schema and this can be provided by mapping different message types to the corresponding message object. This makes it necessary to maintain a central repository of mappings accessible to different messaging interfaces. This is not viable and a better alternative is to present a generic XML structure of the message that can be understood by indiavidual implementations of the messaging components. This would provide a standard API to the XML form of the message and ease access to its fields without worrying about parsing the XML. Application writers can use this API to write different message handling routines based on the XML content and at the same time, the core messaging layer can be retained without being aware of the message schema.

Dynamic plugins

The message channel can provide a gamut of value added service and be quite powerful as it can act as a central controller for switching messages between applications. But the ability to add such features to the channel must be made more convenient instead of having to write complete implementations of the message channel for each new feature. We are adopting the popular concept of plugins to allow for adding features to a channel incrementally.

Each channel starts of with a default set of core features. When a message is to be processed, it runs through an optional chain of plugins before using the default handling routine. These plugins can be added or removed on the fly by the application starting the channel. This application acts as a controller of the channel and could accept requests to add or remove plugins.

For example, consider a user who has launched a component that publishes events about its status every few minutes to a channel. The user may initially have a simple listener application on her desktop machine to receive these events from the channel. If she needs to go away from her desk and still continue to monitor the status, say for a job completion or exception event, she could request the channel to load a plugin to forward the particular events to her handheld device or cellular phone. If she gets back to her desk before its occurrence, she could unload that plugin and continue to monitor all events on the desktop. The plugin feature could be put to many such uses.

WSDL specialization

Currently, we have made the XMessages API transport independent (i.e.) in the WSDL specification, we have defined all message interfaces without using protocol specific constructs such as SOAP header. We are however investigating an optimized transport binding for XMessages, such as one that uses SOAP headers to describe message control parameters (like currentToken, nextToken, leaseDuration etc.), with the message being placed in the SOAP body directly.

Security

Exchanging messages in a large grid brings into focus the need to verify the authenticity of the message and check the authorization of those allowed to publish and subscribe for messages. This check may be on an individual basis as in a message source or sink trusting one another or on a larger perspective with the publishers and listeners being authenticated by a common channel they subscribe to. The modalities of such a security mechanism needs to be looked into more closely.

Extending framework to other messaging platforms

One of the advantages we attributed to the XMessages system is the ability to extend it to implement other messaging APIs or even act as bridges between messaging systems operating in a diverse environment. We need to demonstrate this by creating implementations of other messaging specifications, specifically JMS and OGSA, that have APIs similar to XMessages.