On 11/8/07, Giorgio Zoppi <[EMAIL PROTECTED]> wrote:
>
> Hi,
> i'm going to create a CompositeHandler with the following interface:
> public interface CompositeHandler {
> /* FIXME: This can be added to a a Composite Definition */
> void addComponent(MetaComponent componentDefinition, Composite
> composite);
> void removeComponent(MetaComponent componentDefinition, Composite
> composite);
> }
>
> Where metacomponent is a Interface:
>
>
> I ask you if i can add a composite handler to a composite interface or
> violates some assembly specs.
> So the interface it will be..
> public interface CompositeHandler {
> /* FIXME: This can be added to a a Composite Definition */
> void addComponent(MetaComponent componentDefinition);
> void removeComponent(MetaComponent componentDefinition);
> }
>
> and in the composite definition i have
>
> CompositeHandler getCompositeHandler():
>
> The use case is the following, suppose that you have a composite and
> you want add a component, which it has its class in the current
> composite contribution.
>
> Suppose that you have an workpool.MyWorker class and you want to
> replicate in a new component.
> In this way you can define:
>
> public class MetaWorkerComponent implements MetaComponent {
>
> private String CMP_DEFINITION = "<component name=\"$NAME\">\n" +
> "<implementation.java class=\"$CLASS\"/>"+
> "<property name=\"workerName\">$WNAME</property>"+
> "<service name=\"WorkerService\">"+
> "<binding.sca uri=\"$HOSTNAME/$NAME\"/>"+
> "</service></component>";
> private String componentName;
> private String workerName;
> private String className;
>
> public void setComponentName(String name) {
> CMP_DEFINITION = CMP_DEFINITION.replaceAll("$NAME", name);
> }
> public void setWorkerName(String name)
> {
> CMP_DEFINITION = CMP_DEFINITION.replaceFirst("$WNAME", name);
> }
> public void setWorkerClass(String javaClass)
> {
> CMP_DEFINITION = CMP_DEFINITION.replaceFirst("$CLASS",
> javaClass);
> }
> public void setWorkerHost(URI uri)
> {
> CMP_DEFINITION = CMP_DEFINITION.replaceFirst("$HOSTNAME",
> uri.toString());
> }
> public XMLStreamReader build() throws Exception {
> XMLInputFactory factory = XMLInputFactory.newInstance();
> return factory.createXMLStreamReader(new
> StringReader(CMP_DEFINITION));
> }
> public String getComponentName() {
> return this.getName();
> }
> }
> Or something similar, get from the node your preferred composite, and
> add this component definition as in the following example:
>
> Composite composite = node.getComposite("Workpool");
> CompositeHandler handler = composite.getHandler();
> MetaWorkerComponent component = new MetaWorkerComponent();
> component.setName(...)...
> snip..various things..
> handler.addComponent(component);
>
> This addComponent, parse the definition, wire, and add it to the
> component. What do you think about?
>
> Cheers,
> Giorgio.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
Hi Giorgio
So this is about adding components to a composite dynamically. Can we do
what you need to do by either,
Allowing contributions to be updated (so that you can add a new component to
the composite through the normal contribution process)
OR
Adding a new contribution for each new component. The contribution could
still contain generated XML if required and it could depend on the first
contribution if this is where the component implementation is
This way we don't have to provide new Tuscany specific interfaces for
composite management.
Once you have added the component what do you want to happen to it. For
example, will it be wired to the manager that is controlling the workpool.
If so how will this wiring be introduced? Here is some psuedo code for how
the workpool manager might work without sca wiring (this does depend on the
trunk code with the latest domain implementation).
run() {
under normal operation pass work out to worker components
if (run out of components and max components not reached) {
create a new composite giving the new worker a name
add the composite to a new contribution
domain = SCADomainFinder.newInstance().getSCADomain(domainName);
domain.addContribution(the new contribution)
domain.startComposite(the name of the new composite)
reference to new component = domain.getService(WorkerService.class,
"the name of the new component")
use the new reference to allocate work to the component
store the reference for future use
}
}
If the manager were a component in its own right I think it could be done by
making the reference to workers have a multiplicity greater than 1 and by
adding a new wire when you add the new component. This would rely on doing
some work to make contribution updates work. Don't know how hard that would
be.
Am thinking aloud here so let me know if this is useful.
It would be good to understand a little more about the requirement as we
have some similarly devious code in the current domain implementation and,
now that callable reference support is better, I think we can replace it
with code that only depends on the Tuscany API as opposed to the innards of
the runtime. I haven't done this yet but maybe this is the motivation I need
to sort it out:-)
Regards
Simon
