Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03366.jsonl.gz/152

COM-Komponenten-Handbuch ISBN 3-8273-1936-6
Entwickler müssen Informationen über das System gewinnen, um die von Ihnen erstellten Anwendungen auf die jeweilige Umgebung anzupassen. Moderne Windows-Anwendungen nutzen an vielen Stellen vom Betriebssystem bereitgestellte Dienste, wie zum Beispiel den Verzeichnisdienst Active Directory .
Administratoren stehen vor der Aufgabe, immer größer werdende Netzwerke, die immer mehr Konfigurationsmöglichkeiten bieten, in immer kürzerer Zeit zu verwalten und trotzdem immer ständige Verfügbarkeit sicherzustellen. Der Einsatz von Batch-Dateien und Skripten hilft Administratoren, aufwendige und wiederkehrende Aufgaben zu automatisieren.
Der Zugriff auf das Windows-Betriebssystem und Windows-Anwendungen war lange Zeit mühsam, weil es nur komplexe Application Programming Interface s (API s) gab. Entwicklern standen auf den Programmiersprachen C und C++ basierende APIs wie das Win32-API für den Zugriff auf das Windows-32-Bit-Betriebssystem oder das Messaging Application Programming Interface (MAPI) für den Zugriff auf den Exchange Server zur Verfügung. Diese APIs können zwar grundsätzlich auch aus anderen Programmiersprachen angesprochen werden, doch aufgrund der Komplexität der APIs stehen längst nicht allen Programmiersprachen alle API-Funktionen zur Verfügung.
Administratoren, die sich nicht in diese Tiefen der API-Programmierung stürzen wollten, konnten nur mit der sehr einfachen DOS-Batch -Sprache bzw. mit einzelnen parametrisierbaren Kommandozeilenwerkzeugen mühsam Automatisierungslösungen entwickeln.
Es wäre untertrieben, einfach nur zu sagen, der Trend, objektorientierte Softwarekomponenten einzusetzen, habe auch vor Windows nicht halt gemacht. Vielmehr hat Microsoft mit seinem Component Object Model (COM) die Verbreitung objektorientierter Softwarekomponenten stark gefördert. Das neue Komponentenmodell .NET (sprich »DOTNET «) wird für einen weiteren Schub sorgen.
Tief im Inneren ist COM nicht weniger komplex als das Win32-API . Das wissen aber heute eigentlich nur noch die C++-Entwickler. Denn Microsoft hat für Visual Basic und verschiedene Skriptsprachen Laufzeitumgebungen geschaffen, die die Arbeit mit COM sehr einfach machen.
COM-Komponenten sind in Windows inzwischen allgegenwärtig: in der Benutzeroberfläche, beim Datenzugriff, bei der Webentwicklung, in den Office - und BackOffice -Anwendungen. Viele Dienste des Betriebssystems und auch viele Anwendungen lassen sich inzwischen über COM-Komponenten ansteuern und sind damit gleichermaßen für Visual Basic -Entwickler auch als für Administratoren , die Skriptsprachen einsetzen, einfach zu programmieren.
Die Bewertung »einfach« sollte man im Vergleich zur Programmierung des Win32-APIs oder zur "Hardcore"-COM-Programmierung mit C++ sehen. Auch Visual Basic und die Skriptsprachen verlangen vom Nutzer noch viel Wissen über Programmierung. Einen Makrorekorder, der aus den Mausbewegungen des Administrators in den Management-Konsolen automatisch Programmcode generiert, gibt es zumindest bisher noch nicht.
Zumindest innerhalb der Windows-Welt ist COM ein erfolgreicher Ansatz: COM ist existenzieller Bestandteil aller 32-Bit-Windows-Betriebssysteme. COM wird nicht nur von zahlreichen Anwendungen, sondern auch von Windows selbst genutzt. So beruht auch das Active Scripting (alias Windows Scripting ) auf COM-Komponenten.

