sca-bindings message
[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 - non-hierarchicalURIs
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Bindings <sca-bindings@lists.oasis-open.org>
- Date: Tue, 4 Nov 2008 10:39:05 +0000
Folks,
One point that I would like to make
in the debate on this issue is that the use of the @uri attribute on a
<binding/> element for a service
is really more up to the bindings TC than the assembly TC, although
the description of that element and
the attribute are both in the Assembly specification.
In particular, the requirement for @uri
to be a relative URI for a binding on a <service/> element should
really be dictated by the bindings TC.
If it is interpreted to be a relative URI, the obvious question is
relative to what? And as Eric
points out there are URI schemes that are non-hierarchical.
So, it might be best to say that @uri
for a service is a URI that MAY be absolute or relative, depending on the
binding type involved. The rules
about relative URIs then must be spelled out by any binding that
permits them.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Eric Johnson <eric@tibco.com>
|
To:
| OASIS Bindings <sca-bindings@lists.oasis-open.org>
|
Date:
| 03/11/2008 17:33
|
Subject:
| Re: [sca-bindings] ISSUE-54: Endpoint
URI algorithm is unclear - non-hierarchical URIs |
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:
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
---------------------------------------------------------------------
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]