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