> I think the time is approaching when programming interfaces for UDDI will
> be
> able to be generated automatically from the UDDI WSDL descriptions. I
> think
> we should take this into account when designing and describing the UDDI
> data
> structures and programming interfaces.
I’d support this.
I had (naively) assumed that it would have been possible to generate the programming interfaces for UDDI from the WSDL (naively assuming that this was supposed to be one of the benfits of WSDL!). Certainly as the interface becomes more complicated, I'd argue that this is essential if we want to see take up of UDDI.
In practice, I've find it difficult to generate the API's using the existing published WSDL and the Axis java based toolkit. A major problem has been unsupported XML Schema types in the Axis toolkits. At the last attempt Axis 1.1 beta I think that there was one unsupported type which I had to hack around. The problem at the moment (although I've not tried the latest Axis 1.1 Rc2 yet) is when we hit structures of the form
The Axis toolkit would generate code of the form
String description[];
String overviewURL;
String overviewURL;
(the first overviewURL being from the first part of the choice within the sequence, and the second from the second part of the choice).
I can’t speak for other toolkits (so this may be a peculiarity of Axis) or for the recent 1.1 RC2. In some of the other WebService work, I’ve been involved with we have gone out of the way to make sure that ther structures are such that the WSDL does pass through as many toolkits as possible (in some cases at the expense of concise XML in the opinion of some of the designers).
Matthew