Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of chirino@gmail.com designates
 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received: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=oZovc+5/TzcD5RzyG6QS9vVo9V4ZOLT380JWaKCaPAFngXV+PMDIT3irWpJ7UV7GndROWbPb5muvR/iftiH2e1dDCpbsExPryd7BKdZnXSeZ8ryVDarxUwTOuMCvx0w4uGtnsqk3vkkptvKO7o84aBwTi3GjXPEsbBK8tYym/gI=
Message-ID: <af2843cd0606131146w344062efo67c0771527df4c6d@mail.gmail.com>
Date: Tue, 13 Jun 2006 14:46:03 -0400
From: "Hiram Chirino" <hiram@hiramchirino.com>
Sender: chirino@gmail.com
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType
In-Reply-To: <7D7AD2F6-4E34-4DF2-BBE5-C5893F812DA8@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: 
 <7743F17344E95A4CA78A3E53A7AF496B5C2EEB@corpatsmail1.corp.sensis.com>
	 <77B774B0-6759-4E7B-978F-CEC590E8A94B@apache.org>
	 <af2843cd0606131036r51202d0k5d3cb24a243ef546@mail.gmail.com>
	 <7D7AD2F6-4E34-4DF2-BBE5-C5893F812DA8@apache.org>

On 6/13/06, Brian McCallister <brianm@apache.org> wrote:
> On Jun 13, 2006, at 10:36 AM, Hiram Chirino wrote:
>
> > The think your views are a bit STOMP point of view centric.  bytes
> > messages work fine when both end assume you are just moving around
> > bytes messages.. and it's true everything can eventually converted
> > down to a byte[].
>
> Yes, and no. I want to see ActiveMQ become the de facto standard for
> messaging, period. Part of that is supporting non-JMS really well.
> So, yes, I am looking at it from a non-Java-centric (but allowing for
> Java via JMS) point of view =)
>
> > If you look at it from a JMS point of view, how will a STOMP client
> > deal with an existing JMS network?  What if a JMS MapMessage or an
> > ObjectMessage is sent to a stomp client?  The question is how will
> > that be encoded to bytes[]..  And what if the STOMP client needs to
> > talk to an App that expect JMS MapMessages or ObjectMessages??
>
> This seems, to me, to be a strong argument for a pluggable framework
> for message transformation. Going from JMS to Stomp for non Text/
> Bytes will be quite application specific, I think. In that case
> having a single solution applied to the whole messaging system is
> pretty ugly, period. If you are bridging from JMS to stomp, and using
> things other than bytes or text, it is going to be kind of ugly.
>
> > Yes I guess using a ESB style transformer in the middle would solve
> > the issue, but I think it adds complexity in the overall solution.  It
> > would be easier if the STOMP client could send a Map or Object message
> > directly even if it is an ActiveMQ extension that allows it to do
> > that.
>
> For any messaging system used for multiple applications, I think that
> mapping as a republishing service
>
> >
> > Perhaps we add a header on send:
> > activemq-tranformation: org.a.a.transform.StompTextToMapMessage
>
> I like this name better. Stomp is verbose anyway =)
>
> Being able to send a transformation specification is powerful, but
> kind of scary. I *really* think this should be a configurable option
> on the server, rather than have to have the client know what is
> happening on the other end. Allowing the client to specify is good,
> requiring the client to specify is bad.
>

So if the the client does not specifies a transformation, the
'default' transformation will be used, which is hopefully backward
compatible with what we are doing today in 4.0 and 3.x.

And perhaps we allow the 'default' transformation the be configurable
on the server side so that the default can be changed.  But perhaps
this would over complicate things as clients would expect a default
behaviour which we have now allowed the a server admin to change.


> > And on subscribe we add another header to covert on the way in.
> > activemq-tranformation: org.a.a.transform.MapMessageToStompText
>
> That is a very interesting idea. On subscribe you can specify a
> transformer to apply to whole session by default. A step up from per
> message, but I still think this should be able to be specified on the
> server config as well.
>
> > And if those are just class names, then the  users could implement
> > thier own transformation implementations and just add them to the
> > broker classpath.
>
> I would suggest that we use a weak form of specification encoding.
> ActiveMQ already uses pseudo-urls in a lot of places, and named
> transforms trump class names, usually:
>
> activemq-transformer: class:org.example.WombatTransformer
>
> activemq-transformer: named:wombat-transformer
>
> inline: ruby:it.gsub /kangaroos/i, "wombats"
>
> inline is not a good idea =)
>
> -Brian
>
>
>
>
>


-- 
Regards,
Hiram