On Mon, Feb 2, 2009 at 11:00 PM, Giorgio Zoppi <[email protected]> wrote:
> 2009/2/2 Raymond Feng <[email protected]>: > > 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
