On 06/04/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
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).
The implementations that are supplied currently as basically required by JMS. Obviously any message can be viewed as a set of bytes but the various classes provide different views of the data.
- 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).
The idea originally was that the MIME type should not be closed. In fact the intent was that clients could register their own MIME types with the factory in order to be able to send different types of message easily. In practice, most people just use either BytesMessage or TextMessage and do transformations at a higher layer rather than the messaging layer. In fact I've never actually seen anyone use the JMS StreamMessage class in a real world application (note it's not about streaming data despite the name, it's just a different way of looking at the bytes).
- 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).
Hmm, I can't quite remember what the content type is for in the protocol.
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).
Yes, most people just use BytesMessage.
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 you know the message is XML then you could set the MIME type to be something like text/xml. Then if the client has registered a factory it could do something special with messages with that MIME type. Whether you want to do that at that layer, I'm not sure.
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.
Yes, you'd need to register some classes with the factory on the receiving client. (NB The factory API isn't probably in the public API package at this stage since its direction has never been discussed properly until now).
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?
Yes, you could register some extra MIME types for text message, or an entire new processor for the application/soap+xml MIME type.
(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).
Yes, the API needs some work.
Any advice or recommendations? Does this sound like a useful use case in the general sense?
If I understand you correctly I think you're trying to do what the message factory mechanism was intended to allow users to do - i.e. register new MIME types and process messages with those MIME types in special ways. RG
