More comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, July 12, 2007 7:13 AM
Subject: Re: Canonical form for binding URIs and reference targets
Comments inline.
Simon
scabooz wrote:
Hi guys,
More comments inline. There are some issues with
multiplicity and multiple bindings.
Dave
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, July 11, 2007 7:22 PM
Subject: Re: Canonical form for binding URIs and reference targets
Comments inline.
Raymond Feng wrote:
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.
+1. This approach is cleaner than overloading setURI() for this
purpose.
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.
>
I didn't interpret the spec this way, though it is not 100% clear. At
the
end of section 1.7.3, it says that the value of the URI if specified via
the uri attribute must be <domain-component-name>/<service-name> (i.e.,
without sca:). I wonder if this is a typo and the intention was to say
that this form is used if the value of the uri is specified via the
target attribute.
Section 1.7.3 of the Assembly spec is talking about @uri on the binding.
It's a coincidence that the @target value is similar.
This was my understanding as well. So to specify a uri instead of a
target for the default binding, the SCDL would be
<reference name="myref">
<binding.sca uri="mycomp/myservice"/>
</reference>
and not
<reference name="myref">
<binding.sca uri="sca:mycomp/myservice"/>
</reference>
Sorry for the confusion. I meant to use "sca:mycomp/myservice" internally to
represent a SCA URI. Sure, at the SCDL level, there is no
"sca:".
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.
>
Strictly speaking, this is not the value in the target attribute but
the target's URI as computed by the rules in 1.7.2.1. They will
often be the same, but not always.
Correct.
The binding provider can then call the
setComputedURI() to do the conversion as you proposed.
This takes care of the case when the binding's URI is set from the
SCA target's URI. It doesn't take care of the case where the
binding's URI is set from binding-specific information such as
<binding.ws wsdlElement="mynamespace#wsdl.port(myport)"/>
In this case, the code in ReferenceUtil.validateMultiplicityAndTargets()
needs to know whether or not there is a computed URI, and the provider
has not been created yet. In this case I think it is the binding
extension processor that would need to call setComputedURI().
Simon
Thanks,
Raymond
----- Original Message ----- From: "Simon Nash" <[EMAIL PROTECTED]>
To: <[email protected]>
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>)
There are more scenarios to consider which both cause problems
with your canonicalization algorithm, let's start with these examples:
(I)
<reference name="myref" target="C1/S1 C2/S2" multiplicity="1..n"/>
<binding.sca/>
</reference>
The spec currently says that @uri only contains a single URI, so how do
you handle this case?
At a pinch, the could be canonicalized to multiple bindings each with
a single effective target URI. This isn't quite correct because you
can't have two bindings with the same default name, so this canonical
form wouldn't quite match the original. I am beginning to lean towards
using the effective wires as the canonical form, as shown on the Wiki page
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity
that Raymond created.
Please help me to make sure all the effective wires are correctly
interpreted. There are questions to be answered. Maybe I should bring it to
the spec people for clarification.
(II)
<reference name="myref" target="C1/S1" multiplicity="1..n"/>
<binding.sca/>
<binding.ws/>
</reference>
This means: There is one target, use any of the bindings.
Is not semanticly equivalent to the following, which means
there are two endpoints for myref, requiring the Java reference
to be a list type. The fact that they have the same endpoint
URI is irrelevant.
<reference name="myref" multiplicity="1..n"/>
<binding.sca uri="C1/S1"/>
<binding.ws uri="C1/S1"/>
</reference>
After some thought, I understand the reason for this distinction.
The first example has used the target attribute to reduce the
multiplicity to 1, but the second example hasn't. In the second
example, you seem to be taking the presence of two binding elements
to imply a multiplicity of 2, though I don't see this clearly
stated in the Assembly spec. Also, in both your examples, one of
the binding elements would need a non-default name to be specified,
sinces binding element names on a reference must be unique.
There might also be some differences to consider for
promoted references, but I'm seeing them clearly at the
moment.
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.
I agree with your analysis of the above cases, but your solution has
problems that I tried to illustrate above. I think what you need is
another place to store this info in the model which would allow you
to capture the multiplicity semantics correctly, perhaps in combination
with your algorithm.
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]
