Application Express Community
Application Express Community
| Erscheinungsmonat | APEX-Version | Datenbankversion | Cloud oder on Premise |
| November 2015 | 5.0 | 11.2 und 12.1 | Oracle-Cloud |
Cloud Computing ist in aller Munde - die Oracle-Datenbank und damit Application Express stehen seit einiger Zeit in der Oracle Cloud zur Verfügung. Für APEX- und PL/SQL-Entwickler ist die Oracle Cloud eine sehr interessante Möglichkeit, schnell und einfach an eine laufende Datenbank oder einen laufenden APEX-Workspace zu kommen. Die Cloud kann dies in der Regel innerhalb kurzer Zeit bereitstellen - vergleicht man dies mit dem Alltag im Unternehmen, wo für eine Datenbank oder ein Schema nicht selten Tage oder Wochen vergehen, so lässt sich erahnen, wie flexibel und schnell man mit der Cloud werden kann.
Abbildung 1: Oracle Cloud: Database as a Service
APEX läuft komplett in der Datenbank - das ist weithin bekannt. Da in der Cloud die gleiche Datenbanksoftware läuft, wie im "heimischen Rechenzentrum" (On Premise), läuft eine APEX-Anwendung in der Cloud auch exakt genauso. Dieser Community-Tipp stellt die Datenbank-Services der Oracle Cloud vor - diese können unter cloud.oracle.com im Bereich Platform und dort unter Data Management gefunden werden.
Die Oracle Cloud bietet prinzipiell zwei Datenbank-Dienste an: Database Schema Service und Database as a Service.
Abbildung 1: Oracle Cloud: Database as a Service und Database Schema Service
Abbildung 2: Oracle Cloud: Database Schema Service
Abbildung 3: Oracle Cloud: Database as a Service
Oracle Cloud: Database Schema Service
Wie bereits eingangs erwähnt, abonniert man mit dem Database Schema Service ein Datenbankschema und einen APEX-Workspace. Die APEX-Umgebung selbst, bestehend aus Betriebssystem, Datenbank und Webserver, wird von der Oracle Cloud bereitgestellt. Zugriff auf den Dienst kann man mit Application Express selbst, dem SQL Developer oder mit REST-Webservices nehmen. SQL*Net ist abgeschaltet; Zugriffe mit SQL*Plus, der Oracle Data Pump oder anderen Client-Werkzeugen sind bei diesem Service also nicht möglich. Auch können native Treiber wie JDBC, ODP.NET oder node-oracledb, mit dem Database Schema Service nicht verwendet werden.
Abbildung 4 zeigt die Konsole für den Database Schema Service nach der Anmeldung. Ein Klick auf Service Instance URL bringt den Nutzer zur APEX Homepage.
Abbildung 4: Oracle Cloud: Konsole für Database Schema Service
Was die Arbeit mit APEX angeht, so fühlt sich der Database Schema Service genauso an, wie jede andere APEX-Umgebung: Im Application Builder erstellt man Anwendungen, der SQL Workshop erlaubt das Arbeiten mit Datenbankobjekten wie Tabellen, Views oder PL/SQL Prozeduren und Team-Development bietet einfache Werkzeuge zur Koordination kleinerer Projekte an. Auch alle Packaged Applications stehen zur Verfügung; der Database Schema Service lässt sich also auch nutzen, um Packaged Applications wie den Survey Builder, das Bug Tracking, den Application Standards Tracker oder andere bereitzustellen.
Möchte man mit dem SQL Developer auf den Database Schema Service zugreifen, so verwendet man die eigens dafür bereitgestellten Cloud Connections. Wie man an Abbildung 5 sieht, können aber nicht alle Funktionen der Oracle-Datenbank verwendet werden - die Dokumentation enthält darüber hinaus eine Liste der Datenbankfeatures, die im Database Schema Service nicht zur Verfügung stehen. Dazu zählen Oracle Spatial, Oracle TEXT, Java in der Datenbank und andere. Werden diese benötigt, muss man sich das weiter unten beschriebene Database as a Service näher ansehen.
Abbildung 5: Oracle Cloud: Erstellen einer Cloud Connection zum Database Schema Service
Besonders erwähnenswert ist der SQL Developer Cart - zwar kann dieser auch für Datenbanken im eigenen Rechenzentrum verwendet werden, beim Database Schema Service spielt er seine Fähigkeiten aber voll aus. Der Cart erlaubt es, kurz gesagt, ein SQL-Skript zum Erstellen von Datenbankobjekten - inklusive Daten - zu erstellen. Objekte wie Tabellen, Views, PL/SQL Code, aber auch APEX-Anwendungen können zum Cart hinzugefügt werden (Abbildung 6):
Abbildung 6: Datenbankobjekte im SQL Developer "Cart"
Die Objekte im Cart können dann zum Database Schema Service übertragen werden; dies geschieht über eine SFTP-Verbindung. Nach erfolgreicher Übertragung werden die Skripte dann eingespielt. So lassen sich auch mehrere APEX-Anwendungen auf einmal, gemeinsam mit SQL- und PL/SQL Objekten, in einer Operation einspielen (Abbildung 7).
Abbildung 7: SQL Developer "Cart" zum Database Schema Service übertragen
Auch wenn der Database Schema Service einen sehr starken Bezug zu APEX hat; ist die Nutzung nicht auf APEX beschränkt. Wie alle APEX-Installationen, so bietet auch der Database Schema Service die Fähigkeit zum Bereitstellen von REST-Webservices an (Abbildung 8).
Abbildung 8: REST Services mit Database Schema Service
Diese REST Services können nun mit beliebigen Clients konsumiert werden; ob dies Web-Browser mit Javascript, Java, PHP oder .NET Seiten sind, spielt keine Rolle.
Oracle Cloud: Database as a Service
Nutzt man Database as a Service, so abonniert man eine ganze Datenbank. Im Gegensatz zum Database Schema Service kann man darin so viele Schemas anlegen, wie man möchte. Man bekommt nicht nur einen DBA-, sondern auch einen Betriebssystem-Zugriff und hat so wirklich vollen Zugriff auf den (virtuellen) Server. Auf der einen Seite bringt dies natürlich viel mehr Möglichkeiten und Freiheiten, auf der anderen Seite aber auch mehr Aufgaben mit sich: Schließlich wollen die Datenbank und ggfs. der APEX-Webserver administriert sein. Als Abonnent von Database as a Service ist man dafür - im Gegensatz zu Database Schema Service - selbst zuständig, bekommt aber, wie eingangs schon erwähnt, von der Oracle-Cloud einige hilfreiche Werkzeuge zur Seite gestellt.
Abbildung 9 zeigt die Service-Konsole für Database as a Service, die man erreicht, wenn man sich auf dbaas.oraclecloud.com angemeldet hat.
Abbildung 9: Oracle Cloud: Database as a Service Konsole
In dieser Konsole kann man neue Datenbanken erzeugen, bestehende ansehen, starten, stoppen oder löschen. Klickt man auf den Namen der Instanz, so sieht man Details (Abbildung 10). In diesem Dialog ist auch der aus der Oracle-Welt wohlbekannte SQL*Net Connection String zu sehen - man sieht nochmal, dass Database as a Service eine ganz normale Datenbankinstanz bereitstellt; der einzige Unterschied ist die Tatsache, dass die Verbindung stets durch das Internet erfolgt - während die "heimische" Datenbank typischerweise im Intranet erreichbar ist. Wie weiter hinten noch beschrieben, werden die SQL*Net-Verbindungen daher typischerweise durch einen SSH-Tunnel geleitet.
Abbildung 10: Oracle Cloud: Instanzdetails Database as a Service
Erstellt man eine neue Instanz, so sieht man die vielfältigen Möglichkeiten von Database as a Service (Abbildung 11).
Abbildung 11: Oracle Cloud: Neue Database as a Service erstellen
Nach Auswahl von Datenbankversion und -Edition werden die Details des neuen Datenbank-Service festgelegt.
Abbildung 12: Oracle Cloud: Neue Database as a Service erstellen
Nachdem die Instanz erstellt wurde, kann man sich per Secure Shell (SSH) anmelden; hierzu nimmt man lediglich den privaten SSH-Schlüssel, der zu dem Public Key passt, der beim Erstellen der Instanz angegeben wurde. Ein Login am Betriebssystem mit Passwörtern ist nicht möglich. Letzlich ist das Verfahren mit dem Schlüsselpaar doch um einiges sicherer als Passwörter, es wird auch innerhalb von Unternehmen oft praktiziert. Vom Betriebssystem aus fühlt sich Database as a Service genauso an, wie jeder andere Datenbankserver.
Neben der Datenbank selbst ist auf dem System auch ein Glassfish-Server installiert, der als Webserver für Application Express und ORDS (Oracle REST Data Services) dient. Für die Arbeit mit APEX loggt man sich zuerst in den Workspace INTERNAL ein, erzeugt dort den eigentlichen Workspace und dann kann man mit der Arbeit auch schon loslegen.
Möchte man mit dem SQL Developer auf die Instanz in der Cloud zugreifen, so werden die vorhin erwähnten Cloud Connections nun nicht benötigt - diese sind allein für den Database Schema Service vorgesehen. Für Database as a Service steht SQL*Net, wie bei jedem anderen Datenbankserver, bereit. Zwar kann man den Port 1521 in der Firewall-Konfiguration freischalten; die empfohlene Variante ist aber, das SSH-Tunnel-Feature des SQL Developer zu nutzen: Hier wird das SQL*Net Protokoll durch einen sicheren SSH-Kanal geleitet; so hat man auch in den meisten Unternehmens-Netzwerken kein Problem bei der Verbindung.
Abbildung 13: Oracle Cloud: SQL*Net-Verbindung mit dem SQL Developer über SSH tunneln
Von da an unterschiedet sich die Verbindung zur Datenbankinstanz in der Cloud durch nichts mehr von einer ins lokale Rechenzentrum: Die Datenbank ist eine vollwertige Datenbank; man hat zusätzlich Zugriff auf das Linux-Betriebssystem und kann so auch Einstellungen außerhalb der Datenbank vornehmen. Das Übertragen einer APEX-Anwendung in die Cloud funktioniert dann genauso wie das Übertragen derselben von einem lokalen Datenbankserver auf einen anderen.
Übrigens bietet die Oracle Cloud für Database as a Service auch eine REST-Schnittstelle an - Abonnenten müssen also nicht zwingend das Oracle-Webinterface verwenden, um Datenbankinstanzen zu erstellen, zu bearbeiten oder zu zerstören. Mit dem REST-Interface kann die Cloud auch programmatisch angesprochen und das Erstellen einer Datenbankinstanz sogar automatisiert werden. Abbildung 14 zeigt ein Beispiel: Ein PL/SQL-Paket in der "heimischen" Oracle-Datenbank ruft den REST-Service der Oracle Cloud auf und verwaltet so die Instanzen in der Cloud.
Abbildung 14: REST Interfaces für die Oracle Cloud - ein Beispiel mit PL/SQL
Fazit
Die Oracle Cloud bietet - gerade für APEX- und PL/SQL-Entwickler, interessante Möglichkeiten an, schnell und einfach an einen laufenden Service zu kommen. Mit dem Database Schema Service erhalten APEX-Entwickler sehr einfach Zugriff auf einen APEX-Workspace und ein damit verbundenes Datenbankschema - Anwendungen können, wie man es mit APEX gewohnt ist, schnell und einfach erstellt und veröffentlicht werden. Mit der Administration oder dem Absichern bzw. Härten der Umgebung wird man nicht belastet - all diese Aufgaben übernimmt die Cloud.
Bei größeren Anforderungen ist Database as a Service interessanter - hier bekommt der Entwickler eine (oder mehrere) ganze Datenbank(en) und kann in dieser frei schalten und walten. Alle Datenbankfunktionen stehen zur Verfügung - Anwendungen können wirklich 1:1 von der "heimischen" Datenbank in die Cloud übertragen werden. Allerdings erfordert Database as a Service etwas mehr administrative Aufmerksamkeit.
Das Schöne an einem Datenbankservice in der Cloud ist die große Flexibilität, die man bekommen. In der Konsole von Database as a Service wird eine neue Datenbankinstanz unter einer Stunde erstellt, eingerichtet und bereitgestellt. Vergleicht man das mit der alltäglichen Situation in vielen Unternehmen, wo das Bereitstellen einer neuen Oracle-Instanz nicht selten Tage oder Wochen braucht, so ergibt sich eine bislang ungeahnte Flexibilität und Schnelligkeit.
Für nahezu alle Angebote gibt es ein kostenloses Test-Abonnement für 30 Tage (Trial). Sie erreichen es, indem Sie auf cloud.oracle.com auf den Button Try It oben rechts klicken (Abbildung 15).
Abbildung 15: Oracle Cloud: 30-Tage Testabonnement"
Weitere Informationen