activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac" <de...@nighttale.net>
Subject Re: [stomp-dev] Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)
Date Tue, 19 Sep 2006 08:28:59 GMT
And one copy for this list as I assume that we will continue discussion here :)

On 9/19/06, Dejan Bosanac <dejan@nighttale.net> wrote:
> I think that in order to make this framework usable, it has to be
> simple. It could be a simple interface such as
>
> public interface ProtocolTransformer {
>          public StompFrame convertMessage(ActiveMQMessage message)
> throws IOException, JMSException;
>
>          public  ActiveMQMessage convertMessage(StompFrame command)
> throws IOException, JMSException;
> }
>
> this two methods would be called at appropriate places (probably at
> the begging) of the methods in the ProtocolConverter class. In this
> way we would allow developers to change message type and/or set
> appropriate headers, which seems to me would be more than enough.
>
> The one thing that I'm not sure of is how the ProtocolConverter will
> decide which transformers it should call. For incoming Stomp messages
> someone mentioned a solution which seems fine: to put an extra header
> in the stomp message (such as amq-msg-type or activemq-transformation
> or whatever) which would have a full class name of the transformer to
> be applied. Then the ProtocolConverter would try to load this
> transformer and if it succeed it would apply the transformation.
>
> But this solution is not working for messages that are sent from the
> broker to the stomp clients. We need some mechanism which will say,
> apply this transformation to the ByteMessages so we need a mechanism
> that will be able to register all transformers to the
> ProtocolConverter and then every transformer would be responsible to
> detect whether it should or not change the message.
>
> For configuring purposes we could use Service Provider JAR
> functionality (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Service%20Provider)
> since it is the only way I can think of that not requires external
> configuration.
>
> Two questions that we need to address:
>
> 1. do we want to enable more than one transformation to be applied?
> 2. how this framework will affect overall performances?
>
> What do you think?
>
> Regards,
> Dejan
>
> On 9/19/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.
> >
> > 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.
> >
> > 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.
> >
> > 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?
> >
> > -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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>

Mime
View raw message