Interview mit Ted Farrell auf der Oracleworld in Paris

Productivity with Choice

Rudolf Jansen

Auf der europäischen Hauskonferenz der Firma Oracle in Paris hatten wir die Gelegenheit mit Ted Farrell, Architect & Director of Strategy, Application Development Tools bei Oracle, über die neuesten Entwicklungen im Java-Entwicklungsbereich zu sprechen.

Java Magazin: Vor ungefähr einem Jahr hat Oracle den JSR 198 Standard Extension API for Integrated Development Environments ins Leben gerufen. Andererseits ist Oracle nun auch Mitglied im Eclipse Board. Wie passt das zusammen?

Ted Farrell: Oracles Sicht auf Eclipse unterscheidet sich nicht von der auf andere IDEs. Wir sehen Eclipse als unter Entwicklern beliebte Entwicklungsumgebung und möchten Entwickler unterstützen, die Eclipse als IDE für Oracle-Applikationen einsetzen. Daher unterstützen wir Eclipse in derselben Art und Weise, wie wir das auch durch Erweiterungen für JBuilder und andere IDEs machen, damit Eclipse-Usern alle erforderlichen Ressourcen für die Erstellung von Oracle-Applikationen zur Verfügung stehen. JSR 198 dagegen spiegelt Oracles Sichtweise wider, dass es eigentlich nicht eine einzige Tool-Plattform geben sollte. Das wäre schlecht für die Industrie und schlecht für innovative Ideen, denn wenn alle Hersteller von Entwicklungstools sich auf diese einzelne Architektur konzentrieren müssen, dann ist das nicht besonders förderlich für neue Ideen. JSR 198 ist aus unserer Sicht daher etwas wie wir es jetzt schon auf der Server-Seite von Applikationen kennen: Da sind die APIs standardisiert und alle Hersteller implementieren diesen Standard. Die Implementierung von Oracle unterscheidet sich hier von der Implementierung von BEA oder IBM und so sollte es auch auf der Toolseite sein: Die Schnittstellen müssen standardisiert werden und die Plugins kommunizieren dann über diese standardisierten Schnittstellen.

JM: Es gibt also keine Pläne, Oracles JDeveloper in Zukunft durch Eclipse zu ersetzen?

Farrell: Nein, definitiv nicht. Wir werden den JDeveloper weiterentwickeln. Oracle verdient mit dem JDeveloper aber nicht viel Geld. Unser Fokus liegt nicht auf dem Verkauf von Tools. Unsere Tools sollen die Oracle-Runtime-Umgebung unterstützen.

JM: Wenn man sich die Entwicklung von Java-Applikationen ansieht, so kann man dabei drei Gruppen unterscheiden: Rich-Client Swing-Anwendungen, Web-Anwendungen über Servlets und JSPs sowie EJB-Anwendungen. Wo sehen Sie in der Industrie den Schwerpunkt derzeit und in der Zukunft?

Farrell: Ich würde zwei Gruppen daraus machen: Rich-Client und Thin-Client, also Swing und Web-Applikationen. Wir sehen einen klaren Trend zu Web-Applikationen hin. Was benötigt wird, ist eine bessere Benutzerschnittstelle im Web. Das Web bietet Vorteile bei der Distribution sowie bei späteren Updates. Gesucht sind also Technologien für Web-basierte Applikationen mit bequemen Benutzerschnittstellen. Eingesetzt werden dazu proprietäre Lösungen wie Applets, DHTML und JavaScript. Wir bieten dazu eine Technologie namens UIX, eine Sammlung von UI-Komponenten, die u.a. auch in der Oracle E-Business Suite genutzt wird. Die neue Technik JavaServer Faces wird von uns als einer der ersten Anbieter unterstützt. Diese ganzen Technologien bieten eine ganze Menge für die Erstellung von Web-Applikationen und daher werden in Zukunft wesentlich mehr Web-Applikationen erstellt werden als Swing-Applikationen.

JM: Der JDeveloper geht also auch in diese Richtung?

