iRules and WSDL

An agile application delivery solution

One of the great things about SOA is that it's meta-data driven, and often that meta-data (e.g. WSDL) is dynamically generated to ensure it is up to date. So today when you query a web service for its WSDL contract you get back a dynamically generated, up-to-date description of the service and its endpoint. No one actually manually creates a WSDL these days, that's just craziness. In the early days of web services I was forced to write these bad boys to support testing and let me say that as long as an application server will automatically generate one for me, I'm going to let it!

But I've been thinking a lot about how BIG-IP and specifically iRules fits into this paradigm. One of the tasks iRules is exceedingly well suited to performing is intercepting traffic and transforming it in real-time and that fits right into the process of dynamically generating WSDL documents.  

Consider the example of querying a web service for its WSDL. You've got it, so your client is ready to go, right?

Here's the relevant excerpt of an example WSDL:

                   binding="es:MyServiceSOAPBinding">
        http://elmer.example.com/MyService/>
   

Problem: The endpoint address ("elmer.example.com") resolves to the server on which it was generated, and it's not publicly accessible.  

Houston, we have a problem. To what IP address does elmer.example.com resolve? By default, application servers generate a WSDL with the endpoint address as the hostname or IP address of the local server. What if the service is load balanced? What if it's not in the DMZ or the service is on a multi-homed server? What endpoint did the client end up with? Did I just break my SOA?

Maybe you're thinking this is not a problem; your partners and customers using that web service always retrieve a static copy of the WSDL with the right endpoint address in it because it was manually edited to be correct. No worries.

True enough, that solves the problem, but it also breaks your SOA. SOA is about agility, about loose-coupling, and your static solution is a brittle, tightly-coupled one that makes it a nightmare to update all those partners and customers in the event of a change to that service. You've solved one problem, but created another.  

Solution: Use iRules to ensure that the endpoint address is up-to-date and valid on any request for a WSDL.

Now here's an agile solution. Let's say today you only have one server handling a particular web-service request. A BIG-IP can front end your service and implement an iRule to make sure the endpoint address is valid in any request for a WSDL. That's a huge benefit. No more maintenance to ensure that static WSDL document is accurate, no more concerns about unresolvable endpoint addresses, just an always up-to-date WSDL that points to the right endpoint (i.e. application server).

Why is this an agile solution? Because later on when your service is so popular you need to add a second server to handle the load, BIG-IP is already there and ready to load balance requests for your service across your servers and ensure that the endpoint address is valid. And when you implement version 2 and need to migrate customers or route incoming requests to the right version, BIG-IP can transparently ensure that incoming requests are directed to the right version of your service with an iRule.

It's agile because it adapts to changing conditions with alacrity, just like your SOA.

Imbibing: Coffee