P&P Summit Day Two: Versioning Web Services 2.0

Blog

Don Smith was up next to talk about versioning web services. He’s a program manager for P&P group.

The presentation is more of a sounding board for some of the guidance the P&P group would like to give about versioning web services this coming December. Nothing stated in this entry is necessarily what P&P is wanting to do or they consider they have it licked. They want feedback.

The difficulties involved are things like:

  • Communication is the key to understanding. You have to include communication of upcoming changes.
  • Favor evolution over creation. Provide a way to evolve your service rather than create a completely new service.
  • All changes are either consistent, or not (backward/forward compatible or not).   
  • Business mandates can trump your efforts (semantic changes will too). Breaking changes due to business mandates can really affect the versioning. A semantic change can be just as bothersome. For example, changing the meaning of an existing data point.

Some ideas that P&P has on mitigating these issues are:

  • What if all the message parts on the interface (contract) were optional? All the data points are still strongly typed, but the contents are not required. (Validation would be discussed later).    Several comments on why this would be bad, such as the validation and that we really wouldn’t have that much of a contract. Even a comment that you could have one service for all messages within your enterprise.
  • What if we used WSDL & XSD for what they do well, but not what they do poorly? For example, message validation is not done well with WSDL and XSD because not all the rules are enforced when the code is generated via the tools. WSDL is good for code generation itself, it’s okay at communicating service requirements, but is not good at enforcing the service requirements.
  • Don throws an idea out there that says what if we used a different XSD for validation than we used to describe the interface/contract that was exposed by the WSDL.
  • A comment was made about having a specific contract and a loose contract.    Don responded he liked that idea, but that they should be in the same service so that the loose contract attempts to map the incoming request to something it understands until it validates that it has everything before handing it to the more specific contract.
  • Ignore the things you don’t understand. In this loose contract you should start to ignore extra information as it comes in until you are ready to deal with it. This supports the forward and backward compatibility.
  • The service (I think he means service provider in this case) should be responsible for the quality of the communication and is responsible for the versioning strategy and policy. He talked about using UDDI, extending it with metadata, to include versioning information. This is about raising the level of communication of changes of services.
  • Change management process should be communicated.
  • Consumer constraints should be addressed with consumer-specific data. When clients aren’t willing to move to the next version of the service. This means you need some sort of client identification in the message to ensure you can deal with this.
  • This approach can be applied after-the-fact. The concepts above can perhaps be applied after the fact and not design in up front.

Very different session I’d have to say, but it did fly by quicker than some of the other sessions. Kind of hard to do a conversation style presentation with 300+ people.

At first I thought he meant having a very loose service descriptor on the front exposed to the consumer, but then a more strict one internally. You could be very loose in your clients using your service, but then still make changes to the internal one separately, maybe even use different ones internally as different versions of the service are used. When I asked about this he responded that he didn’t see them as separate services, but rather a loose service that may throw faults when it needs something more specific, ignore incoming data it didn’t need and communicates upcoming changes. Interesting.