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

From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 16 Jun 2011 16:14:50 +0530

Application isolation is a good point. Right now (EE5/6) sometimes the only
way to get a web application using particular APIs or implementations (i.E.
Hibernate) to work is by putting it into an EAR. I doubt, EE6 has
significantly changed that, but as we use WebLogic mostly I can't say that,
as even WLS11 is not fully EE6 compatible yet[?]

Glassfish may behave better on that in some areas, but allowing this kind of
safety for EVERY container would be very beneficial.

2011/6/16 liming <liming_at_tongtech.com>

> ** ** ** **
>
> +1.****
>
> I think the new Java EE 7 for the Platform as a Service Model will draw a
> new blueprint include two parts, one is focus on traditional Java EE spec
> evolution, the other is focus on interfaces for the PaaS Management.****
>
> **1. **Java EE spec evolution things, like application version,
> modularity, JPA, configuration, etc, some previous threads recommend. ****
>
> **2. **Interfaces for the PaaS management things, like applications
> isolation (process per app model or something else), Session SPI,
> provisioning API, application server lifecycle
> controlling(start/stop/deploy/etc/)****
>
> ** **
>
> The most innovation and attractive thing of Java EE 7 is to define
> Interfaces for the PaaS, I think. ****
>
> ** **
>
> Cheers****
>
> --****
>
> Li Ming****
> ------------------------------
>
> *��:* Jevgeni Kabanov [mailto:jevgeni_at_zeroturnaround.com]
> *��ʱ��:* **2011��6��16��** 2:22
> *�ռ��:* **jsr342-experts_at_javaee-spec.java.net**
> *��:* [jsr342-experts] Re: Support for the Platform as a Service model****
>
> ** **
>
> 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. ****
>
> 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.****
>
> 3. REST API layered over JMX API for deployment, configuration management
> and app management. Can't stress that enough.****
>
> 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.****
>
> 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. ****
>
> 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.****
>
> --****
>
> Jevgeni Kabanov****
>
> Founder & CTO of ZeroTurnaround****
>
> http://twitter.com/ekabanov****
>
> ** **
>
> On Wednesday, June 15, 2011 at 18:47 , Reza Rahman wrote:****
>
> Jevgeni,
>
> I agree. I think this is really the practical way most multi-tenancy would
> be implemented.
>
> Cheers,
> Reza
>
>
> On 6/15/2011 8:40 AM, Jevgeni Kabanov wrote: ****
>
> Personally, I don't think that modularity will give any advantages to PaaS
> or multi-tenancy. For PaaS using process-per-application model would make
> the most sense, as that would provide proper isolation and for multi-tenancy
> either separate JVM instance can be used to ensure isolation or a monolithic
> approach to leave isolation requirements to the app developer.
>
> -- ****
>
> Jevgeni Kabanov****
>
> Founder & CTO of ZeroTurnaround****
>
> http://twitter.com/ekabanov****
>
> ** **
>
> On Wednesday, June 15, 2011 at 15:34 , Antonio Goncalves wrote:****
>
> It's scary to thing multi-tenancy without having modularization and wait
> until SE 8 (Jigsaw). I really wonder how we will get trough this PasS/SaaS
> adventure without modularity and just guessing what will happen (even if
> Jigsaw is pretty much defined) ****
>
> ** **
>
> Antonio****
>
> On Tue, Jun 14, 2011 at 20:22, Adam Bien <abien_at_adam-bien.com> wrote:
>
> ****
>
> ** **
>
> On 02.06.2011, at 21:42, Jeff Genender wrote:****
>
>
>
> ****
>
> Im in agreement with a possible cloud profile, but I don't think putting
> off a PaaS item until JavaEE 8 is a good idea. ****
>
> ** **
>
> +1. We should at least prepare things and then wait for Jigsaw :-)****
>
>
>
> ****
>
> The rate which we get things out, there will be a next big thing. Lots of
> folks are clamoring for PaaA standards and I think we are in a good point to
> have it a part of this spec. ****
>
> ** **
>
> Jeff****
>
> ** **
>
> On Jun 2, 2011, at 1:36 PM, Reza Rahman wrote:****
>
>
>
> ****
>
> Antonio,
>
> Glad I'm not the only one seeing things from this perspective :-). Quite
> honestly, I would not be at all opposed to delaying the entire multi-tenancy
> idea to Java EE 8 or later and focus on the more "bread-and-butter" things
> that need to be done :-).
>
> Cheers,
> Reza
>
>
> On 6/2/2011 1:47 PM, Antonio Goncalves wrote: ****
>
> I'm following reza's comments on "not everybody needs cloud" and I think we
> should have a Cloud profile instead of having it on the EE platform ?
> Profiles can be subsets of EE as well as super sets. So why not having a
> Cloud profile that includes most of EE and adds extra cloud features ? This
> way we could also leave EE as it is (which means no Cloud, Cluster,
> multi-tenant...). What do you think ?
>
> Correct me if I'm wrong, but latelly I've been earing a lot about
> multi-tenant. It looks to me that the world is moving the other way now.
> Application servers, databases... tend to be lighter and lighter in terms of
> resources. So why bother having multi-tenancy ? Just instanciate several
> servers or DBs and each instance only hosts one application. If I'm not
> wrong (Nicolas Leroux can correct me) a Play! instance takes less than 100Kb
> or RAM. With profiles, OSGi and modularity arriving, the platform is
> shrinking and the app servers will shrink too, so why not goaling for
> several app servers with one application instead of one app server with
> several applications (same for DBs) ? That's why I think all these PAAS
> concepts could go into a profile, not EE. Multi-tenancy is useful for some
> people, but not everybody.
>
> My 2 cents
>
> Antonio
>
>
> ****
>
> On Sat, May 28, 2011 at 1:02 AM, Reza Rahman <reza_rahman_at_lycos.com>
> wrote:
>
> ****
>
> Bill,
>
> OK, all of what you said makes perfect sense - thanks for the prompt
> response.
>
> We'll put some more thoughts on some of this internally and will try to
> share helpful details.
>
> Cheers,
> Reza ****
>
>
>
>
> On 5/27/2011 6:20 PM, Bill Shannon wrote:****
>
> Hi Reza, welcome back! Linda is busy with JPA today so let me try to
> answer your questions...
>
> Reza Rahman wrote on 05/26/11 02:36 PM:
>
> ****
>
> Linda,
>
> Overall, this is a good start. At the same time though let me state
> up-front two
> concerns:
>
> Firstly, I hope all of this is implemented in away that does not effect
> developers of simple applications that do not require cloud support and
> never
> will.****
>
>
> Yes, that's our goal.
>
> > Secondly, I hope the cloud support does not take up so much bandwidth for
>
> ****
>
> the Java EE 7 JSRs that more mundane but equally/more important things get
> put
> in the back-burner.****
>
>
> Right now I'm more concerned about the reverse. We have a pretty good
> handle
> on what's required for all those more "mundane" things, whereas "cloud
> support"
> is still pretty amorphous. There's a tendency to work on the problems we
> understand instead of the hard problems we don't yet understand. Clearly
> it's
> the latter where we're looking for the most help from the expert group.
>
>
> ****
>
> Specific comments on the document:
> * I was left wondering about the specifics of how a tenant ID get's
> established
> in the first place. While it might not be possible to spec that out
> completely,
> it might be a good idea to have some guidelines so that vendors don't
> diverge
> far beyond effective future collaboration.****
>
>
> Right now my feeling is that there's a number of different ways this could
> be done, and it won't matter to the application which one is chosen, so
> there's
> no need to overly constrain the solution. If you have a specific scenario
> that you're worried about, let us know.
>
>
> ****
>
> * I think it is best not to make cloud support the default platform
> behavior but
> rather something that is enabled specifically. If this really becomes
> cumbersome
> in the future because a majority of applications are on the cloud, we can
> always
> make it the default later. Going the other way round if cloud computing
> turns
> out to be just another over-hyped, vendor-driven bust with limited
> practical
> applicability is going to be difficult I think.****
>
>
> Our current thinking is that an application is going to have to explicitly
> say "I'm designed for the cloud environment". When we understand
> everything
> that that implies, we might change our mind.
>
>
> ****
>
> * I prefer readable Java identifiers to abstruse UUIDs :-).****
>
>
> We want a tenant ID to be usable as a database primary key, a file name,
> etc.,
> so I think we only need to constrain the ID sufficiently to make it usable
> in this way.
>
>
> ****
>
> * I definitely think cloud support should be optional or at least not added
> to
> the Web Profile.****
>
>
> Yes, we expect most of the cloud support to be optional for the entire
> platform. A Java EE 6 product that provides no cloud support should be
> able to be updated to support all the other things in Java EE 7 without
> also having to explicitly support the cloud environment. It may need to
> understand things about the cloud environment so that it can safely ignore
> them, or provide nop or trivial implementations of them, but it shouldn't
> be required to actually run in a cloud environment.
>
>
> ****
>
> * It's difficult to make a call on ignoring the cloud settings without
> looking
> at the overall cloud solution in detail. For now, I would say
> implementations
> that do not support the cloud should simply ignore the cloud settings. This
> would also make development on local machines that need not support the
> cloud
> easier while the application can maybe later deployed to a cloud enabled
> server
> for testing, production, etc.****
>
>
> Right, we need to get further into the details before we can decide this.
>
>
> ****
>
> * Multi-tenancy comes in a very wide array of facets -- the same
> application
> deployed to different machines with tenant-specific configuration talking
> to a
> tenant-specific database, Multiple tenants using the same application but
> going
> to tenant-specific databases, multiple tenants using the same shared
> database,
> and so on. It would be important to get those details hashed out centrally
> and
> propagate it to the different JSRs as opposed to different JSRs coming up
> with
> their own solutions. In this case, if we don't do that chaos might ensue
> :-).****
>
>
> Yes, that's the kind of thing we'll need to discuss further.
>
> ****
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com****
>
> Version: 10.0.1375 / Virus Database: 1509/3663 - Release Date: **05/27/11
>
> ******
>
> ** **
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal>|
> Blog <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
> JUG <http://www.parisjug.org/>****
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1375 / Virus Database: 1511/3675 - Release Date: **06/02/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 <http://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"****
>
> ****
>
> ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
>
>
> ****
>
> ** **
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter<http://twitter.com/agoncal>|
> Blog <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
> JUG <http://www.parisjug.org>****
>
> ** **
> ------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1382 / Virus Database: 1513/3705 - Release Date: **06/15/11*
> *****
>
> ** **
>
> ** **
>

-- 
 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)