qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rupert Smith" <rupertlssm...@googlemail.com>
Subject Re: Qpid Java Design [ was Re: Proposed QPID API Discussion]
Date Thu, 02 Aug 2007 14:55:29 GMT
So the generic 'handle' method has its uses, but it may be something that is
to remain internal to the comm layer, rather than exposed as part of the
API.

On 02/08/07, Rafael Schloming <rafaels@redhat.com> wrote:
>
> Rupert Smith wrote:
> > I think that both Alan and I are saying that use of (QueueDeclare qd) as
> an
> > argument to the queueDeclare method has advantages over using (String
> > queueName, boolean durable, ...)
>
> I agree. The only exception I have made to this in the design of the
> code in org/apache/qpidity is to provide the Invoker abstract class as a
> convenient alternative to manually constructing the QueueDeclare and
> then passing it in. As I see it there are no disadvantages to providing
> this alternative because you can always use the other form if you wish.
>
> > The difference between the two eaxample you give, is whether the method
> > handler is a generic 'handle' method or a specifically names
> 'queueDeclare'
> > method. But that wasn't really the point being made by either of us.
>
> I must have read that into Alan's post.
>
> > For the record, I think for an API, the specific method name is
> superior. I
> > could be won around to the generic 'handle' method point of view, if you
> > would care to try and pursuade me.
>
> I agree that the specific method name is superior, particularly for
> handling incoming method calls as it permits the delegate itself to be
> stateful in its handling of incoming methods. This is actually quite
> important as it provides a powerful tool for isolating the core of the
> broker from details of the protocol interaction.
>
> --Rafael
>
> >
> > Rupert
> >
> > On 02/08/07, Rafael Schloming <rafaels@redhat.com> wrote:
> >> Alan Conway wrote:
> >>> On Thu, 2007-08-02 at 10:07 +0100, Rupert Smith wrote:
> >>>> Hi,
> >>>>
> >>>> I have thought of another reason why I think the AMQP methods as
> >> interfaces
> >>>> approach may be useful. As already mentioned the delegate/invoker
> >> interfaces
> >>>> are symmetric opposites viewed from the client and broker sides. This
> >> means
> >>>> that the routing/delivery layer of the broker will implemented the
> >> invoker
> >>>> interface for incoming method calls, and the client will implement it
> >> for
> >>>> outgoing method calls.
> >>>>
> >>>> Quick example:
> >>>>
> >>>> interface MessageInvoker
> >>>> {
> >>>>    public void messageTransfer(Session context, MessageTransfer mt);
> >>>>    ... more
> >>>> }
> >>>>
> >>>> class ClientMessageImpl implements MessageInvoker { ... }
> >>>>
> >>>> class BrokerDeliveryEngine implements MessageInvoker { ... }
> >>> That's pretty much how the C++ broker does it except each AMQP class
> is
> >>> an interface i.e. you have Message { transfer(...); get(...); etc. }
> >>> I would quite like to break them into individual per-method interfaces
> >>> because it gives more flexibility to distribute the work among classes
> >>> (e.g. the clustering stuff wants to treat "wiring" differently from
> >>> "non-wiring" which means handling a subset of the Queue and Exchange
> >>> classes.) Not sure if this will happen in C++ in the immediate future
> >>> though, as most of the clustering work so far is dealing with frames
> >>> below the semantic layer.
> >> I'm not sure Rupert and Alan are talking about the same thing. As I
> >> understand it Alan is talking about having distinct classes handling
> >> incoming methods, and Rupert is talking about using interfaces rather
> >> than method arguments as part of the client API.
> >>
> >> From what I understand, Rupert is suggesting that this is a superior
> >> client API:
> >>
> >>    QueueDeclare qdecl = factory.newQueueDeclare("queue-name", ...);
> >>    ssn.queueDeclare(qdecl);
> >>
> >> And I believe Alan is suggesting that this is a superior interface for
> >> handling incoming methods:
> >>
> >>    QueueDeclareHandler {
> >>        public void handle(Session ssn, QueueDeclare qdecl);
> >>    }
> >>
> >> I'm pretty sure one of the three of us is confused. Are the above
> >> descriptions accurate or am I the one that is confused?
> >>
> >> --Rafael
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message