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


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.




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