Die Paketverstärkung

Die NetBeans-Erweiterungspakete im Überblick

Daniel Adelhardt und Jens Trapp

Es gibt mittlerweile eine ganze Reihe von Erweiterungsmöglichkeiten für NetBeans: Zum einen gibt es Module, mit denen spezielle Techniken oder Tools integriert werden können. Zum anderen findet man aber auch so genannte „Packs“, die das Einsatzgebiet der IDE auf Bereiche wie Mobile-, Enterprise- und C/C++-Entwicklung ausweiten.

Neben der Java-Entwicklungsumgebung NetBeans gab es bei Sun schon immer eine Reihe weiterer Entwicklungswerkzeuge. Vor einiger Zeit nun wurde beschlossen, dass alle diese Tools auf der NetBeans-Plattform basieren sollten. Allerdings waren sie bis vor kurzem nur als eigenständige Produkte verfügbar und konnten nicht in die aktuellen Versionen der NetBeans-IDE integriert werden. Mittlerweile hat sich dies geändert. Es ist Ziel, alle von Sun bereitgestellten Tools so zu entwickeln, dass sie als Erweiterung der IDE verwendet werden können. Mit diesem Wechsel geht einher, dass die NetBeans Packs im Gegensatz zu den früheren Produkten kostenfrei nutzbar sind. Auch wenn es die Packs nicht mehr als kommerzielle Produkte gibt, hat man natürlich die Möglichkeit, sich mit verschiedenen Support-Angeboten eine professionelle Unterstützung einzukaufen.

Im Gegensatz zur Erweiterung mit einzelnen Plug-in-Modulen liefern die Packs Sammlungen zusammengehöriger Module und Bibliotheken für ein bestimmtes Einsatzgebiet. Die Größe der Packs ist dabei teilweise recht erheblich, was auch der Grund ist, sie nicht von vornherein mit der Basis-IDE zu bündeln. Darum werden sie als „Packs“ in getrennten Downloads zur Verfügung gestellt. Mittlerweile sind fünf verschiedene Packs öffentlich verfügbar.

  • Profiler für Performance-Analyse und Tuning von Java-Applikationen
  • Enterprise Pack für die Entwicklung von Unternehmensapplikationen
  • Mobility Packs für die Entwicklung von mobilen Applikationen auf Basis von Java Micro Edition CDC und der CLDC (je ein eigenes Pack)
  • C/C++ Pack für die Entwicklung von nativen Applikationen fÜr die drei Betriebssysteme Solaris 10, Linux und Windows XP

Auf der Java One wurde außerdem angekündigt, dass der bisher nur als eigenständiges Produkt implementierte Sun Java Studio Creator bald auch als Visual Web Development Pack zur Verfügung gestellt wird. Ein Vorteil des Creator ist die visuelle Unterstützung der JSF-Webentwicklung, womit es einfach ist, komplexe Web- und Portalapplikationen in relativ kurzer Zeit zu entwickeln.

Der Profiler

Im produktiven Einsatz von Programmen gibt es immer wieder Probleme mit dem Laufzeitverhalten. Applikationen sind zu langsam, reagieren nicht mehr oder es kommt zu Programmabstürzen, wenn kein Speicher mehr zur Verfügung steht. Die Ursachen sind typischerweise nicht so leicht mit einem Debugger zu finden, da die Probleme erst unter hoher Last, bei vielen gleichzeitigen Zugriffen oder nach langer Laufzeit auftreten. Um die Fehler im Programm zu finden, benötigt man eine statistische Auswertung über eine größere Anzahl und Dauer von Methodenaufrufen oder eine Analyse, in welchen Programmteilen viel Speicher verbraucht wird. Hierzu setzt man einen Profiler ein, der die notwendigen Daten während der Laufzeit sammelt und dann in aufbereiteter Form darstellt. Dabei ist es wichtig, dass für das Sammeln der Daten nicht zu viel zusätzliche Last entsteht, der Profiler die Laufzeiteigenschaften der Applikation also nicht zu sehr beeinflusst.

