RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code generation

["Daniel Feygin" <feygin@unitspace.com>]

I have mixed feelings about dumbing down the schema just to comply with the
limited capability of supposedly XML Schema-compliant tools.  Indeed some of
the tools I have come across are not equipped to handle UDDI V3 schema and
fail miserably to generate valid Java code (even despite claims of support
to the WS-I Basic Profile, which, if I interpret it correctly, mandates full
compatibility with XML Schema - perhaps these claims will be put to test
when WS-I releases compliance testing tools).  This applies equally to the
non-JAX-RPC Java tools also.  However I have tested and used UDDI V3 schema
and WSDL with Microsoft .NET Framework SDK without a problem.  By dumbing
down V3 schema we would will those tools vendors who have done a good job
implementing W3C's XML and Web services specs.
 
Going back to our own motivations, the present lack of complete support for
XML Schema specification in a large share of available tools poses adoption
barriers for UDDI.  This is clearly an issue we must address and our only
means of dealing with it is by adjusting the schema and WSDL.

I believe John's proposal to maintain two versions of the schema - one as it
is intended to be with proper modeling constraints, etc. and a more
lightweight one that is 'portability enhanced' - is the best approach.  So
when designing UDDI schema we would first implement the authoritative
version relying on all appropriate constructs offered by XML Schema, then
simplify it to work around known tools issues thus producing the light
version.

I now see that the subscriptionResultsList in subscription API might have
been intentionally codified with a sequence of multiple optional elements
when the inherent model was a choice between those elements (see CR-008
http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/1111/udd
i-spec-tc-cr008-subscriptionresults-20021206.doc).  It is still inconsistent
with the subscriptionFilter though, which uses a choice model.  In this
instance, following John's proposed dual maintenance approach, we should
first correct the subscriptionResultsList schema by converting it to the
choice model and then produce a subscription API schema with no choice
constructs in either subscriptionResultsList or subscriptionFilter.

Since we are on this topic, I would also suggest renaming message parts in
WSDL port type to be unique (they are currently all named "body") - some
tools may generate methods with multiple parameters named "body" (for input
and output messages); I have come across one such fairly popular tool.
Instead message parts could have their name derived from the name of the
corresponding element as in the case of message names.  Another issue I came
upon was that portType, binding and service declarations all have to be in
the same file.

To be clear, I also see a problem in the proliferation of custom client APIs
for UDDI, whether it be IBM-SAP-HP's uddi4j, Sun's JAXR, Microsoft's UDDI
SDK or the handful of others that I am aware of.  This clearly defeats the
purpose of producing portable interface descriptions.

Daniel


> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
> Sent: Thursday, October 02, 2003 8:16 PM
> To: 'UDDI Spec TC'
> Subject: [uddi-spec] Changes to UDDI Schemas and WSDL to 
> support code generation
> 
> 
> 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.
> 
> From my experiments to date, these schema changes can be made 
> without requiring UDDI implementations to change, which is 
> good, but my experiments also indicate that even with these 
> changes some implementations do not generate correct Java 
> code for the entire UDDI API, so some tweaking of the 
> generated code is necessary in those cases.
> 
> The schema changes fall into several different categories.
> 
> The first category is related to the use of constructs such 
> as xsd:choice that are nor mandatory in JAX-RPC 1.0.  It is 
> possible to replace the use of such constructs with a more 
> lax approach using sequences of elements, each of which is 
> optional.  This allows applications to be developed which can 
> generate invalid messages of course, but I am not aware of 
> any environment that applies schema validation to a message 
> being sent by a client, so even with the current schemas you 
> cannot guarantee that a client will never send an invalid 
> message so this is not introducing any new problem.
> 
> The second category is related to elements/types that have 
> been introduced only to limit string lengths etc. such as 
> validationTypeString255.  These currently show up in the 
> generated programming model, which is ugly.  In this case 
> also, I am not aware of this checking being applied to 
> outbound messages from a client, so nothing is lost by 
> removing these and just using the base types such as string.
> 
> The third category is related to things that are supported in 
> a proprietary way, which obviously limits application 
> portability.  If my memory serves, these can be avoided by an 
> approach similar to that for the second category, and 
> replacing something like NMTOKEN with string.
> 
> The fourth category is for things such as extensions of 
> xsd:boolean that I do not think add any value and again show 
> up as unnecessary complications in the generated code.  An 
> example of this is truncated.  I think that it is highly 
> unlikely that anyone will want to extend truncated beyond 
> simply true and false.
> 
> There are also a couple of things that need to be 
> added/changed to the UDDI WSDL.  These changes to the WSDL 
> are "strategic", by which I mean that I see no sign of them 
> ever not being required.
> 
> The first of these is that WSDL service and port definitions 
> need to be created, as these affect the Java programming 
> model.  Unfortunately this means that a default/dummy 
> endpoint has to be supplied for each port but the user can 
> supply the correct one at runtime.
> 
> The second is that we need to change the element used to 
> indicate success on calls such as delete_tModel that 
> currently use dispositionReport, as Java does not like the 
> same element being used as both a normal output and a fault.  
> I have created an empty success element for this case, as 
> mentioned in the WS-I Basic Profile.  This will require a 
> change to the UDDI specification and possibly a change in 
> implementations.  My experiments indicate that the 
> implementations do not have to change, and if a 
> dispositionReport is returned when the Java is not expecting 
> one, it is simply ignored, but we may not be able to rely on 
> this.  This change is the most significant one and may 
> require a publication of a 3.1.1 spec. or something.
> 
> John Colgrave
> IBM