activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: [stomp-dev] Pluggable Stomp Message Mapping (was: [stomp-dev] PHP Stomp Client)
Date Tue, 19 Sep 2006 21:48:38 GMT
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

Mime
View raw message