Client/Server - versus Intranet-Applikationen: Softwareentwicklung im Spannungsfeld divergenter Paradigmen

Inhaltsverzeichnis

1 Einleitung

2 Grundlagen der Softwareentwicklung
2.1 Die 3-tier-Architektur
2.1.1 Ausgangspunkt 2-tier-Architektur
2.1.2 Weiterentwicklung 3-tier-Architektur
2.1.2.1 Die Grundstruktur des Modells
2.1.2.2 Die Aufgaben der einzelnen Schichten
2.2 Schnittstellenstandards
2.2.1 Component Object Model
2.2.1.1 Anforderungen
2.2.1.2 Objekte
2.2.1.3 Schnittstellen
2.2.2 Distributed COM
2.2.3 ActiveX
2.3 Threading

3 Erklärung der zwei Paradigmen
3.1 Die Client/Server-Architektur
3.1.1 Entwicklung
3.1.2 Vor- und Nachteile
3.1.3 Der Aufbau einer Client/Server-Architektur
3.1.4 Kommunikationsformen zwischen Client und Server
3.1.4.1 RPC
3.1.4.2 Messaging
3.1.5 Typen von Client/Server-Systemen
3.2 Die Intranet-Architektur
3.2.1 Entwicklung
3.2.2 Vor- und Nachteile
3.2.3 Der Aufbau einer Intranet-Architektur
3.2.3.1 MTS
3.2.3.2 Cobra Application Server
3.2.3.3 Web Server

4 Die Umsetzung von FAME
4.1 Die Struktur von FAME
4.1.1 Die elektronische Akte
4.1.2 Die Vorlagenverwaltung
4.1.3 Die Strukturverwaltung
4.1.4 Die Textbausteinverwaltung
4.1.5 Die Datenzusteuerung
4.2 Der programmatische Aufbau von FAME
4.2.1 Die Basismodule von FAME
4.2.2 Grundlagen für das Design
4.2.2.1 Eindeutige IDs
4.2.2.2 Zentraler Hash
4.2.3 UserInterface
4.2.3.1 UserInterfaces und deren Manager
4.2.3.2 Ein Beispiel zur Verdeutlichung
4.2.4 Business Logik
4.2.5 Datenzugriff
4.2.6 Ablauf eines Dokumentenaufrufs
4.2.7 Zwei Verwendungsmöglichkeiten von FAME
4.2.7.1 Ohne Visualisierung
4.2.7.2 Mit Visualisierung
4.3 Die Wandlung von einer Client/Server- zu einer Intranet-Anwendung
4.3.1 Der ideale UIManager
4.3.2 Kapselung der famerunlib.ocx
4.3.3 Extensible Markup Language (XML) als Standard
4.3.3.1 XML zur Parametrisierung
4.3.3.2 XML als Format zur Datenübertragung
4.3.4 Erzeugung von HTML-Templates

5 Fazit

6 Anhang
6.1 Literaturverzeichnis
6.2 XML-Dateien
6.2.1 FmPropBaseMngr.xml
6.2.2 ListView.xml
6.3 HTML-Templates
6.3.1 Tree.html
6.3.2 Cretlist.html

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Unterschied zwischen 2-tier und 3-tier Architektur

Abbildung 2: Die einzelnen Schichten der 3-tier Architektur

Abbildung 3: Ablauf eines COM-Aufrufs

Abbildung 4: Prozesse, Threads, Appartements

Abbildung 5: Funktionsweise von RPC

Abbildung 6: Aufbau der Sites in einem Messaging-Netzwerk

Abbildung 7: Dateiserver

Abbildung 8: Datenbank-Server

Abbildung 9: Transaktions-Server

Abbildung 10: Groupware-Server

Abbildung 11: Objekt-Server

Abbildung 12: Aufbau der Intranet-Serverstruktur

Abbildung 13: Die elektronische Akte

Abbildung 14: Die Vorlagenverwaltung

Abbildung 15: Die Strukturverwaltung

Abbildung 16: Die Textbausteinverwaltung

Abbildung 17: Die Datenpaketverwaltung

