COM als Middleware - Seite 4

1.3 Middleware-Architekturen  

Es gilt, wie im folgenden näher erläutert, die drei grundsätzlichen Middlewaretypen Message-, Remote Procedure Call- und Object Broker-basierte zu unterscheiden:

Message basierte Middleware
Die nachrichtenbasierte Middleware ist eine meist proprietäre, wenig standardisierte Form der prozessübergreifenden Kommunikation. Sie erlaubt dem Entwickler durch Verwendung von Diensten, beispielsweise einer Broadcasting-Funktionalität, den Datenaustausch über einheitliche Kommunikationsschichten. Die Kopplung basiert auf Queuemanagern und kann durch explizites An- und Abmelden dynamisch gehalten werden. Nachrichtenbasierte Middleware besitzt das Potential plattformübergreifend zu agieren. Sie zeichnet sich durch asynchrone Übertragungsmechanismen mit selektivem Lesen, durch Prioritätsstufen sowie dem Vorhandensein einer oder mehrerer Messages aus, deren Zustellung ist garantiert ist. Dieser Middlewaretyp standardisiert die Datenstruktur der Nachrichten meist nicht, so dass in kommunizierenden Prozessen zusätzlicher Code für die Chiffrierung und die Dechiffrierung zu implementieren ist. Die Beschreibung von übertragenen Informationen erfolgt daher beispielsweise in XML [Extensible Markup Language]. Nachrichtenbasierte Middleware lässt sich auf den gängigsten Betriebssystemen implementieren, unterstützt Programmiersprachen wie C++ und Java und findet Anwendung in Produkten wie IBM MQ Seriell, BEA MessageQ, Tibco.

Remote Procedure Callbasierte Middleware
Remote Procedure Callbasierte [RPC] Middleware ist das Ergebnis eines Standards der Open Software Foundation und bedingt ein DCE [Distributed Computing Environment]. RPC beschreibt Methoden, die ein lokales, verbindungsloses Handling von Prozeduren in externen Prozessen gewährleisten. Die transparente Kommunikation erfolgt über entkoppelnde Schnittstellen, die mit den Prototypen der prozessentfernten Funktionen übereinstimmen. Der Aufruf einer Funktion in einem entfernten Adressraum ist also syntaktisch und semantisch in die Programmiersprache eingebettet. Erreicht wird dies in der Regel über eine IDL [Interface Definition Language], einer programmiersprachenunabhängigen Schnittstellenbeschreibung, anhand derer die Middleware die notwendige Kommunikationsfunktionalität nach der Übersetzungszeit generieren kann. Normativ steht der aufrufende Prozess still, bis er seitens des Remoteprozesses die Bestätigung über das Ende der Prozedurbearbeitung erhält; die Abarbeitung erfolgt also synchron. Praktisch wird der Vorgang meist durch Festlegung eines Timeouts begrenzt bzw. nach dessen Ablauf abgebrochen.

Weitere Dienste dieses Middlewaretyps ohne Transaktionskonzept sind das Lokalisieren der an einer Kommunikation beteiligten Komponenten und das gerichtete Senden und Generieren von Nachrichten ohne Zustellungsgarantie. Gängige Umsetzungen von RPC-Middleware finden sich in Xerox Courier, SUN RPC, HP RPC und Modula/V RPC.

Object Request Brokerbasierte Middleware
ORB-basierte Middleware ist ein verteiltes, objektorientiertes Modell auf Basis des RPC-Ansatzes und erreicht in den Komponentenarchitekturen EJB, CORBA und DCOM die weitläufigste Verbreitung. In Anlehnung an RPC werden beim Softwarebus ORB, einer speziellen Kommunikationsschicht, nicht Prozeduren aufgerufen, sondern analog Operationen auf Methoden ausgeführt.

Die für den Entwickler transparente Kommunikation kann nach der Kompilierung sowohl statisch, als auch während der Laufzeit dynamisch erfolgen. Erreicht wird dies durch eine systemweite Anmeldung der Komponente sowie durch das Beschreiben ihrer Schnittstellen mittels einer objektorientierten IDL. Diese ermöglicht das Einholen von Informationen über Name und Verfügbarkeit einer Komponente zur Laufzeit ermöglicht.

