cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james.strac...@gmail.com>
Subject Re: Introducing Apache Camel (was Re: The implementation of a simple service routing. WAS: RE: Release Update)
Date Fri, 30 Mar 2007 15:10:12 GMT
On 3/26/07, Liu, Jervis <jliu@iona.com> wrote:
> Hi James, thanks for the info, very interesting project, anxious to see a CXFRouteTest
sample running in Camel soon :-),

Me too! :)

I've got a real basic CxfTest working now that fires off a Camel
exchange and uses CXF to process  the endpoint; its a bit of a crappy
example, but its a start...



>  do let us know if there is anything we can help out. Regarding "Also it'd be nice to
resolve URI endpoints in Camel nicely to auto-discover CXF endpoints and vice versa", would
you be able to use a code snippet like below?
>
>         Bus bus = CXFBusFactory.getDefaultBus();
>         ServerRegistry serverRegistry = bus.getExtension(ServerRegistry.class);
>         List<Server> servers = serverRegistry.getServers();
>
>         Server targetServer = null;
>         for (Server server : servers) {
>             targetServer = server;
>             String address = server.getEndpoint().getEndpointInfo().getAddress();
>            ....
>         }

Awesome! That really helped me get started, thanks!

After a quick chat on IRC DanD suggested using a LocalTransport /
LocalConduit / LocalDestination for interactions with CXF from inside
Camel. So I've hacked up an initial version of CxfComponent /
CxfEndpoint using this approach. It seems to be working ok though I'm
still a little unclear on a few things (more below...).

I've hacked a very rough implementation of a CXF Transport too; trying
to basically port the JMS transport to Camel - though I don't quite
undersand the code well enough yet so it needs some serious work :).


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 :). Also
replies are often sent back, using the inbound message rather than the
exchange.getOutMessage().

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?

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?)

* 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? If so where's the proper place to find the
OutputStream; the outMessage or inMessage?

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


> I also saw your comments in org.apache.camel.component.cxf.CxfBinding, this message representation
problem is a hard one. The "CXFBinding", as its name suggested, is a very vague concept, as
in CXF, we can support many different transports and bindings, for example SOAP binding, XML
binding or CDR (CORBA).


Yeah I hear you  :). To be honest I don't like the name I chose of
CxfBinding; its kinda the 'CxfMarshaller' (figuring out how to convert
from a Camel exchange to a CXF exchange and vice versea), though I'm
not overly keen on the word "Marshaller" as there's no consistent
spelling of it so code often uses both spellings :). Anyone got any
better ideas? Maybe CxfAdapter is better? (though thats another word
with 2 spellings....)



>  In the latter case, obviously using an XML Source object wont work. In CXF we have a
concept that built upon an underlying format of inputStream (lets take the inbound as an example),
 we may have many different representations of the incoming message, it can be an XMLInputStream,
a SAAJ message or Java objects.


Yeah, I understand. Unlike JBI which assumes Source objects, Camel is
very flexible, allowing endpoints to use any Java representations.
Then there's a type coercion helper library so folks can switch from
InputStream <-> Reader <-> String <-> Document <-> Source <->
POJO
based on what they need etc.
http://activemq.apache.org/camel/type-converter.html


> Interceptors that belong to different phases can pick the representation of their interest
to work with, of course, they have to know what format they can expect by calling mesage.getContent(...).
In the case of org.apache.camel.component.cxf.CxfBinding, might be a good idea to have an
abstract CxfBinding class, then several extensions such as CXFSoapBinding, CXFXMLBinding,
CXFCORBABinding etc.


Agreed. The idea behind the CxfBinding class was to be the
plugin-strategy for figuring out how to go to/from Camel <-> CXF as
you suggest. Then using some configuration mechanism (or URI format)
we can choose the right binding/adapter/marshaller approach



>  Another thought is that it is likely we may only want to use a stream format in the
router, for example, we only scan the soap header or name space, once we find the info we
will stop any further scanning and redirect the request. In this case, using a Stax based
API presumably will have better performance than transforming the whole input into XML objects.


Agreed. Hopefully the interceptors/processors can choose what types
they want things to be; then if need be we can add further
interceptors / transformers to make things efficient to minimise
things like multiple XML parsers etc.

I've not thought too much about it yet, but we may want to include
Camel routing & mediation rules as an interceptor as well as a
transport & Service...


Thanks for your great feedback!

-- 

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

Mime
View raw message