RE: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

John,

Here are some more comments - this time not inline ;-)

I begin to understand what you are looking for. Additionally to the interoperability I'd like to see addressed (taking my WS-I hat on again ...), you are also looking for portability in terms of unique mapping to programming envrionments.
My fear at this stage is that if we couple the UDDI registration of a Web service too closely to its description in WSDL we might run into WSDL's challenges.

In general, I have three questions:

1) What happens, if WSDL 1.2 comes out and we realize that it is in some way incompatible to WSDL 1.1? We would then not only have to develop a third version of our WSDL TN/BP but also face the problem that existing UDDI registrations won't conform to the new TN/BP version - even if the TN/BP requirements haven't changed.

2) Why do we have to care for existing approaches of mapping WSDL to programming environments? In my view, UDDI is a different species and should have its own mapping approach, if needed.

3) Alternative naming and identifying schemes of UDDI entities were discussed for a long time during UDDI V2 and V3 development and led to the availability of publisher-assigned keys in V3. When I want to publish my Web services by taking the wsdl:ports and rendering uddi:bindingTemplates out of them, I have to identify the bindingTemplates anyway. And if I really want to use the same naming conventions I used in WSDL, I can register a key generator tModel (or use an existing one) that uses the WSDL targetNamespace as its domain, and I use the port's name to identify the bindingTemplate - the concatenation of targetNamespace and port local name would be the bindingTemplate's key. This idea could HELP in finding appropriate keys for new bindingTemplates - and would also meet your requirements. I assume you don't require to search for bindingTemplates based on the WSDL targetNamespace or the port's local name, right?

Claus

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Freitag, 22. November 2002 12:01
To: Wai-Kwong Sam LEE
Cc: uddi-spec
Subject: Re: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service


Sam,

You say that the stub implementation is inherently different across
different tools but the interfaces that the application code should be
written to should not be, only the implementations.  JAX-RPC defines how to
map from WSDL to a Java interface and an application should be written to
that standard generated interface.

Note that JAX-RPC defines an interface that is generated from the WSDL
service definition as well as an implementation-specific class that
implements that (standard) interface, so any JAX-RPC compliant tool should
produce a generated service interface that includes the getHelloIFPort
method in your example, but the class that implements that interface will be
different in each one.

This allows you to change tool/runtime without having to change your code,
but relies on the other tools having the same WSDL file to be able to
generate compatible code, where "the same" means the same namespace name,
the same set of ports etc.

John
----- Original Message -----
From: "Wai-Kwong Sam LEE" <Sam.Lee@oracle.com>
To: "John Colgrave" <colgrave@hursley.ibm.com>
Cc: "uddi-spec" <uddi-spec@lists.oasis-open.org>
Sent: Thursday, November 21, 2002 5:11 PM
Subject: Re: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service


