On Mon, Aug 4, 2008 at 5:14 PM, Rich Smith (rjsmith2) <[EMAIL PROTECTED]>wrote:
> Thanks, Raymond. I'll investigate your suggestions, and post back with > any more > questions. > > --Rich > > > ------------------------------ > *From:* Raymond Feng [mailto:[EMAIL PROTECTED] > *Sent:* Monday, August 04, 2008 8:55 AM > *To:* user@tuscany.apache.org > *Subject:* Re: Question on dynamic configuration of distributed > application > > Hi, > > Thank you for your interest in Tuscany. I have two quick comments inline. > > Raymond > > *From:* Rich Smith (rjsmith2) <[EMAIL PROTECTED]> > *Sent:* Monday, August 04, 2008 7:57 AM > *To:* user@tuscany.apache.org > *Subject:* Question on dynamic configuration of distributed application > > Resending this question now that I am able to get on the mailing list. > Apologies to > anyone who gets it twice. > > Hi, all. I'm working on evaluation of Tuscany Java, and need some advice > on a > particular configuration/use-case that we are planning for our application. > > The application will be scalable from a low-end deployment where it runs on > a > single server to a high-end, distributed deployment, running on several > servers. > SCA and Tuscany seem like a good fit for this. > > In the high-end case, there will be several instances of "back-end > servers", each > of which will run different instances of the same components. The > front-end will > keep a mapping of which back-end server to use for which resources, and so > this > is _not_ going to require any kind of load balancing. > > So far, I've figured out that I can register the back-end server components > using > separate service names, and just get those service references using the > appropriate > names. > > <rfeng>In a SCA domain, the components in top-level composites should > have unique names. But we can configure more than one components to use the > same implementation. Would it help for your use case?</rfeng> > > However, I want to configure the back-ends using our application and not > using > static files (as in the calculator-distributed sample) because it will be > necessary > to allow customers to add back-end servers as they need to > increase capacity. > > The thought of having to regenerate all of the .composite files does not > appeal to > me, and I don't really want to generate five copies of the same file with > different > service names. > > What is the best approach for this? Is there something I can do using SPI > to > dynamically configure a distributed Tuscany Java application? (It's > probably okay > if restart is required somewhere, but it would be even better if not.) > > <rfeng>SCA does have the deployment composite concept. It allows we use a > dynamically configured composite (instead of being packaged in a SCA > contribution) to deploy the application. In Tuscany, we have the following > API: > > org.apache.tuscany.sca.node.SCANode2Factory.createSCANode(String, String, > SCAContribution...) > > The 2nd argument is a String representing the XML for the deployment > composite. > > We also have a SCA Domain Manager in Tuscany which provides the > administration capability. It's built as a SCA composite application with > Web 2.0 front end. The function can be used programmatically to introspect > contributions/composites, resolve wirings and configure nodes for > deployment. You might be able to explore it for your purpose. > > Please try the store tuturial to get a better understanding: > https://svn.apache.org/repos/asf/tuscany/java/sca/tutorials/store/domain > > </rfeng> > > Please let me know. > > --Rich > > Hi Rich Both the calculator-distributed sample and the store tutorial, that Raymond mentions, use the same underlying model of an SCA Domain. Here's how it works. - You build your application as a set of composites where each composite may run on a separate node - References in one composite may target services in another by explicit name - The workspace.xml, domain.composite and cloud.composite file you have looked at model these composites and their association with physical nodes - A domain manager app uses this information to work out what the the real URLs for services and the references that target them will be - When you run up a node with the composite that is intended to run on that node it is configured with the correct endpoints. Composites running on other nodes are able to find it as they are also configured (written on demand) by the domain manager. As you have seen from the calculator-distributed sample this is fairly static. There is a domain manage GUI app that allows you to add composites to your domain which does actually write the worskpace.xml, domain.composite and cloud.composite files for you (start the calculator-distributed sample, ant runDomain, and point your browser at http://l3aw203:9990/ui/home/). You add and remove composites to configure your domain and when you are happy with it you can start nodes out there on the network where you expect them to be and the node will use some configuration to find the domain manager and suck down the information relating to the composite it is supposed to be runnning. Once you've started a node it is currently stand alone. It won't pick up any subsequent changes you make to the domain. To pick up changes you have to restart the node. So how to do what you need to do? The wrinkle you face is that in SCA component names have to be unique (actually they only need to be unique within the context of a composite but for the purpose of this description it's the same thing). If you have 5 different components that you want to wire to then you need to define 5 different components with 5 different names. They can of course all have the sample implementation. There is no sense in the SCA assembly model that you wire to instances of compnents. So your 5 components running on 5 different nodes are not different instances of the same component but separate components. In your case you are suggesting that the front end can select a service based on some knowledge of the resource that the service is running on. This actually sounds like it would fit the model of explicitly named service components well as you need to differentiate a component running on one node from a component running on a different node with different resource properties. To add a new component though would, as you say, require that you create a new composite for the service component. We could get round the need to manually update the front end composite by setting it to autowire to available component services with the right sort of interface. You would still need to restart the front end node though. How does your front end app differentiate between services? If we took the approach above the front end component would have to have a collection of references to services (a reference with a 1..N multiplicity) and hence no easy way to identify one reference from another. You could of course have a method on the service that returns information that allows you to identify the properties of the service and relate these properties to the reference's location in the reference collection. There are some other tricks you could think about, for example, take a look at demo/load-balancing -webapp. This takes a different approach and defines a very simple two component assembly client -> service. The same service composite is then deployed to several different nodes. The client thinks it's only wired to one service and always sends it's request to the same URL, the URL in the binding of that composite. However that URL happens to be the URL of the front end of the load balancer that spreads the load across the separate instances of the composite. Here you can start as many back end nodes as you like dynamically but the front end doesn't get any control over which one is called for any given request. That's probably enough for now but I'm interested to hear more about your application and how we make it run on Tuscany. Regards Simon
