After a quick chat with William.... a quick clarification: The important point here is not how many messages are carried in the exchange....but rather how is the message to operate on is selected.
Inspecting org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(Message) in CXF, which is more or less the parallel of the Pipeline in Camel shines in simplicity - the list of interceptors is traversed, each invoked with the current working copy of the message. While the exchange carries different messages (in/out both data and fault), interceptors are not required to have the intelligence as to what message to operate on - they're handed the message they're expected to manipulate. Any complexity around picking the right one or special semantics is kept outside of the interceptors themselves, and handled by the framework. This yields consistency and simplicity... > -----Original Message----- > From: Andi Abes [mailto:aa...@progress.com] > Sent: Friday, January 30, 2009 2:17 PM > To: dev@camel.apache.org > Subject: RE: Components setting data on OUT > > Took a while, and Roman I think you made great points. > > I think that throughout that thread there seems to have been a bit of > confusing use of terms.... > > For example, the bit below: > >JBI, WSDL and WS stacks like CXF / JAX-WS support the idea of IN, OUT, > >FAULT messages. So its mostly there to support patterns like InOut > >rather than just InOnly. > > >If you want you can just ignore the InOnly world and focus on one-way > >messaging I guess? > > Is a bit misleading. > While JBI and WSDL deal with providing metadata describing the expected > contents of a message, they don't actually mandate the presents of 2 or > 3 different messages simultaneously.... rather just possible content > models. > > Actually if you inspect how handlers in both JAX-WS (e.g > http://java.sun.com/javase/6/docs/api/javax/xml/ws/handler/Handler.html) > and in CXF are structured - they always only handle 1 message, whose > contents might be of the different types described by the metadata. > > Both CXF and JAX-WS provide a context which allows carrying information > around that is used in the different phases of processing the message > (e.g. captured while producing an outbound request and used while > processing the reply)... > This mechanism is used by WS-Addressing, where the only thing that needs > to be captured is the Endpoint Reference to which to produce a reply > when one is ready... > > One of the benefits of having a single "in-progress" message is that it > removes the need to copy things around - which could improve not just > semantics, but also performance - no need to create, copy from in to > out, and then discard messages at every step in a pipeline. > > > > > > > > -----Original Message----- > > From: Roman Kalukiewicz [mailto:roman.kalukiew...@gmail.com] > > Sent: Tuesday, January 27, 2009 10:09 AM > > To: dev@camel.apache.org > > Subject: Re: Components setting data on OUT > > > > 2009/1/27 Andi Abes <aa...@progress.com>: > > > Having finally caught up with the discussion about header/property > > > copying and propagation, I thought it might be interesting to circle > > > back to the original question Claus posed (slightly reworded) - what > is > > > the purpose of the out message? > > > > > > As a "flame generator" question - > > > If the exchange only carried 1 message, where each component in turn > got > > > to use and optionally modify. > > > - how would this be different than the current pipeline behavior ? > > > Currently if a component sets an out message, it is effectively > > > replacing the in message for the next one. > > > > > > - would it not simplify the whole issue of header > copying/propagation? > > > No copying is necessary since it is the same message that travels > > > through the route > > > > > > As an optional augmentation of this model, an exchange could carry 2 > > > messages > > > - the "current" or "working" message, which will eventually be the > > > output of the exchange > > > - a readonly primordial input message, as provided by the user. > > > > > > > > > (start the flame...) > > > > Flame was already started some time ago here: > > > > http://www.nabble.com/in-out-fault-messages-discussion- > > to14170013s22882.html#a14170013 > > > > You can go through it if you want ;) > > > > Roman
