Session D-COM

COM, DCOM, OLE-Automation und MTS

Peter Herzog
ProLib Software GmbH


Active X, OLE, COM, Remote Automation, DCOM, MTS Fernsteuern und Ferngesteuert werden

Am Anfang war ...

Es ist uns seit den Anfängen der EDV bekannt, daß nicht jede Programmiersprache alles bieten kann, was man sich gerne wünschen würde.

Auch darf sich niemand als das absolute Genie bezeichnen um alle Probleme der EDV alleine und das womöglich in C++ oder Assembler zu lösen.

Also lehnen wir uns gerne zurück und lassen andere die Arbeit machen. Sei es nun im Bereich des Dateizugriffes, wo wir uns der Techniken von Rushmore bedienen, oder z.B.: im Bereich der Textverarbeitung, wo sich für uns Microsoft Word anbietet.

Der Betrieb von externen Programmen ist auf einem PC solange kein Problem, solange nicht Daten des einen Programmes in die Verarbeitung des anderen einfließen müssen. Auf den Systemen der Mittleren Datentechnik (MDT) oder auch in der Groß EDV konnten und können diese Wünsche meist nur durch Zwischendateien gelöst werden. Wer von uns hat noch nicht via Textdatei Adressdaten oder Ähnliches transportiert.

Dies bedingt jedoch auf beiden Seiten programmatische Import- und Exportfunktionen, die unter Umständen erst Programmiert werden müssen und daher Geld und Zeit kosten.

OBJectdateien

Schon in früher Zeit hat man sich daher entschlossen nicht ganze Programme zur Verfügung zu stellen, sondern nur Programmteile, die in Form von Object – Dateien (.OBJ) mit dem Linker zum eigentlichen Programm angehängt wurden. Ein xBase – Produkt namens CLIPPER hat davon sehr regen Gebrauch gemacht und wurde erst auf diesem Wege fähig verschiedenste Aufgaben zu bewältigen. Clipper alleine ohne die sogenannten Nantucket Tools war ein nacktes Etwas, womit man nur mit Mühe etwas „zaubern“ konnte.

Die gleiche Problematik ergab sich aber auch für mich selbst, als ich noch COBOL programmieren „durfte“ und damals auf etwas „intelligenteres“ als die eingebaute Dateiverwaltung zugreifen wollte.

Damals war BTRIEVE meine Wahl und ich konnte damals das BTRV.OBJ direkt meinem Cobol Programm hinzulinken und hatte somit die Funktionalität einer satzorientierten Dateiverwaltung mit Indexzugriff zur Verfügung.

Ich war damals (Oje ist das lange her <g>) zwar noch weit von COM und DCOM entfernt, jedoch war das Prinzip ähnlich, nämlich das Verwenden anderer Programme, bzw. Programmteile.

DLL, FLL, PLB

Die Funktionalität wurde später auch in FoxPro eingebettet, nur daß keine Objektdatei gelinked wurde, sondern sogenannte Laufzeit Linklibraries verwendet wurden. Im Falle von FoxPro DOS waren dies die sogenannten PLB Dateien. Damals wurden diese Libraries mit dem Watcom – C Compile geschrieben.

Seit der Windows Version von FoxPro haben wir die sogenannten FLL – Dateien, die man FoxPro Link Libraries nennt.

Bereits Windows hat uns gezeigt, wie dies einfach und leicht funktioniert, indem dort die sogenannten DLL´s (Dynamic Link Libraries) verwendet werden.

Seit der Visual FoxPro Version 3.0 können wir auf DLL´s direkt zugreifen, ohne die berühmte FOXTOOLS.FLL zu benutzen.

Trotz der nun bereits extrem vereinfachten Zugriffsmöglichkeit fremde Programmteile zu verwenden, ist dies immer noch nicht mit COM (Common Object Model) zu vergleichen.

Wir sprachen bisher von Programmteilen, die ohne das aufrufende Programm nicht leben konnten. Vergleichbar mit einem Virus braucht eine DLL, FLL oder ein OBJ immer einen Wirt, der das Modul mit Strom versorgt.

