[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW ISSUE: Endpoint URI algorithm is unclear
Target: binding-ws-CD01-rev2 DESCRIPTION: In section 2.1 (lines 127 - 143), we have the following rules for resolution: The rules for resolving the URI at which an SCA service is hosted, or SCA reference targets, when used with binding.ws (in precedence order) are stated as: 1.The URIs in the endpoint(s) of the referenced WSDL or The URI specified by the wsa:Address element of the wsa:EndpointReference, 2.The explicitly stated URI in the @uri attribute of the binding.ws element, which can be relative, 3.The implicit URI as defined by the Assembly specification However, for item #1, the options separated by "or" do not appear to be mutually exclusive. At least, I cannot find text in the document that makes them so. If this text is meant to make them exclusive, then it doesn't say what to do if they're both present. I note that it is possible that the concrete WSDL addresses from a @wsdlElement port or service reference do not match the targets of deployment in the targeted SCA runtime. Must the SCA runtime throw an error in this circumstance? Further, for services, the assembly specification says that the @uri attribute MUST be relative (lines 2561-2563 of assembly CD-01), which makes #2 above confusing. Finally, the specification strongly implies the use of SOAP. Do we allow for any other binding than SOAP 1.1 & SOAP 1.2? Can we explicitly reference the wsdl:port/soap:address element here? Is it an error if the @uri attribute is present at the same time that the @wsdlElement also points to a port or service element? PROPOSAL: We might be better off enumerating the decision possibilities. To wit (and I think this needs some refinement): For a the binding element on a s service, stop after the first match: 1. If the @wsdlElement attribute is present: 1.a) and refers to a WSDL port element, the URI of the particular binding of the SCA service is the defined by that port element 1.b) and refers to a WSDL service element, the binding defines a URI for each of the port elements defined in the service. 2. If the wsa:EndpointReference element is present, and has a wsa:Address element with an absolute URI, the URI of the binding of service is that URI 3. If there is no wsa:EndpointReference element, then compute the address of the service according to SCA assembly rules. 3.a) if the @uri attribute is present, it must be relative, and the actual URI is computed by computing by combining this with the address of the service. 3.b) if the @uri attribute is absent, the actual binding URI is the address computed for the service. 4. If there is wsa:EndpointReference element with a relative wsa:Address element, compute the address as per #3, and combine the relative address from wsa:Address with the result. (At this point, having determined a URI, we can separately address the question of the EPR's reference parameters) For a binding element on a reference, stop after the first match: 1. If the @wsdlElement attribute is present and refers to a WSDL port element, the URI of the particular binding of the SCA service is the defined by that port element (note - I don't think it makes sense to reference a WSDL "service" here, the ambiguity serves no purpose) 2. If the wsa:EndpointReference element is present, and has a wsa:Address element with an absolute URI, the URI of the binding for the reference is that URI. ...? (At this point, after looking at this for almost an hour, I ran into the difficulty of figuring out exactly what we intend. Which is part of the point of the issue. I found composing the above decision tree quite difficult with the above text, and didn't manage to complete it in the time I allotted myself.)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]