Hi,
Since JAXWS let you handle the low level message, you can use the
SOAPMessageProvider as the camel-cxf endpoint's service class,
then you can handle the SOAPMessage in your process or bean .
Here is a unit test[1] to show how to Use the SOAPMessageProvider in
camel-cxf.
For the IN-OUT chain , camel's pipeline[2] will take care of them.
[1]https://svn.apache.org/repos/asf/activemq/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfSoapMessageProviderTest.java
[2]http://activemq.apache.org/camel/pipes-and-filters.html
Willem
Aaron Mulder wrote:
Is there a way to set up Camel to do something like this:
- accept an incoming Web Services call
- invoke a bean to validate the arguments provided in the SOAP call
- if invalid, return an error response to the original Web Services caller
- if valid, call Velocity or XSLT or something to transform the SOAP
input into another XML format
- pass the new XML document as the argument to a remote HTTP service
- get the response from the remote HTTP service, transform it, and
return that as the response to the original SOAP call
I guess my issues are, the Camel-CXF documentation and example aren't
real clear to me, and I'm not clear on whether you can set up this
whole chain to be IN-OUT so the response from the remote HTTP service
can propagate back through additional transformations and be the
response for the original SOAP call.
I expect it would be easier to have CXF invoke a Spring Bean on the
original Web Services call and that bean does all the other work
that's described. But I'm wondering if it's possible to set it up as
a Camel route instead, which would help decouple all the steps.
Thanks,
Aaron
