activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: STOMP and JMSType
Date Wed, 14 Jun 2006 16:40:28 GMT
On 6/14/06, Brian McCallister <brianm@apache.org> wrote:
> On Jun 13, 2006, at 3:06 PM, Nathan Mittler wrote:
>
> > So it sounds like we're all in agreement on the content-type
> > header.  For
> > text, it would be something like "text" and for bytes it would be
> > "application/octet-stream".  So this would not be an application-level
> > header, but would be used by my stomp client code to determine
> > which message
> > type to create.
>
> Content-type is application level. I was suggesting it for your use
> case where you want to know what to convert a bytes message into in
> your C++ library =)
>

Agreed! the app in this use case is the C++ client lib.  so the c++
client lib could set the content-type to control a custom transformer
so that sent JMS messages are exactly as the C++ stomp lib wants them
to look like.

So I'm starting to think there are 2 main use cases:

1) I want to have portable STOMP client that work on other providers.
Then you accept that you can not tightly integrate with an existing
JMS network in a portable way.  For example they would not be able to
send and receive JMS Map messages.  Since stomp does not specify what
those messages would look like on the wire.  This means that STOMP
needs to define how a portable mapping of JMS ByteMessage and
TextMessage to STOMP Messages.  I think what we have today is very
close to this.  We may just need to formalize it a little more in a
document so that other providers could implement the same STOMP to JMS
mapping.  Of course, this mapping has to stay simple.

2) You have a STOMP client that does not mind intimately knowing about
ActiveMQ.  Then it can request transformation on the the send and
receives.  That transformation could totally change all the STOMP
rules about the headers for for the messages coming in and out.   It
might use the content-type to hold the JMS message type: bytes, text,
object, map, etc.  and other headers like jms.Type to hold the JMSType
headers.  Also the payload encoding could be fancier.

So by default, I think it should work like case #1, if you want to use
case#2, then you use the transform header options.  This gives us
backward compatibility but for your " C++ stomp client that exposes a
JMS like API" use case, I would think it falls under use case #2.

Also, as offshoot idea on #2, is a provider allowed able to expose
additional verbs/operations to clients?  Kinda like how SVN/DAV does
for HTTP?

> > If we're all in agreement with that, then it seems to make sense
> > that the
> > default functionality of the broker be modified to handle content-
> > type in
> > this way.
>
> No. activemq-transformer would provide the JMS type mapping to
> override the default.
>
> I suggested that you use content-type (not required by stomp) to
> decide if something is text or a byte stream. Transfer-encoding is
> also useful for this.
>
> :-)
>
> > And if that's true, then it seems like this particular issue is
> > resolved.
> > This way, we get it into the 4.1 release with no problems.  We can
> > create
> > another issue to do the refactoring as you've suggested ... which will
> > probably take a little more time and several conversations to get
> > right.
> >
> > How does this sound?
> >
> > Nate
> >
> > On 6/13/06, Brian McCallister <brianm@apache.org> wrote:
> >>
> >> 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
> >> supplied.
> >>
> >> 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.
> >>
> >> SUBSCRIBE
> >> activemq-transformer: com.example.ContentTypeMapper
> >>
> >> > Here are the use cases I see:
> >>
> >> s/transformer/activemq-transformer/g
> >>
> >> I like the namespace.
> >>
> >> > Client->Server
> >> > 1) SEND\n...\ntransformer:text (client tells server it's a text
> >> > message)
> >>
> >> +1
> >>
> >> > 2) SEND\n...\ntransformer:bytes (client tells server it's a bytes
> >> > message)
> >>
> >> +1
> >>
> >> > 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)
> >>
> >> +1
> >>
> >> > 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)
> >>
> >> +1
> >>
> >> > 2) MESSAGE\n...\ntransformer:bytes (server tells client it's a
> >> bytes
> >> > message)
> >>
> >> +1
> >>
> >> > 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)
> >>
> >> +1
> >>
> >> > 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
> >>
> >> -Brian
> >>
>
>


-- 
Regards,
Hiram

Mime
View raw message