HJB - the HTTP JMS Bridge
HJB provides access to JMS resources via HTTP. It provides a
REST API equivalent of the JMS 1.1 API, making it possible to
perform JMS operations by accessing JMS objects as REST
resources via HTTP.
HJB
- is language-neutral: it will allow the writing of software
libraries for communicating with JMS providers in any language that
has libraries for communicating over HTTP.
- E.g., it allows Python programs to communicate with arbitrary JMS
providers via PyHJB, the python client library for HJB
- is RESTful: it provides a RESTful equivalent to all of the
non-optional portions of the JMS 1.1 API including
- registration of resources administered by the messaging provider
- connection and session management
- sending and receipt of all types of JMS message
HJB
is deployed as a servlet (HJBServlet), that can run on any servlet
container compliant with version 2.4 of the Java Servlet
specification.
will work with any messaging vendor that provides a JMS 1.1
interface.
aims to do one thing well. Its role is to act as an HTTP gateway
server allowing access to JMS objects as REST resources. Other
potentially useful features are deliberately excluded, e.g,
- HTTP session management
- authentication and authorization
These can be added by using other HTTP servers in the HTTP request
processing chain, e.g, another servlet, Apache httpd, Zope,
RubyOnRails, AddYourFavouriteWebServer here.
- aspires to make the best possible use of the HTTP protocol, and to
be a thin, transparent layer so that there is very little obtruding
between HJB client code and the JMS API. E.g,
- success or failure of each request is indicated by the HTTP
response code,
- a descriptive status of each request is returned to the HTTP user
agent in the response header,
- status messages are detailed, clear and fully internationalized,
- all faults are logged on the server and match the status messages
returned to the user agent.
Copyright © 2006 Tim Emiola. All rights reserved.