In the traditional, monolithic view of middleware, an application often has to deal with different clustering of its messaging layer, data layer and load-balancing layer. This leads to issues of complexity, reliability and performance (particularly due to the overhead of maintaining consistency).

The GigaSpaces approach to JMS is a step towards the virtualization of messaging middleware. The GigaSpaces virtual JMS implementation brings many of the benefits of Grid to JMS users: a queue can span across machines without changing the application (dynamic scalability); the JMS implementation has integrated caching support; and more.

In addition, the GigaSpaces approach creates totally new opportunities, such as the ability to interact in real time with different APIs. For example, consider a trading exchange that submits specific trade requests through one of its JMS queues. A supervisor who wants to cancel the request before it is processed can apply a JDBC view, perform a query to find the appropriate message, and delete it without having to scan the queue.

• Asynchronous messaging – the service consumer (slave) executes a blocking read, waiting for specific instructions or material from the service producer (master). As soon as the producer sends the material, the service consumer reads it.

• Synchronous messaging – the service producer (master) writes a request, then executes a blocking read, waiting for a reply from the service consumer (slave). At the same time, the service consumer executes a blocking read, waiting for a request from the producer. When the request appears in the space, the consumer immediately receives it and writes a response.

• Peer-to-peer – any two processes in the network can communicate directly, with no need for a coordinator.

• Publish-subscribe – several service consumers (slaves) ask to be notified when an object, matching a certain template, is written to the space. The service producer (master) then writes the object, and all consumers receive a notification message, which includes the object itself.

• Master-worker – a work pattern used for parallel processing, in which a master is responsible for breaking down a task into multiple jobs. Workers wait for the jobs by executing blocking take; execute the jobs in parallel; and write the results back to the space. The master reads the responses and aggregates them into a result.

• Brokered messaging – a service producer (master) writes an object with instructions or other material. A special broker takes (reads and erases) the object and analyzes it to determine to which service consumer (slave) it should be sent. The broker then writes a different process object to the space, which is read by the relevant service consumer.

• High availability (hot failover) – existing JMS implementations provide high availability using a JMS master/slave, which must be maintained separately from the application server, database, etc. This makes it more complicated to maintain consistency, and limits scalability. In GigaSpaces, high availability occurs through the GigaSpaces cluster; the same cluster can be used to maintain the JMS component as well as other components in the GigaSpaces environment. This leverages the policies already provided by the GigaSpaces cluster, such as partitioning, replication, and load-balancing. In GigaSpaces, high availability is not dependent on special hardware or software resources.

• Dynamic scalability – a queue/topic can span multiple machines transparently. This allows extremely flexible scalability, not just on a per-server basis, but also in a wide cluster environment. For example, an application can expand its queue capacity dynamically by deploying more nodes to host the queue. In addition, the same logical queue can be partitioned transparently (while still appearing to applications as a single queue entity), enabling capacity-balancing across multiple machines.

• Built-in integration with RDBMS – In many applications, messages received from the messaging system must remain persistent in a database for further inquiry. Normally, this requires specific business logic to map the message in a relational format, and a distributed transaction system to maintain integrity and avoid partial failure. GigaSpaces provides built-in plugins that allow applications to make messages persistent, and even customize them to fit into a specific application format – saving much of the complexity and and overhead incurred when this is done explicitly at the application level.

• Virtual view through different APIs – it may be necessary to search for a specific message in the entire messaging system, for reporting or administrative purposes. The JMS standard does not offer such functionality, but in GigaSpaces, you can view the JMS content directly through the space. For example, an application can use the space JDBC interface to query the entire JMS system for a specific message, regardless of the queue or topic to which it is associated.

• Messaging with integrated distributed caching – this functionality is required by distributed applications that handle distributed data. Most caching and messaging systems are provided by separate vendors and use different technologies, resulting in complexity, partial failover issues, and high costs. The GigaSpaces solution offers caching and messaging within the same runtime environment (not simply bundled in the same product). GigaSpaces, the same space unit can provide combined caching and messaging functionality, achieving both efficiency and integrity.