Mit dem NetBeans Profiler steht den Entwicklern ein Werkzeug zur Verfügung, mit dem man den beschriebenen Problemen in Java-Applikationen, Applets und Java EE-Anwendungen auf den Grund gehen kann. Um den Zeitverlust während der Analyse möglichst gering zu halten, hat man die Möglichkeit, das Sammeln der Daten auf wenige Methoden zu beschränken. Weiß man also bereits ungefähr, welche Stelle bezüglich Performance oder Speicherallokation kritisch sein könnte, kann man die Suche auf diesen Bereich konzentrieren, ohne die anderen Programmteile zu beeinflussen. Mit dem Profiler kann die Rechenzeit (CPU Time) von allen oder einzelnen Methoden gemessen werden, um zu ermitteln, wo die Applikation viel Zeit benötigt. Mithilfe des Memory Profiling kann man erkennen, in welchen Bereichen viele Objekte erzeugt werden. Außerdem kann man Speicherlöcher (Memory Leaks) finden, bei denen die Applikation Referenzen auf nicht mehr benötigte Objekte nicht freigibt, wodurch die Objekte während der Garbage Collection nicht gelöscht werden können.

Entstanden ist der NetBeans Profiler als Projekt in den SunLabs unter dem Codenamen JFluid. Ursprünglich war er als unabhängiges Werkzeug für die Analyse von Speicher-, Performance- und Threading-Problemen entwickelt worden. Die Integration mit NetBeans liefert jetzt ein komfortables User Interface inklusive grafischer Auswertung der Messdaten. Damit wird die Analyse von Java-Applikationen mit NetBeans vereinfacht, sodass sie ohne großen Aufwand in den Entwicklungsprozess eingebunden werden kann.

Der Profiler kann mit NetBeans-Projekten, aber auch mit Programmen, die nicht in NetBeans entwickelt wurden, genutzt werden. Applikationen können lokal oder auf einem anderen Rechner laufen. Ist für das Profiling mit JDK 1.4.2 noch ein modifiziertes JDK notwendig, werden seit Java 5 die mittlerweile standardisierten Tool-Schnittstellen benutzt. Hierfür muss die Applikation mit entsprechenden Laufzeitargumenten gestartet werden. Der Profiler unterstützt die Plattformen Solaris (SPARC und x86), Windows, Linux und Mac OS X.

Liegt die Applikation als NetBeans-Projekt vor, ist ein Start der Analyse über das Menü möglich. Da NetBeans das Ant-Build-System als Grundlage benutzt, muss für diesen Vorgang ein neues Target in das Build Script eingefügt werden. Dies geschieht automatisch, insofern das Build Script von NetBeans angelegt wurde. Wenn das Projekt mit bestehenden Build Scripts arbeitet, muss das Target leider selbst eingefügt werden. Wie in diesem Fall vorzugehen ist, ist entweder in der Tool-Hilfe oder im Kapitel 16 des NetBeans Field Guide nachzulesen.

Um sich einen überblick über die Applikation zu verschaffen, kann man das Monitoring der Threads einschalten. Hierbei wird die Applikation nicht verlangsamt, da nicht in die JVM eingegriffen werden muss. Man erhält eine übersicht über den Speicherbedarf und die verwendeten Threads sowie deren Aktivitäten. Dadurch lässt sich beispielsweise erkennen, ob ein Speicherloch vorliegt, wenn der genutzte Speicher trotz fortlaufender Garbage Collections im Laufe der Zeit immer weiter zunimmt (Abb. 1).

Abb. 1: Beim Monitoring von Applikationen werden der Speicherbedarf und die Threads angezeigt.

Um einem Speicherloch weiter auf den Grund zu gehen, kann man die Speicheranalyse starten (Memory Analysis). Hiermit kann man die Stellen im Programm finden, in denen übermäßig viele Objekte erzeugt werden. Zusätzlich kann auch das Löschen von Objekten mittels Garbage Collection registriert werden, was für das Finden von Speicherlöchern notwendig ist. Dies liefert dann auch die Anzahl der noch genutzten Objekte, deren Speicherverbrauch sowie Informationen darüber, wie lange die Objekte durchschnittlich existieren. Um die Verursacher zu finden, kann man sich die Stellen im Programmablauf (Call Stack) zeigen lassen, wo die Objekte erzeugt wurden. Da das Memory Profiling – insbesondere auch unter Berücksichtigung der Garbage Collection – viel Rechenzeit in Anspruch nehmen kann, ist es sinnvoll, die Suche auf einzelne Klassen einzuschränken. Hierzu sortiert man die angezeigten Ergebnisse so, dass die interessanten Bereiche am Beginn der Tabelle stehen; durch Menüauswahl kann man dann alle Objekte ab einer bestimmten Zeile von der Analyse ausgrenzen.

