activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mittler, Nathan" <nathan.mitt...@sensis.com>
Subject RE: STOMP and JMSType
Date Wed, 14 Jun 2006 17:21:09 GMT


> -----Original Message-----
> From: chirino@gmail.com [mailto:chirino@gmail.com] On Behalf Of Hiram
> Chirino
> Sent: Wednesday, June 14, 2006 12:40 PM
> To: activemq-dev@geronimo.apache.org
> Subject: Re: STOMP and JMSType
> 
> 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.

Ok, so application-level is referring to the C++ library, not the user
of the library?  If so that eliminates the need for another header like
"amq-msg-type".

How do we make this become part of the stomp spec?  When we do, we
should define the list of valid values for it (e.g. "text" and "bytes").

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

So right now, I'm just concerned with #1.  I'd like to make the first
crack at our client as STOMP vendor independent as possible ... and
we're only doing text and bytes messages for the first cut.

If we're in agreement that the two use cases you've identified are two
separate JIRA issues, then we can just create a second JIRA for #2, and
I can go off and implement #1 in the broker.  

BTW, what is the timeframe for 4.1?

> 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