Message oriented middleware (MOM) has been available for many years. In October 1998, an industry standard emerged from Sun Microsystems, the Java Message Service (JMS). At a programming interface level, this standard describes how a messaging middleware is accessed from a piece of Java code. The two main abstractions are “topics” (publish/subscribe messaging) and “queues” (point-to-point messaging). While the standard describes the interface to the messaging middleware, the implementation of the middleware is not specified. Also, integration of non-Java programming languages is not specified, and integration of non-programmable messaging devices (such as phones or pagers) are not specified.
Existing messaging middleware allows one to access the middleware over a fixed, small number of transport protocols. These are usually TCP or SSL. Supporting a new protocol requires the vendor of the middleware to implement it and to integrate it into the middleware. Non-Java devices may or may not be supported, but again, extending the middleware for as yet unsupported devices requires the vendor of the middleware to enable it. Non-programmable devices are unsupported in current messaging middleware products.
This leads to:                Performance impacts, as TCP or SSL are unicast transport protocols, while the publish/subscribe pattern is a multicast abstraction.        Limited applicability, as devices using a new kind of transport protocol are not supported. This is especially true for wireless small devices, such as PDAs or mobile phones, which today cannot be part of a uniform messaging infrastructure.        Limited applicability, as non-programmable devices (such as a mobile phones with a built-in messaging function, e.g. Short Message Service (SMS)) cannot participate in a uniform messaging infrastructure.        A limited choice of message delivery guarantees, resulting in potentially too strong guarantees (which are too expensive) or too weak guarantees (too many messages are lost undetected). This is inadequate especially for wireless networks.        No support of asymmetrical networks, such as a cheap, best-effort bulk downlink for the actual delivery of messages, and a more expensive, reliable uplink for control data to implement the desired quality of service, i.e. message delivery guarantee.        
USPTO Backgrounds
USPTO Backgrounds