>From: Rajith Attapattu <[EMAIL PROTECTED]>
>Date: 27-Jul-2007 17:31
>Subject: Re: Java low level AMQP examples?
>To: [email protected]
>
>You can take a look at the shape of the API from here.
>https://svn.apache.org/repos/asf/incubator/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/nclient/api/
>
>Please provide feedback
>
>Regards,
>
>Rajith
Well, I am a little confused. I thought the idea was that the Qpid low level
client API was to 'closely follow the protocol'. Looking at this API I was
therefore expecting classes and methods something along the lines of:
public interface Connection
{ ... }
public interface Session
{
open(...)
flow(...)
close(...)
...
}
public interface Queue
{
declare(...)
bind(...)
unbind(...)
purge(...)
...
}
public interface Exchange
{ ... }
public interface Message
{
transfer(...)
consume(...)
...
}
That is to say, something that exposes the clients outgoing method call view
onto the spec in a pretty much literal manner, perhaps moved around a little
to provide the creation of resources relative to their containing concept.
For example,
connection.createSession(...) (or openSession)
session.createQueue(...) (or declareQueue)
or maybe:
Session session = connection.session.open(...)
Queue queue = session.queue.declare(...)
or split things like Session and Queue up into lifecycle (factory) and
normal use methods. For example,
interface SessionFactory
{
open(...)
}
then
Session mySession = connection.getSessionFactory ().open(...)
and so on.
Might we need to define interfaces, again mapping the protocol as 1:1 as
possible, for incoming methods? For example:
public interface MessageClientChassis
{
... transfer(...)
}
MessageClientChassis myHandler = new MessageClientChassis() { ...
transfer(...) { // do something interesting } };
session.message.consume(myHandler, myQueue, ...);
Or how about TransferListener, or MessageTransferListener instead of
MessageClientChassis?
So the low-level API, is there for those who want to hook into the incoming
AMQP method calls and deal with them directly (as the JMS client
implementation will want to). The proposed API looks like an AMQP flavoured
JMS to me, rather than 1:1 low-level AMQP.
The Resource interface confuses me. Why should a resource associated with a
session have a particular, and just one, queue associated with it? The
MessageSender interface that extends it only allows sending to that one
particular queue. Even the JMS API, although allowing creation of senders
with a default destination, has send methods to send to alternatives. It
would seem to me that the nice thing about AMQP is that it seperates all the
component parts of its messaging abstraction out into seperate 'classes',
connection, session, exchange, queue, exchange, message, which can be
combined freely within the semantics of the protocol. So the creation of an
interface that artificially forces the end user into a restricted
combination detracts from it. Please ditch Resource, its not a usefull
concept.
MessageListener and ExceptionListener are copies of the same interfaces in
JMS. Need we redefine them? I would have though a low-level API would deal
more directly in terms of AMQP error codes. I think it would be better to
use error codes than to throw exceptions, as error codes are not really
exceptions, they are an expected part of the protocol, rather than erronous
program states. I would expect exceptions to be there for situations like
the connection failing just after I call queue.declare and so on.
I would expect a low-level API to mirror the protocol as closely as it
possibly can in the target language, use the same class/method namings as
the protocol does, and allow EVERY method in the protocol to be called
directly or received directly through some sort of listener interface,
otherwise it is too weak an abstraction to be called low-level.
Also, how does this API fit in with the stub that Rafael is developing? For
example, the SessionDelegate looks like it might implement (or provide a
default implementation of) the incoming Session protocol calls. There was
something called AbstractInvoker in the first version of the stub that
seemed like a natural implementation point of the Session API, that is, its
the thing that client code calls to 'invoke' the protocol.
Rupert
