I haven't had time yet to look at the specific points but in general, yes,
we are looking to decouple different layers of the codebase anyway in order
to make it easier to maintain and give flexibility to swap out different
bits.
Kim is working on making support for multiple protocol versions possible at
the moment and I think further decoupling of layers will make sense once he
has crystallised his thinking in that area.
RG
|---------+---------------------------->
| | "James Strachan" |
| | <[EMAIL PROTECTED]|
| | mail.com> |
| | |
| | 22/09/2006 13:16 |
| | Please respond to|
| | qpid-dev |
|---------+---------------------------->
>------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [email protected]
|
| cc:
|
| Subject: Re: A question for the ActiveMQ chaps on the list...
|
>------------------------------------------------------------------------------------------------------------------------------|
On 9/22/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
> James Strachan wrote:
> > If other messaging providers are to support AMQP then it'd make sense
> > to make it as easy as possible for folks to reuse as much of the basic
> > plumbing code from the qpid project as possible.
>
> I agree. This would be useful and is not currently addressed. Rajith's
> earlier proposal on a protocol level api would help on the client side.
> On the broker side I can see two levels at which there could be some
reuse.
>
> (i) The framing layer objects could be used to parse any stream, though
> they are currently tied to MINA.
>
> (ii) The whole io processing layer could be made more resuable, which is
> what your mail proposed.
>
> I think both are good goals. (i) would allow implementations that wanted
> to manage the threading and io themselves but still reuse the parsing
> code. (ii) allows implementations to focus purely on wiring the AMQP
> requests to their own internal structures.
Agreed - sounds good. If we get loads of users using AMQP in ActiveMQ
I can see us switching to (i) later on to avoid the MINA dependency
and allowing us to reuse our existing threading/transport stuff - but
to get started (ii) would be ideal.
> On (ii), as the java code stands, pluggability of 'method' handlers is
> done through a (state sensitive) registry. So one approach would be to
> allow the registered handlers to be reconfigured for different
> implementations. This is done through the AMQStateManager (and in fact
> in the clustering code I used this to get a cheap way of modifying
> handling of methods. This approach above only works for the 'methods',
> not content for which another plug-in point would be required. You're
> right of course that there is still quite a bit of cleanup work needed.
Yeah - I tried to tinker around there but as soon as AMQStateManager
is used it pulls in AMQMessage, AMQChannel, MessageStore,
QueueRegistry, ExchangeRegistery and pretty much the entire kitchen
sink pretty quickly :). So I was wondering if we could put a little
plugin a little lower down maybe to keep things as abstract as
possible to have things as loosely coupled as possible?
> We have something not unlike your suggestion in the c++ broker, where
> the handler logic is invoked through a series of interfaces matching the
> 'classes' of the protocol requests. Each method frame can invoke the
> method it represents on an instance of these interfaces (see a snippet
> below if interested). Content & header frames aren't treated this way,
> though we do have a InputHandler that simply handles any frame and gives
> a lower level separation from the io processing.
[snip]
Cool.
Am thinking if providers are trying to share code, there's not gonna
be whole lot of difference between the core part of the protocol in
terms of creating connections & channels; its mostly handling the
channel commands/methods where different implementations are gonna
want to plugin. The more of the basic plumbing code we can reuse (such
as validation of the commands and implementing the AMQP processing
rules etc) the better.
--
James
-------
http://radio.weblogs.com/0112098/
This communication is for informational purposes only. It is not intended as an
offer or solicitation for the purchase or sale of any financial instrument or
as an official confirmation of any transaction. All market prices, data and
other information are not warranted as to completeness or accuracy and are
subject to change without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and
affiliates.
This transmission may contain information that is privileged, confidential,
legally privileged, and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any disclosure,
copying, distribution, or use of the information contained herein (including
any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and
any attachments are believed to be free of any virus or other defect that might
affect any computer system into which it is received and opened, it is the
responsibility of the recipient to ensure that it is virus free and no
responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and
affiliates, as applicable, for any loss or damage arising in any way from its
use. If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
