On Jan 10, 2008 3:08 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > a) runtimes of various kinds (SCA standalone, embedded within Tomcat, > etc) > > > > > > We know need to be able to run tuscany applications in different > environments but I want to understand what "runtime" means, how they are > built, how they are shipped and how they are used given the scenarios we > want to support. Thank you ant for putting in the effort to do this. It's > really helping to clarify. Trying to organize my thoughts below based on > this thread. > > b) applications, containing only the code and other artifacts required for > > the application itself > > > +2 > > To see what this looks like I've started creating some of this in the > > sca/modules/runtime-* projects and associated projects in > > sca/distributions. > > > Based on what you have said/checked in, are these the scenarios you have > in > mind? > > Standalone > Start Tuscany from the command line
Or a testcase or any Java class > > Drop contribution jars into a directory which are then picked up > automatically and all contained composites are run > Yes, and also a folder if you don't have a jar yet, so you can point it at target/classes in a testcase to pick up the application contribution being built. > > War > Start tomcat > Add the tuscany war to tomcat webapps dir > Drop contribution jars into a directory (in the expanded war?) > which > are then picked up automatically and all contained composites are run > That folder is within the WAR by default and would contain the sample contribution jars, but by updating the web.xml you can move the folder somewhere else outside of the WAR > Webapp > Construct a webapp > Add dependencies (using maven?) for tuscany jars > Configure web.xml to include the Tuscany filters > Build the war > Start tomcat > Add the war to tomcat webapps at which point the war directory is > loaded as a contribution and and composites that are found are started > yes > > Tomcat > Tuscany installed in tomcat > Start tomcat > As wars are loaded there are analysed to see if they are > contributions and and composites found are started > yes, and possibly (it does today) support a contribution folder for non webapp contributions as well. And ideally we'd eventually also support something like implementation.web thats been mentioned in the past > > I want to work into this the domain angle as when we talk about how a user > might run tuscany we need to understand that. The current code has a start for this though i think its broken right now, but you could define the url of the domain to have the runtime node join that domain. > Here I talk about runtime as > the thing that gets nodes up and going in different environments in order > to > run sca applications (composites). There is a set of stages that a person > wanting to run SCA applications may be aware of. > > A. build sca application jars > result: one or more contribution jar(s) > B. decide which domain(node) they are going to run them on > result: just the knowledge that relates a set of contributions, and the > composites they contain, with how/where they will be run > in the simplest case the result is "I want to run this SCA > application on this standalone runtime" > may result in configuration which describes which composites > will run on which nodes. > C. start runtime (and hence node) - i.e.bring up of tomcat, war, > standalone > result: running nodes ready for contributions > D. add contribution > result: a set of contributions is made available from which composites > can > be deplyed > E. deploy composite > result: composites are assigned to the node that will run them > F. start composite > result: the composite is run and its services are available > G. stop composite > result: the composite is stopped and it's services are no longer > available. For example, if some maintenance is required on that part of > the > application > H. remove composite > result: the node becomes available for other things > I. stop runtime - for example, Ctrl-C the runtime > > Am I correct in saying that in the runtime you have described the stages > come as > > A > B > C > D, E, F come together when a contribution is dropped into a runtime > G, H , I come together when a runtime is stopped > Yes, although theres still some of that hotupdate code in the war distro from a while back so droping a jar into the contribution folder could get it added to a running runtime by doing GHI and DEF. Though thats where it brings up all the issues around how many nodes etc which haven't really be resolved yet. We may need separate contribution folders per runtime or a way to configure which contributions within a contribution folder are for which runtime. I have more to say on the more complex scenarios and how these stages might > be implemented differently is different situations but I want to check I'm > understanding what you are saying so far. > > Simon >
