Noch nie zuvor änderten sich sowohl Business-Abläufe als auch die zugrunde liegende Infomationstechnologie derart rasch. Um diesen Veränderungen in der IT-Struktur Rechnung tragen zu können, muss die verwendete Anwendungsarchitektur ausreichend flexibel gestaltet sein. Den Verantwortlichen drängt sich eine ganze Liste mit Forderungen auf: So sollte es jederzeit möglich sein, Teile der Anwendung anzupassen, ohne große Bereiche der Applikation neu schreiben zu müssen. Am besten wäre es, wenn diese Änderungen sogar während des laufenden Betriebs vorgenommen werden könnten, um die Ausfallzeiten zum Beispiel bei Online-Anwendungen so gering wie möglich zu halten.
Natürlich ist auch die Verwendung der jeweils besten Technologien wünschenswert - als vorteilhaft gilt vor allem, wenn die Anwendung genau mit dem für sie geeigneten Datenbank- und Betriebssystem läuft. Bei der Erstellung und Wartung einer Applikation sollte es möglich sein, die Anwendung in unabhängigePortionen zu unterteilen, so dass die beteiligten Programmierer möglichst effizient und ihren Spezialgebieten entsprechend arbeiten können.
Entflechtung der ProgrammstrukturenDie fertige Anwendung soll unter verschiedenen Frontends (Charactermode, GUI, Web etc.) laufen können und auch in dieser Hinsicht jederzeit erweiterbar sein, ohne dass die Kernlogik verändert werden muss. Schließlich wäre es von unschätzbarem Vorteil, wenn die Applikation an allen Schnittpunkten offen bliebe, so dass später entworfene Applikationen Daten aus dem bestehenden System extrahieren können und die Aktivsysteme zusammenwachsen (API-Thematik).
Alle hier angeführten Wünsche haben eines gemeinsam: Sie erfordern eine Entflechtung der Programmstrukturen. Wenn eine Applikation in Blöcke unterteilt wird, die festgeschriebene Schnittstellen aufweisen, wird genau diese Entflechtung erreicht. Solche Blöcke - oder Komponenten - sind dann wie Bausteine austauschbar. Doch die Komponentenarchitektur geht noch einen Schritt weiter. Komponenten müssen nicht mehr auf demselben Server gespeichert sein. Eine Anwendung kann sich aus verteilt gespeicherten Komponenten zusammensetzen, zwischen denen eine dynamische Lastverteilung stattfindet.
Eine Veränderung der Geschäftsabläufe sollte ihre Entsprechung in einer limitierten Zahl von Komponenten, bestenfalls einer einzigen, finden, die angepasst werden muss. Fehler, die durch Querverbindungen entstehen, sind nur noch innerhalb der Komponente möglich, können aber aufgrund der Überschaubarkeit leicht vermieden werden. Weiterhin ist es möglich, Komponenten während des laufenden Betriebs auszuwechseln beziehungsweise zu erweitern. Durch die Zerlegung der Anwendung in Komponenten werden auch andere Vorteile offensichtlich. Solange für ein beliebiges Programm, eine Datenbank oder Betriebssystem-Funktion eine Komponenten-Schnittstelle besteht, können diese zusammen mit der eigenen Anwendung eingesetzt werden. Und selbst wenn diese Schnittstelle nicht vorhanden ist, so ist es zumeist möglich, durch einen Wrapper eine Art Adapter zu schaffen. Dieser Wrapper besteht aus einer umgebenden Programmstruktur, die nach innen Schnittstellen zu den Objekten und nach außen zum Applikations-Server aufweist. Das führt letztlich dazu, dass Software nicht mehr nach den Schnittstellen, sondern rein nach ihrer Funktionalität ausgewählt werden kann.
Black-Box-Konzept sichert InnovationDurch die Entflechtung wird der effiziente Einsatz der Entwickler gefördert, da die einzelnen Komponenten den Spezialisten entsprechend ihren Schwerpunkten zugewiesen werden können. Fehler lassen sich in den übersichtlichen Komponenten rascher finden und damit auch schneller und billiger beheben. Selbst die Vergabe von Entwicklungsaufträgen außer Haus wird gefördert, da durch den Black-Box-Gedanken die Innovation gesichert bleibt. Schließlich reicht es aus, die Schnittstelle und das Verhalten der Komponente zu spezifizieren, ohne auch nur zu erwähnen, was der Rest der Applikation tut. Frontends lassen sich schneller anpassen, da der gesamte Applikationskern erhalten bleibt: Lediglich die Anzeigekomponenten werden verändert. Dies schafft die Möglichkeit, ein und dieselbe Applikation zum Beispiel im GUI und im Web zu verwenden (Multi-Deployment).
Die Aktivsysteme erfahren durch die Verwendung von Komponenten eine nahtlose Integration. Jedes Programm kann auf die Schnittstellen des anderen und damit auf dessen Daten zugreifen. Spätestens bei der Verwendung von Analyse-Tools über den Datenbestand mehrerer Applikationen hinweg werden die Vorteile deutlich: Daten stehen direkt dort zur Verfügung, wo man vormals mittels komplexer Datenpumpen und Konsolidierungsregeln versuchte, Schnittstellen zu schaffen. Und im Gegensatz zu den meisten nachträglich implementierten Schnittstellen bleibt die Transaktionsorientierung gewahrt.
Die Wahl des Application-ServerEntflechtung und Technologieabstraktion erhöhen die Qualität der Applikationsentwicklung, indem die Programmstrukturen entzerrt und die Schnittstellen offen gelegt werden. Wartung und Portierung werden vereinfacht, die Einsatzmöglichkeiten sind nicht mehr auf ein einziges Frontend beschränkt. Verwendet man Design-Tools wie Rational Rose, lassen sich viele Schritte bereits beim Grunddesign der Applikation erledigen, da die Strukturen der Komponenten automatisch erstellt werden können. Durch Entwicklungswerkzeuge, die den Gedanken der Technologieabstraktion noch weiter unterstützen, lässt sich die Wahl des Frontends sogar vollkommen kapseln, so dass Dual Deployment für Web und GUI automatisch stattfindet.
Früher oder später steht jedes komponentenbasierte Projekt vor einer Entscheidung, die den Fortgang nachhaltig prägt: Welcher Application-Server soll verwendet werden? So viel vorweg: Die Wahl zwischen Microsofts COM+ und Enterprise Javabeans (EJB) kann nicht aufgrund einer prinzipiellen Überlegenheit eines der beiden Modelle getroffen werden, sondern anhand deren Eignung für bestimmte Aufgaben.
Ein Kriterium, auf dem Entscheidungen besonders oft basieren, sollte ganz und gar vernachlässigt werden: der Lizenzpreis. Aus Erfahrung weiß jeder Projektleiter, dass die Gesamtkosten eines komplexen Projektes nur zu einem Bruchteil aus Aufwendungen für Hardware und Software bestehen. Daher lohnt sich ein Blick auf den Preis nur bei sehr kleinen Projekten. Technologieabstraktions-Werkzeuge ermöglichen hier, die Entscheidung nicht pauschal fällen zu müssen, da sich Komponenten so - einmal entwickelt - auf beiden Architekturen einsetzen lassen.
Bestandsaufnahme der SystemeDer erste Ansatzpunkt ist die Bestandsaufnahme der eingebundenen Systeme. COM/MTS läuft nur auf Windows-Plattformen und bietet darüber hinaus kaum Möglichkeiten, heterogene Systeme einzubinden, da die verwendeten Techniken (COM TI, MSMQ und OLE DB) sowie Protokolle (DCOM) nur auf Windows-Plattformen implementiert sind. Die Anbindung an Nicht-Windows Plattformen erfordert also stets Software von Drittanbietern. EJBs verwenden hier IIOP (Internet Inter-ORB Protocol), ein Corba-Protokoll, das durch Tunneling auch über eine Vielzahl anderer Protokolle übertragen werden kann.
Das zweite Kriterium ist der Funktionsumfang des Komponentenmodells selbst. COM bietet ausschließlich "Stateless Components", das heißt, die Komponenten erhalten von sich aus keine Informationen, wer sie gerade benutzt und in welchem Kontext dies geschieht. Die Einschränkung kann durchbrochen werden, indem die Zustandsinformationen bei jedem Aufruf manuell mit übergeben oder aber im Backend in eine Datenbank geschrieben werden. Das aber ist aufwändig und erzeugt im schlimmsten Fall Netzlast durch den stärkeren Informationsfluss zwischen Client und Komponente oder zwischen Server und Backend. EJB wartet zusätzlich noch mit "Persistent Components" (Entity-Beans) auf, die Datenspeicher als Objekte abbilden. Dies ist praktisch, da dadurch der Programmieraufwand beim Datenzugriff gering gehalten wird.
Sowohl MTS als auch EJB besitzen die Möglichkeit, "Queued Components" zu benutzen. Dies sind asynchron gerufene Komponenten, deren Aufruf zunächst in eine Warteschlange geschrieben wird, die dann zu einem späteren Zeitpunkt nach und nach abgearbeitet wird. Interessant ist dieses Feature in Anwendungen etwa für Call-Center, wo zu bestimmten Zeiten eine hohe Auslastung in der Anruferfassung anfällt, die später abgearbeitet werden kann. Bei MTS wird dies über MSMQ (Microsoft Message Queuing Services) umgesetzt, EJBs verwenden dazu JMS (Java Messaging Services), die Teil von J2EE sind.
Unterschiedliche SkalierbarkeitDie Fähigkeiten zur Anwendungsskalierung sind bei beiden Modellen ebenfalls recht unterschiedlich ausgeprägt. Echtes Middle-tier-Load Balancing, also die Fähigkeit, Dubletten von Komponenten auf unterschiedlichen Servern zu halten und diese je nach Verfügbarkeit und Datenlast dynamisch zu verwenden, besitzt nur die EJB-Architektur. Microsoft will hier jedoch Abhilfe schaffen und plant, den MTS ebenfalls mit dieser Fähigkeit auszustatten.
Hardwareseitig sind die Windows-Plattformen zwar auf 16 beziehungsweise 32 Prozessoren beschränkt, doch bietet sich hier die Möglichkeit an, Server im Cluster zu betreiben. In dieser Beziehung ziehen beide Plattformen gleich - das Limit hierfür liegt mehr im planerisch sinnvollen Bereich als in technischen Beschränkungen.
*Kai Mattern ist System-Engineer bei Prolifics Deutschland in Hamburg.
BeispielapplikationAnhand eines Demonstrationsprojektes mit einem Web-fähigen Reservierungssystem für ein fiktives Kino soll der Einsatz von Komponenten in GUI und Web veranschaulicht werden (siehe auch Grafik auf Seite 61). Das Grundgerüst, zwei Komponenten, die alle Datenbankzugriffe ausführen, wurde mit Rational Rose angelegt. Rose generiert aus der angelegten Struktur automatisch die Komponentenrümpfe, die nur noch mit Logik gefüllt werden müssen. Der Inhalt der Komponenten, also die gesamte Präsentations- und Anwendungslogik, wurde in einer 4GL erstellt und kann als COM- und als EJB-Komponente zum Einsatz kommen. Somit besteht weder die Notwendigkeit, sich im Vorfeld auf einen Applikations-Server festzulegen, noch die jeweils zugehörigen Programmiersprachen zu benutzen.
Durch die Verwendung von Komponenten teilt sich die Applikation in drei Arbeitsfelder: Datenbank, Applikationslogik, Präsentation. Diese Trennung sorgt dafür, dass die drei Teilstücke vollkommen unabhängig voneinander entwickelt werden können, da den Entwicklern die Schnittstellen bekannt waren. Die fertige Applikation läuft ohne Änderungen sowohl im GUI als auch im Web.
COM versus EJBFeature / EJB / COM+Sprache der Komponenten / nur Java* / viele*
Plattformen / alle gängigen / Windows
Middleware-Hersteller / 30+ / Microsoft
Legacy Integration / RMI/JNI, Corba / COM TI, MSMQ, OLE DB
Protocol / durch Tunneling fast jedes (IIOP) / DCOM
Stateless Components / ja / ja
Stateful Components / ja / nein
Persistent Components / ja / nein
Method-granularity transactions / ja / nein
Middle-tier Load Balancing / bei den meisten Herstellern / bald
Middle-tier Data Caching / bei einigen Herstellern / nein
Queued Components / bald / ja
Middleware Teil des OS / nein / ja
Integration heterogener Systeme / ja / nein
Prozessoren pro Maschine / 256+ / 16 (32 via OEMs)
Cluster-weite Prozessoren / theoretisch unbegrenzt / theoretisch unbegrenzt
* Gilt nicht bei der Verwendung von Technologieabstraktionswerkzeugen, die diese Einschränkung aufheben.
Abb: Kino-Reservierungsssystem
Wie sich aus Komponentensoftware ein Web-fähiges Kino-Reservierungssystem aufbauen lässt - Details im Kasten "Beispielapplikation" auf Seite 60. Quelle: Prolifics