Whoops -- I meant cart before horse (or something like that anyway :-))...
-- Reza
On 6/16/2011 8:44 PM, Reza Rahman wrote:
> 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
>>
>>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3708 - Release Date: 06/16/11
>
>