I am deep into reworking my patch for TUSCANY-1341. It contains
some changes that should help with this. When I emerge later this
week with the new patch and we can get the patch applied, I'd like
to help with the second stage of this work as described by SimonL.
I think my patch will be a step in the right direction, and we
can take things forward from there.
Simon
Raymond Feng wrote:
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message ----- From: "Simon Laws" <[EMAIL PROTECTED]>
To: "tuscany-dev" <[email protected]>
Sent: Tuesday, July 03, 2007 6:20 AM
Subject: SCA binding and wiring
The SCA binding provides the default binding and appears when the user
doesn't explicitly provide a binding against a reference or a service.
The
Tuscany runtime can use the SCA binding to implement local wires between
components running in the same VM or remote wires between components
running
on different nodes.
There is a simple SCA binding implementation for the distributed
runtime (
binding.sca) which uses JMS for remote wires. Initially the intention had
been to hide all of the remote wiring parts of binding.sca behind the
reference and service providers but there are some issues with the way
wires
are managed with respect to the SCA binding. Specifically the ones I came
across were:
- The original SCA binding was implemented as part of the assembly
model and
there is an amount of code that appears in the process of wiring
references
to services that specifically checks for the presence of the SCA
binding and
does special things in that case. I would like to ensure that the special
things that are done are a product of the binding itself rather than the
builder and activator code.
By the assembly spec, the SCA binding is "special" in two senses:
1) SCA Binding will be used if no binding element is declared for a
service or reference
2) SCA Binding behaves differently on whether the interface is local or
remote
- There are a number of issues about how to identify the target of a
reference in various parts of the code. I believe this primarily boils
down
to the separation of targets and bindings, i.e. a reference has a set of
targets and a binding held independently. For example,
CompositeActivator.addBindingInterceptor() is creating binding
providers but
is not aware of which target is being addressed. This makes it tricky
from
within the binding to assess whether a local or remote wire is required.
To me, the "target" attribute is just a shortcut to define target URIs
for bindings that support the addressing by the logical name
(componentName/serviceName). SCA Binding is one of the bindings. The
binding itself can use the "uri" attribute to declare the
target if "target" is not present. The assembly spec explicitly makes
the "target" attribute of a reference element and "uri" attribute
of a binding element exclusive to avoid confusion.
Logically, binding should be holder of the target information.
Reference/Binding pair is the endpoint.
There were some disucssions on the resolving of targets at:
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200706.mbox/[EMAIL PROTECTED]
- If we want to have the SCA binding provide a facade of the remote
binding
that is actually in use then there is an issue with service invokers. The
service side expects to find an invoker based on the binding service
provider for the binding type in use. If SCA binding is acting as a
facade
the real binding type doesn't have a wire registered against it.
One option is to have the SCA binding provider to act differently based
on the interface and co-location. For example, if the interface is local,
the access method for the reference or service is purely java invocation
and no interceptor/listener is needed.
There may be more issues as I didn't get to the end of trying to make
this
work before seeking an alternative.
The solution in place now for these items has been to provide methods
on the
SCA Binding model that provide access to the remote binding that the SCA
binding is using for remote wires. During the build phase the SCA
Binding is
replaced with the remote binding (JMS currently) and the wire creation
process continues as normal. What I would like to do is look further
at how
we can move these features inside the SCA binding itself.
+1 to move these features inside the SCA binding. Mapping SCA binding to
an existing protocol doesn't mean to replace the binding.sca with
binding.xyz.
Potentially, we can map binding.sca to different protocols depending on
co-location or asynchrony. I think the runtime will need to derive more
metadata for SCA binding. For example, if we choose to use Web Service
protocol for SCA binding, we need to calculate the SOAP adddress based
on the logical
SCA names.
Does anyone have any background on the issues I mention above? Are
there any
other features that the SCA binding should be providing?
There as been much work in TUSCANY-1341 [1] relating to how wiring is
being
organized to ensure that callbacks work and I expect that this will
have a
(positive) impact on the ability to tidy up the SCA binding in this
respect.
These changes need to be taken into account also.
Simon
[1] http://issues.apache.org/jira/browse/TUSCANY-1341
---------------------------------------------------------------------
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]
