---------- Forwarded message ---------- From: Rupert Smith <[EMAIL PROTECTED]> Date: 20-Aug-2007 16:23 Subject: Re: [Java] Message API design notes To: [EMAIL PROTECTED]
I find it strange though because it is like JMS in a parallel universe: JMS Qpid Connection Connection Session Session MessageListener MessageListener ExceptionListener ExceptionListener Message Message BytesMessage ByteBufferMessage ? FileMessage (why in terms of files? could be more abstract in terms of InputStream?) Only, it is not as if the Qpid API is a super-type of the JMS API that you propose to put on top of it. Therefore, the JMS api must extend the Qpid one by 'delegation' or 'wrapping' the Qpid one, and translating. In other words the Qpid and JMS APIs are at a similar level of abstraction, therefore the Qpid API does not naturally form a lower layer to implement JMS on top of, but sits uncomfortably as an extra layer to be translated through. Also, the fact that the Qpid API is a reasonably close copy of the JMS API renders it... kind of pointless. Why bother to repeat concepts like these, when horizontal extension means you can take what JMS already provides and only add to it, rather than duplicating. I think it is the duplicating of the same level of abstraction that bothers me. Rupert On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-08-20 at 15:54 +0100, Rupert Smith wrote: > > On 20/08/07, Arnaud Simon <[EMAIL PROTECTED]> wrote: > > So today the current API could be seen as part of the JMS > > implementation > > i.e. some useful methods for interfacing with the common > > layer. > > Back on the JMS extensions, I haven't implemented them yet. > > The idea is > > to have first the JMS tck passing then to provide support for > > the JMS > > extensions. What do you think? Does that make sense? > > > > It makes some sense, totally fine with things being done in stages. > > > > I just think that this proposed API does not actually look very > > useful, as a 'useful' layer to put between the JMS implementation and > > the comm layer. It looks to me like it would be better to be putting > > the JMS layer straight onto to comm layer, without this 'strange > > cousin' of JMS getting in the way; > > You should have a closer look at it as this API is a close mapping of > the protocol (at least what the JMS layer needs from the AMQP protocol). > The only thing that it does is providing: > - connection negotiation > - synchronization points > - message assembly facilities > - clustering support > > > as I've said before it just seems like an extra layer for no good > > reason (other than perhaps, creating work for people?). Be great if > > the JMS layer can implements a ProtocolClient delegate, and call a > > ProtocolBroker invoker, and be capable of being aware of every event > > in the protocol if it needs to. That is, expose the whole protocol > > through a interface only API, and put the JMS on top of it, handling > > and calling just what it needs to. > > As I said this is pretty much what the current API doe so it should not > be a big deal to move to such a solution if we decide to go for it. Note > that I have nothing against your proposal that I think makes sense. > > > Also, as far as a Qpid API is concerned, there was general agreement > > some months ago, when this was all debated before, that such an API > > should 'look like the protocol'. > > +1, however I may slightly disagree with you as I think that the current > API is very close to the AMQP protocol. > > Arnaud > >
