Tuscany Composite and domain.

[Giorgio Zoppi <gi...@gmail.com>]

Hi to all,
I'm back finally and seeing your composite and node api. I wonder if
it's feasible to replace a composite in node, i.e. the following
steps:

+ stop a node composite
+ get the composite model, and change it
+ start a node with the new composite, different from the previous.

This is the first part. Any hints about?
(I did something a while ago, but it required to modify the assembly
package, thing that i don't want this time)
-- 
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".

Re: Tuscany Composite and domain.

[Giorgio Zoppi <gi...@apache.org>]

> Hi Giorgio.
>
> It feels like the second option that you list is more achievable as we are
> already able to start a node with a configuration, stopping the node and
> providing a new configuration would seem like a good approach to better
> understanding the scenario.

I might do some tries and you'll have a more complete picture.  I need to gain
a better knowlegde of the current trunk.
> What sort of "change" events do we expect a node to respond to?
Some external entity might decide that it needs to duplicate an
existing component
following a given contract, or remove an existing component.
It could be able to reconfigure the node, here a complete picture:
1) An external actor detects that there's a contract violation (adding
a component or remove the component).
2) It tries to adjust this violation reconfiguring the node in a safe way.

> I ask as we
> are faced with that question as soon as we step outside the convenient
> position of assuming a completely static domain.
I know, but seeing the old code and current code it doesn't need a
heavy refactoring
for add some sort of dynamicity (i.e. component replication and
remotion), which is only what i need.
This will open to common several pattern. Suppose a map-reduce where
you'll add executors. I heard of Hessian support
and it'll open to a client C++ to submit work to map executors.
This is my basic scenario. I know that's feasible, but how about the costs?

> For example, at the moment
> we add all the contributions to the domain and then start nodes and that's
> it. You can't necessarily safely change the contributions in the domain
> without restarting all of the nodes to take account of the change.
>
> For example, Adding or removing a composite, or a component or a wire within
> a composite, will likely impact the wiring across the domain.
I know. The only grain that i need a component, for now.

Adding or
> removing policy definitions could also potentially affect many components
> across the domain. In these cases nodes whose configuration is affected
> would need to be restarted.

It should not be in this way. If none use a component how could be
affected other nodes?
(If someone it use, its removal will affect other nodes).

> It would be interesting if you could restate your scenario in terms of a
> before and after snapshot of the contributions involved.
Let me investigate a bit and i'll restate the problem.

Ciao,
Giorgio

-- 
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".

Re: Tuscany Composite and domain.

[Simon Laws <si...@googlemail.com>]

On Mon, Feb 2, 2009 at 11:00 PM, Giorgio Zoppi <gi...@apache.org> wrote:

> 2009/2/2 Raymond Feng <en...@gmail.com>:
> > Hi,
> >
> > The "start" of a node consists of two steps:
> >
> > 1. Bootstrap the Tuscany runtime and extensions: It discovers the
> extension
> > points and extensions and populate them.
> yes. Yes
> > 2. Load contributions and deployable composites. Resolve/Build the
> > composite. And then activate the components (implementation, service and
> > reference).
> yes..done by various builders, and composite configurators.
>
> > I envision there is a configuration for the node. The configuration will
> > contain the following information:
> >
> > a) A list of contributions
> > b) One or more composites (which can be included into a deployment
> > composite)
> > c) Base URIs for various bindings, such as "http://locahost:9080/" for
> > binding.ws
> > d) Other settings for the specific host platform
> Yes. This is the way, I see these stuffs.
>
> > Does your "restart" mean the steps below?
> > 1) Deactivate the composites and clean up the models
> > 2) Change the node configuration (Do you require in-memory change of the
> > models?)
>
> Yes. I require to be able to reconfigure node composite at run-time.
> Suppose that
> you had to optimize the way on which the components behaves at run-time for
> providing a better QoS on your non functional requirements(i.e change
> a policy at runtime,
> duplicate a component a run-time, ecc). You might follow on of the two
> ways in the current runtime:
>
> 1) modify the composite builder, composite activator and contribution
> builder, node impl
> in order to provide a way to modify at run-time a composite which is
> part of a contribution.
> This is the way that i followed one year ago, but i think that's
> costly. In this way you might
> add a new composite item (wire, component, policy) at runtime without
> no risk, and
> with risks if you want to remove (i.e. a pending call to a component) it.
>
> 2)  the steps that you indicate (1,2,3) for my point of view means:
>
> 1) stop / temp. deactivate the node composite (in order to avoid incoming
> calls)
> 2) replace in memory a composite with a newly generated composite,
> in which you had changed items, based on the stopped composite.
> 3) starting again the composite.
>
> In this way i might able to proof you (i.e.providing a demo ) that
> it's feasible to build a demo
> with SCA and some sort of autonomic features.
>
> Best Regards,
> Giorgio
> --
> Quiero ser el rayo de sol que cada día te despierta
> para hacerte respirar y vivir en me.
> "Favola -Moda".
>