Abbildung 18: Vergleich zweier Eigenschaftenmasken

Abbildung 19: Die Verbindungen der Bäume

Abbildung 20: Das Baummodell allgemein

1 Einleitung

Dokumentenmanagement ist in jeder Verwaltung, sei es in sozialen Ein­richtungen, Kliniken oder Behörden, ein zentrales Thema. Dokumente müssen je­derzeit leicht aufzufinden, zu bearbeiten und abzulegen sein. Dies stellte vor dem Computerzeitalter ein beträchtliches Problem dar, da Schriftstücke nur in Papier­form vorhanden waren. Es entstanden enorme Mengen an Aktenbergen in den Büros, die nach einer gewissen Zeit archiviert werden mussten, um Platzmangel vorzubeugen. Musste dann ein Dokument eingesehen werden, das bereits im Archiv eingelagert war, so entstand ein enormer Aufwand, um an das Papier zu gelangen. Meist war dann nicht nur die Person, die den Zugriff benötigte invol­viert, sondern auch zusätzliche, wie Archivare usw.. Durch diese Schilderungen fällt bereits auf, dass diese Art des Dokumentenmanagements relativ teuer und umständlich war.

Außerdem stellten Formulare ein Problem dar, da diese von Druckereien erstellt und anschließend in mühsamer Handarbeit ausgefüllt werden mussten. Das Ein­spannen in die Schreibmaschine offenbarte sich als die erste Herausforderung, die es zu überwinden galt. Die verschiedenen Ausfertigungen mussten genau hintereinander platziert werden, um alle Kreuzchen und Anschriften an der rich­tigen Stelle zu haben. Formulare konnten nicht so einfach geschrieben werden, wie Briefe oder ähnliches. Man musste für jedes Feld die Schreibmaschine neu positionieren, ein „x“ setzen, um dann die Position des Wagens für das nächste Feld neu zu bestimmen. Und bei einem Schreibfehler musste der ganze Aufwand wieder von vorn betrieben werden.

Es gab bereits von anderen Anbietern, die sich auf diese Probleme der Doku­mentenverwaltung spezialisiert hatten, Lösungen. Im Herbst 1990^[1] wurde die Entwicklung von FAME auch in unserem Hause initiiert. Der Verbund der Wald­burg-Zeil-Kliniken erteilte damals den Auftrag zur Erstellung eines Arztbriefschrei­bungssystems, der von der Innovative Software Technologie GmbH (IST GmbH), einer Tochter der damaligen Unternehmensberatung Härle GmbH (UBH), über­nommen wurde. 1992 war die Entstehung von FAME Unix abgeschlossen. Hier­mit konnten schon recht komfortabel Dokumente in der eigens dafür ge­schriebenen Textverarbeitung erfasst werden. Durch eine Textbausteinverwal­tung konnten Textkonserven definiert werden, die dann bei der Erstellung eines Dokuments automatisch eingefügt wurden und so die Arbeit erleichterten. Diese Dokumente wurden dann in Mappen abgelegt, um leicht wieder auffindbar zu sein. Unter Mappen werden hier Patientenakten verstanden, die in elektronischer Form verwaltet werden. Auch Formulare, die zuvor von Originalen nachgebildet und in das System eingespeist wurden, konnten bereits am Bildschirm ausgefüllt werden. Diese wurden dann auf normalem Papier ausgedruckt, wodurch das lästige Einspannen und Justieren sowie die Bevorratung von Formularen entfiel.

Mit dem Aufkommen der graphischen Benutzeroberfläche entstand dann auch der Druck, FAME eine solche zu verpassen. So entstand zwischen 1994 und ’95 die erste Windows-Version FAME 1.0, die in Delphi 1.0 programmiert wurde. Es beinhaltet schon alle Vorzüge von Windows95®. Mappen können separat geöff­net werden und es werden dann die Kapitel und Dokumente in einer Baumstruk­tur angezeigt. Die Dokumentenerstellung wird durch die Integration von Microsoft Office® - Produkten erheblich komfortabler.

Bereits kurze Zeit später, 1997, wurde FAME 1.5 auf den Markt gebracht. Im We­sentlichen entspricht es der Vorgängerversion, lediglich die Oberfläche wurde mehr Windows95® angepasst. Außerdem erleichtert die Integration von Daten aus anderen Anwendungen die tägliche Arbeit ungemein. So müssen sich wie­derholende Daten nicht redundant erfasst werden, sondern die können aus Appli­kationen, wie z.B. der Patientenverwaltung, und Datenbanken übernommen wer­den. Dies wurde durch die Definition einer neutralen Zugriffsschicht, die Stan­dardtechnologien wie ActiveX, Distributed Component Object Model (DCOM) oder Open Database Connectivity (ODBC) sowie native Datenbanktreiber nützt, ermöglicht. Diese heterogene Zugriffsmöglichkeit erlaubt eine optimale Anpass­barkeit an die informationstechnische Infrastruktur des Kunden.

Erst im August 1999 erschien die aktuelle Version FAME 3.0, die seit 1997 mit Delphi 1.0 bis 4.0 programmiert wurde. Sie unterscheidet sich nicht nur in der Oberfläche, sondern auch technisch von FAME 1.5, was auch durch die Release-Nummerierung ausgedrückt werden sollte. Es wurde sehr objektorientiert gear­beitet, weshalb von außen auf Objekte in FAME zugegriffen werden kann. So können Dokumente oder Mappen geöffnet werden, ohne FAME visuell starten zu müssen. Ein weiterer großer Vorteil von FAME ist, dass es durch die Verwen­dung von Standards wie ActiveX in jede beliebige Windows-Applikation eingeglie­dert werden kann.

Heute wird FAME nicht mehr nur im ärztlichen Bereich verwendet. Es hat sich zu einer neutralen Anwendung entwickelt, mit der Dokumente verwaltet und gene­riert werden können. So findet es seine Einsatzgebiete auch im öffentlichen Be­reich der Verwaltung oder in sozialen Einrichtungen. Es kann in Friedhofsverwal­tungen ebenso benützt werden, wie in Applikationen für Baugenehmigungsver­fahren, Personalmanagement, Heizkostenabrechnung, Auftragsabwicklung, Ge­werbeinformation, Arztbriefschreibung, Bewohnerdokumentation, Aktenplanver­waltung oder Bescheinigungswesen.

2 Grundlagen der Softwareentwick­lung

2.1 Die 3-tier-Architektur

2.1.1 Ausgangspunkt 2-tier-Architektur

Die meisten Anwendungen, die heute in Unternehmen verwendet werden, basie­ren noch auf der 2-Schicht-Architektur. Hierbei wird aufgrund der fehlenden Kap­selung der Geschäftslogik-Schicht auf dem Client die Geschäftslogik sowie die Präsentation durchgeführt. Die Daten werden zentral auf dem Server gehalten und jede Verbindung wird direkt vom Client auf den Server durchgeführt. Damit entstehen die Nachteile der begrenzten Skalierbarkeit die noch im Kapitel 3.1.2 näher behandelt werden sollen.

Als erste Weiterentwicklung entstand eine Zwischenlösung, die oft 2,5-Schicht-Architektur genannt wird. Hierbei wird ein Teil der Datenberechnung oder Busi­ness Logik bereits auf den Server ausgelagert. Dadurch wird zwar die Skalierbar­keit etwas erhöht, die Möglichkeiten der Wiederverwendbarkeit der programmier­ten Anwendungsteile sind jedoch immer noch stark eingeschränkt, da immer noch Teile des Programmcodes fix an den Bildschirmmasken hinterlegt wurden.

2.1.2 Weiterentwicklung 3-tier-Architektur

Eine exakte logische Trennung von Präsentations-, Geschäftslogik- und Daten­schicht wird erst durch die 3-Ebenen-Architektur gewährleistet. So wird die Ska­lierbarkeit, wie auch die Flexibilität und Wiederverwendbarkeit enorm gesteigert. Keine Schicht hat genauere Kenntnis vom Aufbau oder der Implementierung der anderen Ebenen. Die Kommunikation läuft lediglich mittels einzelner Methoden­aufrufe über veröffentlichte Schnittstellen ab. Dabei werden nur Ergebnisse be­ziehungsweise die Parameter übermittelt. Die Berechnungen oder Datenzugriffe finden in der angeforderten Schicht selbst statt, ohne dass die anderen Ebenen davon berührt werden.

