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
JORAM fully supports JMS 1.1, JMS 2.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 and JMS 2.0specification 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
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.
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.
Joram is designed with an OSGiTM based services architecture to provide a dynamically adaptable
- 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.
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
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
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
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.
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
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
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.
A user friendly interface based on GWT (Google Web Toolkit) is now available.
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
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.
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 news.sports.tennis and also news.sports.soccer.
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
- 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).
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
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
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
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).