"kurt.stam(a)jboss.com" wrote : | 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. | I'm fairly sure we had discussed leaving this sort of thing until after the 4.2.x release. Nothing of what we've got so far will be changing in this release. Everything is open to discussion for what comes after 4.2.x. anonymous wrote : | 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. | I'm fairly sure that this has been said time and time again: what we have was always a start and not the end result. I'm glad you agree with myself and others that we need to continue the evolution. anonymous wrote : | 1. Requirements (as far as I understand them): | | r1. The user should be able to define their own message type. | Actually this has NOTHING to do with the user and everything to do with the service and the clients that interact with it. As I've said many times, the original intention was always that Message and the marshal/unmarshal approach would be hidden from the majority of users. Clients shouldn't be arbitrarily deciding what message format (Java Serialized, XML, ASN.1 etc.) to use when talking to a service: that's up to the service! And it may be different for different types of clients or even for different "operations" that the service supports. anonymous 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. anonymous wrote : | Discussion | Now what does r1 really mean? It means that the way the message gets serialized should be up to the users desire. | Absolutely not. anonymous wrote : | We offer up 2 ways: Serialized java objects or XML. | We started off offering only one (XML). If you check the implementation of that, it allows for arbitrary plugins for marshalling and unmarshalling arbitrary data types, i.e., it doesn't assume serializable objects. So if anything the XML implementation is a superset of the Serializable one. The reason we also have the Serializable one is historic: that's all Rosetta supported when we inherited it. Feedback at the time from the Rosetta developers was that we should continue supporting Serializable, so we have. But ignoring that fact, let me re-iterate: the client should not (in 99% of cases) we setting the on-the-wire format for interactions with services. That information comes form the services themselves. This isn't new either. If you look at CORBA or some of the older RPC/MOM distributed systems such as Emerald, Argus, ANSAware, Arjuna2 etc. you'll see that they all supported flexible transports that were not (typically) exposed to the invoker: it was opaque. We currently expose a lot of what shouldn't be exposed simply because we have started building up and building out from Rosetta. This was always a first step, so people shouldn't make sweeping and incorrect assumptions based on what's currently there. There will always be a need for some developers to tinker with the low-level details of transports. At the moment we tend to cater for those individuals more than the ones who really don't care/shouldn't care, but as we build up the higher levels of abstraction we'll get there. That doesn't mean we will prevent the types of development style we currently have, only that it'll not be the norm. anonymous wrote : | 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. | I don't think it's such a big deal to have it or not. I do know that we overuse it when it's simply not necessary. From that perspective alone I'd agree to remove it (or deprecate it as we have to!) anonymous 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. | Agreed. See my comment above about the way in which the XML implementation works. It's about 90% of the way you mention and the only differences are slight: at the serialization level. The name (XML message) is in no way meant to represent how the Message is laid down within the address space of the user, i.e., you're not manipulating XML data structures when you add/remove/replace elements. It only becomes XML when you hit the network. There is an issue to clarify the Message and hopefully this will become clearer in the documentation. anonymous 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. | Yes, we will definitely address this and several other issues in the rest of the code after 4.2.x is released. anonymous wrote : | Also let's not reinvent "Property" once again. Let's simply use the one in Java. | Agreed. And we do that elsewhere too. anonymous wrote : | i4. Tools like MVEL cannot process our Message because of i3. | MVEL support is not on the roadmap. So although this is useful information for when we come to re-evaluate, it is irrelevant for this release. anonymous wrote : | 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. | It is far too late to change this for the forthcoming release. I don't think it is that important an issue to reschedule the entire release process of the ESB and the SOA Platform. There are other higher priority issues that we need to address. Plus, feedback from end users is very important too. We can sit here in the forums contemplating what we believe is critical and what isn't, but feedback from in-the-field users is vitally important. anonymous wrote : | OK I'm all in Nomex. | Not sure I get the reference? Actually I am sure: I don't get it ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075531#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...