Gerald, comments inline.
On 3/12/07, Gerald Loeffler <[EMAIL PROTECTED]> wrote:
hi Rajith, thank you very much for giving me some insight into your work at Qpid and the AMQP spec group. I definitely look forward to that AMQP-JMS mapping! I don't really agree with your statement that "The concept of exchanges is a broker side artifact" and that "JMS is just a client API". After all, an AMQP client sends messages to an exchange (so it is not just a broker-side artifact) and the JMS-spec defines what "administered objects" (Queue, Topic, ConnectionFactory) a JMS client can expect to look-up via JNDI from a JMS provider (so JMS also defines a JMS provider's behaviour, to some degree). However i trust that the AMQP-JMS-mapping will sort these issues out.
[RA] IMO the JMS API doesn't define the JMS providers behaviour, rather it provides what is expected from a JMS provider. The broker implementation can be whatever you want as long as you can provide whats expected from the JMS API. YMMV. For example you can implement Topics any which way u want and Qpid has chosen to do it with the topic exchange. Since this is not the forum to talk about JMS and Qpid, I would like to invite u to the Qpid mailing list and you can get a more wide varierty of opinions over there. We really need user feedback and your comments will be very welcomed. I also can't fully agree with your assertion that "Our java client is
actually a JMS implementation on top of AMQP", as this hides the fact that Qpid-specific classes (like org.apache.qpid.client.BasicMessageProducer) provide essential features (such as sending non-persistent and immediate messages) which are not available via the JMS interfaces (javax.jms.MessageProducer in this case). So it just means to show that the mapping of AMQP to JMS needs some clarification, and that there is a part of AMQP that can not be mapped to JMS nicely and the Java mapping of that should also be standardised.
[RA] Gerald I totally that there is some behaviour in AMQP that cannot be fully or effectively expressed through JMS. There is absolutely some value in defining a Java client for AMQP and that is what I am currently doing. The idea is to expose a protocol level API using java. Why we decided to do JMS as the first cut is bcos a) the code donated to the community was a JMS implementation of AMQP b) Most enterprise java apps (including the applications from the donor) were using JMS. so JMS was the more immediate use case. However I don't agree the we need a standard java mapping. AMQP is a wire level protocol. So u really don't need any language mapping bcos what matters is the byte stream on the wire. There is already a language independent protocol API defined, so we don't need any language specific mappings. (it's like SOAP, there is message format and rules on how to interpret it) JMS is a special use case. As I mentioned before the AMQP-JMS mapping is more about interoperability between two JMS impls on top of AMQP and not really about AMQP itself. Bcos we already have a standardised wire format for AMQP. So this is like the SOAP/JMS spec. Hope this helps. Regards, Rajith thanks again and good luck with your endeavours.
I shall let you know if i succeed in integrating Qpid as "just another JMS provider" into Synapse... cheers, gerald On 09/03/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > Hi Gerald, > > Comments in line. > > > > From my understanding QPid fully passes the JMS TCK, so you can use > > > > AMQP out-of-the-box with the existing JMS plug today. So in answer to > > > > your question its trivial to use AMQP. > > > > > [RA] We did have a full pass on the JMS TCK. > But, there was rapid changes on the trunk after that and I haven't run the > TCK for a while. > So I can't claim 100% compliance w/o running it again. But I dobut that we > really broke anything serious or else we would have heard from users. > Once the trunk stabalizes a bit I am going to run the TCK again and fix > anything if broken. > > > In general, there seems to be a mismatch between AMQP features and the > > > JMS API, > > > [RA] Gerald, I am in the AMQP spec group and we are currently working on an > AMQP-JMS mapping to standardise the JMS implementation on top of AMQP and to > describe in detail how these to worlds come to gether. This is to ensure > that any JMS impl on top of AMQP can interoperate with each other. > > >in particular with the concept of an Exchange missing from > > JMS. > [RA] JMS is just a client API. It doesn't really dictate anything about how > a broker should be implemented. > The concept of exchanges is a broker side artifact. For Qpid we have used > the Direct Exchange to implement point-to-point messaging and Topic Exchange > to implement pub-sub. > > > > > > Qpid claims to support "All features required by the Sun JMS 1.1 > > > specification". Last time i checked, though, i wasn't able to write a > > > Qpid client without resorting to the Qpid-specific API - but i'll > > > certainly try again and try to hook it up to Synapse/Axis2. Will keep > > > this list posted... > > > [RA] Gerald we don't have a Qpid (or AMQP) specific java client. Our java > client is actually a JMS implementation on top of AMQP. > JMS was the standard messaging API and we decided to use it rather than have > our own API. Besides there are lots of enterprise apps written on JMS. > So having a JMS client was the best way to convert them transparently on to > AMQP. > > However currently we are doing a refactoring on the client side (java) and > we want have a very low level client API and then map the JMS API on top of > it. > We could then use this low level client API to suport native AMQP features > that JMS doesn't provide. For example Rabbit has a non JMS java client. > There seems to be some interest in using AMQP directly without JMS, so a > native AMQP client in java makes more sense now. > > > > > > > For example, without any coding you should be able to put an XML > > > > message onto AMQP and have Synapse read it, and then route it to a > > > > WS-ReliableMessaging endpoint - for example a Microsoft .NET server. > > > > > > [RA] If synapse needs to inspect the message headers and route and AMQP > message you could do that with the JMS API itself. > I think Asanka already did something to route messages based on the JMS > headers. Asanka is that correct ? > If we use the Qpid JMS client then we can do that. > > > > I think the interesting question is whether we can do tighter > > > > integration, and we'd love any input on what that could be. > > > > > > > for instance: the ability to dynamically declare AMQP exchanges, > > > queues and bindings (which wire an exchange to a queue) from Synapse > > > (possibly based on incoming message properties, etc.), since these > > > dynamic capabilities are a core feature of AMQP that is missing from > > > JMS. > > > [RA] Certainly these features are missing from the current java client. As > we have directly implemented the JMS API. > Part of my current tasks is to work on a low level java client API to do > these things. > Once we have this client I am happy to work with the synapse team to > integrate this into a syanpse extention if the community thinks it's a > useful feature to have. > > > > I'm also interested interested in the wider questions around reliable > > > > messaging protocols, so if you're in a position to share your thoughts > > > > around AMQP I'd love to hear those too. > > > > > > i should consolidate my thoughts first ;-) but it is my impression > > > that AMQP is still in a very early stage of its lifecycle: > > > - there is no standardised Java binding > > > [RA] We will not do any language bindings. People can implement it in any > lanaguage in any way they want as long as they adhere to the wire protocol > and functionality described in the spec. > However we are currently working on an AMQP-JMS mapping to standadise a > guide for implementors to ensure any JMS implementation will interoperate > with another. The idea is to have a JMS client (or even a C or Phython > client if they want to) to be able to read a JMS map message sent by another > JMS client and make sense out of it. Basically we are trying to standarise > the encoding. We are doing this only for java as there is no other common > message API out there for any other language. > > > - even the abstracted API that the spec defines is in flux (e.g. the > > > new message class) > > > [RA] Slowly but surely we are getting closer to finalize this. We already > have the new message class implemented in a branch in Qpid. > > > - i'm unsure as to the interoperability of different AMQP > > > implementations (which is, after all, one central goal for AMQP) > > > - it promisses on-the-wire interoperability without compromising > > > performance, > > > [RA] Interoperability is key for AMQP. We will be introducing a TCK to > ensure that. > > though > > > - it's not firewall-friendly > > > - the spec is very well written ;-) > > > > > > > cheers, > > > gerald > > > > > > > > > > > Paul > > > > > > > > On 3/9/07, Gerald Loeffler <[EMAIL PROTECTED]> wrote: > > > > > Hi asankha, > > > > > > > > > > thanks for your quick response. AMQP transport in Synapse/Axis2 is > > not > > > > > an immediate requirement for us but something that we will want to > > be > > > > > able to do in the not-to-distant future without incurring too much > > > > > effort (based on one of the open-source AMQP implementations i > > > > > mentioned). So it is important to know that you don't consider it a > > > > > difficult task adding it to Axis2. I'll have a look at the relevant > > > > > Axis2 APIs and the code for the JMS transport to get a better > > idea... > > > > > > > > > > As to who is going to do it: that entirely depends on our schedule > > > > > when the concrete need for AMQP arises from our project... > > > > > > > > > > thanks again, > > > > > gerald > > > > > > > > > > On 09/03/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > > > > > > Hi Gerald > > > > > > > Can you please give me a rough idea of what it entails to add > > support > > > > > > > for a new transport to Synapse? I would want to add support for > > AMQP > > > > > > > (http://www.amqp.org/), which has a JMS-like Java client API > > (see > > > > > > > http://cwiki.apache.org/qpid/, http://www.rabbitmq.com/). Is > > this > > > > > > > trivial or a major task? Since Synapse does not build on JBI, it > > must > > > > > > > have its own APIs for doing this... > > > > > > Adding a new transport to Synapse is the same as adding a new > > transport > > > > > > for Axis2 - and is not a difficult task. There are certain Axis2 > > API's > > > > > > you need to implement, and the existing transports should provide > > > > > > adequate examples and code to help guide the effort. > > > > > > > > > > > > Would you be interested in developing an AMQP transport for > > > > > > Synapse/Axis2 yourself, or looking at how you could get the AMQP > > support > > > > > > built into Synapse through the community? Either way I think > > having an > > > > > > actual user requiring a new transport would help in its > > implementation, > > > > > > scope and testing efforts. I will read through some of the links > > you > > > > > > have provided meanwhile.. > > > > > > > > > > > > asankha > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://www.gerald-loeffler.net > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Paul Fremantle > > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > > > > > http://bloglines.com/blog/paulfremantle > > > > [EMAIL PROTECTED] > > > > > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > http://www.gerald-loeffler.net > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Paul Fremantle > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair > > > > http://bloglines.com/blog/paulfremantle > > [EMAIL PROTECTED] > > > > "Oxygenating the Web Service Platform", www.wso2.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > -- http://www.gerald-loeffler.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