Die folgende Abbildung verdeutlicht den Unterschied zwischen der 2- und der 3-Ebenen-Architektur. Es ist ersichtlich, dass bei der ehemaligen Bauweise von Client/Server-Systemen die Clients direkt auf den Server zugreifen und dass das Verhältnis von Clients und Datenbankverbindungen deshalb 1:1 ist. Auf jedem Client läuft hierbei eine Instanz der Applikation. Bei der 3-tier Architektur hinge­gen wird auf Instanzen der Business Services, die die Funktionen der Business-Schicht zur Verfügung stellen, zugegriffen, von denen nicht jede eine eigene Da­tenbankverbindung aufrecht erhält. Es wird lediglich eine Verbindung pro ange­botenem Service erzeugt. So können wesentlich mehr User in das System aufge­nommen werden, da die maximale Anzahl an möglichen Sitzungen nicht so schnell erreicht wird, weil die Datenzugriffe serialisiert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Unterschied zwischen 2-tier und 3-tier Architektur^[2]

2.1.2.1 Die Grundstruktur des Modells

Diese Bauweise umfasst über Schnittstellen gekapselte Modelle. „3 Ebenen“ muss aber nicht mit „3 Maschinen“ gleichgesetzt werden. In den meisten Fällen sind nur 2 Rechner vonnöten. Ein Client auf dem die Präsentationsschicht und ein Server, auf dem die Business- und die Datenschicht liegen. Die einzelnen Schichten können jederzeit, durch die Kapselung der Features in einzelnen Mo­dulen, auf beliebig viele Computer verteilt werden.

Anwendungen, die auf diesem Prinzip basieren, können als logische Netzwerke betrachtet werden, die aus Anbietern und Nutzern von Services bestehen. Ein Service stellt dabei einen Teil der Anwendungslogik dar, der eine genau definier­te Funktionalität bereitstellt. Er kann unabhängig vom Programm designed und implementiert werden, was enorme Flexibilität bedeutet. So können Anwendun­gen jederzeit erweitert werden, ohne den gesamten Quellcode verändern und je­den Client, der von diesen Funktionen abhängt, updaten zu müssen.

Wiederverwendbarkeit wird erreicht, indem Entwickler öffentliche Schnittstellen^[3] definieren, mittels denen auf die Module zugegriffen werden kann. So wird ein Rahmen von Services geschaffen, der in unterschiedlichen Kombinationen ver­wendbar ist. Bei der Entwicklung von neuen Anwendungen muss dann lediglich der Zugriff auf bestehende Services erarbeitet werden, ohne die Features kom­plett neu programmieren zu müssen.

2.1.2.2 Die Aufgaben der einzelnen Schichten

Mittels der Präsentationsschicht werden dem Benutzer die gewünschten Daten angezeigt und die Möglichkeit gegeben, diese zu editieren. Es gibt zwei Anzeige­möglichkeiten. Die native, die das zugrunde liegende Betriebssystem als Hinter­grund nimmt, und die web-basierte, mittels der die Daten innerhalb eines Brow­sers dargeboten werden. Letztere ist vom operierenden System unabhängig und erhöht somit die Benutzerfreundlichkeit des Programms. Es müssen keine spe­ziellen Vorkehrungen getroffen werden, um mit der Anwendung arbeiten zu kön­nen, lediglich ein Standardbrowser ist vonnöten. Es sind jedoch auch andere An­zeigeformen, wie z.B. das Character UserInterface (CUI)^[4] möglich, die von Syste­men wie Unix oder Hostrechnern verwendet werden. Ein Browser kann hierbei ein CUI oder ein Graphical UserInterface (GUI)^[5] darstellen.

