Comments inline.
Simon
ant elder wrote:
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
By "run" I presume you mean a service starts listening. What about
running client code that makes service invocations? This is the
moral equivalent of the "main" method in a java executable class.
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
As stated elsewhere I don't think it should contain all the samples.
Placing the samples there to run them should be an explicit act on
the part of the user.
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'm not sure why multiple runtimes would need to share the same
contribution folder. Is this to avoid needing to copy a file just
to deploy it on an additional runtime? Does it make sense to have
the same contribution deployed on two different runtimes? They
could not be in the same domain or there would be naming conflicts,
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
