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
>