I have been trying to follow this discussion and I think I'm about 90%
up to speed (dangerous I know). Keeping the original binding information
around seems useful. Rebuilding the entire domain composite every time
there is a change seesm undesirable. Could we put the resolved/cloned
bindings in some other place in the model than the originals, so that
the originals are not overwritten?
Simon
Simon Laws wrote:
On Dec 12, 2007 12:10 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
My understanding is that the bindings represent the configured endpoints:
reference bindings are for outbound while service bindings are for
inbound.
When a source reference is wired to a target service, we need to make sure
they are compatible in terms of interface contract and intent/policy.
+1
To me, there might be two types of wires. One type is to wire components
in
the same composite and the other is to wire components from different
composites in the same SCA domain. For the first type, it's fairly static
as
the composite is probably the basic unit for update. It makes sense to
match
I agree that you could consider wiring within a composite to be fairly
static. We have to be careful though as a reference could have wires to both
"local" composite based services and "remote" domain based services. So we
cannot consider a reference to be either local or remote just the wires that
it gives rise to.
the bindings upfront. But for the second type, composites join and leave
the
SCA domain dynamically, it's very hard to keep the matched binding in
sync.
Is it even wise to attempt to resolve the bindings? Should we consider a
SCA
domain level service as the match-maker whenever the reference is used to
make an outbound invocation?
Not sure I understand the last sentence. Let me say a little about how this
could operate...
The domain has full view of all of the composites that are currently active,
i.e. it knows what the domain level composite looks like. Importantly it
also knows about the two important events that affect the domain level
composite. AddToDomainLevelComposite and RemoveFromDomain LevelComposite. On
these two events it is able to look across all services and references in
the domain and perform the same matching process as happens within each
composite. Well it could if it knew the original set of bindings for each
reference. During this process it also knows which references are being
updated as a result of this process so it can pass any updates that result
off to the appropriate nodes if composites have been started. So I don't
think in this process the assembly model recognizes any material difference
between composite and domain level wires. The difference is the process
through at which they are created.
Let's consider the other approach we mentioned. Whenever the domain level
composite is changed the domain level composite is rebuilt along with all of
the composites it includes. I'm sure changes could be made to the current
code to make this work in terms of building the model of the world that the
domain knows about. It would remove a requirement to store the original
bindings for references as the process for resolving references and services
from the domain level down would resolve references in a single pass. The
downside of this approach is it's difficult to tell what has changed.
We could approach this in a number of ways. Keep the old model and compare
against the new to determine changes. Pass each composite off to the node
that is running it and have it determine what has changed (this is what
happens at the moment on a limited basis in that only the composites that
are known to have changed are sent out). The brute force approach could be
taken where a the node is restarted based on the changed composite but this
sounds a bit heavy handed to me in as much that services could become
unavailable in the event that small (or no) changes are made to the
composites that the node is running.
Regards
Simon
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, December 11, 2007 2:25 PM
Subject: Re: Binding target information
On Dec 11, 2007 5:46 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi, Simon.
We went through a similar discussion before. The result is documented
at
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Multiple+bindings+and+reference+multiplicity
.
Can you check if it helps?
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
Sent: Tuesday, December 11, 2007 8:30 AM
Subject: Re: Binding target information
On Dec 11, 2007 3:11 PM, Mike Edwards
<[EMAIL PROTECTED]>
wrote:
Simon,
One of the questions here is whether the representation of the
targets
needs to mirror the alternate ways in which a target can be defined
by
the SCDL.
For example:
a) The target(s) can be defined by the @target attribute on the
reference. Each target can potentially use any one of the bindings
defined for the reference (which is used depends on the binding(s)
attached to each target service).
b) The target can be defined by the @uri attribute on the binding
(or
by
equivalent binding-specific data in other attributes or child
elements
of the binding). These targets are specific to the binding (and
typically there is only one per declared binding)
While it is reasonable to envision the first type of reference being
attached to the reference, I don't see that it is a good idea to
attach
the second type of reference to the reference - the second type are
clearly attached to a particular binding instance. (Consider the
case
where a reference has 2 binding.ws bindings attached, each with its
own
target defined in the @uri attributes, but where other aspects of
the
binding (eg policies) differ between the bindings.
While the target uri's may be technically interchangeable, in
reality
they have to be tied to the binding they are declared on - for
example,
one target may be within our business and require a low level of
security applid, while a second target may be outside our business
and
require a high level of security applied.
How do you think this plays out in the code?
Yours, Mike.
Simon Laws wrote:
When processing references at the domain level I need to know the
name
of
the target service which each reference binding is associated with
so
that I
can match the binding with the service name when the service
endpoint
is
made available or is moved or removed. As a work around I set the
binding
name to the target service name in the case that target services
cannot
be
resolved locally. Not ideal! .
I would like to propose that we add this information into the base
binding
model. For example,
public interface Binding extends Base {
Service getTargetService();
void setTargetService(Service service);
The other thing that this could help us sort out is the
OptimizableBinding.
This holds target service information. With the changes made to
take
the
majority of the domain logic out of the SCA binding I could get
away
with
just knowing the target service.
We do still have to be able to clone bindings (another feature of
OptimizableBinding) in the case where there is more than one
target.
If
I
understand it correctly the assembly model follows what you see in
composite
XML, For example,
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1
TargetService2">
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
Leads to a model that looks something like
Component
Reference
Targets
TargetService1
TargetService2
Bindings
binding.ws
binding.jsonrpc
With the obvious fun involved in working out which binding is
associated
with which target. If they both want to use the same binding it
has
to
be
cloned. Have I got this right? If so should we make bindings
generally
cloneable?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Two points then some examples...
1) There are other cases also as the target could be specified using
autowire or wireByImpl.
2) The runtime code is interesting at the moment in as much as the
service
resolution process gives rise to the reference binding list from the
input
composite being replaced by a list of bindings that represent
resolved
connections to target services.
A)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1 TargetService2">
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
may give rise to
reference
targets
TargetService1
TargetService2
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
This is where the effect is slightly odd. The result is right but we
loose
the original list of bindings from the reference.
B)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref">
<binding.ws uri="TargetService1"/ <http://binding.ws/>>
<binding.jsonrpc uri="TargetService2"/>
</reference>
</component>
may give rise to
reference
targets
? not sure if targets should be here
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.jsonrpc
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
But I can't see that the code does this at the moment although I
haven't
actually tried it to prove that it doesn't work.
C)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" >
<binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
/ <http://binding.ws/>>
</reference>
</component>
may give rise to
reference
targets
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
D)
<component name="SomeComponent">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" target="TargetService1 TargetService2">
<binding.ws uri="TargetService3"/ <http://binding.ws/>>
<binding.jsonrpc uri="TargetService4"/>
</reference>
</component>
This may give rise to the runtime model
reference
targets
TargetService1
TargetService2
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
E)
<component name="SomeComponent" autowire="true">
<implementation.java class="my.ComponentImpl"/>
<reference name="ref" >
<binding.ws/>
<binding.jsonrpc/>
</reference>
</component>
may give rise to
reference
targets
? would be handy to know the autowired target names
bindings
binding.ws
uri="http://localhost:8080/TargetService1";<http://binding.ws/>
binding.ws
uri="http://localhost:8080/TargetService2";<http://binding.ws/>
I don't know what happens with wire by impl but again it would seem
useful
if the target list included the names of services from the sca domain
that
have been wired.
So not sure if this answers your question.
Regards
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Raymond.
Thanks for pointing me back to that. I think maybe I'm only coming to
appreciate the significance of this by working through this again from
the
domain point of view. I have to admit that I had forgotten the detail in
your matrix. When I looked at the wiki a while ago I didn't cotton on to
the
fact that the "Normalized/Component Reference" column is actually all
that
is stored in the assembly model and that the original component
reference
binding information is not available after each composite has initially
been
built.
From the domain point of view that's a little inconvenient as it means
we
would have to rebuild the domain completely each time something changes
so
that you are starting with a clean slate, i.e. you have access to the
original bindings for matching purposes. If I drop a new wire into the
domain I can't simply go and match potential references to services as
the
bindings may no longer be a complete set. Actually it would work the
first
time but not if I dropped in another wire for the same reference. The
wires
must be present before the reference is built so the complete set of
required bindings can be determined.
So this is teasing out two points
1. Lack of original binding list once composites are built. We wouldn't
need
this if we were to rebuild the whole domain on each change but we would
have
to change the assembly builders to allow the domainLeveComposite to be
built
in one go as the original binding list is gone once a composite is
built.
The code currently doesn't treat includes correctly so it won't work as
is.
2. My original point. No generic way to find the target name for a
binding.
It's difficult to quickly identify the binding that satisfies a
particular
target so any operations to update bindings in a reference after it's
been
built are problematic.We could maybe ignore for now the scenario where
someone rewires a reference in a domain. However I am currently updating
reference bindings to complete endpoint information as I don't know the
endpoint information until a composite has been started in a node.
Regards
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]
