It's always a good idea to try things out. I'd like to help and in particular I'm interested in what is specific to Tomcat and what constitutes more general interfaces/patterns for managing contributions/composites/nodes. I'm looking for the APIs and the crossover to the more general distributed domain. To aid that I'd like (us) to bring in the domain manager code in parallel. If nothing else we can steal bits of code from it.
Comments in line On Fri, May 29, 2009 at 11:43 AM, ant elder <[email protected]> wrote: > On Thu, May 28, 2009 at 11:39 AM, Simon Laws <[email protected]> > wrote: > >> I'd like to expand a little on what actual scenarios are being >> discussed here. > > This discussion may well go on and on without achieving much as > happened in some previous discussions without specific objectives so > as a concrete scenario as what i'd like to get working is the SCA > domain used by the new Tuscany Tomcat integration which would work as > follows: > > - The tomcat instance would be a domain. It could also be useful for a > Tomcat instance to contain multiple domains or be part of a wider > domain but i'd like to leave those complications to later. Sounds ok. > > - SCA contributions (webapps and jars/zips etc) can be added during > runtime so the domain needs to support adding and starting > dynamically. Stopping, updating, and removing would be good too but > that can be left till later Right, this is the point about understanding what we mean by dynamic. There is the perfectly reasonable scenario of incremental deployment that is enabled by supporting late binding through a registry without going all the way to dynamic updates. > > - The domain is running within a single JVM so it doesn't need any > remote distribution technology which helps keep things simple I'd like to look at this but it can be done outside of this tomcat exercise. > > - It would be great to also get the SCAClient API able to talk to the > Tomcat domain from a JSE client. I guess thats a slightly different > topic but it might be useful to keep it in mind I think this is enable by whatever APIs we make available from the domain so you're right to include it. > > This seems simple and familiar enough that we'll all be able to > understand it and we have most of that in place now other than being > able to wire across the Tuscany Nodes so it should be easy enough to > implement and test as we work out and agree on what to do for the > domain. I don't think it matters if it uses the "node or domain > centric" approaches that have been mentioned, I don't think it matters either. But what matters is that we are aware that there are two approaches and be clear which ones we are using in each situation as they imply slightly different capabilities and will help us develop the domain APIs or uses the existing > Node classes or some new Domian APIs and interfaces, we just need to > get something working so we can show some progress. Getting something working to show the scenario is great and we can all prod it and learn.
