|If you plan to connect to an external web service that exposes a WSDL file, the recommended connector to use is the Web Service Consumer.|
The Axis and CXF transports provide WSDL connectors that can be used for invoking remote web services by obtaining the service WSDL. Mule creates a dynamic proxy for the service and then invokes it. The easiest tool for doing this, however, is the Web Service Consumer.
A WSDL endpoint enables you to easily invoke web services without generating a client. At startup, it reads the WSDL to determine how to invoke the remote web service during runtime. When a message is sent through the WSDL endpoint, it is able to construct a SOAP message using the message payload and its knowledge of the expected payload format from the WSDL.
You must provide the full URL to the WSDL of the service to invoke, and you must supply a
method parameter that tells Mule which operation to invoke on the service:
The WSDL URL is prepended with the
wsdl: prefix. Mule checks your class path to see if there is a WSDL provider that it can use to create a client proxy from the WSDL. Mule supports both Axis and CXF as WSDL providers. If you want to use a specific one, you can specify it on the URL as follows:
In general, you should use the CXF WSDL endpoint. The one limitation of the CXF WSDL provider is that it does not allow you to use non-Java primitives (objects that are not a String, int, double, and so on). Sometimes the Axis WSDL generation will not work (incorrect namespaces are used), so you can experiment with each one to see which works best.
Note that there are no specific transformers to set on WSDL endpoints.
By default, the WSDL provider will look for your WSDL by taking the endpoint address and appending
?wsdl to it. With the CXF transport, you have the option of specifying a location for the WSDL that is different from that specified with the
?wsdl parameter. This may be useful in cases where the WSDL isn’t available the normal way, either because the SOAP engine doesn’t provide it or the provider does not want to expose the WSDL publicly.
In these cases, you can specify the
wsdlLocation property of the CXF endpoint as follows:
In this case, the WSDL CXF endpoint works as it normally does, except that it reads the WSDL from the local drive.
This service requires two arguments: the "from" currency code and the "to" currency code. When the CXF dispatcher prepares arguments for the invocation of the service, it expects to find a message payload of
Object – that is, an Object array. In the case of the Currency Converter, this should be an array of two Objects - the "from" currency and the "to" currency.
There are several ways to construct this object array, but the easiest way is to use the custom transformer
, which translates a delimited String into an Object array. In the example below, you simply type in a String in the format of
For example, type "EUR,USD" to get the conversion rate for Euros to US Dollars, and you’ll get something like this: