search

jakartaee / messaging

Jakarta Messaging
https://eclipse.org/ee4j/messaging
Other
41 stars 33 forks source link

Support for AMQP messaging #9

Open glassfishrobot opened 13 years ago

glassfishrobot commented 13 years ago

http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol

AMQP adds support for a number of the same things that JMS supports today, and adds to that model. I believe that by JMS 2.0 supporting the AMQP model it allows for cross-system integration, as well as cross-language integration.

glassfishrobot commented 6 years ago
glassfishrobot commented 13 years ago

@glassfishrobot Commented Reported by genomeprjct

glassfishrobot commented 13 years ago

@glassfishrobot Commented clebertsuconic said: AMQP (as the name says) it's a protocol.

I don't think many providers will like the idea on having them implement any given protocol as part of the JMS spec.

glassfishrobot commented 13 years ago

@glassfishrobot Commented tom.barnes said: If we want to strengthen the JMS API interop story with projects like AMQP, I think we should consider (A) adding to the specification so that it forms a superset of AMQP capabilities, and (B) spinning-off a seperate specification for C and .NET APIs.

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: I think AMQP needs to be taken into consideration in JMS 2.0, even though it should continue not to require a specific wire protocol.

For a start, you shouldn't need to use a vendor API to define which wire protocol must be used by a connection factory.

I don't think we need to create JMS bindings for other platforms, which AMQP allows to continue to have whatever API they want.

glassfishrobot commented 13 years ago

@glassfishrobot Commented clebertsuconic said:

Lets add stomp then!
glassfishrobot commented 13 years ago

@glassfishrobot Commented clebertsuconic said: Let me explain my sarcasm:

Protocols are part of design choices. They are the secret sauce sometimes on the message system.

You start to infer how a message system will have to be implemented.. you start to lose attraction to this specification.

I believe in interoperability, but I don't think the JMS API is a place to define wire protocol or implementation specifics on configuration.

I believe wire protocol is beyond the scope of the proposed draft anyway. And I don't see anything needed at the API level.

If there's something that can be done at API in a generic fashion... then lets do it.. but you would need to make a concrete proposition instead of an abstract approach on supporting AMQP.

That's just IMO anyway.

I will let other expert members to chime in on this subject

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: Again, I think the spec should continue not to specify a wire protocol, but I don't think it is a bad thing to look at the new protocol and see if there is anything that we can do in the API to make it easier to implement JMS on top of AMQP.

Regarding STOMP, since the API has been implemented on top of it as well (http://stomp.codehaus.org/Stomp+JMS), I really think it should receive the same whatever treatment we choose to give to AMQP.

glassfishrobot commented 13 years ago

@glassfishrobot Commented bsnyder said: I had a long discussion with Nigel a couple weeks ago regarding my interest in AMQP and STOMP and seeking better points of supporting various wire-level formats underneath the JMS API. I don't believe that the JMS spec should specify a wire-level format, but I do agree that we should understand these formats enough to make sure that the JMS APIs can accommodate them. The same can be said for WebSockets. I've received questions about all of these technologies and how best to use and/or integrate JMS with them. I think it would be worthwhile for this group to discuss this topic and provide some support and possibly examples.

This is another topic regarding integration. I'm seeing a theme here .

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: Agreed.

glassfishrobot commented 13 years ago

@glassfishrobot Commented timlfox said: 1) The AMQP model from 0.8/0.9/0.10 is not rich enough to support JMS. The only implementation that does do "JMS over AMQP" (Qpid), IIRC can only do so by introducing extensions over and above that specified by AMQP. So, JMS over AMQP is really a myth. With AMQP 1.0 there isn't a broker model at all! So this is really a non started unless the AMQP spec changes considerably

2) AMQP as a protocol is far too verbose and clunky to create high speed JMS implementations. The high performers in the JMS space, e.g. TibcoEMS, HornetQ, SonicMQ etc owe a lot of their performance to highly optimised wire protocols. They would have to sacrifice that performance if they were to transport over AMQP. Why would they want to do this?

3) So far, interoperability between implementations (the raison d'etre) of AMQP has largely been a fantasy. Perhaps this will change with 1.0, if enough systems implement it. Also, as mentioned before, AMQP 1.0 does not specify a broker model so if interoperability occurs, it's scope is very limited and certainly not enough to support JMS semantics.

glassfishrobot commented 13 years ago

@glassfishrobot Commented rdohna said: I agree that we should take a look at AMQP and STOMP and maybe other wire protocolls in order to learn, but not endorse any of them for the JMS spec... that's a completely separate snake pit that we should avoid to get into.

BTW: RabbitMQ supports AMQP and JMS, doesn't it?

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: Let me respond to Tim's comments in particular.

1) I think we should look at these "extensions over and above" to see if we can change anything in JMS 2.0 to make it easier to use JMS on top of AMQP (which is the purpose of this issue).

