On Thu, May 15, 2008 at 6:16 PM, Simon Laws <[EMAIL PROTECTED]> wrote:
> On Thu, May 15, 2008 at 2:28 AM, Jean-Sebastien Delfino < > [EMAIL PROTECTED]> wrote: > > > ant elder wrote: > > > >> On Tue, May 13, 2008 at 7:50 AM, Jean-Sebastien Delfino < > >> [EMAIL PROTECTED]> wrote: > >> > >> > >>> - create a domain manager (did u mean create an domain? deploy a > >>>>> domain > >>>>> manager as a web app? start an instance of a domain manager?) > >>>>> > >>>>> > >>>>> You tell me, I'm trying to understand how to use all this > distributed > >>>> domain > >>>> stuff you've written to support the scenario described above. > >>>> > >>>> Well, I'm not sure what to tell you unless I understand what you > meant > >>> by > >>> 'create a domain manager' before Tomcat starts deploying webapps and > what > >>> the purpose would be. > >>> > >>> > >> This is like pulling teeth. > >> > >> Over in the email where you describe how to use a webapp with the > >> standalone > >> domain one of the first steps is "Start the domain manager app", so > given > >> whats been described previously in this thread we will need to do > >> something > >> similar within Tomcat right? > >> > >> ...ant > >> > >> > > Not necessarily, I was starting the domain manager app in that scenario > > mainly for people to see how to contribute to the SCA domain and also use > > the manager app capability to start nodes. > > > > Tuscany standalone nodes can also be started from the command line (use > > tuscany-node2-launcher directly from the command line instead of clicking > > Start in the domain manager app UI). You don't need to use the domain > > manager app then. > > > > I also said in that email that nodes could be started in different > orders. > > That applies to the domain manager app too but obviously you need to > start > > it if you want to use its UI to inspect and manage your nodes. > > > > I'm still trying to understand your user scenario so it's really > difficult > > to say if I'm missing the point here or not, but here are a few more > > thoughts: > > > > - If your nodes are Webapps on Tomcat then you can just deploy them and > > start them using the Tomcat manager, or some of the Tomcat admin tasks > for > > example. > > > > - You don't need to start the SCA domain manager before deploying your > > Webapp to Tomcat. > > > > - When you start the Webapp, it'll need SCA metadata, the SCA composite > to > > use and a list of SCA contributions. There are many ways to provide that > > information: > > > > - You can provide that information using the APIs/SPIs like shown in the > > domain-management sample. > > > > - You can use similar code to build that information, save it to an XML > > file (an ATOM feed with one entry for the composite and one entry per > > contribution) and have your Webapp pick up that file. > > > > - You can also use the domain manager app to get that info. To do that > just > > click on the Node Config column for the Node you're interested in, save > that > > doc to a file, then have your Webapp pick it up as above (and the domain > > manager app does not have to be running at all at that time). > > > > - You can also have the Webapp pick up its config info from a running > > instance of the domain manager app. That's what I've been doing usually > at > > development time to have a quick debug/fix/try-again turn around, but I > > don't think that it's really what you'll want to do in production. > > > > I hope this helps, but again it would be really good if we could look at > > the user scenario that you have in mind together. It would help put the > > technical questions in context, as I'm still trying to guess what you're > > after but don't seem to be able to grasp it. > > -- > > Jean-Sebastien > > > > I'm going to have a go at articulating the scenarios I think are being > discussed on this thread. Hope these reads clearly in the first instance > but > let iterate around these until we agree what we are trying to achieve and > which ones are valid. You may of course want to add other scenarios;-) > > 1. User experience A > > 1.1 The user builds contributionA/compositeA and obtains > contributionB/compositeB from a friend. > 1.2 The user intends to run composite A and compositeB on separate nodes > [a] > > 1.3 The user configures the composites to run on the chosen nodes using a > domain tool [b] > 1.4 The user starts the nodes that he intends to use and configures each > with the composite he already knows he is going to run there and the > contributions this composite depends on [c] > > 2. User experience B > > 2.1 The user builds contributionA/compositeA and obtains > contributionB/compositeB from a friend. [d] > 2.2 The user intends to run composite A and compositeB as webaps in a > single > web container [e] > 2.3 The user copies the war files to the web app container. [f] > > Notes. > > [a] because isolation is require or different composited require different > resources provided by different nodes or for performance reasons etc. > [b] I'm not being precise here about the nature of this tool but it could > be > our domain manager tool which analyzes all the contributions and produces > configured composites based on the information it finds. > [c] the nodes are given the URLs of the contributions to load, The user may > just have put them on a file system so file://.... will work. The > configured > composite is also provided to replace the original one that appears in the > contribution. > > [d] Both contributions are packaged as war files in this case > [e] This isn't a restriction but in this case the user just wants to test > in > a single container. > [f] The domain processing required to resolve the composites in the context > of the domain happens behind the scenes and no SCA specific deployment > steps > are required after each original contribution has been packaged as a war by > the user or his friend. > > Do these capture the essence of what is being discussion? > > Simon > "2. User experience B" is the type of thing I've been talking about here and is something I think would be useful to support. ...ant
