activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)
Date Tue, 19 Sep 2006 05:32:30 GMT
On 9/18/06, Brian McCallister <brianm@apache.org> wrote:
> (Replying at top as it is a long message :-)
>
> The mapping be configured by naming a "converter" of some kind in the
> activemq.xml
>
> This is a bit tricksier than it might be because the activemq.xml is
> just a specialized spring config which reads a lot of stuff from a
> URL syntax, and adding Java classnames in a URL is the ick.
>

When you want to avoid icky long class names I recommend you use the
Factory pattern we for the transports, discovery agents, wire formats,
and event jdbc adapters.  Basically you can use the FactoryFinder to
map a simple string name to your 'converter' factory.

> I've started poking around and my current plan is to pull the AMQ
> message creating and Stomp message creation bits out of the protocol
> converter and use an implementation of some mapping interface to do
> the conversion.
>

sounds good to me.

> Exactly what the interface needs to look like I am not sure yet. In
> order to handle largish messages, it should probably deal with
> DataInput (AMQ's stream/buffer+channel hiding thing) instances, but
> we'll have had to already parse the type to get this far, so it may
> be a case of doing some parsing of the headers, and passing the data
> input in to be munged, or it may fall out that something else is more
> useful.

I'd keep it simple.  Avoid the DataInput stream for now until we prove
it's a performance problem.  I would start by just factoring out this
interface out of ProtocolConverter:

interface MappingStrategy {
	public StompFrame convertMessage(ActiveMQMessage message) throws
IOException, JMSException;
	public  ActiveMQMessage convertMessage(StompFrame command) throws
IOException, JMSException;
        public ActiveMQDestination convertDestination(String name)
throws ProtocolException;
       protected String convertDestination(Destination d);
}

and have a DefaultMappingStrategy that is implemented using the
current methods that are provided.   The ProtocolConverter would then
delegate to the MappingStrategy which is defaulted to a
DefaultMappingStrategy implementation.  But our Stomp transport would
then have an additional configurable string property
'mappingStrategy'.  If it's set, we use that string to look up a
MappingStrategyFactory using the FactoryFinder.

>
> For encoding AMQ to stomp, we are faced with something similar -- we
> pass in the JMS message, which might be a stream message with a large
> body, we probably want to be able to "chunk" it out, that means
> either making a stomp frame abstraction which can read from a stream
> and is returned by the converter, or having the converter actually
> "send" the message on the wire. Not sure which I like more.
>
> Thoughts?
>

I say keep it simple.  the current method signatures of the
convertMessage methods should work.

> -Brian
>
> On Sep 18, 2006, at 7:45 AM, Dejan Bosanac wrote:
>
> > Thanks James.
> >
> >
> >>
> >> We've a Stomp transport for ActiveMQ which is here...
> >> http://incubator.apache.org/activemq/maven/activemq-core/xref/org/
> >> apache/activemq/transport/stomp/package-summary.html
> >>
> >> which can currently deal with all the stomp messages nicely. Maybe
> >> you
> >> mean to extend that? Or did you have something else in mind?
> >>
> >
> >
> > In one of his comments Brian said that he plans to create pluggable
> > handling framework for stomp messages for ActiveMQ 4.1.
> >
> > Following that idea, I have even found a discussion on this topic
> >
> > http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/
> > 200606.mbox/%
> > 3Caf2843cd0606131045k1084ec85qd337a076af47c363@mail.gmail.com%3E
> >
> > which is related to handling of ByteMessages.
> >
> >
> > I thought that this is exactly what I would like to have for handling
> > of this kind of "map" messages. As I see it, it would be the best to
> > extend functionality of the
> >
> > public  ActiveMQMessage convertMessage(StompFrame command)
> >
> > method in the
> >
> > org.apache.activemq.transport.stomp.ProtocolConverter
> >
> > class
> >
> > I can add hard-coded mapping for this special case, or as Brian said,
> > introduce some additional flexibility by allowing developers to submit
> > their own converter classes at this point. Who knows what other
> > "protocol" on top of Stomp someone would be interesting to create in
> > the future (or what kind of object serialization/deserialization to
> > perform).
> >
> > The only thing that I'm not sure of is how these plugins would be
> > configured.
> >
> > In any case, I won't start doing any work on this before we agree on
> > how this functionality should look like, or whether it is necessary to
> > make any changes at all.
> >
> > Dejan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >    http://xircles.codehaus.org/manage_email
> >
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message