On 3/26/07, Liu, Jervis <[EMAIL PROTECTED]> 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/
