Changes to UDDI Schemas and WSDL to support code generation

["John Colgrave" <colgrave@hursley.ibm.com>]

This note is related to a discussion I initiated in the context of UDDI V4
back in March and which I let fizzle out.  I did not lose interest however,
indeed I have since been thinking about the issue in the context of UDDI V3.

I must apologize for the fact that the remainder of this note is going to
talk about one programming language/platform only.  This is a reflection of
my limited experience/knowledge.  I don't know if there are similar problems
with other languages/platforms, but I think the proposed solution/approach
will apply equally well to them, and we should take into account any
requirements of any other languages/platforms.

I must also apologize for the length of the note, but it could have been
worse: I could have included the gory details of all the changes.

I will write up the detailed changes as a Change Request if/when there is
agreement that what I am about to describe is worth doing.

I was surprised at how many different Java clients for UDDI V2 there were
when I did a simple search on the Web, and I think that it cannot help the
adoption of UDDI in general to have so many different client interfaces to
UDDI.  I would like to avoid this problem for UDDI V3.

Given that we have a description of the UDDI data structures and APIs in XML
Schema and WSDL, the obvious approach to providing a Java API for UDDI is to
use JAX-RPC and the mapping it defines from WSDL/Schema to Java.  There are
various tools available that can take a WSDL/Schema description and generate
Java code from it.

The problem for UDDI is that the current JAX-RPC specification does not
require support for all of the schema constructs that are used in the
description of UDDI, and therefore the various tools either do not implement
support for these constructs at all, or do not implement them in the same
way.  I would hope that the JAX-RPC and associated specifications evolve to
support XML Schema fully, but in the meantime I suggest changing the UDDI
schemas to use only those schema constructs that are required by JAX-RPC, as
that gives the best chance for all tools to support them the same way and
therefore allow for UDDI applications that are portable between JAX-RPC
implementations.

We could choose either to have one copy of the schemas or two until such
time as the specifications require support for enough of XML Schema, and
there are implementations of those future specifications available.  If we
choose to have one published version of the schemas then UDDI implementers
that use schema validation will have to maintain a separate version.  If we
choose to have two then we would have to keep the client/programming version
synchronized with the server version.  My current inclination is towards
having two versions so that we do not lose/forget what the original
intention was.