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

[Wai-Kwong Sam LEE <Sam.Lee@oracle.com>]

John Colgrave wrote:
> 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.

<SL>
Maybe I should have made it more clear. Consider the service interface 
that includes the method:
   HelloIF getHelloIFPort() throws ServiceException;

a. The interface HelloIF is totally dependent on the portType.
    The details can all be found in the portType WSDL.
    (Assuming all tools agree on the same java package name)

b. The service interface that defines the method getHelloIFPort()
is dependent upon <wsdl:service> definiton, specifically, the
localname of <wsdl:service> and the localname of <wsdl:port>s
included in the <wsdl:service>
(Again, assuming all tools agree on the same java package name)

To address the need of (a), we do not need a way to retrieve the 
localnames of <wsdl:port>s.

To address the need of (b), we do need a way to retrieve the localnames 
of <wsdl:port>s. If fact, we also need a way to retrieve the localname
of <wsdl:service>.

To close on the issue, I think we need to
1. agree upon whether both (a) and (b) are requirements (in WSDL-UDDIv2
    and WSDL-UDDIv3)
2. if we agree that both (a) and (b) are requirements, consider the
    potential solutions.

    The current text in the TN draft provides one solution
    (put wsdl:port localname
     in tModelInstanceInfo/instanceParms for UDDIv2;
     and in bindingTemplate/categoryBag for UDIv3).
    But the solution:
    - introduces additional complexity in upgrading
      from UDDIv2 to UDDIv3.
    - causes some data duplication (that is part of Claus' general
      concern.

    We, as a group, need to reach a conclusion on whether the
    trade-off is justified.

</SL>