Jevgeni Kabanov wrote on 06/15/2011 11:21 AM:
> I'm still catching up with the reading and some research, but here are in no
> particular order some things I'd ideally want to see from this:
> 1. App servers should abandon the notion that they are only managed by their own
> consoles. Their should be a generic way to start/stop/deploy/etc. I haven't
> looked into JSR-77 yet, maybe that's the one. But I'd propose to standardize on
> the command line instead of the Java API, which is hugely cumbersome in a
> heterogenous environment the apps commonly live in.
We tried to standardize some of this in JSR-77 and JSR-88. They have not been
a success. While we'd like to do more here, it's a tremendous amount of
effort, and not something we're planning to do for EE 7.
> 2. Also, please let me pass parameters to the JVM, e.g. managing Glassfish
> through scripts is impossible. Being able to tune the app server and its JVM
> centrally is a must for the cloud.
To make standardizing this really useful, we'd want standardized JVM
parameters. There are none. A standardized way to pass non-standard
parameters isn't as interesting, and encourages non-portable applications.
Passing JVM parameters with an application when you deploy the application
to the cloud assumes a certain deployment model (one application per JVM)
that we're unlikely to require.
If people think there's value in standardizing a way to pass non-standard
JVM parameters, with no requirement that the application server do anything
with them, I suppose we could consider that.
Oh, and you *can* set JVM parameters for GlassFish using a script so I'm
not sure what your issue is there.
> 3. REST API layered over JMX API for deployment, configuration management and
> app management. Can't stress that enough.
JSR-77 is an EJB API for management. It gave us a standardized protocol
for management that wasn't Java specific. Still, JMX proved more popular.
There is still no cross-platform standardized protocol for management
using JMX. We've been asking for years for a Web Services / SOAP mapping
for JMX. Today, using a REST-based protocol might be a better choice.
Again, this is a ton of work that we won't be able to do for EE 7.
> 4. A jvm-instance-per-app model (better called process per app model) for app
> servers as an alternative to the current classloader per app model and way to
> manage those apps. At least as an option to be standardized on down the line.
I don't think we'll standardize this, but this is definitely one implementation
strategy that we intend to allow.
> 5. Session API/SPI (probably through the same JMX/REST combination) that allows
> to migrate data without relying on the app server and also keep session in the
> super-effective datagrids/caches.
I'm not sure I understand your use case here.
Our focus has been on APIs that applications need. Applications shouldn't
be migrating data.
In some cases we've provided SPIs that allow servers to be extended, or
allow multiple implementations of a facility to be provided independently
of a server vendor. An SPI to allow pluggability of session state
storage and migration mechanisms might be interesting.
> 6. Oh, and an API for provisioning app servers, though that's probably too much
> to expect :)
>
> Generally I think the main thing PaaS support requires is to expose a bunch of
> scripting APIs and make the app server consoles to be consumers of the APIs the
> underlying server exposes. This will create a great ecosystem to complement the
> existing tooling instead of requiring app servers to catch up one by one.
That's not our current plan.
We're trying to enable application server vendors to provide a full cloud
platform.
We're not trying to turn application servers into a component that someone
else would use to construct a full cloud platform.