Für die Messung des CPU-Verbrauchs hat man ebenfalls die Möglichkeit, die Analyse auf Teile der Applikation zu beschränken. Hierzu erhält man zum einen die Möglichkeit, Filter zu setzen, sodass ganze Pakete oder Klassen ausgenommen werden. Zum anderen kann man die Analyse auf eine Root-Methode einschränken. Die Messung beschränkt sich dann auf die Methodenaufrufe, die im Rahmen der Root-Methode erfolgen. In der Darstellung der Ergebnisse kann man sich die aufgerufenen Methoden in einer Art Call Stack anzeigen lassen. Hierbei sieht man die Anzahl der Aufrufe und die verbrauchte Zeit, inklusive aller Untermethoden. In einer zweiten Ansicht kann man sich dann ansehen, wie viel die Methode selbst, also ohne die darin enthaltenen Untermethoden, verbraucht hat (Abb. 2).

Abb. 2: Das CPU Profiling liefert detaillierte Informationen zu den einzelnen Methodenaufrufen.

Für die Analysen kann man sich jeweils die momentan aktuellen Profiling-Daten anzeigen lassen. Für einen späteren Vergleich können Ergebnisse aber auch als Snapshots gespeichert werden. Außerdem hat man die Möglichkeit, alle Zähler zurückzusetzten, was wichtig ist, wenn man die Analysen erst nach einer Vorlaufzeit (Warm-up) beginnen möchte.

Zum Schluss noch eine kleine Warnung: Bei der Analyse des Laufzeitverhaltens sollte man darauf achten, dass man die Applikationen immer unter produktionsähnlichen Szenarien testet. Verbesserungen, die auf dem Rechner des Entwicklers gut sind, können auf großen Servern manchmal zu katastrophalen Folgen führen. Es gilt die goldene Regel, dass man nichts optimieren sollte, wenn kein Problem besteht. Für sinnvolle Verbesserungen benötigt man etwas Erfahrung. Das Gute ist, dass man diese Erfahrung mit dem NetBeans Profiler sammeln kann.

Sind Sie mobil?

Es gibt schon seit relativ langer Zeit eine NetBeans-Variante für die Entwicklung von Java ME-Applikationen. Mittlerweile ist aus dem ursprünglich eigenständigen Produkt ebenfalls ein Add-on-Paket für NetBeans geworden. Mit diesem Paket können Applikationen, so genannte Midlets, auf Basis der CLDC (Connection Limited Device Configuration) entwickelt werden. In diese Geräteklasse fallen die meisten Mobiltelefone mit Java VM. Vor kurzem ist ein weiteres Pack für die Unterstützung von Geräten auf Basis der CDC (Connected Device Configuration) hinzugekommen. CDC zielt insgesamt auf Geräte mit etwas leistungsstärkeren CPUs (vor allem im Vergleich zu den Mobiltelefonen, die vor einigen Jahren verfügbar waren). In letzter Zeit stoßen aber auch immer mehr Mobiltelefone in diese Klasse vor, und so können mit dem Mobility Pack für CDC beispielsweise Applikationen für die Sony-Ericsson-CDC-, die Nokia-80-Serie- und die Savaje-Mobile-Plattformen entwickelt werden.

Im Java ME-Umfeld ist es typisch, dass die Zielgeräte sich in ihren charakteristischen Eigenschaften, wie etwa Speicherplatz, Bildschirmgröße oder auch in ihren Möglichkeiten (Bluetooth, Location APIs etc), stark unterscheiden. Dies hat zu der so genannten Device Fragmentation geführt, bei der eine Applikation für jedes Endgerät angepasst werden muss. Das NetBeans Mobility Pack hilft den Entwicklern hierbei, indem es die möglichen Endgeräte als Konfigurationen speichert.

