[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [uddi-spec] WSDL TN: Issue 5 - identification of port
Claus, See below as usual. 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: Thursday, November 21, 2002 8:36 AM Subject: RE: [uddi-spec] WSDL TN: Issue 5 - identification of port > John, > > Please find <CvR>my comments</CvR> below. > > Claus > > -----Original Message----- > From: John Colgrave [mailto:colgrave@hursley.ibm.com] > Sent: Mittwoch, 20. November 2002 15:42 > To: uddi-spec > Subject: [uddi-spec] WSDL TN: Issue 5 - identification of port > > > > I think I have already covered at least part of this in one of the earlier > notes. One reason for requiring the namespace name and local name in the > UDDI metadata is so that equivalent deployment WSDL can be generated by two > independent tools. > > <CvR>O.k. That means we should better agree on the meaning of "equivalence" in this context. What I tried to say in my earlier response to the "WSDL TN: Issue 2 - generation of wsdl:service" was that equivalence of ports in two separate deployment WSDL documents is given when they are generated from the same bindingTemplate - by using the referenced binding tModel and the contained accessPoint. Naming of the port element and its cointaining service element doesn't count for equivalence. If the port name in the first generated deployment WSDL is built by using the bindingTemplate's bindingKey and the port name in the second generated deployment WSDL is built by concatenating the businessEntity:name, the businessService:name and the name of the binding tModel, it is still the same Web service if the port's network address is the same in the two deployment WSDL documents.</CvR> <JC> I believe I have already pointed out that the proposal for equivalence in the W3C WSDL group is simple name equivalence so two ports would be equivalent if they had the same namespace name and the same local name. </JC> > The local name is also required in the wsdlDeployment case where a service > has more than one port and only the base URL of the deployment WSDL file is > in UDDI, that is, we are not using XPointer. > > <CvR>We should either require referenced deployment WSDL documents to contain only one port or use the XPointer mechanism as we used in the WSDL BP V1 to distinguish between different bindings. Or we should revisit our wsdlDeployment scenario and discuss what it means if the WSDL contains more than one port.</CvR> > <JC> I would not agree with placing any artificial limitations on the structure of WSDL files that could be used with UDDI. We could use XPointer but the local name would still have to be there. The advantage of XPointer would be that it could be used by a generic browsing tool or something like that but for UDDI-specific tooling I think it would be much easier to extract the information from the UDDI structures as currently defined. I don't understand your comment about the wsdlDeployment scenario. Can you elaborate? </JC> > I am not sure that you cannot define more than one targetNamespace in a > single WSDL file so the namespace may also be required to uniquely identify > the correct service/port in the wsdlDeployment case also. > > We could choose not to categorise the bindingTemplate with the port > namespace in the V3 model, but at the cost of requiring the containing > service to be retrieved to find it. > > 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