Application Isolation in App Servers was Re: Module isolation

[Bryan Atsatt]

Whoops, forgot to say one thing...

As you describe it, I would consider JBoss ClassLoader Domains to be
100% public as long as *any* application can import/subscribe/access it.

To me:

a. A public repository contains Modules that may be imported by any other.

b. A private repository contains Modules that may only be imported by
other modules from the *same* deployment unit (e.g. .ear file.)

Anything in between seems to cry out for an access control model.

// Bryan

Bryan Atsatt wrote:
> 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
>>
>