[jboss-dev-forums] [Design of JBoss ESB] - Alternative Message Discussion

[kurt.stam@jboss.com]

I have not posted a response to: the Message Body simplication tpic: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116278
because I think there we need to finish the following discussion first.

This subject of our Message Design has been brought up multiple times over the last year, and now that we are nearing completion on 4.2 it has become more and more clear to me that we should discuss changing the current design.

1. Requirements (as far as I understand them):

r1. The user should be able to define their own message type.

r2. The message should be easy to understand and easy to use.

r3. Should play nice with existing standards like SOAP and WS-* and may I add Java and JMS.


Discussion
Now what does r1 really mean? It means that the way the message gets serialized should be up to the users desire. We offer up 2 ways: Serialized java objects or XML.

2. Issues with the current message implementation:

i1. the body has a named map in which you can place objects or you can use a byteArray, well 
IMHO there is NO need for a byteArray. Everything is Java is an object, so you could simply add
the byteArray in the map. It is causing all sort of misunderstood code in our own code base alone
and we are supposed to understand it. Let's just get rid of the byteArray.

i2. we have two different message implementations depending on the type of the Message (see r1). There
is NO need for this! Only the un/marshal code should be different. There is no need to have this 
MessageFactory, there is no need for Message interfaces. It can all be done by some simple java objects
with different pluggable serialization options.

i3. The Message itself is constructed not using simple Java types: I mean when you do message.getBody() you are not getting the Map API. You are getting our interface. This is higly confusing and we should fix this. Also let's not reinvent "Property" once again. Let's simply use the one in Java.

i4. Tools like MVEL cannot process our Message because of i3.

3. Proposal

Let discuss a simple Message implementation that satisfies our requirements and that does not have the issues above. We can keep on applying bandages on our current implementation, but I think it is broken by design. Yes it will be pain to our users to change it now, but as a Dutch saying goes ?Weak Doctors make stinking wounds?. I think we will be saving everyone involved a great deal of pain if we would decide to change it now.

OK I'm all in Nomex. 

--Kurt

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075495#4075495

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075495