Für jedes Endgerät muss ein Emulator, den man vom jeweiligen Hersteller erhält, als Zielplattform in NetBeans registriert werde. Mithilfe einer eigens entwickelten Schnittstelle können die Möglichkeiten der Emulatoren und damit der Endgeräte erfasst werden. Die IDE nutzt diese Information, um die Klassenpfade bezüglich der unterstützen APIs zu setzen. Hierdurch werden auch die Code-Prüfung und die Code Completion entsprechend angepasst, sodass nur gültige APIs benutzt werden. Außerdem werden Bildschirmparameter wie Größe und Farbe an die Zielplattform angepasst. Die Applikationen können auf den Emulatoren getestet, je nach Gerät auch direkt auf das Endgerät übertragen oder sogar dort auf Fehler untersucht werden (On Device Debugging).

Abb. 3: Mithilfe des grafischen Editors können grafische Benutzerschnittstellen schnell zusammengebaut werden.

Eine der großen Stärken für die CLDC-Entwicklung ist der grafische Editor im Mobility Pack. Mit diesem ist es einfach, einzelne Bildschirmseiten grafisch zu entwickeln und mithilfe der Maus den Fluss zwischen den verschiedenen Seiten zu modellieren. Für die CDC steht ein visueller UI-Editor auf Basis des beliebten Matisse GUI Builder zur Verfügung (Abb. 4).

Abb. 4: Für die Entwicklung von Benutzerschnittstellen steht bei CDC-Applikationen der Matisse GUI Builder zur Verfügung.

Weitere hervorzuhebende Features im Mobility Pack sind beispielsweise die Unterstützung von Unit-Tests auf Basis des J2MEUnit-Test-Frameworks, die Integration von Optimierung und Obfuscation, mit denen der resultierende Bytecode gesichert und komprimiert wird. Für CLDC hat man mithilfe des mitgelieferten J2ME Wireless Toolkit noch viele weitere Möglichkeiten, wie etwa die Verwaltung von Zertifikaten und die Möglichkeit, Applikationen zu signieren.

Um denselben Code für unterschiedliche Plattformen zu benutzen, bietet NetBeans Unterstützung für einen Preprozessor mittels Direktiven à la ifdef/else/endif. Den C-Programmierern unter Ihnen sind diese Anweisungen sicherlich bekannt. Mithilfe dieser Direktiven ist eine bedingte Kompilierung möglich, d.h., bestimmte Code-Fragmente werden nur übersetzt, wenn in der Direktive die richtige Plattform spezifiziert ist. Eingeleitet werden die Direktiven mit „//#“, wodurch sie von normalen Java-Editoren als Kommentar erkannt und ansonsten ignoriert werden.

Bei der Arbeit mit Java ME-Applikationen muss man aufgrund der schwächeren Endgeräte mit einigen Einschränkungen leben. Bei CLDC ist nur ein eingeschränkter Sprachumfang der Java-Sprache erlaubt. Damit scheiden natürlich auch viele lieb gewonnene Zusatzbibliotheken aus, da sie nicht kompatibel sind. Die CDC hat zwar den gleichen Sprachumfang wie die Standard Edition, aber einige in der Java SE mitgelieferten APIs sind nicht in der CDC enthalten. Mithilfe der IDE kann man gut erkennen, welche Möglichkeiten einem zur Verfügung stehen, und darum ist eine Einarbeitung in die Java ME-Plattformen auch ohne große Vorkenntnisse möglich. Für den Einstieg empfehlen sich auch hier die im Internet frei verfügbaren Tutorials und, insbesondere für die CLDC-Entwicklung, auch der NetBeans Field Guide.

Java und C nebeneinander

Das im Moment jüngste Mitglied in der Familie der Packs ist das C/C++ Pack (Abb. 5). Es wird wie NetBeans selbst als Open Source entwickelt. Im Moment befindet es sich noch im Beta-Stadium. Diese Erweiterung bietet Entwicklern von nativen Applikationen den gleichen Komfort wie Java-Entwicklern. Der Editor unterstützt für Source- und Header-Dateien nicht nur die farbliche Codierung der C-Syntax (Syntax Highlighting), sondern auch Code Completion, Einrückung des Codes, Klammerprüfungen sowie die Möglichkeit, mittels Mausklick zu Unterfunktionen zu springen. Es gibt Unterstützung für existierende Makefiles, die analog zu den Ant-Build-Skripten benutzt werden können.

