Bill,
For what it is worth, I agree with you that some of this looks like it
is putting the horse before the cart :-). I'd like to see the existing
developer APIs improve first and perhaps a basic outline of resource
layer multi-tenancy before adding too many new APIs geared towards PaaS
vendors. I think in the interim, JSR-88 and JSR-77 are the way go to
even if they are less than ideal, maybe augmented by vendor-specific
server APIs.
Cheers,
Reza
On 6/16/2011 5:54 PM, Bill Shannon wrote:
> 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.
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3707 - Release Date: 06/16/11
>
>