On 6/13/06, Brian McCallister <[EMAIL PROTECTED]> 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
