Rationale for Message classes design

[Tomas Restrepo <to...@devdeo.com>]

Hi Everyone,

I've been working on some new stuff on top of Qpid lately and I'm running
into a few limitations in the design for the message classes (i.e. IMessage
and friends). So I'd thought I might as well solicit some input on the
topic. This is a bit long, so bear with me :)

Could someone explain to me the overall rationale for the message classes
design? In particular, just what exactly should the relationship be between
the different message classes (i.e. BytesMessage, TextMessage and friends).
Currently the design is very similar in both the .NET and Java clients,
though the Java one has a few more message classes (stream, object, map).

Here are some of the topics I'm a bit confused about:

- It would appear that the classes have been designed as parallel
structures. That is, it seems like either you have one or another class of
message, and the system uses the message MimeType to distinguish each class
during send/receive. At some point, it seems to me like you may want to
treat one message class as another arbitrary class (I'll explain below why).

- It seems like the MimeType system chosen is closed (probably because of
the above): The MimeType is set only during message creation and cannot be
changed, and it seems like it is expected that only a handful of types are
treated in a special manner (e.g. text/xml -> ITextMessage).

- It's not clear what the ContentType property does (at least to me... it's
unimplemented in the .NET client and seems to be used for something
unintuitive in the Java client).


Basically, here's my scenario:
I'm working on a connector on top of the Qpid.NET client that will send and
receive messages. Most messages will be text-based messages which might
contain plain XML or SOAP xml messages, or potentially arbitrary binary or
encoded contents (like a large stream message or an MTOM encoded SOAP
envelope).

The second issue is that message encoding, in all cases (even for plain xml
messages) is controlled a layer above my connector by some platform code.
That means that in general, I can't use the Qpid TextMessage class, because
it handles encoding itself, so instead I have to treat, on my end, all
messages as if they were arbitrary binary messages whose content is opaque
to my connector. That would mean using a BytesMessage or a stream message
type of sorts (which we don't have yet in Qpid.NET).

More important, however, is that for the general case (xml, text and soap
messages) I don't want to hamper interoperability and make it hard for
consumers (which might be in a different language, like java or cpp clients)
to receive and interpret the messages I send and the other way around. 

If I sent all messages as QpidBytesMessage, I'd need to have special code in
the other consumer to interpret the message as text content. This is in part
because of how the MIME type in qpid works at the time (at least as I
understand it from reading the code) and how it is used to decide which
message class is used.

So, in my connector, from the publisher perspective, what I'd like to be
able to do is to create a "binary message" (i.e. a bytes message of sort)
and configure it exactly as I want so that it can be seen at the other end
as a text message (so configure things like mime type and encoding manually
to suit my content).

Likewise, from the consumer perspective, I'd really like the ability to
reinterpret a message using a different structure. For example, the current
QPID implementation doesn't know anything about MIME type
"application/soap+xml" so if it received a message with this content type,
it would interpret it as BytesMessage, making it harder to consume. So as a
consumer, what I'd like is the ability to say: "Let me treat this arbitrary
message I received as a Text Message so that I get the nice text message
interface to it even though you think it contains something different". Does
it make sense?

(Note, also, that the MIME type system in qpid is being handled in a pretty
low level fashion now. In fact, channels or sessions don't expose a way to
create an message for an arbitrary MIME type).

Any advice or recommendations? Does this sound like a useful use case in the
general sense?

Tomas Restrepo
http://www.winterdom.com/weblog/