0 Problemstellung

Im Rahmen dieses Referats soll das Konzept von DDE zur Kommunikation von Windows- Programmen untereinander vorgestellt und erläutert werden. Um dies zu verdeutlichen, möchte ich die Funktionsweise und die Bestandteile von DDE im zweiten Kapitel aufzeigen. Das dritten Kapitel gibt einen kurzen Überblick über anderen Kommunikationstechniken wie OLE und Winsock. Die aktuelle Weiterentwicklungen DCOM wird im letzten Kapitel, neben einem Ausblick auf kommende Kommunikationstechniken, kurz erläutert.

 

 

1 Einführung

Mit dem Erscheinen der Microsoft Windows Version 3.0 am 22. Mai 1990 erlangte zum ersten Mal ein Betriebssytem enorme Popularität, welches in der Lage war, mehrere Anwendungen "gleichzeitig" auszuführen. An diesem Veröffentlichungstag schrieb die Zeitung PC Week [vgl. Ichbiah 1993, S. 262]:

"Dies ist der Augenblick, in dem Windows Wirklichkeit wird im Sinne einer wirklichen Alternative zur Arbeit mit DOS. Bisher war Windows ein Novum, ein Scherz, ein verführerischer, aber enttäuschender und manchmal ärgerlicher Blick auf die Möglichkeiten einer grafischen Benutzeroberfläche. Obwohl auch Windows 3.0 immer noch alles andere als perfekt ist, wird es dieser Kritik ein Ende bereiten."

Acht Jahre danach weist die aktuelle Version "Windows 98" mit der eigentlichen Versionsnummer 4.10 immer noch viele Schwächen auf und ist vom Status eines perfekten Betriebssystems noch weit entfernt. Jedoch wurden viele Funktionen stetig weiterentwickelt und verbessert. Andere wiederum wichtige Funktionen und Eigenschaften wie DDE und OLE wurden aus Gründen der Abwärtskompatibilität und als Basis für neuere Kommunikationstechniken in ihrer komplette Funktionalität in die neuen Versionen übernommen und zum Teil auch erweitert.

Da ein Betriebssystem (OS = Operating System) die Umgebung zum Betrieb der Anwendungen zur Verfügung stellt, resultiert daraus direkt eine der Hauptaufgaben. Das Betriebssystem muß den Programmen eine Plattform zur Kommunikation mit der Hardware des Rechners zur Verfügung stellen. Dies ist eine der primären Aufgaben von Betriebssystemen wie z.B. MS-DOS oder PC-DOS.

Mit der Möglichkeit zur gleichzeitigen Ausführung von mehreren Programmen in windows- ähnlichen Umgebungen erweitert sich der Aufgabenbereich des Betriebssystems um ein wesentliches Merkmal. Das OS muß den einzelnen Programmen eine Plattform zur Kommunikation untereinander zur Verfügung stellen und diese "Unterhaltung" auch kontrollieren. Die Entwicklung dieser sogenannten Interprozeßkommunikation (IPC = Unterhaltung zwischen den Prozessen) unter Windows vollzog sich in drei Stufen, wie die folgende Abbildung zeigt.

DDE_Entwicklung.gif (5043 Byte)

Über die datenorientierten IPC- Mechanismen tauschen die einzelnen Prozesse, unter Windows auch Anwendungen genannt, Binärdaten aus. Die Zwischenablage und Dynamic Data Exchange (DDE) sind datenorientierte IPC-Mechanismen. Die Zwischenablage verwendet einen gemeinsamen Speicher und erlaubt zwischen Anwendungen nur den Austausch von Daten und Befehlen.

Bei den objektorientierten IPC- Mechanismen werden Objekte zwischen den einzelnen Anwendungen ausgetauscht. Diese Objekte besitzen Attribute (Eigenschaften), welche wiederum über die Methoden der jeweiligen Objekte verändert werden können.

Bei einer Kommunikation mittels Distributed Component Object Model DCOM beschränkt sich die Kommunikation nicht nur auf einen Rechner. Zimmermann [c’t 1998, S. 244] beschreibt den Aufbau von DCOM folgendermaßen: "Ein beliebiger Rechner (der Server) führt eine Komponente aus, die von anderen PCs als Clients benutzt wird". Auf welchem Rechner diese Komponente läuft, spielt für den Client keine Rolle.

 

2 Dynamic Data Exchange (DDE)

2.1 Das DDE- Prinzip

