jsr342-experts@javaee-spec.java.net

[jsr342-experts] Re: Support for the Platform as a Service model

From: Jason T. Greene <jason.greene_at_redhat.com>
Date: Thu, 16 Jun 2011 21:50:17 -0500

No I mean that we the EG (including you) marked JSR-88 as pruned in EE6
(will no longer be required for vendors in EE7 provided we don't change
our minds). I thought we did the same for 77, but apparently we did not.

On 6/16/11 9:32 PM, Reza Rahman wrote:
> Jason,
>
> Yep -- we did the same :-).
>
> Cheers,
> Reza
>
>
> On 6/16/2011 9:57 PM, Jason T. Greene wrote:
>> We pruned those two, since they are significantly out of date (did not
>> handle annotations), and had little interest (ask an EE developer
>> about these and you get silence followed by blinks). IMO If we did
>> want to introduce a management / deployment spec, it should be a fresh
>> take from scratch.
>>
>> On 6/16/11 7: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
>>>>
>>>>
>>>
>>
>>
>


-- 
Jason T. Greene
JBoss, a division of Red Hat