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