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 Mon, 26 Mar 2007 14:55:30 GMT
On 3/24/07, Dan Diephouse <dan@envoisolutions.com> wrote:
> Hiya James,
>
> This is very cool. I like the predicate/processor API a lot.

Thanks. FWIW we've nice scripting and XPath support now too...

from(someURI).filter(groovy("foo.bar.any { |i| i.cheese == 'edam'
}")).to(anotherURI).



> Can you explain more what you mean by "I'm just not sure yet in the
> CxfEndpoint how to bind inbound exchanges to the CXF bus and back again
> nicely".

I know the Bus API pretty well; I just don't know the internals of CXF
well enough yet to figure out how to wire Camel and CXF together
nicely. (I've bridged the Exchange/Message classes fine, its the
Channel/Service/Transport parts I've not yet figured out). More in
reply to Jervis's reply later...

Am thinking things we could do are...

* package up Camel as a transport in CXF (then CXF can reuse all the
various Camel transports and Camel can reuse CXF as a nice JAX-WS
typesafe-front end to Camel)
* allow Camel to invoke CXF services (for deploying JAX-WS services
inside Camel and using Camel to route between service implementations)


> Maybe part of the problem is message representation. What do we think of
> creating an XmlMessage which standardizes on using a Source object. Then
> people can write processors which can work for most XML things. CxfMessage
> could then extend XmlMessage.

Yeah; though I do quite like the CXF API where you ask for the body by
class; say as a DOM or Source and it does the right thing. The problem
with XML is that there's so many damn APIs and ways of working with
it...

-- 

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

Mime
View raw message