Should just have done that the first time round!
Here it is:
http://cwiki.apache.org/confluence/display/qpid/Low-Level+API+Diagram
Rupert
On 22/08/07, Rajith Attapattu <[EMAIL PROTECTED]> wrote:
>
> Rupert,
>
> I think the zip got filtered out.
> Howe about attaching it to the wiki and sending a link.
>
> Rajith
>
> On 8/22/07, Rupert Smith <[EMAIL PROTECTED]> wrote:
> >
> > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>
