You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@gmail.com> on 2005/12/15 21:13:40 UTC
Deploying Subsystems and ModuleComponents to Tomcat
I'd like to start a discussion on how we're going to deploy SCA
Subsystems and ModuleComponents to Tomcat.
First I think we should stage things so I propose that in a first step
we only support ModuleComponents and Wires and not try to support the
definition of ExternalServices and EntryPoints in a subsystem right
away. We already support the definition of ExternalServices and
EntryPoints inside SCA modules so this shouldn't limit us too much in
terms of scenarios and we'll still be able to define service networks
this way. When we get our Susbsytem/ModuleComponent story stable enough
then I think it'll be really easy to build the
Subsystem/ExternalService+EntryPoint support on top.
Now here's how I'd like to deploy a Subsystem and its ModuleComponents
to Tomcat:
A ModuleComponent is deployed as a Web app. A Subsystem is deployed as a
Tomcat instance. The Web apps for the ModuleComponents in a Subsystem
are simply deployed to the Tomcat instance representing the Subsystem.
The sca.subsystem file defining the Subsystem file is stored in the conf
directory for the Tomcat instance.
Writing an sca.subsystem file is not mandatory. If you're happy with
burning the configuration of your module in your sca.module file, don't
need to use ModuleComponent properties and don't need to change your
ExternalService bindings after the app has been deployed, then you just
deploy your ModuleComponent as a Web app as we already support today.
Several Tomcat instances can share the same Tomcat runtime,
http://tomcat.apache.org/tomcat-5.5-doc/RUNNING.txt describes how to do it.
To start/stop a subsystem, you start/stop the corresponding Tomcat
instance. To change a Subsystem configuration, you update the
sca.subsystem file, then either stop/start the whole Tomcat instance or
stop/start the Web apps representing the affected ModuleComponents.
What do people think of this approach as a starting point?
--
Jean-Sebastien Delfino
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by Jim Marino <jm...@myroma.net>.
Comments inline. I think this is going to bring up some of the
issues of using Tomcat as a deployment environment (not that Tomcat
is bad, just that we are using it in a way it probably wasn't
designed for).
On Dec 15, 2005, at 2:00 PM, David Booz wrote:
> On 12/15/05, Jean-Sebastien Delfino <js...@gmail.com> wrote
>
>
>> <snip>
>> What do people think of this approach as a starting point?
>>
>
>
> At first it feels a little heavyweight. But, SCA modules need to be
> classloader isolated,
> so using a web app is probably the only approach for modules. That
> leaves
> you without
> a way to contain a subsystem.
>
> Do you have further thoughts on how deployment would work? Is there a
> package (zip, jar), or would you
> just drive it off the subsystem file?
>
I think we are going to have to do a couple of passes. For example,
without having thought this out, we would:
1. Scan for subsystem.xml and compute a subsystem model. This would
be done by some type of bootstrap. It would be helpful if SCA were
eventually recursive where subsytems are just module fragments for this.
2. Have a runtime or root "aggregate component" that contains a
"system aggregate components" that themselves contain system
components (e.g. trx manager, etc.). These aggregate components get
loaded in a special system scope container that is started first.
3. The root aggregate component then gets module components added to
it by entries in the subsystem or by deployed web apps. These module
components are treated by the root aggregate components as just
another component type and are themselves wired with system
components that were previously started over a special (non-proxy)
binding. This will allow us to compose and extend the runtime by
adding new module fragments or modules at the runtime level, i.e. SCA
is used to extend SCA.
> I'm wondering about resolving references. Module Component
> references can
> be wired to Module
> Components in other subsystems. In order to get that to work right,
> would
> you have to rummage around
> in the Tomcat config filesystem? Are there APIs for that?
We can get the %CATALINA_HOME% and can from there by just reading the
file system (assuming security allows that which it should since we
are loaded as part of the Tomcat system). This is going to introduce
some interesting sequencing problems if Tomcat allows web apps to
come online prior to all of them being initialized. If it blocks for
all of them, then I think we will be o.k. since we can lazily handle
wires to other module components. The real tricky one will be in a
cluster.
> Then you'd have
> to work back to get the endpoint
> of the target Module Component.
>
> And last, (perhaps I'm jumping too far ahead) there are some
> advanced cases
> supported by the spec
> which might be difficult to handle in this environment, e.g. deploying
> subsystems with just
> wires.
Yea - that will be a little tricky. Luckily, I think we can get all
the subsystem artifacts before the web apps are deployed and push
that information down into the modules (see my response to Sebastien
earlier). For modules with just wires, I think we may need to incur
the extra hop. This makes me think we will soon want a more advanced
deployment environment - OSGi maybe? ;-)
We will also need to think about how change/update notification works
both within a runtime instance and across a cluster but I assume we
can deal with that later.
The more I think about it, SCA is a giant configuration
infrastructure :-)
>
> --
> Dave Booz
> IBM, SCA Architecture
>
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
jack.unrue@sybase.com wrote:
> David Booz wrote:
>
>> At first it feels a little heavyweight. But, SCA modules need to be
>>
> classloader isolated,
>
>> so using a web app is probably the only approach for modules. That
>>
> leaves you without
>
>> a way to contain a subsystem.
>>
>
> Would it make sense to consider borrowing OSGi -like infrastructure from
> one of the OSGi
> projects, or at least the concept? I realize there are aspects of OSGi
> that Tuscany may not
> want to pull in, but the classloader-related abstractions seem applicable.
>
> Perhaps what I'm saying conflicts with the notion of using Tomcat as a
> container in the
> first place, so please feel free to educate me on that point :-)
>
>
We're using Tomcat as a container right now, an SCA ModuleComponent gets
deployed as a Web App and ModuleComponents communicate through SOAP.
However this is just a starting point, we definitely need to look at
more advanced deployment environments and OSGI in particular at some
point. I'm thinking that SCA modules could be deployed as OSGI bundles
running on an OSGI runtime. I think that Jim also mentioned that as well
in one of his earlier posts to the list.
--
Jean-Sebastien Delfino
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by ja...@sybase.com.
David Booz wrote:
>
> At first it feels a little heavyweight. But, SCA modules need to be
classloader isolated,
> so using a web app is probably the only approach for modules. That
leaves you without
> a way to contain a subsystem.
Would it make sense to consider borrowing OSGi -like infrastructure from
one of the OSGi
projects, or at least the concept? I realize there are aspects of OSGi
that Tuscany may not
want to pull in, but the classloader-related abstractions seem applicable.
Perhaps what I'm saying conflicts with the notion of using Tomcat as a
container in the
first place, so please feel free to educate me on that point :-)
--
Jack Unrue
junrue@sybase.com
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by David Booz <sc...@gmail.com>.
Comments inline.
On 12/15/05, Jean-Sebastien Delfino <js...@gmail.com> wrote:
>
> David Booz wrote:
> > On 12/15/05, Jean-Sebastien Delfino <js...@gmail.com> wrote
> >
> >
> >> <snip>
> >> What do people think of this approach as a starting point?
> >>
> >
> >
> > At first it feels a little heavyweight. But, SCA modules need to be
> > classloader isolated,
> > so using a web app is probably the only approach for modules. That
> leaves
> > you without
> > a way to contain a subsystem.
> >
> >
> Here are some reasons why I think that using a Tomcat instance per
> subsystem is interesting:
> - You can isolate solutions/subsystems from each other, ensure that they
> get the desired service level, amount of memory, CPU etc
> - You can package together a subsystem and all the resources and
> definitions that it needs to work making it really easy to distribute
> and duplicate your application as a self contained bundle.
> - You can also build and configure your SCA runtime with exactly what
> your subsystem needs, and not more... If you don't need pieces of the
> runtime we can strip them out. For example if you're not using
> transaction policies we won't need a TM in the picture, if you're not
> using Web Services we won't include Axis, if you're not using DAS we can
> strip out the DB, etc... I think that this will actually allow us to
> build more lightweight solutions (and simpler to deploy and operate as
> well).
>
> > Do you have further thoughts on how deployment would work? Is there a
> > package (zip, jar), or would you
> > just drive it off the subsystem file?
> >
> >
> With respect to the Subsystem definition, I was thinking about just a
> subsystem file. This may change when we introduce the ability to define
> EntryPoints and ExternalServices in a Subsystem, as they'll have to come
> with binding definitions, interface definitions etc, and we'll have to
> define the correct way to package and deploy these artifacts.
>
> > I'm wondering about resolving references. Module Component references
> can
> > be wired to Module
> > Components in other subsystems. In order to get that to work right,
> would
> > you have to rummage around
> > in the Tomcat config filesystem? Are there APIs for that? Then you'd
> have
> > to work back to get the endpoint
> >
> > of the target Module Component.
> >
> I'm not sure why we'd have to rummage through the filesystem. My
> understanding of the SCA spec is that the target URI of a wire can take
> the following forms:
> - http://www.stockquote.org/services/StockQuote, this is a binding
> specific URI, here a WS binding, this is WS business as usual you just
> need to know the address of the target Web service
> - <moduleComponentName>/<serviceName> allows you to wire to a service in
> another module component in the same subsystem, you just need to know
> the name of the target module component and service, they belong to the
> same subsystem
> - <externalServiceName> allows you to wire to an external service
> defined in the same subsystem
> Page 46 describes another form (which IMO should be listed on p42 as
> well)
> - <systemUri>/<subsystemUri>/<moduleComponentUri>/<serviceUri> allows
> you to wire to a service in another subsystem or another system, again
> here you just need to know the URIs and names of the
> system/subsystem/moduleComponent/service that you want to talk to.
>
> For the last form, I'm thinking that in the long term we would use a
> directory to figure out the actual address behind this URI, for now I
> would try to use the Apache httpd / Tomcat configuration magic to map
> this URI to the actual address of the target service, I'm not sure yet
> how to do that, does anybody on the list know how easy it would be to do?
It was this last form that I was worried about. I'm worried that in order
to
validate a wire, you need to see the subsystem.xml for other subsystems
which are in another part of the tomcat config. I agree that we can put it
off for
now and do this in stages, just don't want to lose sight of the end goal.
Sometimes
solving the harder problems first makes the easier problems even easier.
> And last, (perhaps I'm jumping too far ahead) there are some advanced
> cases
> > supported by the spec
> > which might be difficult to handle in this environment, e.g. deploying
> > subsystems with just
> > wires.
> >
> Yes perhaps you're jumping too far ahead :) I think that initially, in
> the absence of a distributed directory, wires can only be defined in
> their source subsystem. But again this is just a starting point... we
> definitely need to support these advanced scenarios in the future.
>
> > --
> > Dave Booz
> > IBM, SCA Architecture
> >
> >
> --
>
> Jean-Sebastien Delfino
>
>
>
--
Dave Booz
IBM, SCA Architecture scabooz@gmail.com
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by Jean-Sebastien Delfino <js...@gmail.com>.
David Booz wrote:
> On 12/15/05, Jean-Sebastien Delfino <js...@gmail.com> wrote
>
>
>> <snip>
>> What do people think of this approach as a starting point?
>>
>
>
> At first it feels a little heavyweight. But, SCA modules need to be
> classloader isolated,
> so using a web app is probably the only approach for modules. That leaves
> you without
> a way to contain a subsystem.
>
>
Here are some reasons why I think that using a Tomcat instance per
subsystem is interesting:
- You can isolate solutions/subsystems from each other, ensure that they
get the desired service level, amount of memory, CPU etc
- You can package together a subsystem and all the resources and
definitions that it needs to work making it really easy to distribute
and duplicate your application as a self contained bundle.
- You can also build and configure your SCA runtime with exactly what
your subsystem needs, and not more... If you don't need pieces of the
runtime we can strip them out. For example if you're not using
transaction policies we won't need a TM in the picture, if you're not
using Web Services we won't include Axis, if you're not using DAS we can
strip out the DB, etc... I think that this will actually allow us to
build more lightweight solutions (and simpler to deploy and operate as
well).
> Do you have further thoughts on how deployment would work? Is there a
> package (zip, jar), or would you
> just drive it off the subsystem file?
>
>
With respect to the Subsystem definition, I was thinking about just a
subsystem file. This may change when we introduce the ability to define
EntryPoints and ExternalServices in a Subsystem, as they'll have to come
with binding definitions, interface definitions etc, and we'll have to
define the correct way to package and deploy these artifacts.
> I'm wondering about resolving references. Module Component references can
> be wired to Module
> Components in other subsystems. In order to get that to work right, would
> you have to rummage around
> in the Tomcat config filesystem? Are there APIs for that? Then you'd have
> to work back to get the endpoint
>
> of the target Module Component.
>
I'm not sure why we'd have to rummage through the filesystem. My
understanding of the SCA spec is that the target URI of a wire can take
the following forms:
- http://www.stockquote.org/services/StockQuote, this is a binding
specific URI, here a WS binding, this is WS business as usual you just
need to know the address of the target Web service
- <moduleComponentName>/<serviceName> allows you to wire to a service in
another module component in the same subsystem, you just need to know
the name of the target module component and service, they belong to the
same subsystem
- <externalServiceName> allows you to wire to an external service
defined in the same subsystem
Page 46 describes another form (which IMO should be listed on p42 as
well)
- <systemUri>/<subsystemUri>/<moduleComponentUri>/<serviceUri> allows
you to wire to a service in another subsystem or another system, again
here you just need to know the URIs and names of the
system/subsystem/moduleComponent/service that you want to talk to.
For the last form, I'm thinking that in the long term we would use a
directory to figure out the actual address behind this URI, for now I
would try to use the Apache httpd / Tomcat configuration magic to map
this URI to the actual address of the target service, I'm not sure yet
how to do that, does anybody on the list know how easy it would be to do?
> And last, (perhaps I'm jumping too far ahead) there are some advanced cases
> supported by the spec
> which might be difficult to handle in this environment, e.g. deploying
> subsystems with just
> wires.
>
Yes perhaps you're jumping too far ahead :) I think that initially, in
the absence of a distributed directory, wires can only be defined in
their source subsystem. But again this is just a starting point... we
definitely need to support these advanced scenarios in the future.
> --
> Dave Booz
> IBM, SCA Architecture
>
>
--
Jean-Sebastien Delfino
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by David Booz <sc...@gmail.com>.
On 12/15/05, Jean-Sebastien Delfino <js...@gmail.com> wrote
> <snip>
> What do people think of this approach as a starting point?
At first it feels a little heavyweight. But, SCA modules need to be
classloader isolated,
so using a web app is probably the only approach for modules. That leaves
you without
a way to contain a subsystem.
Do you have further thoughts on how deployment would work? Is there a
package (zip, jar), or would you
just drive it off the subsystem file?
I'm wondering about resolving references. Module Component references can
be wired to Module
Components in other subsystems. In order to get that to work right, would
you have to rummage around
in the Tomcat config filesystem? Are there APIs for that? Then you'd have
to work back to get the endpoint
of the target Module Component.
And last, (perhaps I'm jumping too far ahead) there are some advanced cases
supported by the spec
which might be difficult to handle in this environment, e.g. deploying
subsystems with just
wires.
--
Dave Booz
IBM, SCA Architecture
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by Michael Beisiegel <mi...@gmail.com>.
I think this works module just has to be in a jar that is used by the two
war's
that represent the module components.
Michael
On 12/16/05, David Booz <sc...@gmail.com> wrote:
>
> One comment inline on your 1st point.
>
> On 12/15/05, Jim Marino <jm...@myroma.net> wrote:
> >
> > Comments inline
> > On Dec 15, 2005, at 12:13 PM, Jean-Sebastien Delfino wrote:
> >
> > > I'd like to start a discussion on how we're going to deploy SCA
> > > Subsystems and ModuleComponents to Tomcat.
> > >
> > > First I think we should stage things so I propose that in a first
> > > step we only support ModuleComponents and Wires and not try to
> > > support the definition of ExternalServices and EntryPoints in a
> > > subsystem right away. We already support the definition of
> > > ExternalServices and EntryPoints inside SCA modules so this
> > > shouldn't limit us too much in terms of scenarios and we'll still
> > > be able to define service networks this way. When we get our
> > > Susbsytem/ModuleComponent story stable enough then I think it'll be
> > > really easy to build the Subsystem/ExternalService+EntryPoint
> > > support on top.
> > >
> > Yes we should probably approach this in steps. I'm not sure the
> > infrastructure supporting entry points/external services will be any
> > different, if we assume a couple of things. I was envisioning a
> > builder which evaluates the subsystem entry points, external
> > services, and wires and "pushes/injects" the configuration
> > information into the appropriate module SCDL (whose builders then
> > take it and decorate the model there). Basically, configuration
> > information gets collapsed down into the module SCDL and entry points
> > get defined there.
> >
> > This makes a bunch of assumptions and raises a number of questions:
> >
> > 1. Classloader boundaries are at the module level so if we push a
> > subsystem entry point down inside a module, it will run in that
> > context. I imagine this also impacts security. The other option is
> > not to do this and keep subsystem entry points outside the module
> > classloader, thereby incurring an extra hop. This is something we'll
> > probably need to clear up in the spec. I'm not too worried about
> > reloadability since we can handle that relatively easily. I'm
> > inclined to view subystem config as adding to module configuration
> > (the "push down model" rather than as forming an outer shell. Thoughts?
>
>
> I think it's probably a good first step. I'll just note that it does
> prevent
> 2
> Module Components from being implemented by the same module,
>
> 2. We are going to have some interesting sequencing issues for
> > references between module components. I'm not sure if when Tomcat is
> > brought up it waits for all web apps to load before accepting requests.
> >
> > 3. We're going to have some interesting configuration issues to
> > tackle for subsystems and module components that only contain wires.
> > For a module component that only contains wires, the easiest thing to
> > probably do is introduce a hop as opposed to trying to optimize it
> > away at config time since we don't have any control over the order
> > web apps start or come on line.
> >
> > > Now here's how I'd like to deploy a Subsystem and its
> > > ModuleComponents to Tomcat:
> > >
> > > A ModuleComponent is deployed as a Web app. A Subsystem is deployed
> > > as a Tomcat instance. The Web apps for the ModuleComponents in a
> > > Subsystem are simply deployed to the Tomcat instance representing
> > > the Subsystem. The sca.subsystem file defining the Subsystem file
> > > is stored in the conf directory for the Tomcat instance.
> > >
> > > Writing an sca.subsystem file is not mandatory. If you're happy
> > > with burning the configuration of your module in your sca.module
> > > file, don't need to use ModuleComponent properties and don't need
> > > to change your ExternalService bindings after the app has been
> > > deployed, then you just deploy your ModuleComponent as a Web app as
> > > we already support today.
> > >
> > Yes defaults are good.
> > > Several Tomcat instances can share the same Tomcat runtime, http://
> > > tomcat.apache.org/tomcat-5.5-doc/RUNNING.txt describes how to do it.
> > >
> > > To start/stop a subsystem, you start/stop the corresponding Tomcat
> > > instance. To change a Subsystem configuration, you update the
> > > sca.subsystem file, then either stop/start the whole Tomcat
> > > instance or stop/start the Web apps representing the affected
> > > ModuleComponents.
> > >
> > When a subsystem file changes and one just starts and stops the web
> > apps, we may need a trigger for refreshing the subsystem configuration.
> >
> > > What do people think of this approach as a starting point?
> > >
> > I think this is a good start.
> > > --
> > > Jean-Sebastien Delfino
> > >
> >
> >
>
>
> --
> Dave Booz
> IBM, SCA Architecture
> scabooz@gmail.com
>
>
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by David Booz <sc...@gmail.com>.
One comment inline on your 1st point.
On 12/15/05, Jim Marino <jm...@myroma.net> wrote:
>
> Comments inline
> On Dec 15, 2005, at 12:13 PM, Jean-Sebastien Delfino wrote:
>
> > I'd like to start a discussion on how we're going to deploy SCA
> > Subsystems and ModuleComponents to Tomcat.
> >
> > First I think we should stage things so I propose that in a first
> > step we only support ModuleComponents and Wires and not try to
> > support the definition of ExternalServices and EntryPoints in a
> > subsystem right away. We already support the definition of
> > ExternalServices and EntryPoints inside SCA modules so this
> > shouldn't limit us too much in terms of scenarios and we'll still
> > be able to define service networks this way. When we get our
> > Susbsytem/ModuleComponent story stable enough then I think it'll be
> > really easy to build the Subsystem/ExternalService+EntryPoint
> > support on top.
> >
> Yes we should probably approach this in steps. I'm not sure the
> infrastructure supporting entry points/external services will be any
> different, if we assume a couple of things. I was envisioning a
> builder which evaluates the subsystem entry points, external
> services, and wires and "pushes/injects" the configuration
> information into the appropriate module SCDL (whose builders then
> take it and decorate the model there). Basically, configuration
> information gets collapsed down into the module SCDL and entry points
> get defined there.
>
> This makes a bunch of assumptions and raises a number of questions:
>
> 1. Classloader boundaries are at the module level so if we push a
> subsystem entry point down inside a module, it will run in that
> context. I imagine this also impacts security. The other option is
> not to do this and keep subsystem entry points outside the module
> classloader, thereby incurring an extra hop. This is something we'll
> probably need to clear up in the spec. I'm not too worried about
> reloadability since we can handle that relatively easily. I'm
> inclined to view subystem config as adding to module configuration
> (the "push down model" rather than as forming an outer shell. Thoughts?
I think it's probably a good first step. I'll just note that it does prevent
2
Module Components from being implemented by the same module,
2. We are going to have some interesting sequencing issues for
> references between module components. I'm not sure if when Tomcat is
> brought up it waits for all web apps to load before accepting requests.
>
> 3. We're going to have some interesting configuration issues to
> tackle for subsystems and module components that only contain wires.
> For a module component that only contains wires, the easiest thing to
> probably do is introduce a hop as opposed to trying to optimize it
> away at config time since we don't have any control over the order
> web apps start or come on line.
>
> > Now here's how I'd like to deploy a Subsystem and its
> > ModuleComponents to Tomcat:
> >
> > A ModuleComponent is deployed as a Web app. A Subsystem is deployed
> > as a Tomcat instance. The Web apps for the ModuleComponents in a
> > Subsystem are simply deployed to the Tomcat instance representing
> > the Subsystem. The sca.subsystem file defining the Subsystem file
> > is stored in the conf directory for the Tomcat instance.
> >
> > Writing an sca.subsystem file is not mandatory. If you're happy
> > with burning the configuration of your module in your sca.module
> > file, don't need to use ModuleComponent properties and don't need
> > to change your ExternalService bindings after the app has been
> > deployed, then you just deploy your ModuleComponent as a Web app as
> > we already support today.
> >
> Yes defaults are good.
> > Several Tomcat instances can share the same Tomcat runtime, http://
> > tomcat.apache.org/tomcat-5.5-doc/RUNNING.txt describes how to do it.
> >
> > To start/stop a subsystem, you start/stop the corresponding Tomcat
> > instance. To change a Subsystem configuration, you update the
> > sca.subsystem file, then either stop/start the whole Tomcat
> > instance or stop/start the Web apps representing the affected
> > ModuleComponents.
> >
> When a subsystem file changes and one just starts and stops the web
> apps, we may need a trigger for refreshing the subsystem configuration.
>
> > What do people think of this approach as a starting point?
> >
> I think this is a good start.
> > --
> > Jean-Sebastien Delfino
> >
>
>
--
Dave Booz
IBM, SCA Architecture
scabooz@gmail.com
Re: Deploying Subsystems and ModuleComponents to Tomcat
Posted by Jim Marino <jm...@myroma.net>.
Comments inline
On Dec 15, 2005, at 12:13 PM, Jean-Sebastien Delfino wrote:
> I'd like to start a discussion on how we're going to deploy SCA
> Subsystems and ModuleComponents to Tomcat.
>
> First I think we should stage things so I propose that in a first
> step we only support ModuleComponents and Wires and not try to
> support the definition of ExternalServices and EntryPoints in a
> subsystem right away. We already support the definition of
> ExternalServices and EntryPoints inside SCA modules so this
> shouldn't limit us too much in terms of scenarios and we'll still
> be able to define service networks this way. When we get our
> Susbsytem/ModuleComponent story stable enough then I think it'll be
> really easy to build the Subsystem/ExternalService+EntryPoint
> support on top.
>
Yes we should probably approach this in steps. I'm not sure the
infrastructure supporting entry points/external services will be any
different, if we assume a couple of things. I was envisioning a
builder which evaluates the subsystem entry points, external
services, and wires and "pushes/injects" the configuration
information into the appropriate module SCDL (whose builders then
take it and decorate the model there). Basically, configuration
information gets collapsed down into the module SCDL and entry points
get defined there.
This makes a bunch of assumptions and raises a number of questions:
1. Classloader boundaries are at the module level so if we push a
subsystem entry point down inside a module, it will run in that
context. I imagine this also impacts security. The other option is
not to do this and keep subsystem entry points outside the module
classloader, thereby incurring an extra hop. This is something we'll
probably need to clear up in the spec. I'm not too worried about
reloadability since we can handle that relatively easily. I'm
inclined to view subystem config as adding to module configuration
(the "push down model" rather than as forming an outer shell. Thoughts?
2. We are going to have some interesting sequencing issues for
references between module components. I'm not sure if when Tomcat is
brought up it waits for all web apps to load before accepting requests.
3. We're going to have some interesting configuration issues to
tackle for subsystems and module components that only contain wires.
For a module component that only contains wires, the easiest thing to
probably do is introduce a hop as opposed to trying to optimize it
away at config time since we don't have any control over the order
web apps start or come on line.
> Now here's how I'd like to deploy a Subsystem and its
> ModuleComponents to Tomcat:
>
> A ModuleComponent is deployed as a Web app. A Subsystem is deployed
> as a Tomcat instance. The Web apps for the ModuleComponents in a
> Subsystem are simply deployed to the Tomcat instance representing
> the Subsystem. The sca.subsystem file defining the Subsystem file
> is stored in the conf directory for the Tomcat instance.
>
> Writing an sca.subsystem file is not mandatory. If you're happy
> with burning the configuration of your module in your sca.module
> file, don't need to use ModuleComponent properties and don't need
> to change your ExternalService bindings after the app has been
> deployed, then you just deploy your ModuleComponent as a Web app as
> we already support today.
>
Yes defaults are good.
> Several Tomcat instances can share the same Tomcat runtime, http://
> tomcat.apache.org/tomcat-5.5-doc/RUNNING.txt describes how to do it.
>
> To start/stop a subsystem, you start/stop the corresponding Tomcat
> instance. To change a Subsystem configuration, you update the
> sca.subsystem file, then either stop/start the whole Tomcat
> instance or stop/start the Web apps representing the affected
> ModuleComponents.
>
When a subsystem file changes and one just starts and stops the web
apps, we may need a trigger for refreshing the subsystem configuration.
> What do people think of this approach as a starting point?
>
I think this is a good start.
> --
> Jean-Sebastien Delfino
>