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 21:30:46 GMT
On 6/14/06, Nathan Mittler <nathan.mittler@gmail.com> wrote:
> A whiteboard would be really handy ... you guys aren't in NY by any chance,
> are you? ;)
>

DOH I was just there last week (for 3 hours)!  Want to visit Tampa Florida?

> So what I've gathered from the previous exchange is that we need to provide
> a stomp-to-jms message mapping as Hiram suggested (as a stomp extension for
> AMQ)
>

yep.

> Here are what I see as the use cases for my CMS client:
> 1) Stomp client sends a CMS::TextMessage, JMS client receives a TextMessage
> 2) Stomp client sends a CMS::BytesMessage, JMS client receives a
> BytesMessage
> 3) JMS client sends a TextMessage, Stomp client receives a CMS::TextMessage
> 4) JMS client sends a BytesMessage, Stomp client receives a
> CMS::BytesMessage

Yep this is clear.

> 5) JMS client sends !(text || bytes message) - Stomp client error -
> unsupported jms message type.  (One way this could be resolved is to have
> some sort of transformer at the broker that stuffs Object and Map messages
> into a bytes or text message ... perhaps as XML, like James suggested ...
> this, however is a different issue altogether)
>

I would say if your CMS client wants to stay vendor neutral and not
use a ActiveMQ transformation, then we can 1) give an error to the
client 2) avoid consuming those types of messages by adding a selector
predicate on the subscription or 3) silently consume those messages.
I'm partial to #2.

> So here are the things I need you guys to help me fill in:
>

So, from you previous email, I'm assuming the following questions is
in regards to a standarized and portable STOMP to JMS mapping.

Currently I think the way we implemented it (correct me if I'm wrong),
is that if a STOMP message has content-length, then it's turned into a
BytesMessage.  And if it does not then its' turned into a TextMessage.
 And the reverse would be true when sending down to STOMP client from
the broker.

Are we talking about improving this so that it's more explicit?


> 1) What header should I use to do this mapping?
>
> 2) What are the standard values for this header and how do I make a
> determination when I receive a message in the C++ client of text or bytes?
>
> 3) Does this header represent some JMS-specific property that would be
> settable in the JMS Message interface, such as JMSMessageType?  If so, we
> should choose another header, because the user could screw up the mapping
> done by the CMS library.  For example if the client creates a
> CMS::TextMessage, this property should be internally set to that of a text
> message and the user should not be able to change it.
>

I guess this all depends on what the issues are with the current way
that we do thing.  It seems to me that using the content-length header
will allow us to switch between bytes and text just fine.  But it
could be we are talking about making this mapping more explicit than
what we are currently doing.

> I'm sure there are probably more, but that's all I can think of right now.
>
> I think we're getting there guys!  :)
>
> Regards,
> Nate
>
>
> On 6/14/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
> >
> > ok.
> >
> > On 6/14/06, Brian McCallister <brianm@apache.org> wrote:
> > >
> > > On Jun 14, 2006, at 10:53 AM, Hiram Chirino wrote:
> > >
> > > > So here's a link to everything that is in the spec currently:
> > > > http://stomp.codehaus.org/Protocol
> > > >
> > > > It's a WIKI so you can edit it and improve the spec.  I think that a
> > > > the big missing piece in the spec is that there is no specification of
> >
> > > > how STOMP messages get mapped to JMS messages.  Since this is missing,
> > > > there is no provider independent way of sending JMS messages from
> > > > STOMP.  Since every implementation could map a STOMP message to JMS
> > > > messages differently.
> > > >
> > > > I think we need to add a "STOMP Message to JMS Message Mapping"
> > > > section that providers SHOULD comply with if the provider also
> > > > implements a JMS interface.  The great part is since this is missing,
> > > > you can make this whatever you want!
> > >
> > > Appendix, not part of the spec itself. If for no other reason than
> > > ActiveMQ will not be compliant as the current hackjob I implemented
> > > and we are now discussing how to fix is definitely not spec-worthy =)
> > >
> > > Once we have a few implementations and people have worked with it we
> > > can consider moving it from appendix into stomp 1.1 proper.
> > > Enshrining one technique now would be like enshrining a set of rules
> > > for O/R mapping eight years ago.
> > >
> > > -Brian
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
>
>


-- 
Regards,
Hiram

Mime
View raw message