2) Again, the suggestion is not that they drop their stuff for AMQP (or STOMP, for that matter).

3) AMQP remains as the most successful attempt of interoperability in MQ systems, including with platforms other than Java EE, and should be supported.

glassfishrobot commented 13 years ago

@glassfishrobot Commented timlfox said:

1) I think we should look at these "extensions over and above" to see if we can change anything in JMS 2.0 to make it easier to use JMS on top of AMQP

If you wanted to make JMS really work over AMQP, you would need to make the changes in AMQP, not JMS 2.0. The correct place for recommending such changes would be the AMQP working group, not the JCP.

3) AMQP remains as the most successful attempt of interoperability in MQ systems, including with platforms other than Java EE, and should be supported.

What's your measure of success? If you measure success by the number of messaging systems that really interoperate then STOMP is the most successful example of messaging interoperability so far.

Don't get me wrong, I think AMQP has it's place. The 0.9.1 spec is a good solid spec for implementing a message broker, the excellent RabbitMQ is a case in point. But AMQP is not rich enough to support JMS semantics, and AMQP 1.0 shows no sign of improving in that area (in fact AMQP 1.0 doesn't provide any broker semantics at all), so going down that road is likely to result in a dead-end.

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: I was really referring to the fact that Microsoft is in the AMQP game, but I really don't think we should discuss the merits of the new protocol too much, but rather only find out if any experiences when implementing JMS on top of AMQP called for improvements to the API.

It has also been mentioned here that adding protocol metadata would be a good idea and perhaps a new separate "generic" issue should be created for it.

One more thing to discuss here seems to be whether the specification should define how to select the wire protocol in use, given that more libraries can should to support two or more protocols in the future, what do you think about that?

glassfishrobot commented 13 years ago

@glassfishrobot Commented rdohna said: The improvement to JMS could be that we'd have to define profiles, so some messaging system can conform only to a defined subset of JMS... e.g. without support for stream messages.

I think the wire protocol should be kept completely out of JMS. If an implementation can handle more than one, the admin should have to configure it, probably for the queue (with useful defaults).

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: The profile idea sounds good, perhaps you should open a separate ticket for it (you have my vote there!).

Regarding the wire protocol, I wouldn't like to be required to use the API of a specific vendor to specify it, maybe there should be a standard way to configure it in the connection factory, how about that?

glassfishrobot commented 13 years ago

@glassfishrobot Commented rdohna said: Why would you want to configure something like this in your code? You may even want to deploy your software in different environments with different messaging providers and different wire protocols. I think this should be the job of the admin creating the destination, while the programmer should concentrate on other things... like the business code.

glassfishrobot commented 13 years ago

@glassfishrobot Commented fribeiro said: That's probably the right thing, my bad, should be a configuration option in the provider, are the names/default values of such options out of the scope of the spec?

glassfishrobot commented 13 years ago

@glassfishrobot Commented abien said: Could you add a concrete example, what is to change in JMS?

glassfishrobot commented 12 years ago

@glassfishrobot Commented @nigeldeakin said: AMQP is a wire protocol, and I think there's a general consensus that JMS should remain as an API and shouldn't define a wire protocol.

However AMQP is clearly a prominent and successful standard and it's definitely within the scope of JMS to consider whether new JMS features would make it easier for vendors to implement JMS providers that use AMQP as a wire protocol.

I think what we need to take this issue forward is some concrete proposals as to what this might involve. Without specific proposals this will remain just an expression of desire.

So please take this as an invitation to make some proposals. Depending on the scale of changes proposed, these could be for JMS 2.0 or a later revision.

Tagging for review by the expert group.

glassfishrobot commented 11 years ago

@glassfishrobot Commented fribeiro said: You may want to go ahead and close the issue.

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-9

OndroMih commented 2 years ago

The bottom line is that we could create a new lite messaging profile that would support AMQP or STOMP. In other words, it would be easy enough to implement such profile over the AMQP or STOMP protocol and pass the TCK of the lite profile.

What remains is to investigate which requirements of the Messaging simple API are hard to implement over AMQP and STOMP and how the lite profile should relax the requirements for AMQP and STOMP protocols.