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