Nigel,
I fully understand, although I'd love to see this standardized in the current JSR.
I can send out a short proposal with examples when I'm back (I've a current implementation, just need to prepare the gist and send) - John Harby also indicated that he could help out on the proposal as well.
thanks,
Sastry
________________________________
From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr343-experts_at_jms-spec.java.net
Sent: Wednesday, April 4, 2012 4:15 AM
Subject: [jsr343-experts] Re: [jms-spec users] Re: (JMS_SPEC-7) Provide HTTP Binding
Sastry,
My personal feeling is that a HTTP REST interface is such a large
feature that this might have to wait for the next version of JMS, or
perhaps be taken forward in a separate JSR. However I don't want to
close down discussion on the subject and would welcome the EG having
an opportunity to discuss this issue (you'll have seen my separate
email asking EG members to list which possible new features they
would like to discuss - I presume this would be *your* priority).
Although I am asking for a "proposal", I'm thinking of something
fairly short and high-level (and perhaps with a few examples) that
will help us understand what type of API we're talking about and
what it might be used for. I'm not asking for a fully-worded out
specification.
Thanks,
Nigel
On 30/03/2012 18:47, Sastry Malladi wrote:
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
>>>
>>>
>>>
>>
>>
>
>