You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/07/03 15:20:27 UTC
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.
- 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.
- 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.
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.
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
Re: SCA binding and wiring
Posted by Simon Nash <na...@hursley.ibm.com>.
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" <si...@googlemail.com>
> To: "tuscany-dev" <tu...@ws.apache.org>
> 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/%3c017601c7a46c$c5475c80$9e343809@dbooz%3e
>
>
>>
>> - 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: SCA binding and wiring
Posted by Raymond Feng <en...@gmail.com>.
Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <si...@googlemail.com>
To: "tuscany-dev" <tu...@ws.apache.org>
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/%3c017601c7a46c$c5475c80$9e343809@dbooz%3e
>
> - 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org