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