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
