Date: Sat, 18 Jun 2011 00:56:47 +0530
Sounds like we'd also need a JSON JSR first for most of that [?]
On Fri, Jun 17, 2011 at 6:51 PM, Adam Bien <abien_at_adam-bien.com> wrote:
> I would go with resource based approach. Procedural sound somehow
> procedural. A good API should be self-explorative. Look e.g. at
> http://kenai.com/projects/suncloudapis/pages/HelloCloud
>
> thanks!,
>
> adam
> On 17.06.2011, at 15:16, Kristoffer Sjögren wrote:
>
> > 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
> >>>
> >>>
> >>
> >
> >
>
> Independent Consultant, Speaker, Java Champion
>
> Weblog: blog.adam-bien.com
> press: press.adam-bien.com
> eMail: abien_at_adam-bien.com
> twitter: twitter.com/AdamBien
> Mobile: 0049(0)170 280 3144
>
> Author of:
> "Real World Java EE Night Hacks", "Real World Java EE Patterns--Rethinking
> Best Practices"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-- Werner Keil | UOMo Lead | Eclipse Foundation | Agile Coach, Principal Consultant | *emergn* limited 590 Madison Avenue. New York. NY 10022 | 68 Lombard Street. London EC3V 9LJ UK US Toll Free: +1-877.964.1981 | Worldwide Toll Free: +800.225.53482 Twitter @wernerkeil | Skype: werner.keil | www.emergn.com | Reshaping IT
(image/gif attachment: 347.gif)