JavaMagazin 3/2003: WebSphere Studio Application Developer V5

Gib mir 5

von Michael Müller

Die Zeiten von Visual Age for Java sind nun schon eine ganze Weile her und das Nachfolgeprodukt, der WebSphere Studio Application Developer, liegt nun in seiner zweiten Version vor. Diese hört auf den Namen „5“ und liefert eine ganze Reihe von Neuerungen und Verbesserungen, die den Entwickler von J2EE-Applikationen bei seiner Arbeit weit reichend unterstützen.

Der WebSphere Studio Application Developer, kurz: WSAD, ist das Hauptprodukt in der WebSphere Studio-Werkzeugfamilie (Abb. 1) und deckt den ganzen Bereich der Entwicklung von J2EE-Applikationen ab. Eine abgespeckte Variante – WebSphere Studio Site Developer – ist für die Entwicklung von Web-Applikationen ohne Enterprise JavaBeans gedacht. Die nächsthöheren Studio-Werkzeuge, der WebSphere Studio Application Developer Integration Edition (WSAD IE) und der WebSphere Studio Enterprise Developer (WSED), werden demnächst ebenfalls als Version 5 erhältlich sein. Der WSAD IE beinhaltet dabei die komplette Funktionalität des WSAD und erweitert diesen im Wesentlichen um Werkzeuge, mit deren Hilfe J2EE-Applikationen über Java 2-Konnektoren mittels des Web Services Invocation Frameworks an Back-End-Systeme angebunden werden können.
Der WSED beinhaltet die Funktionalität des WSAD IE und erweitert diesen um Werkzeuge, die die Entwickler auf der Host-Seite unterstützen, wie COBOL- und PL/1-Editoren, -Compiler und -Debugger.



Abb. 1: Die Produktfamilie IBM WebSphere Studio

Hat man die Version 5 des WSAD installiert und gestartet, fällt einem sofort eine kleine, aber feine Verbesserung gegenüber der Vorgängerversion auf: Ein kleiner Auswahldialog erlaubt es, das Workspace-Verzeichnis auszuwählen, mit dem die aktuelle Instanz des WSAD betrieben werden soll.
Nach dem Start präsentiert sich die Oberfläche in ihrem neuen Aussehen. Sämtliche Symbole wurden liebevoll überarbeitet und sehen einfach netter aus als in der Vorgängerversion.
Die Eclipse 2-Funktionalität, auf die der WSAD 5 aufbaut, wurde bereits im Artikel „Die zweite Sonnenfinsternis“ im Java Magazin 11.2002 ausführlich beschrieben.

J2EE alt oder neu

Im Folgenden gehen wir auf die einzelnen konkreten Änderungen ein, welche die neue Version gegenüber der Version 4 mit sich bringt. Eine wesentliche Neuerung ist, dass Version 5 die neueste J2EE-Spezifikation 1.3 und damit verbunden auch die dazugehörigen Servlet-, JSP- und EJB-Spezifikationen unterstützt. Parallel dazu findet aber nach wie vor auch die J2EE 1.2 Unterstützung.
Zur Bearbeitung der Deployment Descriptoren wurden die Editoren auf das Eclipse-typische Aussehen (Flat Look) umgestellt (Abb. 2).



Abb. 2: Flat Look des EJB Deployment Descriptor Editors

Alle Einstellungen eines Deployment Descriptors werden nunmehr in einem einzigen Fenster vorgenommen. Die noch in Version 4 bestehende Trennung, bei der die Standardeinstellungen des Deployment Descriptors und die Einstellung der WebSphere-spezifischen Erweiterungen in zwei verschiedenen Editoren vorgenommen wurden, existiert nun nicht mehr. Dennoch ist auch in Version 5 noch klar ersichtlich, bei welchen Einstellungen es sich um Standardeinstellungen handelt und welche zu den WebSphere-spezifischen Erweiterungen zählen.
Auch der Umgang mit Utility JAR-Dateien einer Enterprise-Applikation wurde vereinfacht. Wo bei Version 4 noch viele manuelle Schritte notwendig waren, um aus einem Java-Projekt eine JAR-Datei zu erzeugen und in ein Enterprise Application Project zu kopieren, genügt es bei Version 5, diesem ein Java-Projekt als Utility JAR hinzuzufügen. Der WSAD 5 sorgt dafür, dass Änderungen in diesem Java-Projekt automatisch zu einer Aktualisierung der JAR-Datei führen.
Mit der neuen Version des WSAD wurde die Verzeichnisstruktur der J2EE-Projekte geändert, dennoch ist eine Migration von Projekten, die mit Version 4 erstellt wurden, jederzeit möglich. Ebenso können J2EE 1.2-Anwendungen nach J2EE 1.3 migriert werden.
Als Testumgebung kann zwischen den Versionen 4 bzw. 5 des WebSphere Application Servers (WAS) sowie dem WebSphere Application Server Version 5 Express (WAS ohne EJB-Container) ausgewählt werden.

Web-Werkzeuge

In Version 4 des WSAD waren einige der Web-Werkzeuge noch aus dem WebSphere Studio in den WSAD integriert, d. h. aus dem Vorgängerprodukt von IBM, welches für die Erstellung von reinen Web-Applikationen eingesetzt wurde. Diese Werkzeuge lagen als Windows-Applikationen vor. Allerdings war die Integration nicht vollständig umgesetzt, was sich an vielen kleinen Details zeigte: Kein Code Assist beim Einfügen von Scriptlets, kein Browse-Button zum Auswählen einer Klasse beim Einfügen eines JSP UseBean Tags, Design-Ansicht des HTML-/JSP-Editors (Page Designer) nur auf Windows verfügbar usw. In Version 5 wurden diese alten Werkzeuge sukzessive durch in Java implementierte Plugins ersetzt, welche sich nun homogen in den WSAD einbinden.

Eine wesentliche Neuerung im WSAD 5 ist die Unterstützung bei der Entwicklung von Struts-basierten Web-Applikationen. Legt man ein neues Projekt an, können diesem die notwendigen Bibliotheken hinzugefügt werden. Außerdem existieren für die Konfigurationsdateien entsprechende Editoren, Assistenten zum Anlegen von Action-Klassen, ActionForm-Klassen und Struts-Konfigurationsdateien. Wirklich elegant ist der Web Diagram Editor (Abb. 3), mit dessen Hilfe man den Kontrollfluss einer Struts-basierten Web-Applikation grob skizzieren kann. Dazu legt man verschiedene Knoten an, die die verschiedenen Seiten einer Web-Applikation repräsentieren. Anschließend können die verschiedenen Knoten/Seiten durch Setzen von Verbindungen miteinander verknüpft werden. Darauf basierend werden sodann die zugehörigen HTML-Seiten/JSPs erstellt und vervollständigt.



Abb. 3: Modellierung des Kontrollflusses einer Struts-basierten Web-Applikation

Apropos HTML-Seiten/JSPs – der Page Designer wurde ebenfalls komplett überarbeitet. Attribute zu einem ausgewählten Element einer Seite können nun in einem eigenen View, dem Attributes View, editiert werden. Außerdem werden JSP-Tags innerhalb der Design-Ansicht des Editors durch Rechtecke mit einer Kurznotation des Tags dargestellt. Die Fly over-Hilfe zu den Tags zeigt den genauen Quelltext des Tags an, ohne dass man dazu in die Quelltextansicht des Editors zu wechseln braucht. Der Editor für CSS-Dateien bietet die Möglichkeit, die spezifizierten Stylesheets in einer Voransicht anzuzeigen, um die Auswirkungen einer Änderung sofort betrachten zu können. Verglichen mit dem alten Page Designer – fortan als Page Designer Classic bezeichnet – wurde der neue also um einige Features erweitert. Auf der anderen Seite wurde ein Teil der Funktionalität des alten Page Designers nicht in den neuen übernommen; beispielsweise wird das Einfügen von ActiveX Controls oder die Verwendung von Dynamic HTML für Roll over-Effekte vom neuen Page Designer nicht unterstützt. Jede Version des Page Designers hat also ihre Vorzüge. Standardmäßig wird mit der Version 5 des WSAD der neue Page Designer installiert. Wer auf die Features des Page Designers Classic jedoch nicht verzichten möchte, kann diesen im WSAD 5 aktivieren. Wahlweise kann dann der alte oder der neue Page Designer verwendet werden.

Der in der Praxis üblichen Trennung zwischen statischen und dynamischen Elementen einer Web-Applikation wurde nun durch den neu hinzugekommenen Projekttyp Static Web Project Rechnung getragen. Damit lässt sich diese Trennung schon innerhalb der Entwicklungsumgebung und nicht erst beim Deployment der Applikation vollziehen. Der statische Inhalt wird dabei auf einem reinen HTTP-Server installiert und die dynamischen Elemente auf einem Application Server.

Unternehmenskaffeebohnen

Der Versionssprung bei der EJB-Spezifikation von 1.1 auf 2.0 hat bekanntlich weit reichende Folgen für die Entwicklung von EJBs. Im WSAD gibt es nun die Möglichkeit, sowohl EJB 1.1- als auch EJB 2.0-konforme Module zu entwickeln. Dabei werden sämtliche Neuerungen unterstützt, beispielsweise Local Interfaces, Container Managed Relationships und Message Driven Beans. Als JMS-Provider ist dabei ein im Application Server integriertes WebSphere MQ enthalten, das zur Kommunikation innerhalb der Applikation genutzt werden kann. Für einen applikationsübergreifenden Nachrichtenaustausch ist nach wie vor die Installation eines zusätzlichen Messaging-Produktes notwendig. Die noch in Version 4 existierende Einschränkung, dass lediglich ein relationales EJB-Mapping pro Modul verwaltet werden konnte, wurde in Version 5 behoben. Nun können für verschiedene Datenbanken sogar mehrere Mappings pro Datenbanktyp erstellt und verwaltet werden. Beim Deployment einer Applikation kann man sich dann entscheiden, welches der Mappings für die Generierung der Klassen verwendet werden soll.

Das Konzept von Container Managed Relationships, das in Version 4 des Application Servers lediglich als Erweiterung verfügbar war, ist mittlerweile Bestandteil der EJB 2.0-Spezifikation und somit auch im WSAD 5 in Form eines Relationship Editors verfügbar, wo nun auch Beziehungen mit der Kardinalität many-to-many definiert werden können.
Neben diesen grundlegenden Verbesserungen wurde bei den EJB-Werkzeugen auch eine Reihe von kleineren Aspekten verbessert, die hier nur auszugsweise und stichpunktartig aufgeführt sind:

•	m Outline View: Kennzeichnung der Methoden einer EJB-Klasse, in welchen Interfaces diese jeweils deklariert sind, durch entsprechende Kürzel (L=Local, LH=LocalHome, R=Remote, H=Home).
•	Anzeige der verwendeten Version der Spezifikation eines J2EE-Moduls durch so genannte zuschaltbare Decorator.
•	Umstrukturierung des Aufbaus von EJB-Projekten mit der Möglichkeit, im WSAD 4 erzeugte Projekte zu migrieren.

GUI-Erstellung

Neben diesen vielen Verbesserungen bei den Werkzeugen zur Erstellung serverseitiger Applikationen wurde nun ein GUI-Editor integriert, der so genannte Java Visual Editor (JVE). Nachdem IBM den WSAD als Nachfolgeprodukt von VisualAge for Java (VAJ) positioniert hat, war es überfällig, einen entsprechenden Editor für GUIs zu integrieren. In diesem Editor können AWT- oder Swing-basierte GUI-Klassen grafisch editiert werden. Dazu steht dem Entwickler der View JavaBeans zur Verfügung, der alle in der Klasse enthaltenen Beans hierarchisch anzeigt, ähnlich wie die Beans List in VAJ. Das Editorfenster selbst ist dreigeteilt (Abb. 4).




Abb. 4: Der Java Visual Editor des WSAD 5

Neben den verschiedenen Kategorien für AWT und Swing Beans kann die Klasse entweder grafisch modelliert oder der Java-Quelltext der Klasse editiert werden. Wählt man nun eine grafische Komponente wie einen Button aus der Liste aus und platziert sie in der grafischen Ansicht, wird der dazugehörige Java-Quelltext sofort in der unteren Hälfte des Editors aktualisiert. Ebenso werden Änderungen am Quelltext nach einer einstellbaren Zeitspanne in der grafischen Ansicht des Editors aktualisiert. Neben den Komponenten aus der Standardpalette lassen sich auch benutzerdefinierte JavaBeans einfügen. Zur Verwaltung der Metadaten werden im Gegensatz zu VAJ spezielle Kommentare in den Quelltext eingefügt.

Java-Klassen, die mit dem Visual Composition Editor (VCE) von VAJ erstellt wurden, können für das Nachfolge-Werkzeug migriert werden, indem sie in den WSAD importiert und anschließend im JVE geöffnet werden. Dabei erkennt der Editor anhand der Namenskonventionen für die erzeugten Variablen ivj<Variablenname>, dass diese Klasse mit VAJ erstellt wurde und stellt die Klasse entsprechend dar. Mit Hilfe eines Migrationswerkzeugs für VAJ (IBM VCE Code Generation and Export Utility) können Klassen aus VAJ exportiert werden. Dabei werden die JVE-Kommentare erzeugt, die notwendig sind, um auch beispielsweise nicht grafische Beans im JVE darzustellen. Mit Hilfe dieser Informationen kann der JVE eine Klasse genauso wie in VAJ darstellen, bis auf die Connections. Die Möglichkeit, das Event Handling einer Applikation ebenfalls im JVE zu modellieren, so wie dies in VAJ möglich war, besteht derzeit noch nicht, könnte aber laut IBM in einer der nächsten Versionen folgen.

XML-Erweiterungen