Diese Kapitel erklärt nur die wichtigsten (Ober-)begriffe von COM. Eine detaillierte Einführung in COM erhalten Sie in Kapitel 2 (Theorie) und Kapitel 3 (Praxis). Grundlagen zum Thema objektorientierte Softwarekomponenten erläutert der Anhang A.
Durch die Fachwelt geistert im Zusammenhang mit COM bzw. anstelle des Begriffs COM eine Reihe von weiteren Namen, wobei die MarketingMaschinerie von Microsoft selbst einen großen Teil zur Verwirrung beigetragen hat.
Häufig stellt sich die Frage, was überhaupt der Oberbegriff ist: COM, DCOM oder ActiveX ? Der Autor dieses Buches verwendet stets COM als Oberbegriff. Die Nachwehen der ActiveX-Manie sind aber noch in vielen Bereichen spürbar und lassen sich nicht so leicht aus der Fachwelt entfernen. So würde der Autor lieber von COM Scripting als von Active Scripting sprechen, beugt sich aber in diesem Fall der üblichen Sprechweise.

Wenn jemand von einem COM API spricht, dann meint er damit nicht das in ole32.dll implementierte COM API, sondern eine COM-Komponente. Das ist verwirrend. Vermeiden Sie also bitte, eine Komponente so zu nennen.
Microsoft hat den Begriff ActiveX seit 1996 so sehr in den Vordergrund gestellt, dass er schließlich mit COM gleichgesetzt wurde. Erst im Laufe der Jahre 1998 und 1999 fand eine Rückbesinnung statt, die schließlich zur Einschränkung von ActiveX auf einen Dienst von COM führte. Microsoft definiert in einem Beitrag in der Knowledge Base (»Description of ActiveX Technologies«, [Q154544], Stand August 1999) ActiveX über folgende Teiltechnologien:
ActiveX-Steuerelemente (früher OLE-Steuerelemente oder OCX-Steuerelemente) sind visuelle COM-Komponenten zur Gestaltung von Benutzeroberflächen. Diese Steuerelemente werden in ActiveX Control Hosts platziert. Es gibt jedoch eine spezielle Form von Steuerelementen, sogenannte Design Time Controls (DTC) , die, wie der Name schon sagt, nur zur Entwurfszeit Steuerelemente sind. Während der Programmausführung sind sie innerhalb des ActiveX Containers nicht sichtbar. Beispiele dafür sind das Winsock-Steuerelement ( MSWinsockLib , mswinsck.ocx ) und das Skript-Steuerelement ( MSScriptControlCtl , msscript.ocx ). Einige Steuerelemente (z.B. das Winsock-Steuerelement ) können zudem auch ganz unabhängig von einem ActiveX Container genutzt werden. Diese Steuerelemente lassen sich auch wie normale nichtvisuelle Komponenten instanziieren und per Programmcode steuern.
ActiveX-Dokumente sind Dokumente , die aus verschiedenen, aus unterschiedlichen Anwendungen stammenden Teildokumenten bestehen können. Dabei können die Teildokumente innerhalb der Host-Anwendung des Gesamtdokuments bearbeitet werden. ActiveX-Dokumente verwenden Sie, wenn Sie eine eingebettete Excel-Tabelle in einem Word-Dokument bearbeiten. Früher hieß diese Technik Object Linking and Embedding (OLE) bzw. Vor-Ort-Aktivierung. Ein ActiveX Document Host ist eine Umgebung, die ActiveX-Dokumente anzeigen kann. Ein Beispiel für einen Document Host ist der Internet Explorer.
Immer wieder verwenden Microsoft und andere Quellen den Begriff ActiveX synonym zu COM-Automation . Demnach wäre eine automationsfähige Komponente eine ActiveX-Komponente. So erklärt sich zumindest der Name Active Scripting (auch: ActiveX Scripting ) . Active Scripting basiert auf automationsfähigen Komponenten.
Es ist auch nicht korrekt, ActiveX auf eine »Spezifikation zur Benutzung von COM-Objekten über das Internet« (z.B. wie in [RED97], S. 4) zu reduzieren, da ActiveX auch außerhalb des Internets eingesetzt wird (z.B. die ActiveX-Steuerelemente in Windows-Fenstern ).
COM unfasst einen Binärstandard für Komponenten und ist daher programmiersprachenunabhängig. Es sind inzwischen viele Sprachen (z.B. C++, C, Java, Visual Basic, Delphi) verfügbar, die COM-Komponenten nutzen und erzeugen können.
COM ist ein objektorientiertes Komponentenmodell, das mit Konzepten wie Klassen, Schnittstellen, Attributen und Methoden arbeitet. Die Klassen sind in der Regel in hierarchischen Objektmodellen angeordnet. Für den Nutzer der Komponente (den sogenannten COM-Client ) ist die Komponente (der sogenannte COM-Server ) eine Klassenbibliothek.
Es sind bereits zahlreiche Komponenten für den Zugriff auf unterschiedliche Betriebssystem- und Anwendungsfunktionen verfügbar. Dieses Kapitel unternimmt einen Streifzug durch die Systemfunktionen, die derzeit durch Komponenten angesprochen werden können. Sofern die Komponenten in diesem Buch besprochen werden, finden Sie Hinweise auf die entsprechenden Kapitelnummern.
Die hier vorgestellten Komponenten sind nur ein Querschnitt der verfügbaren COM-Komponenten zur Automatisierung von Windows. Darüber hinaus gibt es aber noch weitere, zum Teil sehr spezielle Komponenten, die im Rahmen von Automatisierungslösungen interessant sein könnten.
Nicht alle COM-Komponenten stammen von Microsoft selbst: Es gibt inzwischen unzählige Komponenten anderer Anbieter - zum Teil auch als Share- und Freeware. Auch selbst entwickelte COM-Komponenten können unabhängig von der Programmiersprache, in der sie implementiert wurden, verwendet werden. Anwendungen, die direkt komponentenbasiert entwickelt werden, können sehr einfach angesteuert werden.
Einige Komponenten kapseln den Zugriff auf bestehende Application Programming Interfaces (APIs) von Betriebssystem und Anwendungen . Die Komponenten sind hier Stellvertreter, die die (komplexen) API-Funktionen kapseln. Als positiver Nebeneffekt entsteht dabei in der Regel ein einfaches Objektmodell als Ersatz für komplexe Reihen von API-Aufrufen. Andere Komponenten implementieren eigenständige Funktionalitäten, für die keine weiteren Anwendungen nötig sind.
Die Möglichkeiten des Systemzugriffs mit COM-Komponenten sind vielfältig, deshalb wird der Aufwand eines Entwicklungsprojekts (egal, ob es um ein Skript oder eine »große« Software geht) maßgeblich durch die Auswahl der Komponenten bestimmt.
Eine intensive Recherche nach vorhandenen COM-Komponenten ist ein entscheidender Erfolgsfaktor. Mit der zunehmenden Verbreitung des Komponentengedankens werden Make-or-Buy -Entscheidungen zu einem ständigen Begleiter im Softwareentwicklungsprozess . Entwickler werden sich fragen lassen müssen, ob es notwendig war, eigene Routinen zu entwickeln, anstatt auf dem Markt verfügbare Komponenten zu einer Anwendung zusammenzubauen. Eine unterlassene Internet-Recherche kann dazu führen, dass man sich tagelang mit Problemen beschäftigt, die andere mit wesentlich geringeren Kosten längst gelöst haben.
Eine Fensterverwaltung ist auch Teil von MiniOLE [KNU01]. Das Common Dialog Control ermöglicht die Nutzungen von Windows-Standarddialogen (Daten öffnen, Drucker auswählen etc.). Einfache Windows-Bildschirmmasken kann man mit QuickPrompts [TOP00] erzeugen.
Die Benutzerverwaltung unter Windows NT4, Windows2000, Windows XP und Windows.NET (jeweils einschließlich des Active Directory) ermöglicht das Active Directory Service Interface (ADSI) , siehe Kapitel 13. Funktionen zur Benutzerverwaltung bietet auch die ISPSignup -Komponente aus dem IIS Resource Kit.
Die Windows Management Instrumentation (WMI) ist ein übergreifender Ansatz zum Zugriff auf alle möglichen Arten von System- und Netzwerk-informationen (Kapitel 14). WMI ermöglicht auch den Zugriff auf Informa-tionen aus Quellen wie Registry, Dateisystem und Ereignisprotokollen, die durch andere Einzelkomponenten bereits abgedeckt sind. Während WMI den Vorteil der Einheitlichkeit bietet, sind die speziellen Komponenten im konkreten Anwendungsfall oft etwas einfacher zu handhaben. Eine bunte Mischung ausgewählter Funktionen bieten auch die in drei Komponenten aufgeteilten OnePoint Utility Objects (Kapitel 25). Für den Windows Installer Service gibt es ein Windows Installer Object Model .
Die WSH Runtime-Komponente (Kapitel 4) von Microsoft kann Einträge nur erzeugen, aber nicht lesen. Diese Komponenten können zudem nur in das Anwendungsprotokoll, nicht aber in andere Protokolle schreiben.
Die Freeware -Komponente STMAdmin von Sean McLeod kann Einträge über ein Objektmodell in jedes beliebige NT-Ereignisprotokoll schreiben und auch Einträge lesen (Kapitel 12.1). Die Firma ACES bietet im Rahmen des ACES WinNT Automation Kit auch die Möglichkeit, auf ein Ereignisprotokoll wie auf eine Datenbanktabelle zuzugreifen (Kapitel 12.2). In den OnePoint Utility Objects for Scripting , die mit dem Microsoft Operations Manager (MOM ) mitgeliefert werden, gibt es eine Klasse, mit der man ein Ereignisprotokoll in eine Datei sichern und danach leeren kann (Kapitel 25).
Wieder bietet die WSH Runtime-Komponente (Kapitel 4) nur rudimentäre Zugriffsmöglichkeiten auf die Registry. Als bessere Alternative wird in diesem Buch die Komponente RegCol (Kapitel 11) vorgestellt. Rechte auf Registry-Schlüssel können nur mit der ADSSecurity-Komponente (Kapitel 13) geändert werden (ADS steht für Active Directory Service ).
Die Basiskonfiguration der auf dem System installierten COM-Komponenten ist entweder über direkte Registry-Manipulation oder durch WMI möglich. Für die erweiterten Einstellungen im Zusammenhang mit dem Microsoft Transaction Server und COM+ gibt es eigene Komponenten (Kapitel 15).
Den Zugriff auf das Dateisystem ermöglichen in erster Linie die File System Objects (FSO) von Microsoft, die als ein Teil der Scripting Runtime Library in Kapitel 5 vorgestellt werden. Zum Teil ergänzt, zum Teil redundant abgebildet werden die Funktionen von FSO in den Shell Objects (Kapitel 6). Zum Zugriff auf die Rechte in NTFS -Dateisystemen benötigen Sie die ADsSecurity-Komponente (Kapitel 13.10.5). Zum Zugriff auf entfernte Dateisysteme via FTP gibt es neben der Internet-Transfer-Komponente von Microsoft zahlreiche interessante Lösungen von Drittanbietern (Kapitel 21).
Die in Windows2000 mitgelieferte DfsCore Komponente ermöglicht die Verwaltung des Distributed File Systems (DFS ). Für die Verwaltung des Quota-Managements gibt es in Windows2000 die Microsoft Disk Quota-Komponente .
TCP/IP -Kommunikation auf Transportebene ermöglicht die Microsoft Winsock-Komponente (Kapitel 21.1). Auf Anwendungsebene bietet Microsoft die Internet Transfer-Komponente zur HTTP - und FTP -Kommunikation (Kapitel 21.2). Gerade in diesem Bereich gibt es auch viele andere Anbieter, z.B. ASPInet (Kapitel 20.3), Mabry FTPX (Kapitel 21.4) und die OnePoint Utility Objects for Scripting (Kapitel 25).
Für die Verarbeitung von elektronischen Nachrichten stellt Microsoft mit den Collaboration Data Objects (CDO) inzwischen eine ganze Familie von Komponenten zur Verfügung (Kapitel 18 und 19). Es gibt auf dem Free - und Shareware markt zahlreiche Komponenten für das Handling von SMTP -Nachrichten (z.B. JMAIL , Kapitel 20). Einige CDO -Versionen beherrschen darüber hinaus aber die Nachrichtenkommunikation via MAPI . Auch die Firma Lotus bietet mit den Domino Collaboration Objects (DCO) für Lotus Notes 5.x bzw. Notes OLE Objects für Notes 4.x zwei COM-Komponenten [LOT01a] für den Zugriff auf ihr Groupware -System an.