1.3.1 Betrachtung gängiger ORB Middleware-Modelle

Dem Grundgedanken der Komponentenentwicklung folgend, gäbe es idealerweise nicht eine Vielzahl unterschiedlicher Middlewareumsetzungen, sondern einen einzigen globalen Standard. Praktisch hingegen existiert eine breite Auswahl an Modellen, von denen tatsächlich derzeit nur drei Architekturen wirklich relevant erscheinen: EJB, CORBA und DCOM. Interessanterweise vertritt hier CORBA den fortgeschrittensten und flexibelsten Standard mit der geringsten Marktpräsenz, gegenüber der proprietärsten aber verbreitetsten Lösung DCOM.

Im Anschluss sollen diese drei Konzepte hinsichtlich ihrer markanten Merkmale und ihrer Entstehung kurz umrissen werden:

Die Firma Sun entwickelt seit 1991 die Interpretersprache Java. Ziel ist es, eine einfache und plattformunabhängige Entwicklungssprache zu schaffen, die ihren Einsatz neben PCs auch in der Programmierung von Haushalts- oder Industriesystemen findet. Das 1995 erstmalig vorgestellte Java-Release sollte die Vorteile von C++ und Smalltalk mit einer höheren Semantik vereinen. Mit Einführung einer weiteren Version des Java Development Kit [JDK] 1997 wurde der vorhandene Interpreter stark optimiert und das Event-Handling geändert. Bemerkenswert an der neuen Java 1.1 Spezifikation, ist neben dem neuen Komponentenmodell Enterprise Java Beans [EJB], die Ergänzung des Remote Method Invocation [RMI]. In Zusammenarbeit mit führenden Anbietern von Enterprise-Tools [IBM, BEA, Oracle, HP, Novell] entwickelt Sun 1998 den Enterprise Java Beans Standard, der eine einheitliche Ablaufumgebung für Java-Komponenten in heterogenen Netzwerken schaffen sollte. Mittlerweile liegt die EJB 2.0-Spezifikation vor. U.a. ermöglicht EJB 2.0 die asynchrone Kommunikation zwischen Komponenten durch JMS [Java Message Service], eine verbesserte automatische Persistenz und Interoperabilität zwischen EJB-Servern sowie die Integration von IIOP als Kommunikationsprotokoll.

Ziel der EJB Architektur soll die Bildung eines Middleware-Standards für die Entwicklung verteilter, komponentenbasierter, also objektorientierter Applikationen sein, in dessen Zentrum die Programmiersprache Java steht. Komponenten lassen sich hier herstellerunabhängig implementieren, wobei die technischen Details, wie Transaktionsmanagement, Statusverwaltung für den Entwickler transparent bleiben. Die Kompatibilität der Komponenten untereinander ist durch eine eindeutige Schnittstellen-Spezifikation sichergestellt. EJBs sind ohne Neukompilierung oder Änderung des Quelltextes auf jeder Plattform lauffähig und bieten somit ein Höchstmaß an Portabilität. Sun sichert die Kompatibilität sowohl im Rahmen der bestehenden Java-APIs, als auch im Verbund mit Serversystemen von Drittanbietern und CORBA-Protokollen zu.

Lösungen zu häufig auftretende Aufgaben in Geschäftsanwendungen, wie Datenbankzugriffe, Transaktionen, verteilte Objekte oder Sicherheit werden bereits durch das Framework zur Verfügung gestellt. Zahlreiche Softwarehersteller unterstützen bereits die EJB Architektur und bieten ihren Kunden somit eine reichhaltige Auswahl von interoperablen Komponenten und Applikationsservern.

Die strikte Kapselung von Softwarekomponenten untereinander und zum Betriebssystem ermöglicht es, einzelne Komponenten von einem Server auf einen anderen zu verlagern und damit die Skalierbarkeit eines Systems zu erhöhen. Gestattet die Sprache Java bereits die plattformunabhängige Entwicklung von Applikationen, werden hier in einem weiteren Schritt serverseitige Applikationen von Abhängigkeiten zu Datenbanken und Webservern befreit. EJB-Komponenten lassen sich ohne Änderung bestehender Quelltexte problemlos in unterschiedliche Umgebungen integrieren.

