JORAM - Features

JORAM Features


Here's a listing of the main features available in JORAM.
For a full description of all features and how to use them, please consult the documentation.


JORAM fully supports JMS 1.1, JMS 2.0, Jakarta/JMS 3.0 and Java EE with support for transient, persistent, transactional and XA messaging (JORAM provide a fully functional XAResource implementation, JORAM sessions can then be enlisted in any JTA transaction according to the normal JTA semantics).

All the features described in the JMS 1.1, 2.0 and Jakarta/JMS 3.0 specification are provided by JORAM.

JORAM is an open-source software component released under the LGPL license. JORAM availability on a wide range of Java-based platforms - from J2EETM to J2METM allows your ownership investment to be rationalized over your numerous heterogeneous systems and Internet devices.

JORAM is an all-in-one mature messaging solution, it includes many features that are missing in competitive offerings and it does not require third-party products, it provides a built-in atomic storage and a distributed JNDI server. JORAM is shipped with multiples transport implementations: an InVM transport implementation for when both the client(s) and server are in the same Java virtual machine, and also a TCP based implementation when clients and server are remote.

In default configuration it only requires standard JDK classes to run.


JCA adaptor and seamless integration into Application Server.
JORAM provides a fully functional JCA adaptor that can be used in any JEE compliant application server to integrate JORAM so it can be used for consuming messages via Message Driven Beans (MDBs), or for sending messages in Enterprise JavaBeans or servlets.
JORAM can easily be installed as the JMS provider of any JCA compliant Application Server. By default, JORAM is embedded in JOnAS Application Server.
Simple instructions are provided in the distribution showing you how to do this with popular Application Server.

Standalone server
JORAM can also be run as a 100% standalone messaging server with no dependencies on Application Server. This is of interest if you want messaging, but don't want an application server.

OSGi Design
Joram is designed with an OSGiTM based services architecture to provide a dynamically adaptable messaging server:

  • The Joram server can be launched as a set of OSGi bundles (it is always possible to launch the server as a classic Java program).
  • Additional services can be started, stopped, reconfigured: Command line interface, Web console, etc.

Embedded server.
JORAM can be configured as a set of Plain Old Java Objects, it can therefore be embedded in any third party product and instantiated directly.

Configurable Client/Server communication system.
The JORAM Client/Server transport is configurable and extensible.
JORAM is shipped with multiples transport implementations:

  • In-VM transport - If client(s) and servers are running in the same Java virtual machine, then can be configured to use the InVM tranport which creates direct connections in code.
  • TCP or SSL transport - Clients and servers can be configured to communicate using standard TCP or encrypted sockets (using the Secure Sockets Layer - SSL).

Very high performance journal for message persistence.
JORAM provides message persistence using its own built-in high performance journal.
The JORAM persistence system is completely pluggable, it defines a Service Provider Interface (SPI) that you can implement in order to plug-in a new implementation.
JORAM is shipped with additionnal persistence modules using relational databases for example.

Fully pluggable transport system for communication between servers.
The JORAM low level transport is completely pluggable, it defines a Service Provider Interface (SPI) that you can implement in order to plug-in a new provider.
JORAM is shipped with multiples transport implementations:

  • TCP transport - Servers can be configured to communicate using standard TCP sockets.
  • SSL transport - Servers can be configured to communicate through encrypted TCP sockets using the Secure Sockets Layer (SSL).
  • HTTP(S) transport - Servers can be configured to communicate messaging traffic tunnelling over HTTP(S) requests and responses. This can be useful when you are running through a firewall.
  • UDP transport - Servers can be configured to communicate using UDP sockets.

Flexible distributed architecture, Load-Balancing and availability

Scalability and Distribution.
The combination of the Store and Forward facility with the use of a highly reliable MOM provides 100% guaranteed message delivery despite network transient failures or disconnected mode. The fully distributed message broker architecture enables a high level of scalability for JORAM systems.

