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
> > > > >
> > > >
> > >
> >
>
