You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Valerio Schiavoni <va...@gmail.com> on 2007/04/06 12:52:09 UTC
composite reconfiguration
Hello everyone,
does Tuscany/SCA provide any support for dynamic reconfiguration of
deployed composites ? The question is not strictly related to specific
technologies, even tough I do recognize that shipping composites
within OSGi bundles could help in this perspective - well, it would
delegate to the osgi runtime the reconfiguration resposabilities i
guess -
thanks,
Valerio
--
http://jroller.com/page/vschiavoni
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: composite reconfiguration
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Hi Valerio,
Some comments and questions inline.
Valerio Schiavoni wrote:
> Hello Jean-Sebastian,
>
> On 4/6/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> - add/update/remove SCA contributions (packages containing composites
>> and component implementation artifacts) to/from the SCA domain
>> - add/update/remove deploymentComposites, declaring the top-level
>> components active in the SCA domain
>> These operations are described in the SCA assembly spec - chapter 1.10.4
>> - Operations on SCA contributions.
>> Doing this will update the configuration of components, including the
>> configuration of their properties, bindings, and references (by rewiring
>> them to other components).
>
>> Do you have any specific re-configuration use cases in mind that we
>> should support?
>
> In particular, I was thinking about binding re-configuration at first.
> Reading at the specs:
>
> "this functionality makes it possible for the deployer to create a
> composite with final configuration and wiring decisions and add it to
> an installed contribution without having to modify the contents of the
> root contribution."
>
> As you said, updating a contribution will update also declared bindings.
You'll need to restart the components contributed by that contribution
to get the updated bindings.
> How does it work when updating binding.java to a different one ?
The wires, binding selection etc. should be re-evaluated when the
impacted components get restarted. Did you mean binding.sca?
> Can you point me somewhere within the core module ?
>
There is really no special processing for handling updates of a
contribution. Updating a contribution is very similar to contributing it
the first time.
Here are a few pointers to code along the contribution and start path:
- in the contribution module,
o.a.t.contribution.service.ContributionService is used to add or update
a contribution
- in the assembly-xml module, o.a.t.assembly.xml.CompositeProcessor
reads a Composite and populates the assembly model in memory, describing
composites, components, services, bindings etc.
- in the core module, o.a.t.core.deployer.DeployerImpl walks the
assembly model and triggers runtime Builders which create runtime
context objects for components, services with bindings etc.
- these runtime context objects (for example
o.a.t.implementation.java.context.JavaComponent) implement
o.a.t.spi.Lifecycle (defined in module core-spi), and their start()
method is called
>> Would you be interested in helping with some of this work?
>
> I would be interested, but as I'm already working on the fractal
> contribution:
>
> https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal/
>
Cool. Do you already have a patch to contribute? If you want to submit a
JIRA issue with a patch, we can contribute it to the sandbox first, and
everybody can take a look at it and help you, let you know when we make
changes that will affect your code etc. and even better at some point
integrate your extension in the trunk...
> i guess it'd be difficult for me to productive. Also, I'm trying to
> figure out what's changed in 1.0 for extensions..
>
We have made a number of changes to extensions recently, in particular
to how SCA assembly XML (.composite files etc.) are loaded, and also to
the model interfaces representing SCA assemblies. Feel free to ask any
questions, we'll try to help as much as possible. There are sample
extensions under samples/implementation-crud, samples/echo-binding and
samples/echo-databinding. We're also looking for feedback on the SPIs
and suggestions for improvement.
Would you mind giving us a short summary of how you are extending
Tuscany and integrating with Fractal? A little more context on what
you're doing will probably help us help you better :)
Thanks
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: composite reconfiguration
Posted by Valerio Schiavoni <va...@gmail.com>.
Hello Jean-Sebastian,
On 4/6/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> - add/update/remove SCA contributions (packages containing composites
> and component implementation artifacts) to/from the SCA domain
> - add/update/remove deploymentComposites, declaring the top-level
> components active in the SCA domain
> These operations are described in the SCA assembly spec - chapter 1.10.4
> - Operations on SCA contributions.
> Doing this will update the configuration of components, including the
> configuration of their properties, bindings, and references (by rewiring
> them to other components).
> Do you have any specific re-configuration use cases in mind that we
> should support?
In particular, I was thinking about binding re-configuration at first.
Reading at the specs:
"this functionality makes it possible for the deployer to create a
composite with final configuration and wiring decisions and add it to
an installed contribution without having to modify the contents of the
root contribution."
As you said, updating a contribution will update also declared bindings.
How does it work when updating binding.java to a different one ?
Can you point me somewhere within the core module ?
>Would you be interested in helping with some of this work?
I would be interested, but as I'm already working on the fractal contribution:
https://svn.apache.org/repos/asf/incubator/tuscany/sandbox/fractal/
i guess it'd be difficult for me to productive. Also, I'm trying to
figure out what's changed in 1.0 for extensions..
--
http://jroller.com/page/vschiavoni
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: composite reconfiguration
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Valerio Schiavoni wrote:
> Hello everyone,
>
> does Tuscany/SCA provide any support for dynamic reconfiguration of
> deployed composites ? The question is not strictly related to specific
> technologies, even tough I do recognize that shipping composites
> within OSGi bundles could help in this perspective - well, it would
> delegate to the osgi runtime the reconfiguration resposabilities i
> guess -
>
> thanks,
> Valerio
>
Hi Valerio,
Yes. I'm not sure if it already works in the latest runtime as Luciano
is still working on the first cut of an implementation of the SCA
ContributionService and it's not fully integrated with the rest of the
runtime yet, but it should/will allow you to do the following:
- add/update/remove SCA contributions (packages containing composites
and component implementation artifacts) to/from the SCA domain
- add/update/remove deploymentComposites, declaring the top-level
components active in the SCA domain
These operations are described in the SCA assembly spec - chapter 1.10.4
- Operations on SCA contributions.
Doing this will update the configuration of components, including the
configuration of their properties, bindings, and references (by rewiring
them to other components).
I think it will be useful to expose the configuration of the SCA domain
and the ContributionService operations as JMX operations as well at some
point. We have the beginning of a JMX infrastructure in our jmx module.
We could start leveraging it when the ContributionService is in a good
enough shape.
I also agree with you that OSGI may help, providing good isolation
between bundles and help to manage their lifecycle (to reload/restart an
updated bundle for example). However I've not looked at our OSGI
integration for a few weeks and last time I checked it was not building.
It would be good to restart this OSGI work and see how we could plug SCA
contributions packaged as OSGI bundles into the SCA ContributionService.
Do you have any specific re-configuration use cases in mind that we
should support? Would you be interested in helping with some of this work?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org