Hi All,
I think a greater value add and challenge would be to support multi-tenant
capability to an application, rather than to the platform. Moving forward,
"multi-tenancy" and "scalability" are the two major aspects every
application architect would need to chalk out.
Though application multi-tenancy is something the application needs to
build, a lot of work needs to be done on top of the existing
JDBC/JPA/Servlet contracts in order to really achieve this. May be the
expert group should focus more on this aspect.
-comments-
----- Original Message -----
From: "Jason T. Greene" <jason.greene_at_redhat.com>
> On 6/2/11 12:47 PM, Antonio Goncalves wrote:
>
> -snip-
>
>> Correct me if I'm wrong, but latelly I've been earing a lot about
>> multi-tenant. It looks to me that the world is moving the other way now.
>> Application servers, databases... tend to be lighter and lighter in
>> terms of resources. So why bother having multi-tenancy ? Just
>> instanciate several servers or DBs and each instance only hosts one
>> application.
>
> This is essentially my thoughts on multi-tenant single JVM PAAS, but also
> for a number of other reasons:
>
> 1. Security - Without major changes to the SE JVMs, it will be nearly
> impossible to prevent one hostile app from having the ability to
> interfere with another. The JVM security manager isnt really a good fit
> for a multi-tenant environment, at a minimum it would be very difficult to
> manager. Also there is really no such thing as a heap safe guard, so it's
> possible that one tenant could somehow gain access to another's memory.
Completely Agree. In a multi-tenant platform, things like classloaders,
static registries etc. can really become a nightmare, forcing the containers
and applications to be re-engineered.
> 2. Robustness - One bad/broken jar can easily crash the entire server,
> since there is no limit to the amount of cpu and memory it can use.
> 3. Resource tracking fairness - With the state of the current SE JVMs,
> it's not really possible to bill usage fairly. You could track the number
> of requests, possible connection pool usage, and invocation counts, but
> these are not necessarily a fair representation of hardware resource cost.
Yes, it is very difficult to meet customer SLAs. I'm not sure if tracking
Java EE resource usage opens up a new business model for the PaaS vendors.
> 4. Complexity - Trying to get all of the EE services to "partially" adress
> the above problems (the best we can hope for given the state of SE) will
> lead major changes to probably every EE API we have, and will likely make
> all of the implementations far more complex.
>
> All of these issues are pretty much solved by having multiple processes
> which can then take advantage of the underlying OS that has been solving
> these problems for decades. Having each of those processes be a JVM works
> great today, however, it does waste memory since there is no class/data
> sharing*,**.
Yes, this model has been cost-effective and practical for hosted
applications.
>
> It's a shame that the work behind MVM didn't continue, had it been further
> along, it might have fit our needs.
>
> If the goal, however, is to make it easier to build SAAS applications that
> actually sounds achievable.
>
> [*] I realize openjdk has a class sharing feature but it is very limited
> (client only, inteded for bootclasspath only), and requires that you save
> memory dumps (so not practical).
>
> [**] Certain non-certified JVMs (Dalvik), and other research projects have
> implemented multi process class file sharing.
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
-Deepak