JBoss Messaging core is a completely JMS-agnostic messaging system with its own core API.
If you don't want to use JMS you can use the core API directly. The core API provides all the functionality of JMS but without much of the complexity. It also provides features that are not normally available using JMS.
Some of the core messaging concepts are similar to JMS concepts, but core messaging concepts differ in some ways. In general the core messaging API is simpler than the JMS API, since we remove distinctions between queues, topics and subscriptions. We'll discuss each of the major core messaging concepts in turn, but to see the API in detail, please consult the Javadoc.
A message is the unit of data which is sent between clients and servers.
A message has a body which is effectively a byte[], it also has a set of properties which are key-value pairs. Each property key is a string and property values can be of type integer, long, short, byte, byte[], String, double, float or boolean.
A message has a destination which represents the address it is being sent to. When the message arrives on the server it is routed to any queues that are bound to the address. An address may have many queues bound to it or even none.
Messages can be either durable or non durable. Durable messages in a durable queue will survive a server crash or restart. Non durable messages will never survive a server crash or restart.
Messages can be specified with a priority value between 0 and 9. 0 represents the highest priority and 9 represents the lowest. JBoss Messaging will attempt to deliver higher priority messages before lower priority ones.
Messages can be specified with an optional expiry time. JBoss Messaging will not deliver messages after its expiry time has been exceeded.
Messages also have an optional timestamp which represents the time the message was sent.
A server maintains a mapping between an address and a set of queues. Zero or more queues can be bound to a single address. Each queue can be bound with an optional message filter. When a message is routed to an address it is routed to the set of queues bound to the message's destination address. If any of the queues are bound with a filter expression, then the message will only be routed to the subset of bound queues which match that filter expression.
In core, there is no concept of a Topic, Topic is a JMS only term. Instead, in core, we just deal with addresses and queues.
For example, a JMS topic would implemented by a single address to which many queues are bound. Each queue represents a subscription of the topic. A JMS Queue would be implemented as a single address to which one queue is bound - that queue represents the JMS queue.
Queues can be durable, meaning the messages they contain survive a server crash or restart, as long as the messages in them are durable. Non durable queues do not survive a server restart or crash even if the messages they contain are durable.
Queues can also be temporary, meaning they are automatically deleted when the client connection is closed, if they are not explicitly deleted before that.
Queues can be bound with an optional filter expression. If a filter expression is supplied then the server will only route messages that match that filter expression to any queues bound to the address.
Many queues can be bound to a single address. A particular queue is only bound to a maximum of one address.
Clients use ClientSessionFactory instances to create ClientSession instances. ClientSessionFactory instances know how to connect to the server to create sessions, and are configurable with many settings.
A client uses a ClientSession for consuming and producing messages and for grouping them in transactions. ClientSession instances can support both transactional and non transactional semantics and also provide an XAResource interface so messaging operations can be performed as part of a JTA transaction.
ClientSession instances group ClientConsumers and ClientProducers.
Clients use ClientConsumer instances to consume messages from a queue. Core Messaging supports both synchronous and asynchronous message consumption semantics. ClientConsumer instances can be configured with an optional filter expression and will only consume messages which match that expression.
Here's a very simple program using the core messaging API to send and receive a message:
ClientSessionFactory nettyFactory = new ClientSessionFactoryImpl(
new TransportConfiguration(
InVMConnectorFactory.class.getName()));
ClientSession session = nettyFactory.createSession();
session.createQueue("example", "example", true);
ClientProducer producer = session.createProducer("example");
ClientMessage message = session.createClientMessage(true);
message.getBody().writeString("Hello");
producer.send(message);
session.start();
ClientConsumer consumer = session.createConsumer("example");
ClientMessage msgReceived = consumer.receive();
System.out.println("message = " + msgReceived.getBody().readString());
session.close();