"Kevin.Conner(a)jboss.com" wrote : "kurt.stam(a)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. | No, you're not wrong. We're in the last phases of releasing 4.2 and the platform release is soon after that. We have QA, docs, productization etc. all running against what we've got and making good progress. No changes to the ESB at this stage can ever happen in isolation. anonymous wrote : | "kurt.stam(a)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. | +1 anonymous wrote : | "kurt.stam(a)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(a)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. | Agreed. The transport is defined by the service as part of the contract definition. anonymous wrote : | 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). | Oh yes. Definitely. anonymous wrote : | "kurt.stam(a)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. | Let's deprecate it then. anonymous wrote : | 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. | I may be missing something, but the Map in the Body implementation has nothing to do with context. That's what the Context element of the Message is for. Granted that we don't use that in the way we should (yes, that's another JIRA-ed issue ;-), and we tend to stuff context related information within the Body, but even if we fix that it doesn't remove the need for Body to maintain a mapping of content to name. The names of elements within the Body need to be unique, particularly if the Body can be manipulated by different independently developed service components (e.g., Actions). Whether the internal implementation of Body is a Map or not should be down to the Body implementation and not exposed to the end user. anonymous wrote : | 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*. | +1 anonymous wrote : | "kurt.stam(a)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. | +1 anonymous wrote : | The fact that the current implementations are focussed on serialising the message is the real issue. | Well to be honest the current XML implementation isn't focussed on Java serialized objects at all. With the exception of Attachments (simply hasn't been added) and Properties (obvious reasons), the XML message type doesn't mandate a content type for the elements within a Message. If there's not Java Serializable, then you just add a plugin to cope with the marshal/unmarshal for that data type. Pretty standard approach to be perfectly honest, and used in several distributed systems. I think the real issue is that we expose too much of this to developers. However, as I said in my response to Kurt, you've got to start somewhere and given the original Rosetta donation we started bottom-up. That means we haven't yet developed the higher level abstractions that we all (?) know and agree we need to have. But they'll come soon enough. anonymous wrote : | "kurt.stam(a)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(a)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. | +1 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075533#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...