The SCA specs don't have so much detail about this but as i understand it the intention is that an SCA domain could be quite dynamic with nodes and services coming and going at runtime. There's certainly nothing that i can see in the specs that say that should not be the case anyway. We don't have much of this in Tuscany yet but I hope thats just a point in time thing which we will improve on. Having users like yourself keep asking for it and saying its important to you will help make it happen quicker, and if you'd like to help with design or code even better :)
...ant On Wed, Aug 6, 2008 at 7:00 PM, Rich Smith (rjsmith2) <[EMAIL PROTECTED]>wrote: > Simon, just curious if there is any talk in SCA of having anything > similar to OSGi's > concept of service references and service trackers to permit a more dynamic > system > where services can be added to and removed from the system at runtime > without > having to restart components. > > Or, is it considered to be enough for now to have the system statically > configured at > startup time? > > What's the thinking on this? > > --Rich > > > ------------------------------ > *From:* Simon Laws [mailto:[EMAIL PROTECTED] > *Sent:* Monday, August 04, 2008 2:35 PM > > *To:* [email protected] > *Subject:* Re: Question on dynamic configuration of distributed > application > > > > 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:* [email protected] >> *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:* [email protected] >> *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 >
