Nigel,
Yes, I was thinking about defining a REST/HTTP interface for the subset of the API - Transactionality and ordering of messages etc. is not important to expose via this interface. I was thinking of exposing basic Restful resources : A Queue, A topic, sending and receiving messages to them, specifying a subscription (a filter condition) and preferences for message delivery - pull Vs push (using callback endpoints, websockets or otherwise). In addition a management and monitoring interface as well. Specifying the QoS (best effort/real-time, at-least-once and at-most-once semantics).
What I mean by "embeddable mode" friendly is that the JMS server should have a embeddable mode option, in which the Restful resources implementation can make local java calls to the embedded JMS server without going through the network. There already is a network hop through HTTP and we want to avoid a second hop.
Sastry
________________________________
From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr343-experts_at_jms-spec.java.net
Sent: Monday, March 5, 2012 3:17 AM
Subject: [jsr343-experts] Re: (JMS_SPEC-7) Provide HTTP Binding
Sastry,
Thanks for your comments.
As you say, stateful JMS concepts such as connections and sessions
are difficult to express in a HTTP/REST interface. The same applies
to the JMS concepts of transactions and client acknowledgement.
Were you thinking of a HTTP/REST interface which mapped onto a
subset of existing JMS functionality (e.g. no message order
guarantees, no transactions) or do yo think we need to define some
new concepts in JMS which map more easily to a internet environment,
such as new QoS options?
You also mention "embedded mode". Can you clarify what you mean by
this, and what kind of changes would be needed to make JMS
"embeddable mode" friendly?
Thanks,
Nigel
On 05/03/2012 07:16, Sastry Malladi wrote:
Hi,
>I'm sorry for being silent so far on the mailing list. I've recently joined the expert group (in Jan) - I'm am an Architect at eBay driving the eBay middleware platform, including
>a next gen messaging platform.
>
>
>In the internet world, the messaging systems tend to serve a more "disconnected world" - meaning that there is no concept of a "connection" or "session" to the broker - Applications just publish and receive messages (millions of them) at will, with different QoS and delivery channels. These applications are also typically polyglot (written in multiple different languages) and almost always use HTTP/REST to communicate, although the likes of SPDY and Websockets are also partly in use and upcoming.
>
>
>Although this JSR is for Java API for messaging, I'd still strongly request you to consider including an HTTP, more importantly a simple REST interface to the messaging API, for wider adoption. We don't have to make implementing the REST interface mandatory for compliance, but I bet most providers will implement, as the world is moving towards that direction. This is what we are doing as well. The REST service implementation may choose to use the underlying Java API in embedded mode, so we need to make sure the Java API is "embeddable mode" friendly.
>
>
>thanks,
>
>Sastry
>
>
>
>
>________________________________
> From: Nigel Deakin <nigel.deakin_at_oracle.com>
>To: jsr343-experts_at_jms-spec.java.net
>Sent: Friday, March 2, 2012 8:44 AM
>Subject: [jsr343-experts] (JMS_SPEC-7) Provide HTTP Binding
>
>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
>
>
>