[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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> 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> 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> John ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC