Applying WS-I Basic Profile

Stefan is applying the WS-I Basic Profile in his current project. You chose wisely, Grasshopper! :-)

He enumerates some of the project's guidelines:

3. All of our functional extensions — e.g. transactions (which will likely not include but I’ll use as an example anyway) — will be implemented using SOAP and WSDL extension mechanisms. This means that there may be custom SOAP headers, e.g. to propagate a transaction context, as well as meta-data, e.g. in the form of elements from other namespaces within our WSDLs.

It’s the last point that I’m not 100% percent sure about yet. I believe the Basic Profile does not restrict the usage of extensions such as SOAP headers or additional WSDL elements — while they’ll obviously impact interoperability with simple and out-of-the-box service consumers and providers, it would be perfectly possible to interact with services that use these extensions if the toolkit or implementation technology of outside or 3rd parties support access to those extension elements. In other words: A service that expects certain specific SOAP headers to be set, or a WSDL that includes custom extensions, could still be profile compliant.

This is indeed a good question. I may possibly be able to shed some light on the matter.

As I explain in my article on the new WS-I Profiles, there are now three profiles: Basic Profile 1.1 (BP1.1), Simple Soap Binding Profile 1.0 (SSBP1.0) and the Attachments Profile 1.0 (AP1.0). These can be used in conjunction with eachother as follows: BP1.1, BP1.1 + SSBP1.0 and BP1.1 + AP1.0. The WS-I Testing Tools can be used to test for each of these three conformance configurations.

The Basic Profile 1.1 includes some extensibility points which, if exploited, are flagged by the WS-I Testing Tools (note that the BP1.1 testing tools are not yet final, but are in the approval cycle and should be available soon) as warnings. Thus, you can be conformant with the profile with the caveat that interoperability may be compromised.

However, there is a twist to the use of extensibility points in WSDL bindings if you want to also claim conformance to the Simple Soap Binding Profile 1.0 as it constrains the WSDL binding to be only the WSDL SOAP binding, exclusive of any extensions. So, for those cases where the WSDL SOAP binding is used in conjunction with some other WSDL extension, it may be best to simply claim conformance only with the Basic Profile 1.1.

Also, if there will be use of SOAP headers, then in order to enable interoperability, it might be best to avoid use of the SOAP mustUnderstand attribute if at all possible. Construct the service such that it can function without the headers. Thus, clients that don't support the extensions, can still access the service and clients that do support the extensions can take advantage of the increased functionality, etc. Just a thought.

It will be interesting to follow the progress on his project!

Technorati Tags: webservices, interoperability, wsi