Hi Bob

I made a small test case to give us something a little more concrete to talk
to (http://svn.apache.org/repos/asf/tuscany/sandbox/slaws/scheduler/). There
are a couple of different scheduler components in there at the moment....

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
           targetNamespace="http://sample";
           xmlns:sample="http://sample";
           name="Scheduler">

    <component name="Scheduler">
        <implementation.java class="scheduler.SchedulerImpl"/>
        <service name="Scheduler">
            <binding.ws uri="http://localhost:8080/Scheduler"/>
        </service>
    </component>

    <component name="Scheduler2">
        <implementation.java class="scheduler.SchedulerImpl"/>
        <service name="Scheduler">
            <binding.ws uri="http://localhost:8080/Scheduler2"/>
        </service>
        <reference name="workers" multiplicity="0..n">
            <binding.ws uri="http://localhost:8081/WorkerA"/>
            <binding.ws uri="http://localhost:8082/WorkerB"/>
        </reference>
    </component>

</composite>

I've used SCA to model a Scheduler/Worker scenario here so I can experiment
with the pattern, different bindings etc. I.e. I'm doing Scheduler/Worker
coodination at the application level rather than relying on any particular
feature of the infrastructure. Hence I'm not necessarily proposing this as a
final solution. In particular this is not using the power of domain level
wiring and assumes that the worker interfaces are all the same . Anyhow it
gives me something to play with.

In the first scheduler component Scheduler starts up and waits for workers
to register with it. This happens as I've configured the worker components
to know where the scheduler is, as follows;

    <component name="WorkerA">
        <implementation.java class="worker.WorkerImpl" />
        <property name="name">WorkerA</property>
        <service name="Worker">
            <binding.ws uri="http://localhost:8081/WorkerA"/>
        </service>
        <reference name="scheduler">
            <binding.ws uri="http://localhost:8080/Scheduler"/>
        </reference>
    </component>

In the second scheduler component Scheduler2 starts up and uses the
reference binding configuration to find the worker components. You will note
that the same workers are used in both cases and that the same scheduler
implementation is used in bother cases so you could mix and match having
some nodes register and some be defined statically either through reference
bindings or, if I added it, by using the domain manage (or in your case by
loading configuration from a database).

It looks like having multiple bindings configured in this way is working for
me. I'm trying this on the latest 1.x code. It looks like in your case the
reference name doesn't refer to the name of the reference as it appears in
the component implementation. For example, in my case the SchedulerImpl
class defines the following reference.

    @Reference
    protected List<Worker> workers;

Hence this matches the reference as defined in the composite file

<reference name="workers" multiplicity="0..n">

In this example you'll notice that workers register a name, which I don't
actually use at the moment. If I wanted to get a name from workers that are
configured statically I'd have to add a getName() method to the worker
interface.

I haven't had a chance to look at your question about creating
<interface.java> but note that I'm not using it in this case. With Java
implementations the runtime can introspect this information from the
implementation class.

In the past I (an others in the commnity like Giorgio) have looked at
failover and loadbalancing a little bit. There is a loadbalancing demo that
deploys nodes to a cluster of tomcat servers and exploits Apache's ability
to load balance across Tomcat servers. We could also change bindings to, for
example, JMS which generally allows components to listen on queues and we
could exploit that for some natural load balancing (haven't tired that in
Tuscany yet but I could adapt this sample.

I'm interested in looking at what parts of the infrastructure need improving
to better support these kinds of scenarios. So all feeback/help is
gratefully received.

Regards

Simon


On Tue, Nov 18, 2008 at 4:05 PM, Maloney, Robert A
<[EMAIL PROTECTED]>wrote:

>  Hi Simon,
>
>
>
> > Just a normal XML composite file but with the uri of the reference
>
> > and service binding set appropriately depending on where the service
>
> > is deployed. Do you need a particular binding in you're environment?
>
>
>
> I want to use web service bindings throughout.  I am trying the following
>
> composite:
>
>
>
>   <component name="SchedulerComponent">
>
>     <implementation.java class="hub.WorkerServiceComponent"/>
>
>     <reference name="WorkerService" multiplicity="1..n">
>
>       <interface.java interface="hub.WorkerService"/>
>
>       <binding.ws name="WorkerService_1" uri="
> http://localhost:8090/WorkerService_1"/>
>
>       <binding.ws name="WorkerService_2" uri="
> http://localhost:8095/WorkerService_2"/>
>
>     </reference>
>
>   </component>
>
>
>
> but I am getting the following errors when creating the node from the
> composite:
>
>
>
>   Nov 18, 2008 10:26:58 AM
> org.apache.tuscany.sca.assembly.builder.impl.ComponentConfigurationBuilderImpl
>
>   SEVERE: Reference not found for component reference: Component =
> SchedulerComponent Reference = WorkerService
>
>   Nov 18, 2008 10:26:58 AM
> org.apache.tuscany.sca.assembly.builder.impl.CompositeBindingURIBuilderImpl
>
>   SEVERE: Reference not found for component reference: Component =
> SchedulerComponent Reference = WorkerService
>
>   Nov 18, 2008 10:26:58 AM
> org.apache.tuscany.sca.assembly.builder.impl.ComponentReferenceWireBuilderImpl
>
>   WARNING: No targets for reference: Composite = {http://hub}client
> Reference = dReferenceArray
>
>
>
> Can you see what's wrong?
>
>
>
> I assume the last warning regarding the member variable in the
> WorkerServiceComponent
>
> is due to the prior 2 errors.
>
>
>
> Also, so far I can generate the composite files based on the code in the
>
> domain-management sample using the modelFactories and
> ExtensibleStAXArtifactProcessor.
>
> However, I am having difficulty generating the <interface.java> and
> attaching
>
> it to the reference.  Do you have sample code for that?
>
>
>
> > How you you normally differentiate between services. By name?
>
>
>
> Yes.  So even though I am launching the services and know their name,
>
> I have to query the service to correlate the name with the items
>
> in the dReferenceArray WorkerServiceComponent member variable,
>
> and build a separate hash map with them, correct?
>
>
>
> > However we could look at adding a service interface to the Scheduler
>
> > that allows new nodes to register references to themselves and extend
>
> > the reference array in that way.Would take a bit of experimentation.
>
>
>
> And also the ability to unregister old nodes.  The ability to manage
>
> failover of worker nodes is desirable.
>
>
>
> Thanks,
>
>
>
> Bob
>

Reply via email to