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).
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.
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.
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.
What are the concepts we have in this regard?
LieGrue,
strub
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.