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.

More on WS-I Profiles

Stefan Tilkov,

As I had hoped, Chris Ferris, who is extremely knowledgeable about WS-I Basic Profile (which somehow fails to surprise me, since he’s one of the editors), has some answers related to yesterday’s WS-I questions.

He explains that although there are some extensibility points within the Basic Profile 1.1, the Simple SOAP Binding Profile 1.0 forbids any non-profile compliant bindings. His suggestion is to get around this by claiming only Basic Profile conformance. If my reading of the spec is correct, another workaround would be to separate the WSDL into its abstract part (schemas, messages, operations and portTypes) and into one or more concrete bindings. The abstract part would be BP 1.1 compliant, the concrete part would claim conformance to the Binding Profile (where applicable). The only downside I can see is that this way, it will not be possible to use a single wsdl:service with multiple wsdl:port elements. But that is something I’d be willing to accept.

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.

This is of course excellent advice. I agree in principle, with the slight difference that where certain header is required to be processed (from a functional point of view — again, the transaction context is a good example), it should be indicated with the mustUnderstand attribute. After all that’s what it’s for. But if course this should be used as restrictively as possible.