Hi
In the context of management and administration it may be favorable to meditate on the differences between declarative and procedural methodologies also.
A procedural approach offer a sense of control but administration gets complicated as unreliable networks grows. It also force administrators to learn what commands and in what order to execute them in order navigate configuration into the desired state, i.e. pre-conditions must be known and tracked by the administrator. This makes it even more difficult to maintain a consistent configuration across the network.
A declarative approach hides procedural implementation details and complexity from the administrator and is gentler and potentially more robust and secure from the perspective of server/process. Changes can also be validated before commited since the desired end state is known upfront.
It is anyway interesting to see that the separation between upgrades and configuration management can really start to blur when thinking about it - *perform* an upgrade or *configure* an upgrade :-)
Food for thought.
Cheers,
-Kristoffer
-----Original Message-----
From: Adam Bien [mailto:abien_at_adam-bien.com]
Sent: den 17 juni 2011 10:34
To: jsr342-experts_at_javaee-spec.java.net
Subject: [jsr342-experts] Re: Support for the Platform as a Service model
" think in the interim, JSR-88 and JSR-77 are the way go "
Absolutely. They are already a part of J2EE and would require a face lift. I guess it is impossible to prune them, so introducing another one would just increase the Java EE 7 complexity.
--adam
On 17.06.2011, at 02:44, 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
>>
>>
>