Archive for the “Web Services” Category

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.

Comments No Comments »

The brain damage required to expose IS Flow services as document literal or Soap Message style web services is in sharp contrast to the ease with which you can create Soap RPC web services using Integration Server.

I generally recommend using document literal web services to my clients because they offer more explicit control over error generation, ability to validate the schema(s) associated with the soap messages before processing its payload and the ability to log the raw soap messages received from the business partner or internal customer.

However, the work required to create and test the wrapper services that extract and validate the soap body elements, convert the body into the correct inputs for the “wrapped” service and then map the outputs of that service (or exceptions it throws) into a valid soap response is far beyond what is reasonable to expect developers to do these days.

I’ve toyed with the idea of creating a few utility services to make creating the wrapper service much, much easier, but knowing that WM is planning on replacing the IS soap stack with Glue over the next several releases, that might be a lot of wasted effort.

Generating a WSDL that will invoke your wrapper service is also harder than it should be. For some reason, you can’t just refer to the input and output documents of your wrapped service. You have to create a new document type that contains a “holder” document type. That document type contains only one child, a document reference to the document type you really want to use. When you inspect the generated WSDL the holder document is there, but when you generate a Flow or java client from the WSDL the method only uses the input document of the wrapped service.

BTW, my favorite way to generate Glue java clients from WSDL files is to use Eclipse with the Glue plugins. Just create a new Glue project and then add a web reference. The new web reference wizard prompts you for the location of the WSDL and generates the classes you need. Just add a new class with a main method to invoke your web service and you’re set. Easy!


Comments No Comments »