Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

11.02.2000 - 

Spezifikationen kein Allheilmittel

OOP 2000: Der steinige Weg zu verteilten Systemen

MÜNCHEN (as) - Die Eroberung der Server durch Java und Corba ist in vollem Gang. Doch der großflächige Einsatz von komponentenbasierten Systemen bleibt eine Herkulesaufgabe, da weder die Standards noch die Tools ausreichend Hilfe bei der Analyse und dem Design solcher Anwendungen bieten.

Java bewährt sich in der Praxis - trotz vieler Probleme im Detail. Bereits heute ist der Einsatz der Sprache für verteilte Client-Server-Anwendungen verbreiteter als in der reinen Client-Entwicklung. So schätzen die Analysten der Giga Group, dass Mitte 1999 bereits über 60 Prozent aller Java-Entwickler in erster Linie für den Server programmiert haben, wobei vor allem Techniken wie Java Serverpages (JSP), Java Servlets und Remote Method Invocation (RMI) genutzt wurden. Zugleich beginnen immer mehr Unternehmen hierzulande, auch Server-basierte Geschäftslogik gemäß den Spezifikationen des Komponentenmodells Enterprise Javabeans (EJB) zu entwickeln.

Auf der diesjährigen Entwicklermesse für Objektorientiertes Programmieren (OOP) und der ihr angeschlossenen Java-Konferenz stellten die Erfahrungen mit der Sun-Sprache einen Schwerpunkt der Vorträge dar. Gernot Starke, Mitarbeiter der Unternehmensberatung Schumann, beschrieb seine Erfahrungen mit Java auf dem Server am Beispiel des Börseninformationssystems "ITZ Börse" des Informationstechnikzentrums Köln. Die Anwendung wird derzeit von 250 Sparkassen genutzt und versorgt deren Kunden mit aktuellen Daten von den Aktienmärkten und verwaltet ihre Wertpapierportfolios. Grundlage ist eine Servlet-Architektur auf einem Web-Server, die HTML-Seiten für die Clients generiert und die Anbindung zu weiteren Anwendungen herstellt. Bei letzteren handelt es sich um relationale Datenbanksysteme für die Speicherung der aktuellen Kursinformationen sowie zur Verwaltung der Benutzerprofile, eine Anwendung für historische Börsendaten, ein SMS-Gateway sowie weitere Internet-Dienste.

Von eitlem Sonnenschein kann jedoch bei der Server-seitigen Java-Nutzung nicht immer die Rede sein, sagt Starke. Vielmehr müssen Entwickler bei der Anwendungsintegration über Java manche Klippen umschiffen. So bestehe beispielsweise die Gefahr, dass bei einer geforderten Wiederverwendung von bestehenden Anwendungen oder Teilen daraus auch deren nachteilige Eigenschaften in Form von Java-Klassen abgebildet werden und somit in der neuen Architektur weiter existieren. Zudem blieben die derzeit erhältlichen Java Virtual Machines unter den Unix-Derivaten AIX und Solaris laut Starke in der Leistung deutlich hinter denen für die Intel-Plattform zurück.

Weitgehend Forschungscharakter hat der Einsatz von Java bisher auch, wenn es um die Entwicklung hochverfügbarer Anwendungen geht, deren Ausfallrisiko bei weniger als 0,1 Prozent liegt (High Availability Computing = HACMP). Insgesamt glauben aber Starke und mit ihm die meisten Redner auf der OOP, dass spätestens mit dem Erscheinen der Java 2 Enterprise Edition (J2EE) eine stabile und leistungsstarke Plattform zur Verfügung steht. So kommen etwa mit Version 1.1 der EJB-Spezifikationen wichtige Neuerungen wie die obligatorische Nutzung von "Entity Beans", XML-Deployment-Deskriptoren, ein erweitertes Sicherheitskonzept (deklarative Attribute für die Autorisierung) sowie das Erzeugen eines Standard-JNDI-Kontextes (Zugriff der Beans auf Umgebungsvariablen) hinzu.