Dynamic Data Exchange bedeutet wörtlich "dynamischer Datenaustausch". Um die Daten zwischen den verschiedenen Anwendungen austauschen zu können, benutzt DDE das Windows- Nachrichtensystem und stellt hierfür neun DDE- Nachrichten zur Verfügung. Ein DDE- Nachrichtenaustausch bezeichnet man als Konversation. Es gibt zwei verschiedene Arten der DDE- Konversation. Zum einen die auf Nachrichten basierende, zum anderen die auf der DDE- Management Library (DDEML) beruhende. Hierbei setzt die DDEML- Methode auf die eigentliche DDE- Methode, erleichtert jedoch dem Benutzer den Umgang und sorgt für die Einhaltung des DDE- Protokolls. Das DDE- Protokoll gibt an, wie eine Konversation zwischen den Anwendungen ablaufen muß. Man unterteilt die DDE- Anwendungen in vier Kategorien: Client, Server, Client/Server und Monitor.

Die Bestandteile des DDE- Protokolls und der genaue Ablauf einer DDE- Konversation soll im Folgenden anhand eines Markplatzes erläutert werden.

 

2.2 Das DDE- Protokoll

 

Das DDE- Protokoll beinhaltet einen Satz von Regeln, welchen alle DDE- Anwendungen einhalten sollten. Es legt fest wer sich mit wem unterhalten darf. Auch der Zeitpunkt, den genauen Ablauf und das Aussehen (Format) der Konversation sind durch das DDE- Protokoll genau definiert. Selbstverständlich kann eine Anwendung auch eine nicht DDE- Protokoll- konforme Konversationen führen, jedoch nur mit Anwendungen, die die gleichen Abweichungen vom DDE- Protokoll beinhalten. Eine typische DDE- Konversation besteht nach Microsoft aus folgenden Ereignissen:

1.    Auf die Eröffnung durch den Client antwortet der Server

eroeffnung.gif (4984 Byte)

2.    Eine Unterhaltung kann verschiedene Zwecke haben:

    1. Der Client fordert beim Server Daten an und der Server übermittelt ihm diese.
    2. Der Client sendet (uploaded) dem Server Daten
    3. Der Client weist den Server an, ihn bei Änderungen bestimmter Daten zu informieren.
    4. Der Client fordert den Server auf, ihn bei einer Änderung die veränderten Daten zu senden.

3.    Die Unterhaltung wird durch einen der beiden beendet.

beenden1.gif (4966 Byte)

oder

beenden2.gif (4914 Byte)

 

Eine Konversation wird mittels Nachrichten geführt. Jede der neun verschiedenen DDE- Nachrichten hat die Parameter hwnd, msg, wParam und lParam. Hwnd gibt den Window- Handle ("Fensteranker") des Zielfensters an, msg beinhaltet die Art der Nachricht. Durch den Parameter wParam wird Window- Handle des Absenders gespeichert und lParam hat einen nachrichtenspezifischen Inhalt.

 

Nachricht Bedeutung
WM_DDE_INITIATE Eine DDE- Konversation eröffnen
WM_DDE_ACK Positive oder negative Bestätigung einer Transaktion.
WM_DDE_TERMINATE Eine Unterhaltung beenden.
WM_DDE_EXECUTE Einen Befehl vom Client an den Server übergeben.
WM_DDE_POKE Daten im Server werden durch den Client verändert.
WM_DDE_REQUEST Client fordert Daten vom Server an.
WM_DDE_ADVISE Aufforderung an den Server, den Client bei Datenänderung zu informieren.
WM_DDE_DATA Mitteilung des Servers über Datenänderung und Übertragung der veränderten Daten, wenn vom Client gewünscht.
WM_DDE_UNADVISE Der Client wird nicht mehr über Datenänderungen in Kenntnis gesetzt.

 

 

2.3 Verlauf einer DDE- Konversation

Um die Konversation einzuleiten, sendet der Client die Nachricht WM_DDE_INITIATE mit der Anwendungsbezeichnung (application name) und dem Gesprächsthema (topic) als Parameter an den Server. Die Anwendungsbezeichnung legt der Programmentwickler fest, z.B. lautet der Anwendungsname von Microsoft® Word für Windows "WinWord". Ein Thema für eine Unterhaltung wäre z.B. ein "Dokument" in Word oder eine "Arbeitsmappe" in Microsoft® Excel für Windows (Anwendungsname: "Excel"). Zu jedem Thema kann es mehrere Gegenstände (items) geben. Diese Elemente der Themen sind z.B. "Textmarken" eines Word- Dokuments bzw. "Zellenbezüge" einer Excel- Arbeitsmappe.

