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.

05.02.1999 - 

Keine Grabenkämpfe mehr, aber Umsetzungsprobleme

OOP ´99: Komponenten brauchen Frameworks

MÜNCHEN (gfh) - Die Erprobungsphase für Komponenten nähert sich dem Ende. Auf der OOP ?99 in München suchten die Entwickler nach Architekturen, um diese Technik auf breiter Ebene für ihre Unternehmens-DV produktiv zu machen. Gleichzeitig bereiten sich die Hersteller auf den erhofften Boom der Embedded Systems vor.

Die OOP gilt als Deutschlands wichtigste Kongreßmesse für Objektorientierung. Die einst heftig geführten Grabenkämpfe um die reine Lehre gehören der Vergangenheit an, seit sich die Branche auf den umfassenderen Begriff der Komponenten geeinigt hat. Profitiert hat davon vor allem Microsoft, dessen Techniken früher lediglich ein Schattendasein geführt hatten. Der Veranstalter Sigs hatte für die Techniken um das Component Object Model (COM) eine eigene Vortragsreihe reserviert. Den Reden des Microsoft-Managers John Gross zur Distributed Internet Application Architecture (DNA)war jedoch anzumerken, daß vor diesem Entwicklerpublikum noch Missionsarbeit zu leisten ist. In dem mit rund 200 Zuhörern gutbesuchten Kurs über die Verwendung von COM+ hatte kaum ein Fünftel der Teilnehmer schon mit Microsofts Komponententechnik gearbeitet.

Weniger glücklich über die jetzige Ausrichtung der Veranstaltung sind die Anhänger von Smalltalk. Von ihnen ist in München wenig mehr als der traditionelle Smalltalk-Abend übriggeblieben. Nach Auskunft von Fachleuten ist die Mutter aller objektorientierten Programmiersprachen auch heute noch auf der Höhe der Zeit, und auch die User sind mit den damit entwickelten Anwendungen zufrieden. Für Nachfolgeprojekte sind jedoch nur schwer Programmierer zu finden. Sie arbeiten entweder im Heer der Entwickler für die Microsoft-Welt, oder sie suchen Zugang zu den modischen Java-Projekten.

Auch in München war Java die mit den meisten Vorträgen bedachte Technik. Dabei ging es in der Regel um praktische Probleme insbesondere bei großen Projekten. Trotzdem gilt, daß auf der OOP die Programmiersprachen eher ein Randthema waren. Im Vordergrund des Interesses stand vielmehr die Frage nach Architekturen und Methoden für den Aufbau einer objekt- beziehungsweise komponentenbasierten Datenverarbeitung, in die sich die bisherigen Unternehmensanwendungen ebenso integrieren lassen wie die allgegenwärtigen Windows-Clients.

Was Analyse und Design objektorientierter Projekte betraf, so konnten die Veranstalter mit Grady Booch aufwarten, der die Unified Modelling Language (UML) mitentwickelt hat. Er beantwortete im Rahmen einer ironisch als Gerichtsverhandlung gestalteten Podiumsdiskussion mehrere Stunden lang kritische Fragen.

Dabei wurde deutlich, daß die Anwender unter der sehr allgemein formulierten UML leiden; es fällt ihnen schwer, daraus Rezepte für erfolgreiche Projekte abzuleiten. Immer wieder verwies Booch in solchen Fällen vage auf die UML-Ergänzung "Unified Process".

Viele Entwickler haben jedoch gegenwärtig konkrete Pläne: Ihre Unternehmen wollen Geschäfte via Web machen, brauchen dafür aber eine Infrastruktur, die ihre Anwendungen mit dem Internet verbindet. Helfen soll dabei Middleware wie Web-Applikations-Server, die hierzulande jedoch noch nicht sonderlich verbreitet sind.

Außerdem wurde auf der OOP immer wieder das Problem angesprochen, daß sich damit zwar Unternehmensdatenbanken anbinden ließen, deren Performance aber durch die Zusammenarbeit mit der modernen Komponententechnik rapide nachlasse. Auch die Datenpersistenz sei noch ein Problem. Einige Hersteller wie etwa Roguewave versuchen diesem Manko mit besonderen Produkten und Caching-Mechanismen zu begegnen. Andere wie etwa Iona Technologies bauen die Integrations-Features ihrer Applikations-Server aus. Sie folgen damit einem von Analysten prognostizierten Trend, diese Art Middleware zu einer allgemeinen Anwendungsplattform weiterzuentwickeln. Im Zusammenhang mit Datenhaltung fiel aber auch immer wieder das Stichwort XML. Die Sprache verspricht ein universelles Übertragungsmedium für strukturierte und unstrukturierte Informationen zu werden.

