Fresh APIs based on newer JMX versions would be even better. Don't ask developers about management and monitoring - ask the troubleshooters / operations :-)
On 17.06.2011, at 03:57, 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