Jeffrey D. Clark [Clark 1993, S. 23] beschreibt das Einleiten einer DDE- Konversation mit dem Einleiten eines Gespräches, bei dem sich alle Teilnehmer in einem finsteren Raum befinden. Wenn Sie den Raum betreten, um mit ihrem Kollegen Markus über den Kauf eines Kleinwagens zu reden, dann können Sie beispielsweise folgendes rufen: "Hallo Markus (Anwendungsname), hier spricht Thomas (eigener Anwendungsname). Ich möchte mit dir über den Kauf (Thema) eines Kleinwagens (Gegenstand) reden". Nun kann folgendes passieren:

Es kann aber auch sein, daß Sie nicht mehr wissen, ob ihr Kollege Markus oder Michael heißt, also rufen Sie in den Raum: "Hallo, hier spricht Thomas. Möchte sich jemand mit mir über den Kauf eines Kleinwagens unterhalten?" è Es kann sein, daß Sie keine, eine oder mehrere Anworten erhalten.

Wenn Sie sehr kontaktfreudig sind, können Sie aber auch einfach rufen: "Hallo, ich bin Thomas und würde mich gerne mit irgend jemand über ein beliebiges Thema unterhalten
è Sie werden von jedem, der Lust hat eine Antwort erhalten.

 

Einleiten einer Verbindung

Eine Konversation beginnt folgendermaßen:

Die Nachrichten zum Einleiten der Unterhaltung (WM_DDE_INITIATE) und zum Bestätigen der Anfrage (WM_DDE_ACK) werden mittels der Windows- Funktion SendMessage() versandt. Alle übrigen Nachrichten, auch WM_DDE_ACK als Antwort auf WM_DDE_EXECUTE werden mit der Windows- Funktion PostMassage() gesendet.

 

Cold- Link

Der Client kann, nachdem die Verbindung aufgebaut wurde, über einen sogenannten "Cold- Link" bestimmte Items vom Server anfordern. Der Server übergibt in seiner Antwort die Daten und kann den Client durch Setzen bestimmter "Flags" (fAck = 1) zur Empfangsbestätigung auffordern.

Kann der Server die gewünschten Daten nicht bereitstellen, sendet er eine negative Bestätigung an den Client (WM_DDE_ACK (fAck = 0)).

 

Hot- Link

Der Client hat auch die Möglichkeit, den Server anzuweisen, ihm bei einer Änderung der Daten sofort die aktuellen Daten zu senden. Hierbei spricht man von einer Hot- Link- Verbindung, welche durch die Nachricht WM_DDE_ADVISE eingeleitet wird. Auf die Anweisung des Clients antwortet der Server wie beim Cold- Link mit WM_DDE_ACK. Tritt nun eine Änderung der betreffenden Daten ein, überträgt der Server die Daten mittels WM_DDE_DATA. Dies geschieht fortlaufend, bis der Client den Hot- Link mit WM_DDE_UNADVISE beendet und der Server daraufhin mit WM_DDE_ACK antwortet.

 

Warm- Link

Bei dieser Art der DDE- Konversation fordert der Client wie bei einem Hot- Link den Server auf, ihm von jeder Datenänderung zu berichten. Beim Warm- Link kann jedoch der Client nach jeder Änderung selbst entscheiden, ob ihm die veränderten Daten gesendet werden sollen oder nicht. Die Anforderung und Übertragung der Daten wird mit einem Cold- Link bewerkstelligt.

Eine Unterscheidung zwischen Hot- und Warm- Link wird durch das Flag fNoData (Hot- Link à 0 Warm- Link à 1) ermöglicht. Die folgende Abbildung zeigt den möglichen zeitlichen Ablauf einer Warm- Link- Verbindung nachdem eine Verbindung mit WM_DDE_INITIATE aufgebaut und bestätigt wurde.

 

Austausch von Befehlen

Während einer Konversation kann die Client- Anwendung die Serveranwendung zur Ausführung eines Befehls auffordern. Hierzu übergibt sie den auszuführenden Befehl (z.B. ändere Zellenbezug in Excel) und unter Umständen dessen Argumente (z.B. eine Zeile nach unten) als Parameter der Nachricht WM_DDE_EXECUTE. Der Server antwortet mit WM_DDE_ACK und gibt mit den Flags an, ob er den Befehl ausführen konnte, oder nicht.

 

Beenden einer Verbindung

