Your question is a very good one. Expanding a bit further, there are at least three different issues to be considered:
- How will two separate versions of a service in IS be maintained when the fully qualified name of a service must be unique?
- How will you describe services such that consumers of your web service operations can invoke different versions of the same operation?
- What component will handle the routing of requests for versioned web service operations?
Maintaining Separate Versions of Integration Server services:
For the first issue, since the name must be unique, you can either make the version number part of the folder structure or part of the name of the service. Either will work, but my preference is to use a separate folder structure.
A third, less appealing option is to setup an entirely new IS server in which only the new version of the services is installed. If an intermediary (such as Infravio X-Broker) were available it could route requests to the new IS instance based on characteristics in the message.
Describing Versioned Services To External Consumers:
Regarding how to describe a Web Service such that requests to invoke its operations can be handled correctly, there are a few common approaches. The one that I have seen used the most often and that I have used is to include the version information in the namespace assigned to the Web Service. The SOAP and WS-Security specs use this approach.
Another is to add a version element or attribute to your request messages (or to a required header element). This also works but has the disadvantage of requiring that some parsing of the request message take place before the request can be routed correctly. It’s advantage is that the namespace name can be somewhat “cleaner” because it does not have to include version information.
Routing Requests For Versioned Services:
A third issue to consider is whether an additional component is needed to route requests for versioned services to the correct provider. Routing functionality like this is one of the services commonly found in ESB implementations of ESB products and is part of the Burton Group’s SOA Reference Architecture. (Click here, for a discussion of this Reference Architecture model by webMethods’ Miko Matsumura).
If you adopt a strategy of including version information in the namespace assigned to your Web Service, then you may not need a component other than IS to route requests to the correct provider. This is true, whether you populate the “Universal Name” of your “wrapper” service that expose an internal Flow or Java service or whether you use a custom soap processor to lookup or derive the name of the service to be invoked.
However, if the namespace name does not include version information, you will either need an custom SOAP processor to pre-process the soap request in order to extract the version information from the request and use it to lookup or derive the correct name of the service to be invoked. If an intermediary such as X-Broker or another ESB is available, it could be used to route the request appropriately.
Yet another option would be to register a new instance of a soap processor with its own directive (e.g. “/soap/v2services”) that would always route requests it received to the correct version. This strikes me as a kludge at best, but might do in a pinch if you did not control namespace names and did not have an intermediary.
Mark Carlson
