activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 18:34:03 GMT
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.

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


View raw message