A follow-up point occurred to me after I shut off my computer for the
day on Friday.
For some URI schemes that can be used for SOAP bindings (at least, in
theory), those URI schemes may not be hierarchical like http(s).
Specifically, both the "jms" and "mailto" schemes ("udp"?) are not
hierarchical. Which means that even in my proposed resolution, rules
#3 and #4 below may not make sense under certain conditions, because
there is no meaning to a "relative" wsa:EndpointReference when the
scheme itself isn't relative.
Anyway, our proposal for the default binding (proposed resolution to
issue #11) - the meat of which is here:
http://lists.oasis-open.org/archives/sca-bindings/200809/msg00052.html
has this sentence at the beginning: "This section
describes the defaults that MUST be used
if the specific transport
details are not otherwise specified." That would mean, of course, a
vendor could theoretically support something like a policy intent of
"jms" on binding.ws. However, if they do that, it would contradict the
rules for the URI generation.
-Eric.
Eric Johnson wrote:
490F30B0.70608@tibco.com" type="cite">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
---------------------------------------------------------------------
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
|