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.
