Application Isolation in App Servers was Re: Module isolation

[Bryan Atsatt]

Adrian wrote:
> On Mon, 2007-06-18 at 14:09 -0700, Bryan Atsatt wrote:
>> So an application server would have to create, say, a private
>> LocalRepository instance to hold the modules of a single application.
>> And it would have to ensure that no other application could get it's
>> grubby paws on that repository instance.
>>
>> Ok. That works for me. And it eliminates the need for cloning AND for
>> releaseModule():
>>
>> 1. Any given Repository instance is either 100% shared or 100% private,
>> with *no* in-between.
>
> Since we are talking about appservers, I'll just point out
> that this doesn't cover what JBoss allows you to do.
>
> In JBoss we have a notion of what I like to call "ClassLoader Domains"
> although they are actually called "LoaderRepositorys" after
> the JMX name (note the JMX spec only has a singleton repository).
>
> These are "isolated" classloading systems that sit on top
> of a "Default Domain" and you can choose whether to do
> parent/child delegation in either
> * standard J2SE order (parent first)
> * servlet style (child first).
>
> When you deploy an application you get to choose the domain.
> There is nothing to stop you putting multiple applications
> into the same domain.
>
> I would guess in your proposal they WOULD share the
> same LocalRepository but only those named applications
> would have access to it?

Right.

>
> There are two main usecases for such a configuration.
>
> 1)  Optimization
> You want to optimize the inter-application communication
> between related applications. i.e. one application uses
> components from another application and you don't want
> to do call-by-value.
> By having the applications in the same classloader domain
> one application can lookup and use the local interfaces
> of the other application.

Yep.

>
> 2) Convenience
> You deploy a rar inside an ear (making the rar classes
> invisible to other applications)
> but you want to configure the connection factories
> of that rar outside the ear where it is easier to
> edit the configuration file.
>
> In this case you can specify that the connection factories
> should use the classloading domain of the ear, making
> its classes visible again.
>
> e.g. something like:
>
> <connection-factories>
>
> <loader-repository>classloader:application=myapp.ear</loader-repository>
>
> <etc/>

This last example doesn't really apply in our server, as the config is
just as easy to edit inside as outside an ear. But I see your point.


Most apps don't need to share classes in this way, and need only a
mixture of global and purely local classes. Clearly any module system
will be able to satisfy the first requirement. We need to make sure we
can also satisfy the second.

But you are right, of course, that there exist more complex scenarios
that require an intermediate form of sharing. Your named domains seems
to satisfy that requirement. Can you restrict access to domains?

And, as you know, even *within* an application, web-modules need to be
isolated. So the private repository approach breaks down a bit here, or
must be taken to the extreme of a single module repository instance.
This is where an access control model might be a better solution.


Our server supports three models for class sharing:

1. Global. All apps share a single version of the classes. This is a
deprecated model.

2. Shared. Our "Shared Libraries" are named/versioned loaders configured
at the server level, each with one or more code-sources. Each can
optionally import other shared-libraries. Import declarations are by
name and version range. A default set of imports is configured by the
container for all application instances, but each is app free to modify
that set via config.

(This is obviously very much like the 277/OSGi model.)

3. Application group. Applications are hierarchical: each app is
deployed under some parent, and can access the classes of that parent
(excluding web-modules). So several apps can be deployed under a common
parent, and classes visible at the parent are visible to the children.
The global model in #1 simply means deploying classes into our "default"
application.


The shared-library approach has proved to be the most flexible and most
used (surprise). But this model does not support any access control, so
at the moment, if you want restricted sharing you must use the shared
parent approach.

And while we do support execution under a SecurityManager, *very* few
companies are willing to pay the runtime overhead for this. Sure,
permissions can be applied without a SecurityManager, but this incurs
the administrative headache of granting permissions correctly.


So I'd rather steer clear of a permission based approach to restricting
access to modules, if we want to go down this path at all.

// Bryan

> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Adrian Brock
> Chief Scientist
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>