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>