activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: [stomp-dev] Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)
Date Fri, 22 Sep 2006 09:59:04 GMT
Sounds great, go for it Dejan!

On 9/20/06, Dejan Bosanac <dejan@nighttale.net> wrote:
> This sounds to me like the best approach to this problem. It
> simplifies implementation of the configuration mechanism and at the
> same time gives just enough flexibility. I don't think that there will
> be many (if any) clients that will want to change mapping for
> connections that are already established.
>
> If others agree with this approach, I can try to find some time these
> days to do some work in this direction.
>
> Thanks,
> Dejan
>
> On 9/19/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > I think that the client should only be allowed to change the default
> > mapping if he optionally specifies a 'protocol-mapping' header when he
> > connects.  Something like
> >
> > CONNECT
> > login:<username>
> > passcode:<passcode>
> > protocol-mapping: foo
> >
> > Where foo is mapped to a implementation of ProtocolMapper/Converter.
> > Then the client will be expected to send messages in that mapping
> > format and all messages sent to it will also conform to that format.
> >
> > On 9/19/06, Dejan Bosanac <dejan@nighttale.net> wrote:
> > > 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
> > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
> >
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Mime
View raw message