Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        bsnyder added a comment -

        This is exactly what I meant with my comment in JMS_SPEC-5. Providing specifications for binding JMS to other various technologies would really help out users.

        Show
        bsnyder added a comment - This is exactly what I meant with my comment in JMS_SPEC-5 . Providing specifications for binding JMS to other various technologies would really help out users.
        Hide
        clebertsuconic added a comment -

        Maybe a new message type? for this and spec-5?

        Show
        clebertsuconic added a comment - Maybe a new message type? for this and spec-5?
        Hide
        fribeiro added a comment -

        I like the idea of a new message type for HTTP but think it is complementary, not supplementary, to a standard mapping between HTTP and JMS.

        Vendors have long used non-standard things like "HTTP-Content-Type", for example, that make it difficult to integrate with other systems.

        Show
        fribeiro added a comment - I like the idea of a new message type for HTTP but think it is complementary, not supplementary, to a standard mapping between HTTP and JMS. Vendors have long used non-standard things like "HTTP-Content-Type", for example, that make it difficult to integrate with other systems.
        Hide
        rdohna added a comment -

        I don't quite understand. HTTP is a synchronous protocoll, JMS is asynchronous. What is the use case to transport an HTTP request via JMS? Load balancing? Routing? Pipes-And-Filters? Any of the EAI patterns? Can't you do these things with plain vanilla EJBs, for example? And the programming model would be much simpler, wouldn't it?

        Show
        rdohna added a comment - I don't quite understand. HTTP is a synchronous protocoll, JMS is asynchronous. What is the use case to transport an HTTP request via JMS? Load balancing? Routing? Pipes-And-Filters? Any of the EAI patterns? Can't you do these things with plain vanilla EJBs, for example? And the programming model would be much simpler, wouldn't it?
        Hide
        fribeiro added a comment -

        I've seen HTTP being properly used more than once to allow communication from platforms without JMS client libraries, for example, not to mention a HTTP request may need to be transformed to JMS as explained in my most recent comment in JMS-SPEC-9.

        Show
        fribeiro added a comment - I've seen HTTP being properly used more than once to allow communication from platforms without JMS client libraries, for example, not to mention a HTTP request may need to be transformed to JMS as explained in my most recent comment in JMS-SPEC-9.
        Hide
        rdohna added a comment -

        Did I get your scenario right: You have some client that can't directly produce messages for your JMS system. You provide it a generic adapter that converts any http request into a JMS message. The adapter replies to the client as soon as the message is sent. You use some message routing to get the request to some service. If there is any feedback from the service to the client, it's in a separate channel. The important thing to note is that almost all HTTP header fields could be required for the routing, while the body is simply the HTTP body, i.e. eventually even binary.

        I'd prefer a direct feedback for the client, when the request is invalid. But you may have use cases where this is okay.

        So I guess that the binding this issue requests is to standardise the mapping of the HTTP field names to the JMS headers/properties, right? I assume most fields would just map one to one, but e.g. the first line would have to be split into properties for the method (e.g. GET), the path (e.g. "/"), and the protocol version (e.g. "HTTP/1.1").

        To cut a long story short, I think this is either a bridge between two different messaging solutions or just one specific application protocol. In both cases, I'd say that it should not be part of this spec.

        Show
        rdohna added a comment - Did I get your scenario right: You have some client that can't directly produce messages for your JMS system. You provide it a generic adapter that converts any http request into a JMS message. The adapter replies to the client as soon as the message is sent. You use some message routing to get the request to some service. If there is any feedback from the service to the client, it's in a separate channel. The important thing to note is that almost all HTTP header fields could be required for the routing, while the body is simply the HTTP body, i.e. eventually even binary. I'd prefer a direct feedback for the client, when the request is invalid. But you may have use cases where this is okay. So I guess that the binding this issue requests is to standardise the mapping of the HTTP field names to the JMS headers/properties, right? I assume most fields would just map one to one, but e.g. the first line would have to be split into properties for the method (e.g. GET), the path (e.g. "/"), and the protocol version (e.g. "HTTP/1.1"). To cut a long story short, I think this is either a bridge between two different messaging solutions or just one specific application protocol. In both cases, I'd say that it should not be part of this spec.
        Hide
        fribeiro added a comment -

        You got it right, and I can agree if doesn't necessarily fit in the JMS spec itself (which should perhaps focus only on the API), but, if not there, where do you think it should be standardized?

        Show
        fribeiro added a comment - You got it right, and I can agree if doesn't necessarily fit in the JMS spec itself (which should perhaps focus only on the API), but, if not there, where do you think it should be standardized?
        Hide
        rdohna added a comment - - edited

        I have no idea other that what you've suggested: Another JSR.

        But this issue should be closed, shouldn't it?

        Show
        rdohna added a comment - - edited I have no idea other that what you've suggested: Another JSR. But this issue should be closed, shouldn't it?
        Hide
        fribeiro added a comment -

        I can't do it myself and also want to wait for Nigel's comments about this matter, he can probably help with the new JSR or point me to another venue for that standard.

        Show
        fribeiro added a comment - I can't do it myself and also want to wait for Nigel's comments about this matter, he can probably help with the new JSR or point me to another venue for that standard.
        Hide
        abien added a comment -

        +1 for a separate spec.

        Show
        abien added a comment - +1 for a separate spec.
        Hide
        Nigel Deakin added a comment -

        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

        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.

        Irrespective of this, there may be scope to enhance the existing JMS (Java) API to make it easier to deliver a HTTP binding. I think we already have one in JMS_SPEC-5, and there may be others).

        Show
        Nigel Deakin added a comment - 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 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. Irrespective of this, there may be scope to enhance the existing JMS (Java) API to make it easier to deliver a HTTP binding. I think we already have one in JMS_SPEC-5 , and there may be others).
        Hide
        John Harby added a comment -

        I agree with Nigel that a thorough specification for this is probably not feasible for this release. We may want to consider a couple of items to add that would be basic common features of current REST/JMS implementations such as publishing use POST and consuming using DELETE or GET, etc. These could be specified for those who wish to support REST, not mandated for any JMS provider.

        Show
        John Harby added a comment - I agree with Nigel that a thorough specification for this is probably not feasible for this release. We may want to consider a couple of items to add that would be basic common features of current REST/JMS implementations such as publishing use POST and consuming using DELETE or GET, etc. These could be specified for those who wish to support REST, not mandated for any JMS provider.
        Hide
        fribeiro added a comment -

        You may want to go ahead and close the issue.

        Show
        fribeiro added a comment - You may want to go ahead and close the issue.
        Hide
        Nigel Deakin added a comment - - edited

        Comment noted - but I think this is an issue which deserves further discussion for a further version of JMS. So I'll leave this open. Tagging for review for 2.1.

        Show
        Nigel Deakin added a comment - - edited Comment noted - but I think this is an issue which deserves further discussion for a further version of JMS. So I'll leave this open. Tagging for review for 2.1.

          People

          • Assignee:
            Unassigned
            Reporter:
            fribeiro
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: