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


JAXR is an abstraction API that is designed to allow access to a variety of
registries.  It does not claim to support all of the capabilities of any one
registry, so I doubt that it will ever completely replace specific clients
for each registry.

Work has not yet started on a version of JAXR that addresses UDDI V3 so I
imagine that if we do not support the generation of a standard Java API from
WSDL that we will see a multitude of UDDI V3 Java clients, just as we saw
with UDDI V2.

This is not a question of interoperability so I don't think the UDDIBuilders
effort is relevant to this discussion.  This is a question of application
portability, and as such may well be outside the normal remit of OASIS.  I
quite like the suggestion of a Technical Note to contain the simplified
schemas as that keeps a clear distinction from the spec. itself and can
easily be amended or withdrawn as appropriate.

I think the WSDL changes need to be made to the "real" WSDL descriptions,
and the associated changes made to the specification.  As I mentioned in my
original note, I think the WSDL changes are strategic whereas the schema
changes are tactical.

John Colgrave
IBM


> -----Original Message-----
> From: Anne Thomas Manes [mailto:anne@manes.net]
> Sent: 06 October 2003 13:04
> To: UDDI Spec TC
> Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support code
> generation
> 
> Agreed -- but JAXR is the "official" (per the JCP) Java API for accessing
> UDDI.
> 
> I think my primary point here is that UDDI should not constrain its
> schemas
> based on Sun's early interpretation of how to implement Java support for
> Web services.
> 
> Sun has turned around and seems genuinely supportive of SOAP/WSDL/UDDI Web
> services these days, but the specs still represent Sun's earlier
> resistance
> to the technology.The JAXR effort was led by someone who preferred ebXML
> reg/rep over UDDI. JAXM was led by someone who preferred ebXML ebMS over
> SOAP. JAX-RPC was led by someone who thought SOAP was strictly for RPC.
> Regardless of Sun's current commitment to SOAP/WSDL/UDDI, the current
> specs
> reflect this early prejudice. I think it will take another release cycle
> of
> the specs (or perhaps a complete rearchitecture) before they properly
> support the document/literal style being adopted by the industry.
> 
> Most UDDI providers include a UDDI client API. A couple of years ago
> Systinet tried to initiate a UDDIBuilders effort to establish a forum to
> test interoperability among various UDDI clients and servers, although the
> timing was a bit unfortunate -- they did it about a week before WS-I
> launched, so no one seemed interested in joining the effort. But just as
> SOAPBuilders complements WS-I, so does UDDIBuilders. Perhaps we ought to
> re-examine Systinet's idea?
> 
> Anne
> 
> At 10:03 AM 10/6/2003 +1000, Rogers, Tony wrote:
> >But JAX-R is not a proper mapping to UDDI - it applies some imperfect
> >mapping to its own abstractions. There are a number of UDDI constructs
> >that don't map to JAX-R.
> >
> >Tony.
> >
> >-----Original Message-----
> >From: Anne Thomas Manes [mailto:anne@manes.net]
> >Sent: Saturday, 4 October 2003 3:13
> >To: John Colgrave; 'UDDI Spec TC'
> >Subject: RE: [uddi-spec] Changes to UDDI Schemas and WSDL to support
> >code generation
> >
> >
> >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_wo
> >rkgroup.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_wor
> >kgroup.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]