Universal Messaging 9.5 is the successor of Universal Messaging 9.0/9.1.

Universal Messaging 9.5 includes new features, enhancements, and changes as described in the following topics.

webMethods Universal Messaging can now be managed and monitored using webMethods Command Central. Users can perform actions such as starting or stopping Universal Messaging realms, monitoring status and KPIs, and configuring ports and license keys of Universal Messaging realms. For details, see the webMethods Command Central section in these release notes.

Universal Messaging assets can now be deployed using webMethods Deployer. Universal Messaging assets can be exported using Enterprise Manager and checked into a version control system. From there, users can create builds and deploy assets selectively using Deployer. Supported asset types are as follows:

Universal Messaging can now be monitored using webMethods Optimize for Infrastructure. Fifty-two KPIs are available that span realms, queues, channels, and data groups-all of which can be tracked over time for trending and alerting using advanced analytic capabilities in Optimize.

Universal Messaging now supports acknowledgement of individual messages and redelivery counts both on shared durable topics and on queues. This support improves performance of multi-threaded processing and duplicate detection, as is typically used with webMethods Integration Server triggers

Universal Messaging now supports multicast delivery on non-filtered channels. This support allows the high-performance fanout of messages to a large number of interested clients, which is accomplished through the use of broadcast network protocols rather than point-to-point delivery to individual subscribers.

Universal Messaging C++ clients now support a wider range of platforms. These platforms include the following:

The performance of Universal Messaging persistent document stores has been improved for mixed and reliable channels.

The shared-memory transport capability of Universal Messaging -for low-latency messaging within a single machine - has been improved, further reducing end-to-end latency.

Universal Messaging 9.5 SP2 introduces a new store type for channels and queues - Off Heap. Off Heap Store is a new Topic or Queue store mechanism that uses memory which is not within the Java Heap space, but rather, is allocated directly from the host's memory.

Any memory allocated within the JVM is subject to Garbage Collection inspection. This inspection allows the JVM to release unused memory and move memory that has been used for a while into different memory partitions. It also adds a level of jitter to the JVM, as it needs to pause while it does this inspection and potential move. The use of Off Heap memory stops the Garbage Collection from inspecting and moving these regions since they are outside of the JVM's memory domain. This has the effect of reducing such jitter within the Universal Messaging Server.

Since the events are stored in memory, you still get fast memory access, with no impact from GC within the Server. This is extremely useful when using stores that can potentially contain data that will exist for a prolonged period of time, since pauses that might otherwise be caused by GC inspections will not occur. By default, the server will be allowed to use a maximum of 1GB of memory for off heap store use (in addition to the current default of 1GB maximum available to the Java heap). However, these amounts are not pre-located. Typically, a system will start off consuming approximately 128-256MB of RAM, and will consume more memory only if it needs to.

Remote Direct Memory Access is direct access from the memory of one computer into that of another without involving either one's operating system. This permits high-throughput low-latency communication, which is especially useful in massively parallel computer clusters.

With Shared Memory drivers built into Universal Messaging and supported in C#, C++ and Java we can achieve very fast, high throughput messaging on the same machine. With conventional networking standards like TCP/IP, all messages are pushed through the kernel's network stack and back again. There are some off-loaded drivers allowing application code direct access to the Network card, but these still require a layer of TCP above to interpret and manage. RDMA removes this restriction and allows an area of application memory to be mapped and then written to from a remote computer with no Operating System involvement at all; instead, the Interface card and driver alone marshal the incoming event and put the data directly in the application's memory. This results in performance close to that of same-machine Shared Memory, but between 2 separate computers.

The default value for Config / Event Storage / CacheAge has been reduced from 1 day to 1 minute.

The default value for: Config / Global Values / DisableExplicitGC has been changed from true to false.

A new configuration parameter: Config / Fanout Values / DelayPublishOnCapacity has been added, with a default value of true. It causes the publisher to be throttled once any optionally set capacities are reached on a channel or queue.

The default heap size has been changed from 512MB to 1GB.

The following updates are available at the API level: