In der prozeduralen Programmierung, die die IT lange Jahre dominiert hat und in weiten Bereichen bis heute das wichtigste Modell darstellt, stehen die Abläufe im Mittelpunkt. Diese müssen beschrieben und dabei "sequentialisiert" werden. Dabei entstehen logische Einheiten, sogenannte Module, die manchmal auch in mehreren Programmen genutzt werden können. Letztlich gilt es, diese Module zu einer sequentiellen Abfolge zu verbinden. Dafür dienen "Prozeduren" und/oder Funktionen bei deren Aufruf Daten unter den Modulen ausgetauscht werden. Dabei entstehen sogenannte Aufruf-Hierarchien. Prozedurale Programme beschreiben also Abläufe, die Komplexität der Programme liegt in den Algorithmen. Die Anwendungen sind daher empfindlich, wenn der Ablauf selbst sich ändert.
War das Abstraktionsverfahren der prozeduralen Programmierung die Zerlegung der Abläufe, so versuchte die objektorientierte Programmierung das Abstraktionsverhalten des Menschen auf die IT zu übertragen. Dabei wird die Realität als eine Ansammlung von Objekten aufgefasst, die klassifiziert werden können. Eine Klasse beschreibt den Bauplan eines Objekttyps mit seinen Eigenschaften, den Attributen, und seinen Fähigkeiten, den Methoden. Darauf basierend entsteht also eine Anwendung, indem Objekte dieser Klassen Aktionen ausführen, so können sich Objekte zum Beispiel untereinander manipulieren. Die Abstraktionsmethode der objektorientierten Programmierung ist Abbildung.
Der objektorientierte Ansatz hat zum Ziel, die Programmierung zu vereinfachen, indem ein "natürliches" Verhalten des Menschen - Klassifizierung, Abstraktion und Bilden von Hierarchien - angewendet wird. Allerdings entsteht dabei eine neue Komplexität: die in der Beziehung von Objekten untereinander. Eine Veränderung der Beziehungen eines einzelnen Objektes kann weitreichende Folgen auf andere Objekte haben.

Das größte Problem der Software-Entwicklung ist immer die Zeit, die benötigt wird, vorhandene Systeme zu ändern, anzupassen und zu erweitern. Die objektorientierte Programmierung hat zwar das Programmieren entscheidend verändert, ihre ursprüngliche Zielsetzung - die Vereinfachung der Software-Entwicklung - jedoch nur zum Teil erreicht. Im Gegensatz zur Software ist die Entwicklung von Hardware heute viel schneller. Hier kommunizieren einzelne Bausteine über standardisierte Verbindungen und können via Plug & Play einzeln ausgetauscht werden. Bei der Komponenten-Architektur geht es im Grunde um nichts anderes. Plug & Play soll auch für Softwarebausteine funktionieren und so immer kürzere Entwicklungszyklen ermöglichen.
Mit Einführung der Komponenten-Architektur versucht man, die Komplexität der Prozesse in überschaubare Bausteine zu unterteilen. Dabei übernimmt jeder Baustein eine Teilaufgabe des gesamten Prozesses und realisiert diesen Teil völlig eigenständig. Die Implementierung der Bausteine kann an kleine Projektguppen weitergegeben werden, die wiederum beliebig objektorientiert oder strukturiert vorgehen können. Um aus den so entstandenen Bausteinen eine vollständige Anwendung zusammenzubauen, müssen die einzelnen Teile in Beziehung zueinander gebracht und eventuell mit Kommunikationsschnittstellen versehen werden.

