Versioning Web Service Information in UDDI

This blog has been a great source of feedback from customers and industry colleagues. I'd like to use that channel a little more proactively now.

We're working with the UDDI TC on approaches to versioning (as the public OASIS UDDI meeting minutes show). We've currently identified that we want to take any web service object in UDDI (business services, binding templates, and portType and binding tModels generated following the "Using WSDL in UDDI" Tech Note) and put versioning information on any of them. Our current thinking is that this includes version numbering (usually a major.minor number but any content should be alright), revision or build information (of arbitrary content), milestone information (such as "latest revision"), and "component information" that can be used to logically tie together multiple objects. Unchecked taxonomy tModels can be created for each of these types of information. From any UDDI web service object (e.g. a portType tModel representing an interface definition) categories (keyedReferences) that refer to those tModels and whose keyValues reflects the version, revision, milestone and component.

All this is straightforward enough. A few questions:
- is it acceptable that this won't work for V2 bindingTemplates (categories can only be placed on UDDI V3 bindingTemplates)? Most versioning may take place on the portType tModels (the interfaces) so maybe this is okay.
- should the version be arbitrary content (any string) or should it be allowed to be numeric (possibly with a majorVersion category and minorVersion category)? Since UDDI will get range searching soon enough, this might be attractive. It is however, more complex (more categories necessary) and may not match with the version labeling methods of some shops.
- are there other semantically meaningful milestones that should be "built-in" besides "latest revision", "latest version".

I'm very curious how companies have versioned their web service information in their registries (UDDI-based or otherwise, from Systinet or elsewhere).

Comments

[Romin Irani]

This is an interesting thread. While I am not a guru on UDDI specs, I am currently involved in evaluating it for maintaining specifications, etc in a UDDI Registry.

I would like to add that the specifications that we are trying to maintain are basically XML Schema files that could go through multiple versions and there could be several active versions of each schema.

For e.g. consider a typical scenario.

An Organization ABC (DUNS = 123456789) is interested in receiving PIP documents (defined by the Rosettanet standard). The PIP Document is going to be described by a XML Schema published by Organization ABC (i.e. they super impose their own restrictions on a standard PIP Schema published by Rosettanet). For sake of simplicity, Organization ABC currently accepts only Inventory Reports (PIP 4C1). So, it publishes a XML Schema as follows (Please note this):

PIP4C1v02.00-123456789-v01.00

This is the only way of identifying a unique version in the current scenario. So the versioning is present not only for the PIP document (v02.00) but also for the revisions made to it i.e. v01.00. The 123456789 is the DUNS number to further uniquely identify that this publication is from a specific Organization.

Consider a given, that one also has to build in subscription information so that a partner XYZ gets notification if a newer version say :

PIP4C1v02.00-123456789-v01.05

is published.

I would love to know your thoughts about this.

Thanks.

[Manoj Kumar]

I am using UDDI v2 and somehow need to implement versioning for the services I am publishing. I though it will be a good idea to use the upcoming style.

Will you pl send me any link to the current state of the proposal about the versioning?

Thanks,
Manoj Kumar

[Don Smith]

I see this is an old entry, but it doesn't look like web service versioning metadata made it into the UDDI v3 spec. Is this correct? I've extended UDDI v2 to include versioning metadata and while I haven't dived into the v3 spec, I can't imagine that I wouldn't be able to do the same thing in v3 ... but I certainly don't want to if I don't have to because placeholders already exist. Thanks.