zurück zum Artikel

16 Cloud-Angebote finden sich derzeit auf Oracles zentraler Cloud-Website. Eines haben alle gemeinsam: Sie basieren auf den als Plattform-Services bezeichneten Angeboten des WebLogic-Anwendungsservers und der Oracle-Datenbank.

Verhöhnte Oracle-Chef Larry Ellison das Cloud-Thema lange Zeit, hat sich das Bild mittlerweile deutlich geändert: 16 Cloud-Angebote finden sich derzeit auf der zentralen Cloud-Website [1] des Softwarekonzerns. Dabei ist es nicht immer einfach, den Überblick über verfügbare oder nur angekündigte Angebote zu behalten. Eines haben alle gemeinsam: Sie haben die als Plattform-Services bezeichneten Angebote des WebLogic-Anwendungsservers und die Oracle-Datenbank zur Grundlage.

Grundsätzlich gliedert sich Oracles Cloud-Angebot in vier Bereiche. Am oberen Bildrand (vgl. Abb. 1) stehen die fertigen Anwendungen. Neben Enterprise Resource Planning (ERP), Financial Reporting, Planning und Budgeting gehören Talent Management, Human Capital Management, Sales and Marketing sowie ein Customer-Service- und Support-Angebot zum Bereich "Application Services". Es handelt sich hierbei um SaaS-Angebote (Software as a Service) aus dem Fusion-Applications-Bereich.

Im Bereich "Social Services" findet man weitere SaaS-Produkte in Form des Oracle Social Network, Angeboten zum Social Marketing und Monitoring sowie einer Analytics-Anwendung. Die "Common Infrastructure Services" bieten Infrastrukturdienste wie Storage und Messaging an, die sich in Richtung Infrastructure as a Service (IaaS) entwickeln.

Der Begriff "Plattform Services" bezeichnet den Java- sowie den Datenbank- und Entwickler-Service. Bei beiden handelt es sich der Definition nach um sogenannte Platforms as a Service (PaaS). Alle genannten Dienste setzen auf der auch unter dem Begriff "Cloud Application Foundation" bekannten technischen Grundlage für Oracles Middleware auf.

Dieses Hintergrundwissen hilft beim Verstehen der Angebote. Was in vielen schillernden Begriffen und Kästchen jedoch daherkommt, ist nur unwesentlich mehr als eine mandantenfähige Version von Oracles beiden Exa-Appliances: genauer Exalogic, die Kombination aus Middle-, Hard- und Software, und deren Exadate genannte Datenbank-Version. Beide empfiehlt Oracle seinen Kunden, wenn es um den Aufbau einer privaten XaaS-Anwendung im Unternehmen geht.

Beim derzeitigen Hype rund um die sogenannten PaaS-Produkte ist es nicht verwunderlich, dass Oracle gerade dieses Angebot als erstes an die Kunden ausgerollt hat. Wer den Service ausprobieren möchte, kann sich für eine 30-tägige Probephase anmelden, in der eine eingeschränkte Variante kostenlos zur Verfügung steht. Ein "Try it"-Knopf oben rechts auf der Webseite des Java Cloud Service [2] führt den Anwender direkt zu einer Registrierungs-Webseite.

Die Testversion umfasst eine Managed-Instanz mit 1,5 GByte Java-Heap und 5 GByte Datentransfer. Ebenfalls enthalten ist eine auf 1[]GByte Daten sowie 6 GByte Transfervolumen begrenzte Testversion des Database Cloud Service im selben Zeitraum. Voraussetzung für die Nutzung ist ein Benutzerkonto auf Oracle.com. Hat man bereits einen Account, sind es nur vier Schritte bis zur Registrierung (s. Abb. 2).

Aktivieren und Funktionen

Reinkommen und verwalten

Neben den Kontakt- sind leider Kreditkarteninformationen zu hinterlegen, die laut Oracle zum Sicherstellen der Identität dienen. Fakt ist, dass nach dem Ablauf der Testphase der Account nicht mehr zugängig ist und nicht automatisch verlängert wird. Zumindest war das beim Autor bisher immer der Fall. Normalerweise wird nach wenigen Minuten per E-Mail eine Bestätigung mit einem Aktivierungs-Link versendet. Erst nach Klick auf diesen stehen die beiden Services wirklich zur Verfügung und man kann sich auf Oracles Cloud-Seite anmelden. Passwort und Identity Domain werden dem Anmelder nach der Aktivierung per E-Mail zugeschickt. Die Anmeldung mit dem Oracle.com-Benutzernamen ist hingegen nicht möglich. Grund hierfür sind die unterschiedlichen Identity-Management-Infrastrukturen.

Zur Bedienung über das Web-Interface gibt es vier Bereiche: "My Services" enthält eine Übersicht aller aktiven Dienste eines Accounts (s. Abb. 3) und ist allgemein für die Aufgaben rund um die Verwaltung der Services gedacht.

Neben den eigentlichen Diensten und den Informationen über die Auslastung werden hier Details zu den einzelnen Services (SFTP User, Administration, weitere Informationen) und Links zu den Service-Konsolen angeboten – dazu später mehr. Der Bereich "My Account" liefert buchhalterische Einzelheiten wie Bestellnummern, Kosten, Buchungen, Status der Services und Adressen der Ansprechpartner (s. Abb. 4). Darüber hinaus lassen sich hier neue Dienste erwerben.

Für die Zugriffsberechtigungen ist die sogenannte "Identity Console" zuständig (s. Abb. 5). Mit ihr lassen sich die Nutzer der kompletten Identity Domain verwalten. Damit ist auch klar, warum die Information schon bei der Anmeldung benötigt wurde. Eine Identity Domain kann beliebig viele Services enthalten, und die in ihr registrierten Dienste bekommen so eine zentrale Nutzerverwaltung.

Abschließend fehlen noch die beiden Service-Konsolen für den Java- und den Datenbank-Service (Abb. 6 und 7). Die Konsole für die Datenbank ist eine APEX-Anwendung (Application Express) und bietet schnellen Zugriff auf grundlegende Funktionen. Neben eigenen APEX-Anwendungen lässt sich mit dem SQL Workshop, der zentralen Komponente der APEX-Werkzeugsammlung, die Datenbank administrieren. Der eingebaute Objekt-Browser, die SQL-Kommandozeile, der Skript-Import und auch ein Tool zum Erstellen von RESTful-Services direkt aus der Datenbank heraus sind recht einfache kleine Werkzeuge, mit denen man die alltäglichen Aufgaben in den Griff bekommt.

Die Java Console sieht vollständig anders aus. Nicht mehr ganz so sorgfältig visuell aufbereitet, springen dem Anwender diverse Tabellen und Diagramme ins Auge. Neben dem Deployment und dessen Umkehrung, Starten beziehungsweise Stoppen von Anwendungen und der Anzeige der Verfügbarkeit lassen sich hier die Logfiles der Instanzen anschauen oder herunterladen. Auf den ersten Blick scheint alles viel zu klein, um hilfreich zu sein. Tatsächlich bietet die mit ADF (Application Development Framework) arbeitende Oberfläche nicht wirklich viel Komfort, weshalb sie sich für alltägliches Arbeiten mit der Cloud kaum eignet. Schon aufgrund der vergleichsweise langen Ladezeiten und der sich ständig aktualisierenden Teilbereiche bereitet die Arbeit mit ihr keinen Spaß.

Um Anwendungen in die Java-Cloud zu auszurollen, gibt es unterschiedliche Herangehensweisen. Die im Browser zu öffnende Schnittstelle ist nur eine davon (s. Abb. 8). Der zentrale Aspekt für die Entwicklung ist das Java Cloud Service Software Development Kit (SDK).

Es lässt sich direkt von Oracles Technology Network (OTN) kostenlos herunterladen [3] und steht unter der sogenannten OTN License. Das SDK besteht aus Kommandozeilen-Wrapper, diversen Ant-Tasks und Maven-Plug-in. Darüber hinaus stellt es eine Java-API für die Administration des Services zur Verfügung, die unter anderem bei den IDE-Integrationen zum Einsatz kommt.

Die Administration des Java-Service hinterlässt einen durchaus gemischten Eindruck. Spannender sind die tatsächlichen Inhalte des Angebots. Die Instanzen des Java-Cloud-Service laufen als virtuelle Maschinen auf Exalogic Compute Nodes (vgl. Abb. 9). Pro Java-Service ist eine WebLogic-Domain mit Cluster-Konfiguration vorhanden. Die Managed Server laufen jeweils auf unterschiedlichen VM-Instanzen, um eine entsprechende Verfügbarkeit zu gewährleisten – das allerdings nur bei den teureren Angeboten, die mehr als eine Managed-Server-Instanz anbieten. Damit sind die einzelnen Java-Cloud-Services über den Hypervisor vollständig voneinander getrennt, und ein ungewollter Zugriff zwischen Kunden ist somit weitgehend ausgeschlossen.

Als Java EE Server wird WebLogic 10.3.6.0 verwendet. Er läuft auf Oracles JVM JRockit (R28.2.0). Konkreter bedeutet das, dass sich auf dem Java-Cloud-Service nur mit Java EE 5 konforme Java-6- Anwendungen betreiben lassen. Damit bietet Oracle seinen Kunden einen Spezifikationsstandard an, der deutlich in die Jahre gekommen ist. Darüber trösten auch die punktuell verfügbaren Erweiterungen für Java EE 6 (JSF 2.0, JPA 2.0 und JAX-RS 1.1) nicht hinweg. Schlimmer ist lediglich die Tatsache, dass bestimmte APIs vollständig entfernt wurden. So ist unter anderem die Verwendung der meisten weblogic.*- und com.bea.*-Pakete nicht möglich, EJB 2.x Entity Beans werden nicht unterstützt, Deployments auf Basis der Java EE Connector Architecture (JCA) sind nicht möglich, und auch mit Java Message Service (JMS) arbeitende Anwendungen lassen sich nicht betreiben. Eine vollständige Liste der nicht unterstützten Funktionen ist online verfügbar [4]. Aber auf Seiten der Oracle-Techniken findet man Erweiterungen im Angebot. So wird ADF 11.1.1.6 teilweise unterstützt. Ausnahmen bilden hier die Gegenstücke zu den serverseitig nicht unterstützten Funktionen wie ADF MBeans, ADF Data Controls for JMX und ähnliche.

Einsatz und Fazit

Frisch ans Werk

Um mit der Testversion des Service möglichst schnell starten zu können, empfiehlt sich eine der Oracle- eigenen Entwicklungsumgebungen. Am Beispiel des aktuellen NetBeans 7.3 [5] lässt sich der Ablauf am einfachsten nachvollziehen: Nach dem Download und der Installation ist zuerst das Oracle-Cloud-Plug-in zu installieren, da es nicht mehr automatisch mit ausgeliefert wird. Über Tools | Plugins | Available Plugins lässt sich "Oracle Cloud" (Version 1.3.0.1.1) auswählen und installieren. Danach kann man im Reiter "Service" mit der Option "Cloud" per Rechtsklick eine neue Oracle-Cloud-Instanz hinzufügen. Hat man die relevanten Informationen in die drei Dialoge eingegeben, erscheinen zwei neue Service-Einträge: die "Oracle Cloud" direkt unter dem "Cloud"-Knoten und ein Eintrag "Oracle Cloud Remote" unter "Servers" (vgl. Abb. 10).

Von hier an geht das Entwickeln vergleichsweise leicht von der Hand. Einfach eine beliebige Java- EE-5-Anwendung im Rahmen der technischen Möglichkeiten aussuchen, im Einstellungen-Dialog des Projekts den entsprechenden Server "Oracle Cloud Remote" wählen und die Anwendung via Rechts-Klick | Run ausführen. NetBeans übernimmt im Hintergrund alles Weitere. Die Anwendung wird zuerst auf die Cloud-Instanz geladen und im Anschluss eingespielt. Parallel dazu erfolgt ein Viren- und der obligatorische Whitelist-Scan. Für alle drei Schritte kann man die Logfiles entsprechend ansehen. Für solche Aktionen ist wiederum der Eintrag "Oracle Cloud" auf dem "Services"-Reiter zuständig. Per Rechtsklick gelangt man zu den Job- und Instanz-Logfiles (vgl. Abb. 11).