Noch nicht an den Ständen sichtbar, aber immer wieder im Gespräch war auf der OOP die Verwendung von Komponententechniken für Embedded-Systeme. Kurz vor der Freigabe steht "Navajo", eine Datenbank, die von der Hamburger Poet Software GmbH für den Einsatz in Telefonen von Ericsson entwickelt wurde. Poet erwartet, daß in diesem Jahr eine ganze Reihe ähnlicher Produkte fertiggestellt werden. Erst dann lasse sich testen, ob derartige Geräte tatsächlich - wie erhofft - einen Massenmarkt finden.

Enttäuscht waren die Entwickler von der Vorstellung der Jini-Technik durch den Sun-Gastredner Douglas Southerland. Die Idee, Geräte und Dienste ohne vorherigen Installationsaufwand überall auf der Welt nutzen zu können, wurde zwar mit großem Interesse aufgenommen, es fehlte jedoch an technischen Details. Aus der Darstellung wurde nicht klar, welche Aufgaben durch Jini auf die Entwickler zukommen. So kritisiert UML-Guru Booch, daß das Sicherheitskonzept noch nicht durchdacht sei. Außerdem sei ihm nicht ganz wohl bei dem Gedanken, daß man mit Jini immer feststellen könne, wo er gerade am Rechner sitzt und was er tut.

Dennoch hält er die Idee für wichtig und zukunftsträchtig. Er persönlich interessiere sich jedoch mehr dafür, wie man Muster, sogenannte Patterns, benutzen könne, um den Entwicklern das Leben leichter zu machen. Booch schwebt vor, erfolgreiche Projekte nach ähnlichen Mustern zu durchforsten, um daraus Konsequenzen für ähnlich gelagerte Aufgaben abzuleiten.

Enterprise Javabeans

Mit Enterprise Javabeans (EJB) wurde auf der OOP eine noch junge Komponentenarchitektur besprochen, die Java künftig für Server-Anwendungen interessant machen wird. Daher hier noch einmal das Wichtigste in Kürze.

Die EJB-Spezifikationen 1.0 definieren einen Satz von Programmier-Schnittstellen und Diensten für Server-seitige Java-Komponenten(Beans). Sie sollen Middleware-Anwendungen plattform- und herstellerunabhängig machen und deren Integration erleichtern. Entwickler können sich künftig mehr auf die Programmierung von Geschäftslogik konzentrieren.

Die wichtigsten Features sind:

Container: Im EJB-Framework übernehmen sogenannte Container die Kommunikation (Methodenaufrufe) und Bereitstellung von Diensten zwischen den Anwendungskomponenten. Eine aufwendige, individuelle Schnittstellen-Programmierung entfällt. Letztere ist der Grund,warum Geschäftsobjekte oftmals nicht wiederverwendbar sind. Objekte werden, üblicherweise immer größer und komplexer, je mehr Eigenschaften hinzukommen. Sammelt man jedoch gleichartige Objekte in Containern bleiben sie überschaubar. Daher sind Container in jeder Komponentenarchitektur vorgesehen.

Services: Für jede EJB-Klasse gibt es einen spezifischen Container, über den zur Laufzeit alle Methodenaufrufe laufen. Der Javabean werden Dienste wie Transaktionen, Messaging, Naming-Services, Sicherheit, Verwaltung des Lebenszyklus sowie Persistenz zur Verfügung gestellt.

Folgende Schnittstellen müssen in EJB-Servern immer vorhanden sein:

- Remote Methode Invocation (RMI),

- Internet Inter-ORB Protocol (IIOP),

- Java Naming and Directory Interface (JNDI),

- Java Transaction Service (JTS)/ Java Transaction API (JTAPI) sowie

- Java Database Connectivity (JDBC)

Persistenz: Die EJB-Spezifikationen bieten zwei Formen der zeitlichen Speicherung von Beans. Die "Sessionbean" ist für temporäre Daten gedacht, die sich persistent speichern lassen. Sie ist anonym, eindeutig identifizierbar, optional transaktionsorientiert und steht nur einem Client zur Verfügung.

"Entitybeans", die in EJB 1.0 noch optional sind, werden hingegen dauerhaft in einem festen Zustand abgespeichert. Sie sind über einen sogenannten Primärschlüssel eindeutig identifizierbar, für mehrere Clients ansprechbar und immer transaktionsgesteuert.