monitor 4_97

Activation (auch als Compound Document
bezeichnet) bestehen.
Das Component Object Model ist
eine Sammlung von Klassen mit den jeweiligen
Schnittstellen (Interfaces).
Entscheidender Unterschied zwischen
gängigen Betrachtungsweisen der
Objektorientierung und dem COM-
Konzept ist die Tatsache, daß ein COM-
Objekt mehrere Interfaces anbieten
kann. Ein spezielles Interface wird dabei
immer unterstützt, das Unknown-Interface.
Unknown bietet als wesentliche
Methode die Query-Interface-Methode
an. Mit Query-Interface können weiterführende
Interfaces abgefragt werden.
Physisch stellt ein Interface immer eine
Menge von Funktionszeigern dar. Ein
C++-Objekt (oder auch Small-Talkoder
Java-Objekt) hat immer nur ein Interface.
Dieses Interface setzt sich aus
den eigenen öffentlichen Attributen
und Methoden und denen der Mutterklassen
zusammen. Dieses Interface ist
somit eindeutig durch die Klasse bestimmt.
Ein Abfragen nach weiteren Interfaces
ist sinnlos. COM dagegen kennt
keine Vererbung. Die Anhäufung von
Interfaces soll im COM die Vererbung
ersetzen.
COM-Verbindungen beginnen mit
der Suche der Klassen-Kennung
(CLSID) in der Registrierungsdatei. Der
Suchbegriff setzt sich aus dem Komponenten-,
Klassen- und Versionsbezeichner
zusammen (z.B. Excel.Application.5).
Eine COM-API-Funktion kann
eindeutige CLSIDs, die sich aus Zeitstempel
und Netzwerkkennung zusammensetzen,
generieren.
Über die CLSID wird der gesuchte
Server gestartet und ein Metaklassenobjekt
zur Objektgenerierung (class
factory) im Server instanziert. Diese
Class Factory instanziert schließlich das
gesuchte Server-Objekt. Bei COM-
Klassen, die über Visual C++ angelegt
wurden, ist die Class Factury-Klasse
eine Kindklasse von COleObject-
Factory. Diese Kindklasse wird über einen
Makro DECLARE_OLECREATE
eingerichtet. Über das Query-Interface
erhält man vom Serverobjekt das gesuchte
Interface. Die Lokalität des
Serverobjekts kann dabei im selben Prozeßrahmen
des Clients (In-Proc-Server)
oder als COM-Objekt lokal oder remote
sein. Innerhalb des Clients befindet sich
dann ein Proxy-Objekt, das die Schnittstellen
des Servers nachbildet. Die
Kommunikation zwischen Proxy und
dem Gegenüber im Server (Stub) wird
über COM abgewickelt.
Ziel dieses 1989 gegründeten und herstellerunabhängigen
Konsortiums war die
Bereitstellung einer geeigneten Infrastruktur
für verteilte objektorientierte Programme
auf heterogenen Netzwerken. Um die
Standardisierung in geordnete Bahnen zu
lenken, hat die OMG eine Referenzarchitektur
OMA (Object Management Architecture)
definiert, deren Bestandteile die
beteiligten Mitglieder schrittweise mit Inhalt
füllen.
Der Object Request Broker (ORB) ist
Kern der OMA. Seine primäre Aufgabe besteht
in der Übermittlung von Methodenaufrufen
von einer Client-Applikation zu
einem entfernten Objekt sowie in der
Rückmeldung von Fehlern und Ergebnissen.
Corba ist das Kürzel für ,,Common Object
Request Broker Architecture“. Corba
ist allerdings mehr als ein bloßer Mechanismus
für Methodenaufruf zwischen Prozessen.
Der Zugriff auf entfernte Objekte soll
auch unabhängig von Programmiersprachen
erfolgen. Ein solches Objektmodell
findet sich in der Corba-Spezifikation. Jedes
Objekt ist Instanz eines Interface-Typs.
Ein Interfacetyp repräsentiert eine Klasse
mit möglicherweise mehreren Elternklassen.
Unterstützung findet dabei Schnitt-
COM oder ActiveX-Controls kennzeichnen
sich durch Schnittstellen, die
als Methoden (Diensterbringung) und
Eigenschaften (Properties) verfügbar
sind. Einige Standard-Eigenschaften
(Stock-Properties), wie Schriftart-Einstellung
oder Farbeinstellung sind bereits
vorbereitet. Stock-Properties können
einfach in ActiveXControls
integriert werden. Grundsätzlich sollten
Merkmale, die gesetzt und gelesen
werden und zudem ein Attribut zur
Datenhaltung erfordern, als Properties
realisiert werden. Methoden sollen die
Services des Controls sein. Für den Einsatz
des Controls spielt es kaum eine
Rolle, ob für bestimmte Aufgaben Properties
oder Methoden eingesetzt werden.
An ihren Container können COM-
Controls über Events Botschaften zurücksenden.
Gerade diese Events verschieben
das sonst übliche
Client/Server-Verhältnis in ein PeertoPeer-Verhältnis.
Das Control selber
kann beliebig komplexe Darstellungen
übernehmen. Von einfachen Eingabefeldern
bis zu aufwendigen TabControls
mit integrierten Listen, die je Zeile wieder
Controls enthalten, sind COM-Controls
möglich und üblich. Gerade hier
sollte die Zielsetzung sein, bestehende
Projekte auf Controls zu verteilen und so
auch über Active X verfügbar zu ma-
OMG und Corba
stellenvererbung, nicht jedoch Implementierungsvererbung.
Damit eine Applikation
auf ein Corba-Objekt zugreifen kann,
muß die Interoperabilität zwischen dem
Aufrufer und dem entfernten Objekt gewährleistet
sein. In Corba gibt es zu diesem
Zweck eine eigene Schnittstellenbeschreibungssprache
namens IDL (Interface Definition
Language). IDL enthält ausschließlich
Elemente zur Datenbeschreibung
und keinerlei Anweisungskonstrukte.
Die Syntax ist an C++ angelehnt.
Im Corba-Standard 1.2 fehlt eine Spezifikation,
wie die Kopplung verschiedener
Corba-Implementierungen aussehen soll.
Das hat zu fehlender Interoperabilität zwischen
den Produkten unterschiedlicher
Hersteller geführt. Der Nachfolgestandard
Corba 2.0 legt nun fest, wie Corba-Produkte
auf Basis vorhandener Kommunikationsprotokolle
miteinander zusammenarbeiten
müssen. Einzig die Kooperation auf Basis
von TCP/IP ist verpflichtend, alles andere
optional. Wollen zwei beliebige Broker
über TCP/IP Informationen austauschen,
müssen sie hierfür das standardisierte IIOP
(Internet Inter ORB Protocol) benutzen. ❏
chen. Bei neuen Projekten bietet sich ein
solcher modularer, komponentenbasierender
Ansatz besonders an.
ActiveX-Steuerelemente können auf
HTML-Seiten plaziert und über Skripten-Sprachen
(JavaScript von Netscape
und Visual Basic Script von Microsoft)
verknüpft werden. Für die Bearbeitung
von Skripten sorgen im Internet-Explorer
eigenständige Komponenten, die
Scripten Engines. Der HTML-Viewer
weiß also nicht, in welcher Sprache ein
auszuführendes Script geschrieben ist.
Statt dessen erzeugt er eine Instanz, der
zum Skript gehörenden Scripten-Engine
und veranlaßt sie dazu, mit der Ausführung
des Skriptes zu beginnen.
Die für den Informationsaustausch
zwischen Viewer und Scripten-Engine
notwendigen Schnittstellen definiert
die Spezifikation des ActiveX-Scripting.
Scripten-Engines werden in der
Regel als prozeßinterner Server implementiert,
wodurch jede beliebige Anwendung
als Skripten-Host arbeiten
kann, wenn sie eine Scripten-Engine
lädt und von ihr gesteuert wird.
Beim Einpflanzen von Controls auf
HTML-Seiten können die persistenten
Eigenschaften des Controls bearbeitet
werden. Mögliche persistente Eigenschaften
sind Voreinstellungen des Controls
oder vorgegebene Auswahl-Daten
bis hin zu Multimedia-Daten. Die Per-
66 monitor 4/97