Re: Introducing Apache Camel (was Re: The implementation of a simple service routing. WAS: RE: Release Update)

[James Strachan <ja...@gmail.com>]

On 3/31/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> On 3/30/07, James Strachan <ja...@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.

Good idea. Any of open/start/begin would be good.


> 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.

No, it was stuff like this (from LocalTransportFactoryTest)


static class EchoObserver implements MessageObserver {

    public void onMessage(Message message) {
        try {
            Conduit backChannel =
message.getDestination().getBackChannel(message, null, null);
            message.remove(LocalConduit.DIRECT_DISPATCH);

            backChannel.send(message);

            OutputStream out = message.getContent(OutputStream.class);
            assertNotNull(out);
            InputStream in = message.getContent(InputStream.class);
            assertNotNull(in);

            copy(in, out, 1024);

            out.close();
            in.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}


> 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.

Great thanks!


> 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.

Great thanks for the clarifications!


-- 

James
-------
http://radio.weblogs.com/0112098/