Trotz des großen Zuspruchs für Java ist nach Meinung von Experten jedoch nicht damit zu rechnen, dass sich eines der Komponentenmodelle EJB von Sun Microsystems, COM/DCOM von Microsoft oder Corba des Konsortiums Object Management Group (OMG) auf absehbare Zeit alleine durchsetzen wird. Vielmehr entwickeln sich Corba mit Release 3.0 und COM/DCOM durch sein Aufgehen in COM+ zu immer mächtigeren Plattformen. Immerhin ist eine spätere Ehe zwischen Java und Corba nicht ausgeschlossen. So nutzt die Sun-Sprache schon heute Corba als eine Möglichkeit zur Integration und damit Weiterverwendung von Anwendungslogik.

Auch sind Großprojekte auf Basis einer EJB-Architektur derzeit in Deutschland noch Mangelware. "Ich kenne keine zehn Anwendungen", resümierte etwa Marc Gille von der Micram AG. Dabei rühren die Probleme nicht in erster Linie von der fehlenden Reife der Java- oder Corba-Spezifikationen her, sondern liegen in der grundsätzlichen Komplexität einer verteilten Anwendungsentwicklung begründet. Beispielsweise ist der Umgang mit Transaktionalität oder Teststrategien für viele Entwickler Neuland.

IT-Abteilungen können heute zwar auf eine Reihe leistungsfähiger Entwicklungsumgebungen zugreifen, doch ist der Lern- und Zeitaufwand erheblich und eine umfassendere Unterstützung bei der verteilten Softwareentwicklung nicht vorhanden. Die derzeit viel besprochenen Applikations-Server helfen zwar beim Aufbau und der Kopplung verteilter, komponentenbasierter Architekturen weiter, indem sie Kommunikationsmechanismen und Dienste etwa für Transaktionen oder Sicherheit bieten. Für den eigentlichen strukturierten und geordneten Entwicklungsprozess bieten allerdings auch sie nur wenig. "Oft werden Produkte zuallererst gekauft, Methoden kommen hingegen zu kurz", klagt Micram-Vertreter Gille.

Anwender müssen jedoch im komplexen Geflecht verteilter Systeme funktionale und nichtfunktionale Anforderungen erfüllen, um das Risiko eines Scheiterns ihres Projektes zu reduzieren. Als Hilfestellung gibt es komplexe, objektorientierte Prozessmodelle für die Analyse und das Design wie der "Rational Unified Process" (RUP) oder die von Desmond D''Souza und Alan Cameron Wills entwickelte Methodik "Catalysis". Diese verwenden die Unified Modeling Language (UML), die sehr umfangreich und schwer zu nutzen ist. Doch erst die richtige Kombination aus Technologie (Sprache, Werkzeuge) und Entwicklungsprozess führt zum Erfolg in Projekten, in denen es um mehr als eine Web-Anbindung bestehender Client-Server-Systeme geht. Genau an diesem Punkt aber haben die meisten IT-Abteilungen Schwierigkeiten, über Analyse und Design zu einer auf die eigenen Erfordernisse zugeschnittenen Architektur zu kommen.

Einer der "Early Adapters", der die Problematik zur Genüge kennt, ist die Asea Brown Boveri AG (ABB). Christian Zeidler, Mitarbeiter der Abteilung Software Engineering im Forschungszentrum Heidelberg, weiß aus langjähriger Erfahrung, dass komponentenbasierte Entwicklung Schwerstarbeit ist. Zwar seien Fortschritte zu verzeichnen, da mittlerweile Komponenten bei der GUI-Entwicklung genutzt werden könnten, es grundlegende Anwendungsfunktionalität in Form von Komponenten zu kaufen gebe und als Referenzen die Modelle EJB, Corba und COM zur Verfügung ständen. Letztere allein helfen den IT-Abteilungen jedoch wenig und lassen bei der Entwicklung verteilter Systeme Fragen offen. Die Suche nach käuflichen, anwendungsspezifischen Bausteinen ist ferner meist erfolglos, und Standardkomponenten, wie sie etwa Frameworks wie "San Francisco" oder "Taligent" bieten, sind zu unspezifisch bezüglich ihrer Schnittstellen und des Verhaltens der angebotenen Komponenten. Außerdem seien derartige Rahmenwerke schwer zu verwenden, da eine große Zahl unterschiedlicher Klassen zu lernen sind.

