A message or event encapsulates application data. It generally comprises of headers or descriptors which describe the data, its origins and other application related information and properties. Then there is also the payload, which is the chunk of data that needs to be processed by the application. Finally, there are also the routing footprints which are added by every location the message/event has traversed through.

Message Oriented Middleware (MOM) facilitates communications between entities through the exchange of messages or events. Events and messages are for the most part identical and tend to be used interchangeably quite often. MOM facilitates asynchronous communications and allow for the development of far richer applications.

Remote method invocations have been used in distributed systems for quite some time. Frameworks such as CORBA from the Object Management Group (OMG) have had schemes in place to facilitate invocations on remote objects for more than a decade. There also has been support for remote invocations in programming languages, a case in point being the Java Remote Method Invocation (RMI) Framework. In these cases we could think of the remote object as providing a service comprising a set of functions. The provider exposes the service’s capability through an appropriate description language, which comprises the function names, the number and type arguments that a given service function takes and finally the return type that would be returned upon completion of the invocation. A simpler principle of remote invocations exists for Grid and Web Services.

Distributed messaging relies on entities responding, interacting and facilitating communications through the exchange of events rather than remote invocations. Both approaches are needed and serve different purposes.

Messaging systems based on queuing rely on the store-and-forward approach for communications. Also such systems tend to rely on point-to-point communications and the setting of queues at each end to facilitate communications.

In publish/subscribe systems the routing of messages from the publisher to the subscriber is within the purview of the message oriented middleware (MOM), which is responsible for routing the right content from the producer to the right consumers. Publish/Subscribe systems provide a clear decoupling of the message producer and consumer roles that interacting entities might have.

This is especially useful if there are a large number of potential consumers for a given event. In such cases a producer need not keep track of the large number of consumers that you should route the event to. The middleware performs this function for you.

The push by Java to include publish subscribe features into its messaging middleware include efforts like the Java Message Service (JMS) specification. One of the goals of JMS is to offer a unified API across publish subscribe implementations. JMS comprises of a set of interfaces. JMS Providers or JMS compliant systems provide implementations of these interfaces.

The JMS specification results in JMS clients being able to interoperate with any service provider, this process generally requires clients to incorporate a few changes in the initialization sequences that are specific to the vendor being used, after which interactions, as specified in the JMS API, continue.  JMS clients are provider agnostic, and with a change in initialization sequences a client should be able to function just as well with any other provider. JMS does not provide for interoperability between JMS providers, though interactions between clients of different providers can be achieved through a client that is connected to the different JMS providers.

NaradaBrokering is an open source technology supporting a suite of capabilities for reliable/robust flexible messaging; given the message based service architecture of Grids, this project is aimed at providing for the transport of messages between services and between services and clients. NaradaBrokering is designed around a scalable distributed network of cooperating message routers and processors. Messages/Events within NaradaBrokering encapsulate expressive power at multiple levels. Where, when and how these events reveal their expressive power constitutes information flow. NaradaBrokering manages this information flow.

Yes, NaradaBrokering can tunnel through firewalls and authentication proxies. NaradaBrokering can deal with 3 different types of authentication challenges (Basic, Digest and NTLM). We have also tested NaradaBrokering with Microsoft’s ISA firewall/proxy and it has been successfully deployed on Linux systems residing behind firewalls. The next release of NaradaBrokering will have a firewall/proxy configuration manager which will guide users/administrators through setting up NaradaBrokering communications across such boundaries.

One of the advantages of using the NaradaBrokering system is that you don't need MBONE for the system to work, which is the case in hardware multicast. Furthermore, the biggest drawback for using hardware multicast is that representing subscription sets as groups entails an enormous number of groups. For example if one could run into 2ⁿ groups for n subscribers. Furthermore NaradaBrokering also allows you to tunnel through authenticating firewalls and proxies; domains where multicast communication is not possible.

Robust messaging pertains to the ability to deliver messages to interested entities irrespective of the failures that might take place within the system. Similarly entities should be able to retrieve events after prolonged disconnects. NaradaBrokering provides this capability.

A single broker in NaradaBrokering can handle between 100-400 concurrent video streams with acceptable performance. NaradaBrokering has also been deployed in real-time settings by providing back end support for the Anabas conferencing software running in JMS emulation mode. Several online seminars have been conducted using this Anabas-NaradaBrokering combination and the number of users collaborating concurrently has been in the excess of 30 users several times. The strains imposed by Shared Display both in terms of the size of these messages and the rate of changes were handled adequately by NaradaBrokering.

The distributed architecture of NaradaBrokering allows us to support large concentrations of clients.

NaradaBrokering supports a very wide variety of constraints. These could be String based topics, Integer topics, Tag=Value pairs, XPath queries and SQL queries. We plan to add Regular Expression support in subsequent releases.

NaradaBrokering goes beyond other operational publish/subscribe systems in many ways. This is predicated on several factors including its support for JMS, P2P interactions, audio-video conferencing, integrated performance monitoring, communication through firewalls among others. The system has been designed to scale over a wide variety of devices - from hand held computers at one end to high performance computers and sensors at the other extreme.

NaradaBrokering has been used for supporting A/V conferencing applications, collaboration software, for communications within portals, fault tolerant Grid FTP among others. For a more comprehensive list please refer to the SC03 handout.