activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Message transforming on broker
Date Tue, 15 Jan 2008 19:42:25 GMT
Awesome!

On Jan 15, 2008 6:47 AM, Dejan Bosanac <dejan@nighttale.net> wrote:
> 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

Perfect!

>
> - 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.
>

Sure.. We can get those applied.  BTW when you submitted those patches
you did not click the check box that said your granting the ASF a lic.
to use your patch.  If you get a chance please reattach the patches
with those check boxes clicked.

> - 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.

That sounds ok to me.  Perhaps we should add a header to the legacy
frame to that folks know that the transformation failed either on the
send or subscriber side.

>
> - 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 one fishy thing is that it sounds like it's being used like a
content-type.  Perhaps we should make the "transformation" purely a
transient header that only controls sender / subscriber behavior.

> - 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.
>

This sounds fine to me!  Please make it a separate patch.

> 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
> >
>



-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Open Source SOA
http://open.iona.com

Mime
View raw message