J2EE: Applikationsentwicklung verliert an Komplexität

24.11.2003
Von Evgenia Rosa

Sehr viel komfortabler geht es zu, wenn die Entwicklungsumgebungen die Arbeit des Programmierers mit grafischen Werkzeugen unterstützen, so durch Wizards, die grafische Modellierung auf Basis der Unified Modelling Language (UML) mit Klassen- und Aktivitätsdiagrammen sowie durch eine automatische Generierung von Java-Klassen und XML-Dateien. Daneben gehören Features wie Tuning, Debugging sowie Monitoring von Web-Services zum Leistungsumfang der meisten Programmier-Tools.

Bei der Entwicklung von Web-Services lassen sich sowohl bestehende Programme entsprechend aufbereiten als auch neue Anwendungen schreiben. Für eine neue Anwendung programmiert der Entwickler wie gewohnt seine Geschäftslogik zum Beispiel in Form von Java-Klassen. Hierbei werden Applikationen in "stateless" oder "statefull" unterschieden, wobei sich Anwendungen ersteren Typs einen Status nicht merken. Wer für die Erstellung von Web-Services Anwendungen benutzen möchte, die sich den Status merken, muss sich derzeit mit Cookies behelfen. Hier ist der Programmierer jedoch nicht gezwungen, selbst Hand anzulegen, sondern der Application Server benutzt in diesem Fall automatisch den Cookie-Mechanismus. Dieser Weg ist allerdings nicht standardisiert, beim Wechsel auf eine andere Ablaufumgebung kann also ein Änderungsaufwand entstehen. Weitere Implementierungen von Logik können unter anderem stateless Enterprise Javabeans (EJBs), JMS Destination oder auch Datenbankanwendungen wie

SQL-Prozeduren und Java-Stored-Procedures sein.

Im zweiten Schritt legt der Entwickler nun ein J2EE Enterprise Archive (EAR) an. Die meisten Entwicklungs-Tools unterstützen das. Dabei wird ein WSDL-Interface, das beschreibt, wie man den Service aufrufen kann, automatisch erzeugt. Gleichzeitig erfolgt die Generierung aller technischen Klassen: ein Client-Stub oder auch Proxy sorgt dafür, dass Java-Aufrufe auf der Client-Seite in Soap-Nachrichten übersetzt werden, und ein Server-Skeleton überträgt Server-seitig die Soap-Aufrufe in die Sprache der Dienstimplementierung etwa in Java.

Für den Client-Entwickler stehen Java-APIs zur Verfügung, so dass er Soap-Nachrichten nicht per Hand erzeugen muss. Der Grund: Entwickler kennen sich mit Java aus und sollen sich nicht unnötig mit Soap-Implementierung befassen müssen.