DDE

Die erste echte Neuerung beim Zugriff auf fremde Programme ist DDE (Dynamic Data Exchange)

Mit DDE konnte man zu einem ebenfalls DDE fähigem Programm einen Kanal öffnen und ihm darüber Befehle mitteilen.

Dies war eine hervorragende Technik um mit dem fremden Programm kommunizieren zu können. Jedoch war es leider langsam und teilweise kompliziert. Auch hat sich das fremde Programm nicht immer „ordentlich“ verhalten, was viele von Ihnen unter dem Begriff „Twainschnittstellenproblem“ heute noch kennen. (Viele Twainschnittstellen für verschiedenste, auch moderne Scanner, müssen per DDE angesprochen werden, da meistens die Treiber der 32 Bit Welt nicht ordentlich funktionieren)

Von der Technik her ist zu bemerken, daß beide Programme parallel ab laufen waren und nur der Kanal in der Mitte die Nabelschnur darstellte.

Dies war Microsoft auch nicht genug, da es immer noch zwei „sichtbar“ parallel laufende Applikationen gab. Also ein Betrieb wie bei der DLL oder einem OBJ – File nicht möglich war wo der zweite Programmteil quasi unsichtbar zur Verfügung stand.

OLE 1.0

Als nächster Schritt wurde OLE (Object linking and / or embedding) erfunden.

Hier wurde ein Weg eingeschlagen, den wir heute noch auf unseren Systemen vorfinden und der uns seither teils sichtbar, teils unsichtbar begleitet.

Auch wurde die Zugriffslogik entscheidend geändert. Nicht mehr die Funktionalität liegt im Vordergrund, sondern die Daten, mit denen etwas passieren soll.

OLE macht regen Gebrauch von den sogenannten Fileextensions. In der Windows Registry ist nun eingetragen, welche Extension nun für welches Programm zuständig ist. DOC – Dateien sind eindeutig WinWord zugeordnet und sobald wir nun eine Datei mit dieser Extension aktivieren (öffnen) wird zuerst einmal in der Registry nachgesehen, welches Programm dafür zuständig ist und dieses wird dann auch geöffnet.

Sie können dies auch unter FoxPro verwenden, indem Sie in einer Tabelle ein sogenanntes General – Feld anlegen. In ein solches Feld kann nun einerseits eine DOC – Datei eingebunden werden (Die gesamte Datei wird in das General – Feld kopiert , embedding ) oder nur hinzugelinked werden (Der Pfad zur Datei wird gespeichert, linking)

OLE 2.0

Der Unterschied zu OLE 1.0 und OLE 2.0 zeigte sich beim Aufruf durch den Doppelklick auf die eingebundene Datei. Unter OLE 1.0 öffnete sich das gesamte Programm und die Datei konnte bearbeitet werden. Unter OLE 2.0 wurde nur der Kernel des Hostprogrammes gestartet und direkt in Visual FoxPro konnte man quasi durch ein Fenster auf das Hostprogramm schauen, in dem die Datei nun bearbeitet werden konnte.

Trotz dieser gewaltigen Technik war es immer noch kein echtes „Fernsteuern“ wie wir es uns wünschen würden.

OLE Automation

Daher legte Microsoft noch eins drauf und erfand die sogenannte OLE – Automation.

Erst durch diesen Begriff und diese Technik hatten wir wieder den Stand erreicht, den wir mit DLL, FLL und OBJ bereits seit Jahren gewohnt waren.

Und genau diese Zugriffsart bzw. der Weg begleitet uns seitdem durch alle Produkte Microsofts.

Wieder einmal ausschlaggebend ist die Registry, in der ein OLE – Automationsfähiges Programm eingetragen sein muß. Nehmen wir uns als Beispiel Winword 97 heraus. Dieses Programm finden Sie in der Registry unter dem Eintrag

HKEY_CLASSES_ROOT\Word.Application.8

