On 03/24/2011 10:25 AM, Robert Godfrey wrote:
On 24 March 2011 15:11, Rafael Schloming<[email protected]> wrote:
On 03/24/2011 09:57 AM, Robert Godfrey wrote:
On 24 March 2011 14:47, Rafael Schloming<[email protected]> wrote:
*snip*
I agree with your suggested goal. I would actually go slightly farther and
say that pragmatically to succeed we need a much less confusing story for
users than we have right now, so a further goal for the 1-0 work needs to be
to supplant the many obviously separate parts of qpid with a more coherent
suite of artifacts.
I don't want to bite off more than we can chew - but I certainly agree that
we need to make Qpid a much more coherent story than it is now. However,
possibly that's a slightly different, though equally important, objective to
the one we seem to be discussing now. If we can direct our energies so that
the necessary energies we need to expend to get Qpid speaking AMQP 1-0, with
the necessary number of client language bindings... and at the same time
increase the commonality of API, functionality and configuration for other
artefacts (brokers in particular) that would be a spectacular success.
I does seem to me though that we should first set our sights firmly on
achievable goals... and defining and implementing a "common transport layer"
(even if to start off with it is not actually in use in the current
artefacts) is a very achievable goal.
As for what I mean by a common transport layer, I think it’s useful to
consider two different dimensions of the problem: firstly, sharing a
transport implementation between different programming models within a
homogenous environment, e.g. a broker and a client, and secondly sharing an
implementation between heterogenous environments, i.e. different languages.
I’ve attached a presentation that introduces some of my ideas at a high
level. I think some people have seen this already, but it's probably a good
time to share with a broader audience. I’ve also been doing some prototyping
work exploring an architecture that addresses both of these points in the
context of a 1-0 implementation. I have a more complete python version and a
less complete (but improving) C version, both currently hosted at github:
https://github.com/rhs/amqp (python prototype)
https://github.com/rhs/amp (C prototype)
Note that the github location is purely for convenience of sharing and
backup until I have something that will make sense to introduce to qpid.
As for how to incorporate this into qpid, I think if we want to become a
ubiquitous protocol implementation, then the transport has to be an
independently available component that is easily embeddable within third
party apps that wish to integrate with messaging. As such it needs to have
as few dependencies as possible and a very narrow and well considered set of
interfaces. Given this, the natural way to develop this would be as an
independent sub project within qpid, so that from the start we are forced to
observe good packaging and dependency practices and consider our interfaces
carefully.
So - as above... this sounds like the beginning of a plan. I really need to
have a better idea of the sort of interfaces you are talking about between
the different components of your architecture... do you think it would be
useful to produce some sort of UML diagram showing how you thing the
interfaces between these would look?
Yes, I think that would be useful. In fact I've already taken a very
brief look at umlgraph which is purported to be able to automatically
produce UML diagrams from annotated java code. From what I understand
it's basically just a doclet that processes the class hierarchy and
produces a graphviz representation. This might be a good place to start,
it would be easy to throw together a few skeletal java classes that
match the interfaces currently in the python prototype.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
