Currently I use the SwitchYard 0.2 version. I download the SwitchYard 0.3 version. There is a quickstart project called camel-soap-proxy. I build this project and deploy it in the SwitchYard 0.3. when I send a soap message listed as follow from soapUI to the service in the switchyard.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:switchyard-quickstart:camel-soap-proxy:1.0">
And I get the following response.
<faultstring>org.switchyard.HandlerException: Unexpected exception handling SOAP Message</faultstring>
Anyone who knows the reason, let me know please which steps I missed.
1 of 1 people found this helpful
I see you found the quickstart, but for the benefit of others it is called "camel-soap-proxy" and can be found in the quickstarts/ directory of the 0.3 distribution. Our quickstarts are hosted in a separate GitHub repository, so you can always grab the source separately as well:
The issue with deploying that quickstart to AS 7.0.2 is that the web services stack is disabled in the default configuration. So the web service that you are proxying to is never deployed. The fault message we return should be more useful, but if you check the console log for your AS instance you will see the connection error. You have some options:
1) Use the test framework support to experiment with the functionality standalone. There is already a test in the quickstart which demonstrates this.
2) Deploy the web service separately on AS 7.0.2 using the standalone-preview configuration.
Might also be possible to use AS 7.1 Beta to try this out, but we haven't had a chance to verify everything works in that version yet.
yes Keith, as you say I had seen the connection error in the console. But I do not know the web service stack is disabled in the default configuration. I just think maybe I miss some steps when I deploy this quickstart in the SwitchYard. Anyway, thank you very much!
When it comes to your suggestion the option 2), does "AS 7.0.2" mean "JBoss AS 7.0.2" or "JBoss AS 7 + SwitchYard 0.2" ? I think maybe both switchyard-as7-0.2 and switchyard-as7-0.3 use JBoss AS 7.0.2. Is it right or not? As to "standalone-preview configuration", it means that I need to enable the web service stack in a config file. is it right?
Is it possible for me to enable the web service stack in switchyard-as7-0.2 or switchyard-as7-0.3 and deploy this quickstart in the server? If it is possible, I may send a soap request from soapUI to the service in the SwitchYard.
Sorry, I meant the standalone-preview configuration in AS 7.0.2 with SwitchYard 0.3. To use the standalone-preview configuration, you start the server with the following command:
Let me take a look at creating a deployable all-in-one example for 7.0.2 tomorrow.
It was bugging me, so I decided to update the app now instead. Check out the attached camel-soap-proxy-as.zip for a working example. Just unzip it and do the following:
cd camel-soap-proxy cp target/switchyard-quickstarts-camel-soap-proxy-0.3.0.Final.jar $AS7_HOME/standalone/deployments/. $AS7_HOME/bin/standalone.sh --server-config=standalone-preview.xml
Or some variation thereof. I was able to successfully test with SoapUI on AS 7.0.2 with this change. You can diff the src directory to see the changes I made, but it was just an update to the source @WebService class and the WSDL (to reflect the hosted URL on AS 7).
camel-soap-proxy-as.zip 38.1 K
Keith, thank you very much! I will let you know soon.
I deploy this updated project in SwitchYard 0.3. It works. Keith, thank you very much!
Now, I will try to use a web service war file exported from Eclipse and deploy this new WS in the SwitchYard 0.3. I will let you know the result soon.
Keith, I deploy a new WS (HelloService.war) exported from Eclipse in SwitchYard 0.3. It seems that the configuration in switchyard.xml is not correct. Could you please let me which element I do not set correctly? Currently I create this demo project based on the camel-soap-proxy project.
- When deploying HelloService.war in SwitchYard 0.3, you can get the wsdl file from the following url:
- The interface for HelloService WS is com.nexright.HelloService.
- There is a HelloService.wsdl file in the wsdl directory.
Keith, now I know the reason why I cannot deploy this WS proxy in SwitchYard successfully.
- WS proxy project needs the interface file (HelloService.java), because I config this interface in the switchyard.xml. When I deploy this WS Proxy projec in SwitchYard; the SwitchYard server cannot find the interface.So I need to add this interface in the WS proxy project.
- Also I need to add the binding in the interface (see the attachment).
There is a little confusion.
- It is the WS proxy. And I already provide the wsdl file. Why do I need to do the input & output binding?
- The second thing is that it is possible for us to use the web service which is located in other application server. In this case, the third party just provides us the wsdl file and back end url (without providing the interface file, for example: HelloService.java). How could we implement this kind of WS proxy in the SwitchYard? If the SwitchYard can support this user case (I believe it should be), could you please let me know how to modify this project config file switchyard.xml?
HelloService.java.zip 342 bytes
One thing that might help with the confusion is a small change of perspective. Right now, you are developing the web service implementation and the routing service at the same time. This means that you are aware of the implementation details of the web service(Java bean + interface), which is what is confusing matters. My suggestion would be to approach it like this:
1) Develop your web service as a completely separate project. Deploy this and then forget about the implementation behind it.
2) Grab the WSDL that's generated at runtime from (1) and use that as the basis of the WSDL used for the SOAP binding in your SwitchYard application.
3) Define a Java interface for your SwitchYard routing service that contains the @OperationTypes annotation. Think of this as an internal detail of your routing service implementation - it simply specifies the input and output types that the routing service will be dealing with.
I imagine what's confusing is that you are using the same interface class for the routing service and the web service. If you are proxying for another web service, you should limit your proxy application to the public contract of that service (the WSDL) and not mix up the actual implementation artifacts.
Yes Keith, I had done this demo project as you decribe steps. Now I know this Java interface is for SwitchYard routing service that contains the @OperationTypes annotation (I think we may use JAXB or Transformer to do the same thing as well. is it right? Because it is just SOAP Gateway binding. ). As you say this Java interface for SwitchYard routing service may be different from the reference web service interface. I list the config in switchyard.xml file as following. But we must keep the same method declaration. And I test this case, it works. As to proxying for another web service, I will try it later and let you know soon.
I want to know how to config a web service which is located in OTHER application server (not in the same SwitchYard server). Here is the URL: http://10.197.74.195:8080/MathService/servlet/mathService. How should I add this URL in the following route?
I try to use the following configuration, but not successful.
<spring:to uri ="http://10.197.74.195:8080/MathService/servlet/mathService"/>
I also try to modify the following configuration as well, however it is still not successful.
<sca:reference name="MathService" promote="MathService" multiplicity="0..1">
switchyard.xml 3.2 K
I had a look at your comment here
I attached a modified quickstart with your HelloService and WSDL. The only thing I did was modified the reference to use the WSDL HTTP url of the war file that is deployed in the same server. The WS war can be deployed in any remote server too. If there is any issue in this sample, please post the server log to investigate further. I insist that you isolate the implementation and references one by one. If MathService is not working, then include those java files like the way I did in this attached sample and let us know.
What this sample demonstrates is this
soapUI <=> ProxyService(SOAP) <=> ProxyService(SwitchYard-impl) <=> Camel Route <=> HelloService(SwitchYard-ref) <=> HelloService(SOAP)-Local/Remote
camel-soap-proxy-alan.zip 21.8 K
Notice that the sample does not include any HelloServiceBean.java file. This is because the implementation of the WebService is done externally in the war file.