> 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
