There is a subtle difference between the structure I have described, that is
dimensions 1 + 2, versus the comm layer + proposed client API as a layered
system.
As two separate dimensions, a client application would be coded against both.
It would use dimension 1 to invoke the protocol directly as an API defined
purely in terms of interfaces (server chassis). It would use dimension 2 as
a concrete utility set for doing the common interactions that customers do
not want to have to recode themselves. This is the idea behind the
interfaces ProtocolBroker and ProtocolConversation that I described. For
example:
// This is the utility class, it provides the same interface as the AMQP
protocol 1:1 API, by extending ProtocolBroker.
// It implements ProtocolClient, because it can be registered as a delegate,
for the comm layer (or direct in-vm routing layer) to notify of
// events.
// It adds synchronous receive methods to wait for incoming methods, and
utility methods for the common interaction stuff.
public ProtocolConversation extends ProtocolBroker , ProtocolClient
{
// To block for incoming methods.
public MethodSessionAttached receiveSessionAttached();
... and so on.
// Common interactions.
public ConnectionContext openConnectionSequence();
public SessionContext openSessionSequence(ConnectionContext connection);
.... and so on.
}
In the layered approach, using the proposed client API, you are presenting
the client API as a complete abstraction with a different interface to that
which the comm layer presents. As an abstraction it presents a complete
environment for client to program against. It re-presents the direct
protocol 1:1 API a second time, as a completely separate type, filtering
down to just what a client needs to program against, fair enough, but to me
this unnecessary fragmentation or duplication of the type structure of the
program. That is, its not as if you have Session from the proposed client
API, implementing Invoker from the comm layer, even though both are
presenting AMQP 1:1.
I am proposing the use of interfaces as a common abstraction that I can pull
out of both the comm layer, and the client API, not to mention some future
broker routing layer that we will have.
This discussion about the layering of the protocol has given me another
idea. If the end client only needs to see model layer + a limited amount of
stuff from some of other layers too? This can be presented as a trimmed down
version of the full 1:1 protocol API (you guessed it, as an interface,
whoopee!) for the sole purpose of writing clients apps against. So at the
moment I have ProtocolBroker, which exposes the whole of the AMQP server
chassis. I can also define:
public interface ClientInvoker
{
// public void declareQueue(SessionContext session, MethodQueueDeclare
qd);
// But I think we are preferring the exposed argument form for coding
against, fair enough, I do too.
public void declareQueue(SessionContext session, String queueName,
boolean durable, Blah blah);
// And so on...
}
// This one is equivalent to MessageListener, but expressed more directly in
terms of AMQP.
public interface ClientDelegate
{
public void messageTransfer(SessionContext session,
MethodMessageTransfer mt);
// I'm not sure now what pings are going to look like, so this is just a
guess, but I think you get the idea.
public void pingPing(ConnectionContext connection, MethodPingPing pp);
// or is it session context?
// And so on, for whatever else we thinks clients are going to want to
see...
}
I would just make sure that I mark the ProtocolBroker and ProtocolClient, as
extending both of these interfaces. Nothing else needs to be done, as these
methods are already in the ProtocolBroker and ProtocolClient interfaces
because of the ClassXXX interfaces that they extend. Quick example:
public interface ProtocolBroker extends ClassMessageBroker,
ClassSessionBroker, ClassExecutionBroker, ... , ClientInvoker
public interface ProtocolClient extends ClassMessageClient,
ClassSessionClient, ClassExecutionClient, ..., ClientDelegate
Then I can add to the factory methods that return narrowed, client only
interfaces (for dummies):
public interface ProtocolFactory
{
// To get full invokers to call the protocol through.
public ProtocolBroker getBrokerInvoker();
public ProtocolClient getClientInvoker();
// To register delegates to be informed of incoming methods-as-events.
public void registerBrokerDelegate(ProtocolBroker delegate);
public void registerClientDelegate(ProtocolClient delegate);
// To get/register narrowed down invokers/delegates for client
applications.
public ClientInvoker getClientInvoker();
public void registerClientDelegate(ClientDelegate delegate);
}
Implementation of getClientInvoker will just be:
ProtocolBroker invoker;
public ClientInvoker getClientInvoker()
{
return (ClientInvoker)invoker;
}
Sorry, I need to think of some better names for these things, ClientInvoker
is pretty confusing, given that it is a narrowing of ProtocolBroker.
Do note, that I am not proposing getting rid of the existing
invoker+delegate model of the comm layer, which is neat, just slicing the
interfaces a little more finely (I must have said this about 5 times). After
all, the protocol is not symmetrical, in the sense that client and server
chassis are different. (It has an inverse symmetry in the sense that the
interface that the client calls is the one that the broker implements, but
that is a different idea altogether, and is what I based my idea of plugging
a client directly into an in-vm broker around). Look back, please, at the
diagram I sent. Did everyone get that btw? I hope the Apache list did not
filter the attached Zip file out.
As for the broker being a client for broker-to-broker communication, I think
there is something to be said for having an asymmetrical protocol. Imagine a
jigsaw. Lets think of a client as 'outy' piece and a broker as an 'inny'
piece. Neither kind of piece on its own is particularly useful. Plug a
client into a broker (direct in-vm, if you please) and you have a universal
connector; the fabled 'inny-outy' piece. Now you can build whatever graph
you like out of these connector pieces. There is no need to make the
protocol symmetric for broker-2-broker communications.
Some good points from Martin, I think. Our customers use JMS, we can't ask
them to rewrite their apps, they've got better things to spend their time
and money on. Lets offer them new capabilities, that they can take at their
own pace.
can u c it yet rajith? bcos i think u gonna like it. (my bad).
Rupert
On 21/08/07, Rajith Attapattu < [EMAIL PROTECTED] > wrote:
>
> Yes I believe the Qpid API sits above the API you talk about.
> And I would like that to be the API we promote to users as a client.
>
> What you are essentially talking about is a slightly different approach to
> how the comm layer should expose it self.
> We need that API for sanity and design purposes. End users may also use it
> if they want to build their own client or broker.
> So lets not confuse that with the Client API discussion.
>
> I believe Rafi can answer you better as to why he didn't use the interface
> approach or as to why he didn't split into seperate classes.
> Also I am not sure spliting up server and client chasis make much sense.
> Bcos a broker can be a client to anothe Broker.
> Can u elaborate a bit more as to why you would need to make such a
> distinction.
>
> I think an Invoker and a Delegate makes more sense.
> Invoker being the methods you can call and Delegate being the method that
> somebody else can call you with out making any distinction as server or
> client.
>
>
> On 8/21/07, Rupert Smith < [EMAIL PROTECTED]> wrote:
> >
> > Yes, but my proposal differs slightly, in that it uses interfaces, not
> > concrete classes, and splits server and client chassis up. Other than
> > that,
> > yes, the comm layer seems to fit the bill perfectly. No surprise, given
> > that
> > I started with Rafeal's stub and pulled an interface only API out of it.
> >
> > On 21/08/07, Rajith Attapattu < [EMAIL PROTECTED]> wrote:
> > >
> > > On 8/21/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On 21/08/07, Carl Trieloff < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Watching the debate, I think you guys are actually quite close to
> > each
> > > > > other.
> > > >
> > > >
> > > > Yes, as I say, we are to some extent talking at cross purposes. I'm
> > > > primarily coming from the point of view of modularizing, and
> allowing
> > > > multiple implementations of a common set of interfaces. I think
> Rajith
> > > is
> > > > primarily looking at things from the point of view of offering a
> > client
> > > > API.
> > > > I'm actually thinking of an API that is for both the client and the
> > > > broker,
> > > > to call into a shared comm layer.
> > >
> > >
> > > Rupert, there is code in common module that satisfies your criteria
> > > a.k.acomm layer.
> > > I guess we can disucss this more in detail when we all meet at the
> f2f.
> > > The idea is to have a common API that will provide a basis for a
> client
> > > and
> > > broker implementation.
> > > If a user wants to hook into this layer, then that is possible as
> well.
> > >
> > > The client API that I am talking about is a thin layer on top of this
> > > common
> > > API.
> > > Which provides connection negotiation, failover and a few convinience
> > > methods.
> > > 90% of the method invocations are directly called on the comm layer.
> > > If u look at the code.
> > > ClientSession implements o.a.q.client.Session extends
> > o.a.q.Sessionextends
> > > Invoker.
> > >
> > > The o.a.q.Session is part of the comm layer and will be used by both
> > > broker
> > > and client.
> > > The o.a.q.client.Session is just a mask for exposing only what is
> > > appropriate and useful for a client + sugar.
> > >
> > > So we seem to be in agreement.
> > >
> > > > L1 - Transport
> > > > > L2 - Session
> > > > > L3 - Execution
> > > > > L4 - Model
> > > >
> > > > This is something for me to think about, because I have not tried to
> > > take
> > > > this into account. My idea to expose the whole protocol, is
> completely
> > > > flat
> > > > wrt this layering. The reason I thought every method has to be
> > exposed,
> > > is
> > > > so that the client can be plugged direct into the broker in-vm or
> into
> > a
> > > > comm layer for going over the network. Sounds like I need to expose
> > > layers
> > > > 2-4 in full, in order to do this.
> > > >
> > > > Is it the case that every method belongs to one of these layers? In
> > > which
> > > > case, will the layer numbers be put into the 0-10 xml?
> > > >
> > > > Rupert
> > > >
> > >
> >
>