Anwender müssen sich darauf einstellen, während des iterativen Entwicklungsprozesses mit einer Vielzahl schwieriger, domänenspezifischer Fragen konfrontiert zu werden (siehe Kasten "Checkliste"). Zugleich gibt es heute noch reichlich Lorbeer bei der Verbesserung vieler Einzelaspekte der komponentenbasierten Softwareentwicklung zu gewinnen. Beispiele hierfür sieht Zeidler etwa bei den heutigen Prozessmodellen wie RUP oder Catalysis. Diese sind sehr schwer zu erlernen, verlangen genaue Kenntnisse der UML und dienen bisher dennoch lediglich als Katalysatoren bei der Anwendungsentwicklung. Sie brauchen zusätzliche Werkzeuge und Techniken wie etwa "Patterns". Letztere dienen laut Zeidler zwar in erster Linie als Designvorlage für spezifische Anwendungsbestandteile. Sie können aber bei der Strukturierung einer komplexen Architektur in Subsysteme und in Form von "Design Patterns" bei deren weiterer Spezifizierung helfen.

Außerdem sind die heutigen Komponentenmodelle EJB, Corba und COM bisher zu wenig auf Anwendungsdomänen ausgerichtet. Der wachsende Einsatz von Frameworks zielt in diese Richtung ab, hilft jedoch bisher kaum bei der Umsetzung spezifischer, fachlicher Anforderungen. Zudem fordert Zeidler, dass neben den Schnittstellen-Spezifikationen auch eine Metabeschreibung der Komponenteninfrastruktur und des Verhaltens von Interfaces vorhanden sein sollte. "Ziel ist es, Werkzeuge zu erhalten, mit denen sich Bestandteile von Architekturen spezifizieren, grafisch darstellen, instanzieren und validieren sowie die Übereinstimmung von Anforderungen mit der existierenden Infrastruktur überprüfen lassen."

Wie nicht anders zu erwarten, geht es jedoch bei der objektorientierten und komponentenbasierten Entwicklung neben allen technischen und architekturspezifischen Details auch um kulturelle Probleme. Redner wie Paul Allen, Spezialist für Methoden bei Sterling Software, betonten, dass IT-Abteilungen Strategien benötigen, um das Management dauerhaft für das neue Entwicklungsparadigma zu gewinnen. Sie müssen ihren Chefs, den Fachabteilungen und renitenten Kollegen erklären, dass die von Herstellern und Gurus gebetsmühlenhaft gelobte leichte Wiederverwendbarkeit, Qualitätsverbesserung, Zeitersparnis sowie Distribution von Komponenten nur mittel- bis langfristig zu erzielen sind.

Es komme daher auf die richtige Unterteilung der Arbeiten in Mikro- und Makrostrategien an. Dabei müsse das IT-Team während des gesamten Projektverlaufs von vornherein die beteiligten Abteilungen einbinden, klare Rollen vergeben und auch hin und wieder eine Sprache sprechen, die die Manager verstehen (siehe Kasten Nutzen und Kompoenten). Dabei sollte es laut Allen auch nicht an List fehlen, wie sie die OO-Experten Adele Goldberg und Kenneth Rubin beschrieben haben: "Lässt sich das Management nicht durch Angst und Habgier zu einer Entscheidung bewegen, werden Sie gezwungen sein, Logik zu verwenden - ein viel schwächeres Überzeugungsmittel."

"Checkliste"Fragen wie diese stellen sich bei der komponentenbasierten Entwicklung:

-Wie unterscheidet sich das Grobdesign meiner komponentenbasierten Anwendung beispielsweise vom reinen OO-Ansatz?

-Wie kann ich Komponentenspezifikationen aus meinen Fachanforderungen generieren?

-Wie wandle ich zum Beispiel ein Objektmodell für eine Domäne in Komponenten um?

-Wie spezifiziere ich die Anforderungen an meine Komponenten im Design-Dokument?

-Wie soll die Kommunikation zwischen meinen Anwendungskomponenten erfolgen?

-Können mir Patterns weiterhelfen?

-Decken die Komponentenmodelle (EJB, Corba, COM) alle Anforderungen ab?

-Wie programmiere ich die vielen Komponenten, und gibt es Support durch die Werkzeuge?

-Wo finde ich möglicherweise bereits existierende Komponenten?

-Erfüllen zugekaufte/wiederverwendete Komponenten meine Anforderungen?

-Wie gewährleiste ich die Qualität und die Sicherheit der entwickelten Software?

-Wie teste ich eine derartige "zusammengebaute" Anwendung?

-Lassen sich Komponenten für den späteren Gebrauch verwalten und wiederfinden? Quelle: ABB