Re: ActiveMQ can now support AMQP clients.
Brian McCallister wrote: On Oct 26, 2006, at 3:51 AM, Gordon Sim wrote: Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. Huh? Is this referring to Hiram's patches which work to decouple the code to make it more easily reusable? Yes, though it was not intended in any derogatory sense. Due to the nature of the code the changes required to integrate into active mq resulted in two incompatible branches (e.g. we can't use the Data-Input/Output interfaces, you can't use the mina ByteBuffer). James has already clarified that it should be viewed more as an experimental branch to highlight the areas that would need to be refactored to allow cleaner reuse. I would strongly advise against preferring less reusable code in order to make it more difficult for people to reuse the code and "guard" against forks. Forks are usually social phenomena, not technical. I'm not sure what part of my mail gave you the impression that that was my aim, but can assure you that it is not. To repeat what I tried to say earlier: I recognise that its valuable to make as many parts of the qpid codebase reusable from other projects as possible and I accept that is not the case now.
Re: ActiveMQ can now support AMQP clients.
James Strachan wrote: On 10/26/06, Gordon Sim <[EMAIL PROTECTED]> wrote: I agree, sharing code is ideal. The qpid proposal included reusable libraries as an objective and this seems sensible in the effort to promote AMQP and interoperability. Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. Note I wouldn't call this a fork; its just an early experimental spike to see how much of the qpid code needs to be changed to be usable in ActiveMQ. I stand corrected. The intention is to refactor and reuse as much qpid code as possible (assuming the qpid project accepts those refactors) and work with the qpid community to ensure we have one codebase for AMQP framing where possible. A fork is only a last resort when you can't work with a community after trying all other possibilities. Now we have the spike working, we can step back and compare the two sets of qpid framing code to see if we can refactor things into one library we can share (hopefully) - or at least find the common bits we can share; maybe one common core with 2 optional parts (for MINA v anything else). Yes, I am in full agreement with that approach.
Re: ActiveMQ can now support AMQP clients.
Brian McCallister wrote: On Oct 26, 2006, at 3:51 AM, Gordon Sim wrote: Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. Huh? Is this referring to Hiram's patches which work to decouple the code to make it more easily reusable? no idea, however having had a look at what Hiram did I would recommend that we get the new code generators in as they change a bit in this area, and then see which items map into that -- less rework. I would strongly advise against preferring less reusable code in order to make it more difficult for people to reuse the code and "guard" against forks. Forks are usually social phenomena, not technical. -Brian
Re: ActiveMQ can now support AMQP clients.
On Oct 26, 2006, at 3:51 AM, Gordon Sim wrote: Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. Huh? Is this referring to Hiram's patches which work to decouple the code to make it more easily reusable? I would strongly advise against preferring less reusable code in order to make it more difficult for people to reuse the code and "guard" against forks. Forks are usually social phenomena, not technical. -Brian
Re: ActiveMQ can now support AMQP clients.
On Oct 26, 2006, at 3:13 PM, John O'Hara wrote: James It would be really useful if you would answer my question about code sharing from Apache ActiveMQ into Apache Qpid too, please. I could do with some mentoring in this. Short form, is please by all means reuse anything that is useful (as mentioned in my previous email). Long form is that if there are chunks of code which can be made into standalone utility libraries, that is generally preferable to copy & paste reuse. -Brian
Re: ActiveMQ can now support AMQP clients.
On Oct 26, 2006, at 3:54 AM, John O'Hara wrote: Also, I wanted to ask you in your capacity as Mentor, in the Apache family would it be cool to re-use code from ActiveMQ in Qpid where that makes sense? Please do, if it will help in any way! Please also let us know, also, if there is anything that would be helpful to extract into jakarta-commons, which is basically a repo for little libraries used between various projects. -Brian
Re: ActiveMQ can now support AMQP clients.
James It would be really useful if you would answer my question about code sharing from Apache ActiveMQ into Apache Qpid too, please. I could do with some mentoring in this. Many thanks John On 26/10/06, James Strachan <[EMAIL PROTECTED]> wrote: On 10/26/06, Gordon Sim <[EMAIL PROTECTED]> wrote: > James Strachan wrote: > > The desire is to share code - partlcularly the low level Qpid framing > > code. We're all Apache folk afterall and projects are meant to work > > together & share code where it makes sense to do so. > > > > Ideally qpid and ActiveMQ would share a large chunk of ocde for the > > AMQP framing stuff; though right now its hard to do that as qpid is > > not terribly easy to reuse and is based on MINA and ActiveMQ has its > > own transport framework. > > I agree, sharing code is ideal. The qpid proposal included reusable > libraries as an objective and this seems sensible in the effort to > promote AMQP and interoperability. > > Right now the feedback seems to be that the code is mainly useful as > 'seed' code for a fork. Forks are clearly not ideal as they dilute the > collective effort, but sometimes they may be inevitable due to different > long term needs/aims or lack of short term resources to make more minor > adjustments to satisfy all needs. Note I wouldn't call this a fork; its just an early experimental spike to see how much of the qpid code needs to be changed to be usable in ActiveMQ. The intention is to refactor and reuse as much qpid code as possible (assuming the qpid project accepts those refactors) and work with the qpid community to ensure we have one codebase for AMQP framing where possible. A fork is only a last resort when you can't work with a community after trying all other possibilities. Now we have the spike working, we can step back and compare the two sets of qpid framing code to see if we can refactor things into one library we can share (hopefully) - or at least find the common bits we can share; maybe one common core with 2 optional parts (for MINA v anything else). Until this exercise was done it was a little hard to know exactly what would need to be changed in the qpid marshalling/framing code so that we could reuse it in ActiveMQ > The second reason certainly applies here and perhaps the first one does > as well. I think both qpid and ActiveMQ could share the same framing code (or at least large chunks of it) especially if the qpid folks are happy to live with some refactors to make the framing code a little easier to work with & allow the MINA stuff to be decoupled > Regardless, moving to a more componentized code base for qpid > is desirable and will happen (though perhaps not fast enough for everyone). Cool > On more specific issues, the main obstacle in reuse of the framing layer > is I believe the coupling to Mina. Agreed. Though Hiram's added a similar Visitor pattern to the generated code that we use in OpenWire as well which can make working with the protocol much simpler - it might be nice to add that to qpid too. > As stated in an earlier mail, I think > there will always be different needs here: jdk ByteBuffer, mina > ByteBuffer, Data- Input/Output. As a lot of the code here is already > generated, we may be able when time allows, to address all needs through > different (or parameterized) templates. Agreed. It should be pretty trivial to have MINA and non-MINA generated code. I wonder if it'd make sense to generate interfaces for the various AMQP commands; then have a couple of options for generated implementations (MINA versus pure POJO)? Then the core framing/exchange handling code could work with either marshalling approaches. > At a higher level, e.g. the various exchange classes, there seem to be > less changes between the codebases now (mainly just repackaging?) so > maybe there we can more easily share in the short term. Yeah. The exchange, queue & security packages seem pretty much the same & could be reused if the MINA code could be decoupled - say behind an interface / implementation class separation. e.g. we could share the generated interfaces; then qpid's broker could depend on the mina-generated implementation classes and ActiveMQ could depend on the non-mina generated classes (in different packages). Note this interface separation could further help for dealing with multiple versions of the protocol etc. Or another approach could be just to decouple the marshalling code from the commands e.g. see how Hiram's decoupled the marshalling of the commands from the actual commands (so the commands themselves have no dependency on any transport/marshalling code). If that were done we could then share the same command classes & we'd just have different marshalling plugins. Either way, hopefully we can share most of the same framing/exchange handling code. Would some qpid-ers be interested in an attempt to merge some of Hiram's spike back into qpid so we can share more of the framing/exchange handling code a
Re: ActiveMQ can now support AMQP clients.
On 10/26/06, Gordon Sim <[EMAIL PROTECTED]> wrote: James Strachan wrote: > The desire is to share code - partlcularly the low level Qpid framing > code. We're all Apache folk afterall and projects are meant to work > together & share code where it makes sense to do so. > > Ideally qpid and ActiveMQ would share a large chunk of ocde for the > AMQP framing stuff; though right now its hard to do that as qpid is > not terribly easy to reuse and is based on MINA and ActiveMQ has its > own transport framework. I agree, sharing code is ideal. The qpid proposal included reusable libraries as an objective and this seems sensible in the effort to promote AMQP and interoperability. Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. Note I wouldn't call this a fork; its just an early experimental spike to see how much of the qpid code needs to be changed to be usable in ActiveMQ. The intention is to refactor and reuse as much qpid code as possible (assuming the qpid project accepts those refactors) and work with the qpid community to ensure we have one codebase for AMQP framing where possible. A fork is only a last resort when you can't work with a community after trying all other possibilities. Now we have the spike working, we can step back and compare the two sets of qpid framing code to see if we can refactor things into one library we can share (hopefully) - or at least find the common bits we can share; maybe one common core with 2 optional parts (for MINA v anything else). Until this exercise was done it was a little hard to know exactly what would need to be changed in the qpid marshalling/framing code so that we could reuse it in ActiveMQ The second reason certainly applies here and perhaps the first one does as well. I think both qpid and ActiveMQ could share the same framing code (or at least large chunks of it) especially if the qpid folks are happy to live with some refactors to make the framing code a little easier to work with & allow the MINA stuff to be decoupled Regardless, moving to a more componentized code base for qpid is desirable and will happen (though perhaps not fast enough for everyone). Cool On more specific issues, the main obstacle in reuse of the framing layer is I believe the coupling to Mina. Agreed. Though Hiram's added a similar Visitor pattern to the generated code that we use in OpenWire as well which can make working with the protocol much simpler - it might be nice to add that to qpid too. As stated in an earlier mail, I think there will always be different needs here: jdk ByteBuffer, mina ByteBuffer, Data- Input/Output. As a lot of the code here is already generated, we may be able when time allows, to address all needs through different (or parameterized) templates. Agreed. It should be pretty trivial to have MINA and non-MINA generated code. I wonder if it'd make sense to generate interfaces for the various AMQP commands; then have a couple of options for generated implementations (MINA versus pure POJO)? Then the core framing/exchange handling code could work with either marshalling approaches. At a higher level, e.g. the various exchange classes, there seem to be less changes between the codebases now (mainly just repackaging?) so maybe there we can more easily share in the short term. Yeah. The exchange, queue & security packages seem pretty much the same & could be reused if the MINA code could be decoupled - say behind an interface / implementation class separation. e.g. we could share the generated interfaces; then qpid's broker could depend on the mina-generated implementation classes and ActiveMQ could depend on the non-mina generated classes (in different packages). Note this interface separation could further help for dealing with multiple versions of the protocol etc. Or another approach could be just to decouple the marshalling code from the commands e.g. see how Hiram's decoupled the marshalling of the commands from the actual commands (so the commands themselves have no dependency on any transport/marshalling code). If that were done we could then share the same command classes & we'd just have different marshalling plugins. Either way, hopefully we can share most of the same framing/exchange handling code. Would some qpid-ers be interested in an attempt to merge some of Hiram's spike back into qpid so we can share more of the framing/exchange handling code across qpid and ActiveMQ? -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ can now support AMQP clients.
Jame I agree some getting to some kind of compliance testing is necessary.. we'll probably get there later in 2007. Also, I wanted to ask you in your capacity as Mentor, in the Apache family would it be cool to re-use code from ActiveMQ in Qpid where that makes sense? A simplistic example would be to re-use selector processing, but I'm sure there are other synergies. By the same logic, given that MINA is an Apache project (and a very good design); wouldn't it make sense to converge on that for IO processing across both projects? If MINA is lacking, we could all help make it better. I know that Robert has already contributed patches to MINA, and middleware is a great stress test for a framework like it. Best regards John On 26/10/06, James Strachan <[EMAIL PROTECTED]> wrote: On 10/26/06, John O'Hara <[EMAIL PROTECTED]> wrote: > I'm confused where ActiveMQ is going here. > > To quote Hiram: > "It also means that the AMQP message are in a seperate messaging > domain from the JMS messages. Now that everything is integrated and running > together we can figure what is the best approach to merging the messaging > domains." > > Does this mean that the current implementation is a "cut and shunt"? Where > two implementations are parked in the same address space? > > I'm hoping that the ActiveMQ folk's interest in AMQP is not just a "box > ticking" exercise for marketing purposes, and that it's a genuine effort to > engineer a correct AMQP solution. It is. Its one of the reasons why folks from the ActiveMQ community keep harping on about wanting a good TCK for AMQP. We've bitter experience with TCKs (particularly the J2EE TCK :) but what it does provide is a great comfort feeling that providers that pass the TCK really are compliant. Without a TCK, complex specs take lots of vendor get togethers to make them work (as the WS-* folks have found out) and interop between providers suffers causing users much pain. > The possibilities for damaging an emerging standard here are enormous; I > hope that everyone on the mailing list cares about the success of the AMQP > protocol, and understands the need to work towards good interoperating > implementations and the need *NOT* to confuse the market. You've confused me again :) How does ActiveMQ supporting the AMQP protocol confuse the market? > Have the ActiveMQ folk committed anything to the Qpid code tree FWIW Hiram certainly isnt a committer on Qpid nor is the ActiveMQ community in general > which isn't > driven by a desire to import Qpid into ActiveMQ? The desire is to share code - partlcularly the low level Qpid framing code. We're all Apache folk afterall and projects are meant to work together & share code where it makes sense to do so. Ideally qpid and ActiveMQ would share a large chunk of ocde for the AMQP framing stuff; though right now its hard to do that as qpid is not terribly easy to reuse and is based on MINA and ActiveMQ has its own transport framework. > I most sincerely hope the answer is yes. BTW did you see Hiram's patches to the qpid code generation stuff, which is pure qpid code and has nothing to do with ActiveMQ at all other than making it easier for other projects to reuse Qpid code? -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ can now support AMQP clients.
James Strachan wrote: The desire is to share code - partlcularly the low level Qpid framing code. We're all Apache folk afterall and projects are meant to work together & share code where it makes sense to do so. Ideally qpid and ActiveMQ would share a large chunk of ocde for the AMQP framing stuff; though right now its hard to do that as qpid is not terribly easy to reuse and is based on MINA and ActiveMQ has its own transport framework. I agree, sharing code is ideal. The qpid proposal included reusable libraries as an objective and this seems sensible in the effort to promote AMQP and interoperability. Right now the feedback seems to be that the code is mainly useful as 'seed' code for a fork. Forks are clearly not ideal as they dilute the collective effort, but sometimes they may be inevitable due to different long term needs/aims or lack of short term resources to make more minor adjustments to satisfy all needs. The second reason certainly applies here and perhaps the first one does as well. Regardless, moving to a more componentized code base for qpid is desirable and will happen (though perhaps not fast enough for everyone). On more specific issues, the main obstacle in reuse of the framing layer is I believe the coupling to Mina. As stated in an earlier mail, I think there will always be different needs here: jdk ByteBuffer, mina ByteBuffer, Data- Input/Output. As a lot of the code here is already generated, we may be able when time allows, to address all needs through different (or parameterized) templates. At a higher level, e.g. the various exchange classes, there seem to be less changes between the codebases now (mainly just repackaging?) so maybe there we can more easily share in the short term. Finally: Good job, Hiram, your work and feedback has been valuable in opening up the discussion and giving food for thought! Thanks also for keeping us in the loop with all your changes, much appreciated.
Re: ActiveMQ can now support AMQP clients.
On 10/26/06, John O'Hara <[EMAIL PROTECTED]> wrote: I'm confused where ActiveMQ is going here. To quote Hiram: "It also means that the AMQP message are in a seperate messaging domain from the JMS messages. Now that everything is integrated and running together we can figure what is the best approach to merging the messaging domains." Does this mean that the current implementation is a "cut and shunt"? Where two implementations are parked in the same address space? I'm hoping that the ActiveMQ folk's interest in AMQP is not just a "box ticking" exercise for marketing purposes, and that it's a genuine effort to engineer a correct AMQP solution. It is. Its one of the reasons why folks from the ActiveMQ community keep harping on about wanting a good TCK for AMQP. We've bitter experience with TCKs (particularly the J2EE TCK :) but what it does provide is a great comfort feeling that providers that pass the TCK really are compliant. Without a TCK, complex specs take lots of vendor get togethers to make them work (as the WS-* folks have found out) and interop between providers suffers causing users much pain. The possibilities for damaging an emerging standard here are enormous; I hope that everyone on the mailing list cares about the success of the AMQP protocol, and understands the need to work towards good interoperating implementations and the need *NOT* to confuse the market. You've confused me again :) How does ActiveMQ supporting the AMQP protocol confuse the market? Have the ActiveMQ folk committed anything to the Qpid code tree FWIW Hiram certainly isnt a committer on Qpid nor is the ActiveMQ community in general which isn't driven by a desire to import Qpid into ActiveMQ? The desire is to share code - partlcularly the low level Qpid framing code. We're all Apache folk afterall and projects are meant to work together & share code where it makes sense to do so. Ideally qpid and ActiveMQ would share a large chunk of ocde for the AMQP framing stuff; though right now its hard to do that as qpid is not terribly easy to reuse and is based on MINA and ActiveMQ has its own transport framework. I most sincerely hope the answer is yes. BTW did you see Hiram's patches to the qpid code generation stuff, which is pure qpid code and has nothing to do with ActiveMQ at all other than making it easier for other projects to reuse Qpid code? -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ can now support AMQP clients.
I am delighted that ActiveMQ wants to support AMQP. The more, the merrier :-) John On 26/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: On 10/25/06, John O'Hara <[EMAIL PROTECTED]> wrote: > I'm confused where ActiveMQ is going here. > > To quote Hiram: > "It also means that the AMQP message are in a seperate messaging > domain from the JMS messages. Now that everything is integrated and running > together we can figure what is the best approach to merging the messaging > domains." > > Does this mean that the current implementation is a "cut and shunt"? Where > two implementations are parked in the same address space? Are referring to the fact that AMQP messaging domain is currently still separated from the JMS messaging domain? This is not that odd in messaging systems. Even the queue and topic messaging domains in JMS are generally "two implementations are parked in the same address space". But I suspect that once I get a chance to start working on my next development cycle on the code, I'll figure out a way to have a better binding between the messaging domains. I'm just a code monkey trying to promote AMQP and ActiveMQ by adding and implementation to ActiveMQ based from the qpid code base. I did not know that folks would get upset if I did that. If you think there is something lacking in the implementation, please feel free to submit patches. We are part of the same community after all! -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
On 10/25/06, John O'Hara <[EMAIL PROTECTED]> wrote: I'm confused where ActiveMQ is going here. To quote Hiram: "It also means that the AMQP message are in a seperate messaging domain from the JMS messages. Now that everything is integrated and running together we can figure what is the best approach to merging the messaging domains." Does this mean that the current implementation is a "cut and shunt"? Where two implementations are parked in the same address space? Are referring to the fact that AMQP messaging domain is currently still separated from the JMS messaging domain? This is not that odd in messaging systems. Even the queue and topic messaging domains in JMS are generally "two implementations are parked in the same address space". But I suspect that once I get a chance to start working on my next development cycle on the code, I'll figure out a way to have a better binding between the messaging domains. I'm just a code monkey trying to promote AMQP and ActiveMQ by adding and implementation to ActiveMQ based from the qpid code base. I did not know that folks would get upset if I did that. If you think there is something lacking in the implementation, please feel free to submit patches. We are part of the same community after all! -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
I'm confused where ActiveMQ is going here. To quote Hiram: "It also means that the AMQP message are in a seperate messaging domain from the JMS messages. Now that everything is integrated and running together we can figure what is the best approach to merging the messaging domains." Does this mean that the current implementation is a "cut and shunt"? Where two implementations are parked in the same address space? I'm hoping that the ActiveMQ folk's interest in AMQP is not just a "box ticking" exercise for marketing purposes, and that it's a genuine effort to engineer a correct AMQP solution. The possibilities for damaging an emerging standard here are enormous; I hope that everyone on the mailing list cares about the success of the AMQP protocol, and understands the need to work towards good interoperating implementations and the need *NOT* to confuse the market. Have the ActiveMQ folk committed anything to the Qpid code tree which isn't driven by a desire to import Qpid into ActiveMQ? I most sincerely hope the answer is yes. Cheers John On 25/10/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Resend, have not seen this show up yet on the list.] On Oct 23, 2006, at 2:08 PM, James Strachan wrote: > On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: >> [Sorry if this is a duplicate -- originally sent it Saturday but >> haven't seen it show up here.] >> >> On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: >> >> > Hey Folks, >> > >> > Just wanted to give you an update on the progress that ActiveMQ is >> > making in >> > supporting AMQP clients. I have taken most of the java code from >> > the qpid >> > project and done some major refactoring to it so that it's more >> > inline with >> > the ActiveMQ architecture. It now uses the ActiveMQ transport, >> > wireformat, >> > broker service, connector, and configuration patterns. So now >> it is >> > possible to have your ActiveMQ broker support both standard >> > ActiveMQ clients >> > and AMQP clients like the qpid implemented java and C++ clients. >> >> May I ask for a clarification? If your work uses the ActiveMQ wire >> format, does that mean that it's non-interoperable with Qpid? > > Yes > > I think what Hiram means is that it uses the same ActiveMQ plugin > interfaces which are used to implement other protocols like OpenWire, > Stomp, XMPP (i.e. Transport and WireFormat are interfaces) - but that > it actually uses the AMQP protocol on the wire. So, by "yes," did you mean "yes, it's non-interoperable" (which is what I asked above), or "yes, it's interoperable" ? >> In >> other words, can a normal Qpid client using the AMQ protocol version > > Yes - or at least thats the intention. (I've not tried it yet :) This "yes" seems to contradict your "yes" from above, no? I'm really not trying to be a pain, but so far responses to these questions have been confusing. I'm just trying to make sure we're all on the same page. Given that ActiveMQ probably doesn't provide APIs that correspond to AMQ features like exchanges and bindings, how is it that an ActiveMQ application can meaningfully interact or fully interoperate with an AMQP implementation like Qpid? thanks, --steve
Re: ActiveMQ can now support AMQP clients.
[Resend, have not seen this show up yet on the list.] On Oct 23, 2006, at 2:08 PM, James Strachan wrote: On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: > Hey Folks, > > Just wanted to give you an update on the progress that ActiveMQ is > making in > supporting AMQP clients. I have taken most of the java code from > the qpid > project and done some major refactoring to it so that it's more > inline with > the ActiveMQ architecture. It now uses the ActiveMQ transport, > wireformat, > broker service, connector, and configuration patterns. So now it is > possible to have your ActiveMQ broker support both standard > ActiveMQ clients > and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? Yes I think what Hiram means is that it uses the same ActiveMQ plugin interfaces which are used to implement other protocols like OpenWire, Stomp, XMPP (i.e. Transport and WireFormat are interfaces) - but that it actually uses the AMQP protocol on the wire. So, by "yes," did you mean "yes, it's non-interoperable" (which is what I asked above), or "yes, it's interoperable" ? In other words, can a normal Qpid client using the AMQ protocol version Yes - or at least thats the intention. (I've not tried it yet :) This "yes" seems to contradict your "yes" from above, no? I'm really not trying to be a pain, but so far responses to these questions have been confusing. I'm just trying to make sure we're all on the same page. Given that ActiveMQ probably doesn't provide APIs that correspond to AMQ features like exchanges and bindings, how is it that an ActiveMQ application can meaningfully interact or fully interoperate with an AMQP implementation like Qpid? thanks, --steve
Re: ActiveMQ can now support AMQP clients.
On 10/24/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: On Oct 23, 2006, at 2:08 PM, James Strachan wrote: > On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: >> [Sorry if this is a duplicate -- originally sent it Saturday but >> haven't seen it show up here.] >> >> On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: >> >> > Hey Folks, >> > >> > Just wanted to give you an update on the progress that ActiveMQ is >> > making in >> > supporting AMQP clients. I have taken most of the java code from >> > the qpid >> > project and done some major refactoring to it so that it's more >> > inline with >> > the ActiveMQ architecture. It now uses the ActiveMQ transport, >> > wireformat, >> > broker service, connector, and configuration patterns. So now >> it is >> > possible to have your ActiveMQ broker support both standard >> > ActiveMQ clients >> > and AMQP clients like the qpid implemented java and C++ clients. >> >> May I ask for a clarification? If your work uses the ActiveMQ wire >> format, does that mean that it's non-interoperable with Qpid? > > Yes > > I think what Hiram means is that it uses the same ActiveMQ plugin > interfaces which are used to implement other protocols like OpenWire, > Stomp, XMPP (i.e. Transport and WireFormat are interfaces) - but that > it actually uses the AMQP protocol on the wire. So, by "yes," did you mean "yes, it's non-interoperable" (which is what I asked above), or "yes, it's interoperable" ? >> In >> other words, can a normal Qpid client using the AMQ protocol version > > Yes - or at least thats the intention. (I've not tried it yet :) This "yes" seems to contradict your "yes" from above, no? I'm really not trying to be a pain, but so far responses to these questions have been confusing. I'm just trying to make sure we're all on the same page. Given that ActiveMQ probably doesn't provide APIs that correspond to AMQ features like exchanges and bindings, how is it that an ActiveMQ application can meaningfully interact or fully interoperate with an AMQP implementation like Qpid? We integrated the core of the QPID exchange/binding/queue logic with ActiveMQ. So this means all semantics that the QPID broker understood are preserved. It also means that the AMQP message are in a seperate messaging domain from the JMS messages. Now that everything is integrated and running together we can figure what is the best approach to merging the messaging domains. thanks, --steve -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
On Oct 23, 2006, at 2:08 PM, James Strachan wrote: On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: > Hey Folks, > > Just wanted to give you an update on the progress that ActiveMQ is > making in > supporting AMQP clients. I have taken most of the java code from > the qpid > project and done some major refactoring to it so that it's more > inline with > the ActiveMQ architecture. It now uses the ActiveMQ transport, > wireformat, > broker service, connector, and configuration patterns. So now it is > possible to have your ActiveMQ broker support both standard > ActiveMQ clients > and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? Yes I think what Hiram means is that it uses the same ActiveMQ plugin interfaces which are used to implement other protocols like OpenWire, Stomp, XMPP (i.e. Transport and WireFormat are interfaces) - but that it actually uses the AMQP protocol on the wire. So, by "yes," did you mean "yes, it's non-interoperable" (which is what I asked above), or "yes, it's interoperable" ? In other words, can a normal Qpid client using the AMQ protocol version Yes - or at least thats the intention. (I've not tried it yet :) This "yes" seems to contradict your "yes" from above, no? I'm really not trying to be a pain, but so far responses to these questions have been confusing. I'm just trying to make sure we're all on the same page. Given that ActiveMQ probably doesn't provide APIs that correspond to AMQ features like exchanges and bindings, how is it that an ActiveMQ application can meaningfully interact or fully interoperate with an AMQP implementation like Qpid? thanks, --steve
Re: ActiveMQ can now support AMQP clients.
Hi Carl, On 10/24/06, Carl Trieloff <[EMAIL PROTECTED]> wrote: Hiram, Looking at the code, it looks like you run Qpid as a "parallel" broker inside ActiveMQ with Yep! No reason not to re-use an excellent amqp broker implementation. forwarding through the IO layer. I was looking to see if there where areas we could work together Yes the IO layer was hevily refactored since ActiveMQ does not use MINA. We also use IOC to configure the broker components. but I can't say I see them yet as the current approach there is no integration in underlying infrastructure. What are your ideas/plans or use cases moving forward? Please re-read my original post that started this thread. I've outlined some of the items that I would like improve going forward. The biggest line item in the list is integrating the messaging domains. First off, ActiveMQ might bring the whole exchange / binding concept right into the core. But until that happens we may do something simpler like figuring out a way for Qpid queues to map to ActiveMQ queues. I hope that the ActiveMQ broker and the Qpid java broker team can one day be integrated and we are only working on broker. Otherwise, I'm afraid that we will be we-writing the same underlying bits over and over! Regards, Carl. Hiram Chirino wrote: > Hi John, > > We support all the exchanges that are currently supported in the qpid > server. I've got a feeling we may need to add more add more as we > integrate > into the JMS messaging domains. > > On 10/24/06, John O'Hara <[EMAIL PROTECTED]> wrote: >> >> I'm excited by your achievement, but I'm concerned you get the semantics >> that go with the commands. >> >> Which AMQP Exchanges does ActiveMQ support? Header? Topic? Direct? >> >> As a poor analogy; its not great to use French phrases with English >> words. >> Has anyone seen the BBC sitcom from years back - "'Allo 'Allo" ? :-) >> >> Cheers >> John >> >> On 23/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: >> > >> > thx for the clarification! >> > >> > On 10/23/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: >> > > >> > > The version is 0.8. >> > > >> > > However >> > > >> > > The original AMQP specification defined the major number as the >> major >> > > octet/10, while the minor is composed of two numbers, the major >> octet%10 >> > > and minor octet (are you confused yet?) Hence major octet=8, minor >> > > octet=0 translates to 0.80 under this rule. (This is in reality a >> > > three-level version system made to look like a two-level system.) >> > > >> > > This rule has now been replaced by the more straight forward rule: >> > > major=major octet, minor=minor octet. So the next official >> release of >> > > the specification later this year will have major=0, minor=9. >> > > >> > > ... A recipe for confusion! ;-) >> > > >> > > Kim >> > > >> > > On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: >> > > >> > > > Yes! But BTW.. it seems like at least the version I've been >> working >> > > > with, >> > > > the version is 8.0. Is this right?? Or is the version actually >> > > > supposed to >> > > > be 0.8??? >> > > > >> > > >> > > >> > >> > >> > -- >> > Regards, >> > Hiram >> > >> > Blog: http://hiramchirino.com >> > >> > >> >> > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
Hiram, Looking at the code, it looks like you run Qpid as a "parallel" broker inside ActiveMQ with forwarding through the IO layer. I was looking to see if there where areas we could work together but I can't say I see them yet as the current approach there is no integration in underlying infrastructure. What are your ideas/plans or use cases moving forward? Regards, Carl. Hiram Chirino wrote: Hi John, We support all the exchanges that are currently supported in the qpid server. I've got a feeling we may need to add more add more as we integrate into the JMS messaging domains. On 10/24/06, John O'Hara <[EMAIL PROTECTED]> wrote: I'm excited by your achievement, but I'm concerned you get the semantics that go with the commands. Which AMQP Exchanges does ActiveMQ support? Header? Topic? Direct? As a poor analogy; its not great to use French phrases with English words. Has anyone seen the BBC sitcom from years back - "'Allo 'Allo" ? :-) Cheers John On 23/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > thx for the clarification! > > On 10/23/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: > > > > The version is 0.8. > > > > However > > > > The original AMQP specification defined the major number as the major > > octet/10, while the minor is composed of two numbers, the major octet%10 > > and minor octet (are you confused yet?) Hence major octet=8, minor > > octet=0 translates to 0.80 under this rule. (This is in reality a > > three-level version system made to look like a two-level system.) > > > > This rule has now been replaced by the more straight forward rule: > > major=major octet, minor=minor octet. So the next official release of > > the specification later this year will have major=0, minor=9. > > > > ... A recipe for confusion! ;-) > > > > Kim > > > > On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: > > > > > Yes! But BTW.. it seems like at least the version I've been working > > > with, > > > the version is 8.0. Is this right?? Or is the version actually > > > supposed to > > > be 0.8??? > > > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > >
Re: ActiveMQ can now support AMQP clients.
Hi John, We support all the exchanges that are currently supported in the qpid server. I've got a feeling we may need to add more add more as we integrate into the JMS messaging domains. On 10/24/06, John O'Hara <[EMAIL PROTECTED]> wrote: I'm excited by your achievement, but I'm concerned you get the semantics that go with the commands. Which AMQP Exchanges does ActiveMQ support? Header? Topic? Direct? As a poor analogy; its not great to use French phrases with English words. Has anyone seen the BBC sitcom from years back - "'Allo 'Allo" ? :-) Cheers John On 23/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > thx for the clarification! > > On 10/23/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: > > > > The version is 0.8. > > > > However > > > > The original AMQP specification defined the major number as the major > > octet/10, while the minor is composed of two numbers, the major octet%10 > > and minor octet (are you confused yet?) Hence major octet=8, minor > > octet=0 translates to 0.80 under this rule. (This is in reality a > > three-level version system made to look like a two-level system.) > > > > This rule has now been replaced by the more straight forward rule: > > major=major octet, minor=minor octet. So the next official release of > > the specification later this year will have major=0, minor=9. > > > > ... A recipe for confusion! ;-) > > > > Kim > > > > On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: > > > > > Yes! But BTW.. it seems like at least the version I've been working > > > with, > > > the version is 8.0. Is this right?? Or is the version actually > > > supposed to > > > be 0.8??? > > > > > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
I'm excited by your achievement, but I'm concerned you get the semantics that go with the commands. Which AMQP Exchanges does ActiveMQ support? Header? Topic? Direct? As a poor analogy; its not great to use French phrases with English words. Has anyone seen the BBC sitcom from years back - "'Allo 'Allo" ? :-) Cheers John On 23/10/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: thx for the clarification! On 10/23/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: > > The version is 0.8. > > However > > The original AMQP specification defined the major number as the major > octet/10, while the minor is composed of two numbers, the major octet%10 > and minor octet (are you confused yet?) Hence major octet=8, minor > octet=0 translates to 0.80 under this rule. (This is in reality a > three-level version system made to look like a two-level system.) > > This rule has now been replaced by the more straight forward rule: > major=major octet, minor=minor octet. So the next official release of > the specification later this year will have major=0, minor=9. > > ... A recipe for confusion! ;-) > > Kim > > On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: > > > Yes! But BTW.. it seems like at least the version I've been working > > with, > > the version is 8.0. Is this right?? Or is the version actually > > supposed to > > be 0.8??? > > > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
thx for the clarification! On 10/23/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: The version is 0.8. However The original AMQP specification defined the major number as the major octet/10, while the minor is composed of two numbers, the major octet%10 and minor octet (are you confused yet?) Hence major octet=8, minor octet=0 translates to 0.80 under this rule. (This is in reality a three-level version system made to look like a two-level system.) This rule has now been replaced by the more straight forward rule: major=major octet, minor=minor octet. So the next official release of the specification later this year will have major=0, minor=9. ... A recipe for confusion! ;-) Kim On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: > Yes! But BTW.. it seems like at least the version I've been working > with, > the version is 8.0. Is this right?? Or is the version actually > supposed to > be 0.8??? > -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
The version is 0.8. However The original AMQP specification defined the major number as the major octet/10, while the minor is composed of two numbers, the major octet%10 and minor octet (are you confused yet?) Hence major octet=8, minor octet=0 translates to 0.80 under this rule. (This is in reality a three-level version system made to look like a two-level system.) This rule has now been replaced by the more straight forward rule: major=major octet, minor=minor octet. So the next official release of the specification later this year will have major=0, minor=9. ... A recipe for confusion! ;-) Kim On Mon, 2006-10-23 at 13:03 -0500, Hiram Chirino wrote: > Yes! But BTW.. it seems like at least the version I've been working > with, > the version is 8.0. Is this right?? Or is the version actually > supposed to > be 0.8??? >
Re: ActiveMQ can now support AMQP clients.
Hiram Chirino wrote: On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: > Hey Folks, > > Just wanted to give you an update on the progress that ActiveMQ is > making in > supporting AMQP clients. I have taken most of the java code from > the qpid > project and done some major refactoring to it so that it's more > inline with > the ActiveMQ architecture. It now uses the ActiveMQ transport, > wireformat, > broker service, connector, and configuration patterns. So now it is > possible to have your ActiveMQ broker support both standard > ActiveMQ clients > and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? In Ah.. ActiveMQ has an architecture in place to support multiple wire formats. When I stated that is uses the ActiveMQ wireformat patterns, it means that the AMQP marshallers now provide an ActiveMQ WireFormat interface that other parts of the ActiveMQ broker can use to marshal and unmarshal objects. other words, can a normal Qpid client using the AMQ protocol version 0.8 talk directly to an ActiveMQ broker based on this work? Yes! But BTW.. it seems like at least the version I've been working with, the version is 8.0. Is this right?? Or is the version actually supposed to be 0.8??? It is meant to be 0-8. That will be corrected in an update to 0-9. Carl. --steve > > The stuff that still missing is that the AMQP messages are in separate > messaging domain from the ActiveMQ messages. The next set of work > that's > still pending is : > - Need to add Unit tests! > - integrating the messaging domains > - implementing the AMQP persistence using ActiveMQ's message stores > - porting the sasl implementation in qpid (big refactor needed to > make it > IOC configured). > - and once we are happy with all the integration and everything is > pretty > stable, JMXify it! > > Please note that the AMQP spec is still moving so the latest qpid's > clients > may no long be compatible with this work, (I've been testing > against qpid > sources about 3 weeks old.) Hopefully qpid will do a milestone > release soon > and then I'll port the protocol changes that I've missed when they > do that. > > If anybody wants to pitch in and help, here's where our amqp/qpid > integration module is located in svn: > http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: > Hey Folks, > > Just wanted to give you an update on the progress that ActiveMQ is > making in > supporting AMQP clients. I have taken most of the java code from > the qpid > project and done some major refactoring to it so that it's more > inline with > the ActiveMQ architecture. It now uses the ActiveMQ transport, > wireformat, > broker service, connector, and configuration patterns. So now it is > possible to have your ActiveMQ broker support both standard > ActiveMQ clients > and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? Yes I think what Hiram means is that it uses the same ActiveMQ plugin interfaces which are used to implement other protocols like OpenWire, Stomp, XMPP (i.e. Transport and WireFormat are interfaces) - but that it actually uses the AMQP protocol on the wire. In other words, can a normal Qpid client using the AMQ protocol version Yes - or at least thats the intention. (I've not tried it yet :) -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ can now support AMQP clients.
On 10/23/06, Steve Vinoski <[EMAIL PROTECTED]> wrote: [Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: > Hey Folks, > > Just wanted to give you an update on the progress that ActiveMQ is > making in > supporting AMQP clients. I have taken most of the java code from > the qpid > project and done some major refactoring to it so that it's more > inline with > the ActiveMQ architecture. It now uses the ActiveMQ transport, > wireformat, > broker service, connector, and configuration patterns. So now it is > possible to have your ActiveMQ broker support both standard > ActiveMQ clients > and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? In Ah.. ActiveMQ has an architecture in place to support multiple wire formats. When I stated that is uses the ActiveMQ wireformat patterns, it means that the AMQP marshallers now provide an ActiveMQ WireFormat interface that other parts of the ActiveMQ broker can use to marshal and unmarshal objects. other words, can a normal Qpid client using the AMQ protocol version 0.8 talk directly to an ActiveMQ broker based on this work? Yes! But BTW.. it seems like at least the version I've been working with, the version is 8.0. Is this right?? Or is the version actually supposed to be 0.8??? --steve > > The stuff that still missing is that the AMQP messages are in separate > messaging domain from the ActiveMQ messages. The next set of work > that's > still pending is : > - Need to add Unit tests! > - integrating the messaging domains > - implementing the AMQP persistence using ActiveMQ's message stores > - porting the sasl implementation in qpid (big refactor needed to > make it > IOC configured). > - and once we are happy with all the integration and everything is > pretty > stable, JMXify it! > > Please note that the AMQP spec is still moving so the latest qpid's > clients > may no long be compatible with this work, (I've been testing > against qpid > sources about 3 weeks old.) Hopefully qpid will do a milestone > release soon > and then I'll port the protocol changes that I've missed when they > do that. > > If anybody wants to pitch in and help, here's where our amqp/qpid > integration module is located in svn: > http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: Hey Folks, Just wanted to give you an update on the progress that ActiveMQ is making in supporting AMQP clients. I have taken most of the java code from the qpid project and done some major refactoring to it so that it's more inline with the ActiveMQ architecture. It now uses the ActiveMQ transport, wireformat, May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? In other words, can a normal Qpid client using the AMQ protocol version 0.8 talk directly to an ActiveMQ broker based on this work? --steve broker service, connector, and configuration patterns. So now it is possible to have your ActiveMQ broker support both standard ActiveMQ clients and AMQP clients like the qpid implemented java and C++ clients. The stuff that still missing is that the AMQP messages are in separate messaging domain from the ActiveMQ messages. The next set of work that's still pending is : - Need to add Unit tests! - integrating the messaging domains - implementing the AMQP persistence using ActiveMQ's message stores - porting the sasl implementation in qpid (big refactor needed to make it IOC configured). - and once we are happy with all the integration and everything is pretty stable, JMXify it! Please note that the AMQP spec is still moving so the latest qpid's clients may no long be compatible with this work, (I've been testing against qpid sources about 3 weeks old.) Hopefully qpid will do a milestone release soon and then I'll port the protocol changes that I've missed when they do that. If anybody wants to pitch in and help, here's where our amqp/qpid integration module is located in svn: http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
[Sorry if this is a duplicate -- originally sent it Saturday but haven't seen it show up here.] On Oct 20, 2006, at 10:29 PM, Hiram Chirino wrote: Hey Folks, Just wanted to give you an update on the progress that ActiveMQ is making in supporting AMQP clients. I have taken most of the java code from the qpid project and done some major refactoring to it so that it's more inline with the ActiveMQ architecture. It now uses the ActiveMQ transport, wireformat, broker service, connector, and configuration patterns. So now it is possible to have your ActiveMQ broker support both standard ActiveMQ clients and AMQP clients like the qpid implemented java and C++ clients. May I ask for a clarification? If your work uses the ActiveMQ wire format, does that mean that it's non-interoperable with Qpid? In other words, can a normal Qpid client using the AMQ protocol version 0.8 talk directly to an ActiveMQ broker based on this work? --steve The stuff that still missing is that the AMQP messages are in separate messaging domain from the ActiveMQ messages. The next set of work that's still pending is : - Need to add Unit tests! - integrating the messaging domains - implementing the AMQP persistence using ActiveMQ's message stores - porting the sasl implementation in qpid (big refactor needed to make it IOC configured). - and once we are happy with all the integration and everything is pretty stable, JMXify it! Please note that the AMQP spec is still moving so the latest qpid's clients may no long be compatible with this work, (I've been testing against qpid sources about 3 weeks old.) Hopefully qpid will do a milestone release soon and then I'll port the protocol changes that I've missed when they do that. If anybody wants to pitch in and help, here's where our amqp/qpid integration module is located in svn: http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ can now support AMQP clients.
Great work Hiram! On 10/21/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: Hey Folks, Just wanted to give you an update on the progress that ActiveMQ is making in supporting AMQP clients. I have taken most of the java code from the qpid project and done some major refactoring to it so that it's more inline with the ActiveMQ architecture. It now uses the ActiveMQ transport, wireformat, broker service, connector, and configuration patterns. So now it is possible to have your ActiveMQ broker support both standard ActiveMQ clients and AMQP clients like the qpid implemented java and C++ clients. The stuff that still missing is that the AMQP messages are in separate messaging domain from the ActiveMQ messages. The next set of work that's still pending is : - Need to add Unit tests! - integrating the messaging domains - implementing the AMQP persistence using ActiveMQ's message stores - porting the sasl implementation in qpid (big refactor needed to make it IOC configured). - and once we are happy with all the integration and everything is pretty stable, JMXify it! Please note that the AMQP spec is still moving so the latest qpid's clients may no long be compatible with this work, (I've been testing against qpid sources about 3 weeks old.) Hopefully qpid will do a milestone release soon and then I'll port the protocol changes that I've missed when they do that. If anybody wants to pitch in and help, here's where our amqp/qpid integration module is located in svn: http://svn.apache.org/viewvc/incubator/activemq/sandbox/qpid -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
