OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Matthew,

The conclusion I draw is that JAX-RPC 1.0 does not *fully* support WS-I.

I apologise for not mentioning JAX-RPC 1.1 in my original note, I certainly
intended to.  I have not seen a final JAX-RPC 1.1 Specification but looking
at the Change Log it seems that certain schema features will still not be
required so even 1.1 will not fully support Schema, but it will be a lot
better.

The Change Log also says, in section 2.13, "Morever (sic), we need to state
how tools should behave when encountering documents that use schema features
marked as optional" which suggests that there are still going to be features
of schema that are optional but the 1.1 Specification will state how tools
should handle them.

If a "rich" mapping to Java is given for these optional features then we
could get a usable programming model, even if it is not necessarily
supported by every JAX-RPC runtime.  If, however, the handling of optional
features is to map them to SOAPElement then that will not produce a usable
programming model and we would still need to produce a schema that used only
those schema features that JAX-RPC 1.1 regarded as mandatory.

John Colgrave
IBM


> -----Original Message-----
> From: Matthew J. Dovey [mailto:matthew.dovey@oucs.ox.ac.uk]
> Sent: 03 October 2003 22:05
> To: John Colgrave; UDDI Spec TC
> Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code
> generation
> 
> John,
> 
> WS-I clearly states that
> 
> "R2800 A DESCRIPTION MAY use any construct from XML Schema 1.0."
> 
> Although I don't think you can directly apply WS-I compliane to tools,
> but a tool which didn't allow you to implement a WS-I compliant
> WebService is certainly not in the spirit of WS-I, and I would have
> thought that most too vendors are working towards tools which "conform"
> to WS-I. In fact, one of the things I hoped to emerge from WS-I was some
> uniformity from WSDL code generation tools!
> 
> Likewise, I would argue that JAX-RPC cannot be argued to be support
> WS-I, if it only maps a subset of XML schema and WS-I says that any XML
> 1.0 construct can be used. The mission statement of WS-I is "The Web
> Services Interoperability Organization is an open industry effort
> chartered to promote Web Services interoperability across platforms,
> applications, and programming languages", so JAX-RPC is apparently
> within scope! So a pertinent question is why JAX-RPC does support WS-I!
> 
> Matthew
> 
> 
> 
> > -----Original Message-----
> > From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> > Sent: Friday, October 03, 2003 11:14 AM
> > To: 'UDDI Spec TC'
> > Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to
> > support code generation
> >
> > 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.
> >
> >
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]