Für die Übersetzung des Codes benötigt man einen C- oder C++ Compiler, denn das Paket liefert keinen eigenen mit. Dabei werden natürlich die Sun Compiler, die es mittlerweile außer für Solaris auch für Linux gibt, sowie der gcc unterstützt. Für Windows werden neben dem gcc auch MinGW und Microsoft Visual C++ unterstützt. Als Debugger wird gdb unterstützt.

Abb. 5: Das C/C++ Pack unter Windows XP. Mittels Code Completion kann man sich passende Alternativen in einem Pop-up-Menü zeigen lassen.
Add-ons für Unternehmensapplikationen

Im Standardumfang des NetBeans-Download ist bereits alles an Modulen enthalten, um sowohl Java-Client- als auch komplexe Java-Enterprise-Anwendungen zu bauen. Das NetBeans Enterprise Pack umfasst deshalb eine Sammlung von Plug-ins, die den Anwendungsbereich der IDE deutlich über die Entwicklung für die gängigen Java-Plattformen hinaus vergrößern. Im Einzelnen umfasst das Pack:

  • eine UML 2.0-Modellierungskomponente
  • Plug-ins zur Bearbeitung von XML Schemas
  • Laufzeitumgebung und IDE-Plug-ins fÜr Java Business Integration (JBI)
  • Unterst&uumtzung fÜr die Business Process Execution Language (BPEL) 2.0
  • Integration von Identity-Management bzw. Single-Sign-on-Fähigkeiten mit dem Projekt OpenSSO

Bei der Installation des Enterprise Pack kann man die Module einzeln selektieren, da anzunehmen ist, dass nicht jeder Entwickler alle Aspekte des Packs benötigt.

UML-Plug-in

Neu für NetBeans-Anwender ist die direkte Unterstützung von UML in der IDE. Bislang gab es hierzu nur Module von Drittherstellern. Das Enterprise-Pack-UML-Plug-in integriert sich dabei in NetBeans als neuer Projekttyp. Über das Projektverwaltungsmenü sind unter dem Punkt UML drei verschiedene UML-Projekte auswählbar:

  • Platform-Independent Model: Dieser UML-Projekttyp wird fÜr reine Modellierungsprojekte ohne Sourcecode-Generierung genutzt.
  • Java Platform Model: Über die Auswahl dieses Projekttyps können optional UML-Modellierungsprojekte mit separaten NetBeans-Java-Projekten assoziiert werden. Damit kann dann eine bidirektionale Synchronisierung zwischen UML-Modell und Java-Sourcecode erfolgen.
  • Java-Platform Model by Reverse Engineering: Wenn bereits umfangreicher Sourcecode in bestehenden Java-Projekten existiert, dann kann dieser auch über Reverse Engineering des Projektes in das UML-Projekt importiert werden.

Die Unterstützung für UML durch das NetBeans-Plug-in ist sehr umfangreich. Als Diagrammtypen für die Modellierung stehen Klassen-, Aktivitäts-, Zustandsdiagramme, Deployment-, Sequenz-, Komponenten-, Kollaborations- und Use-Case-Diagramme zur Verfügung. Innerhalb der jeweiligen Diagramme können auch die UML 2-Konstrukte benutzt werden.

Abb. 6: UML-Plug-in des NetBeans Enterprise Pack

Wer bestehenden Sourcecode per Reverse Engineering in UML-Diagramme überführen möchte, der kann dies ohne viel Aufwand bewerkstelligen. Durch die Verknüpfung des UML-Projektes mit einem Java-Projekt werden die Quellen des Java-Projektes analysiert und automatisch als Modellelemente importiert. Nach dem Import kann dann entweder im Code oder im Modell gearbeitet werden – die Synchronisierung aktualisiert beide Teile fortlaufend im Hintergrund. Eine Besonderheit der Code-Modell-Synchronisierung ist, dass der Sourcecode frei von Metainformation über das Modell bleibt (Abb. 7).

Abb. 7: Reverse Engineering einer Methode als Sequenzdiagramm

