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