Arnuad, You should unset your reply-to, as I thought I was replying to the list, not realising I was sending messages only to you. We should discuss these things on the list.
rupert On 20/08/07, Rupert Smith <[EMAIL PROTECTED]> wrote: > > > > ---------- 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 > > > > >
