Re: [sca-bindings] ISSUE-54: Endpoint URI algorithm is unclear

[Eric Johnson <eric@tibco.com>]

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