activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <>
Subject Re: STOMP and JMSType
Date Tue, 13 Jun 2006 21:44:24 GMT
On 6/13/06, Nathan Mittler <> wrote:
> Could you guys point me to a place in AMQ where this sort of thing is being
> done?  That would save me a lot of searching =)

Its not really done anywhere else :-(

> I'm viewing this problem from the client side - the Stomp C++ client that
> Tim Bish and I are writing currently supports text and bytes messages.  So
> when I get a stomp frame in, I need to map it back to a text or bytes
> message.  We chose to do this for a couple of reasons: 1) to give JMS users
> a familiar interface and 2) to provide a simple interface for reading and
> writing text messages (e.g. xml).

Sure.  that would be handy.  But you could also eventualy support Map
messages too right?

> With that said, I'm not seeing how I can do that mapping if the transformer
> is provided only in the SUBSCRIBE.  A client could potentially get a variety
> of message types from a single subscription.  I think it would have to be
> part of the MESSAGE frame, rather than the SUBSCRIBE.

Well, when the publisher is a pure jms client, he wont be providing a
header for the transform type right?  What I was thinking is that when
the client says SUBSCRIBE with x transform, it basically sets up a
contract that given all the JMS message types a well defined
transformation to STOMP frames will be done.  It could be that a
future transform will take a Map messages and turn it into XML and put
that in a text stomp frame.  But a different transformation might take
a Map message and do a binary encoding of the key value pairs.  Either
way the client will know what to expect because he requested it on the

In addition, a smarter transformer could enhance the subscription's
selector so that it does not receive message types that it cannot
handle.  That way if the client says it can only receive text
messages, it only subscribes to text messages.

> Here are the use cases I see:
> Client->Server
> 1) SEND\n...\ntransformer:text (client tells server it's a text message)
> 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes message)
> 3) SEND\n...\ntransformer:default (client tells server to use content-length
> to make determination)
> 4) SEND\n...\n (no transformer specified - same as #3)
> 5) SEND\n..\ntransformer:bob (client gives server unknown transformer - use
> default)

and I also see stuff similar to:
6) SEND\n...\ntransformer:xml-to-map (client tells server it's a xml
stomp frame that need to get converted to a jms MAP message)

> Server->Client
> 1) MESSAGE\n...\ntransformer:text (server tells client it's a text message)
> 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a bytes
> message)
> 3) MESSAGE\n...\ntransformer:default (server tells client to use
> content-length to make determination)
> 4) MESSAGE\n...\n (no transformer specified - same as #3)
> 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown
> transformer - use default)

Sure, but that's just content type information.  I do agree we need to
set this to something.  But it's separate from doing transforms to map
from all the JMS message types to the 2 basic stomp types text and

> Does this make sense, or am I missing something?

I think we are starting to converge now.  I guess the biggest issues
with content type like fields is that there are so many of them.  I
personally would map content-type -> JMSType since I think they were
meant to hold app specific descriptions of the payload.  We may want
to have the additional header you were proposing to hold information
about the STOMP frame - > JMS Message type kind of information.  It
gets fuzzy here.

> Thanks,
> Nate
> On 6/13/06, Hiram Chirino <> wrote:
> >
> > > 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:
> > >
> >
> > yeah! URI style configuration rocks!
> >
> >
> > > -Brian
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >


View raw message