Date: Thu, 16 Jun 2011 16:18:59 +0530
If we could get both (before SE 8) that would be perfect. I agree, if you
deploy to "Stage A" (stage might be also a particular vendor's cloud [?])
there might be different requirements for what the application needs than to
"Stage B". Some of the most significant examples are stages that are used
for testing or mocking out data, although at least build environments like
Maven already tend to make a difference, e.g. keep the test code out of
production.
Real modularity will have to go even further.
Werner
On Wed, Jun 15, 2011 at 6:57 PM, Jeff Genender <jgenender_at_savoirtech.com>wrote:
> Modularity, configuration all play a significant part in PaaS or
> multi-tenancy. I wouldn't want one without the other since they are very
> inter-connected.
>
> Jeff
>
> On Jun 15, 2011, at 7:20 AM, Werner Keil wrote:
>
> I think some form of configuration management as discussed in at least one
> other thread here is far more important, than modularization.
> On Jun 15, 2011 6:11 PM, "Jevgeni Kabanov" <jevgeni_at_zeroturnaround.com>
> 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 (mailto:
> 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 (mailto: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 JUG (http://www.parisjug.org/)
> >> > > > > 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 (http://blog.adam-bien.com)
> >> > press: press.adam-bien.com (http://press.adam-bien.com)
> >> > eMail: abien_at_adam-bien.com (mailto: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)
> >
>
>
>
-- 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)