Eine DDE- Konversation wird mit der Nachricht WM_DDE_TERMINATE beendet. Ein Abbau der Verbindung kann von beiden Gesprächsteilnehmern eingeleitet werden. Wenn der Server eine Nachricht zum Beenden erhält, antwortet er mit WM_DDE_TERMINATE. Dasselbe gilt auch für den Client.

 

2.4 Die DDEML- Bibliothek

Laut Clark [Clark 1993, S.57 ff] findet sich unter dem Namen Dynamic Data Exchange Management Library (DDEML) eine dynamisch einbindbare Bibliothek, die eine Programmierschnittstelle für DDE- Anwendungen bereitstellt. Die DDEML "stellt" sich zwischen die Anwendungen und das eigentliche DDE- Nachrichtensystem (s. Grafik) und hat zwei Hauptaufgaben:

Jede Anwendung, welche eine DDEML- Konversation führen möchte, muß sich zunächst mit der Funktion DdeInitialize bei der DDEML- Bibliothek registrieren. Erst nach erfolgreicher Registrierung von Client und Server, wobei die Server- vor der Client- Anwendung registriert werden muß, kann der Client über die Funktion DdeConnect eine indirekte Verbindung zur Server- Anwendung aufbauen. Eine direkte Konversation zwischen den Anwendungen mit DDEML ist nicht möglich. Der Informationsaustausch, bei DDEML- Unterhaltungen auch Transaktion genannt, erfolgt ausschließlich über Aufrufe von DDEML- Funktionen. Dadurch erlangt die ganze Konversation mehr Stabilität und ist vor Abstürzen sicherer als eine auf reine DDE- Nachrichten gestützte Unterhaltung.

Mit der Funktion DdeClientTransaction und den in der Tabelle genannten Parametern kann der Client dieselben Konversationen mit dem Server führen, wie bei einer "normalen" DDE- Unterhaltung, mit dem Unterschied, daß die DDEML jede Transaktion zunächst auf ihre Gültigkeit überprüft und sie erst dann überträgt.

 

Transaktionsart Bedeutung
XTYP_REQUEST Client fordert Daten vom Server an.
XTYP_EXECUTE Einen Befehl vom Client an den Server senden
XTYP_POKE Client sendet Daten an den Server
XTYP_ADVSTART Aufbau eines Hot- oder Warm- Links
XTYP_ADVSTOP Beenden eines Hot- oder Warm- Links

 

Eine genaue Beschreibung der einzelnen Transaktionen und der DDEML- Transaktionsverwaltung würde den Rahmen dieses Referates sprengen. Deshalb möchte ich am Beispiel eines Briefversandes per Post die Funktionsweise einer DDEML- Unterhaltung kurz erläutern.

Wenn Sie einen richtig adressierten und frankierten Brief (à eine den DDEML- Konventionen entsprechende Nachricht) in den Briefkasten werfen (à an die DDEML übergeben), erwarten Sie, daß der Brief bei dem richtigen Empfänger (à Server) ankommt. Sie müssen sich nicht um die Koordination des Transports (à DDE- Nachrichten), geschweige denn um den eigentlichen Transport des Briefes (à wo ist der Server) kümmern. Sie erwarten entweder eine Anwort des Empfängers (à über die DDEML) oder eine Benachrichtigung, falls der Brief unzustellbar war (à DDEML- Fehlermeldung). Ein Informationsaustausch per Post (à DDEML) ist natürlich nur möglich, wenn sowohl der Empfänger (à Server) als auch der Absender (à Client) über jeweils eine der Post bekannten Adresse (à DDEML- Registrierung durch DdeInitialize) verzeichnet sind und beiden Kommunikationspartnern die Adressen bekannt sind.

 

3. Andere Kommunikationstechniken

Die Konversation mit DDE unter Windows ist seit der Version 3.0 möglich. In der Version 3.1 wurde Windows unter anderem um die DDEML erweitert. Außerdem wurde die Kommunikation und der Austausch von Informationen durch OLE 1.0 mit OLE 2.0 ausgebaut. Durch Windows für Workgroups 3.11 wurde DDE mit der Erweiterung NetDDE netzwerkfähig.

 

3.1. OLE

Das Kürzel OLE steht für Object Linking and Embedding und wird als Nachfolger von DDE gesehen, da OLE 1.0 noch komplett auf DDE- Nachrichten basiert. OLE 2.0 benutzt zur Kommunikation sogenannte Lightweight Remote Procedure Calls (LRPC). Lightweight bedeutet in diesem Fall "kein Netzwerk" und besagt, daß OLE 2.0 nicht netzwerkfähig ist.

