You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@verizon.net> on 2006/08/15 23:14:25 UTC
Composite references - wiring and model and runtime representations
One of the composite reference scenarios outlined by Jeremy has a local wire between the Component and the Reference, and an external wire from the CompositeComponent to a sibling Component or Reference (aka the "uncle"). For instance:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="OuterComposite">
<component name="SourceComponent">
<implementation.composite name="InnerComposite"/>
<references>
<reference name="TargetComponentRef" target="TargetComponent"/>
</references>
</component>
<composite name="InnerComposite">
<service name="" target="InnerSourceComponent">
<interface.java interface="..."/>
</service>
<component name="InnerSourceComponent">
<implementation.java class="SourceImpl"/>
<references>
<reference name="target" target="TargetComponentRef"/>
</references>
</component>
<reference name="TargetComponentRef">
<interface.java interface="..."/>
</reference>
</composite>
<component name="TargetComponent">
<implementation.java class="TargetImpl"/>
</component>
</composite>
There are two issues to consider: (1) how the composite reference "TargetComponentRef" gets modeled, and (2) how is the composite reference "TargetComponentRef" is wired by the wiring infrastructure.
(1) Model and runtime objects for a targetless composite reference. A targetless composite reference does not have a binding and it is not specified by a component and given a target. So, at the model level the object that represents this kind of composite reference is not a BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain ReferenceDefinition instance that is considered separately by CompositeBuilder to get its runtime representation built. In fact, ReferenceLoader seems to deal with this case already, returning a ReferenceDefinition instance when there is no binding, so it's just a matter of setting up the CompositeBuilder and registering a builder for the ReferenceDefinition with the builder registry. At the runtime level we seem to have agreed on the definition of a CompositeReference class that extends ReferenceExtension. The other piece that is needed is a builder that creates a CompositeReference, that is registered with the builder registry and that takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems a new class is needed, perhaps ReferenceBuilder or CompositeReferenceBuilder.
(2) Wiring a targetless composite reference. In the example above, TargetComponentRef does not specify an explicit target or a binding, its target is intended to be resolved by a component that is implemented by the composite that contains TargetComponentRef, SourceComponent in this case. When SourceComponent is being built by CompositeBuilder, a runtime representation is created for it, e.g., a CompositeComponentImpl. When an outbound wire is being added to the created CompositeComponentImpl by WireService, via the BuilderRegistry, the CompositeComponentImpl should pass on this wire to the runtime representation of TargetComponentRef, i.e., CompositeReference. This way, a CompositeComponent "shares" the outbound wire of its target with the corresponding CompositeReference. This way, the behavior of ConnectorImpl can be to just connect the outbound wire in SourceComponent's CompositeComponentImpl and not to recurse down into TargetComponentRef as it is sharing the same wire that was already connected.
One question that arises is: should passing on wires happen recursively down? For instance, since the reference in InnerSourceComponent is to a composite reference, should the outbound wire given to the CompositeComponent that represents InnerSourceComponent come from the composite reference, i.e., TargetComponentRef?
Re: Composite references - wiring and model and runtime representations
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 16, 2006, at 6:36 AM, Ignacio Silva-Lepe wrote:
> There are two issues to consider: (1) how the composite reference
> "TargetComponentRef" gets modeled, and (2) how is the composite
> reference
> "TargetComponentRef" is wired by the wiring infrastructure.
>
> (1) Model and runtime objects for a targetless composite reference. A
> targetless composite reference does not have a binding and it is not
> specified by a component and given a target. So, at the model level
> the
> object that represents this kind of composite reference is not a
> BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
> ReferenceDefinition instance that is considered separately by
> CompositeBuilder to get its runtime representation built. In fact,
> ReferenceLoader seems to deal with this case already, returning a
> ReferenceDefinition instance when there is no binding, so it's just
> a matter
> of setting up the CompositeBuilder and registering a builder for the
> ReferenceDefinition with the builder registry. At the runtime level
> we seem
> to have agreed on the definition of a CompositeReference class that
> extends
> ReferenceExtension. The other piece that is needed is a builder
> that creates
> a CompositeReference, that is registered with the builder registry
> and that
> takes a ReferenceDefinition. This can't be a BindingBuilder, so it
> seems a
> new class is needed, perhaps ReferenceBuilder or
> CompositeReferenceBuilder.
>
Yes this seems right to me. Raymond was preparing to make some
changes to builder dispatching so could you coordinate with him and
I'll apply patches?
> (2) Wiring a targetless composite reference. In the example above,
> TargetComponentRef does not specify an explicit target or a
> binding, its
> target is intended to be resolved by a component that is
> implemented by the
> composite that contains TargetComponentRef, SourceComponent in this
> case.
> When SourceComponent is being built by CompositeBuilder, a runtime
> representation is created for it, e.g., a CompositeComponentImpl.
> When an
> outbound wire is being added to the created CompositeComponentImpl by
> WireService, via the BuilderRegistry, the CompositeComponentImpl
> should pass
> on this wire to the runtime representation of TargetComponentRef,
> i.e.,
> CompositeReference. This way, a CompositeComponent "shares" the
> outbound
> wire of its target with the corresponding CompositeReference. This
> way, the
> behavior of ConnectorImpl can be to just connect the outbound wire in
> SourceComponent's CompositeComponentImpl and not to recurse down into
> TargetComponentRef as it is sharing the same wire that was already
> connected.
> One question that arises is: should passing on wires happen
> recursively
> down? For instance, since the reference in InnerSourceComponent is
> to a
> composite reference, should the outbound wire given to the
> CompositeComponent that represents InnerSourceComponent come from the
> composite reference, i.e., TargetComponentRef?
>
This brings up some interesting issues. Composite References have
inbound and outbound wires. So in a typical component-->reference
wiring, we have:
component outbound wire--->reference inbound wire--->reference
outbound wire
I think it may be simpler to preserve this as opposed to optimizing
the reference away since multiple components may point to the same
composite reference. So, in the above scenario, it is modeled the
same, with the reference inbound wire being an implementation detail
of the composite:
InnerSourceComponent/OutbindWire---> TargetComponentReference/
InboundWire---> TargetComponentReference/OutboundWire given to the
containing composite and propagated down
The connecting from the inner component to the inner reference would
be done first and then the containing composite would receive the
outbound wire and attach it to the inner reference.
Jim
>
>
> ---------------------------------------------------------------------
> 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: Composite references - wiring and model and runtime representations
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 17, 2006, at 12:02 PM, Ignacio Silva-Lepe wrote:
> Yep, you're right. However, to have a ReferenceDefinition with a
> reference target but not a binding, I would have to create a new
> spi.model class. Unless it has a big impact on, for instance, the
> loader code, it would be nice if we could say that a
> ReferenceDefinition _can_ have a target URI but it does not have
> to. I have not delved into the loader code enough to tell whether
> its worth the class savings. So let me know whether you think it
> would or would not work.
>
I'd prefer to try the extra class route first since having things
that are valid in one context but not another on the same class can
lead to trouble.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite references - wiring and model and runtime representations
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Yep, you're right. However, to have a ReferenceDefinition with a reference
target but not a binding, I would have to create a new spi.model class.
Unless it has a big impact on, for instance, the loader code, it would be
nice if we could say that a ReferenceDefinition _can_ have a target URI but
it does not have to. I have not delved into the loader code enough to tell
whether its worth the class savings. So let me know whether you think it
would or would not work.
----- Original Message -----
From: "Jim Marino" <jm...@myromatours.com>
To: <tu...@ws.apache.org>
Sent: Thursday, August 17, 2006 2:45 PM
Subject: Re: Composite references - wiring and model and runtime
representations
>
> On Aug 17, 2006, at 11:29 AM, Ignacio Silva-Lepe wrote:
>
>> One more thing. AIUI, the assembly spec defines a <service/> element as
>> containing a required reference URI. This means that getTarget and
>> setTarget really belong in spi.model.ServiceDefinition and not just in
>> BoundServiceDefinition. So unless there are any objections, I'll promote
>> these methods to ServiceDefinition.
>>
> That's for a <service> definition in a composite but not in the component
> type. I it seems like the issue we are running into is it depends on how
> you look at things.
>
> Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite references - wiring and model and runtime representations
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 17, 2006, at 11:29 AM, Ignacio Silva-Lepe wrote:
> One more thing. AIUI, the assembly spec defines a <service/>
> element as containing a required reference URI. This means that
> getTarget and setTarget really belong in
> spi.model.ServiceDefinition and not just in BoundServiceDefinition.
> So unless there are any objections, I'll promote these methods to
> ServiceDefinition.
>
That's for a <service> definition in a composite but not in the
component type. I it seems like the issue we are running into is it
depends on how you look at things.
Jim
> ----- Original Message ----- From: "Ignacio Silva-Lepe"
> <is...@verizon.net>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, August 16, 2006 2:04 PM
> Subject: Re: Composite references - wiring and model and runtime
> representations
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite references - wiring and model and runtime representations
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
One more thing. AIUI, the assembly spec defines a <service/> element as
containing a required reference URI. This means that getTarget and setTarget
really belong in spi.model.ServiceDefinition and not just in
BoundServiceDefinition. So unless there are any objections, I'll promote
these methods to ServiceDefinition.
----- Original Message -----
From: "Ignacio Silva-Lepe" <is...@verizon.net>
To: <tu...@ws.apache.org>
Sent: Wednesday, August 16, 2006 2:04 PM
Subject: Re: Composite references - wiring and model and runtime
representations
> Ok, so for issue (1) it seems that the builder needed to build
> CompositeReference and CompositeService needs to be exposed to the spi,
> since CompositeBuilder needs to ask the builder registry to build these
> objects. So the plan is to add methods to build these objects to
> spi.builder.Builder. And since BuilderRegistryImpl needs to be able to
> delegate to an appropriate builder, then we also need a spi.builder
> interface for them. Not sure what to call it. BindingBuilder does the
> corresponding thing for bound references and services. I'll try something
> like BindlessBuilder for now and we can rename it if/when we find
> something better. Of course, all this is up for debate, so let me know.
>
> ----- Original Message -----
> From: "Ignacio Silva-Lepe" <is...@verizon.net>
> To: <tu...@ws.apache.org>
> Sent: Wednesday, August 16, 2006 9:36 AM
> Subject: Re: Composite references - wiring and model and runtime
> representations
>
>
>> Raymond, thanks for the corrections, I was not using the latest spec and
>> I made up the nesting. I append my original note with the correct scdl to
>> restart the thread. As for your questions, (1) yes, the intention is that
>> InnerComposite be executed in the same address space as OuterComposite,
>> and (2) for the purposes of this thread, I am focusing on composite
>> references, but similar issues apply to composite services, so in
>> particular, we can imagine a third (or zeroth) component in
>> OuterComposite that is wired to SourceComponent to invoke it locally via
>> its composite service.
>>
>> -------------------- Original Note ----------------------
>> One of the composite reference scenarios outlined by Jeremy has a local
>> wire
>> between the Component and the Reference, and an external wire from the
>> CompositeComponent to a sibling Component or Reference (aka the "uncle").
>> For instance:
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> name="OuterComposite">
>>
>> <component name="SourceComponent">
>> <implementation.composite name="InnerComposite"/>
>> <reference name="TargetComponentRef">TargetComponent</reference>
>> </component>
>>
>> <component name="TargetComponent">
>> <implementation.java class="TargetImpl"/>
>> </component>
>>
>> </composite>
>>
>> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
>> name="InnerComposite">
>>
>> <service name="InnerComponentService" target="InnerSourceComponent">
>> <interface.java interface="..."/>
>> </service>
>>
>> <component name="InnerSourceComponent">
>> <implementation.java class="SourceImpl"/>
>> <reference name="target">TargetComponentRef</reference>
>> </component>
>>
>> <reference name="TargetComponentRef">
>> <interface.java interface="..."/>
>> </reference>
>>
>> </composite>
>>
>>
>> There are two issues to consider: (1) how the composite reference
>> "TargetComponentRef" gets modeled, and (2) how is the composite reference
>> "TargetComponentRef" is wired by the wiring infrastructure.
>>
>> (1) Model and runtime objects for a targetless composite reference. A
>> targetless composite reference does not have a binding and it is not
>> specified by a component and given a target. So, at the model level the
>> object that represents this kind of composite reference is not a
>> BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
>> ReferenceDefinition instance that is considered separately by
>> CompositeBuilder to get its runtime representation built. In fact,
>> ReferenceLoader seems to deal with this case already, returning a
>> ReferenceDefinition instance when there is no binding, so it's just a
>> matter
>> of setting up the CompositeBuilder and registering a builder for the
>> ReferenceDefinition with the builder registry. At the runtime level we
>> seem
>> to have agreed on the definition of a CompositeReference class that
>> extends
>> ReferenceExtension. The other piece that is needed is a builder that
>> creates
>> a CompositeReference, that is registered with the builder registry and
>> that
>> takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems
>> a
>> new class is needed, perhaps ReferenceBuilder or
>> CompositeReferenceBuilder.
>>
>> (2) Wiring a targetless composite reference. In the example above,
>> TargetComponentRef does not specify an explicit target or a binding, its
>> target is intended to be resolved by a component that is implemented by
>> the
>> composite that contains TargetComponentRef, SourceComponent in this case.
>> When SourceComponent is being built by CompositeBuilder, a runtime
>> representation is created for it, e.g., a CompositeComponentImpl. When an
>> outbound wire is being added to the created CompositeComponentImpl by
>> WireService, via the BuilderRegistry, the CompositeComponentImpl should
>> pass
>> on this wire to the runtime representation of TargetComponentRef, i.e.,
>> CompositeReference. This way, a CompositeComponent "shares" the outbound
>> wire of its target with the corresponding CompositeReference. This way,
>> the
>> behavior of ConnectorImpl can be to just connect the outbound wire in
>> SourceComponent's CompositeComponentImpl and not to recurse down into
>> TargetComponentRef as it is sharing the same wire that was already
>> connected.
>> One question that arises is: should passing on wires happen recursively
>> down? For instance, since the reference in InnerSourceComponent is to a
>> composite reference, should the outbound wire given to the
>> CompositeComponent that represents InnerSourceComponent come from the
>> composite reference, i.e., TargetComponentRef?
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite references - wiring and model and runtime representations
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Ok, so for issue (1) it seems that the builder needed to build
CompositeReference and CompositeService needs to be exposed to the spi,
since CompositeBuilder needs to ask the builder registry to build these
objects. So the plan is to add methods to build these objects to
spi.builder.Builder. And since BuilderRegistryImpl needs to be able to
delegate to an appropriate builder, then we also need a spi.builder
interface for them. Not sure what to call it. BindingBuilder does the
corresponding thing for bound references and services. I'll try something
like BindlessBuilder for now and we can rename it if/when we find something
better. Of course, all this is up for debate, so let me know.
----- Original Message -----
From: "Ignacio Silva-Lepe" <is...@verizon.net>
To: <tu...@ws.apache.org>
Sent: Wednesday, August 16, 2006 9:36 AM
Subject: Re: Composite references - wiring and model and runtime
representations
> Raymond, thanks for the corrections, I was not using the latest spec and I
> made up the nesting. I append my original note with the correct scdl to
> restart the thread. As for your questions, (1) yes, the intention is that
> InnerComposite be executed in the same address space as OuterComposite,
> and (2) for the purposes of this thread, I am focusing on composite
> references, but similar issues apply to composite services, so in
> particular, we can imagine a third (or zeroth) component in OuterComposite
> that is wired to SourceComponent to invoke it locally via its composite
> service.
>
> -------------------- Original Note ----------------------
> One of the composite reference scenarios outlined by Jeremy has a local
> wire
> between the Component and the Reference, and an external wire from the
> CompositeComponent to a sibling Component or Reference (aka the "uncle").
> For instance:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> name="OuterComposite">
>
> <component name="SourceComponent">
> <implementation.composite name="InnerComposite"/>
> <reference name="TargetComponentRef">TargetComponent</reference>
> </component>
>
> <component name="TargetComponent">
> <implementation.java class="TargetImpl"/>
> </component>
>
> </composite>
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
> name="InnerComposite">
>
> <service name="InnerComponentService" target="InnerSourceComponent">
> <interface.java interface="..."/>
> </service>
>
> <component name="InnerSourceComponent">
> <implementation.java class="SourceImpl"/>
> <reference name="target">TargetComponentRef</reference>
> </component>
>
> <reference name="TargetComponentRef">
> <interface.java interface="..."/>
> </reference>
>
> </composite>
>
>
> There are two issues to consider: (1) how the composite reference
> "TargetComponentRef" gets modeled, and (2) how is the composite reference
> "TargetComponentRef" is wired by the wiring infrastructure.
>
> (1) Model and runtime objects for a targetless composite reference. A
> targetless composite reference does not have a binding and it is not
> specified by a component and given a target. So, at the model level the
> object that represents this kind of composite reference is not a
> BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
> ReferenceDefinition instance that is considered separately by
> CompositeBuilder to get its runtime representation built. In fact,
> ReferenceLoader seems to deal with this case already, returning a
> ReferenceDefinition instance when there is no binding, so it's just a
> matter
> of setting up the CompositeBuilder and registering a builder for the
> ReferenceDefinition with the builder registry. At the runtime level we
> seem
> to have agreed on the definition of a CompositeReference class that
> extends
> ReferenceExtension. The other piece that is needed is a builder that
> creates
> a CompositeReference, that is registered with the builder registry and
> that
> takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems a
> new class is needed, perhaps ReferenceBuilder or
> CompositeReferenceBuilder.
>
> (2) Wiring a targetless composite reference. In the example above,
> TargetComponentRef does not specify an explicit target or a binding, its
> target is intended to be resolved by a component that is implemented by
> the
> composite that contains TargetComponentRef, SourceComponent in this case.
> When SourceComponent is being built by CompositeBuilder, a runtime
> representation is created for it, e.g., a CompositeComponentImpl. When an
> outbound wire is being added to the created CompositeComponentImpl by
> WireService, via the BuilderRegistry, the CompositeComponentImpl should
> pass
> on this wire to the runtime representation of TargetComponentRef, i.e.,
> CompositeReference. This way, a CompositeComponent "shares" the outbound
> wire of its target with the corresponding CompositeReference. This way,
> the
> behavior of ConnectorImpl can be to just connect the outbound wire in
> SourceComponent's CompositeComponentImpl and not to recurse down into
> TargetComponentRef as it is sharing the same wire that was already
> connected.
> One question that arises is: should passing on wires happen recursively
> down? For instance, since the reference in InnerSourceComponent is to a
> composite reference, should the outbound wire given to the
> CompositeComponent that represents InnerSourceComponent come from the
> composite reference, i.e., TargetComponentRef?
>
>
>
> ---------------------------------------------------------------------
> 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: Composite references - wiring and model and runtime representations
Posted by Ignacio Silva-Lepe <is...@verizon.net>.
Raymond, thanks for the corrections, I was not using the latest spec and I
made up the nesting. I append my original note with the correct scdl to
restart the thread. As for your questions, (1) yes, the intention is that
InnerComposite be executed in the same address space as OuterComposite, and
(2) for the purposes of this thread, I am focusing on composite references,
but similar issues apply to composite services, so in particular, we can
imagine a third (or zeroth) component in OuterComposite that is wired to
SourceComponent to invoke it locally via its composite service.
-------------------- Original Note ----------------------
One of the composite reference scenarios outlined by Jeremy has a local wire
between the Component and the Reference, and an external wire from the
CompositeComponent to a sibling Component or Reference (aka the "uncle").
For instance:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="OuterComposite">
<component name="SourceComponent">
<implementation.composite name="InnerComposite"/>
<reference name="TargetComponentRef">TargetComponent</reference>
</component>
<component name="TargetComponent">
<implementation.java class="TargetImpl"/>
</component>
</composite>
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="InnerComposite">
<service name="InnerComponentService" target="InnerSourceComponent">
<interface.java interface="..."/>
</service>
<component name="InnerSourceComponent">
<implementation.java class="SourceImpl"/>
<reference name="target">TargetComponentRef</reference>
</component>
<reference name="TargetComponentRef">
<interface.java interface="..."/>
</reference>
</composite>
There are two issues to consider: (1) how the composite reference
"TargetComponentRef" gets modeled, and (2) how is the composite reference
"TargetComponentRef" is wired by the wiring infrastructure.
(1) Model and runtime objects for a targetless composite reference. A
targetless composite reference does not have a binding and it is not
specified by a component and given a target. So, at the model level the
object that represents this kind of composite reference is not a
BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
ReferenceDefinition instance that is considered separately by
CompositeBuilder to get its runtime representation built. In fact,
ReferenceLoader seems to deal with this case already, returning a
ReferenceDefinition instance when there is no binding, so it's just a matter
of setting up the CompositeBuilder and registering a builder for the
ReferenceDefinition with the builder registry. At the runtime level we seem
to have agreed on the definition of a CompositeReference class that extends
ReferenceExtension. The other piece that is needed is a builder that creates
a CompositeReference, that is registered with the builder registry and that
takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems a
new class is needed, perhaps ReferenceBuilder or CompositeReferenceBuilder.
(2) Wiring a targetless composite reference. In the example above,
TargetComponentRef does not specify an explicit target or a binding, its
target is intended to be resolved by a component that is implemented by the
composite that contains TargetComponentRef, SourceComponent in this case.
When SourceComponent is being built by CompositeBuilder, a runtime
representation is created for it, e.g., a CompositeComponentImpl. When an
outbound wire is being added to the created CompositeComponentImpl by
WireService, via the BuilderRegistry, the CompositeComponentImpl should pass
on this wire to the runtime representation of TargetComponentRef, i.e.,
CompositeReference. This way, a CompositeComponent "shares" the outbound
wire of its target with the corresponding CompositeReference. This way, the
behavior of ConnectorImpl can be to just connect the outbound wire in
SourceComponent's CompositeComponentImpl and not to recurse down into
TargetComponentRef as it is sharing the same wire that was already
connected.
One question that arises is: should passing on wires happen recursively
down? For instance, since the reference in InnerSourceComponent is to a
composite reference, should the outbound wire given to the
CompositeComponent that represents InnerSourceComponent come from the
composite reference, i.e., TargetComponentRef?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Composite references - wiring and model and runtime representations
Posted by Raymond Feng <en...@gmail.com>.
Hi,
First, there're some syntax issues for the SCDL. Sorry for being picky here,
just don't want to mislead some folks.
1) By the SCA spec 0.95 draft, I don't think you can nest "composite"
elements inside a "composite". I guess you meant to implement a component
using another composite here. In that case, you need to define the composite
in a separate SCDL.
2) <reference> should be direct child of <component> instead of
<references>. And the element text of <reference> is the target instead of
"target" attrobute.
Second, I think I ran into a similar issue as you brought up here. Usually,
you can deploy a composite and the composite can provide services over the
service bindings as well as consume other services via the bound references.
Now you implement a component using another composite (InnerComposite), is
the InnerComposite coming into the same address space as OutComposite? How
does the CompositeImplementation invoker invoke InnerComposite via the bound
services (remotely or locally)?
Thanks,
Raymond
----- Original Message -----
From: "Ignacio Silva-Lepe" <is...@verizon.net>
To: "Tuscany Dev" <tu...@ws.apache.org>
Sent: Tuesday, August 15, 2006 2:14 PM
Subject: Composite references - wiring and model and runtime representations
One of the composite reference scenarios outlined by Jeremy has a local wire
between the Component and the Reference, and an external wire from the
CompositeComponent to a sibling Component or Reference (aka the "uncle").
For instance:
<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
name="OuterComposite">
<component name="SourceComponent">
<implementation.composite name="InnerComposite"/>
<references>
<reference name="TargetComponentRef" target="TargetComponent"/>
</references>
</component>
<composite name="InnerComposite">
<service name="" target="InnerSourceComponent">
<interface.java interface="..."/>
</service>
<component name="InnerSourceComponent">
<implementation.java class="SourceImpl"/>
<references>
<reference name="target" target="TargetComponentRef"/>
</references>
</component>
<reference name="TargetComponentRef">
<interface.java interface="..."/>
</reference>
</composite>
<component name="TargetComponent">
<implementation.java class="TargetImpl"/>
</component>
</composite>
There are two issues to consider: (1) how the composite reference
"TargetComponentRef" gets modeled, and (2) how is the composite reference
"TargetComponentRef" is wired by the wiring infrastructure.
(1) Model and runtime objects for a targetless composite reference. A
targetless composite reference does not have a binding and it is not
specified by a component and given a target. So, at the model level the
object that represents this kind of composite reference is not a
BoundReferenceDefinition nor a ReferenceTarget, but it can be a plain
ReferenceDefinition instance that is considered separately by
CompositeBuilder to get its runtime representation built. In fact,
ReferenceLoader seems to deal with this case already, returning a
ReferenceDefinition instance when there is no binding, so it's just a matter
of setting up the CompositeBuilder and registering a builder for the
ReferenceDefinition with the builder registry. At the runtime level we seem
to have agreed on the definition of a CompositeReference class that extends
ReferenceExtension. The other piece that is needed is a builder that creates
a CompositeReference, that is registered with the builder registry and that
takes a ReferenceDefinition. This can't be a BindingBuilder, so it seems a
new class is needed, perhaps ReferenceBuilder or CompositeReferenceBuilder.
(2) Wiring a targetless composite reference. In the example above,
TargetComponentRef does not specify an explicit target or a binding, its
target is intended to be resolved by a component that is implemented by the
composite that contains TargetComponentRef, SourceComponent in this case.
When SourceComponent is being built by CompositeBuilder, a runtime
representation is created for it, e.g., a CompositeComponentImpl. When an
outbound wire is being added to the created CompositeComponentImpl by
WireService, via the BuilderRegistry, the CompositeComponentImpl should pass
on this wire to the runtime representation of TargetComponentRef, i.e.,
CompositeReference. This way, a CompositeComponent "shares" the outbound
wire of its target with the corresponding CompositeReference. This way, the
behavior of ConnectorImpl can be to just connect the outbound wire in
SourceComponent's CompositeComponentImpl and not to recurse down into
TargetComponentRef as it is sharing the same wire that was already
connected.
One question that arises is: should passing on wires happen recursively
down? For instance, since the reference in InnerSourceComponent is to a
composite reference, should the outbound wire given to the
CompositeComponent that represents InnerSourceComponent come from the
composite reference, i.e., TargetComponentRef?
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org