Clustered destinations.
A destination, queue or topic, might be distributed among many servers. Such a logical destination is made of physical destination representatives on different servers. Such destinations allow both a higher degree of availability as well as bandwidth reduction on a wide area network basis.
Whereas a regular destination totally depends on the server it is deployed on, a clustered destination still works even when some of the servers it is deployed on are down.
This feature also allows to spread the inherent load of the transport and processing of messages on different servers, reducing the CPU load of each server and the network traffic between servers.

Master/Slave high availability server.
If you don't have an existing HA infrastructure, the JORAM Master/Slave configuration is a way for providing high availability and fault tolerance to your messaging solution.

Replication of data store and Failover via shared file system.
The data store of a live server can be replicated to a backup server, so in event of failure of the live server, the data is available immediately for a backup server. The backup server can be configured to start from the replicated data store in case of failure of backup server, thus making the service available.


Joram includes a distributed management and deployment infrastructure that will dramatically simplify your administration operations. It provides authentication, authorization, and encryption support that ensure the protection of your messages.

JMX support.
JORAM has extensive support for JMX allowing you to monitor and control the behavior of the broker through standard JMX Management facilities.

Administration API and management over JMS connection.
The management API is available using a standard JMS connection, by sending and consuming messages to and from a special JMS destination. It allows to remotely manage your distributed JORAM configuration through a simple JMS connection.
This is over and above the standard functionality available in the JMS 1.1 API which does not define a management API.

Administration and JMX monitoring Rest API
The Joram Administration Rest API allows you to use several administration features of Joram over a simple Rest/HTTP interface. For example this allows any web capable device to create User or Destination using a regular HTTP Post or Get request.
The Joram generic JMX Rest API allows you to expose the JMX Mbeans of the Joram server over a simple Rest/HTTP interface. For example this allows any web capable device to get and show Mbean's attributes using a regular HTTP request.

Programmatic creation of connection factories and JMS destinations.
Connection factories, JMS queues and topics can be created programmatically on client side.
You are not limited to looking up administered objects via JNDI as per JMS. They can be instantiated directly allowing you to remove JNDI from the equation if you do not want to use it.

XML based scripts for deployment and configuration.
Joram defines a XML scripting language for configuring your application. this allows the deployment of all the administered objects of your application without writing a line of code.

Administration console.
A user friendly interface based on GWT (Google Web Toolkit) is now available.

Management destinations.
Management destinations are special destinations producing monitoring messages like number of destinations, number of messages in a subscription, etc. You can subscribe to them using the normal JMS semantics.

Message counters and statistics.
JORAM message counters allow you to see a history of the messages that arrived in yours destinations or subscription over time. It defines several metrics above and beyond a simple message count.

Specialized destinations

Hierarchic topics.
Also known as "topic wild-cards", the idea is to build a hierarchical structure of topics.
The interest of such a structure is to allow a subscriber to specifically choose the type of information it is interested in, by allowing it to subscribe to the corresponding subtopic. For example you could create a topic subscriber on news.sports then it will receive all messages sent to and also
To be noted, a hierarchy may be spread over many servers, such a distributed architecture introduces flexibility and availability.

Dead message queue.
A dead message queue is a JMS Queue where a message gets sent when it can't be handled normally by the system. A dead message is a message considered as undeliverable for various reasons, for example:

  • The message can't be delivered after X number of retries.
  • The message expires before it is delivered to the client. Not only does JORAM guarantee it will never deliver an expired message to a consumer, it also has a configurable garbage collector that inspects queues in memory, weeding out expired messages and sending to expiry queues if appropriate.
  • The target destination does not exist or the sender does not have the writing right on this target destination.
  • The maximum number of messages in the queue has been reached or the message has been explicitly deleted on the destination or subscription (a maximum size for a queue or a subscription can be configured).

Dead message queue are highly configurable in JORAM - they can be configured either globally or individually (User, Destination or subscription).

Scheduled queue.
A scheduled queue allows to specify time in future when you want message delivered. The message won't get delivered until then.