Auf der Ebene der Business Logik werden Berechnungen durchgeführt. Hier wer­den Funktionen und Regeln definiert, nach denen das Programm handeln soll. Die betriebswirtschaftlichen und organisatorischen Algorithmen werden gekap­selt, woraus auch der Name Business Object (BO) resultiert. Außerdem werden Services bereitgestellt, die vom Präsentationslayer verwendet werden. Um die Wiederverwendbarkeit zu erhöhen, werden diese in separaten Modulen zentral abgelegt. So muss bei einer Änderung nur die betroffene Stelle geändert werden, ohne das ganze Programm überarbeiten zu müssen. Durch diese Kapselung be­steht zusätzlich die Möglichkeit, dass auch andere Anwendungen auf die Funktio­nen dieser Module zugreifen; sie sind an keine spezielle Client-Applikation ge­bunden.

In der untersten Ebene, der Datenschicht, werden die Datenbankzugriffe gere­gelt. Hier ist das Wissen über die Daten Persistenz, d.h. den Speicherungsort von Daten, abgelegt. Mittels Datenregeln wird sichergestellt, dass die gesicherten Angaben auch konsistent bleiben. So kann z.B. abgeprüft werden, ob ein Feld leer ist oder ob es zu einem Datensatz ein weiterer in einer anderen Datenbank besteht. Die Kapselung bewirkt, dass bei Änderungen der Persistenz die Ge­schäftslogik nicht aktualisiert werden muss.

Die folgende Darstellung veranschaulicht nochmals die Abtrennung der einzel­nen Schichten voneinander. Außerdem wird ersichtlich, dass die zur Verfügung gestellten Services anwendungsübergreifend genutzt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Die einzelnen Schichten der 3-tier Architektur

Bei allen Modifikationen muss lediglich darauf geachtet werden, dass die Schnitt­stellen nicht verändert werden. Dies ist die Voraussetzung für die leichte Wieder­verwendbarkeit des Programmcodes. Sind die Schnittstellen von Aktualisierun­gen betroffen, müssen alle Module, die darauf zugreifen müssen, mit abgeändert werden. Werden nur Erweiterungen durchgeführt, können die alten Programmtei­le in ihrem Ursprungszustand belassen werden. Allerdings stehen diesen dann die Erweiterungen nicht zur Verfügung.

2.2 Schnittstellenstandards

Um zu garantieren, dass FAME auf allen gängigen Systemen lauffähig ist, wer­den bei All for One allgemeine Technologiestandards bei der Entwicklung ver­wendet. Auch die Fähigkeit, FAME in jede beliebige Standardanwendung zu inte­grieren, wird dadurch ermöglicht. Ebenso wird die Übernahme von Daten aus an­deren Programmen somit gewährleistet.

So entfallen lästige Anpassungsarbeiten bei der Integration von FAME in be­stehende Systeme. Über allgemeine Schnittstellen kann von anderen Anwen­dungen oder Skripten auf alle Business Objekte von FAME zugegriffen werden. Außerdem muss so nicht die Oberfläche von FAME verwendet werden. Durch die direkte Integration in andere Systeme, anstelle der Nutzung mehrerer losgelöster Programme, können Systembrüche vermieden werden. Diese entstehen, wenn der organisatorische Prozess und die zugehörige Software nicht übereinstimmen. Die zur Verfügung gestellten Formulare können in jede beliebige Anwendung ein­gebettet werden, was mehr Komfort für die Benutzer bedeutet. Sie müssen sich damit nicht an eine neue Applikation gewöhnen, sondern können FAME inner­halb der bereits vertrauten Umgebung verwenden.

2.2.1 Component Object Model>

COM stellt ein sprach- und betriebssystemunabhängiges Objektmodell auf Sys­temebene dar. Die größte Verbreitung findet es in Microsoft®-Systemen, es kann aber auch z.B. in Unix implementiert werden. COM bietet einen Standardweg an, über den Komponenten und Anwendungen miteinander kommunizieren können.^[6]

2.2.1.1 Anforderungen

