How would you handle SOAP processing like WS-Addressing, WS-RM where the creation of the ouput message needs some information about the input message ? We can't really rely on our users to set all those informations on the output message ...
I do agree that most of the time only a single message will be used, but there are cases where you need both the request and the response / fault. On Jan 31, 2008 11:05 AM, Roman Kalukiewicz <[EMAIL PROTECTED]> wrote: > 2008/1/30, Hadrian Zbarcea <[EMAIL PROTECTED]>: > > Hi Roman, > > > > But it already is like that, sort of. If you like, imagine that your > > message has a tag (out/fault) that tells us how that message got > > there, that we also keep the previous message around (in). > > This is exactly what I'm trying to propose. > The difference is like between one chair and possible labels on it, or > three chairs labeled in constant way. When I have one chair, I know > where to sit. When I have three, I don't. Moreover consequences of > this choice are significant, and not always clear. (OK - I know that > software is not a furniture ;) ) > > Whole discussion here is maybe simply about some taste - I prefer my > the model I shown, while you prefer current one. I can perfectly work > (and works) with the current one, and Camel is a great framework > anyway - no question about it. > > I simply believe that my model is simpler and easier to understand for > our users AND it could be simpler to code (once again - maybe a matter > of taste). > > What is definitely against my idea is the fact that we have already > working different model, and someone could argue "don't fix it if it > is not broken". That is true, and we have to think about backward > compatibility and other important stuff. My propose looks like a > revolution in the whole framework. I believe, that it is not a > revolution, because even now almost no component uses faults, while > in/out distinction is simply lost when you use pipeline. Moreover my > patch shows, that it is not revolution. I was able to have 1 message > in the exchange, and every test passes. It means, that we can > deprecate some methods (like getOut() and getFault()) temporarily and > we ARE backward compatible, and no more guessing if I should use in or > out message. > > Just to clarify - I had to create quite complicated flow using camel > that included jms, xslts, JBI, http, splitters, error handling and > many other stuff. My proposal comes from many problems I had with > those in/out/fault messages. Many times it was a matter of guess (or > looking into the code) why something doesn't work when I set in or out > (don't mention about faults that couldn't be handled in DSL at all), > why my headers are lost, ... > > All those problems could be fixed somehow - true. I'm trying to say - > don't build bridges over those rivers. Just take another route, that > doesn't have rivers at all, if it leads to the same destination... > maybe even faster ;) > > Roman > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