Farrell: Wir unterstützen beide Ansätze. Die Kernphilosophie von JDeveloper 10g lautet Productivity with Choice. Wenn Ihre Entwickler bereits in einer bestimmten Technik eingearbeitet sind, z.B. in Struts oder JSP, dann wollen wir Sie nicht zwingen, alle wieder umzuschulen. Sie selber sollen entscheiden, wie Sie arbeiten wollen. Wenn Sie ein Swing-Programmierer sind, dann können Sie alles andere ausschalten und weiter Swing programmieren. Wenn Sie JSPs schon gut kennen, dann haben wir einige Frameworks, mit denen Sie noch mehr aus JSPs herausholen können. Wenn Sie EJBs einsetzen wollen, dann bieten wir Ihnen eine Persistenz-Architektur an, mit der Sie die Daten aus der Datenbank holen und cachen können. Sie können sich also Ihre Technologie aussuchen. Der JDeveloper ist also für alle Arten von Java-Entwicklung einsetzbar.

JM: Zur neuen Version 10g des JDevelopers: Die Version 10g der Oracle-Datenbank steht im Zeichen des Grid-Computings. Was bedeutet das für die Entwickler von Grid-Anwendungen? Angeblich sollen ja keine Code-Änderungen für Grid-Applikationen nötig sein.

Farrell: Das schöne am Grid ist, dass bestehende Applikationen ohne Änderung im Grid lauffähig sind. Und im Gegensatz zu Grid-Ansätzen anderer Hersteller wie z.B. IBM gibt es bei uns auch keine speziellen Grid-APIs oder Grid-Libraries. Das ist ähnlich wie beim J2EE-Ansatz. Da definieren Sie nur ein Objekt und die Verteilung in der Runtime-Umgebung wird von der Infrastruktur übernommen. Der Grid-Ansatz überträgt dieses Konzept nun auf die nächste Ebene. Programmierer sind weiterhin für die Erstellung der Software zuständig, das Grid übernimmt dann das Management dieser Software.

Trotzdem können Entwickler natürlich Software bauen, die von den Vorteilen des Grids profitieren kann. Das basiert dann auf SOA (Service Oriented Architecture). Indem man wiederverwendbare Komponenten entwickelt, werden Services zur Verfügung gestellt. Und diese Services können dann vom Grid je nach Bedarf mit Ressourcen versorgt werden. Nehmen Sie als Beispiel einen Bestellservice und einen Finanzservice: Wenn am Quartalsende verstärkt Ressourcen für den Finanzservice benötigt werden, können diese vom Grid zur Laufzeit zur Verfügung gestellt werden und in der übrigen Zeit für die anderen Services genutzt werden. Die neuen Features von JDeveloper 10g haben eine Reihe von Schwerpunkten. Einer davon ist SOA. Wir bieten ein Framework mit Namen Oracle Application Development Framework (Oracle ADF) an. Das ist eine Sammlung von Runtime-Klassen, die auf J2EE aufbauen. Entwickler setzen also nicht mehr die J2EE-APIs ein, sondern wählen über unsere Runtime-Klassen einen mehr deklarativen Ansatz. Oracle ADF soll also Entwicklern helfen, wiederverwendbare Services zu bauen.

JM: Wie ist denn das Verhältnis zwischen diesem neuen ADF-Framework und den bisherigen BC4J (Business Components for Java)-Klassen?

Farrell: Eine weitere wichtige Eigenschaft von ADF ist die Tatsache, dass ADF nicht eine grundlegend neue Technik ist. Wir haben ja bereits mit BC4J und UIX zwei Frameworks im Programm und auch außerhalb von Oracle gibt es entsprechende Frameworks wie z.B. Apache Struts. ADF vereint nun die besten Eigenschaften dieser bereits bestehenden Frameworks unter einem gemeinsamen Dach. ADF ist also die erste Version eines Ansatzes, bei dem bewährte Frameworks wie z.B. BC4J verwendet werden, die bereits in einer Vielzahl von Enterprise-Anwendungen eingesetzt werden.

JM: Wann ist der neue JDeveloper 10g verfügbar?

