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 >
