JMS extension

Introduction

This page will document some requirements and high-level design ideas regarding a future JMS connector. This is related to RFE #175.

The purpose of JMS is to help Java developers that want to create, send, receive, and read messages. Its main characteristics are:

  • Loosely-coupled
  • Asynchronous
  • Reliable

For more details, we recommend reading the JMS tutorial. This way of communicating maps particularly well to the REST/HTTP semantics and especially the PUT/POST/GET/HEAD verbs.

Requirements

The overall goal is to integrate the JMS API with the Restlet API.

  • Provide a client connector that lets a developer connect to a provider
  • Send messages to a queue or to a topic
  • Receive messages from a queue or from a topic and being able to process them

Analysis

Notes

  • Connection -> Session -> Message Producer / Message Consumer / Message (creation)
  • Synchronous or asynchronous consumption
  • Message selector to filter -> server parameters
  • Associated JNDI namespace (destinations, connection factories)
  • Domains (point-to-point -> queue, publish-and-subscribe -> topic)
  • Message (header -> values like correlation ID, [properties], [body -> text / map / bytes / stream / object message])

References

Design

Common aspects

  • A new "jms://" scheme should be defined, with either "queues" or "topics" as the authority part.
  • Exemple: "jms://queues/myParent/myQueue". Note that there is an existing effort to define a JMS URI scheme, but I'm not sure if it will be the best/simplest mechanism for us.

Server connector

Here are some initial design thoughts:

  • Server connector should be able to be instantiated with a "Protocol.JMS" constant.
  • Parameters would be used to specify the queue(s) or topic(s) to connector to or to subscribe to.
  • A MessageRepresentation class would wrap the JMS Message one
  • A mapping between MessageRepresentation and a streamable representation format would be defined (XML, multi-part?)

Example to create a new JMS server connector inside a parent Component:

Server jmsServer = getServers().add(Protocol.JMS);
Series<Parameters> params = jmsServer.getContext().getParameters();
params.add("queue", "myParent.myQueue1");
params.add("queue", "myParent.myQueue2");
params.add("topic", "myParent.myTopic");

Client connector

  • A JMS client connector could act as a queue sender (PTP) or as a topic publisher (pub/sub)
  • A JMS target resource would be identified using a JMS URI, naming a unique queue or a unique topic.
  • The method to send and publish could be Method#POST, reusing the known HTTP semantics.
  • In addition, we could consider adding JmsMethod#SEND and JmsMethod#PUBLISH methods for a more direct mapping to JMS terminology.
  • A connection pooling for the client connector might become necessary as connection creation can be an expensive operation.
Comments (0)