Pattern-Based Configuration: Hello Web Service Proxy!


After the introduction of Simple Service, the patterns series continues!

The second pattern we would like to introduce is Web Service Proxy. Proxying web services is a very common practice used for different reasons like security or auditing. This pattern allows a short and easy configuration of such a proxy.

WS Proxy

Core Features

A web service proxy acts as an intermediate between a caller application and the target web service. This gives the proxy a chance to transparently introduce new behaviors in the calling sequence. For example, it can:

  • add or remove HTTP headers,
  • transform the SOAP envelope (body or header) to add or remove specific entries,
  • rewrite remote WSDLs so they appear to bind to services inside a corporate firewall,
  • introduce custom error handling.

Let’s take a look at Web Service Proxy in action:

With this configuration in place, all calls to the local weather forecaster proxy will be redirected to the remote one.

The Web Service Proxy is provided by the ws module, which must be present on the classpath to be usable. Its namespace is and its schema location is

The true value add comes from the automatic address rewriting that will be performed by the proxy: calling http://localhost:8090/weather-forecast?wsdl will return the remote WSDL where the port addresses will have been automatically rewritten based on the URL of the request hitting the proxy. That way, if your Mule instance is accessed behind a load balancer or any kind of network indirection, the generated WSDL will point the caller to port addresses that respect your particular network topology.

As said above, the proxy can perform changes on the SOAP invocation by the use of transformers. This is demonstrated hereafter:

Notice how transformers are introduced by using references to globally declared ones. This technique is also applicable to global endpoints, as you can see with the above reference to target-ws-endpoint.

The Web Service Proxy element supports child elements. The following shows a configuration variant where endpoints are declared internally and an exception strategy has been added in:

Finally, the Web Service Proxy also supports inheritance, which allows sharing common configuration attributes across several concrete instantiations of the proxy. Check out the following to see how inheritance works:

The proxy offers a few extra options as far as WSDL handling is concerned. Let’s look at them.

WSDL Redirection

In some cases, the remote web service doesn’t follow the common practice of exposing its WSDL on the same address as the service with a “?wsdl” appended at the end. In that case, it is required to point the Web Service Proxy to the exact location of the remote WSDL, as illustrated there:

In this scenario, the remote WSDL will have its port addresses rewritten as explained above.

For the case when no remote WSDL is available or if the remote WSDL needs manual adjustment before being exposed by the Web Service Proxy, the solution consists in storing the correct WSDL as a local file and have the proxy serve it. This is done as shown here:

In this case, the WSDL will be served as is from the file: no rewriting will occur.

More Proxying

We’re done with our discovery of the new Web Service Proxy pattern. As you can see, proxying web services through this construct is easy and quite powerful. Should you have more advanced needs, like dealing with multiple outbound endpoints, keep in mind that the CXF module gives you all the constructs required for building advanced proxies.

Your feedback and suggestions are welcome: please share them as comments or in the forum dedicated to configuration patterns.

We'd love to hear your opinion on this post

21 Responses to “Pattern-Based Configuration: Hello Web Service Proxy!”

  1. […] }); }Web Service Proxy was the last configuration pattern presented in this blog. Time for a new […]

  2. hi,

    i have a web service created with Netbeans and i’d like to test it with Mule ESB

    haw to do it???


  3. What is a “web service created with Netbeans”? Is it a JAX-WS annotated POJO? Or JAX-RS annoted? Or else?

    What do you mean by “test it with Mule ESB”? Do you mean: deploy it on Mule or do you mean connect to your existing web service with Mule?

  4. concerning the web service, i just created un simple WebService with Glassfish ESB,

    i’d like to :
    -deploy it on Mule
    -connect to an existing web service deployed in glassfish with Mule

  5. I assume that by “web service” you mean SOAP-style web service.

    If your web service is JAX-WS annotated, you can use Simple Service to host it on Mule. See:

    But if your web service uses any Glassfish ESB specific, then it can not be deployed on Mule ESB (of course).

    Now, to call an existing SOAP web service from Mule, one option is to use the WSDL connector:

  6. David plz can u help me,

    my problem is that i “must” try to understand how SOAP-style web service can work with Mule ESB,

    -i create a web service with ecplise.
    -i installe Mule in eclipse

    but i don’t know how use Mule and this web service?

    i must add in my project the mule configuration file? and how run it?

    thx for helping me

  7. There is a complete section of the user guide dedicated to web services:

  8. Hi,

    If I want to call the web method with some can i do that.

    My implementation:

    Now, If I want to call some method of “newCalcService” say “AddInt” which takes two integer params.

    How can I call that with existing implementation??

    Thanks & Regards,

  9. In Web Service Proxy pattern is it also possible to use Routing?

  10. Without knowing your use case. I think you could do routing with a flow in front of several WS Proxies. What kind of routing do would you want to do?

  11. Hi , Please let me know how to host a webservice from WSDL in mule ESB. I have WSDL file by using that i want to host a service and write logic inside the implementation class.

  12. […] much like its cousin the Web Service Proxy, the HTTP Proxy sits in the middle between a caller application and a target web resource. It […]

  13. Hi. Thanks for this. I happen to be searching for such a pattern. The thing is the application that I am building is residing in a dynamic environment where the servers on which the webservices are hosted will be moving every few months. So I was looking at proxies which would keep on checking where the services are available and in turn allow always up time for the clients. Also, what I do want is to create some kind of generic webservices for the proxy server so I do not have to create specific wsdls everytime some new webservices are introduced in the environment. I am researching on this and would appreciate it if you guide me to resources where something of this nature has already been tried out. Thanks.

  14. […] of the incoming request that is signed and has to validated. By the way, I know there is also the webservice-proxy-pattern in Mule but I couldn’t use this in combination with the signing/ validating which I needed to […]

  15. hi
    what is the different between interceptor and filter or proxy

    thank u

  16. – Interceptors in Mule are very much like their AOP counterparts, see:
    – Filters are specialised type of interceptor, see:
    – Proxies are specialised bridges, see:

  17. thank u for your answer
    i want to implement security as a service

    i want to know which of this solution is better and why ?

    1- i use a proxy design pattern that the proxy class act as an engine which call security services like this article :


    2 – use of interceptor like this article :
    Rich Services: The Integration Piece of the SOA Puzzle

    i know solution 1 can implement like 2 but i want to know the advantages and disadvantages of interceptor solution

    thank u

  18. If you use an interceptor it will be placed in a flow, which itself will act as a proxy. So I think you’re trying to compare to different but complementary concepts.

  19. thank u