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
