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 Tue, 13 Jun 2006 17:49:51 GMT
Sounds good to me.

+1

-----Original Message-----
From: chirino@gmail.com [mailto:chirino@gmail.com] On Behalf Of Hiram
Chirino
Sent: Tuesday, June 13, 2006 1:45 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: STOMP and JMSType

On 6/13/06, Mittler, Nathan <nathan.mittler@sensis.com> wrote:
> Just to make clear what the proposed new "hard-coded" logic does:
>
> 1) If there is no content-length, it's a text message (same as before)
> 2) else, if there is no message type, it's a bytes message (same as
> before)
> 3) else use amq-msg-type to determine the message type
>
> So this logic is backward-compatible with the existing logic.  If the
> client does not specify "amq-msg-type", the behavior will be the same
as
> it is now.
>
> The STOMP protocol doesn't define a mapping to a JMS system, so as far
> as predictability goes, the users just need to follow our logic for
the
> mapping.  They wouldn't be able to change the mapping, like they would
> with a pluggable framework, but they shouldn't need to.  They just
code
> their clients against the mapping that we publish online and they'll
be
> up and running.
>
> I'm getting the feeling that the main reason for leaning toward the
> pluggable framework is to support a BytesMessage-only paradigm.  In a
> STOMP-only world this probably makes sense.  You're just and receiving
> "stuff".  But when you're bridging between Stomp and JMS, I'm not sure
> why a client would ever want this restriction.  It seems like if you
> want BytesMessages to come out the other end, then you just follow our
> mapping logic to make that happen, which really is as simple as
> including "content-length" (which you would have to include for a true
> bytes message anyway) and leave off "amq-msg-type" (which you would by
> default).
>
> Even if you were to implement a pluggable framework, you would still
> need to have some sort of application metadata like the "amq-msg-type"
> header.  Assuming our framework is comprised of a bunch of message
> transformers that go between raw bytes and ActiveMQMessages, the
default
> transformer for the STOMP transport would do this mapping the way I've
> proposed above.  So you wouldn't be eliminating the need for the
> "amq-msg-type" header, you'd just be pushing around the logic that
uses
> it.
>
> So I guess I'm still not seeing the bang for the buck ... it seems
like
> the "hard-coded" solution works for all cases that we've defined so
far.
> I'd rather just get this functionality in because I think it's useful
> and people have been asking for it.  I'm all for continuing to discuss
> the pluggable framework, but it seems that that is a separate issue
from
> what I'm trying to do here (...and probably literally a separate JIRA
> issue).

I agree.  But instead calling the header 'amq-msg-type' (which does
not explicitly convey that a transformation is being used), I'd like
it to be called 'activemq-transformation' set to a class name of the
transformation (or something that maps to a classname, like we do for
our service discovery).

and this would be header that is not carried with the message, it's a
header that controls the send and subscribe operations.

>
> Regards,
> Nate
>
>
> -----Original Message-----
> From: Brian McCallister [mailto:brianm@apache.org]
> Sent: Tuesday, June 13, 2006 12:20 PM
> To: activemq-dev@geronimo.apache.org
> Subject: Re: STOMP and JMSType
>
>
> On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote:
>
> > James,
> > I think that's what we're proposing here.  I proposed
"amq-msg-type",
> > but I suppose "content-type" is just as good.  I think Brian's main
> > concern (Brian, correct me if I'm wrong) is that he'd like the
mapping
> > of stomp message to AMQ message type to be pluggable, not
hard-coded.
>
> Actually, my first choice would be hard coded to bytes message,
> period, finished =)
>
> We cannot do this without breaking backwards compatibility, which I
> have been presuming we don't want to do.
>
> The most important thing, to me, when mapping from Stomp to JMS is to
> have it be very predictable. I don't want to ever have someone have a
> JMS client listening for stuff from Stomp and having to guess at the
> message type. As such, the default should be "it is X." If they need
> some other mapping, I would suggest that they look at some kind of
> transformer service which republishes messages.
>
> If we are going to have more complicated mapping, I want to either
> make it super crippled: a default "compatibility mode" and a strong
> recommended "5.0 mode." The next step is to make mapping pluggable,
> but don't make a big deal out of it. As ben Laurie would say, a
> European style API.
>
> That is the external point of view. For the internal point of view,
> the cleanest implementation I can think of is to have an interface
> which takes a Send (or something like) and returns an ActiveMQMessage.
>
> I am quite strongly against using using application level metadata
> (which content-type is in Stomp and JMSType is in JMS) for mapping
> information. I am also quite against every client having to specify
> what to map the message to as the client should be able to be
> independent of the particular implementation. I think it is a very
> bad idea to require the client to add the mapping to every message.
>
> -Brian
>
>
>


-- 
Regards,
Hiram

Mime
View raw message