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 http://www.mulesoft.org/schema/mule/ws and its schema location is http://www.mulesoft.org/schema/mule/ws/3.0/mule-ws.xsd.

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.

No related posts.


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

From the Mule’s Mouth » Blog Archive » Pattern-Based Configuration: Hello Bridge! October 4th, 2010, 7:01 am

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

ahmed March 25th, 2011, 8:29 am

hi,

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

haw to do it???

thx.

David Dossot March 25th, 2011, 9:30 am

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?

ahmed March 25th, 2011, 10:29 am

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

David Dossot March 25th, 2011, 10:52 am

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: http://www.mulesoft.org/documentation/display/MULE3USER/Simple+Service+Pattern

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: http://www.mulesoft.org/documentation/display/MULE3USER/WSDL+Connectors

ahmed March 26th, 2011, 1:20 pm

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

David Dossot March 27th, 2011, 10:16 am

There is a complete section of the user guide dedicated to web services: http://www.mulesoft.org/documentation/display/MULE3USER/Using+Web+Services

Sudeep August 8th, 2011, 7:30 am

Hi,

If I want to call the web method with some arguments..how 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,
Sudeep.

Oceanmist August 30th, 2011, 7:37 am

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

David Dossot August 30th, 2011, 2:27 pm

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?

Neeraj November 24th, 2011, 9:58 am

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.

Pattern-Based Configuration: Hello HTTP Proxy! | Mule ESB August 15th, 2012, 12:05 am

[...] 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 [...]

Shamshu August 26th, 2012, 5:28 am

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.

Signing and Validating Soap requests with Mule ESB « The Pragmatic Integrator January 14th, 2013, 7:04 am

[...] 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 [...]

samaneh June 6th, 2013, 5:40 am

hi
what is the different between interceptor and filter or proxy

thank u

David Dossot June 6th, 2013, 9:54 am

- Interceptors in Mule are very much like their AOP counterparts, see: http://www.mulesoft.org/documentation/display/current/Using+Interceptors
- Filters are specialised type of interceptor, see: http://www.mulesoft.org/documentation/display/current/Filters
- Proxies are specialised bridges, see: http://www.mulesoft.org/documentation/display/current/Bridge+Pattern

samaneh June 7th, 2013, 6:02 am

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 :
http://www.slideshare.net/Zubin67/seaas-a-reference-architecture-for-security-services-in-soa

Or

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

David Dossot June 7th, 2013, 3:22 pm

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.

Leave a Comment