Zunächst muss ein Weg verfügbar sein, über den es möglich ist, Komponenten ortstransparent zu instanzieren. Objekte, die diese Module nutzen, müssen leicht erstellbar sein, da der übliche Einarbeitungsaufwand in die Komponentennutzung eine große Barriere für die Wiederverwendung von bereits existentem Code dar­stellt. Außerdem müssen diese Komponenten durch die Entwickler mit einem ein­deutigen Stempel versehen werden können, um sie einwandfrei identifizieren zu können. So wird vermieden, dass eine zentrale Instanz eingerichtet werden muss, die diese Aufgabe übernimmt. Mit Hilfe dieses Kennzeichens können Mo­dule von jeder Anwendung verwendet werden, ohne Überschneidungen bezüg­lich des Namens o.ä. befürchten zu müssen.

Die zweite Herausforderung, die es zu überwinden gilt, ist die Interaktion zwischen den BOs. Es muss möglich sein, dass Objekte miteinander operieren, ohne Wissen davon zu haben, wo ihr Kommunikationspartner sich befindet. Nor­malerweise ist die Einrichtung einer solchen Funktionalität sehr komplex und stellt einen großen Programmieraufwand dar. Durch das Angebot eines Stan­dardwegs über COM entfällt dies, wodurch wiederum die Wiederverwendbarkeit erleichtert wird.

Die Sprachunabhängigkeit soll es ermöglichen, dass Entwickler jede Pro­grammiersprache verwenden können, um ihre Applikation zu erstellen. Sie kön­nen COM-Komponenten erstellen, die dann 1 oder mehrere Schnittstellen zu ihren Modulen anbieten. Jede dieser Schnittstellen enthält eine gewisse Anzahl von Methoden und Eigenschaften, auf die von außen zugegriffen werden kann.

Zuletzt muss die Möglichkeit bestehen, dass neuere Versionen von Kom­ponenten erstellt werden können, ohne dass ältere Anwendungen verändert wer­den müssen. Die Aktualisierung kann bestehende Probleme in den existierenden Modulen, sowie neue Funktionalität betreffen. Das Hinzufügen neuer Features stellt dabei kein großes Problem dar. Diese stehen dann lediglich den bestehen­den Anwendungen nicht zur Verfügung, wenn diese nicht geändert werden. Bei der Behebung von Fehlern muss darauf geachtet werden, dass die Methoden- und Eigenschaftsnamen, die über die Schnittstelle bereitgestellt werden, nicht va­riiert werden. Ansonsten erhalten bereits existierende Applikationen Fehler, wenn sie versuchen, einen alten Methodennamen aufzurufen. Es existieren mündliche Verträge, die es verbieten, Schnittstellen inkompatibel zu ändern. Technisch wird dies jedoch nicht kontrolliert.

2.2.1.2 Objekte

Objekte sind Instanzen von Klassen, die zur Laufzeit erzeugt werden. Dabei besitzt jedes eine Identität (ID), einen Status und ein Verhalten. Die ID bestimmt das BO eindeutig, so dass bei einem Aufruf sichergestellt ist, dass das richtige verwendet wird. Der Status sind die Daten, die mit einem speziellen Objekt ver­bunden sind. Das Verhalten wird durch den Aufruf der Methoden bestimmt.

Wenn Anwendungen mit Objekten kommunizieren wollen, ist dies nur über öf­fentliche Schnittstellen möglich. Dabei müssen sogenannte Schnittstellenzeiger verwendet werden. In COM ist genau definiert, wie diese Verständigung abläuft. Da ausschließlich Schnittstellenzeiger verwendet werden, ist der Status uninte­ressant. Lediglich die Identität muss mit dem Zeiger verbunden werden, um Zu­griff auf das BO zu erlangen.

Es wird zwischen öffentlichen und privaten Objekten unterschieden. Erstere kön­nen von außen instanziert werden. Private Objekte sind nur intern instanzierbar, können aber nach außen weitergegeben werden. Dies geschieht klassischerwei­se als Rückgabewert einer Methode oder einer Eigenschaft.

2.2.1.3 Schnittstellen

Eine Schnittstelle ist eine logische Zusammenfassung von Methoden. Dabei exis­tieren öffentliche Methoden, die von außen nutzbar sind. Private Methoden hin­gegen können nur innerhalb des Objektes verwendet werden.