Eine Komponente ist ein Softwarebaustein, der für sich eine vollständige Anwendung darstellt, die jedoch nur einen kleinen Teil des gesamten Systems realisiert. Softwarebausteine kann man selber entwickeln oder auch als fertige Komponenten einkaufen, beispielsweise Microsoft Word als Baustein, der die Funktion einer Textverarbeitung übernimmt.
Um eine gute Übersicht über alle vorhandenen Bausteine zu haben ist es wichtig, ein Repository anzulegen. Dabei müssen die Bausteine mit ihrer Schnittstelle - die die Kommunikation mit anderen Bausteinen regelt - und den realisierten Aufgabenstellungen beschrieben werden. Will man nun eine Applikation realisieren, analysiert man zunächst, welche Aufgaben diese Applikation realisieren soll. Dann lassen sich im Repository die entsprechenden Komponenten ermitteln, die verschiedene Teilaufgaben übernehmen können. Sind alle notwendigen Bausteine beisammen, kann man die eigentliche Applikation realisieren, indem man die verschiedenen Bausteine aufruft.

Zwei Typen von Komponenten lassen sich unterscheiden. Die In-Process-Komponenten sind lokale Komponenten, die als ein Bestandteil des Anwendungsprozesses gelten. Diese Komponenten sind im Prinzip gebundene Unterprogramme, die jedoch über die standardisierte Schnittstelle angesprochen werden. Typische Vertreter sind COM- und JavaBean-Komponenten.
Demgegenüber gibt es die verteilten Komponenten. Für die Anwendung sind es entfernte Komponenten, welche verteilt im Netzwerk liegen können und die auch extern zur Anwendung verwaltet werden. Diese Modelle beinhalten also eine Netzwerk Kommunikation, auch wenn die Komponente selbst sogar auf dem gleichen Rechner liegt. Bei den verteilten Architekturen haben sich in den letzten Jahren drei unterschiedliche Technologie etablieren können:

- COM+ / DCOM Distributed Component Object Model
- Corba / CCM Common Object Request Broker Architecture / Corba Component Model
- J2EE/EJB Java 2 Plattform, Enterprise Edition/Enterprise JavaBean

Das COM+-Modell wurde von Microsoft definiert und basiert auf einer von Programmiersprachen unabhängigen API (Application Programming Interface). Das benötigte Runtime-Modul wird als Bestandteil der Microsoft Betriebssysteme mitgeliefert. Die Information wie eine Komponente anzusprechen ist und wo sie im Netzwerk zu finden ist, wird in der Windows Registry hinterlegt. COM+ unterstützt Transaktionssteuerung und Security direkt auf der Kommunikationsebene. Weitere Dienste wie COM-Datenbankzugriffe werden von Microsoft angeboten.
Anders als COM+ ist Corba ein industriedefinierter Standard und Sprachen- sowie Plattform-Unabhängig. Dabei bestimmt der jeweilige Anbieter, welche Sprachen und Systeme er mit seinem Produkt, dem ORB, unterstützt. Die Kommunikation erfolgt über ein extra definiertes Protokoll: IIOP. Damit können auch ORBs verschiedener Hersteller untereinander kommunizieren. Servicedienste wie Transaktionssteuerung und Security werden ggf. vom Anbieter als eigenständige Corba-Dienste angeboten.
EJB schließlich ist ein Komponentenmodell speziell für Java und damit auch plattformunabhängig. Es gibt eine Reihe von SUN zertifizierten Applikationsservern, die in der Lage sind diese Komponenten auszuführen. Dabei implementieren JavaBeans ausschließlich die Logik einer Komponente. Alle Services wie Transaktionssteuerung und Security werden vom Applikationsserver zur Verfügung gestellt.