Im Jahre 1989 gründeten marktbestimmende Softwareunternehmen wie Hewlett Packard, Sun u.a. den Industrieverband Object Management Group [OMG]. Populärstes Nichtmitglied war erstaunlicherweise über Jahre hinweg die Firma Microsoft, die aber mittlerweile passiv vertreten ist. Zentrales Ziel war die Entwicklung eines Konzeptes zur Unterstützung und Verbreitung objektorientierter Techniken sowie verteilter Informationsverarbeitung. Mit derzeit über 700 Mitglieder bildet die OMG in der IT-Branche ein umfassendes Industriekonsortium.

Maßgebliche Ergebnisse dieses Zusammenschlusses ist unter anderen die Middleware Common Object Request Broker Architecture [CORBA] für die Kommunikation zwischen verteilten Objekten sowie die Unified Modelling Language [UML] ein Standard für den Komponentenentwurf [s. Kapitel 1.4.4].

Die Geschichte von CORBA ist eng verknüpft mit der Geschichte der OMG selbst. Schon bald nach der Gründung legte die OMG die erste Version des Referenzmodells Object Management Architecture [OMA] vor, das in den folgenden Jahren immer wieder erweitert und verbessert wurde. Kernelement dieser Architektur ist der Object Request Broker [ORB], der eine Interaktionskomponente für verteilte Objekte bereitstellt. Die Standardisierung dieser Komponente begann mit der Einführung von CORBA Anfang 1991.

Die erste offizielle CORBA-Version besaß den maßgeblichen Nachteil, dass die Interoperabilität zwischen Objekten auf den ORB eines Herstellers beschränkt war. Dieser Umstand fundierte auf einer unzureichenden Spezifikationen hinsichtlich der Kommunikation zwischen ORB und Objekten. Diese war jeweils herstellerspezifisch zu implementieren. Erst der 1995 verabschiedete CORBA 2.0 Standard beseitigte mit Einführung des General Inter-ORB Protocoll [GIOP] dieses Problem, so dass seitdem verschiedene ORBs von unterschiedlichen Herstellern problemlos zusammenarbeiten. Das GIOP fand für diverse Netzwerkprotokolle eine Umsetzung. Seine bekannteste Variante ist das auf TCP/IP basierende Internet Inter-ORB Protocoll [IIOP]. Ende 1995 wurden die weitergehenden Dienste [Object Services und Common Facilities] definiert, die eine allgemein verwendbare Toolbox für objektorientierte, verteilte Anwendungen darstellt.

Mit dem einstweilen verabschiedeten CORBA 3.0 Standard, erhält die OMG-Middleware Ergänzungen wie den Quality of Service, bessere Internettauglichkeit [insbesondere über Firewalls] und ein neues Framework zwecks Erstellung und Verwaltung von Komponenten. CORBA-Komponenten lassen sich in ADA [SAP], C++ oder Java verfassen. CORBA findet derzeit überwiegend Anwendung in Echtzeitsystemen und auf Microcontrollern.

Das Distributed Component Object Model [DCOM] ist das Ergebnis verschiedener Bestrebungen der Firma Microsoft und bildet neben CORBA und EJB das wohl verbreitetste Komponentenmodell.

MS-DOS als Vorläufer des Multiprocessing-Systems Windows, konnte lediglich einen einzelnen Task bedienen und bot damit zwangsläufig eine anwendungszentrierte Umgebung. Mit der Entwicklung und der zunehmenden Verfügbarkeit leistungsstärkerer Prozessoren, führte Microsoft mit Windows ihr erstes Multitaskingsystem zur Marktreife. Bald ergab sich daraus die Notwendigkeit des anwendungsübergreifenden Datenaustausches, die durch Konzepte wie DDE [Dynamic Data Exchange] und Clipboard [Zwischenablage] bedient wurden. Der Betriebssystemdienst DDE ermöglichte Windows-Entwicklern erstmalig die anwendungs- als auch rechnerübergreifenden Kommunikation auf Basis einer standardisierten Middleware. Aufgrund seiner Komplexität und diversen Einschränkungen, bewährte sich die Implementierung von DDE mangels auch Akzeptanz nicht und verliert seitdem zunehmend an Bedeutung.

