I refer to this JIRA issue logged by fribeiro in June 2011.
Provide HTTP Binding
http://java.net/jira/browse/JMS_SPEC-7
"If none is available from another organization, I think the JCP should provide (maybe in a separate JSR) a standard
HTTP binding for JMS, given how often these technologies are used together."
A discussion took place in the comments on that issue between the proposer and various EG members. I'd like to bring
that discussion to the EG properly so we can formally decide how to handle this.
I think that this proposal is is essentially proposing that JMS defines some kind of HTTP binding (protocol, really) to
a JMS provider. I can well imagine that this is a common requirement: I know at least two JMS providers that provide a
HTTP protocol and I'm sure there are others.
I think there are a number of issues here:
1. Whether a standard HTTP protocol to JMS is required
2. If so, whether it belongs in JMS or in some other specification
3. Whether there is scope to enhance the existing JMS (Java) API to make it easier to deliver a HTTP binding
Defining a standard HTTP protocol sounds, on the face of it, a good idea. It would be necessary to decide what JMS
features could be made available using HTTP - some, like message order or transactions, would probably rely on the
concept of there being some kind of client state maintained between requests.
Then there's the question of whether this is should be defined as part of JMS, as a separate JCP specification, or under
the auspices of some other body.
As a general rule the JCP is "for developing standard technical specifications for Java technology", but defining a HTTP
protocol for JMS is certainly not out of the question. Some would probably recommend that it be defined at OASIS, or
even IETF. But if it needs to align strongly with the Java API then that might be enough justification to develop it as
part of JMS.
We would need to consider what the compatibility requirements would be for the HTTP protocol? Would all JMS products be
required to include a REST server that supported the protocol?
We would also need to consider where the HTTP protocol would sit the JMS architecture. Would the JMS server support the
HTTP protocol or would we be defining a separate server that accepted HTTP requests and translated them to the native
network protocol for the JMS server, perhaps by just translating them into JMS API calls?
My feeling is that we would never want to make it mandatory for a JMS provider to directly support the HTTP protocol,
and that it should be possible to implement it as a separate component interfacing with the JMS provider using the
standard JMS API (if it requires proprietary API then it isn't really a JMS binding). This suggests to me that this
belongs in a separate JSR.
I'm also mindful that this would be a significant piece of work and there's not going to be time to deliver in the JMS
2.0 timescales in any case.
So my proposal is that we take the decision to not attempt to define a HTTP protocol for JMS 2.0. We can leave the issue
open, but it is likely that a HTTP protocol would need to be delivered as a separate JSR.
Discussion welcome.
Now let's consider the point (3) above, whether there is scope to enhance the existing JMS (Java) API to make it easier
to deliver a HTTP binding. I think the answer to this is definitely yes, and we welcome proposals. (I think we already
have one in JMS_SPEC-5, which we'll discuss separately, and there may be others).
Nigel