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 Wed, 20 Sep 2006 10:24:34 GMT
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
>

Mime
View raw message