This is a single archived entry from Stefan Tilkov’s blog. For more up-to-date content, check out my author page at INNOQ, which has more information about me and also contains a list of published talks, podcasts, and articles. Or you can check out the full archive.

Applying WS-I Basic Profile

Stefan Tilkov,

I’m currently working on trying to define the best way to apply the WS-I’s Basic Profile specification in a complex SOA scenario. In this particular project, we are building a set of tools, libraries, and technical services that together form a rich infrastructure platform for a very large, global company. One of the project’s decisions was to stick to standards wherever possible, adopt public specifications and best practices as wherever useful, and build whatever remains in a proprietary way as an intermediary solution (and move to standards as they become available and mature).

One of the goals, of course, is to enable the best possible interoperability without reducing our ambitious functional objectives. Thus, we are considering adopting the WS-I Basic Profile, and have come up with a set of pragmatic rules that I’d like to put here to gather some feedback:

  1. We’ll use WSDL 1.1 for describing service contracts, and validate our descriptions using the WS-I’s own testing tools. As we’ll have other transport protocols than HTTP (which is a transfer protocol, but never mind), only some of our endpoints are going to be profile compliant; that doesn’t seem to be a problem, though, as long as we’re claiming conformance only for those that actually are conforming. For this, we are going to use the compliance claim attachment mechanism. We’ll apply that, as well as the UDDI v3 WSDL-to-UDDI mapping best practice (which is actually a technical note), to publish our descriptions to our UDDI-based service registry. A profile-conforming WSDL will also be used as the input for our various code generation tools. This way, we’ll ensure that the largest possible number of tools and toolkits in the market will be able to accept our service descriptions as input.

  2. For all of infrastructure (technical) services (or rather, ports) that are part of the platform, we’ll introduce SOAP/HTTP bindings (possibly in addition to others), claim conformance, and ensure it using appropriate test cases and the WS-I testing tools. This way, we’ll make sure that independently developed services will be able to access our infrastructure components.

  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.

My plan is to follow up on this entry as I gather more information and become more familiar with WS-I’s work. And of course I have that strange feeling I might have more than a couple of readers who’d actually be more than qualified to help me go into the right direction ;-)