Wer häufig vor der Aufgabe steht, bestehenden Code zu dokumentieren, der wird auch Gefallen an der Möglichkeit finden, die Implementierung einzelner Methoden automatisch als Sequenzdiagramme visualisieren zu lassen. Dazu werden einfach im Klassendiagramm die Operation einer Klasse und im Kontextmenü die Option „Reverse Engineer Operation“ selektiert. Für die Darstellung kann man dann zwischen Sequenz- und Kollaborationsdiagrammen wählen.

Ebenfalls ein nützliches Feature der UML-Komponente ist der eingebaute Report-Generator. Aus dem Projekt lässt sich eine komplette HTML-Dokumentation aller Modellelemente und Diagramme erzeugen. Wahlweise können aber auch einzelne Diagramme als Grafik in diversen Formaten exportiert werden.

XML-Plug-in

Für Entwicklungsumgebungen ist adäquate Unterstützung von XML seit geraumer Zeit ein Muss. So bietet auch NetBeans in der IDE als Standard-Plug-ins bereits einige Möglichkeiten, XML-Dokumente, DTDs oder Schemas zu erstellen bzw. zu verarbeiten. Bislang wurde hierfür jedoch ein Editor-zentrischer Ansatz gewählt. Mit dem XML-Plug-in im Enterprise Pack geht man nun neue Wege. Man hat erkannt, dass die rein textuelle Erstellung und Darstellung von großen Schema-Dateien im Editor nicht sonderlich intuitiv ist. Das neue XML-Plug-in bietet deshalb verschiedene Varianten, um Schemas grafisch aufzubereiten sowie zu editieren. Neben der einfachen Source-Ansicht existiert eine Baumansicht, eine mehrspaltige Ansicht der Schema-Bestandteile sowie eine grafische Designansicht.

Ein weiteres innovatives Feature des Plug-ins ist die Analyse von Abhängigkeiten in der Schema-Datei. Wenn man herausfinden möchte, an welchen Stellen im Schema Elemente referenziert werden, so nutzt man im Kontextmenü die Option „find Usages“. Dies öffnet zum einen die XML-Refactoring-Ansicht für die Darstellung der Abhängigkeiten, zum anderen wird auch ein grafisches Modell (angelehnt an UML-Klassendiagramme) angezeigt.

Abb. 8: NetBeans Enterprise Pack XML Pack: Analyse und Refactoring von XML-Schema-Dateien

Auch um die Erstellung von XML Schemas zu vereinfachen, wurden neue Wege beschritten. Per Drag & Drop zieht man Schema-Konstrukte wie Attribute, Elemente oder komplexe Typen aus der NetBeans-Komponentenpalette und platziert diese im Editor Canvas. Natürlich kann immer zwischen der Source-Ansicht und der grafischen Darstellung gewechselt werden.

Abb. 9: NetBeans Enterprise Pack XML Pack: grafische Schema-Erstellung
SOA mit NetBeans

Die NetBeans-Umgebung unterstützt in Version 5.5 ja bereits die vereinfachte Java EE 5, APIs für EJBs und Web Services. Aufbauend auf diesen Technologien ermöglichen die SOA-Plug-ins nun die Orchestrierung entsprechend erstellter Services. Das Ziel der Entwicklung ist es, über die Orchestrierung so genannte Composite Applications zu bauen. Anstelle einer klassischen, oft monolithisch entwickelten Applikation möchte man bei Composite Applications einzelne feingranulare Dienste aggregieren und Dienste über eine Prozesssteuerung, meist in Form einer BPEL Engine, verknüpfen. Für diese neuen und sehr komplexen Aufgabenstellungen bringt das Enterprise Pack gleich eine ganze Reihe von Erweiterungs-Plug-ins mit sich:

  • JBI-Unterstützung: Die Version 5.5 von NetBeans wird bereits mit dem Glassfish Application Server ausgeliefert. Das Enterprise Pack erweitert diese Installation noch um den JBI-Container. Bei der verwendeten Implementierung handelt es sich um eine vereinfachte, Single-JVM-Variante des OpenESB-Projektes. Bestandteil der Installation sind auch diverse JBI-Komponenten, wie eine JAX-WS-SOAP-Binding-Komponente sowie eine Java EE Service Engine, um Java EE-Komponenten innerhalb des JBI-Containers nutzen zu können.
  • BPEL 2.0-Unterstützung: Für die Orchestrierung von Services wird auf BPEL zurückgegriffen. Das Enterprise Pack bietet hierfür neben der entsprechenden Modellierungskomponente sowie Erweiterungen für Test und Debugging auch eine BPEL Runtime. Die mitgelieferte Open Source BPEL 2.0 Engine von Sun installiert sich ebenfalls als JBI Service Engine in die Lauftzeitinfrastruktur von Glassfish und OpenESB.
  • Web Services Federation: Optional wird auf Glassfish auch der Sun Java System Access Manager (Projekt OpenSSO) mit deployt. Über diese Runtime und entsprechende IDE-Plug-ins können Web Services konfiguriert werden, die zum Beispiel SAML bzw. WS-Security Token Profile benutzen.

