Newsletter 4/2011
Werbung
SWISS ORACLE USER GROUP www.soug.ch Newsletter 4/2011 Oktober 2011 · Aktiv/Passiv Failover Clustering · Implementierung von Web Services in Oracle DB Anwendungen · Von Oracle Forms zu Oracle ADF und JEE · SnapManager für Oracle · New Features in Oracle APEX TIPS&TECHNIQUES 11 Magdalena Serban, Bahar Us und Andreas Gaede, PITSS GmbH Von Oracle Forms zu Oracle ADF und JEE Modernisierung von Oracle Forms Anwendungen auf das Oracle Application Development Framework und die JEE Architektur. Doch zunächst einmal: Warum JEE? Warum ADF? Was spricht für den Wechsel? Oracle bietet heutzutage ein umfassendes Sortiment an Entwicklungslösungen, wobei die technischen Möglichkeiten zur Erstellung neuer Anwendungen nahezu unbegrenzt sind. Doch was geschieht mit bestehenden Legacy Anwendungen basierend auf Oracle Forms? Lassen sie sich in die neue JEE Architektur integrieren? In welchem Umfang lässt sich ein Nutzen aus den neuen Technologien ziehen und gleichzeitig das kostspielige und riskante Unterfangen vermeiden, Anwendungen ganz neu zu schreiben? Dieser Artikel geht näher auf diese Fragen ein. Des Weiteren wird ein Überblick sowohl über die Chancen als auch über die Herausforderungen geboten werden, die mit einem solchen Wechsel der Software Architektur einhergehen. Das Internet ändert unsere Geschäftsabläufe wie nie zuvor und damit auch die Anforderungen, die die Anwender an die Software haben. Die meisten Anwendungen, die wir im Laufe der vergangenen Jahre mit Forms entwickelt haben, lassen sich durch geeignete Werkzeuge meist kostengünstig auf die neuste Forms Version anheben und damit Web-fähig machen. Es gibt jedoch Szenarien in Geschäftsabläufen, die durch eine webbasierte Architektur noch besser erfüllt werden können, wie z.B. reichhaltiger gestaltete Anwenderoberflächen oder Datenhaltung in der Logikschicht usw. Für solche Szenarien empfiehlt Oracle, die Applikation gemäss der JEE Architektur neu zu schreiben und mit den restlichen Modulen auf dem Anwendungsserver zu integrieren. JEE verspricht auf lange Sicht eine leichtere Pflege der Anwendungen aufgrund von offenen Standards und vereinfachter Integration mit anderen Produkten. Allerdings erscheint JEE den Datenbankentwicklern trotz der Vorteile komplex und schwierig. Oracle Forms Entwickler (oder allgemeiner 4GL Entwickler) sind eine äusserst hohe Produktivität gewohnt, die sich mit JEE so nicht erreichen lässt. Hier ist es schwierig, Kunden die gleichen kurzen Entwicklungszeiten zu bieten, die sie gewohnt sind. Aus diesem Grund empfiehlt Oracle das Oracle Application Development Framework (ADF), um die JEE Design Pattern (Model View Controller, MVC) einfacher zu implementieren. Mit seiner visuellen, selbsterklärenden Umgebung erlaubt ADF schneller Code zu schreiben und die Entwicklungszeit zu reduzieren. Aber ist das alles wirklich so einfach, wie es scheint? Die Herausforderung: Neuentwicklung Das Rezept für ein erfolgreiches ReEngineering Projekt von Forms nach ADF lautet: Stellen Sie sicher, dass Sie über ein sehr gutes Verständnis der bestehenden und neu zu erstellenden Forms Applikation in ihrer gesamten Komplexität verfügen – Legacy Anwendungen wurden vor langer Zeit entwickelt und haben oftmals eine erhebliche Grösse und Komplexität erreicht. In vielen Fällen sind die damaligen Forms Entwickler nicht mehr im Unternehmen und die notwendigen Dokumentationen unzureichend oder überhaupt nicht vorhanden. Die Java Entwickler, welche für die Neuerstellung der Anwendung zuständig sind, tun sich oft schwer, die Komponenten, deren Verknüpfungen vollständig zu verstehen und benötigen unter Umständen Schulungen zum Verhalten der laufenden Forms-Anwendung. Eignen Sie sich umfassende Kenntnisse der neuen Technologien an und überführen Sie den bestehenden Funktionsumfang in die neue Architektur bei gleichzeitiger Verbesserung – dies ist eine anspruchsvolle Aufgabe, weil Forms und JEE von Grund auf unterschiedlich sind. Darüber hinaus ist die Migration der Applikation nur dann erfolgreich, wenn die neue Version anwendungsfreundlicher ist und über bessere technische Fähigkeiten verfügt, wie z.B. eine intuitivere Oberfläche. Es sollte schliesslich nicht das Ziel sein, dass die hohe Investition in das Modernisierungsprojekt, lediglich eine exakte 1 zu 1-Kopie der ursprünglichen Anwendung hervorbringt. SOUG Newsletter 4/2011 12 TIPS&TECHNIQUES Etablieren Sie ein Projektmanagement, um den Fortschritt der Migration zu planen und zu überwachen – Software Projekte auf Grundlage neuer Technologien scheitern oft an unvorhergesehenen Problemen, an Erfahrungsmangel und an fehlenden Implementierungsstandards. Es empfiehlt sich das Projekt kontinuierlich und gewissenhaft auf bekannte Beschränkungen im Hinblick auf Zeit, Budget und Qualität zu überwachen, um den Erfolg von Beginn an zu gewährleisten. Hinter diesen drei einfachen Zutaten werden die wirklichen Herausforderungen sichtbar: Kompetenzen Gemischtes Kompetenzprofil: Kenntnisse sowohl von PL/SQL und Forms als auch von Java, JavaScript, XML und JEE sind für ein erfolgreiches Projekt unverzichtbar. Java Kenntnisse dürften auf dem Markt einfach zu finden sein, aber der ausschlaggebende Faktor ist das Verständnis sowohl der Forms Komplexität als auch der neuen Technologie samt dessen Zielarchitektur. Anwenderoberfläche Anpassung an die Stärken und Schwächen des Internet Modells: im Gegenzug zur höheren Benutzerfreundlichkeit weisen browserbasierte Anwendungen auch gewisse Einschränkungen auf. Oracle Forms bietet eine äusserst dateneffiziente Architektur, die es möglich macht, in einem Applet Tausende von Datensätzen abzufragen, Hunderte von Feldern auf einer Seite anzuzeigen, auf Client Rechner zuzugreifen sowie Dateien via Host Anweisungen zu bearbeiten. Daher muss eine typische Forms Applikation umgestaltet werden, um in einem einfachen Browser zu laufen – etwa, indem die Datensätze in Gruppen von je 20 angezeigt, die hunderte von Feldern auf verschiedene Seiten verteilt oder die Zugriffe auf den Client Rechner verringert werden. SOUG Newsletter 4/2011 Anwendungen, die sich nicht auf diese Weise anpassen lassen, sollten durch einen Upgrade auf die neueste Forms Version angehoben werden, bis die neue Technologie dies in geeigneter Form unterstützt. Business Logik Forms Anwendungen besitzen oft eine eng verzahnte Logik, die innerhalb eines Codesegments beispielsweise Business Logik mit Aktionen der Anwendungsoberfläche, Datenvalidierung, Datenbearbeitung usw. vereint. Bei der Übertragung eines solchen Codesegments nach ADF muss die Logik in ihre Komponenten aufgetrennt und nach dem MVC Design Patter neu definiert werden, damit eine echte ADF Architektur entstehen kann. Abbildung 1: gemischte Business Logik am Beispiel eines Triggers in einer Forms Applikation Lösungsansätze für die Logik sind: Umsetzung des gesamten Codes in Java – ein solcher Ansatz wäre nur dann erfolgreich, wenn der Code zu 100% von Hand umgeschrieben würde. In einem solchen Fall ginge die gesamte Investition in der Forms Business Logik verloren. Es gibt zwar Tools auf dem Markt, die eine automatische Konvertierung des gesamten Oracle Forms Codes nach Java versprechen, aber der so erzeugte Code ist sequenziell und prozedural wie PL/SQL und nicht objektorientiert, wie Java Code eigentlich sein sollte. Ein so generierter Code enthält das gleiche Gemisch wie der ursprüngliche Code, bestehend aus Datenverarbeitung, Business Logik, Aktionen der Anwenderoberfläche oder gar Runtime-Befehle, die zu eigentümlichen, komplexen Java-Konstrukten führen. Dieser Code ist schwer verständlich und erfüllt in den meisten Fällen nicht die Erwartungen an Java konforme Codes. Eine Pflege des Java- TIPS&TECHNIQUES Codes ist selbst nach Bereitstellung der proprietär eingebrachten Elemente kaum denkbar. Der Hauptgrund, warum dies nicht als der geeignete Lösungsansatz erscheint, liegt jedoch darin, dass wir hier von Datenbankanwendungen ausgehen müssen, deren Business Logik direkt auf grosse Datenmenge angewendet wird. Somit ist ein Grossteil der Logik weit besser in der Nähe der Daten in der Oracle Datenbank aufgehoben als in der Präsentationsschicht. Beibehaltung der Business Logik in PL/SQL und Ablage in die Datenbank – der Code für Datenzugriffe oder Datenbearbeitung ist in der Regel in der Datenbank schneller und reduziert dort den Datenverkehr im Netzwerk auf ein Minimum. PL/ SQL hat sowohl in Oracle Forms Anwendungen als auch in der Datenbank alle im Laufe der Jahre angefallenen geschäftlichen Anforderungen gemeistert und wird das auch in Zukunft in gewohnt zuverlässiger, performanter Weise tun. Ein solcher Ansatz stellt eine enorme Risiko-Minimierung dar. Migriert man nach JEE, dann sind natürlich nicht alle Code Segmente zur Verwendung in der Datenbank geeignet, wie Code für die Anwender Oberfläche, Navigationscode und Feld-Validierungen. Diese sind näher an der Präsentationsschicht. 13 A N Z E I G E gloBâle Services Individuelle Softwarelösungen Business Intelligence Application Engineering Seit 10 Jahren local, in Ihrer weltweiten Nähe. The local player for global solutions [email protected] www.irix.ch Dornacherstrasse 192 CH – 4053 Basel Dank dieser tiefen Kenntnis der Applikation kann PITSS.CON die Anzahl der Forms Komponenten enorm erhöhen, die in natürlicher Form in die ADF Welt überführt werden. Die kombinierte Strategie – Code für die Anwenderoberfläche in Java, Datenbearbeitung in der Datenbank. Dies ist die Lösung, die wir klar empfehlen und im folgenden Abschnitt näher erläutern werden. T 061 367 93 33 Architektur Der grösste Teil der Business Logik (BL) in Forms gilt der Bearbeitung von Daten. Die diesbezügliche Logik gehört selbstverständlich in die Oracle Datenbank. PITSS.CON unterstützt die Transformation der datenintensiven Business Logik in die Datenbank und erzeugt dort Die PITSS.CON Lösung PITSS.CON lädt die Forms und Reports Anwendungen samt Datenbankschemata ins Repository, parst die Programmstrukturen und den gesamten Code und erstellt daraus feingranulare Metadaten mit allen applikations-relevanten Objekten und deren Abhängigkeiten. Abbildung 2: PITSS.CON Forms zu ADF Migration einen Business Logik Layer (BL Layer). Nach der Transformation des Codes von Forms und Reports in die Datenbank ist diese BL Layer nicht mehr nur SOUG Newsletter 4/2011 14 TIPS&TECHNIQUES den Oracle Forms und Reports Programmen zugänglich, sondern auch von Oracle ADF und Oracle APEX aus ausführbar oder kann als Web Service (WS) angeboten werden. Damit ist die neugeschaffene BL von anderen Technologien verwendbar und kann hinter unterschiedlichsten Oberflächen, BEPL Prozessen und innerhalb des Enterprise Service Bus ESB einer SOA seine Aufgaben wahrnehmen. Dies stellt nicht nur einen enormen Schutz Ihrer Investitionen dar, sondern steigert nachhaltig den Wert, durch Wiederverwendbarkeit und Rückführung redundanten Codes zu zentral organisierten Funktionen. Reduzierung der Wartungsaufwände, effiziente Weiterentwicklung und Oberflächenunabhängigkeit sind weitere positiv begleitende Merkmale dieses Ansatzes. Zukünftige Anpassungen oder Modernisierungsvorhaben lassen sich leichter realisieren. Das Ablegen der Business Logik in der Datenbank unterstützt den gesamten langläufigen Migrationsprozess in optimaler Weise, da der neu erzeugte, neu strukturierte und effizientere Code sowohl in der Forms wie auch in der entstehenden ADF Applikation zum Einsatz kommt. Das schrittweise Migrieren führt zu besser getestetem Code, minimiert die Migrationsrisiken und beschleunigt so den Gesamtprozess. Ein weiterer Aspekt dieses Ansatzes ist die Implementierung einer Serviceorientierten Architektur (SOA), denn im gesamten SOA Konzept geht es gerade um die Wiederverwendung und Integration von Komponenten. Die noch verbleibenden Forms Komponenten werden durch den «ADF Assistant» in das ADF MVC Pattern basierend auf ADF Faces, JSF und ADF Business Components überführt. Prozess Abbildung 3: Prozess Applikationsanalyse – der erste Schritt besteht darin, sämtliche Module ins PITSS.CON Repository zu laden, um eine genaue Analyse durchzuführen. PITSS.CON lädt in sein Oracle-basiertes Repository nicht separate XML-Versionen der Forms-Modulen sondern alle verwendeten Quelldateien: FMB, MMB, PLL, OLB, RDF, SQL usw. sowie deren Datenbank-Schemen. Alle diese «Puzzleteile» sind wichtig, um eine korrekte Anwendungsanalyse auszuführen. Abbildung 4: Typische FormsAnwendungskomponenten Abbildung 5: PITSS.CON Forms Flow Analysis SOUG Newsletter 4/2011 In dieser Phase wird die Migrationsstrategie festgelegt, die sich nach der Beschaffenheit und der Komplexität der jeweiligen Applikation sowie den Anforderungen an die Oberfläche und dem Ausmass der Anpassung an die WEB Technologie richtet. Verringerung von Redundanzen und von unbenutzten Objekten – der nächste Schritt ist die Bereinigung der Applikation von nicht genutztem Code, so dass nur noch die Kernfunktionen erhalten bleiben. Dies ist der ideale Ausgangspunkt, um wieder die Kontrolle über die bestehende Applikation zurückzugewinnen, die Applikation auf das notwendige Minimum zurückzufahren und um eine tragende Dokumentation für die Reise in die Modernisierung zu erstellen. Unserer Erfahrung nach stellt sich in diesem Schritt heraus, das mindestens 20–30% der Applikationsobjekte redundant sind, ungenutzte Tabellen, Bibliotheken, mehrfach vorhandene oder ungenutzte Code Abschnitte oder sogar komplett obsolete Funktionen, wie beispielsweise Kalenderfunktionen TIPS&TECHNIQUES 15 für ein Datumsfeld, die in der neuen JEE Umgebung nicht mehr benötigt werden. Toolgestütztes Re-Engineering von Anwendungen nach ADF – nachdem die Anwendung um den Grossteil der darin enthaltenen Business Logik bereinigt wurde, kann die Nachbildung der Anwenderoberfläche nahezu auf Knopfdruck bewerkstelligt werden. Der «ADF Assistant» erzeugt automatisch die dazugehörigen ADF Objekte: Abbildung 6: PITSS.CON Unbenutzter Objekte-Analyse-Bericht Migration von Business Logik in die Datenbank – dieser Schritt ist die Grundlage für die erfolgreiche Modernisierung hin zu einer serviceorientierten Architektur. Hierbei lässt sich mit den folgenden Hilfsmitteln viel Zeit und Geld sparen: BL Assistant – extrahiert BusinessLogik aus dem Forms und Reports Code. PITSS.CON konstruiert die Code Kette, aus der sich ein Dienst, eine Funktion oder ein Prozess zusammensetzt, und zeigt visuell auf, inwieweit der Dienst in die Datenbank migriert werden kann. Der BL Assistant führt dann die Transformation durch und setzt den neu erzeugten Code wieder in der ursprünglichen Applikation ein. Die so entstandene Datenbank-Logik steht nicht nur jeder Forms Applikation zur Verfügung, sondern auch ADF Anwendungen, und lässt sich sogar als Web Service noch breiter verfügbar machen. Web Service Wizard – stellt jede gespeicherte Funktion als Web Dienst zur Verfügung und öffnet die Applikation damit für die Aussenwelt. Application Analysis und Application Impact – ermöglichen Ihnen, schnell und präzise auszuwerten, welche Auswirkungen eine geplante Änderung hat, nicht verwendeten oder problematischen Code zu erkennen und den Übergang in eine serviceorientierte Architektur reibungsloser zu gestalten. Abbildung 7: Beispiel einer Anwendung automatisch mit PITSS.CON ADF-Assistenten migriert s Geschäftsfunktionen mit ADF Business Components; s Datenobjekte, als Unterstützung für einfacheres Aufrufen der gespeicherten Business Logik von der ADF Applikation aus; s Abschluss der Model-, Viewund Controller-Schichten MVC, Analyse aller Komponenten der Forms Applikation – Fenster, Leinwand-Elemente, Blöcke, Objekte usw. und Erstellung der dazugehörigen ADF-Objekte unter Berücksichtigung jeder einzelnen Objekteigenschaft und deren Grösse, in dem dieses Objekt im ADF angelegt wird; s Generierung von Java Methoden für die Benutzeroberfläche durch die Übersetzung der PL-/ SQL-Business Logik in Java Code, wobei automatisch die Zuordnung von Variablen und das Aufrufen von gespeicherter Business Logik über die Datenzugriffsobjekte implementiert wird. SOUG Newsletter 4/2011 16 TIPS&TECHNIQUES Nachbearbeitungs-Prozess – Das Ergebnis des zuvor geschilderten Prozesses wird ausführlich und umfassend dokumentiert. Diese Dokumentation ist eine hervorragende Basis für Entwickler, die an der konvertierten Applikation arbeiten, um Schätzung hinsichtlich des noch benötigten Arbeitsaufwands für Feinabstimmungen zu gewinnen. In der Regel sind manuelle Anpassungen nach der Erstellung für die folgenden Aufgaben möglich: s Anpassung des Weblayouts – falls gewünscht, können die mit dem Tool erstellten Seiten mit Oracle JDeveloper weiter verfeinert werden s Neuordnung der Seitennavigation mithilfe vorgefertigter Komponenten s Verfeinerung und Aktivierung der vom Tool übersetzten Java Methoden s vollständige Definition der Komponenten, die sich nicht 100% toolgestützt generieren liessen, oder das Anbieten von Lösungen, mit denen sich die Beschränkungen des Web-Technologie umgehen lassen (beispielsweise Client Dateisystem oder Zugriff auf die Registry) rung von 20 – 30% zur Amortisation des Projektes beitragen Vorbereitung auf die neue Technologie durch das Beschaffen und Aneignen der erforderlichen Kenntnisse Start von Pilotprojekten – Migration nach ADF von Programmen, die externe Verwendung finden, auf die mit einem Browser zugegriffen werden soll; gleichzeitig Festlegung, welche Anwendungen in Forms bleiben müssen – meist Anwendungen für den internen Gebrauch, insbesondere, wenn sie datenintensiv sind oder sehr häufig die Interaktion des Anwenders erfordern. Der Weg von Forms zu ADF kann eine Herausforderung sein, ist aber auf jeden Fall wert: Die nebenstehenden Schritte sind in Migration Projekten für unsere Kunden angewandt. Und wir sind stolz zu sagen: Es ist uns jedes Mal gelungen, rechtzeitig eine gut funktionierende, moderne ADF-Anwendung zu erstellen. Die End-Benutzer lieben die ADF 11g Rich BenutzeroberflächeKomponenten; die Java-Entwickler mögen die klare, leicht verständliche Architektur. Diese erfolgreichen Kunden-Migrationsprojekte sind der lebende Beweis dafür, dass Oracle ADF in der Lage ist uns zu helfen leistungsfähige, zukunftsorientierte Oracle DatenbankAnwendungen zu erstellen. Fazit Wir sind uns bewusst, dass die Entscheidung zum Umstieg auf JEE und JDeveloper ADF einen wichtigen Schritt und eine grosse Herausforderung darstellt. Hier sind ein paar Schritte welche die typischen Risiken eines solchen Umstiegs erheblich minimieren können: Konsolidierung der Business Logik in die Datenbank – für welchen Lösungsansatz auch immer Sie sich entscheiden (Beibehaltung von Forms oder Umstellung auf ein anderes Framework), der erste Schritt der Risikominimierung besteht darin, die Business Logik zu konsolidieren, also von nicht genutzten Codes zu bereinigen und redundante Codes zusammenzuführen sowie diese in die Datenbank zu verschieben. Allein dieser Schritt kann mit einer Code-Reduzierung und -Konsolidie- SOUG Newsletter 4/2011 Abbildung 8: PITSS.CON Anwendungsanalyse-Bericht Schätzung des Arbeitsaufwands – Zahlreiche Kunden sind bereits auf uns zugekommen, nachdem sie mitunter mehrmals vergeblich versucht hatten, Legacy Anwendungen von Hand zu modernisieren und dafür ganze Mannjahre an Arbeitsaufwand und gewaltige Budgets investiert hatten – um am Ende mit einem enttäuschenden Ergebnis dazustehen. Contact PITTS GmbH Magdalena Serban E-Mail: [email protected] 24 TIPS&TECHNIQUES Florin Serban, PITSS GmbH Implementierung von Web Services in Oracle-Datenbankanwendungen Datenbearbeitungsanwendungen existieren seit dem Anfang der IT und unterstützen heutzutage die meisten unserer Geschäftsprozesse. Während dieser Zeit wurden die Anwendungen weiterentwickelt, um sich den ständig ändernden Geschäftsanforderungen anzupassen. In der Bestrebung nach schneller Entwicklung, Anpassung, Bugfixing und Patching ist die typische OracleDatenbankanwendung grösser und grösser geworden mit den Abbildung 1: Oracle Datenbank Anwendung Jahren und besteht nun aus einer Mischung von alten wie neuen Komponenten, geschrieben in verschiedenen Programmiersprachen und ausgelegt mit unterschiedlichen Architekturen. Eine unserer grössten Herausforderungen wird es sein, das Beste aus all diesen Komponenten herauszuziehen, neu zu strukturieren und in modernen, modularen Anwendungen interagieren zu lassen, sodass die heutigen und zukünftigen Geschäftsanforderungen flexibel unterstützt werden. Der aktuelle Artikel versucht Möglichkeiten aufzuzeigen, wie eine in die Jahre gekommene Oracle Forms Anwendung zu einem Teil einer modernen WebEntwicklungswelt wird. Da die Serviceorientierten Architekturen zunehmend an Bedeutung gewinnen, möchten wir aufzeigen, mit welchen Mitteln externe Anwendungen durch Implementierung von Web Services integriert werden können. SOUG Newsletter 4/2011 Ein paar Worte über Oracle Forms Anwendungen Oracle Forms ist ein solides und ausgereiftes Framework und wohl die meist verwendete Umgebung für die Entwicklung von Oracle Datenbankanwendungen in den letzten 20 Jahren. Seine Architektur wurde speziell für die schnelle und einfache Entwicklung von komplexen Datenbankanwendungen konzipiert. Doch vor 25 Jahren, als die Forms Architektur entworfen wurde, war die Interoperabilität von Anwendungen und die Kommunikation über Web Services noch kein wirkliches Thema. Deshalb ist es keine leichte Aufgabe, alte Oracle Forms Applikationen so zu modernisieren, dass sie mit externen Anwendungen interagieren: Als Web-Services Verbraucher besitzen Forms-Anwendungen, im Gegensatz zu modernen ADF oder APEX Anwendungen keine eigenen Mechanismen, um direkte Verbindungen zu Web-Services herzustellen. Forms kann nur indirekt auf Web Services mit Hilfe von Proxy Diensten oder Datenbank Web Services zugreifen. Beide Lösungen werden wir im Detail betrachten und darstellen, was besser zu unseren Anforderungen passt. Als Web-Services Anbieter: Wenn wir jedoch Forms-Funktionalitäten (= Business-Logik) als Web-Services öffentlich anbieten wollen, müssen wir den entsprechenden Source-Code in die Oracle Datenbank migrieren, um ihn von dort als WebService zu verwenden. Forms kann alleine wegen seiner kompakten Architektur diese Rolle nicht übernehmen. Hier werden wir aufzeigen, wie man in diesem Fall vorgehen kann und warum die Migration von Business-Logik in der Datenbank die Wiederverwendbarkeit des Source-Code erhöht und damit die zukünftigen Migrations- und Modernisierungsschritte unserer FormsAnwendungen ganz erheblich vereinfacht. Web Services aufrufen Wie bereits angesprochen, haben wir zwei Möglichkeiten, um auf externe Web-Services von Oracle Forms Anwendungen aus zuzugreifen: direkt TIPS&TECHNIQUES von Forms mit Hilfe eines Web-Service Proxy-Servers oder von der Oracle-Datenbank aus unter Verwendung seiner Web Service Utilities. Aufrufen von Web Services vom Oracle Forms Wie kann Oracle Forms auf externe Web Services zugreifen? Nun, Forms ist von Natur aus nicht in der Lage, direkt mit Web Services zu kommunizieren, jedoch kann es Java-Klassen innerhalb eines Web-Services Proxy kommunizieren. Der Proxy dient hierbei als Vermittler, denn er ist in der Lage, eine Verbindung zum eigentlichen WebService zu etablieren, wie in Abbildung 2 dargestellt. Abbildung 2: Die Kommunikation zwischen Forms und Web Service über Proxy Um diesen Mechanismus zum Aufruf eines Web-Services in der FormsAnwendung zu verankern, müssen einige Schritte durch geführt werden: Generieren des Web Service Proxy Dieser kann unter Verwendung der Oracle JDeveloper leicht erstellt werden. Man muss lediglich die URL eingeben, wo die Definition des Web Services gefunden werden kann, die so genannte WSDL (Web Service Definition Language). Dies ist ein XML-Dokument, das alle Informationen über die Operationen, die Adresse des Web Services sowie das Message-Protokoll enthält. Wichtig ist hier die Wahl der richtigen Java-Version, die zur Kompilierung der Java-Dateien verwendet werden sollte und mit der Forms JRE Java-Version übereinstimmen muss. Einbringen des Web Service Proxy in eine Jar-Datei Dies kann ebenfalls mit dem Oracle JDeveloper erfolgen, indem man das Projekt mit dem generierten Web-Service-Proxy als JAR-Datei kennzeichnet. Einstellen der FORMS_BUILDER_ CLASSPATH Umgebungsvariable Im Registrierungs-Editor müssen 25 wir die FORMS_BUILDER_CLASSPATH Variable im Oracle-Home der aktuellen Forms-Version einstellen. Der Variablenwert sollte die Adresse beinhalten wo die erzeugte ProxyJAR-Datei zu finden ist. Auf diese Weise werden die Java Klassen des Web-Service-Proxy für den FormJava Importer sichtbar. Importieren der Java-Klassen in der Forms-Anwendung Hier verwenden wir den Forms Java Importer, um die Proxy JavaKlassen, die mit dem Webdienst kommunizieren sollen, in unsere Forms-Anwendung zu importieren. Diese Klassen werden in der Regel mit WebServiceNamePortClient benannt. Die Java-Importer kreieren in der Forms-Anwendung für die importierten Java-Klassen eine Package-Spezifikation und dessen Body als PL/SQL-Schnittstelle. Einstellen der CLASSPATH Umgebungsvariablen für die Laufzeit In der ENV-Datei, die von der FormsAnwendung zur Laufzeit verwendet wird, müssen wir der CLASSPATH Umgebungsvariablen die Adresse der Proxy-JAR-Datei hinzufügen. Diese Einstellung ist notwendig, um die Proxy-Java-Klassen während der Laufzeit im Zugriff zu haben. Sobald wir diesen Mechanismus in unserer Forms-Anwendung implementiert haben, sind wir in der Lage, die Funktionalitäten des neu generierten Package zu verwenden und den WebService aufzurufen. Abbildung 3: Forms-Code Beispiel für das Einlesen der Temperatur eines bestimmten Ortes durch den Aufruf des http://www.Webservicex.net/globalweather.asmx?wsdl Web-Service SOUG Newsletter 4/2011 26 TIPS&TECHNIQUES Das Synchronous/ Asynchronous Dilemma Der Code in Abbildung 3 ist ein Beispiel eines Web Service mit synchronem Aufruf. Hier empfängt der Proxy den Aufruf aus der Forms-Anwendung und sendet diesen weiter an den Webdienst. Kurz darauf erhält er die Antwort vom Web Service und leitet sie zurück zur Forms-Anwendung. Während dieser Abfolge sind die Forms Ressourcen blockiert (locked), die Code-Ausführung wird angehalten, bis die Forms Runtime eine Antwort vom Web Service empfängt. Zur optimalen Auslegung des neuen Web Service, ob synchron oder asynchron, sollten wir uns folgende Fragen stellen: Brauchen wir die Antwort des Web Service für die Fortsetzung der Programmlogik? Denn wenn nicht, können wir einen asynchronen Web Service benutzen. Wie lange dauert die Ausführung des Web Service? Können wir uns leisten, die Anwendung für diesen Zeitraum zu blockieren? Betrachtet man die Ressourcen, die während dem Web-Service blockiert werden: Werden sie auch für andere Prozesse verwendet? Die letzten beiden Fragen sind sehr wichtig: Denn ein verschachteltes Locken vieler Datenbank-Sessions, die versuchen auf die gleichen Ressourcen wie der Web Service zuzugreifen, sollte vermieden werden. Die Lösung wäre: Asynchrone Web Services. Eine mögliche Architektur für asynchrone Aufrufe würde das Einbinden eines Einweg-BPEL-Prozesses, der Advanced Queuing (AQ) DatenbankFunktionalität und das neue Forms 11g Event Objekt erlauben. Verwenden des Forms 11g Event Objekts In unserer neuen Architektur sollte der Proxy nicht die direkte Kommunikation zwischen Forms und einem WebService übernehmen, sondern zwischen Forms und einem BPEL-Prozess. Da dieser BPEL-Prozess ein Einweg Prozess ist («shut and forget»), wartet der Web Service Proxy nicht auf die Antwort des BPEL Prozesses. Nach Erhalt der Auftragsbestätigung durch den BPEL- 1 Prozess lässt der Proxy die Forms Logik weiterlaufen. Der BPEL-Prozess leitet den Anruf an den Webdienst und wartet auf dessen Antwort. Nach dem Empfang übergibt der BPEL-Prozess die Antwort, in diesem Fall als Mitteilung einer Queue, auf die ein Event-Objekt der Forms-Anwendung wartet. Wir haben hier mehrere Möglichkeiten, damit der BPEL Prozess die Antwort sendet: direkte Übertragung der Antwort durch einen AQ-Adapter indirekt über einen DB-Adapter: bevor wir die Antwort weiter an die Queue senden, können wir zusätzliche Aktionen in der Datenbank mittels eines Datenbank-Triggers, -Funktion oder -Prozedur ausführen. Sobald die Antwort in der Queue platziert wird, meldet das Advanced Queuing der Forms Runtime. Der When-Event-Raised Trigger liest beim nächsten Ping des Forms-Applets die Antwort ein1. Abbildung 4: Die Kommunikation zwischen Forms und Web-Service über Forms11g Event Empfehlung zu asynchronen Prozessen: Da die Ausführung des Webdienstes einige Zeit dauern kann und die Forms-Anwendung durchaus die Kontrolle über den gestarteten Prozessen verliert, sollte der BPEL-Prozess regelmässig Nachrichten über seinen Status an die Forms-Anwendung senden. Bei langläufigen Webdiensten bietet sich an, das der WebService den BPEL Prozess sofern möglich über seinen Status informiert und der wiederum die Forms-Anwendung benachrichtigt, so behält die führende Forms-Anwendung trotz asynchroner Abarbeitung die Kontrolle. Mehr Details über das Event-Objekt bei: http://www.oracle.com/technology/sample_code/products/forms/11g/aqinteg/lab1/index.htm#o SOUG Newsletter 4/2011 TIPS&TECHNIQUES Aufrufen von Web Services aus der Oracle Datenbank Nachdem wir gesehen haben, wie wir Web-Services aus Forms aufrufen, stellt sich die Frage, wie befähigen wir die Datenbank-Funktionalität, wie z.B. die Geschäftslogik, die aus der Forms Anwendung zur Datenbank migriert wurde, um sich vorhandener Web Services zu bedienen? Wie können wir den vorher diskutierten Proxy-Webdienst Aufruf ersetzen? Hier bietet Oracle einige Möglichkeiten an, wie: Java-Lösung – dieser Lösungsansatz stellt einen Java Web ServiceClient in der Datenbank bereit. Allerdings können der Java Web Service und dessen abhängige Klassen zu Inkompatibilitäten mit vorhandenen Java-Klassen der Datenbank führen, was dann die Datenbankstabilität beeinträchtigen2 könnte. UTL_HTTP – ist verfügbar ab Oracle 7.3.4 und bietet die Möglichkeit, HTTP-Aufrufe direkt aus der Datenbank durchzuführen. Es kann durchaus für die Kommunikation mit einem Webdienst verwendet werden, indem man eine HTTP-Anfrage sendet, die eine SOAP-Message für Web-Services enthält und als Antwort wiederum eine HTTP Antwort mit der SOAP-Message erwartet. UTL_DBWS – ist verfügbar ab Oracle 10g und kann direkt SOAPCalls verwenden. Im Vergleich zu UTL_HTTP ist es besser auf WebServices ausgelegt. Die Funktionen und Prozeduren, die in diesem Paket definiert sind, stellen Wrapper für die JAX-RPC dynamische Invocation Interface bereit. Ein Stub (Proxy) wird jedes Mal dynamisch erzeugt, sobald wir auf einen WebService über UTL_DBWS zugreifen. Anmerkung: Obwohl UTL_DBWS in einer Oracle 10g DB vorinstalliert ist, ist die dazugehörige Callout-Utility nicht sofort verfügbar und muss nachträglich installiert werden3. In Abbildung 5 sehen wir ein Beispiel zur Anwendung von UTL_DBWS, um einen externen Web Service aufzurufen, der wiederrum die Temperatur für einen bestimmten Ort abfragt: 2 3 27 Die letzten beiden dargestellten PL / SQL-Lösungen haben den grossen Vorteil, dass sie sich perfekt in eine Oracle-Datenbank-Anwendung integrieren lassen. UTL_DBWS ist neuer und damit auch empfohlen von Oracle. Es enthält viele neue Features, Bugfixes und Patches, die nur über DBWS Callout Utility verfügbar sind, sofern es um SOAPAufrufe geht. Abbildung 5: Aufruf eines Web Service mit UTL_DBWS Database Web Service Callout Utility 10.1.3.: http://www.oracle.com/technology/sample_code/tech/java/jsp/callout_users_guide.htm Details on installing Oracle Callout Utility: http://www.oracle-base.com/articles/10g/utl_dbws10g.php SOUG Newsletter 4/2011 28 TIPS&TECHNIQUES Bis zu diesem Zeitpunkt haben wir die Möglichkeiten diskutiert, wie eine Oracle Forms-Anwendung sowohl aus Forms als auch aus der darunterliegenden Datenbank externe Logik in Form von Web-Services konsumieren kann. zu erhöhen, ist die Geschäftslogik entweder neu zu schreiben oder sie vom Forms Programm zu trennen. Schliesslich sollten die Geschäftsprozesse nicht von der Benutzeroberfläche abhängig sein. Aber wie können wir von aussen Forms Funktionalität aufrufen? Bei der Migration der Geschäftslogik aus der Forms-Anwendung in die Datenbank ist es ratsam, den migrierten Code zu konsolidieren und ihn beispielsweise mit all dem funktionell-verwandten Code-Segmenten in einem DB Paketen4 bereitzustellen. Bereitstellung von Web Services Funktionalität für die Aussenwelt verfügbar machen Wir können Funktionalität, die innerhalb der Forms Module definiert ist, nicht direkt als Web Services bereitstellen, aber wir können Oracle DatenbankObjekte dazu anbieten. Was bedeuten würde, dass die Funktionalität, die wir als Web Service bereitstellen wollen, sich noch in dem Forms-Modul befindet. Damit sollten wir Logik erst einmal in die Datenbank migrieren, um sie anschliessend von dort zu verwenden. Lasst uns diese Idee der Migration unserer Geschäftslogik näher betrachten. Warum Forms BusinessLogik in die Datenbank migrieren? Die Forms Architektur macht keine klare Trennung zwischen seiner Datenbearbeitung- und den graphischen Komponenten. In ADF zum Beispiel, kann der Data Modeler (z.B. ADF Business Components (BC)) nicht auf die View Layer Objekte zugreifen oder verweisen. In Forms dagegen hat jede Programmunit oder Trigger vollen Zugriff auf den graphischen Komponenten. Die in Forms gebotene grössere Flexibilität in der Anwendungsentwicklung wird in der ADF Welt durch die nicht so flexible Struktur, aber mit einem höheren Grad der Wiederverwendung ausgeglichen: die ADF BC Funktionalität kann als Webdienste freigestellt und aus externen Anwendungen ausgerufen werde. Die einzige Möglichkeit, die wir in Forms-Anwendungen haben, um diesen Grad der Wiederverwendbarkeit Die Migration des PL/SQL Codes in Datenbank hat eine Reihe von Vorteilen: Auf der einen Seite, kann der so migrierte Datenbank-Code von anderen Anwendungen verwendet werden – entweder direkt oder durch Web-Services. Auf der anderen Seite wird die FormsAnwendung dadurch ganz erheblich vereinfacht und daher leichter migrierbar in anderen Technologien wie ADF5 oder APEX. 5 SOUG Newsletter 4/2011 Die Oracle-Datenbank als Web-Service Provider In einer Service-Orientierten Architektur kann eine Oracle-Datenbank nicht nur die Rolle des Web-Service-Clients übernehmen, wie wir bereits gesehen haben, sondern auch die Rolle als Web-Service Provider. Mit der neuesten Datenbank Version hat sich die Interoperabilität mit anderen Anwendungen drastisch erhöht, denn jetzt haben wir Zugriff auf Oracle Daten und Funktionalität via Web Services. Welche Objekte können wir bereitstellen? Aus der Liste der OracleKomponenten, die als Web Services bereitgestellt werden können, wie vordefinierte SQL-Befehle, XQuery oder DML-Anweisungen, PL/SQL und Java gespeicherte Programmblöcke oder Advanced Queues, richten wir unseren Blick auf PL/SQL Programmblö- Abbildung 6: Oracle Datenbank as Web Service Anbieter PITSS.CON Application Engineering AE, Konzeption und Umsetzung, A. Gaede, 2009, http://pitss.com/fileadmin/pitss/images/de/White_Papers/2009-07_PITSS_White_Paper_AE_-_DE.pdf Von Oracle Forms zu Oracle ADF und JEE, M. Serban, B. Us, 2010 http://www.pitss.de/fileadmin/pitss/images/de/White_Papers/2010-11_PITSS_White_Paper_ADF_DE.pdf 4 Datenbank Funktionalität bereitstellen cke. Die PL/SQL Programmblöcke wie Funktionen, Prozeduren oder Packages sind diejenigen, die den Kern unserer Geschäftslogik ausmachen und damit auch die Business-Logik, die wir aus den Forms-Anwendungen in die Datenbank migrieren können. Abbildung 6 zeigt drei Möglichkeiten auf, um die DB-seitige Business-Logik als WebService zu konsumieren: PL/SQL Web Services – sind die erste Wahl und vielleicht die am meisten verwendete Lösung, um DB Prozeduren und Funktionen als Web Services zu verwenden. Sie müssen auf einem TIPS&TECHNIQUES 29 Webserver wie dem WebLogic deployed werden. BPEL-Prozesse – werden in der Regel verwendet, um komplexe Prozesse darzustellen und zu orchestrieren. Sie können auch verwendet werden, um Prozeduren und Funktionen der Datenbank einzubinden. Auch sie müssen auf einem Webserver wie dem WebLogic deployed werden, da sie eine BPEL Laufzeitumgebung benötigen. Native XML DB Web Services – werden erst mit der Oracle 11g-Datenbank angeboten; es stellt die neueste Lösung dar, um Datenbank-Logik als Web Services zur Verfügung zu stellen. Vorteil hier: Diese Web-Services benötigen keine Codes oder Web-Server für ihre Bereitstellung. per-Beispiel, das einen gleichwertigen Datentyp für Interval year to month verwendet. PL/SQL Web Services Der PL/SQL Web Service besteht in der Regel aus einer oder mehrerer Java-Klassen, die über JDBC die Oracle Datenbank-Verbindung herstellen und so die Programmblöcke anrufen. Auch hier stellt sich die Frage: Welche Funktionalität kann als WebService angeboten werden? Dies sind allein stehende Prozeduren und Funktionen sowie Prozeduren und Funktionen, die in Datenbank-Package definiert sind. Hier gibt es jedoch einige Beschränkungen, die durch den Oracle-JDBC-Treiber gegeben sind: nicht alle SQL-und PL/SQLDatentypen, die die Oracle-Datenbank kennt, werden unterstützt. Wir können zum Beispiel keine Funktionen und Prozeduren, deren Argumente SQL-Datentypen sind, wie Interval day to second, Interval year to month, Timestamp with local time zone, Timestamp with time zone oder PL/SQL Datentypen wie PL/ SQL boolean, PL/SQL record oder PL/ SQL index by table. Jedoch lassen sich diese Einschränkungen durch alternative Lösungen umgehen: wie eine PL/SQL-Wrapper für solche Programmblöcke. Diese Wrapper werden so definieren, dass sie nur SQL-Datentypen benutzen, die von den JDBC-Treiber unterstützt werden bevor sie als Web-Services bereitgestellt werden. Abbildung 7 bietet ein Wrap- Abbildung 7: PL/SQL Wrapper für die GetDate Function Die untenstehende Tabelle veranschaulicht die eingeschränkten Datentypen sowie die dazu passenden Äquivalente. Hier können wir sehen, dass für den PL/SQL record oder PL/SQL index by table zusätzlich entsprechende Objekte oder Collection Datentypen erstellet werden müssen. Datentypen nicht von JDBC unterstützt Äquivalenten Strukturen (mit entsprechender Struktur) (mit entsprechender Struktur) Tabelle 1: Datentypzuordnung SOUG Newsletter 4/2011 30 TIPS&TECHNIQUES Die manuelle Erstellung eines PL/ SQL Web Service ist ein komplizierter Prozess, der eine breite Palette von Kenntnissen erfordert. Hier bietet es sich an, auf leistungsfähige WizardProgramme zurückzugreifen, die unsere Arbeit erleichtern können, wie die von JDeveloper 11g oder PITSS.CON. Sicherlich kann ein Wizard nicht alle Fälle abdecken, aber mit seiner Hilfe und einer nachgelagerten Anpassung ist man schneller und flexibler als die fehlerbehaftete, manuelle Entwicklung. Typische Einschränkungen sind: Überladene Programmblöcke Diese Einschränkung ist bereits durch das WSDL-Dokument gegeben, das verhindern möchte, dass verschiedene Operationen unter dem gleichen Namen veröffentlicht werden. Die Lösung ist die Erstellung eines weiteren Web-Service als weitere Schnittstelle für den überladenen Programmblock. Standalone Programmblöcke Der Assistent des JDeveloper erlaubt derzeit nicht die Verwendung einfacher Funktionen oder Prozeduren. PITSS.CON 8 bietet hier einen leistungsfähigen Assistenten, der solche Programmblöcke als WebService generiert. Nicht unterstützte Datentypen wie in Tabelle 1 und binary_float, binary_double, nclob – Die mögliche Lösung wären Wrapper. Der letzte Schritt zum lauffähigen PL/SQL WebService ist das Deployment auf einem Webserver. Hier können wir zwischen Oracle WebLogic, JBoss, Tomcat oder WebSphere-Server wählen. Der Deployment-Prozess kann in mehreren Arten durchgeführt werden: vom JDeveloper, mit einem Ant-Task oder, wenn wir uns für WebLogic Server entscheiden, von der WebLogicKonsole. SOUG Newsletter 4/2011 BPEL-Prozesse BPEL ist eine auf XML-basierte Sprache für das Erzeugen von komplexen Prozessen, die auch mehrere WebServices einbinden, man spricht hier auch vom Orchestrieren der Prozesse. Eingesetzt auf einem Webserver wie Oracle WebLogic oder jedem anderen Server, der eine BPEL Laufzeitumgebung besitzt, kann der generierte BPELProzess selbst auch als Web Service angeboten werden. Um einen BPEL Prozess zu konstruieren, können wir den im JDeveloper eingebundenen BPEL-Editor verwenden. Das Arbeiten mit BPEL-Editor ist ein einfaches Drag-and-Drop und benötigt keine Java-oder PL/SQL Kenntnisse. Um uns nicht im Detail zu verlieren, konzentrieren wir uns hier auf die BPEL Fähigkeit, die uns erlaubt die Oracle-Datenbank-Funktionalität als Web-Services bereitzustellen. Die Schlüsselkomponente, die dies möglich macht, ist der BPEL-DB-Adapter. Dieser Adapter ist von Oracle vordefiniert, um auf Standalone-Prozeduren oder -Funktionen zuzugreifen, um DML oder Selects- auszuführen oder nach neuen bzw. geänderten Datensätzen in einer Tabelle zu suchen. Zur besseren Einschätzung sind hier einige Fähigkeiten oder Einschränkungen des DB-Adapters aufgeführt: Überladene Programmblöcke Er ermöglicht die Bereitstellung von überladenen Funktionen oder Prozeduren. Abbildung 8: Beispiel eines synchronen BPEL-Prozesses, welcher in der Lage ist eine Funktion freizustellen TIPS&TECHNIQUES Datentypen Unterstützt keine Datentypen wie rowid, urowid, interval, timestamp with (local) time zone, bfile. Wie bei den PL/SQL Web Services kann der DB-Adapter für Funktionen oder Prozeduren Wrapper generieren und bereitstellen, indem die nicht unterstützten Datentypen mit varchar2 ersetzt werden. Für die PL/ SQL record, PL/SQL index by table und PL/SQL Boolean generiert und erstellt er Datenbank-Wrapper und zusätzliche Objekte oder Tabellentypen. Der DB-Adapter kann nur für alleinstehende Funktionen oder Prozeduren konfiguriert werden. Dies ist eine klare Einschränkung, wenn wir auf ganze Datenbank-Pakete zugreifen wollen. In einem solchen Fall müssen wir DB-Adapter für jede Funktion oder Prozedur im Paket erstellen. Wenn wir im Paket mehrere Programmblöcke haben, die nicht unterstützte Datentypen verwenden, dann wird jeder der entsprechenden DB Adapter separate Wrapper oder zusätzliche Objekte / Table-Typen generieren. Dies würde zu NamensKonflikten führen und wir müssten die erstellten Namen so ändern, um die Konflikte zu beseitigen. Native DB Web-Services 31 Web-Services einen Webdienst, der von der Web-Client-Anwendungen verwendet werden kann, um SQL-Anweisungen und XQuery-Ausdrücke dynamisch auszuführen. Die Aktivierung der nativen DB Web Services Feature Aus Sicherheitsgründen ist das native DB Web Service Feature in der Oracle-Datenbank nicht automatisch aktiviert. Um die Oracle XML DB zu konfigurieren und dieses Feature zu aktivieren, müssen wir die Oracle XML DB HTTP-Server aktivieren und die ‘orawsv’ Servlet im xdbconfig.xml Datei editieren. Die Aktivierung des XML DB HTTPServers wird abgeschlossen durch das Setzen der Port-Nummer auf einen Wert grösser als 0. Eine Überprüfung ist einfach, indem wir die Port-Nummer des XML-HTTP-Server DB mit Hilfe der DBMS_XDB.GetHttpPort oder .SetHttpPort Funktionalität einstellen, wie in der folgenden Befehlszeile: Das gleiche DBMS_XDB Paket kann benutzt werden, um die ‘orawsv’ Servlet-Konfiguration in der xdbconfig.xml Oracle-Konfigurationsdatei hinzufügen, siehe Skriptbeispiel in Abbildung 9. Das Feature der «Native Datenbank Web Services» ist eine Erweiterung der Oracle XML DB, verfügbar ab Oracle11g. Damit eliminiert Oracle den Aufwand einen Webdienst einzurichten. Mehr als das, dieses Feature eliminiert die Notwendigkeit einen Webserver überhaupt bereitzustellen. Die OracleDatenbank übernimmt hier die WebServer-Rolle, mit Hilfe ihrem integrierten HTTP-Server, Teil der Oracle XML DB Funktionalität. Durch Aktivierung der nativen Datenbank Web Services sind die Datenbank-Prozeduren und Funktionen, die entweder Standalone oder in einem Paket definiert wurden, automatisch als Webdienste bereitgestellt. Darüber hinaus enthalten die native Datenbank Abbildung 9: SQL Skript zum Hinzufügen der «orawsv» ServletKonfiguration zur XML DB-Konfigurationsdatei (laufen als SYS Datenbankbenutzer) SOUG Newsletter 4/2011 32 TIPS&TECHNIQUES Aktivieren der nativen DB Web Services für einen DB-Benutzer Obwohl das native Datenbank Web Services Feature jetzt aktiviert ist, brauchen die Datenbank-Benutzer zusätzliche Rechte, um in die Lage zu kommen, eigene Programmblöcke als native Web-Services bereitzustellen. Es gibt 3 Rollen, die den Zugriff auf die native Datenbank Web Services steuern: XDB_WEBSERVICES erforderliche Rolle, die die Verwendung von nativen Web Services über HTTPS ermöglicht XDB_WEBSERVICES_OVER_HTTP erlaubt die Verwendung von nativen Web Services über HTTP XDB_WEBSERVICES_WITH_PUBLIC ermöglicht den Zugriff auf PUBLIC Datenbank-Objekte. Finden und ausführen von Native DB Web Services Nach der Aktivierung des nativen Datenbank Web Services Feature und der Erteilung der entsprechenden Rollen für die Datenbankbenutzer folgt der nächste Schritt, das Identifizieren der Web-Services Adresse, d.h. die URLs des nativen Web Services WSDL-Dokumentes. Das WSDL-Dokument gibt uns nicht nur die Adresse des Web Service, sondern auch die enthaltenden Operationen samt Parameter. Es bleibt anzumerken, dass die Oracle XML DB SOAP1.1 unterstützt und der Web-Service-Client diese Version benötigt, um im HTTP POST Prozess die SOAP-Anfrage an die nativen Datenbank-Webdienste weiterzureichen. Das native Datenbank Web-Services-Feature bietet nur einen Webdienst, der verwendet werden kann, um SQL-Anweisungen oder XQueryAusdrücke in der Datenbank durchzuführen. Sein WSDL-Dokument URL verweist auf eine Adresse wie http:// host:port/orawsv?wsdl, wo der Host der Datenbank-Host und der Port die Port-Nummer ist, die von der XML DB HTTP-Server verwendet wird. Bei den PL/SQL-Programmblöcken haben wir eine andere Situation. Jede Prozedur oder Funktion, Standalone oder im Paket, hat ihren eigenen dynamischen Web Service. Die WSDLDokumente dieses Web-Services be- SOUG Newsletter 4/2011 finden sich für Standalone-Funktionen und Prozeduren: http://host:port/ orawsv/DBSCHEMA/FUNCTION_or_ PROCEDURE?wsdl, und bei Funktionen und Prozeduren aus Paketen: http://host:port/orawsv/ DBSCHEMA/PACKAGE/FUNCTION_ or_PROCEDURE?wsdl. Zusätzlich gibt es native Web-Services definiert für Datenbank-Pakete. Solch ein Webdienst stellt alle Prozeduren und Funktionen zur Verfügung, die im zugehörigen Paket definiert sind, sowie die URL des WSDL-Dokuments http://host:port/orawsv/DBSCHEMA/ PACKAGE?wsdl. Hier müssen wir darauf achten, dass die URLs Schema-, Paket-, Funktion- oder Prozedurnamen in Grossbuchstaben geschrieben werden, sonst bringt uns der Browser einen Fehler zurück. Nachdem wir bisher die Vorteile der nativen DB Web Services betrachtet haben, bleibt die Frage nach ihren Beschränkungen. Einige typische Probleme, auf die wir stossen können, sind: Überladene Funktionen oder Prozeduren können nur über die nativen Web-Services erreicht werden Unterstützte Datentypen: Die Prozeduren und Funktionen mit Parametern wie PL/SQL record, PL/SQL indexed tables oder database collection, lassen sich nicht als native Web-Services bereitstellten. Fazit Wir haben hier die Möglichkeiten einer besseren Integration von Oracle Forms-Anwendungen in die moderne Web-Welt betrachtet. Da wir und unsere Anwendungen ständig mit neuen, modernen Technologien für die Entwicklung von Datenbankanwendungen konfrontiert werden, ist alleine schon die Auswahl der Besten schwieriger als je zuvor. Werfen Sie einen Blick auf Oracle Konferenzen: die Agendas sind mit neuen Themen, wie ADF, APEX, BI Publisher und so weiter ausgefüllt und es ist richtig so, da eine neue Ära der Anwendungsentwicklung längst begonnen hat: die Ära der Web-Entwicklung. Doch während wir die Strategien bewerten, um den besten Weg zu wählen, sind wir mit einer sehr bodenständigen, wichtigen und dringenden Frage konfrontiert: Was passiert mit dem gegenwärtigen System, sodass es weiterhin die Geschäftsprozesse unterstützt mit Hilfe der aktuell verfügbaren Ressourcen? Viele Unternehmen, die Legacy Forms-Anwendungen besitzen, verharren noch in einem «Wait-and-See»Ansatz und machen erst einmal den Upgrade ihrer Forms-Anwendungen auf die zurzeit neue 11g-Version. Auf diese Weise erhalten sie die Vorteile, die die 11g-Version mit sich bringt, bleiben unter Support, während man Zeit gewinnt, um die neuen Technologien zu bewerten, zu verstehen, die modernen Entwicklungssprachen und -Architekturen zu erlernen und die neuen Technologien reifer werden. Aber, ob wir nun beschliessen, in die neuen Technologien zu migrieren, oder erst einmal bei Forms zu bleiben, bietet sich eine gute Strategie an, so viel wie möglich von der Business-Logik einer Forms-Anwendung in die Datenbank zu verschieben. Der Applikations-Code wird entrümpelt, der Code überarbeitet und als WebService anderen Anwendern und Kunden zugänglich gemacht. Der Hauptvorteil jedoch liegt darin, dass Sie, wann immer Sie wollen, viel einfacher in die neuen Technologien migrieren. Die Implementierung von Web Services und das Orchestrieren in einer modernen Architektur stellt alleine schon eine exzellente Verbesserung dar und kann mit minimalen Investitionen erreicht werden. Ebenfalls lässt sich der Kerngedanke der Serviceorientierten (SOA) Prinzipien erreichen – Wiederverwendung, Interoperabilität und Setzen von Standards – während unsere Datenbank-Anwendungen flexibler werden und schneller auf die sich ändernden Geschäftsanforderungen reagieren. Contact PITTS GmbH Andreas Gaede E-Mail: [email protected]
