Hi, Simon.
I'm also looking into this area from a different perspective now: support
multiple bindings for references and services in terms of promotion and
wiring. I also remember Sebastien once suggested that we add a new
computedURI to the base Binding model.
I take the value of "target" attribute as a URI for the "sca" protocol
(i.e., sca:<componentName>/<serviceName>) and it can be converted to native
URIs supported by the bindings. For example, the binding.ws can construct a
HTTP URI for target "C1/S1" to be "http://localhost:8080/.../C1/S1"; assuming
binding.ws supports the logical SCA addressing. The binding provider can
then call the setComputedURI() to do the conversion as you proposed.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Wednesday, July 11, 2007 3:00 PM
Subject: Canonical form for binding URIs and reference targets
I'm looking at what it would take to eliminate the special handling
of the SCA binding within the core runtime when creating wires.
This would mean that all binding types are treated the same by the
core runtime and each binding provider implementation would be
responsible for providing the correct invocation semantics for its
binding type.
Reference binding endpoint URIs can be specified in various ways:
1. The uri attribute on a binding element.
2. The target attribute on a reference or wire.
3. Binding-specific attributes such as <binding.ws wsdlElement=.../>
where the value of the wsdlElement attribute is
<WSDL-namespace-URI>#wsdl.service(<service-name>) or
<WSDL-namespace-URI>#wsdl.port(<service-name>/<port-name>)
Currently the model holds each of these forms differently even
when they are semantically equivalent. This leads to two problems.
1. Different valid forms with the same semantics are not
interchangeable. For example,
<reference name="myref" target="mycomp/myservice"/>
is treated as a valid wire, but
<reference name="myref">
<binding.sca uri="mycomp/myservice"/>
</reference>
produces an error because wiring only looks at the target
attribute of the reference, not the uri attrbute of the binding.
2. Some SCDL errors are not detected. For example,
<reference name="myref" target="mycomp/myservice">
<binding.ws wsdlElement="mynamespace#wsdl.port(myport)"/>
<reference>
is an error because the target URI is specified by both the
reference and the binding. However,
<reference name="myref" target="mycomp/myservice">
<binding.ws wsdlElement="mynamespace#wsdl.binding(mybinding)"/>
<reference>
is valid. Currently the core runtime does not have enough
information to be able to flag an error for the first but not
the second. Another example is that the unpromoted reference
<reference name="myref"/>
is detected by the core runtime as unwired because the target
attribute is missing, but the unpromoted reference
<reference name="myref">
<binding.ws wsdlElement="mynamespace#wsdl.binding(mybinding)"/>
<reference>
is not detected as unwired even though it too has no target URI.
This is because the core runtime has no reliable means of finding
out from the Web Service binding extension that a target URI was
not specified.
My suggestion to fix this is to have the model use the uri attribute
of the binding as the canonical form of the target URI in all cases,
no matter which of the alternate forms was specified in SCDL.
The core runtime can do this canonicalization itself when the target
attribute is specified on a reference element or on a wire element,
but it needs some help from extension bindings when the target URI
is provided in a binding-specific way.
Specifically, this would mean that the resolve() method of extension
binding processors would need to call the Binding.setURI() method
if a binding-specific means of providing the target URI is used.
This would be a new requirement on extension bindings. It doesn't
change any SPI signatures but it could be regarded as a change to
the (currently unwritten) SPI contract.
What do people think about this approach?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
