You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Robert Godfrey <ro...@gmail.com> on 2010/01/04 17:27:12 UTC
C++ and Java Broker common configuration and tooling
Happy New Year all...
So, at the start of this new year I think it is important that we try to
focus on improving the experience of our project... and in particular I
think we should be looking at making the project look like a single coherent
whole.
Currently the Java and C++ Brokers look and behave almost completely
differently, and I think we all should be trying hard to remedy that
situation.
The first step in my grand plan to fix this was obviously implementing AMQP
0-10
The next task I set myself was to investigate how we can use a single set of
management and configuration tools across the two brokers such that the user
experience is common.
To that end I have spent the last couple of weeks implementing a prototype
QMF management layer in the Java Broker, attempting to use the same
management schema as used by the C++ broker. Further I have implemented the
required methods to enable federation between Java and C++ (and to use the
same tools to set it up) - both static and dynamic routing has been
implemented.
Once trunk is unfrozen I will be able to apply my patch that provides for
qpid-tool, qpid-route et. al to work against the Java Broker.
In implementing QMF Management and Federation I have come up against a
number of obstacles caused by assumptions built in to the QMF management
schema that are based on the behaviour of the C++ broker (e.g. that it
doesn't support multiple vhosts), I also have a number of
questions/comments on the schema as a whole. I've collected all these on
the following wiki page:
http://cwiki.apache.org/confluence/display/qpid/Broker+Management+QMF+Coverage
I would be grateful if those familiar with the C++ broker and it's
management could answer some of the questions therein... Further I would
like to get feedback on my comments and suggestions for additions to the
management capabilities. From those more familiar with the Java management
capabilities - a review to point out any other capabilities that cannot be
carried out through QMF would be very helpful.
In terms of next steps in uniting the user experience:
1) I think we need to collectively agree on how we can update the management
schema to work fully with the Java Broker and hopefully to expand its
coverage to that it encompasses everything that can currently be performed
by the Java JMX management solution.
2) I will be trying to put together a wiki page of all the "extensions" to
AMQP that the brokers currently implement (e.g. arguments to queue/exchange
declare, bind,subscribe, etc...). ultimately we should try to unify these
as well - and also to define a mechanism so that clients can detect on
connection which extensions are available.
Beyond the configuration and management work I've started already, the
biggest gap is probably ACLs - and I've not looked at all at that yet.
Overall I think with a bit of work from both the C++ and Java communities we
can get the brokers to look and behave much more similarly... however we
will also need to change the way we work a bit so that when we decide to add
new features we attempt to discuss and agree before implementing. It will do
no good to get the brokers temporarily aligned if they immediately begin to
drift apart again.
Your thoughts?
-- Rob
Re: C++ and Java Broker common configuration and tooling
Posted by Gordon Sim <gs...@redhat.com>.
On 01/04/2010 04:27 PM, Robert Godfrey wrote:
> Happy New Year all...
>
> So, at the start of this new year I think it is important that we try to
> focus on improving the experience of our project... and in particular I
> think we should be looking at making the project look like a single coherent
> whole.
I agree, that is a valuable goal.
> Currently the Java and C++ Brokers look and behave almost completely
> differently, and I think we all should be trying hard to remedy that
> situation.
>
> The first step in my grand plan to fix this was obviously implementing AMQP
> 0-10
>
> The next task I set myself was to investigate how we can use a single set of
> management and configuration tools across the two brokers such that the user
> experience is common.
>
> To that end I have spent the last couple of weeks implementing a prototype
> QMF management layer in the Java Broker, attempting to use the same
> management schema as used by the C++ broker. Further I have implemented the
> required methods to enable federation between Java and C++ (and to use the
> same tools to set it up) - both static and dynamic routing has been
> implemented.
Excellent, thanks for your hard work! (I feel suitably embarrassed
having spent the last two weeks eating and sleeping!)
> Once trunk is unfrozen I will be able to apply my patch that provides for
> qpid-tool, qpid-route et. al to work against the Java Broker.
>
> In implementing QMF Management and Federation I have come up against a
> number of obstacles caused by assumptions built in to the QMF management
> schema that are based on the behaviour of the C++ broker (e.g. that it
> doesn't support multiple vhosts), I also have a number of
> questions/comments on the schema as a whole. I've collected all these on
> the following wiki page:
>
> http://cwiki.apache.org/confluence/display/qpid/Broker+Management+QMF+Coverage
>
> I would be grateful if those familiar with the C++ broker and it's
> management could answer some of the questions therein... Further I would
> like to get feedback on my comments and suggestions for additions to the
> management capabilities. From those more familiar with the Java management
> capabilities - a review to point out any other capabilities that cannot be
> carried out through QMF would be very helpful.
>
> In terms of next steps in uniting the user experience:
>
> 1) I think we need to collectively agree on how we can update the management
> schema to work fully with the Java Broker and hopefully to expand its
> coverage to that it encompasses everything that can currently be performed
> by the Java JMX management solution.
>
> 2) I will be trying to put together a wiki page of all the "extensions" to
> AMQP that the brokers currently implement (e.g. arguments to queue/exchange
> declare, bind,subscribe, etc...). ultimately we should try to unify these
> as well - and also to define a mechanism so that clients can detect on
> connection which extensions are available.
>
> Beyond the configuration and management work I've started already, the
> biggest gap is probably ACLs - and I've not looked at all at that yet.
>
> Overall I think with a bit of work from both the C++ and Java communities we
> can get the brokers to look and behave much more similarly... however we
> will also need to change the way we work a bit so that when we decide to add
> new features we attempt to discuss and agree before implementing. It will do
> no good to get the brokers temporarily aligned if they immediately begin to
> drift apart again.
>
> Your thoughts?
Thanks for taking the lead on this! I think this would greatly benefit
to the Qpid community.
(I have filled in some detail on the c++ extensions and added a few
comments/answers on the management coverage page to begin with).
--Gordon.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> I don't wish to overcomplicate, but do you want some grouping of features...
> (e.g. a parentFeature tag) if we're looking at the same sort of granularity
> as unit tests, that should be quite fine... but many of them may be aspects
> of the same "feature"...
Quite possibly. I suspect the format requirements will become more
apparent as more content is added. Maybe the first step is to identify
all the existing feature-list-type content we have and then see how
amenable it all is to being massaged into a single format.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
Posted by Robert Godfrey <ro...@gmail.com>.
I don't wish to overcomplicate, but do you want some grouping of features...
(e.g. a parentFeature tag) if we're looking at the same sort of granularity
as unit tests, that should be quite fine... but many of them may be aspects
of the same "feature"...
-- Rob
2010/1/6 Rafael Schloming <ra...@redhat.com>
> Alan Conway wrote:
>
>> On 01/06/2010 06:52 AM, Robert Godfrey wrote:
>>
>>> 2010/1/6 Rafael Schloming<ra...@redhat.com>
>>>
>>> Robert Godfrey wrote:
>>>>
>>>> Overall I think with a bit of work from both the C++ and Java
>>>>> communities
>>>>> we
>>>>> can get the brokers to look and behave much more similarly... however
>>>>> we
>>>>> will also need to change the way we work a bit so that when we decide
>>>>> to
>>>>> add
>>>>> new features we attempt to discuss and agree before implementing. It
>>>>> will
>>>>> do
>>>>> no good to get the brokers temporarily aligned if they immediately
>>>>> begin
>>>>> to
>>>>> drift apart again.
>>>>>
>>>>>
>>>> I'm just thinking aloud here, but perhaps it would help to gather our
>>>> various disparate documentation snippits into a single canonical feature
>>>> glossary somewhere in SVN. Ideally in some format that could be easily
>>>> fed
>>>> into the documentation, but could also serve as a source for other
>>>> things
>>>> such as generating test matrices, and doing feature based coverage
>>>> analysis.
>>>>
>>>> --Rafael
>>>>
>>>>
>>>>
>>>> That sounds like an excellent idea...
>>>
>>>
>> Can jrobie's proposed docbook for documentation project provide the right
>> format for this? It's XML so should be possible to generate various types of
>> file. Seems like something we want to be able to inject into the user doc as
>> well.
>>
>
> Possibly, I'm not a docbook expert. Either way I suspect a simple XML file
> could be trivially transformed into docbook and whatever else we need, e.g.
> something along the lines of:
>
> <feature name="foo" title="Foo">
> <description>
> Blah blah blah.
> </description>
>
> <component name="java-broker"/>
> <component name="cpp-broker"/>
>
> <test ref="pointer-to-test"/>
> ...
> </feature>
>
> I'm not sure the extent to which we want to cross reference
> tests/components/etc against this sort of thing. If that's something we feel
> would be valuable then I suspect making up a simple XML format and
> translating to docbook would be the way to go. If on the other hand it's
> essentially just a documentation-only feature glossary then I'm sure docbook
> alone would be sufficient.
>
> As long as the format is fairly regular, I'm not particularly fussed either
> way as it should be straightforward to translate later if necessary.
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: C++ and Java Broker common configuration and tooling
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 01/06/2010 06:52 AM, Robert Godfrey wrote:
>> 2010/1/6 Rafael Schloming<ra...@redhat.com>
>>
>>> Robert Godfrey wrote:
>>>
>>>> Overall I think with a bit of work from both the C++ and Java
>>>> communities
>>>> we
>>>> can get the brokers to look and behave much more similarly...
>>>> however we
>>>> will also need to change the way we work a bit so that when we
>>>> decide to
>>>> add
>>>> new features we attempt to discuss and agree before implementing. It
>>>> will
>>>> do
>>>> no good to get the brokers temporarily aligned if they immediately
>>>> begin
>>>> to
>>>> drift apart again.
>>>>
>>>
>>> I'm just thinking aloud here, but perhaps it would help to gather our
>>> various disparate documentation snippits into a single canonical feature
>>> glossary somewhere in SVN. Ideally in some format that could be
>>> easily fed
>>> into the documentation, but could also serve as a source for other
>>> things
>>> such as generating test matrices, and doing feature based coverage
>>> analysis.
>>>
>>> --Rafael
>>>
>>>
>>>
>> That sounds like an excellent idea...
>>
>
> Can jrobie's proposed docbook for documentation project provide the
> right format for this? It's XML so should be possible to generate
> various types of file. Seems like something we want to be able to inject
> into the user doc as well.
Possibly, I'm not a docbook expert. Either way I suspect a simple XML
file could be trivially transformed into docbook and whatever else we
need, e.g. something along the lines of:
<feature name="foo" title="Foo">
<description>
Blah blah blah.
</description>
<component name="java-broker"/>
<component name="cpp-broker"/>
<test ref="pointer-to-test"/>
...
</feature>
I'm not sure the extent to which we want to cross reference
tests/components/etc against this sort of thing. If that's something we
feel would be valuable then I suspect making up a simple XML format and
translating to docbook would be the way to go. If on the other hand it's
essentially just a documentation-only feature glossary then I'm sure
docbook alone would be sufficient.
As long as the format is fairly regular, I'm not particularly fussed
either way as it should be straightforward to translate later if necessary.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
Posted by Alan Conway <ac...@redhat.com>.
On 01/06/2010 06:52 AM, Robert Godfrey wrote:
> 2010/1/6 Rafael Schloming<ra...@redhat.com>
>
>> Robert Godfrey wrote:
>>
>>> Overall I think with a bit of work from both the C++ and Java communities
>>> we
>>> can get the brokers to look and behave much more similarly... however we
>>> will also need to change the way we work a bit so that when we decide to
>>> add
>>> new features we attempt to discuss and agree before implementing. It will
>>> do
>>> no good to get the brokers temporarily aligned if they immediately begin
>>> to
>>> drift apart again.
>>>
>>
>> I'm just thinking aloud here, but perhaps it would help to gather our
>> various disparate documentation snippits into a single canonical feature
>> glossary somewhere in SVN. Ideally in some format that could be easily fed
>> into the documentation, but could also serve as a source for other things
>> such as generating test matrices, and doing feature based coverage analysis.
>>
>> --Rafael
>>
>>
>>
> That sounds like an excellent idea...
>
Can jrobie's proposed docbook for documentation project provide the right format
for this? It's XML so should be possible to generate various types of file.
Seems like something we want to be able to inject into the user doc as well.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: C++ and Java Broker common configuration and tooling
Posted by Robert Godfrey <ro...@gmail.com>.
2010/1/6 Rafael Schloming <ra...@redhat.com>
> Robert Godfrey wrote:
>
>> Overall I think with a bit of work from both the C++ and Java communities
>> we
>> can get the brokers to look and behave much more similarly... however we
>> will also need to change the way we work a bit so that when we decide to
>> add
>> new features we attempt to discuss and agree before implementing. It will
>> do
>> no good to get the brokers temporarily aligned if they immediately begin
>> to
>> drift apart again.
>>
>
> I'm just thinking aloud here, but perhaps it would help to gather our
> various disparate documentation snippits into a single canonical feature
> glossary somewhere in SVN. Ideally in some format that could be easily fed
> into the documentation, but could also serve as a source for other things
> such as generating test matrices, and doing feature based coverage analysis.
>
> --Rafael
>
>
>
That sounds like an excellent idea...
-- Rob
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: C++ and Java Broker common configuration and tooling
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> Overall I think with a bit of work from both the C++ and Java communities we
> can get the brokers to look and behave much more similarly... however we
> will also need to change the way we work a bit so that when we decide to add
> new features we attempt to discuss and agree before implementing. It will do
> no good to get the brokers temporarily aligned if they immediately begin to
> drift apart again.
I'm just thinking aloud here, but perhaps it would help to gather our
various disparate documentation snippits into a single canonical feature
glossary somewhere in SVN. Ideally in some format that could be easily
fed into the documentation, but could also serve as a source for other
things such as generating test matrices, and doing feature based
coverage analysis.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org