You can just deploy a camel route that has two CXF endpoints in it. One that listens for Server A and another that sends to Server B. In between these endpoints in your route you can add any kind of content based routing you need.
I'm assuming you are referring to the servicemix-cxf-bc component. There is an option to deploy a listener (consumer) and sender (producer). This looks like it will lead me down the right path.
I have a follow on question about using the servicemix-cxf-bc component. I would like to make it where web services can contact servicemix (ie, make access a bit more generic) and servicemix will then do a bit of content routing.
Is this possible in a more generic way or do I need to create a servicemix-cxf-bc consumer and producer for each interaction?
Just for a bit more clarity, this is an example of what I'm thinking:
1. create a wsdl that represents a web service deployed inside servicemix
2. create and deploy a cxf web service inside servicemix that will route the request to my camel routing
3. in my camel routing, use the content-based routing pattern to analyze the soap msg and route accordingly
As a first step to implementing this, I'm implementing a proxy (client --> consumer --> producer --> service). Later, I'll add the camel routing.
When I call my cxf consumer (http://localhost:8000/Calculate), I get a connection refused error.
My xbean.xml is as follows:
My WSDL (for the service section) is as follows:
<!-- real service -->
<wsdl:port binding="impl:CalculateSoapBinding" name="Calculate">
<!-- cxf consumer -->
<wsdl:port binding="impl:CalculateSoapBinding" name="ConsumerCalculateEndpoint">
<!-- cxf producer -->
<wsdl:port binding="impl:CalculateSoapBinding" name="ProducerCalculateEndpoint">
For my WSDL, I took the actual service's WSDL and added a service entry for the cxf consumer and producer.
Also, when I replaced the address for the producer with the actual service's address, I then get a not found error.
FYI: some additional info when doing some testing from a browser
Edited by: lyfe on Nov 17, 2009 5:43 PM (added info from browser testing)
I got the following flow to work:
external client --> cxf consumer --> cxf producer --> external service
The following things were done:
- reboot my IDE (think an uncleared conflict with port 8080 never got cleared)
- reboot servicemix
- used an unedited WSDL file from external service
Now, I'm going to work on the following flow:
external client --> cxf consumer --> cxf web service --> camel routing --> cxf producer --> external service
My end goal is to create a way for external clients to access the ESB in a "generic way" as if it's a web service, then the ESB will route the request to the appropriate external web service based on the msg content. When I state in a "generic way", I'm basically going to have one service deployed in the ESB that takes a SOAP msg containing XML. From this service, I'm going to generate a WSDL file that external clients can use to generate the necessary classes to access the web service deployed in the ESB.
Does this plan sounds like it could work or am I going to bang my head into the wall?
Edited by: lyfe on Nov 17, 2009 7:51 PM
I took a different approach and got this to work..and be much simpler.
i have a similar problem as the one you described. I'm using a little bit different approach, but with some problems
see my post here :
I can (as a workaround) use the solution you got. Can you gice me some more explanations about? (an example could be appreciated).
Thanks in advance.
For this situation, I took out the cxf components (however, I may need to use in the future). I was able to achieve what I needed using http endpoints.
For the provider endpoints (using http:endpoint since http:soap-provider has a bug in the version I'm using), I specified the locationURI and I placed the wsdl resource on the server with servicemix. For my situation, this was an ok action.
For the consumer endpoint (using http:soap-consumer), make sure to set the value for useJbiWrapper to false (useJbiWrapper="false"). If you don't, your message will be wrapped in an additional tag that you may not be expecting. I also created a wsdl for the consumer endpoint. Before I send to the provider endpoint, I do some transformation on the message.
Back to the reason for using cxf components. It looks like using cxf provides additional security features I want to take advantage of. I'm using version 18.104.22.168. I've hit many and plenty bugs (and finding "ok" work arounds). I'm investigating the next release. I'm hoping to set up a workflow to priduce similar results using cxf components.
Regarding your post, I remember hitting the "operation not bound on this message." I can't remember exactly what I did, if anything, to overcome it.