Mit Einführung von Windows 3.1 und OLE [Object Linking and Embedding] im Jahre 1992, erfuhr Microsofts Vision der dokumentenzentrierten Umgebung ihre erste Umsetzung. Der wesentliche Unterschied zwischen einer anwendungszentrierten und einer dokumentenzentrierten Umgebung ist durch den Weg, über den Daten prozessübergreifend transportiert werden können, beschrieben. Anwendungszentrierte Daten charakterisieren sich durch Konvertierung mittels Import- und Exportfunktionen, dokumentenzentrierte Daten hingegen sind eingebettete, dokumentengebundene Informationen. Eine Exceltabelle lässt sich mit einem Word-Dokument verlinken, ohne dass dieses binär importiert werden muss. Änderungen in der Tabelle sind für sämtliche OLE [später OLE 1.0] unterstützenden Anwendungen gleichbedeutend wirksam. Zusammenfassend ermöglichte das auf DDE fußenden OLE 1.0 Anwendungen ein mehrmaliges Verweisen auf Dokumente ohne Konvertierungen vornehmen zu müssen. Der durch diese Technik geprägte Begriff des Compounded Documents [zusammengesetztes Dokument] etablierte sich.

OLE 1.0 erfuhr 1993 mit OLE 2.0 seine Ablösung. Durch Vereinigung verschiedener Techniken entstand das COM-Basismodell für die Realisierung von komponenten-basierter Software. Elementare Neuerungen waren die Bereitstellung standardisierter Mechanismen des Zugriffs und des Ausführen von Operationen auf Objekte. Des weiteren unterstützte OLE 2.0 objektbezogene Dienste zur Verwaltung und Fehlerbehandlung sowie die Möglichkeit Objekte prozessübergreifend auszutauschen, als auch global eindeutig zu identifizieren. Im Zuge dessen propagierte und prägte Microsoft die Programmiersprache Visual Basic als Richtlinie der komponentenbasierten Softwareentwicklung auf Windows-Betriebssystemen. Erste Komponenten oblagen dem sprachspezifischen VBX-Standard [Visual Basic Extension], waren aber in andern Programmiersprachen schwer bis gar nicht implementierbar. Nach der erneuten Definition einer einheitlichen Schnittstellenstruktur erfreute sich VBX im 16-Bit-Windows großer Popularität und trug maßgeblich zur Entstehung eines ganzen Industriezweiges, der Komponentenentwicklung durch Drittanbieter [3rd-party-development], bei. Nachfolgend wurde das am EJB-Ansatz der Firma Sun orientierte Modell dieser GUI-Komponenten mit Einführung des OCX-Standards [OLE Control Extension] auf 32-Bit angepasst und weiter verbessert.

"COM supports the only currently viable component marketplace. The market for third-party components based on COM has been estimated at US$670 million dollars in 1998, with a projected 65 percent compound annual growth rate, growing to approximately US$3 billion dollars by 2001." [ http://www.microsoft.com/com/about.asp ]

Mit COM stand unter Windows in Folge erstmalig eine Richtlinie zur Verfügung, die die Wiederverwendbarkeit von binären Komponenten gewährleistete und über definierte Schnittstellen die Interoperabilität garantierte. Aufbauend auf Konzepte des 1989 gegründeten Konsortiums OSF [Open Software Foundation] zur Standardisierung von verteilten Informationsstrukturen auf heterogene Plattformen, implementierte Microsoft 1996 mit NT4 erfolgreich eine RPC-Variante [Remote Procedure Call]. RPC erlaubt die plattformübergreifende Interprozess-Kommunikation in vernetzten Rechnersystemen und erweiterte somit das Objektbeschreibungsmodell COM zu DCOM [Distributed COM]. Das DCOM-Protokoll, auch ORPC [Object RPC] genannt, nutzt durch Manipulation der Header und Nutzdaten die RPC-Protocol Data Unit [PDU] und steht daher im Protokollstapel nicht über, sondern neben RPC.

DCOM unterstützt den Windows-Entwickler mit einer Sammlung von Werkzeugen und Diensten bei der Erstellung von verteilten Anwendungen nach dem Client-Server-Prinzip. Durch EntireX ist die Middleware DCOM mittlerweile auch auf andere Plattformen, beispielsweise Linux, portierbar und vervollständigt sich dadurch zu einem echten DCE [Distributed Computing Environment].