On 9/21/07, Skip Schuler <[EMAIL PROTECTED]> wrote: > > Thanks Simon for the update on current state and support in this area! Let > me try to contribute a bit on what I see would be useful, and what I'd > like > to see support for (and what would really help me sell Tuscany to my > customer and project manager). > > I really like the Web 2.0 approach that Tuscany has taken with support for > " > 2.0" bindings such as atom/rss feeds, json-rpc and more. However, I think > there is much more in this Web 2.0 direction that Tuscany can be inspired > from. As Web 2.0 and SOA are converging (some call it the "global SOA"), > many new (and existing) projects have to take this into consideration. And > as companies and solutions are starting to open up their SOA and content > to > the web (partners, the SaaS delivery model, etc), a number of new > challenges > become more important, e.g. scalability and reliability of your SOA > infrastructure. > > I'm not sure how much the SCA spec addresses here.. Maybe some > restrictions > (stateless vs stateful services) could be allowed at first? Also there > could > be other bindings/protocols that are more suited within a network of > services than HTTP/SOAP. > > Anyway, that's my 2 cents (for now ;-). If Tuscany could have (proven) > support for some of these distributed services challenges (e.g. > load-balancing, fail-over, service provisioning as listed below), that's > be > a direction I'd love to see! > > > Thanks, > Skip > > > On 9/20/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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! > > > > > > Hi Skip, good comments, thank you...
Very interesting thoughts about Web2.0 Tuscany SCA has some support for the kinds of protocols and development styles used with Web2.0 today, for example, JSONRPC, DWR, scripting and there is a web resource implementation type. Doing this in larger scale environments though requires the extra angle of infrastructure capability that you're talking about. The SCA specs haven't addressed these issues to date but I don't think a huge amount of invention is required here. I think Tuscany can learn a lot from existing web technologies in terms of how to do reliability and scalability. This is an advantage of having good support for web technologies HTTP, SOAP etc in Tuscany but you're right it would be interesting to see how other Tuscany supported bindings, like JSONRPC, RMI could fit in. Based on your Web2.0 comments a useful exercise could be to take a simple Web2.0 application supported by a set of distributed Tuscany services and investigate how this can be deployed in some existing container (s) that have some of the resilience capabilities you're after. This would bring out required code changes and enhancements and also potentially provide a deployment template that others could use. Tuscany currently has a level of integration with a number of web containters (Tomcat, Jetty, Geronimo) and a quick Google says that Tomcat and Geronimo have clustering solutions so that could be something to start with. Do you have a particular Web2.0 scenario in mind that could be used? Regards Simon