Wenn eine Komponente eine Schnittstelle verwendet, muss diese auch die zu­gehörige Definition haben. Darin wird genau die Syntax festgelegt, wie die Me­thoden aufgerufen werden. Auch die Semantik wird festgehalten.

Dabei müssen folgende 3 Anforderungen von jeder Schnittstelle erfüllt werden. Sie muss eindeutig identifizierbar und von der allgemeinen Schnittstelle IUnknown abgeleitet sein. Zur Identifikation wird dabei ein Globally unique identi­fier (GUID), der aus einem String besteht, verwendet. Außerdem darf die Schnitt­stelle nicht mehr verändert werden, sobald sie veröffentlicht wurde.

2.2.2 Distributed COM

DCOM bildet die Erweiterung des COM-Modells. Hiermit kann auf Komponenten maschinentransparent zugegriffen werden. Es erweitert den Ausführungsbereich von Objektinstanzen auf das Netzwerk.

COM ist fixiert auf sogenannte In-Process-Server (Inproc-Server), das heißt, die Objekte laufen im Prozessraum einer Anwendung. Das bedeutet, dass hier die Threads des Client-Prozesses verwendet werden, anstatt eigene Threads zu er­zeugen. DCOM hingegen wird als Out-Process-Server (Outproc-Server) imple­mentiert. So können Objekte auch außerhalb des Prozessraums einer Anwen­dung aufgerufen werden. Sogar über Systemgrenzen hinweg sind Objektinstan­zierungen möglich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Ablauf eines COM-Aufrufs^[7]

Aus dem obigen Bild wird deutlich, dass COM-Aufrufe immer über RPC ablaufen. Dabei spielt es keine Rolle, wo der Rumpf des COM-Prozesses sich befindet. Lediglich beim Aufruf von der Client-Seite her, muss überprüft werden, ob es sich um einen lokalen oder einen Remote-Prozess handelt. Dementsprechend wird der richtige Proxy angesprochen, um den Zugriff zu autorisieren. Von dieser Stel­le aus, läuft die Prozedur gleich ab, ob der Prozess nun lokal liegt oder auf einer anderen Maschine. Die Anfrage wird mittels RPC an den COM-Rumpf übertra­gen, der dann das entsprechende Objekt aufruft, welches die erbetene Funktion ausführt.

2.2.3 ActiveX

ActiveX steht für „active extensions“ und wurde 1996 von Microsoft im Zuge der Vorstellung ihrer Internet-Technologien eingeführt. Diese Controls stellen eine spezielle Technologie dar, die auf COM für programmatische Controls aufgebaut wurde, um Komponenten in einem Netzwerk miteinander kommunizieren lassen zu können, ohne beachten zu müssen, in welcher Sprache sie geschrieben wur­den. Um ihre Eigenschaften, Methoden und Ereignisse bereitzustellen, wird Auto­matisierung verwendet. Mittels ActiveX können Ereignisse ausgelöst, Datenquel­lenverbindungen hergestellt und Lizenzierung unterstützt werden.

2.3 Threading

Ein Thread ist die Umgebung, in der Programmcode ausgeführt wird. Eine CPU kann immer nur einen Thread zur selben Zeit behandeln. Ein Prozess besteht aus einem oder mehreren Threads, wobei dann der erste der Hauptthread ist. Ist das letztere der Fall, wird von Multithreading gesprochen. So können sich viele Anwendungen die Prozessorleistung eines Rechners teilen, ohne warten zu müs­sen, bis die vorherige Applikation sich beendet hat. Dieses Multithreading-Modell wird von Windows® verwendet. Die Threadanzahl ist durch die Gesamtleistung des Rechners begrenzt.

Es gibt einige unterschiedliche Modelle, wie Threads verwendet werden können. Diese erklären, in welchen Threads die Objekte einer Komponente laufen können und wie der Zugriff darauf synchronisiert wird. Alle Threading-Modelle, die von COM unterstützt werden, basieren auf der Idee der Appartements. Dies ist die Ausführungsumgebung für BOs, die sich während ihrer gesamten Lebensdauer innerhalb eines Appartements befinden.

