[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] ISSUE-54: Endpoint URI algorithm is unclear
Logged as: http://www.osoa.org/jira/browse/BINDINGS-54 -Eric. Eric Johnson wrote: > 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.) > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]