Die Informationen, welche ein Client vom Server bezieht, werden entweder in das Verbunddokument (z.B. ein Word- Dokument) eingebettet (embedded) oder verknüpft (linked). Sind die Daten eingebettet, so werden sie im Verbunddokument gespeichert. Werden die Daten jedoch verknüpft, so wird im Verbunddokument nur ein Verweis auf die Daten gespeichert. Daraus ergeben sich zugleich Vor- und Nachteile:

 

 

Einbetten

Verknüpfen

Vorteile
  • Das Verbunddokument mit seinem gesamten Inhalt ist transportierbar
  • Daten können im Verbunddokument ohne Auswirkung auf die ursprünglichen Daten verändert werden
  • Geringerer Speicherbedarf
  • Bei Veränderung der verknüpften Daten automatische Änderung im Verbunddokument
Nachteile
  • Hoher Speicherbedarf
  • Keine automatische Aktualisierung der Daten im Verbunddokument
  • Beim Löschen der Daten stehen sie auch nicht mehr im Verbunddokument zur Verfügung

 

OLE ist ein dokumentzentrierter Ansatz, da das Verbunddokument im Mittelpunkt steht. Daten können in einem Verbunddokument gezielt mit den dafür geeigneten Werkzeugen bearbeitet werden, ohne daß das Dokument verlassen werden muß. Der Benutzer muß sich nur auf das "Was" (Daten) konzentrieren, nicht auf das "Wie" (Anwendung). Im Gegensatz dazu folgt DDE dem anwendungszentrierten Ansatz, bei dem die Anwendung im Mittelpunkt steht und der Benutzer wissen muß, welche Daten mit welcher Anwendung bearbeitet werden können (vgl. [Clark 1993, S. 266]). OLE wird deshalb in Entwicklerkreisen auch als "funktionierendes DDE" bezeichnet.

 

3.2 Winsock

Bei einer Kommunikation von Windows- Programmen mit Winsock ist ein Informationsaustausch zwischen den Anwendungen über ein beliebiges Netzwerk möglich. Dazu "klemmt" sich die Winsock- Bibliothek (ähnlich der DDEML, nur auf einer anderen Schicht) zwischen die Windows- Anwendungen und das Netzwerk. Im OSI- Schichtenmodell ist Winsock zwischen den anwendungsorientierten und den transportorientierten Schichten angesiedelt (vgl. [Quinn, Shute 1996, S 26]). Zur Vereinfachung der Winsock- Programmierung stellt Winsock eine API (Application Programing Interface) zur Verfügung. Diese API ermöglicht mit ihren Funktionen eine komfortable und systemunabhängige Art der Kommunikation.

 

4. Ausblick

4.1 Distrubted Component Object Model (DCOM)

Beim COM (Component Object Model) werden artverwandte Funktionen zu sogenannten Komponenten zusammengefaßt. So kann z.B. Word und Excel auf dieselbe Komponente zum Drucken von Daten zurückgreifen. Dieses System verringert zum einen den Programmieraufwand und zum anderen den benötigten Speicherbedarf. DCOM (Distributed COM) ermöglicht sogar eine Verteilung der Komponenten im Netzwerk. Wenn ein Client die Hürde des Verbindungsaufbaus zum Server überwunden hat, ist der Zugriff auf die Funktionen und damit auch der Daten des Servers problemlos.

 

Die Zukunft der Kommunikation von Windows- Programmen liegt in Techniken wie dem DCOM. Eine Verfeinerung des Client- Server- Prinzips weit über das Three- Tier- Modell hinaus hat bereits bei den aktuellen Anwendungen Einzug gehalten. Beim Three- Tier- Modell (Drei- Schichten- Modell) unterscheidet man zwischen Oberflächenschicht (GUI- Schicht), der Business- Schicht und der Datenbank- Schicht. Aktuelle Entwicklungssprachen wie z.B. JAVA bieten dem Programmierer jedoch Möglichkeiten zur Entwicklung von Komponenten mit kleinstem Funktionsumfang. Als populäres Beispiel sei an dieser Stelle Lotus "eSuite" genannt. Die "Kunst" der eigentlichen Programmerstellung besteht später nur noch im "Snap together" (Snap together = Suche nach Software, die im Client- Server Sinne gut zusammenarbeitet - vgl. [Treffert 1999]) der einzelnen Komponenten.

Dennoch werden Kommunikationstechniken wie DDE und OLE nicht nur aus Kompatibilitätsgründen von Windows- Version zu Windows- Version "mitgeschleppt", sondern dienen als Basis für die einfach zu handhabende Komponenten- Kommunikation.