> See <SL> at the end.
>
> John Colgrave wrote:
> > Claus,
> >
> > See below.
> >
> > John
> > ----- Original Message -----
> > From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
> > To: "'John Colgrave'" <colgrave@hursley.ibm.com>; "uddi-spec"
> > <uddi-spec@lists.oasis-open.org>
> > Sent: Wednesday, November 20, 2002 3:41 PM
> > Subject: RE: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service
> >
> >
> >
> >>John,
> >>
> >>Please find <CvR>my comments</CvR> below.
> >>
> >>Claus
> >>
> >>-----Original Message-----
> >>From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> >>Sent: Mittwoch, 20. November 2002 12:11
> >>To: uddi-spec
> >>Subject: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service
> >>
> >>
> >>This requirement was raised by Karsten, and I believe the current IBM
> >>tooling generates the deployment WSDL so it would seem to be a
requirement
> >>of at least Microsoft and IBM.  In general I can readily envision
> >>application development/deployment tools that will generate the
deployment
> >>information as a service is deployed.  If these tools work with UDDI,
the
> >>obvious thing for them to do would be to generate the UDDI metadata
> >>dynamically and add it to the registry.  To work with programming
> >
> > languages
> >
> >>such as Java however, they would need to produce the deployment WSDL so
> >
> > that
> >
> >>the correct service class etc. could be generated.
> >>
> >>If a different person wanted to use the deployment WSDL, I would think
it
> >>would be useful for them also to be able to generate it from the same
UDDI
> >>registry using a tool.  This is the kind of thing that the current IBM
> >
> > tools
> >
> >>do.
> >>
> >><CvR>I'm not arguing against the generation of WSDL deployment documents
> >
> > in general. My issue is that I don't see a requirement so far to
generate
> > the very same wsdl:service that was once described in the Web service
> > provider's WSDL deployment document previous to the registration of the
WSDL
> > artifacts in UDDI.</CvR>
> >
> > <JC>
> > I think I have already described that the wsdl:service is used with
JAX-RPC
> > to generate a bunch of Java and the structure and operation of this Java
> > code depends on the namespace name and the port names, not to mention
the
> > ports that are part of the service, so unless you generate the same
> > deployment WSDL from UDDI you will not get the same Java code generated
so
> > two developers that happen to use two different tools will end up with
> > different Java interfaces to the same service, which is not good.
> >
> > Given that you have to have the same service namespace, the same service
> > name, the same set of ports, each with the correct local name, I am not
sure
> > you could do anything but generate an equivalent, if not identical,
> > deployment WSDL.
> > <JC>
> >
> >>The namespace name and local name are required for the generation of the
> >>deployment WSDL for two reasons:
> >>
> >>1) The proposal on the table in the W3C WSDL group for equivalence is
for
> >>QName-based equivalence, so two WSDL services would be regarded as
> >>equivalent if they had the same namespace name and the same local name.
> >>Similarly for ports etc.  Assuming multiple people want to generate
> >>equivalent deployment WSDL from the same UDDI metadata, this means that
we
> >>have to capture the namespace name and the local name of each WSDL
element
> >>that might be compared.
> >>
> >><CvR>Assuming multiple people want to generate equivalent deployment
WSDL
> >
> > from the same UDDI metadata, this means that the Web service provider
has to
> > separately publish the ports that are to be registered in UDDI. Each
> > resulting bindingTemplate can then be used by a Web service consumer to
> > generate corresponding deployment WSDL again. This is independent of the
> > fact whether or not the WSDL's namespaces and local names are captured
in
> > the bindingTemplate. The Web service consumer can choose any naming
> > convention for the deployment WSDL's service and port elements in order
to
> > generate proxies in the client infrastructure (this is the only reason I
can
> > think of why the Web service consumer might have to generate the
deployment
> > WSDL). What finally counts when the Web service is invoked at the Web
> > service provider's side is a valid message (specified by the WSDL
portType)
> > that arrives over a suitable protocol (specified by the WSDL binding) at
the
> > network address that was once spe!
> >
> >>cified by the Web service provider (in the WSDL port extension).</CvR>
> >
> >
> > <JC>
> > You can't do the generation at the port level.  See comments above and
in
> > another thread.
> >
> > You have to have the right namespace name(s) and port names, and you
have to
> > have the right set of ports if you want to be able to produce the same
Java
> > code and have a single shared programming model for the service.
> >
> > You are right that what finally counts at the web service provider's
side is
> > what comes over the wire but you are adopting that limited WS-I
viewpoint
> > again. :-)
> > </JC>
> >
> >>2) The namespace name and local name are used, for example, in the
> >>generation of Java from WSDL, where the namespace name is mapped to a
Java
> >>package and the local name is mapped to a class name, or just used with
> >
> > the
> >
> >>namespace name to identify something, a port for example, via a
> >>javax.xml.namespace.QName, so the QName is surfaced as part of the
> >>programming model.
> >>
> >><CvR>This seems to be a reasonable approach but I don't see a reason yet
> >
> > why we have to rely on the service's namespace and the port's local name
> > from the orginal deployment WSDL (see my comment above).</CvR>
> >
> > <JC>
> > Partly because somebody may have already produced the "master"
programming
> > language artefacts from it, which is just a special case of the fact
that I
> > hope I have demonstrated that we can't leave it up to tools to just make
up
> > these names therefore they have to be stored in UDDI.  Given that we
have to
> > have them in UDDI they may as well be correct!
> > </JC>
> >
> <SL>
> John, could you elaborate more on the imporatnce of preserving port
> QName / service QName from a client's perspective?
>
> Take a simple helloWorld service as an example
> (used in Sun's JAXRPC tutorial)
> Assume
> 1. a developer gets a deployment WSDL that is fabricated by a UDDI tool
> (i.e., port QName and service QName are made up).
> 2. the developer wants to generate some client stub to invoke the service,
>
> What the developer will get:
> - a client interface : modeled based on the portType
> - An Stub that implmenets the client interface: generated
>    by the JAXRPC tool and is tool specific.
> - When a client invokes the Stub, he may need to write some code
>     like this (adapted from jax-rpc tutorial):
>      HelloIF hello = (new HelloWorld_Impl().getHelloIFPort());
>      hello.sayHello("Duke!");
>
> - In this scenario:
>    - the stub internally may rely on port QName / service QName,
>      but it is totally hidden from the developer's code.
>    - what gets sent on the wire (the actual SOAP message) is,
>      again, independent of the port QName / service QName.
>
>
> Now consider another devloper uses another JAX-RPC tool and
> another UDDI-tool to generate some client stub.
>
> The developer will get:
> - exactly the same client interface (since it's based on the same
portType)
> - the stub implementation (including naming, package, etc.) may
>    be different. But they are inherently different across
>    different jaxrpc tools. Furthermore, what gets sent on the
>    wire (the SOAP message) will exactly the same.
>
>
> Based on the above reasoning, I don't see why the service QName / port
> QName must be preserved for the purpose of generating  client stubs.
>
> I bet I am missing something. John, could you elaborate?
>
>
> </SL>
>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>