Anschließend öffnet der Browser die in der Cloud deployte Anwendung. Dazu erscheint standardmäßig erst einmal ein Login-Dialog. Der Grund ist einfach: Per Standardeinstellung sind alle ausgerollten Anwendungen nur den in der Identity Domain registrierten Anwendern zugänglich. Will man zusätzlich anonyme Zugriffe zulassen, ist ein leeres <login-config/>-Element in die Datei web.xml aufzunehmen. Soweit funktioniert alles vergleichsweise reibungslos. Etwas komplizierter ist die Einbindung der Funktionen von Java EE 6. Hierfür sind der Anwendung in der herstellereigenen weblogic.xml-Datei entsprechende Bibliotheksreferenzen mitzugeben. Um eine JSF-2-Anwendung bereitzustellen, ist also die entsprechende Bibliothek dort nach folgendem Muster einzubinden:

<library-ref>
      <library-name>jsf</library-name>
      <specification-version>2.0</specification-version>
      <exact-match>true</exact-match>
</library-ref>

Das entsprechende Mapping des Faces Servlets vorausgesetzt, kann man jetzt eine einfache ManagedBean schreiben und den Versions-String der JSF-Referenzimplementierung Mojarra ausgeben
lassen:

public String getVersion() {
       Package jsfPackage = FacesContext.class.getPackage();
       String implTitle = jsfPackage.getImplementationTitle();
       String implVersion = jsfPackage.getImplementationVersion();
       String implVendor = jsfPackage.getImplementationVendor();
// returns Mojarra Sun Microsystems, Inc. 2.0.2-SNAPSHOT
       return implTitle + " " + implVendor + " " + implVersion;

 }

Analoges gilt für die anderen einsetzbaren Java-EE-6-Spezifikationen. NetBeans übernimmt in diesem Fall die Kommunikation mit der Cloud, und bei halbwegs stabiler und guter Anbindung merkt man lediglich die zusätzlichen Schritte. Gerade bei kleinen Anwendungen fällt der Upload nicht ins Gewicht. Arbeitet man mit größeren Deployments, wird es unhandlich. Dafür empfiehlt Oracle die lokale Verwendung eines WebLogic-Servers. Deployments dürfen bis zu 95 MByte groß sein, was für die Mehrzahl der Anwendungen ausreichend sein sollte.

Fazit

Die Oracle Java Cloud hinterlässt einen gemischten Eindruck. Das Wissen um die sündhaft teure Hardware und den bekannten und etablierten WebLogic-Server steht in direktem Gegensatz zu den eingeschränkten Funktionen und der teilweise lieblos ausgestatteten Oberfläche. Technisch ist die derzeitige Version für den reinen Java-EE-Entwickler nicht attraktiv, da niemand mit derart veralteten Werkzeugen arbeiten möchte. Für bestehende Oracle-Kunden eröffnet sich hier allerdings ein attraktives neues Feld: Ihnen ist es vergleichsweise einfach möglich, die im Haus vorhandenen Anwendungen mehrheitlich ohne Änderungen auf einen Ansatz mit Cloud-Anbindung umzustellen.

Markus Eisele [6]
ist Principal IT Architect bei der msg systems AG in München sowie Mitglied in Java EE 7 Expert Group, JCP und iJUG e.V sowie Oracle ACE Director. (jul [7])

URL dieses Artikels:
https://www.heise.de/-1866388

Links in diesem Artikel:
[1] http://cloud.oracle.com
[2] https://cloud.oracle.com/mycloud/f?p=service%3Ajava%3A0
[3] http://www.oracle.com/technetwork/topics/cloud/downloads/index.html
[4] http://docs.oracle.com/cloud/CSJSU/feat_implement.htm#BCEDJIAE
[5] http://netbeans.org/community/releases/73/
[6] http://blog.eisele.net
[7] mailto:jul@heise.de

Copyright © 2013 Heise Medien