Dokumentenmanagement ist in jeder Verwaltung, sei es in sozialen Einrichtungen, Kliniken oder Behörden, ein zentrales Thema. Dokumente müssen jederzeit 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 involviert, 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 Einspannen 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 richtigen 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 Dokumentenverwaltung spezialisiert hatten, Lösungen. Im Herbst 19901wurde die Entwicklung von FAME auch in unserem Hause initiiert. Der Verbund der Waldburg-Zeil-Kliniken erteilte damals den Auftrag zur Erstellung eines Arztbriefschreibungssystems, der von der Innovative Software Technologie GmbH (IST GmbH), einer Tochter der damaligen Unternehmensberatung Härle GmbH (UBH), übernommen wurde. 1992 war die Entstehung von FAME Unix abgeschlossen. Hiermit konnten schon recht komfortabel Dokumente in der eigens dafür geschriebenen Textverarbeitung erfasst werden.
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 Einrichtungen, Kliniken oder Behörden, ein zentrales Thema. Dokumente müssen jederzeit leicht aufzufinden, zu bearbeiten und abzulegen sein. Dies stellte vor dem Computerzeitalter ein beträchtliches Problem dar, da Schriftstücke nur in Papierform 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 involviert, 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 Einspannen 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 richtigen 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 Dokumentenverwaltung spezialisiert hatten, Lösungen. Im Herbst 1990[1] wurde die Entwicklung von FAME auch in unserem Hause initiiert. Der Verbund der Waldburg-Zeil-Kliniken erteilte damals den Auftrag zur Erstellung eines Arztbriefschreibungssystems, der von der Innovative Software Technologie GmbH (IST GmbH), einer Tochter der damaligen Unternehmensberatung Härle GmbH (UBH), übernommen wurde. 1992 war die Entstehung von FAME Unix abgeschlossen. Hiermit konnten schon recht komfortabel Dokumente in der eigens dafür geschriebenen Textverarbeitung erfasst werden. Durch eine Textbausteinverwaltung 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öffnet werden und es werden dann die Kapitel und Dokumente in einer Baumstruktur 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 Wesentlichen 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 wiederholende Daten nicht redundant erfasst werden, sondern die können aus Applikationen, wie z.B. der Patientenverwaltung, und Datenbanken übernommen werden. Dies wurde durch die Definition einer neutralen Zugriffsschicht, die Standardtechnologien 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 Anpassbarkeit 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 gearbeitet, 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 Verwendung von Standards wie ActiveX in jede beliebige Windows-Applikation eingegliedert 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 generiert werden können. So findet es seine Einsatzgebiete auch im öffentlichen Bereich der Verwaltung oder in sozialen Einrichtungen. Es kann in Friedhofsverwaltungen ebenso benützt werden, wie in Applikationen für Baugenehmigungsverfahren, Personalmanagement, Heizkostenabrechnung, Auftragsabwicklung, Gewerbeinformation, Arztbriefschreibung, Bewohnerdokumentation, Aktenplanverwaltung oder Bescheinigungswesen.
2 Grundlagen der Softwareentwicklung
2.1 Die 3-tier-Architektur
2.1.1 Ausgangspunkt 2-tier-Architektur
Die meisten Anwendungen, die heute in Unternehmen verwendet werden, basieren noch auf der 2-Schicht-Architektur. Hierbei wird aufgrund der fehlenden Kapselung 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 Business Logik bereits auf den Server ausgelagert. Dadurch wird zwar die Skalierbarkeit etwas erhöht, die Möglichkeiten der Wiederverwendbarkeit der programmierten 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 Datenschicht wird erst durch die 3-Ebenen-Architektur gewährleistet. So wird die Skalierbarkeit, 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 Methodenaufrufe über veröffentlichte Schnittstellen ab. Dabei werden nur Ergebnisse beziehungsweise 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 hingegen wird auf Instanzen der Business Services, die die Funktionen der Business-Schicht zur Verfügung stellen, zugegriffen, von denen nicht jede eine eigene Datenbankverbindung aufrecht erhält. Es wird lediglich eine Verbindung pro angebotenem Service erzeugt. So können wesentlich mehr User in das System aufgenommen 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 Modulen, 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 definierte Funktionalität bereitstellt. Er kann unabhängig vom Programm designed und implementiert werden, was enorme Flexibilität bedeutet. So können Anwendungen jederzeit erweitert werden, ohne den gesamten Quellcode verändern und jeden 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 verwendbar ist. Bei der Entwicklung von neuen Anwendungen muss dann lediglich der Zugriff auf bestehende Services erarbeitet werden, ohne die Features komplett 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 Anzeigemöglichkeiten. Die native, die das zugrunde liegende Betriebssystem als Hintergrund nimmt, und die web-basierte, mittels der die Daten innerhalb eines Browsers dargeboten werden. Letztere ist vom operierenden System unabhängig und erhöht somit die Benutzerfreundlichkeit des Programms. Es müssen keine speziellen Vorkehrungen getroffen werden, um mit der Anwendung arbeiten zu können, lediglich ein Standardbrowser ist vonnöten. Es sind jedoch auch andere Anzeigeformen, wie z.B. das Character UserInterface (CUI)[4] möglich, die von Systemen 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 werden Funktionen und Regeln definiert, nach denen das Programm handeln soll. Die betriebswirtschaftlichen und organisatorischen Algorithmen werden gekapselt, 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 besteht zusätzlich die Möglichkeit, dass auch andere Anwendungen auf die Funktionen dieser Module zugreifen; sie sind an keine spezielle Client-Applikation gebunden.
In der untersten Ebene, der Datenschicht, werden die Datenbankzugriffe geregelt. 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 Geschäftslogik nicht aktualisiert werden muss.
Die folgende Darstellung veranschaulicht nochmals die Abtrennung der einzelnen 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 Schnittstellen nicht verändert werden. Dies ist die Voraussetzung für die leichte Wiederverwendbarkeit des Programmcodes. Sind die Schnittstellen von Aktualisierungen betroffen, müssen alle Module, die darauf zugreifen müssen, mit abgeändert werden. Werden nur Erweiterungen durchgeführt, können die alten Programmteile 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, werden bei All for One allgemeine Technologiestandards bei der Entwicklung verwendet. Auch die Fähigkeit, FAME in jede beliebige Standardanwendung zu integrieren, wird dadurch ermöglicht. Ebenso wird die Übernahme von Daten aus anderen Programmen somit gewährleistet.
So entfallen lästige Anpassungsarbeiten bei der Integration von FAME in bestehende Systeme. Über allgemeine Schnittstellen kann von anderen Anwendungen 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 eingebettet 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 innerhalb der bereits vertrauten Umgebung verwenden.
2.2.1 Component Object Model>
COM stellt ein sprach- und betriebssystemunabhängiges Objektmodell auf Systemebene 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 darstellt. Außerdem müssen diese Komponenten durch die Entwickler mit einem eindeutigen 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 Module von jeder Anwendung verwendet werden, ohne Überschneidungen bezüglich 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. Normalerweise ist die Einrichtung einer solchen Funktionalität sehr komplex und stellt einen großen Programmieraufwand dar. Durch das Angebot eines Standardwegs über COM entfällt dies, wodurch wiederum die Wiederverwendbarkeit erleichtert wird.
Die Sprachunabhängigkeit soll es ermöglichen, dass Entwickler jede Programmiersprache verwenden können, um ihre Applikation zu erstellen. Sie können 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 Komponenten erstellt werden können, ohne dass ältere Anwendungen verändert werden 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 bestehenden 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 variiert 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 verbunden sind. Das Verhalten wird durch den Aufruf der Methoden bestimmt.
Wenn Anwendungen mit Objekten kommunizieren wollen, ist dies nur über öffentliche 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 uninteressant. Lediglich die Identität muss mit dem Zeiger verbunden werden, um Zugriff auf das BO zu erlangen.
Es wird zwischen öffentlichen und privaten Objekten unterschieden. Erstere können von außen instanziert werden. Private Objekte sind nur intern instanzierbar, können aber nach außen weitergegeben werden. Dies geschieht klassischerweise als Rückgabewert einer Methode oder einer Eigenschaft.
2.2.1.3 Schnittstellen
Eine Schnittstelle ist eine logische Zusammenfassung von Methoden. Dabei existieren öffentliche Methoden, die von außen nutzbar sind. Private Methoden hingegen können nur innerhalb des Objektes verwendet werden.
Wenn eine Komponente eine Schnittstelle verwendet, muss diese auch die zugehörige Definition haben. Darin wird genau die Syntax festgelegt, wie die Methoden 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 identifier (GUID), der aus einem String besteht, verwendet. Außerdem darf die Schnittstelle 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 erzeugen. DCOM hingegen wird als Out-Process-Server (Outproc-Server) implementiert. So können Objekte auch außerhalb des Prozessraums einer Anwendung aufgerufen werden. Sogar über Systemgrenzen hinweg sind Objektinstanzierungen 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 Stelle 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 übertragen, 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 wurden. Um ihre Eigenschaften, Methoden und Ereignisse bereitzustellen, wird Automatisierung verwendet. Mittels ActiveX können Ereignisse ausgelöst, Datenquellenverbindungen 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üssen, 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 Messaging-System von Windows® verwendet. Sie werden als spezielle Nachrichten behandelt und in einem versteckten Fenster, das von COM erzeugt wird, ausgeführt. Dazu benötigen Threads eine sogenannte „message pump“, eine Programmschleife, die Messages aus der aktuellen Warteschleife erhält, diese übersetzt und an andere Applikationen versendet. Durch dieses Synchonisationsmodell wird Thread-Sicherheit gewährleistet. Innerhalb des STA können Objekte mit anderen Objekte kommunizieren, ohne einen Systemabsturz befürchten zu müssen.
Beim MTA wird der Zugriff auf die Objekte nicht von COM synchronisiert. Hier werden Threads dynamisch zugeteilt, je nach Notwendigkeit, um parallele Aufrufe bewältigen zu können. Somit können Objekte dieses Appartements von mehreren Threads gleichzeitig verwendet werden, was zu einer Performancesteigerung führen kann, je nach Situation. Von den Entwicklern muss hier jedoch beachtet 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 Methoden 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 Graphiken darstellen kann.
[6] Kirtland, CBA
[7] vgl. Microsoft Corporation, COM, Kapitel 1, Seite 21
- Quote paper
- Martina Dippel (Author), 2001, Client/Server - versus Intranet-Applikationen: Softwareentwicklung im Spannungsfeld divergenter Paradigmen, Munich, GRIN Verlag, https://www.grin.com/document/47552
-
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X. -
Upload your own papers! Earn money and win an iPhone X.