[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]