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

[Anne Thomas Manes <anne@manes.net>]

If we're going to talk about standard Java interfaces to UDDI, then we 
should be talking about JAXR, not JAX-RPC. According to the JCP, JAXR is 
the single standard Java API for UDDI. I believe that JAXR is based on JAXM 
rather than JAX-RPC.

Bear in mind that JAX-RPC was initially designed to support RPC/encoded and 
not Document/Literal. The sample serialization framework defined in the 
current version of JAX-RPC (the first Appendix -- describing the JAX-RPC RI 
serialization framework) is based on SOAP Encoding -- not full XML Schema.

I don't think we should constrain our schemas due to shortcomings in the 
design of JAX-RPC.

Anne

At 11:14 AM 10/3/2003 +0100, John Colgrave wrote:
>This is a response to both Matthew and Daniel.
>
>I deliberately avoided mention of any particular product or tool and focused
>on standards.  In the case of Java that means JAX-RPC.  It is only when
>JAX-RPC mandates the mapping to Java for all of XML Schema, or at least the
>subset of XML Schema that we use in the description of UDDI, that we can
>reasonably expect to have a single standard Java programming model for UDDI.
>
>If similar standards exist for other languages then the same will hold for
>those languages. I know there are multiple tools that can generate code in
>languages other than Java but I don't know if there are standards similar to
>JAX-RPC for other languages.
>
>It is highly unlikely that all tools will support exactly the same set of
>extensions to the standard, and even less likely that they will all do so in
>a compatible way.  It is also unlikely that all tools will support the same
>set of optional features of the standard.
>
>I don't think WS-I is particularly relevant to this discussion as WS-I does
>not address programming interfaces.  There are some tools available, I have
>used the Analyzer tool to check the UDDI 3.0.1 WSDL and Schema descriptions.
>
>John Colgrave
>IBM
>
>
> > -----Original Message-----
> > From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk]
> > Sent: 02 October 2003 18:33
> > To: John Colgrave; UDDI Spec TC
> > Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code
> > generation
> >
> > John,
> >
> > This is an issue I've also raised in the past (being surprised when I
> > first encoutered UDDI that the authors of the v1 and v2 WSDL hadn't
> > tested with code generation tools already!), and I did do some quick
> > testing of the 3.0.1 WSDL through the .Net and Apache Axis WSDL2Java
> > compilers at the Moscow FTF. At present, the only issue which came
> > immediately to light (without a close inspection of the generated code,
> > and of course at the time I didn't have a UDDI v3 registry to test
> > against) was that Axis (which I suspect is as well used in Java circles
> > as JAX-RPC) couldn't handle constructs of the form
> >
> > <choice>
> >   <element name="something" />
> >   <sequence>
> >         <element name="something" />
> >         <element name="somethingelse" />
> >   </sequence>
> > </choice>
> >
> > I have this open as a bug against the Apache bugtraq system.
> >
> > Part of the problem, is that these tools are developing too (I've had
> > similar tool support trouble in another web service standard, where it
> > was tricky to balance modifying the standard against waiting for the
> > tools to develop). For example, when I tried the UDDI v3 WSDL last year
> > in Axis, little of it compiled due to lack of support for any but core
> > types, in Jan most went through apart from the above construct and about
> > 1 or 2 types. At the last check in July, only the above construct seemed
> > problematic.
> >
> > Matthew
> >
> > > -----Original Message-----
> > > From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> > > Sent: Thursday, October 02, 2003 5: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
> > >
> > >
> > >
> > >
> > > To unsubscribe from this mailing list (and be removed from
> > > the roster of the OASIS TC), go to
> > > http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members
> > > /leave_workgroup.php.
> > >
> > >
> > >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> > the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-
> > spec/members/leave_workgroup.php.
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/uddi-spec/members/leave_workgroup.php.