ESB messages API and design considerations

[karypid]

I'm a newcomer to JBossESB and am having trouble understanding the API and rationale behind message factories and the body. I would appreciate some feedback to these very basic questions:

I set a breakpoint in my message composer code and using the variable inspector I observed that:

When you use the XMLMessageFactory to create a text message, it creates an entry in the table of objects that belong to the message body. The key used is "org.jboss.soa.esb.message.payload.text", which is the constant value for TextBody.DEFAULT_LOCATION.
If you simply use a MessageFactory, an entry is created in the message objects table under the key Body.DEFAULT_LOCATION (whose value is "org.jboss.soa.esb.message.defaultEntry").

Now, all actions that pre-ship with the JBoss ESB expect the message body to reside at Body.DEFAULT_LOCATION. So, if you create your message using an XMLMessageFactory, all these goodies are useless, because they can't "see" your message body.

My understanding was that the basic things you need to decide in order to create your message, are:

The kind of serialization you want to use withing the ESB: this means you must choose either XMLMessageFactory or SerializedMessageFactory.
What will be in the message body. This means that you must choose a TextBody, ObjectBody, BytesBody, or MapBody).

So, here's the list of things that don't make sense:

Why is MessageFactory non-abstract? Shouldn't one be forced to use XML / Java serialization (or roll their own)? I would've expected it to be abstract and for XMLMessageFactory and SerializedMessageFactory to extend it. If you want some other serialization, you would need to extend MessageFactory and implement the message construction methods.
Since MessageFactory is (evidently) non-abstract, what serialization does it use?
I would've expected the message factories (XMLMessageFactory and SerializedMessageFactory) to place the body under the Body.DEFAULT_LOCATION key. Why don't they do that?
In fact, what's the point of having various message body types (TextBody, ObjectBody, etc)? Is it to improve legibility of the code? (admittedly, writing "TextBody" immediately reveals to the developer reading it what one is working with text here)

[marklittle]

A lot of questions, which is good. But let's move this to the design forum if you don't mind, and then I'll try to answer.

[marklittle]

"karypid" wrote:
I'm a newcomer to JBossESB and am having trouble understanding the API and rationale behind message factories and the body. I would appreciate some feedback to these very basic questions:

I set a breakpoint in my message composer code and using the variable inspector I observed that:

You know the code is available to look through too :-) ?

<ul>
<li>When you use the XMLMessageFactory to create a text message, it creates an entry in the table of objects that belong to the message body. The key used is "org.jboss.soa.esb.message.payload.text", which is the constant value for TextBody.DEFAULT_LOCATION.</li>
<li>If you simply use a MessageFactory, an entry is created in the message objects table under the key Body.DEFAULT_LOCATION (whose value is "org.jboss.soa.esb.message.defaultEntry").</li>
</ul>

Yes, plus this is all documented in the Programmers Guide.

Now, all actions that pre-ship with the JBoss ESB expect the message body to reside at Body.DEFAULT_LOCATION. So, if you create your message using an XMLMessageFactory, all these goodies are useless, because they can't "see" your message body.

These factories and body types were added quite late in the development of the 4.x codebase, primarily as a way of trying to simplify the whole message approach. However, we ended up simplifying the message interaction in another way entirely, so none of the out-of-the-box actions make use of them. But that's not to say that you can't create your own actions that use them. Once again, that's kind of the benefit of having the source or having a pluggable architecture for service composition: if you don't like what you get then you can replace/augment it.

My understanding was that the basic things you need to decide in order to create your message, are:

<ul><li>The kind of serialization you want to use withing the ESB: this means you must choose either XMLMessageFactory or SerializedMessageFactory.</li>
<li>What will be in the message body. This means that you must choose a TextBody, ObjectBody, BytesBody, or MapBody).</li></ul>

Have you checked out the Programmers Guide? As I said, it does go into this in some detail.

But the majority illustrations and examples for message interaction is not to go via these Body types at all. That's not to say that you have to develop in that way yourself. But as you've pointed out, the out-of-the-box actions won't be keying on the same points in the payload.

So, here's the list of things that don't make sense:
<ol>
<li>Why is MessageFactory non-abstract? Shouldn't one be forced to use XML / Java serialization (or roll their own)? I would've expected it to be abstract and for XMLMessageFactory and SerializedMessageFactory to extend it. If you want some other serialization, you would need to extend MessageFactory and implement the message construction methods.</li>

Erm, MessageFactory is abstract.

public abstract class MessageFactory

<li>Since MessageFactory is (evidently) non-abstract, what serialization does it use?</li>

It's evidently abstract ;-) Which code are you looking at?

<li>I would've expected the message factories (XMLMessageFactory and SerializedMessageFactory) to place the body under the Body.DEFAULT_LOCATION key. Why don't they do that?</li>

The current approach is to put the content in a well-defined location within the payload that isn't the DEFAULT_LOCATION in order that they can co-exist with existing code.

<li>In fact, what's the point of having various message body types (TextBody, ObjectBody, etc)? Is it to improve legibility of the code? (admittedly, writing "TextBody" immediately reveals to the developer reading it what one is working with text here)</li>
</ol>

The request we had at the time was a suggestion to mirror the JMS message types, since many users know and understand that approach.

[karypid]

You are correct to point out that all these things are in the Programmer's Manual:

The fact that the actual format of the message ends up as either XML or Java (page 28):

As mentioned previously, JBossESB supports two serialized message formats: MessageType.JBOSS_XML and MessageType.JAVA_SERIALIZED. In the following sections we shall look at each of these formats in more detail.

The fact that TextBody, ObjectBody et al are not accessible as the "default location" (page 23):

It is important to realise that these extensions do not store their data in the default location; data should be retrieved using the corresponding getters on the extension instance.

The fact that everything else expects the data in the "default location" (page 22):

By default, all JBossESB 4.2.1GA+ components (Actions, Listeners, Gateways, Routers, Notifiers etc) get and set data on the message through the messages "Default Payload Location"

The fact that MessageFactory is abstract (page 27):

public abstract class MessageFactory { ...

I'm just trying to say that these questions remain even after reading the documentation, going through the examples that ship with the ESB (which are VERY useful by the way) and going through the forum reading posts like:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116278
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116445

To an inexperienced user, it is not clear how to approach the subjecto of "message" definition.

I was sidetracked on MessageFactory being abstract because I called its static getInstance() method and got a reference ot something that could create messages. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=142011 for how I came to do that.

From what you said, it appears to me that the API was recently fluctuating and that now it is best (in my case where messages are XML documents) to go with XMLMessageFactory, use an appropriate body extension (e.g. TextBody) and write my own actions rather than going with the defaults.

[marklittle]

OK, I see what you mean. Can you create a JIRA and reference this forum posting? Assign it to me and I'll take a look at improving things.