Farrell: Derzeit gibt es noch eine Preview-Version. Die Release-Version ist für Anfang 2004 vorgesehen.

JM: Der JDeveloper ist natürlich sehr gut auf den Einsatz im Zusammenhang mit den anderen Oracle-Produkten abgestimmt. Warum sollte er denn auch in Projekten eingesetzt werden, in denen ansonsten Datenbanken bzw. Applikations-Server von anderen Herstellern eingesetzt werden?

Farrell: Der Fokus von JDeveloper 10g und dem ADF-Framework liegt auf Produktivität. Wir als Java-Industrie bekennen uns zu Standards und der freien Wahl aus Produkten, die auf diesen Standards beruhen. Daher ist ADF auch unabhängig von einem speziellen Applikations-Server. Sie können es mit JBoss oder WebLogic einsetzen, sie sind da nicht auf Oracle-Produkte beschränkt. Oracle bietet Ihnen zwar den Vorteil, Produkte für alle Bereiche im Angebot zu haben, aber Sie müssen nicht alles von Oracle kaufen. ADF arbeitet genauso mit fremden Applikations-Servern zusammen wie der Oracle Application Server mit anderen Datenbanken zusammenläuft.

JM: Ein anderes neues Tool von Oracle ist HTML-DB, eine Art Entwicklungsumgebung in der Oracle-Datenbank. Was ist HTML-DB? Wann sollte man HTML-DB einsetzen und wann den JDeveloper?

Farrell: Eine gute Frage. HTML-DB ist eine gehostete Entwicklungsumgebung mit klarem Fokus auf Benutzer, die bisher Tools wie Microsoft Access eingesetzt haben. Wer mit Access vertraut ist und der Art und Weise wie man dort Formulare auf der Basis einer Datenbank erzeugt, für den wird HTML-DB eine sehr komfortable Umgebung sein. Viele Unternehmen setzen sogar Excel-Spreadsheets als Datenbank für kleine Applikationen ein. HTML-DB bietet hier mehr, insbesondere für Web-basierte Anwendungen. Der JDeveloper zielt dagegen mehr auf den klassischen Entwickler, der seine Anwendungen bisher mit Fortran, Cobol, Java oder C++ entwickelt, während HTML-DB eher für die bisherigen Access- und Excel-Programmierer gedacht ist.

JM: Wie sieht denn dann die Zukunft von Oracle Forms aus? Soll HTML-DB Oracle Forms ablösen?

Farrell: Ich denke, dass sich Oracle Forms-User eher im JDeveloper-Umfeld wiederfinden werden. Unsere Empfehlung für Forms-User lautet: Falls es keinen Grund für einen Wechsel von Forms weg gibt, dann sollte auch keine Umstellung erfolgen. Wir werden diese Technologie weiter unterstützen und daher kann sie auch weiter eingesetzt werden.

Es läuft bei dieser Frage auf eine grundlegende Architekturfrage hinaus. Die Runtime-Architektur von Oracle Forms unterscheidet sich deutlich von der aus dem J2EE-Bereich. Man benötigt hier keinen Applikations-Server, stattdessen wird alles aus der Datenbank heraus erzeugt. Erst wenn die Projekt-Anforderungen einen Wechsel in eine J2EE-Architektur erforderlich machen, ist der Zeitpunkt gekommen, wo man von Oracle Forms auf den JDeveloper wechseln sollte. Schwerpunkt der JDeveloper-Version 10g ist das ADF-Framework, bei dessen Erstellung wir eine Menge der Kenntnisse einsetzen konnten, die wir bei der Erstellung der visuellen Tools, Forms und Designer gewinnen konnten. Daher ist der JDeveloper auch das Tool, das für bisherige Forms-Benutzer am geeignetsten ist, wenn diese auf Grund neuer Anforderungen umsteigen müssen. HTML-DB ist wie bereits erwähnt eher für die bisherigen Nutzer von Finanz-Spreadsheets gedacht.

JM: Vielen Dank für das Gespräch.

Geschrieben von
Rudolf Jansen
Kommentare

Schreibe einen Kommentar

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