Also Resource is bound to a queue name, then MessageSender extends Resource and provides a send method. However, in AMQP we don't send to queues, but to routing keys.
On 31/07/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > On 31/07/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > So the low level Qpid API you are talking about is there in the current > > code. > > However it would be tedious to program at this level with out a good > > knowledge of the protocol. > > Hence we need a more developer friendly API that is at a slightly higher > > > > level. > > This is what we want to promote as an API, and it does contain most of > > the > > methods in the low level API. > > > > I think that in that case, there is no point in having a seperate Qpid API > that is any different to the JMS API. There is the low-level, against the > protocol API, tedious to program against, but there for those who might wish > to. For example, somebody might conceivably like to hook into the > session.ping method notification, to provide feedback to users that an > application is still 'live'. Someone else might like to hook into the frame > arrival events, to provide a progress indicator, as a large message is > received, and so on. I really thought that the low-level API is purely for > those who are prepared to learn the protocol and can find some advantage in > doing so. Also, Martin points out that having a solid API to call against, > that looks like the protocol, and a JMS layer on top of it, would mean that > a seperate native implementation could be provided, then it would be trivial > to do JMS with a native low-level driver, by wrapping the C implementation > as Java native methods. > > The proposed Qpid API looks too much like JMS to be a usefull seperate > concept. I think maybe you came up with the idea of mapping the protocol 1:1 > as a first cut, then realised that the end user wants something a little > different to call, and are now begining to realise that that thing is JMS, > hence are taking your API in that direction, without fully realising yet the > fact that JMS is what you really want. For example, there is a direct > parallel between the MessageSender and MessageReceiver and Consumer and > Publisher in JMS. > > There is little point in layering JMS on top of the proposed API, to my > thinking all it will represent is another layer to slow things down, not to > mention the added complication of translating exception hierarchies between > the layers. > > What we have at the moment in the 0-8 client (more or less) is the JMS > API, defined as interfaces and the Qpid API defined as interfaces, then a > common implementation that implements both sets of interfaces in a single > class; not in a layered way, but in a side-by-side way. AMQP specific calls > then becomes a 'horizontal' extension of JMS, rather than a sub-layer. > > I don't see any point in promoting a 'developer friendly' API in Java that > is not JMS. The developer friendly messaging API for java is JMS. > > Rupert >
