I agree that we need to have a concrete proposal and I don't mind volunteering to work on such a proposal - The only catch is I'm going on a sabbatical for 1 month starting next week and if it still helps, I can put a proposal together after I get back, if timelines match.
You are correct that someone can just implement the HTTP REST interface only and re-use some existing JMS provider and in fact, I'm currently implementing such a provider. So from a compliance perspective, implementing either interface or both should be allowed.
So, if you think there is a possibility that we will add this to the current spec, then I can work on a proposal when I get back. Let me know.
thanks,
Sastry
________________________________
From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr343-experts_at_jms-spec.java.net
Sent: Wednesday, March 28, 2012 7:58 AM
Subject: [jms-spec users] [jsr343-experts] Re: (JMS_SPEC-7) Provide HTTP Binding
(Sorry for the delay)
Yes, this all sounds very interesting. I think what this needs is
for one or more individuals to take this forward to the next level
of detail - perhaps listing the various JMS functions it would
support and what kind of HTTP action/request/callback this would
correspond to. Even if this doesn't make it into JMS 2.0 (and we are
all still deciding priorities - see separate email) it would be
really great to have one or more proposals on the table.
Effectively we'd be defining the API for a web application which
could use the normal JMS (Java) API to communicate with the actual
JMS provider (at least for the reference implementation). So we
would probably want to allow people to implement it and become
spec-compliant without the need to implement the JMS provider as
well (and vice versa). We might decide that this is best achieved
as a separate JSR but I'm happy to treat it within the scope of JMS
for now.
Whether or not a Java EE application server would be required to
support the HTTP interface could be considered separately. That
would be something to discuss with the Java EE expert group at a
later stage.
You mentioned "local calls to the embedded JMS server". I know that
some JMS providers do allow the JMS "server" to be embedded in the
same JVM as the application, and provide a JMS API which uses method
calls rather than the network to communicate with it. However not
all do and this is not required by the spec. So we'd probably need
to leave it to the individual HTTP protocol implementation to decide
whether to take advantage of such a feature for a particular JMS
provider.
Nigel
On 06/03/2012 05:40, Sastry Malladi wrote:
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
>>
>>
>>
>
>