Hi Giorgio.

It feels like the second option that you list is more achievable as we are
already able to start a node with a configuration, stopping the node and
providing a new configuration would seem like a good approach to better
understanding the scenario.

What sort of "change" events do we expect a node to respond to? I ask as we
are faced with that question as soon as we step outside the convenient
position of assuming a completely static domain. For example, at the moment
we add all the contributions to the domain and then start nodes and that's
it. You can't necessarily safely change the contributions in the domain
without restarting all of the nodes to take account of the change.

For example, Adding or removing a composite, or a component or a wire within
a composite, will likely impact the wiring across the domain. Adding or
removing policy definitions could also potentially affect many components
across the domain. In these cases nodes whose configuration is affected
would need to be restarted.

It would be interesting if you could restate your scenario in terms of a
before and after snapshot of the contributions involved.

Simon

Re: Tuscany Composite and domain.

[Giorgio Zoppi <gi...@apache.org>]

2009/2/2 Raymond Feng <en...@gmail.com>:
> Hi,
>
> The "start" of a node consists of two steps:
>
> 1. Bootstrap the Tuscany runtime and extensions: It discovers the extension
> points and extensions and populate them.
yes. Yes
> 2. Load contributions and deployable composites. Resolve/Build the
> composite. And then activate the components (implementation, service and
> reference).
yes..done by various builders, and composite configurators.

> I envision there is a configuration for the node. The configuration will
> contain the following information:
>
> a) A list of contributions
> b) One or more composites (which can be included into a deployment
> composite)
> c) Base URIs for various bindings, such as "http://locahost:9080/" for
> binding.ws
> d) Other settings for the specific host platform
Yes. This is the way, I see these stuffs.

> Does your "restart" mean the steps below?
> 1) Deactivate the composites and clean up the models
> 2) Change the node configuration (Do you require in-memory change of the
> models?)

Yes. I require to be able to reconfigure node composite at run-time.
Suppose that
you had to optimize the way on which the components behaves at run-time for
providing a better QoS on your non functional requirements(i.e change
a policy at runtime,
duplicate a component a run-time, ecc). You might follow on of the two
ways in the current runtime:

1) modify the composite builder, composite activator and contribution
builder, node impl
in order to provide a way to modify at run-time a composite which is
part of a contribution.
This is the way that i followed one year ago, but i think that's
costly. In this way you might
add a new composite item (wire, component, policy) at runtime without
no risk, and
with risks if you want to remove (i.e. a pending call to a component) it.

2)  the steps that you indicate (1,2,3) for my point of view means:

1) stop / temp. deactivate the node composite (in order to avoid incoming calls)
2) replace in memory a composite with a newly generated composite,
in which you had changed items, based on the stopped composite.
3) starting again the composite.

In this way i might able to proof you (i.e.providing a demo ) that
it's feasible to build a demo
with SCA and some sort of autonomic features.

Best Regards,
Giorgio
-- 
Quiero ser el rayo de sol que cada día te despierta
para hacerte respirar y vivir en me.
"Favola -Moda".

Re: Tuscany Composite and domain.

[Raymond Feng <en...@gmail.com>]

Hi,

The "start" of a node consists of two steps:

1. Bootstrap the Tuscany runtime and extensions: It discovers the extension 
points and extensions and populate them.
2. Load contributions and deployable composites. Resolve/Build the 
composite. And then activate the components (implementation, service and 
reference).

I envision there is a configuration for the node. The configuration will 
contain the following information:

a) A list of contributions
b) One or more composites (which can be included into a deployment 
composite)
c) Base URIs for various bindings, such as "http://locahost:9080/" for 
binding.ws
d) Other settings for the specific host platform

Does your "restart" mean the steps below?
1) Deactivate the composites and clean up the models
2) Change the node configuration (Do you require in-memory change of the 
models?)
3) Activate the composites again

Thanks,
Raymond
--------------------------------------------------
From: "Giorgio Zoppi" <gi...@gmail.com>
Sent: Monday, February 02, 2009 1:06 PM
To: <tu...@ws.apache.org>
Subject: Tuscany Composite and domain.

> Hi to all,
> I'm back finally and seeing your composite and node api. I wonder if
> it's feasible to replace a composite in node, i.e. the following
> steps:
>
> + stop a node composite
> + get the composite model, and change it
> + start a node with the new composite, different from the previous.
>
> This is the first part. Any hints about?
> (I did something a while ago, but it required to modify the assembly
> package, thing that i don't want this time)
> -- 
> Quiero ser el rayo de sol que cada día te despierta
> para hacerte respirar y vivir en me.
> "Favola -Moda".