Über den Wolken: Java EE und die Cloud

API Changes – Teil 1

So weit, so gut. Es bleibt aber nach wie vor die Frage offen, welche Auswirkungen die oben beschriebenen Erweiterungen der Java-EE-Spezifikation auf die in ihr zusammengefassten Technologien haben werden. Schaut man sich einmal den aktuellen Stand der entsprechenden JSRs an, so fällt auf, dass einige davon scheinbar keine oder kaum Cloud-spezifische Änderungen mit sich bringen. Auf andere Spezifikationen dagegen hat das neue Konzept einen deutlich stärkeren Einfluss. Als Beispiel einer solchen Spezifikation wollen wir uns einmal die zukünftige JPA-Version 2.1 anschauen. Wie bereits oben beschrieben, wird es auf Anwendungsebene einen Mandanten pro Applikation geben. Aber wie sieht es mit der Datenbank aus? Generell sind hier drei unterschiedliche Szenarien denkbar:

  1. Eine DB pro Mandant
  2. Eine gemeinsame DB für alle Mandanten und ein Schema pro Mandant
  3. Eine gemeinsame DB und ein gemeinsames Schema für alle Mandanten

Im ersten Szenario müsste der JPA-Provider in Abhängigkeit der aktuellen Tenant ID die korrekte DataSource auswählen, um so den Zugriff auf die richtige Datenbank zu garantieren. Im zweiten Szenario gilt in etwa das gleiche, nur eben auf Basis des Schemas. Hier stellt sich allerdings die Frage, ob zusätzlich ein gemeinsames Schema unterstützt werden sollte, in dem sich Daten befinden, auf die alle Mandanten zugreifen dürfen. Das dritte Szenario setzt implizit voraus, dass jede Tabelle über eine zusätzliche Spalte verfügt, die angibt, zu welchem Mandanten der Datensatz gehört. Der JPA-Provider müsste in diesem Szenario bei jeder Abfrage automatisch eine entsprechende WHERE-Clause hinzufügen.

Nach aktuellem Stand der Spezifikation werden zukünftig mindestens die ersten beiden Szenarien durch JPA 2.1 unterstützt. Das dritte Szenario dagegen sollte zunächst einmal außen vor bleiben. Wer die Philosophie von Larry Ellison zum Thema Multi-Tenancy kennt – er hält ein Konstrukt wie in Szenario 3 beschrieben für nicht brauchbar – wundert sich darüber sicherlich nicht. Es scheint aber mittlerweile so, als ob auch das dritte Szenario ausreichend Freunde in der Expert Group gefunden hätte und daher eventuell nun doch mit in die Spezifikation einfließen könnte. Im Zuge der oben beschriebenen Erweiterungen sollen übrigens auch das Generieren von Schemata und der initiale Datenimport in JPA standardisiert werden.

API Changes – Teil 2

Einen ähnlich starken Einfluss auf die zukünftige Ausrichtung der APIs wird „the Cloud“ auf den Bereich der Security haben. Sollen mehrere mandantenspezifische Anwendungen parallel in einem Server laufen, stellt dies natürlich erhöhte Anforderungen an die Sicherheit. Mithilfe eines selbst zu installierenden Security-Managers soll der Cloud-Provider zukünftig beispielsweise File- und Netzwerkzugriffe gezielt kontrollieren können. Natürlich geht das auch bereits heute schon. Allerdings stellt der Security-Manager derzeit etwaige Zugriffsverletzungen erst zur Laufzeit fest, was wiederum unschöne Security Exceptions zur Folge haben kann. Problematisch an diesen Exceptions ist vor allem die Tatsache, dass sie mit hoher Wahrscheinlichkeit nicht zur Entwicklungszeit – und eventuell auch nicht während der Integration Tests – auftreten, da in diesen Umgebungen häufig andere Security-Einstellungen vorliegen. Um dieses Problem zu beheben, wird es ab Java EE 7 möglich sein, einer Anwendung deklarativ die von ihr benötigten Rechte mitzugeben. So kann bereits während des Deployments geprüft werden, ob der installierte Security Manager diese gewährt oder nicht.

Missing Pieces

Wie es scheint, tut sich also einiges in der neuen Java-EE-Spezifikation hinsichtlich „the Cloud“. Aber ist damit bereits das Ende der Fahnenstange erreicht? Mitnichten. Schaut man sich einmal in den einschlägigen Foren um, geht der in Java EE 7 skizzierte Cloud-Ansatz vielen entschieden nicht weit genug. Wichtige Themen wie Service Level Agreements, Quality of Service Elasticity, Self-Adjustment oder Capacity on Demand bleiben in der aktuellen Spezifikation noch vollständig außen vor. Gleiches gilt für Versionierung und Modularisierung, was als direkte Folge der Verschiebung von Project Jigsaw in das JDK 8 zu verstehen ist.

Fazit

Nach Single-Node-Servern und Server-Clustering scheint Java EE in der Cloud der nächste logische Schritt zu sein. Die neue Spezifikation der Java Enterprise Edition bereitet dafür das Feld und erlaubt das Deployment von mandantenfähigen Anwendungen. Dass dies nur ein erster Schritt sein kann, wird deutlich, wenn man die doch sehr begrenzten Möglichkeiten der Spezifikation mit dem Bedarf in der Realität abgleicht. Java EE 7 ist daher eher als erstes Cloud-Zwischenrelease anzusehen. Richtig spannend wird es wohl erst mit Java EE 8. In diesem Sinne: Stay tuned…

Lars Röwekamp ist Geschäftsführer der open knowledge GmbH und berät seit mehr als zehn Jahren Kunden in internationalen Projekten rund um das Thema Enterprise Computing (Twitter: @mobileLarson).

Matthias Weßendorf arbeitet für die Firma Kaazing. Dort beschäftigt er sich mit WebSocket, HTML5 und weiteren Themen rund um das Next Generation Web. Er bloggt regelmäßig auf http://matthiaswessendorf.wordpress.com (Twitter: @mwessendorf).

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.