jsr342-experts@javaee-spec.java.net

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

From: Kristoffer Sjögren <kristoffer.sjogren_at_ericsson.com>
Date: Fri, 17 Jun 2011 10:15:35 +0200

One example of a Java EE-based PaaS is Red Hat's OpenShift Flex. Google App Engine could be seen as another example (not fully Java EE).

Cheers,
-Kristoffer

-----Original Message-----
From: Jevgeni Kabanov [mailto:jevgeni_at_zeroturnaround.com]
Sent: den 17 juni 2011 08:32
To: jsr342-experts_at_javaee-spec.java.net
Subject: [jsr342-experts] Re: Support for the Platform as a Service model

I did say "ideally".

I guess I'll turn the question around then -- what are the good examples of a Java EE-based PaaS today? I know of Amazon Beanstalk, are there any others?

--
Jevgeni Kabanov
Founder & CTO of ZeroTurnaround
http://twitter.com/ekabanov
On Friday, June 17, 2011 at 0:54 , 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.