activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Bosanac" <de...@nighttale.net>
Subject Re: Message transforming on broker
Date Tue, 15 Jan 2008 11:47:35 GMT
I've finally got my hands on this and implemented it in a way we
discussed it here. Patch is uploaded to the old issue
(https://issues.apache.org/activemq/browse/AMQ-943).

 Here are a couple of notes and questions:

- I've used the "transformation" header to lookup the appropriate
frame translator

- In the current implementation there is a XStreamFrameTranslator
which handles basic XML and JSON transformations

- For JSON conversion to work we need to use 1.2.2 version of XStream,
which is currently hardcoded in the pom, but if we apply this change
(https://issues.apache.org/activemq/browse/AMQ-1493) we can use it as
normal.

- the implementation ignores any errors that could happen during
transformation (unknown translator, wrong xml, etc) and uses legacy
translator in those cases. I think this is desired behavior, but if
you think different it could be easily changed.

- the transformation is done when user sends or subscribes with the
"transformation" header. Also, if the JMS client sends a message with
"transformation" header set it will be transformed before delivered to
the STOMP client even if it has not subscribed with the
"transformation" header. The subscription "transformation" has a
priority against message "transformation" in case that both are set

- the open question is how to add a support configuration of XStream
(and other marshallers) in the Spring context. The current
implementation is nice, but to be really useful people needs (or at
least I do) to have configured XStream to handle desired XML(JSON)
format. The transport layer is not easily exposed to the spring
application context. I found one solution that could work, but is not
so elegant.

1. make XBeanBrokerService ApplicationContextAware
2. make StompTransportFactory BrokerServiceAware
3. when creating transports if the transport factory implements
BrokerServiceAware it is passed to it
4. then if the broker service is application context aware we can
extract it in the factory.

any better ideas? When we sort this out, we can make OXM translator
that could use well configured XStream, Castor, XMLBeans, etc.

All comments are welcomed.

Thanks
-- 
Dejan Bosanac
www.scriptinginjava.net


On Dec 15, 2007 6:59 PM, Hiram Chirino <hiram@hiramchirino.com> wrote:
>
> On Dec 15, 2007 11:11 AM, Dejan Bosanac <dejan@nighttale.net> wrote:
> > Hi Hiram
> >
> > On Dec 14, 2007 6:40 PM, Hiram Chirino <hiram@hiramchirino.com> wrote:
> > > I personally think that a STOMP client should request a transformation
> > > strategy.  For example on a subscribe, he could do
> > >
> > > SUBSCRIBE
> > > destination: /queue/foo
> > > transformation: jms-json
> > > ack: client
> > >
> > > And on the reverse side, The send could look like:
> > >
> > > SEND
> > > destination:/queue/a
> > > transformation: jms-json
> > >
> > > ["Hello World",1]
> > > ^@
> > >
> > > And have the Stomp transport handle those "transformation" headers by
> > > looking up the "jms-json" transformation in the spring context.  This
> > > would allow the broker to have extensible transformations.  And the
> > > looked up object would just need to implement the following interface:
> > >
> > > http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/transport/stomp/FrameTranslator.html
> >
> > That's great. This idea has been discussed on the list some time ago
> > and I think it's a good approach. I though that maybe it could be
> > useful for other transports as well, but you're probably right that we
> > should keep this Stomp-related for now.
> >
> > A few questions about your idea:
> >
> > * Maybe it would be better to have "transfomers" registered at boot
> > time, rather then doing lookups when message arrives? If so, there has
> > to be a mechanism to configure Stomp transport with transformers that
> > will be used. What method do you propose for this, if any? Maybe
> > StompTransportFactory could do lookup on init?
>
> Well the one up side to doing the lookup per send is that the sender
> can choose different transformation strategies depending on the
> message he is sending.  Perhaps he got a JSON message in, so he sends
> using the json transformation.  Perhaps he got a XML message so he
> sends it using an XML transformation etc.
>
> The look up cost should be cheap but if you think perhaps it's an
> expensive operation, we could cache lookups.  The easiest way to make
> this extensible and easy to get stuff registered for lookup is to use
> the FactoryFinder [1] to lookup implementations by searching the
> META-INF directories.  For examples how we use this see the impl of
> DiscoveryAgentFactory [2]
>
> [1] http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/util/FactoryFinder.html
> [2] https://svn.apache.org/repos/asf/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/transport/discovery/DiscoveryAgentFactory.java
> >
> > * We have to allow users to add their "domain" classes to the amq
> > classpath, as I guess the most of them will want to transform XML/JSON
> > to objects of those classes. That's not a problem for brokers embedded
> > in applications, but I guess they could do that in the off-the-shelf
> > broker by adding appropriate JAR to the lib/ folder?
> >
>
> Yep that's the standard way we expand functionality in the broker.
>
> >
> > >
> > > Just need to find someone who is willing to take a stab at enhancing
> > > the stomp transport so that it does those "transfromation" header
> > > handling logic.  And add a few more interesting implementations of
> > > FrameTranslator.
> >
> > No problem about that. I'll invest some time in this, both in amq and
> > PHP Stomp client. But before that I thought I handle authentication
> > for Stomp as it is far more important IMHO. I'll start with this patch
> > (https://issues.apache.org/activemq/browse/AMQ-1272) add test cases
> > and implement proper behavior.
> >
>
> That's awesome!
>
> >
> > Cheers
> > --
> > Dejan Bosanac
> > www.scriptinginjava.net
> >
>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>

Mime
View raw message