Graham’s talk provided a bit of history for SOA and building new applications (composite applications) from “parts” comprised of existing services.

He stated that the interesting question is not whether shared infrastructure services should be provided, but in which layer they should reside. The application server was originally a good place to do this, but unless an enterprise is using a single vendor and single version, it is difficult or impossible to provide infrastructure services for SOA in an app server container. Graham suggests that the appropriate place for these services to live is in the services bus itself. Commonly cited shared infrastructure services are security, transformation, failover and versioning.

The second half of Graham’s presentation focused on future directions for the product. I have to reformat those notes before posting.

I breakfasted with WM Users and Advantage members as well as several WM employees this morning. Everyone had head of WM Users and frequently indicated that it was the first place they visited to look for solutions to newly encountered problems. What a great compliment for the community!

One example given was last week’s issue with Trading Networks. There were relatively few posts on this critical issue at WM Users, but the second post pointed to the fix that had already been made available on Advantage. Now that’s “getting it done faster” (coincidently the theme at this year’s Integration World!).

Keynote speakers were good. Graham’s presentation on service-oriented everything was also interesting. I took notes on both and will post later. Alas, I could not get a WiFi connection in the ballroom in which the general sessions are hosted, so live-blogging will not be possible.

Now off to network at lunch and then to the afternoon break-out sessions.

Mark

I arrived in San Diego this evening just in time to catch a gorgeous sunset over the pacific (OK, the harbor at least).

I spent a productive half hour or so at the welcome reception and met WM Users luminary and EDI expert, Chris Linton as well as a host of other webMethods employees and clients. It was also good to see long-time WM Users contributor Igor Androsov taking a break from his project in Japan.

Tuesday morning means an early wake-up call to co-host the Advantage and WM Users breakfast with Nathan Harvey and Ajay Batra followed by keynotes and breakout sessions.

Check back here for updates throughout the day.

Mark

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.