You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2007/04/02 20:43:15 UTC
[java] Client refactoring
Hi Folks,
I worked on refactoring the java client and have a prototype available for
comments.
https://svn.apache.org/repos/asf/incubator/qpid/branches/client_restructure/java/newclient/
All forms of feedback is greatly appreciated.
Attached is the design document and an example is available under
o.a.q.nclient.sample.TestClient on how to use the new API and
event/state notifications.
Summary
---------
The goals of the re-factoring are as follows.
1. Provide an AMQP protocol level API.
2. Achieve a clear separation of concerns.
3. Implement proper state and event handling.
4. Provide extensibility to extend the API at any level.
5. Provide a unified interface for configuration through jvm
arguments,xml ..etc. (Used commons configuration)
More information about the design can be found at
http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Client+refactoring
Regards,
Rajith
Re: [java] Client refactoring
Posted by Rajith Attapattu <ra...@gmail.com>.
Hey Rupert,
Thanks for the comments.
My comments are inline marked with [RA]
rajith
On 4/4/07, Rupert Smith <ru...@googlemail.com> wrote:
>
> Looks interesting, and good to see a document outlining an architecture in
> a
> clean and easy to understand way.
>
> A couple of questions:
>
> Do you think this level of layering is going to be necessary in the
> client?
> It sounds flexible and extensible but if that flexibility is not put to
> good
> use in practice, it may just add complexity. What is the use case for the
> extensibility?
[RA] The idea was to build a very low level API with various hooks in place
for a more high level API to build on top of.
Ex. The JMS API to build on top of this.
Do you think this level of layering might slow the client down? Getting from
> the client API down to the wire looks like it is going to be a
> considerably
> long chain of calls (another layer above for JMS, and Mina itself probably
> has a few layers below). I can imagine though, that the network itself
> will
> be sufficiently slow to make the effects of this negligible.
[RA] If you look at the old client you could still see these layers all
though not very visible or obvious.
TransportPhase - AMQProtocolHandler
ExecutionPhase - Request and Response Managers
ModelPhase - AMQStateManager & Handlers
Another problem was that there was no clear seperation of concerns within
those layers.
And that is something that has been addressed to a certain extent in this
refactoring.
If working on the AMQ client level API please give consideration to
> consistency accross all clients in qpid, wrt to naming of
> namespaces/packages, classes, methods, arguments etc. I have no time to
> dedicate towards that effort myself at the moment, so this is just a
> suggestion...
[RA] You mean across c++,python ...etc ?
Alan, Rafi can u comment ?
Also bear in mind that I never invented any new API. It's just a 1-1 map of
the AMQP protocol API.
Please keep the questions comming.
Regards,
Rajith
Rupert
>
> On 02/04/07, Rajith Attapattu <ra...@gmail.com> wrote:
> >
> > Hi Folks,
> >
> > I worked on refactoring the java client and have a prototype available
> for
> > comments.
> >
> >
> https://svn.apache.org/repos/asf/incubator/qpid/branches/client_restructure/java/newclient/
> >
> > All forms of feedback is greatly appreciated.
> > Attached is the design document and an example is available under
> > o.a.q.nclient.sample.TestClient on how to use the new API and
> > event/state notifications.
> >
> > Summary
> > ---------
> > The goals of the re-factoring are as follows.
> >
> > 1. Provide an AMQP protocol level API.
> > 2. Achieve a clear separation of concerns.
> > 3. Implement proper state and event handling.
> > 4. Provide extensibility to extend the API at any level.
> > 5. Provide a unified interface for configuration through jvm
> > arguments,xml ..etc. (Used commons configuration)
> >
> >
> > More information about the design can be found at
> >
> >
> http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Client+refactoring
> >
> > Regards,
> >
> > Rajith
> >
>
Re: [java] Client refactoring
Posted by Rupert Smith <ru...@googlemail.com>.
Looks interesting, and good to see a document outlining an architecture in a
clean and easy to understand way.
A couple of questions:
Do you think this level of layering is going to be necessary in the client?
It sounds flexible and extensible but if that flexibility is not put to good
use in practice, it may just add complexity. What is the use case for the
extensibility?
Do you think this level of layering might slow the client down? Getting from
the client API down to the wire looks like it is going to be a considerably
long chain of calls (another layer above for JMS, and Mina itself probably
has a few layers below). I can imagine though, that the network itself will
be sufficiently slow to make the effects of this negligible.
If working on the AMQ client level API please give consideration to
consistency accross all clients in qpid, wrt to naming of
namespaces/packages, classes, methods, arguments etc. I have no time to
dedicate towards that effort myself at the moment, so this is just a
suggestion...
Rupert
On 02/04/07, Rajith Attapattu <ra...@gmail.com> wrote:
>
> Hi Folks,
>
> I worked on refactoring the java client and have a prototype available for
> comments.
>
> https://svn.apache.org/repos/asf/incubator/qpid/branches/client_restructure/java/newclient/
>
> All forms of feedback is greatly appreciated.
> Attached is the design document and an example is available under
> o.a.q.nclient.sample.TestClient on how to use the new API and
> event/state notifications.
>
> Summary
> ---------
> The goals of the re-factoring are as follows.
>
> 1. Provide an AMQP protocol level API.
> 2. Achieve a clear separation of concerns.
> 3. Implement proper state and event handling.
> 4. Provide extensibility to extend the API at any level.
> 5. Provide a unified interface for configuration through jvm
> arguments,xml ..etc. (Used commons configuration)
>
>
> More information about the design can be found at
>
> http://cwiki.apache.org/confluence/display/qpid/Qpid+Java+Client+refactoring
>
> Regards,
>
> Rajith
>