Hi Skip Some comments in line...
Regards Simon On 9/20/07, Skip Schuler <[EMAIL PROTECTED]> wrote: > > Hi, > > I'm testing with tuscany-sca-0.99-incubating, and I'm happy to see the > calculator-distributed example. I'd like to know more about what > capabilities Tuscany offers in terms of supporting a distributed > architecture. I have a few use cases for my architecture; We have tried to stay fairly true to the concept of a distributed domain as we see it discussed in the spec. The basic idea is that you have parts of a domain (nodes) running in separate JVMs (on separate machines if you like). You contribute SCA composites to these nodes and components can reference one another within the scope of the domain using the usual ComponentName/ReferenceName approach regardless of where the component it actually running. Of course under the covers we have a simple registry that maps ComponentName/ReferenceName to a physical endpoint and hence the SCA binding can send the message to the right place. The implementation at the moment is very simple. We just use web protocols (HTTP/SOAP) to pass the messages and to allow nods to register with domains. - load balancing and scaling; can one e.g. configure a service to be > load-balanced between different nodes? In particular it would be great to > be > able (dynamically) to add/remove a node for scaling up and down (to an > optional max/min number of nodes). There isn't any one particular mechanism that we mandate. I could think of several, for example. - Run you nodes in an app server cluster and let it worry about balancing out requests across nodes. - Use some other (grid) clustering technology to host the nodes and spray requests out. - Use a protocol (and suitable bindings) in your SCA application to provide the load balancing, e.g. a message queue, so that you can start new node and have the new nodes provide services on the end of the queue. We need a new binding for this. - fail-over; if a node for some reasons fail, could another node pick up the > service(s) it served? Again we would rely on suitable infrastructure that is designed to do this. Changes would be required in Tuscany to make this work properly, For example, some of the scope containers that manage state, as happens with conversational services, would have to prepared to persist their state to take account of failover (perhaps into the session in the web app case). Having said this with the simple set up we have now the intention is that you will be able to stop nodes and bring them up elsewhere with stopping to whole lot. Note a failover solution that answers the state question but affords some flexibility. Doesn't quite work at the moment as there are some issues with retrying messages. - service provisioning; deploying and starting services on different nodes. At the moment this should work with any tool that can fire up a java application somewhere on the network and provide data to it, e.g. via a shared file system or via ftp. In trunk we do have a web app implementation that allows you to upload contribution jars through a web interface. So if we wanted to do more development in that direction there are some options. Any feedback is appreciated, i.e. what support is there (docs?), what's > planned, or if this is out of scope for Tuscany. Am writing some docs to go with the V1.0 release for what we have at the moment. The scenarios you bring up are very interesting and I think we need to have a good story about how people will address them with Tuscany. Personally I think such support would be really helpful. Any help you can give us working up good answers to the questions from comments on list to developing scenarios and code is much appreciated. What we need is input on what should be supported and would be useful. Thanks! >