In weiten Bereichen der Applikationsentwicklung ist COBOL nach wie vor die wichtigste Programmiersprache. Die Probleme der Y2K- und der Euro-Umstellung haben die große Bedeutung von COBOL nur unterstrichen. COBOL ist zwar alles andere als "hype", aber die wenigsten wissen, dass in großen Unternehmen, in Banken oder Versicherungen noch immer Mannschaften mit hunderten von COBOL-Entwicklern beschäftigen. Da auch diese Anwendungsteile einen Anschluss an die Komponenten-Welt benötigen, unterstützt COBOL alle drei Modelle für Komponenten-Architekturen. COBOL Programme können also COM+, Corba- und/oder EJB-Objekte verwenden und selbstverständlich ist es auch möglich, in COBOL die Objekte selbst zu realisieren. Die Frage ist nur: wie geht das?
In einer typischen COBOL-Entwicklungsumgebung für verteilte Anwendungen, wie zum Beispiel MERANTs Net Express, finden sich heute spezielle Assistenten, um auf der Basis von COBOL-Programmen verteilte Komponenten nach den verschiedenen Modellen zu erzeugen. Dabei startet ein "Class Wizard" einen Dialog mit dem Entwickler und fragt alle nötigen Informationen ab, um in COBOL die jeweils objektorientierten Klassen, Methoden und Daten zu implementieren. Aus diesen Informationen generiert der Wizard dann automatisch COBOL-Source-Code, der nur noch mit der gewünschten Logik gefüllt werden muß. Er hilft so dem Entwickler, die gewünschten objektorientierten Vorgaben in die Syntax von OO COBOL (objektorientiertes COBOL) umzusetzen. Beim Anlegen einer neuen Klasse kann man bestimmen, dass diese Klasse eine OLE-Komponente oder auch EJB-Komponente abbilden soll. Der Assistent generiert die dazu nötigen Quellen und Erweiterungen.

Andere Tools, wie der AssetMiner, können aus existierenden COBOL-Programmen Businesslogik extrahieren und daraus Komponenten generieren. Ganz automatisch geht das freilich nicht, aber das Tools kann den Code nach Syntax, die für Businesslogik typisch ist, analysieren. Auf das Ergebnis kann der Entwickler im Dialog zugreifen und die tatsächlich gewünschten Ausschnitte auswählen. Sobald auf diese Weise alle Teile einer Businesskomponente zusammengestellt sind, generiert das Tool daraus ein neues COBOL-Programm, das als unabhängiges Unterprogramm - also als Komponente - genutzt werden kann. Die so entstandenen neuen Unterprogramme können mit einer beliebigen Kommunikationsschicht - COM+, Corba oder EJB - versehen und so direkt in die jeweilige Komponenten-Architektur integriert werden.
Mit solchen Hilfsmitteln lassen sich also COBOL-Programme so verändern, dass sie direkt Komponenten implementieren können. Häufig wollen Unternehmen die vorhandenen Anwendungen aber nicht verändern und sie trotzdem in Komponenten-Architekturen nutzen. MERANT bietet dafür seinen EnterpriseLink ComponentGenerator. Dieser Werkzeugkasten ist in der Lage, CICS-Transaktionen über ein EJB-Interface aufrufbar zu machen.
Der ComponentGenerator prüft zunächst die vorhandene Anwendung auf Vollständigkeit. Auf dieser Basis wird ein Workflow definiert, also eine Sequenz von Transaktionsschritten, die eine Aufgabe lösen, die nun in einer Komponenten-Architektur benötigt wird. Anhand der Quellen der betroffenen Programme ermittelt der Component Generator selbst alle nötigen Informationen für die Definition eines EJB-Interfaces.

Da eine Anwendung eine Komponente nur auf Basis der Schnittstelle und der fachlichen Anforderung benutzt, stellt die Art der Implementierung für die Anwendung selbst eine Black Box dar. So kann unbemerkt eine Komponente verändert oder sogar ausgetauscht werden. Wenn sich zum Beispiel eine fachliche Regel ändert, genügt die Änderung in einer Komponente um alle Anwendungen anzupassen. So erreicht man ein hohes Maß an Flexibilität.
Wird zusätzlich eine Trennung der fachlichen Logik von dem eingesetzten Komponentenmodell, also der Schnittstelle COM+, Corba oder EJB vorgenommen, kann sogar das technologische Umfeld jederzeit an neue Anforderungen angepaßt werden. Eine solche Business-Komponente implementiert nur noch den Geschäftsprozeß selbst. Wenn die Business-Komponente außerdem in einer plattformunabhängigen Sprache wie COBOL implementiert wurde, kann sie jederzeit und überall wieder verwendet werden.
Eine Komponenten-Architektur kann Entwicklungszeiten wesentlich verkürzen und ermöglicht ein schnelleres Reagieren auf Veränderungen im Markt. Die so entstehende Komponenten-Infrastruktur kann schnell verändert und angepaßt werden. Mit der Wiederverwendbarkeit von Anwendungsteilen können nicht zuletzt die Entwicklungskosten reduziert werden, zumal sich oft Komponenten von Drittanbietern in eigenen Applikationen integrieren lassen. Aber auch die Qualität der Software kann erheblich verbessert werden, da bereits getestete Komponenten zum Einsatz kommen. Jede Verbesserung einer Komponente verbessert auch jede Anwendung, die sie benutzt.

