Thanks Linda, answers below.
LieGrue,
strub
----- Original Message -----
> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> To: Mark Struberg <struberg_at_yahoo.de>
> Cc: "users_at_jpa-spec.java.net" <users_at_jpa-spec.java.net>
> Sent: Tuesday, May 29, 2012 10:59 PM
> Subject: Re: [jpa-spec users] EE7 PaaS 'tenent' term question
>
> Hi Mark, all,
>
> On 5/28/2012 11:16 PM, Mark Struberg wrote:
>> Hi Linda et al!
>>
>> I've now read through quite a few of Oracles EE7
>> PaaS/SaaS documents and I think I now have at least an idea about what
>> could have been my problem understanding it.
>>
>>
>> My problem with
>> all those discussions is mostly about the terminus 'tenant' in this
>> respect. This is actually a pretty well coined term in my surrounding,
>> but the meaning seams not to fit the meaning which it is used for in the
>> EE7 specification.
>>
>> I try to lay out what I understood and please correct me if I got things
> wrong - txs.
>>
>> EE7
>> aims to use the Java EE platform for PaaS providers. My personal
>> opinion is that this is almost like buzzword-bingo and it's not that
>> important for 98% of all Java EE users, but let's take this apart for a
>> moment as this is on the manager/salesman roadmap it seems. It's at
>> least a complete contrary step to EE6 which aimed for
> 'simplification'
>> (and thus was very successful imo).
>
> Well, I have to disagree, especially given that a number of the
> facilities we are adding to support use in cloud environments also
> apply to non-cloud environments as well and contribute to ease-of-use
> -- e.g., the resource definition metadata. We are also trying to
> better align ease-of-use functionality offered by some components more
> broadly across the platform. While the focus of the EE 7 JSR itself
> needs to be on the platform as a whole, many of the component JSRs are
> also adding features that aim to enhance and/or simplify application
> development.
[strub]
Thanks for clarifying. I'm sure there will be plenty of well worthy additions to the JPA and other specs.
My opinion above was purely targeting the PaaS core feature itself.
Reading through a few Oracle PaaS documents and the EE7 spec preview gave me the impression that the goal is to create an EE7 server which is capable to serve as PaaS out of the box. Not via starting new JVMs for each 'tenant' but directly in the EE contaier. Similar to dynamically adding a webapp you could then dynamically add a new tenant and his apps to the EE container. Obviously/fortunately I got this wrong. I will try to further dig through documents to find out how this should work instead.
>
>> Nontheless, according to the EE7
>> PaaS documents, the classic scenario is a company A which offers a PaaS
>> to a 'customer' B which buys the Platform services to serve _his_
>> customers C which in turn could have customers D themselfs as well. The
>> EE7 PaaS documents now only call B as 'tenant'. And this is where
> the
>> tenant term of EE7 doesn't fit most classical definitions.
>>
>
> There are too many layers here. A customer (B) of a PaaS environment
> may deploy an application for its own use and/or B may offer such an
> application for the use of other customers. We refer to such
> customers of the application as "tenants". [In the trivial case,
> B could be regarded as its own tenant.] An application instance
> that is deployed for a tenant may be accessed by the end users of that
> tenant's organization.
[strub]
That's the point. As far as I've read it, the PaaS documentation only calls B a 'tenant', not C, not D. Only the one who installs his application to the PaaS server - regardless if he is using it for himself or for serving other people. So I agree that it's not about 'application managed tenancy' as you call it, but purely about the one who buys a platform service.
>> In
>> my original understanding a 'tenant' is a 'role + branding
> layer' of an
>> _application_. E.g. back in 2005 we programmed (and for some operators
> also hosted)
>> Napster.mobile for 80++ cellphone companies. Each cellphone company was a
>> 'tenant' for us - with it's own branding and data view. And
> sometimes a
>> single cellphone provider even had multiple sub-tenants (MVNO virtual
>> operators, prepaid business, etc). The classical 'tenant' term is
> imo
>> much more business/application oriented. A classical 'tenant' is
> also
>> most times used to define 'exceptional behaviour' with a well
> defined
>> default-behaviour as fallback. I would not have liked it to import 50
>> million tracks and 35 TB songs for EACH of our 'tenants'. This
> stuff is
>> simply shared if no special overriding rule applies to the specific tenant
> ...
>>
>>
>>
>> Back to the EE7 platform as a whole (all
>> is still true for JPA as well). Most PaaS providers atm deliberately
>> provide the isolation at the operating system level. E.g. via virtual
>> machines, Xen, kvm, etc. Or they just start another tomcat/EE-server for
>> their customers. Most times simply because doing proper security
>> hardening is MUCH easier with such a strict isolation. Or they provide a
>> deliberately cut down subset of a few APIs and nothing else (like GAE).
>>
>> Running
>> an EE server as PaaS and giving someone free access to deploy any
>> application he wants to a _shared_ EE server might become either a.) a
>> huge security problem, or b.) a huge performance problem (caused by
>> excessive security) and c.) a huge testing problem.
>>
>
> And we are certainly not requiring this (for the reasons you cite).
>
>> Up to now
>> _tons_ of projects/tools are pretty edgy and use lots of 'hardcore'
>> tricks to get their work done. E.g. taking a JAR and doing bytecode
>> analyzing and dynamic Class modifications instead of going via java.lang
>> ClassLoader reflection (mostly just to prevent blasting up the PermGen
>> space). And tons of other stuff you see when digging deeply into some
>> containers. There is more of that stuff around than most people think...
>> All this stuff would most probably not work anymore in a tightly
>> secured environment! The EE server would basically need to be completely
>> paranoid when it comes to customer code. Until now we are pretty
>> relaxed - because we know _exactly_ what runs on our servers! (Or we
>> don't care because the JVM/OS is strictly isolated)
>>
>>
>> Back to the database. I'm not worried about dynamically creating
> EntityManagerFactories - I'm more worried about securing them.
>>
>
> Um, can you be more specific? In Java EE 7, our model is still
> single-application-instance-per-tenant, so it is not assumed that
> entity manager factories would be shared across tenants, unless
> the application itself were managing multitenancy ("application-managed
> Saas") in my earlier terminology. Some JPA vendors support this
> today, and there has been some discussion in this group as to
> whether we should build in any support in JPA 2.1 to standardize on
> any of this. That is still a TBD.
[strub]
if there is no way to access the PU of another tenant, then all is fine.
>> What are the concepts we have in this regard?
>>
>> LieGrue,
>> strub
>>
>
> LieGrue, and thanks again for posting,
>
> -Linda
>
>>
>> PS: sorry that it took me so long to answer, but I'm pretty loaded at
> $$dayjob atm
>> PPS: will answer the mail regarding @Index meta-annotation after a few
> meetings.
>