Alle Aufrufe, die an ein Objekt gerichtet werden, werden darin abgewickelt. Wird die Anwendung, die die Anfrage gestartet hat, in einem anderen Appartement ausgeführt, so wird der Zugriff auf das Appartement des angeforderten BOs von COM synchronisiert. Außerdem ist das sogenannte „Marshaling“ vonnöten. Dazu werden alle Anfragen von COM abgefangen, in ein Standardformat verpackt und als Methodenaufruf ins Appartement des Objekts gegeben. Derartige Prozeduren wirken sich wesentlich auf die Performance der Anwendung aus, da hier bereits zwei Threads durch eine Aktion in Anspruch genommen werden.

Es gibt zwei unterschiedliche Appartement-Typen: single-threaded (STA) und multi-threaded apartment (MTA). Im ersten Fall ist ein Appartement mit einem Thread für dessen ganze Lebensdauer verbunden. Ein Prozess kann dabei einige STAs haben, wobei das erste dann das Haupt-STA ist. Diese Art des Threading wird auch als Appartement-Modell bezeichnet. Wird ein Prozess mit mehreren Threads verbunden, spricht man vom MTA, das zugehörige Threading-Modell nennt sich „free-threaded model“.

Durch die Eigenschaften des STA wird garantiert, dass auf dessen Objekte nie gleichzeitig zugegriffen wird und diese immer im selben Thread laufen. Es wird immer nur ein Aufruf zugleich abgearbeitet, gleichgültig wie viele Objekte sich im Appartement befinden. Um die Anfragen zu synchronisieren, wird das Messa­ging-System von Windows® verwendet. Sie werden als spezielle Nachrichten be­handelt und in einem versteckten Fenster, das von COM erzeugt wird, ausge­führt. Dazu benötigen Threads eine sogenannte „message pump“, eine Pro­grammschleife, die Messages aus der aktuellen Warteschleife erhält, diese über­setzt und an andere Applikationen versendet. Durch dieses Synchonisationsmo­dell wird Thread-Sicherheit gewährleistet. Innerhalb des STA können Objekte mit anderen Objekte kommunizieren, ohne einen Systemabsturz befürchten zu müs­sen.

Beim MTA wird der Zugriff auf die Objekte nicht von COM synchronisiert. Hier werden Threads dynamisch zugeteilt, je nach Notwendigkeit, um parallele Auf­rufe bewältigen zu können. Somit können Objekte dieses Appartements von mehreren Threads gleichzeitig verwendet werden, was zu einer Performancestei­gerung führen kann, je nach Situation. Von den Entwicklern muss hier jedoch be­achtet werden, die globale Variablen zu schützen, da auf diese nun von vielen Anwendungen zugegriffen werden kann. Bei einer Änderung einer solchen muss sichergestellt sein, dass die Daten, die eine andere Applikation in diese Variable geschrieben hat, nicht verloren gehen.

Um zu gewährleisten, dass das Appartement der aufrufenden Anwendung mit dem Threading-Modell des angeforderten Objekts übereinstimmt, muss vom Komponenten-Entwickler der gewählte Typ spezifiziert werden. Dazu wird ein Wert der Registry verwendet, der auf den Inproc32-Schlüssel gesetzt wird. COM holt sich diesen Wert und bestimmt daraus das entsprechende Appartement, in dem das BO erzeugt werden muss.

[...]

---

^[1] Buschbacher, Druckformaterstellung, S. 1

^[2] Kirtland, CBA, S. 7

^[3] Unter öffentlichen Schnittstellen werden Festlegungen verstanden, in denen die Metho­den und Attribute festgeschrieben sind, auf die von außen zugegriffen werden darf.

^[4] Ein CUI kann nur ASCII-Zeichen darstellen. Anzeige von Bildern ist nicht möglich.

^[5] Ein GUI ist eine graphische Benutzeroberfläche, die alle Arten von Zeichen und Graphi­ken darstellen kann.

^[6] Kirtland, CBA

^[7] vgl. Microsoft Corporation, COM, Kapitel 1, Seite 21