Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <7b774c950703311332x44a8ab64g18a6dcf023eb3e18@mail.gmail.com>
Date: Sat, 31 Mar 2007 15:32:28 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Introducing Apache Camel (was Re: The implementation of a simple
 service routing. WAS: RE: Release Update)
In-Reply-To: <ec6e67fd0703300810x7ff6b492gcab6cd6aaaf22a91@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_68878_14943065.1175373148092"
References: <ec6e67fd0703230809n1a30084w75c0eaa10cbb8520@mail.gmail.com>
	 <9A4696F35B459043970EE4A85A317390066858@amer-ems1.IONAGLOBAL.COM>
	 <ec6e67fd0703300810x7ff6b492gcab6cd6aaaf22a91@mail.gmail.com>

------=_Part_68878_14943065.1175373148092
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/30/07, James Strachan <james.strachan@gmail.com> wrote:

>
> I have found the use of CXF Exchange / Message a bit confusing. I
> looked at different test cases and they seem to use the
> Exchange/Message in different ways; e.g. some test cases only use the
> Exchange.getInMessage () and put an InputStream and OutputStream in
> there then ignoring the out message. Then at some point  when sending
> a message back into a backConduit an InputStream can get morphed into
> a PipedInputStream.


Also it looks strange that a reply can be sent to a back channel, yet
> after the send, the inbound message's input/ouptut streams are
> processed some more; from someone with a JMS / JBI background this is
> very confusing, as send() usually implies the message is ready to be
> sent, not that the inbound processing hasn't even started yet :).


I think we should probably rename send() to open() as thats what it really
does.

Also
> replies are often sent back, using the inbound message rather than the
> exchange.getOutMessage().


Maybe you are seeing something like this and being confused:

Conduit backChannel = d.getBackChannel(inMsg, null, null);
backChannel.send(outMsg);
backChannel.close();

the getBackChannel() selects the appropriate back channel for you using the
parameters you supply to the method - like the input message. In some cases
this will be the synchronous http response channel (i.e.
Destination.getBackChannel()). In some cases this will be a new Conduit
entirely.


So I've found it a tad complex trying to figure out what is a well
> behaved connector to CXF Bus API meant to do? I've noodled around the
> wiki but things do still seem a bit confusing; I wonder is there some
> kinda canonical test case somewhere that shows what a well behaved
> client and service of the Bus API is?


Maybe check out the ObjectBindingTest that I just committed? I tried to make
things a little more clear in there about how the server and client sides
work.

I wonder could anyone answer the following questions; it'd certainly
> be good to pop the answers in a wiki page somewhere to try avoid
> others getting as confused as I've been lately...
>
> * what generally should be in the exchange/in/out messages in terms of
> headers and body types for a well behaved client & service. (e.g.
> InputStream seems common in the inMessage right? How about the
> output?)


It is up to the transport to select the reperesentation. When you're sending
a message via most Conduits, Conduit.send() creates an outputstream which
you can write to. Conduit.close() then closes this output stream.
Destinations will typically create an InputStream and set them on the
incoming message.

The big exception to this is the local transport. The LocalTransport now
supports a DIRECT_DISPATCH flag which just copies the content from one
message to another. SO when you send a message, it will create a copy of
that Message and send the Copy to the receiving Destination.

* whats the lifecycle between sending messages and the use of the
> streams. e.g. it looks like a service can send a reply before its even
> started to read the input right? Is it meant to send to the back
> channel first, then start reading the OutputStream thats put in the
> in/out message?


On the input side you can read right away.

On the output side, an OutpuStream is created when you call
Conduit.send(message)
typically. This stream is then closed when you call Conduit.close(message).
The OutputStream is available via message.getContent(OutputStream.class);

If so where's the proper place to find the
> OutputStream; the outMessage or inMessage?


The out message.


* should a service send the outMessage into the Conduit or the inMessage?


Hopefully my snippet above helps explain it better.


Regards,

- Dan


-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

------=_Part_68878_14943065.1175373148092--