Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of chirino@gmail.com designates
 209.85.146.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=prJFLjWRk08XQJ4WppAoLnowpsyxf6OmGlMekx+lLGq+PzJYFT00NJnh3MAUIuXS3g/KpZwQqWKq7PnY9f6jwDWavg6i0xNnQJtg6j4Q+GEAS6+5OrfbJN2vMnUZ4LZlN3dkVdHhnmejzkWqzpnJ1uNzvIVTV3gMvcBYtI3MYNM=
Message-ID: <af2843cd0712150959g1b4703c5o29ffd9ae9c13e9b@mail.gmail.com>
Date: Sat, 15 Dec 2007 12:59:32 -0500
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: dev@activemq.apache.org
Subject: Re: Message transforming on broker
In-Reply-To: <36e91d9d0712150811o11b57e6j88a0f0081358c7e4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <36e91d9d0712140346m67495b12qdf96574c2755c18b@mail.gmail.com>
	 <36e91d9d0712140354w6d7af483ga9747ba5077b432e@mail.gmail.com>
	 <af2843cd0712140940q687e6ce0oc0daa2754650e016@mail.gmail.com>
	 <36e91d9d0712150811o11b57e6j88a0f0081358c7e4@mail.gmail.com>

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