Auch im Bereich der XML-Werkzeuge ist der WSAD 5 erheblich erweitert worden, insbesondere hinsichtlich des Umgangs mit XSL-Dateien. So steht jetzt für das Editieren eine Reihe von Assistenten zur Verfügung, um oft benötigte XSLT-Konstrukte und Code-Gerüste einzufügen. Die Code Assist-Funktionalität zeigt, analog zum Java-Editor, die an der aktuellen Stelle im Quelltext möglichen Code-Ergänzungen an. Ferner gibt es jetzt einen ebenso komfortablen wie umfangreichen Assistenten zum Erstellen von XPath-Ausdrücken.

Für den Test von XSL-Dateien wurde dem WSAD 5 eine eigene Perspective spendiert – die XSL Debug Perspective. In dieser Perspective kann, ähnlich wie in der Debug Perspective, eine XSL-Transformation Schritt für Schritt untersucht werden. Dabei stehen verschiedene Views zur Verfügung, die detaillierte Informationen zur aktuellen Debugging-Sitzung darstellen. Es werden beispielsweise alle Properties des aktuellen XSL-Elements angezeigt, das momentan bearbeitet wird. In einem Template Call Stack View können die verschiedenen Aufrufe von XSL Template-Funktionen betrachtet werden, damit die Position, in der die Transformation momentan steht, nachvollziehbar ist. Alternativ zur schrittweisen Beobachtung der Transformation können innerhalb der XSL-Datei Breakpoints gesetzt werden, um die Abarbeitung bis zu einem spezifischen Punkt laufen zu lassen und dann die aktuelle Stelle der Transformation genauer zu untersuchen.

Datenbanken

Die Datenbankwerkzeuge wurden um die Möglichkeit erweitert, erstellte Datenbankschemas direkt über eine JDBC-Datenbankverbindung auf einer Datenbank anzuwenden. Der Entwickler muss nun nicht mehr datenbankspezifische Werkzeuge verwenden, um ein Datenbankschema zu installieren. Außerdem wurde der DB2 Stored Procedure Builder in den WSAD integriert, mit dem sich nun in der Entwicklungsumgebung datenbankseitige Funktionen für die hauseigene Datenbank erstellen und verwalten lassen. Darüber hinaus können auch DB2 User Defined Functions (UDF) im WSAD entwickelt und auf der Datenbank angewendet bzw. von einer Datenbank importiert werden.

Test und Profiling

Eine neue Funktionalität des WSAD 5 sind die Component Tests. Hier hat der Entwickler die Möglichkeit, Testfälle zu definieren und auszuführen. Es stehen drei Typen von Testfällen zur Verfügung: Manuell, Java und HTTP. Die erzeugten Testfälle lassen sich dann innerhalb des WSAD ausführen. Für jeden Testlauf kann ein Report generiert werden, der die Testergebnisse aufzeichnet.
Die Profiling-Funktionalität wurde im WSAD 5 ebenfalls erweitert. Neu hinzugekommen ist ein Sequence Diagram View, der die aufgezeichneten Daten aus den Performanzmessungen in Form eines Sequenzdiagramms – entweder für Klassen oder Objekte – darstellt. Ebenfalls neu ist der J2EE Request Profiler, der innerhalb eines WebSphere Application Servers läuft, die Interaktion zwischen verschiedenen J2EE-Komponenten aufzeichnet und die Daten so aufbereitet, dass in den unterschiedlichen Views des WSAD diese Informationen angezeigt werden. So kann beispielsweise aufgezeichnet werden, wann welches Servlet welche Methoden einer EJB aufruft.

Fazit

Neben Verbesserungen, die sich aufgrund der Verwendung von Eclipse 2 als Basis für den WSAD 5 ergeben, sind in allen Bereichen Neuerungen und Verbesserungen umgesetzt worden. Der Entwickler enthält also mit der Version 5 ein sehr mächtiges Werkzeug, welches es ihm ermöglicht, seine Entwicklungsaufgaben mit beträchtlicher Effizienz durchzuführen. Schon allein wegen der vielen kleinen Verbesserungen lohnt es sich eigentlich bereits, WSAD 5 einzusetzen. Doch die neuen Features, wie beispielsweise die Funktionalität für Component Test, XSL Debugging und natürlich die Unterstützung von J2EE 1.3, machen den Einsatz dieser Version mittelfristig geradezu unvermeidbar. Ein rundum gelungenes Produkt.

Links & Literatur

•	www.ibm.com/websphere/developer/zones/studio/appdev/
•	Stefan Mathias Aust, Michael Rusitska: „Die zweite Sonnenfinsternis“ in: Java Magazin 11/2002
•	www7.software.ibm.com/vad.nsf/data/document4293