One of the core patterns for a Gateway is "Service Virtualization". Service Virtualization means that an organization can expose virtual services in front of its infrastructure. These virtual services can take the form of lightweight REST APIs or heavyweight SOAP Web Services. The Service Virtualization pattern enables you to do neat things, like expose a REST service in front of a SOAP service, and convert REST to SOAP dynamically at the Gateway. You can also use the Gateway to deploy a virtual service in front of a database, or a message queue, or an ESB.

But how does it work? The answer comes down to how the virtual service is advertised to the client. Remember that service interfaces are generally advertised using WSDL (and as of WSDL 2.0, this applies to REST API interfaces as well as SOAP). WSDL includes the address of the service provider host. When the Gateway exposes a virtual service, it must replace this address with the address of the Gateway. Otherwise, clients would simply try to connect to the back-end service, thus attempting to bypass the Gateway.

Here we see an example where the client is pulling down the WSDL of a virtual service from the Vordel Gateway. Notice that the address of the service has been changed to the address of the Gateway:

 

 

 
But what if a client from the outside world accesses the virtual service, via a public Fully-Qualified Domain Name like services.mycompany.com ? Will the WSDL still say "VordelGateway" in it? If so, this would not work.

A neat feature of the Vordel Gateway is that it dynamically virtualizes its services based on how the client calls it. So, when we call the virtual service using the hostname services.mycompany.com , this is what happens:

 

 

 

Notice that the Vordel Gateway has dynamically virtualized the service with the hostname used by the client. If we'd pulled down the WSDL by its IP address, it would have placed the IP address in there. This is a very neat feature.

The SSL-savvy of you may be thinking "hmm.... those WSDL addresses use SSL but that's going to throw a warning if the hostname changes, and it'll also cause some Java clients not to connect". Well, that points to another neat feature that enables Service Virtualization. The Vordel Gateway implements SSL Server Name Identifier (SNI) which means that when it's called using a particular hostname, it will dynamically use the appropriate SSL certificate (and private key) for that connection. If you right-click on an SSL interface in Policy Studio, you can see this:

 

 

 

Notice in the screenshot above that there are two certificates set. Both must have corresponding private keys (since that's essential for SSL). When the Gateway is called using the name "vordelgateway", it assumes identity "CN=VordelGateway" (CN means "Common Name", in X.509 Certificate jargon). When the Gateway is called using "services.mycompany.com", like in the second screenshot above, it assumes identity "CN=services.mycompany.com". This is all done on the fly. Without this feature, many clients would not connect because the SSL certificate would not match the hostname. But with this feature, it "just works".

For more info, you can register for a live demo of the Vordel Gateway at: http://www.vordel.com/demo.html