Hi Nigel,
I understand if you feel this is a bit too adventurous at this
point. There are a couple of implementations out
there in ActiveMQ - jsr343-experts_at_jms-spec.java.net and HornetQ -
http://docs.jboss.org/hornetq/2.2.2.Final/rest-interface-manual/html/ch09.html
Perhaps we could start with something very simple that could be
expanded in later versions?
Thanks,
John Harby
On Wed, Apr 4, 2012 at 4:57 PM, Sastry Malladi <m_sastry_at_yahoo.com> wrote:
> 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> <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> <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> <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
>
>
>
>
>
>
>
>
>