> 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
Drop contribution jars into a directory which are then picked up
automatically and all contained composites are run
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
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
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
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. 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
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
