+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 <http://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 <http://www.parisjug.org/>
JUG
_____
No virus found in this message.
Checked by AVG - www.avg.com <http://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 <http://www.antoniogoncalves.org> site | Twitter
<http://twitter.com/agoncal> | Blog
<http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
<http://www.linkedin.com/in/agoncal> | Paris <http://www.parisjug.org> JUG
_____
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