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

[Kevin.Conner@jboss.com]

"kurt.stam at jboss.com" wrote : 
  | because I think there we need to finish the following discussion first.
  | 

I believe it has been mentioned a number of times that this is a discussion for 5 and not the 4.x codebase, of course I could be wrong.

"kurt.stam at jboss.com" wrote : 
  | r1. The user should be able to define their own message type.
  | 

Sorry but the message *type* should be irrelevant as far as the user is concerned.  Only the contents of the message are of concern.

"kurt.stam at jboss.com" wrote : 
  | 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.
  | 

Agreed.

"kurt.stam at jboss.com" wrote : 
  | 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.
  | 

The way in which a message is serialised should only be of relevance to a transport and not the user of the message.  The real issue is that we still have major changes to be made to the architecture before we are close to the original design Mark and I proposed (especially in relation to the transport).

"kurt.stam at jboss.com" wrote : 
  | 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.
  | 

I agree that there is no need for the byte array and it does just confuse the issue.

The named map should also be changed IMHO.  The real use of this map is to pass context data around but this should be handled by a separate (explicit) message context.  This will allow us add other abilities to the context, such as the visibility of the context properties  (i.e. whether it only applies to specific services, handlers, threads, VMs etc.).

There is a big difference between message *context* and message *payload*.

"kurt.stam at jboss.com" wrote : 
  | 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.
  | 

Interfaces should be used to allow for flexibility in implementation.  Different implementations may be possible to optimise for different requirements, e.g. in VM storage, DB passivation etc.

The fact that the current implementations are focussed on serialising the message is the real issue.

"kurt.stam at jboss.com" wrote : 
  | 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.
  | 

This goes back to separating out the message context which could easily extend the Map interface.  I agree that reusing an appropriate (core) interface is preferable to reinventing our own.

"kurt.stam at jboss.com" wrote : 
  | i4. Tools like MVEL cannot process our Message because of i3.
  | 
  | 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.
  | 

It is far too late in the day to change this now so this will have to stay for 4.x.  

We have an opportunity to handle this (and other issues) in the 5 stream and then migrate the 4.x stream towards this.

Kev


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

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