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 21:37:21 GMT
On Jun 13, 2006, at 1:50 PM, 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 =)
> 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.

Within a general Stomp client, I would suggest that switching on JMS  
message types is not a productive goal. Using Content-type here makes  
a lot more sense, I think. . It would make a lot of sense to set it  
for text messages going out to Stomp if there is not one already  

Stomp is a protocol, like HTTP or SMTP -- hardwiring a client to a  
specific server implementation is probably not a general solution  
(though is fine if it is specifically an activemq client which  
happens to use stomp for transport).

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

Content-type: text/xml


Content-type: application/octet-stream

> 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.

activemq-transformer: com.example.ContentTypeMapper

> Here are the use cases I see:


I like the namespace.

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

-1 Give it a descriptive name so that we can change the default  
without breaking these.

> 4) SEND\n...\n (no transformer specified - same as #3)


> 5) SEND\n..\ntransformer:bob (client gives server unknown  
> transformer - use
> default)

Return an error -- do not quietly swallow this.

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

-1 same as #3 above

> 4) MESSAGE\n...\n (no transformer specified - same as #3)


> 5) MESSAGE\n...\ntransformer:bob (server tells client to use unknown
> transformer - use default)

-1 same as #5 above

This does highlight that we have two real transform cases, send and  
receive if we support CONNECT or SUBSCRIBE level transformers. We can  
infer the correct direct on MESSAGE and SEND, but not the others. As  
this would make the interface have all of two methods, I am quite  
happy combining it.

Alternately we can have different headers on SUBSCRIBE and CONNECT


View raw message