Virtues of WSDL Virtualization

WSDL virtualization is the ability to create a virtual WSDL from one or more predefined WSDLs files. Typically, WSDL virtualization takes place across multiple back-end systems that expose their operations through WSDL documents. An intermediary gateway sits between the producer and the consumer and aggregates the WSDLs. Based on policies enforced on the gateway, operations are exposed to the consumers. A sample deployment is shown below.


The virtues of WSDL virtualization include:

1. Security: The virtual WSDL can exposed or hide some of the operations from the original WSDLs. The WSDL endpoints are cloaked with only the intermediaries endpoints being exposed.
   
2. Consistency: Virtualization allows to select operations from multiple WSDLs and exposed them to clients as a coherent single WSDL.
   
3. Productivity: The main benefit of virtualization is to be able to mix and match operations without having to copy and paste parts of the desired WSDLs into new WSDL files. It allows a customer to be able generate a library of all the operations suported on its organization and only exposed the ones required for a particular customer.
   

Some of the challenges of WSDL Virtualization addressed by Sophisticated SOA Gateways, such as Forum Systems Sentry include:

1. Resolving different schemas that share the same namespace.
   
2. Multiple schemas might have different constraints for the same element, that might be incompatible.
   
3. Exposing the list of WSDLs that developers should be working on. Although external trading partners typically require a single WSDL, internal developers work with multiple WSDLs. A list of WSDL needs to be retrieved from the SOA Gateway to better manage developers working across multiple WSDLs

WSDL Virtualization is a crucial part of deploying SOA. The vices of free-for-all operations can quickly set chaos within a SOA deployment that can only be controlled through SOA Gateways that provide strong WSDL virtualization.

Qualifying Your SOA Gateway's Horse Power

Often in our tech industry there is a penchant to spout off performance numbers without qualifying the metrics and conditions under which these numbers are derived. The SOA Gateway community is not immune to this indulgence. I have to admit, even I am guilty of committing this sin sometimes.

In the SOA Gateway world, performance cannot simply be defined in terms of transactions per second (TPS) due to complexity of a message transaction and the task policy of the gateway. As a result, SOA Gateways today always specify a specific task (i.e XML transformation, WS-Encryption) and the associated TPS. However, this type of metric still falls short of fully expressing the true performance metric of a SOA Gateway. For example, a common task that is staple of every SOA Gateway is schema validation. This task validates the the structure of incoming and outgoing SOAP/XML messages. The performance of a SOA Gateway when performing validation is often expressed in terms of Schema Validation TPS.
This is simply not sufficient. Further qualifiers that should be applied to schema validation performance numbers are as follows:

• What is the size of the message?
• What transport protocol (HTTP 1.0, HTTP 1.1, MQ etc) was used to derive the numbers?
• Was the deployment in proxy mode or was it in service mode?
• How many clients were used in generation of load?
• Was the validation task performed on both inbound and out bond messages?
• How complex was the message structure and its associated schema (i.e n-dimensional arrays, abstract types).

The last bullet is a real challenge and it really affects the validation performance of a gateway.
Unless, these qualifiers are resolved, the numbers are subjective at best. Maybe one day we will learn some lessons from the automotive industry to really define a true metric in defining performance of each task in a SOA Gateway.

Common SOA Gateway Deployments

SOA Gateways are becoming standard in enterprise SOA deployments with the following common themes:

1. Identity mediation is the first step for the majority of SOA Deployments. Identities come in may shapes and sizes represented at both the protocol level (e.g., HTTP Basic Auth, SSL Mutual Auth) and message level (WS-Security tokens X.509, SAML, etc.). Even if an enterprise successfully standardizes on a single identity representation, it cannot dictate how it's trading partners should represent its identities. Thus, inditites need to be accepted in many forms and changed to a single internal representation - that is if everyone within an organization can agree to a standardized representation. Most likely, even internally, more than one identity representation exists.
2. XML Firewalling is essential to ensure that information is checked before it makes it to the back end application server. The XML should be clean so that the backend server can safely process the message. Even more significant is the need to ensure that the SOA Gateway checks for information leaking from the corporation. This includes preventing sensitive information such as Credit Card Holder information from being compromised, as mandated by the PCI Security Standards Council.
3. Data Integrity and Privacy using content based signatures and encryption ensures that the message is not tampered with and that any part of the message can be encrypted granularly using standards such as WS-Security.

Other items such as Data Mediation, enrichment, transformation and archiving are also commonly enabled in a SOA Gateway deployment.