Pluggable acquisition / distribution bridge.
Queue and Topic implements an extension framework for data acquisition (create JMS message from external data), and data distribution (create external data from JMS message). JORAM is shipped with various acquisition / distribution modules:

  • JMS acquisition / distribution (JMS bridge), 100% once and only once delivery is guaranteed with a JMS bridge without having to resort to more heavyweight solutions such as JTA (XA). The last implementation (5.5) allows load-balancing and fail-over through multiples JMS providers.
  • AMQP acquisition / distribution (AMQP bridge since 5.4), the implementation allows load-balancing and fail-over through multiples AMQP providers with a 100% once and only once delivery guaranteed.
  • Mail acquisition / distribution,
  • URL acquisition,
  • JMX acquisition,
  • FTP acquisition / distribution.

Interoperability and extensibility

Support for multi-language clients.
Joram offers a "JMS like" API for C and C++ clients, additionnaly JORAM can be accessed by clients in many different languages by using Stomp Connect.
JORAM supports the AMQP v0.9.1 specification, later releases of JORAM will provide full AMQP v1 support allowing access natively by clients written in many different languages.

JMS 2.0 Rest API plugins
The Joram JMS 2.0 generic Rest API allows you to leverage the features of Joram/JMS over a simple Rest/HTTP interface. Messages are produced and consumed through simple HTTP messages, this allows any web capable device to publish or consume messages using a regular HTTP Post or Get request.

JMS bridge and others.
This allows you to bridge between JORAM and any other JMS 1.1 compliant provider. This generic gateway allows JORAM applications to interoperate seamlessly with foreign applications running on any JMS compliant messaging service. Additional gateways are also available with AMQP, the SMTP mail system and with the FTP file transfer. Bridges are highly configurable.

Queue and Topic implement an extension framework for data acquisition (create JMS message from external data), handling, transformation, and data distribution (create external data from JMS message). The agent API, available besides the pure JMS API, allows the rapid development of complex distributed applications while ensuring full interoperability with JMS applications.


Transparent auto-reconnection of JMS clients.
Clients can be configured to auto-reconnect to servers when they become unavailable, e.g. due to a temporary network problem. Reconnection can be configured with retry-interval, it includes an heart-beat mechanism to detect network failures.
Needed data is safely resent in case of failure without running the risk of lost or duplicate messages.

Automatic reconnection for inbound connections in JCA Resource Adapter.
Inbound connections will be destroyed and reconnected, if the connection that receives the messages fails. This mechanism allows transparent fail-over for MDBs when the JMS provider become unavailable, e.g. due to a temporary network problem or perhaps the server is being rebooted or has crashed.

Configurable message buffering.
Consumers can be configured to buffer messages on the client side to give optimal performance. This can also be disabled to give deterministic distribution of messages in a queue with multiple consumers.

Producer flow control.
JORAM provides a flow control mechanism to prevent clients overwhelming a server with messages. On a per connection basic you can specify the maximum rate, that a producer is allowed to send messages at.

Implicit acknowledge mode.
With implicit acknowledge mode, messages are acked before delivery, thus avoiding having to ack from the client side and reducing the overall traffic on the wire.

Non blocking sends.
JORAM can be configured to either send messages blocking or non blocking. With a blocking send (default) the call to send() will not return until the message has reached the server.

Pluggable JMS and MOM interceptor.
JORAM defines an interceptor mechanism allowing to transparently process incoming and outgoing messages through JMS sessions.
A similar interception mechanism is available for processing messages in the MOM. Interceptors can be located on destinations and on connection in/out channels.


JORAM performances are dependent on the target architecture: hardware (CPU, Memory, Disk), network, operating system and JVM.
They also differ depending on many factors:

  • the type of JMS destination used: Queue or Topic,
  • the communication link between the client and the server: In-VM, TCP, etc
  • the quality of service requested and the size of messages,
  • the number of clients: producers and consumers.

When running the JORAM server on a laptop (Intel Core i7 1.8Ghz) and a single producer and consumer client in separate VMs on the same box, using a single topic we got around 25,000 messages per second using JMS messages with a payload of 500 bytes.
To obtain an indication of what kind of performance you can expect from JORAM, the distribution includes a set of tests you can run easily on your hardware architecture (a simple tutorial shows the use of these tests here).

Copyright © 1999-2018, OW2 Consortium | Contact | Webmaster | Last modified at 2023-11-30 07:27 AM