Über das Projektverwaltungsmenü kann bei installiertem Enterprise Pack die Kategorie „Service Oriented Architectures“ ausgewählt werden. Dort stehen zwei Projekttypen zur Auswahl: BPEL Module und Composite Application. Composite-Application-Projekte sind von der Struktur her vergleichbar mit Java EE-Projekten, nur mit dem Unterschied, dass ein Deployment für einen JBI-Container erzeugt wird. Im Sinne der JBI-Spezifikation entspricht ein solches Composite-Application-Projekt einer Service Assembly, enthält also im Wesentlichen nur einen jbi.xml-Deskriptor sowie weitere Deployment-Artefakte in Form von Service Units. Eine solche enthaltene Service Unit kann zum Beispiel ein BPEL-Projekt sein, das die BPEL-Prozesse sowie WSDL- und Schema-Dateien enthält. Der Entwickler muss sich aber dank des IDE-Plug-ins keine Gedanken über das korrekte Packaging und die Erstellung der JBI-Deskriptoren machen – dies erfolgt automatisch beim Build- und Deploy-Vorgang. Um ein BPEL-Projekt deployen zu können, muss dieses über das Kontextmenü der IDE (per „Add JBI Module“) einem Composite-Application-Projekt als Modul hinzufügt werden. Danach kann das Projekt gebaut und direkt auf den JBI-Container deployt werden.

Ein weiteres Feature des SOA-Plug-ins stellt der grafische BPEL Designer dar. Über diesen können per Drag & Drop aus der Palette die BPEL 2.0-Konstrukte auf das Designfenster gezogen werden. Das Plug-in weist dabei bereits während des visuellen Designs auf potenzielle Modellierungsfehler hin. Das Mappen von Input- und Output-Parametern von Prozessaktivitäten sowie einfache Operationen – zum Beispiel String-Manipulation, Boolesche Operationen, oder einfache Vergleiche – können ebenfalls visuell über den integrierten BPEL Mapper durchgeführt werden. Auch Unterstützung für das Testen und Debuggen von BPEL-Prozessen wurde integriert. So können im BPEL-Prozess Debugger Breakpoints gesetzt und die Prozessaktivitäten schrittweise durchlaufen werden. Auch an Unterstützung von Unit-Tests auf Prozessebene wurde gedacht: Zu Prozessen können Input-Dateien hinterlegt werden. Diese werden dann beim Testdurchlauf mit Ergebnis-Templates verglichen. Auf diese Art und Weise kann die fehlerfreie Prozessausführung zum Beispiel nach Re-Designs einfach getestet werden.

Abb. 10: NetBeans Enterprise Pack BPEL Designer und Mapper
Fazit

Im Verlauf der letzten Monate ist rund um das NetBeans-Projekt vieles an innovativen Projekten entstanden. Die Entwicklungsumgebung hat ihre klassische Java SE-Domäne längst verlassen und deckt mittlerweile alle Bereiche der Java-Entwicklung und auch viele darüber hinausgehende Aspekte ab. Auch die Roadmap für die nächsten Releases zeigt, dass noch jede Menge spannende neue Features zu erwarten sind, die NetBeans durchaus zu einer ernst zu nehmenden IDE-Alternative machen.

Daniel Adelhardt und Jens Trapp arbeiten beide als Softwarearchitekten mit Schwerpunkt Java- und Java EE-Architekturen bei Sun Microsystems.
Geschrieben von
Daniel Adelhardt und Jens Trapp
Kommentare

Schreibe einen Kommentar

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