[Design of JBoss ESB] - Re: Alternative Message Discussion
by mark.little＠jboss.com
"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#4075533
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075533
18 years, 7 months
[Design of JBoss ESB] - Re: Alternative Message Discussion
by mark.little＠jboss.com
"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#4075531
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075531
18 years, 7 months
[Design of JBoss ESB] - Re: Alternative Message Discussion
by Kevin.Conner＠jboss.com
"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.
"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.
"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. 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(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.
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(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.
The fact that the current implementations are focussed on serialising the message is the real issue.
"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.
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
18 years, 7 months
[Design of JBoss ESB] - Alternative Message Discussion
by 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
18 years, 7 months
[Design of JBoss Build System] - Re: Using jdocbook
by nbhatia
One more thing. When processing the PDF, I am getting the following error:
| [INFO] [jdocbook:generate]
| [INFO] building formatting result [D:\ProjectsTest\DocBook\andromda-tutorial-java\target\docbook\pdf\andromda-tutorial-java.pdf]
| Aug 18, 2007 2:07:07 PM org.apache.fop.fo.flow.ExternalGraphic bind
| SEVERE: Image not available: url(1)
|
I suspect this is because FO cannot find the title page image defined in fopdf.xsl (taken from hibernate):
| <xsl:param name="custom.titlepage.img">1</xsl:param>
| ...
| <xsl:call-template name="fo-external-image">
| <xsl:with-param name="filename" select="$custom.titlepage.img"/>
| </xsl:call-template>
|
1) How do I specify the title page image?
2) Is there any way to see the .fo file produced by Saxon?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075488#4075488
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075488
18 years, 7 months
[Design of JBoss Build System] - Re: Using jdocbook
by nbhatia
Steve,
Please ignore my previous post. I have resolved most of the issues by simplifying my directory structure.
1) I realized that the image directory structure can be copied using **/* syntax in imageResource tag. So this is not an issue any more.
2) Instead of sharing images and css between html and html_single, I am using the default layout of the plugin, i.e. images and css under html and html_single directories. Although this consumes more space, it does make the two output directories self contained.
3) Because of the above decision, image and css paths have now simplified from "../shared/images/xyz.jpg" to simply "xyz.jpg". As a result FOP is no longer giving a MalformedURLException. Yeah!
The only minor issue I have right now is with the html and html_single output. The images and css are currently output at the root level. I would like them to be pushed one level down - under images and css directories - just like they are in staging. Is it possible to do this? I tried to play with "imagesDirectory" and "cssDirectry" elements described under Usage (http://labs.jboss.com/maven-jdocbook-plugin/usage.html), but that didn't help. I think these elements apply only to the staging directory, but they don't seem to be doing anything to the staging directory either.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4075481#4075481
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4075481
18 years, 7 months