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