Auf Basis einer EJB-Komponenten-Architektur wird ein Kunden-Informationssystem implementiert. Einige Komponenten stehen bereits zur Verfügung, so ermöglicht Insert das Anlegen eines neuen Kunden und Delete löscht einen existierenden Kunden. Jetzt soll noch die Komponente Update realisiert werden, die es ermöglicht, die Daten eines Kunden zu aktualisieren. Dieser Prozeß existiert bereits: Im "Altsystem" gibt es einen genau passenden Ablauf, mit weitreichenden semantischen Prüfungen, Berechtigungskontrolle usw. Allerdings handelt es sich dabei um eine Folge von CICS-Transaktionen auf einer OS/390.
Um diese Transaktionsfolge als Komponente zu realisieren, müssen zunächst die Sourcen der CICS-Anwendung zur Verfügung gestellt werden. Sind diese mit dem Repository (hier eine Revolve-Datenbank) auf Vollständigkeit geprüft, kann die Abfolge der Transaktionen als Workflow im ComponentGenerator festgelegt werden. Sobald man alle Transaktionsschritte ausgewählt hat, kann man daraus eine sogenannte eBizTX (eBusiness Transaktion) definieren.
Mit dem Workflow hat man dann eigentlich den positiven Pfad durch eine existierende Anwendung beschrieben. Im Regelfall können aber auch Abweichungen von diesem Pfad zur Laufzeit auftreten - zum Beispiel durch Fehler. Im vorliegenden Beispiel kann es sein, dass der Kunde mit der angegebenen Kundennummer im System nicht existiert und das beim Schreiben der aktualisierten Daten ein Fehler auftritt. Diese Abzweige vom Hauptpfad ermittelt der ComponentGenerator anhand des Repository. Nun kann der Entwickler die Komponente mit ihrem Interface, also den Daten für die Ein- und Ausgabe, interaktiv definieren. Der ComponentGenerator liefert dazu bereits die Information, welche Daten von dem Workflow als Eingabe benötigt werden und welche Ausgabeinformationen inklusive Fehlerbehandlung möglich sind.
Nachdem so alle nötigen Informationen zusammengestellt wurden, kann der ComponentGenerator die Java-Sourcen generieren, die die Komponente Update über ein EJB-Interface beschreibt. Zusätzlich wird ein COBOL-Source generiert, der den Transaktionsablauf über die 3270-Bridge des CICS-Systems steuert. Schließlich wird das COBOL Programm auf den Host transferiert, um dort generiert zu werden. Der Workflow steht damit über ein eBizTX-Interface auf dem Host zur Verfügung.
Der Java Sourcecode kann beispielsweise mit Visual Age for Java übersetzt und zu den anderen Komponenten beigefügt werden. Die Java-Komponente und das COBOL-eBizTX können über MQSeries miteinander kommunizieren und so ihre Daten austauschen.
Nun ist die neue Komponente Update über ein EJB-Interface einsatzbereit. Tatsächlich wird der Businessprozeß aber nicht in der Java-Komponente realisiert, sondern auf dem Mainframe als Folge von CICS-Transaktionen. Dieses Vorgehen ermöglicht es, vorhandene Prozesse in einer CICS-Umgebung auf dem Host in EJB-Architekturen direkt nutzbar zu machen.

Kommentar zum Artikel

"Sehr interessanter Artikel, habe vor 20 Jahren mit COBOL gearbeitet, dass diese Programmiersprache sich immer weiter entwickelt hat zeigt doch deren Güte. (Dezember 2004)"