Dort wiederum gibt es einen Eintrag einer CLSID (Class ID, ein weltweit eindeutiger Schlüssel) mit dem nichtssagenden Wert

{000209FF-0000-0000-C000-000000000046}

Der wiederum hat einen eigenen Eintrag den Sie unter

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID

finden.

Darunter wiederum finden Sie unter LocalServer32 den Eintrag auf die WinWord.EXE mit dem Parameter /Automation, was soviel bedeutet, daß mit Aufruf von word.application.8 nicht das komplette WinWord gestartet werden soll, sondern nur der Teil, der die pure Funktionalität beinhaltet. Unterm Strich sind dies jedoch ca. 80% vom gesamten WinWord, da sich nur in den restlichen 20% die grafische Ausgabe befindet.

Versuchen Sie einfach folgende Befehlszeilen unter Visual FoxPro , vorausgesetzt Sie haben WinWord 97 ordentlich installiert.

oWord = createobject(„word.application.8“)

oWord.Documents.Add()

oWord.Selection.TypeText(„Wow, es funktioniert“)

Sie sehen, es gleicht einer Erweiterung des Sprachumfanges von Visual FoxPro.

Ähnlich sieht es auch bei Excel, Powerpoint, Visual Basic – Programmen und natürlich auch bei Visual FoxPro selbst aus.

Visual FoxPro fernzusteuern sieht für uns VFP – Programmierer zwar etwas seltsam aus, macht jedoch aus der Sicht eines VBA – Programmierers durchaus Sinn.

Versuchen Sie es einfach einmal selbst aus.

oVFP = createobject("visualfoxpro.application")

oVFP.docmd(“? Chr(7)“)

Sie werden einen kleinen „Ping“ hören. Nichts besonderes werden Sie sagen. Für einen WinWord – VBA Programmierer durchaus. <g>

Das Beispiel

Aber kommen wir einmal zu einer brauchbaren Demonstration der gesamten Geschichte. Es bringt nicht sonderlich viel, wenn Visual FoxPro aufgerufen wird und nur eine einzelne Befehlszeile ausgeführt werden kann. Wir wollen mit VFP ja programmieren und nicht wie in den Zeiten des Commandwindows nur einzelne Befehle ausführen.

Also machen wir uns die Fähigkeiten von VFP einmal zu nutze und bauen uns eine simple Auswahlmaske mit der wir einen Kundenstammsatz auswählen und ihn im WinWord anzeigen lassen.

Die Ansteuerung soll jedoch nicht von VFP aus erfolgen, sondern diesmal wollen wir WinWord nicht verlassen, sondern auf Knopfdruck eine Visual FoxPro Maske erscheinen lassen, welche uns die bereits bekannte Customer - Datei anzeigt und uns einen Datensatz auswählen läßt.

Der VFP – COM – Server

Als erstes benötigen wir also ein VFP – Programm welches uns die Datei Customer in einem Grid anzeigt und mit einem OK - Button die Form wieder schließen läßt.

Das ganze packen wir in ein Projekt und fügen noch ein Startprogramm hinzu.

Beginnen wir mit dem Projekt. Den Namen wollen wir sorgfältig wählen, da dieser Name später als Objektname in der Registry abgespeichert wird.

Ich verwende den Namen VFPWORD.

Nun erzeugen wir ein Startprogramm ebenfalls mit dem Namen VFPWORD in dem wir folgende Programmzeilen einfügen:

define class customer as custom olepublic

procedure getcustomer

local ocustomer, lcstring