Im Gegensatz zu den großen Brüdern Microsoft Outlook 97/98/2000/2002 kann keine der bisher veröffentlichten Versionen von Outlook Express automatisiert werden, da es kein in einer COM-Komponente implementiertes Objektmodell dafür gibt.
Beliebige Textdateien können mit der Scripting Runtime-Komponente (Kapitel 5) bearbeitet werden. Für INI - und CSV -Dateien gibt es u.a. die Komponente WindowsScripting (Kapitel 23) und MiniOLE [KNU01]. Die ActiveX Data Objects (ADO) können auf strukturierte Textdateien zugreifen (Kapitel 9). XML -strukturierte Textdateien werden mit Hilfe der MSXML-Komponente verarbeitet (Kapitel 8). ADO kann Datenbanktabellen in XML-Dateien umwandeln. Das Text Object Model (TOM) für den Zugriff auf Rich-Text -Dateien wird in diesem Buch nicht vorgestellt.
Verschlüsselungsfunktionen bietet Microsoft in der ISPSignup -Komponente aus dem IIS Resource Kit . Eine Komponente zur Nutzung von Pretty Good Privacy (PGP ) unter dem Namen NSDPGP gibt es bei [PGP01].
Die ActiveX Data Objects (ADO) (Kapitel 9) sind allgemeine Komponenten für den Zugriff auf Datenquellen. Dazu gehören neben Datenbanken auch Textdateien und Verzeichnisdienste. Neben der ADO-Kernkomponente gibt es inzwischen zwei Erweiterungen: Microsoft ADO Extensions for DDL and Security (ADOX) und ADO Multi Dimensional (ADOMD) für die OLAP-Dienste.
Der Zugriff auf den Inhalt von Microsoft SQL Server -Datenbanken ist mit den ActiveX Data Objects (ADO) möglich. Die Konfiguration des SQL Servers und der Datenbanken selbst wird dagegen durch die SQL Server Distributed Management Objects (SQL-DMO; Kapitel 16) abgebildet. Für die Administration der OLAP-Dienste (Online Analytical Processing ) gibt es die Decision Support Objects (DSO) .
Microsoft liefert einen OLEDB-Provider für Oracle , so dass auch Oracle-Datenbanken via ADO angesprochen werden können. Darüber hinaus bietet Oracle mit der Komponente Oracle Objects for OLE (OO4O) eine eigene, spezialisierte Lösung für den Zugriff von COM-Sprachen auf die eigenen Datenbanken an.
Eine der wichtigsten Komponenten ist das Active Directory Service Interface (ADSI) (Kapitel 13), mit dem Verzeichnisdienste unterschiedlicher Art (z.B. Active Directory , Exchange Server , Internet Information Server ) verwaltet werden können. Neben der Verwaltung des Active Directory unter Windows2000 gehört dazu auch die Benutzer- und Ressourcenverwaltung unter NT 4.0. Ausgewählte Funktionen zum Umgang mit dem Active Directory bietet auch die Komponente OnePoint Utility Objects for Active Directory (Kapitel 25).
Für den Zugriff auf den Exchange Server gibt es inzwischen mehrere Lösungen, die zum Teil redundant sind. Da der Exchange- Verzeichnisdienst LDAP -fähig ist, kann auch hier das Active Directory Service Interface (ADSI) (Kapitel 13.8) eingesetzt werden.
Für die Konfiguration der Rechte auf Exchange-Verzeichnisobjekte benötigen Sie die ADsSecurity-Komponente (Kapitel 13.10.5). Eine Ausnahme bilden auch hier die öffentlichen Ordner, deren Rechte Sie nur über die ACL-Komponente (ACL steht für Access Control List ) aus dem Exchange Resource Kit setzen können. Die ebenfalls mit dem Exchange Resource Kit gelieferte AcctCrt - Komponente (AcctCrt steht für Account Control ) bietet dagegen nur Funktionen, die sich auch mit ADSI und der ADsSecurity-Komponente erledigen lassen.
Primär auf die Inhalte, also den Message Store , fokussiert die Komponente Collaboration Data Objects (CDO) (Kapitel 18 und 19). Zum Teil kann CDO aber auch auf den Verzeichnisdienst zugreifen. Für spezielle, versteckte Nachrichten wie Posteingangsregeln und Event Agents gibt es eigene Automatisierungskomponenten in Form der Rule-Komponente ( Microsoft Exchange SDK 5.5 Rules 1.0 ) sowie der ESConfig-Komponente ( Microsoft Exchange Event Service Config 1.0 Library ). Öffentliche Ordner können nur mit CDO, nicht aber mit ADSI eingerichtet werden. Die Entwicklung von einfachen Workflow -Anwendungen für Exchange 5.5 ermöglichen die Microsoft Routing Objects .
Die OnePoint Utility Objects for Exchange (Kapitel 22) bieten eine wichtige Funktion, die man in allen anderen Microsoft-Automatisierungskomponenten vergeblich sucht: Mit dieser Komponente ist man in der Lage zu ermitteln, wie groß die einzelnen Postfächer und öffentlichen Ordner auf einem Exchange Server sind.
An dieser Aufteilung der Automatisierungsschnittstellen hat sich mit Exchange2000 einiges geändert. Die Collaboration Data Objects 3.0 haben sich gegenüber den CDO -Versionen für Exchange 5.5 stark verändert (Kapitel 19.3). Das Active Directory Service Interface (ADSI) spielt aufgrund der Integration von Exchange2000 in das Active Directory weiterhin eine zentrale Rolle. Hinzugekommen ist einerseits der Zugriff auf den Exchange Information Store via ActiveX Data Objects (ADO) und zum anderen eine neue Komponente mit dem Namen CDO for Exchange Management (CDOEXM) , beschrieben in Kapitel 19.4.
Für den Bereich der Workflow-Funktionen bietet Exchange2000 die Komponente Microsoft CDO Workflow Objects for Microsoft Exchange (CDOWF) . Einige Funktionen von Exchange2000 können auch über die Windows Management Instrumentation (WMI) überwacht und gesteuert werden. Das komplexe Thema der Automatisierung von Exchange2000 wird in Kapitel 19 zusammenhängend behandelt.
können per COM gesteuert werden, sondern auch Hilfsanwendungen wie Microsoft Graph und der Microsoft Agent . Da dieses Buch im Schwerpunkt Serveranwendungen behandelt, gibt es in Kapitel 26 hierzu nur ein kleines Beispiel. Die Dokumentation der Automatisierungskomponenten von Microsoft Office füllen mehrere dicke Bücher, die bei verschiedenen Verlagen erhältlich sind.
In den Kapiteln 4 bis 26 werden verschiedene COM-Komponenten zur Automatisierung administrativer Aufgaben in den Windows-Betriebssystemen sowie in Produkten der Microsoft BackOffice -Produktfamilie beschrieben. Der Schwerpunkt liegt dabei verständlicherweise auf den von Microsoft gelieferten Komponenten. Daneben wird eine Auswahl interessanter Komponenten anderer Anbieter vorgestellt.
Die Ausführlichkeit der Darstellung in diesem Buch richtet sich vor allem nach Bedeutung und Komplexität der Komponenten. Das Active Directory Service Interface (ADSI) zur Verzeichnisdienstverwaltung und die Windows Management Instrumentation (WMI) als übergreifender Ansatz zum Systemmanagement nehmen daher den größten Raum ein. In Wichtigkeit und Umfang folgen die Scripting Runtime Library für den Dateisystemzugriff und die ActiveX Data Objects (ADO) für den Datenbankzugriff.
Die Reihenfolge der Darstellung der Komponenten in diesem Kapitel ist dagegen eher didaktischer Natur: Mit der WSH Runtime Library und der Scripting Runtime Library stehen zwei Komponenten am Anfang, die einfach zu handhaben sind.
Gerade bei großen Komponenten kann an dieser Stelle nur ein repräsentativer Ausschnitt der Komponente besprochen werden. Besonderes Ziel ist es daher, Ihnen ein Grundverständnis jeder einzelnen Komponente zu geben, damit Sie sich anschließend selbst weiter orientieren können. Zur Veranschaulichung ist das Objektmodell in Form einer Grafik wiedergegeben. Hinweise zu der dort verwendeten Notation sowie zu den Listings finden Sie im Anhang.