One of my big gripes about webMethods support for web services is the complexity required to expose an IS Flow or java service as a document/literal or soap-message style web service. This contrasts with the incredible ease with which those same services can be exposed as soap-rpc style web services.
Most of the complexity comes with the need to create a wrapper service for each Flow or java service that you want to expose. The job of the wrapper service is to extract the data needed to invoke the service being exposed from the body of the soap message, validated it against a schema, invoke the service and format the response of that service as a soap message to be returned to the consumer.
I have long thought it would be possible to create a set of utilities to eliminate the need for the wrapper service, but never had a compelling reason to do so… until now.
My current client needed to use document/literal soap messages and wanted to use Netegrity SiteMinder to secure them. I needed a place to extract the SAML assertion from the soap header and wanted to be able to create a single entry point for all incoming soap messages.
The solution involved creating a custom soap processor. The soap processor performs all of the functions of the wrapper service (extraction, validation, invocation, response formatting) but also makes the call to the custom Netegrity agent to obtain an authorization decision.
This design required the creation of a custom web services registry which allows the soap processor to lookup the service to be invoked as well as to obtain some additional meta-data. Examples of the web service meta-data include whether the web service requires input or output validation and, if so, what document types should be used. In the initial implementation this registry is persisted to the file system as an XML file, but the design allows for use of other repositories such as a relational DBMS, LDAP or UDDI.
Adding a meta-data element containing a remote server alias allows the service to be invoked to reside either on the same server as the soap processor or on remote server. If this same logic exists on each IS server, this feature will support transparent failover when used with a hardware load balancer.
If you can create a document/literal wrapper service, you have the skills needed to create a custom soap processor. The difficult bits to get right included extracting and renaming the input document for any name, namespace and prefix combination, looking up the service in the web services registry and adding the namespace and prefix to the response document. These items were handled with java services and some complicated XQL queries.
With this custom soap processor, any Flow or java service which accepts a single document for input and returns its results in a single document can be exposed as a document/literal web service with minimal effort. Doing so requires only that the service be “registered” by calling a service that adds its meta-data to the registry and that document types be created to hold the input and output documents for WSDL generation. WSDL’s are generated from the service to be invoked (not the wrapper service) and must specify the directive of the new soap processor rather than “default”.
So, it can be done, it works well in early testing with minimal performance impact and the complexity of exposing Flow and java services as doc/lit web services has been greatly reduced.