lcstring=substr(left(sys(16),rat("\",sys(16))),at(":",sys(16))-1)

SET defa TO (lcstring)

do form getcustomer name ocustomer linked

read events

endproc

enddefine

Wichtig ist die erste Zeile in diesem Programm, das Define Statement. Dieses Statement habe ich mit der Klausel OLEPUBLIC ausgestattet, welches VFP anweist, einen COM – Server aus dem Programm zu erstellen.

Die Klasse selbst habe ich CUSTOMER genannt. Also wird unser COM – Server unter dem Namen VFPWORD.CUSTOMER zur Verfügung stehen.

Im COM – Server selbst gibt es nur eine einzige Methode GETCUSTOMER welche uns die Maske anzeigen soll.

Zuerst müssen wir jedoch sicherstellen, daß wir uns auch im gleichen Verzeichnis befinden, wo die EXE oder die erzeugte DLL liegen wird. Dies wird durch die Zeilen:

lcstring=substr(left(sys(16),rat("\",sys(16))),at(":",sys(16))-1)

SET defa TO (lcstring)

bewerkstelligt. Merken Sie sich die zwei kleinen Anweisungen. Sie sind sehr sinnvoll, bei allen COM – Servern, die Sie jemals erzeugen werden. Sobald nämlich ein COM – Server gestartet wird, zeigt der Defaultpfad in das Verzeichnis der VFP500.DLL, also in das Windows/System32 Verzeichnis.

Nun müssen wir noch einen kleinen Trick anwenden, um zu verhindern, daß unsere Maske zwar am Schirm erscheint, jedoch nicht sofort wieder verschwindet. Deswegen habe ich nach dem DO FORM Kommando einen READ EVENTS eingeführt, welcher in der Form durch ein CLEAR EVENTS wieder aufgelöst werden muß.

Die Maske selbst ist einfachst erstellt. Erzeugen Sie eine Form, Öffnen Sie das Dataenvironment und fügen Sie die Customer Datei dazu. Nun ziehen Sie die gesamte Customer Datei in die Form und es wird Ihnen ein Grid erzeugt, welches alle Felder beinhaltet. Sie können natürlich die Felder und das Aussehen des Grinds verändern, wie Sie wollen.

Nun benötigen wir noch einen Button welcher uns die Form schließen läßt und die Daten in die Zwischenablage kopiert. Im Click -. Event des Buttons schreiben Sie einfach:

_cliptext = customer.company+chr(13)+ customer.address+chr(13)+customer.postalcode+" "+customer.region

clea events

thisform.release

_cliptext ist die Zwischenablage in der wir uns die Daten mit CHR(13) getrennt aufbereiten. Das CLEA EVENTS sorgt dafür, daß der COM – Server weiterarbeitet und das THISFORM.RELEASE schließt die Maske.

Nun noch ein paar Einstellungen in der Maske selbst, damit Sie einerseits selbständig am Schirm erscheint und andererseits sich in den Vordergrund schiebt.

Setzen Sie daher folgende Properties:

AlwaysOnTop    .T.

AutoCenter     .T.

BorderStyle    2 Fixed Dialog

Closeable      .F.

Desktop        .T.

ShowWindow     2 As Top-Level Form

Nun erzeugen Sie aus dem Projekt eine EXE -Datei.

Der WinWord COM – Client

Im WinWord selbst benötigen wir nun noch ein paar Zeilen Makrocode um unseren COM – Server zu starten und die nun in der Zwischenablage befindlichen Daten im aktuellen Worddokument einzufügen.

In WinWord können Sie unter Extras / Makros ein neues Makro erstellen. Nennen wir es der Einfachheit halber auch VFPWORD und fügen Sie folgende Zeilen darin ein.

Dim ovfpword As Object

Set ovfpword = CreateObject("vfpword.customer")

ovfpword.getcustomer

Set ovfpword = Nothing

Selection.Paste

Gehen wir zur Erklärung Schritt für Schritt vor.

Als erstes wird mit der DIM Anweisung eine Objektvariable definiert.

Nun wird diese Variable mit der SET Anweisung mit der Objektreferenz aus der Funktion createobject() gefüllt. Im Createobject finden wir den Namen unseres COM – Servers wieder.

Nun wird die Methode getcustomer angesprochen, welche unsere Maske anzeigen läßt und auf unseren Klick auf den OK Button wartet.

Nach dem Klick geht es zum nächsten SET, welches die Objektreferenz wieder zerstört.

Nun müssen wir nur noch den Inhalt der Zwischenablage einfügen und fertig.

Sie sehen, wenn man weiß, wie.... kein Problem.

OLE – DLL vs OLE – EXE

Sie haben im vorherigen Beispiel bemerkt, daß Sie die Möglichkeit haben entweder eine EXE oder eine DLL zu erzeugen.

Visual FoxPro 5.0 ist nicht Multithreading, dies bedeutet, daß ein Programm nicht mehrmals parallel laufen kann. Im Falle einer OLE – DLL wird das Programm "In Prozess" direkt an das aufrufende Programm, in unserem Falle WinWord angeschlossen. Ist einmal diese DLL an WinWord angehängt ist es nicht möglich diese DLL mehrmals parallel aufzurufen. Hintereinander natürlich schon.

Wird hingegen eine EXE erstellt, so wird diese EXE als "Out of Prozess" gestartet, was soviel bedeutet, als ob es eine eigenständige EXE ist und auch im Taskmanager erscheint. Sobald eine weitere Instanz der EXE gefordert wird, wird diese einfach noch einmal als einzelne EXE im Speicher instanziiert und ist somit "Quasi-Multithreading" (Streiten wir uns nun nicht um die Begriffe, 100%ig ist diese Definition nicht haltbar")

Unter VFP 6 ist nun das sogenannte Apartment – Threading Modell eingeführt worden, was eine OLE – DLL im Microsoft Transaktion Server mehrfach aufruffähig macht.

Leider ist in der VFP6.0 Version diese Funktionalität noch nicht 100%ig ausgereift, was bedeutet, daß diese DLL zwar als Apartment - Threading gekennzeichnet ist, jedoch auf Methodenebene nur eine Ausführung zur gleichen Zeit erlaubt. 

Wollen wir Microsoft jedoch die Chance auf eine Version 6.1 oder ähnliches geben.

Zwischen OLE-DLL´s und OLE-EXE´s gibt es auch noch einen weiteren Unterschied. Wir haben bereits gehört, daß eine OLE-DLL als Anhängsel an einem anderen Programm angehängt wird. Dies hat zur Folge, daß eine OLE-DLL keine eigenen visuellen Elemente anzeigen kann.

Eine OLE-EXE dagegen hat alles zur Verfügung um auch Formulare oder ähnliches anzuzeigen. Das obige Beispiel muß daher als OLE-EXE kompiliert werden, damit die Customer - Form angezeigt werden kann.

Active-X

Diese Komponenten stammen ursprünglich aus dem Visual Basic ab, welches von Haus aus nicht besonders viele Möglichkeiten zur Programmierung geboten hat.

Es wurde eine Schnittstelle geschaffen, bei der man externe VBX - Dateien ansprechen konnte.

Wenn man es genau betrachtet sind es modifizierte DLL´s, welche jedoch ausschließlich unter Visual Basic eingesetzt werden konnten.

Die VBX´en haben direkt auf interne Funktionen von Visual Basic zugegriffen, wodurch jedoch eine Art Einbahnstraße geschaffen wurde.

Man hat also die Köpfe zusammengesteckt und nahezu gleichzeitig mit OLE 2 die sogenannten OCX´e geschaffen.

Diese in C++ erzeugten "Pseudo-DLL´s" konnten nun teilweise bereits unter Visual FoxPro 3.0 eingesetzt werden.

Später wurde aus Marketinggründen ein Active X daraus gemacht. Active X Komponenten zeichnen sich durch Ihr grafisches Erscheinungsbild aus. (die meisten von Ihnen)

Ein Active X kann nur mit C++ oder neuerdings Visual Basic 5 erzeugt werden.

Durch die freie Verwendbarkeit, eigenen sich Active X Komponenten wunderbar um in nahezu allen Microsoft Produkten eingesetzt zu werden.

Selbst auf dem Internetexplorer sind viele von Ihnen einsetzbar.

Ein sehr gutes Beispiel liefert das Kalendercontrol, welches eine Monatsansicht darstellt und einem die Möglichkeit bietet Kalenderdaten anzuzeigen und auf Benutzereingaben zu reagieren.

Sie können es selbst ausprobieren, indem Sie unter VFP eine Form erzeugen und unter Extras / Optionen / Steuerelemente das "Calendar Control" markieren.

In der Maske selbst können Sie das Control nun aus der Toolbar der "Formular - Steuerelemente" in Ihre Form fallen lassen.

In der Zwischenzeit sind viele Bestandteile des Windowsbetriebsystems als Active-X Komponenten verfügbar.

Berühmtes Beispiel ist der Internetexplorer. Sehen Sie sich die IEXPLORE.EXE einmal genauer an. Sie werden bemerken, daß diese nur 60 Kb groß ist.

In Wirklichkeit ist die EXE nur eine Schale welche Ihrerseits das Internetcontrol als Active-X lädt.

DCOM

Bisher haben wir nur davon gesprochen, daß wir uns eines Programmes aneignen, welches auf der Maschine vorliegt, auf der auch das Hostprogramm läuft.

Dank Remote Procedure Call´s des Windows - Systems ist es jedoch auch möglich Programme über das Netzwerk zur Verfügung zu stellen.

Dazu gibt es grundsätzlich zwei verschiedene Vorgehensweisen.

  1. Remote Automation
  2. Distributed Common Object Modell

Ich möchte es vorwegnehmen, daß Remote Automation bei Microsoft bereits OUT ist und in Zukunft nur noch DCOM Verwendung findet.

Jedoch soll kurz erklärt werden, wie Remote Automation funktioniert.

Auf alle Fälle muß das aufzurufende Programm eine OLE - fähige Applikation sein. Also z.B. eine Visual FoxPro Klasse welche mit OLE-PUBLIC definiert wurde.

Dann muß auf dem Server die Applikation mit dem "RemAuto Verbindungs-Manager" (RACMGR32.EXE) als Remote Automation deklariert werden.

Dann startet man noch den " Automatisierungs-Manager" (AUTMGR32.EXE) der nun seinerseits auf Anfragen aus dem Netzwerk reagieren kann.

Wichtig ist vor allem, daß man die unter VFP erzeugte VBR und TLB Datei auf den Client überträgt und mit dem "Client registration Tool" (CLIREG32.EXE) in der Registry des Clients registriert.

Der Weg zum Erfolg ist nun folgendermaßen:

  1. CREATEOBJECT Aufruf des Clients
  2. es wird in der lokalen Registry nachgesehen, wo sich die aufgerufene Klasse befindet. Dort ist eingetragen, daß sie sich auf Computer sowieso befindet, was nun die Wirkung hat, daß mit diesem Computer Verbindung aufgenommen wird.
  3. Der Automatisierungs-Manager auf dem Host erkennt die Anfrage und sucht seinerseits die Klasse in der Registry des Host.
  4. Der Automatisierungs-Manager instanziiert die Klasse und übergibt via Netzwerk ein Objekthandle an den Client.
  5. Über diesen Netzwerkhandle werden nun die Nachrichten geschickt und der Client kann sich des Hosts bedienen.

DCOM unterscheidet sich nun folgendermaßen von Remoteautomation, indem es keinen Manager benötigt um zwischen Host und Client zu kommunizieren. Außerdem muß mit dem DCOM Konfigurationstool (DCOMCNFG.EXE) eingestellt werden, wo sich die Klasse befindet und wer darauf zugreifen darf.

Der größte Schwachpunkt der Remote Automation war und ist die Zugriffs(un)sicherheit. Erst mit DCOM ist ein Zugriffsschutz auf Systemebene gewährleistet.

Der Aufrufweg ist dann aber wieder identisch mit der "alten" Methode.

MTS

Seit Einführung des Option Packs unter NT4 bekommt man ein komplett neues Tool beigelegt, welches sich Microsoft Transaction Server nennt.

Die Versionsnummer beträgt hier bereits eine 2, was anzeigt, daß dieses Programm die Kinderkrankheiten bereits hinter sich gelassen hat.

Interessant ist besonders das Wort "Transaction". Mit Hilfe des DTC (Distributed Transaction Coordinator) ist der MTS nämlich in der Lage auf MS-SQL-Servern und Oracle Transaktionen zu starten, zu beenden oder per Rollback zurückzunehmen.

Das bedeutet, daß der MTS die Rolle eines "Aufpassers" übernimmt. Startet ein am MTS installiertes Programm eine Transaction auf einem SQL-Server und stürzt das Programm dann ab, oder wird es absichtlich verlassen oder beendet, so weiß der MTS, daß nun auch die Daten wieder in den Zustand vor der Transaction gebracht werden müssen und veranlaßt dies am SQL-Server. 

Solange Sie jedoch nicht mit einem SQL-Server arbeiten, dient uns der MTS für eine ganz andere Aufgabe.

Der MTS kann dafür sorgen, daß eine Single - Applikation mehrfach für verschiedene Benutzer ablaufen kann, ohne daß man sich um Netzwerkprobleme kümmern muß.

Grundsätzlich arbeitet der MTS wie ein normaler Server auf dem eine OLE-DLL installiert wurde.

Via DCOM (Distributed Common Object Modell) kann eine OLE-DLL über das Netzwerk auf dem Server gestartet werden.

Dies ist noch nichts aufregendes, da dies mit normalem DCOM oder Remote Automation ebenfalls funktioniert.

Anders sieht es bereits aus, wenn man sich einmal 200 oder sogar 1000 User vorstellt, die alle gleichzeitig die OLE-DLL laden wollen.

Grundsätzlich ist dies mit einer unter VFP5 entwickelten OLE-EXE möglich, da diese dann mehrfach instanziiert wird und für jeden User eine eigene Instanz am Server läuft.

Machen wir jedoch einen Blick auf die Speicherbelastung in einem solchen Fall. Eine kleine OLE-EXE verbraucht so zwischen 1 und 6 Megabyte. Mal 1000 User und wir sind schon fern von Gut und Böse.

Da kommt der MTS ins Spiel. Dort können grundsätzlich nur OLE-DLL´s installiert werden. VFP5-DLL´s kommen nicht in Frage, da diese noch nicht MTS - fähig sind. erst die VFP6 Version macht "ordentliche" DLL´s mit einer ordentlichen Typelibrary.

Wenn nun eine solche DLL als "Paket" installiert wird, so kapselt der MTS die DLL und ermöglicht einen Transparenten Zugriff von "Microsoft´s Definition von" nahezu unbeschränkt vielen Usern.

Das natürlich überall Grenzen zu setzen sind ist uns klar, aber der MTS verwaltet derartig intelligent den Speicher für die DLL´s, so daß pro User der auf die DLL zugreift nur ein Minimum an Speicherplatz und Prozessorlast benötigt wird.

Im Moment haben wir unter der VFP6.0 Version noch ein Entscheidendes Problem. Eine VFP6-DLL läßt sich zwar wunderbar installieren, sie ist jedoch nicht 100% Multithreading fähig. Das bedeutet im Klartext, daß alle anderen User warten müssen, solange ein einziger die DLL "beschäftigt".

Dieses Problem soll jedoch in einem sehr bald erscheinenden "Patch" behoben werden.

Schlußwort

Es ist mir natürlich nicht möglich alle Möglichkeiten aufzuzeigen, wie man wo mit was auf andere Programme zurückgreift. Was ich zum Beispiel im Moment nicht behandelt habe ist das absolut neue Message Queuing, welches mit dem neuen MSMQ - Server möglich wird. Aber es muß für weitere Devcons noch etwas übrig bleiben.

Sie sehen, daß die Entwicklung nicht stehen bleibt. Letztes Jahr wurde der MTS wahrlich bestaunt und heute ist es nichts Besonderes mehr, wenn man sich einmal damit beschäftigt hat.

Mir liegt am Herzen, daß sie durch diesen Artikel in Ihrer täglichen Arbeit etwas Erleichterung finden und der Frust über fehlende Möglichkeiten etwas gedämpft wurde.