Die COM Technologie ist die von Microsoft definierte und implementierte Technologie zur Kommunikation zwischen Anwendungen. Diese Kommunikation steht auch in Netzwerken zur Verfügung und kann so zur effizienteren Nutzung von Ressourcen eingesetzt werden.
Visual FoxPro bietet uns die Möglichkeit, COM Server zu erstellen. Mit einem COM Server können Funktionalitäten in VFP erstellt und über die COM Schnittstelle anderen Anwendungen zur Verfügung gestellt werden. Interessant ist dies auch unter dem Aspekt, da in VFP ein Datenbanksystem integriert ist und nicht noch ein zusätzlicher Dienst für die Verwaltung von Daten installiert werden muß – wie dies zum Beispiel bei VB der Fall ist.
COM Server bieten auch die Möglichkeit, verschiedene Benutzeroberflächen (HTML/Java, VB, VFP) zu erstellen und die eigentliche Geschäftslogik nur einmal als COM Server zu implementieren. Ein COM Server kann auch in einem Netzwerk zentral auf einem Server installiert und dort ausgeführt werden – die Arbeitsstationen führen nur die Benutzeroberfläche aus. Dieser Anwendungsfalle basiert auf der erweiterten COM Technologie und wird als DCOM bezeichnet (Distributet COM).
Der Einsatz von COM setzt jedoch ein Anwendungsdesign voraus, das die Funktionalitäten einer Anwendung in mehrere Ebenen aufteilt. Wir sprechen in diesem Fall von einer Multi-Tier Architektur.
Bevor wir uns mit dem Design und der Implementierung von COM Servern beschäftigen, sehen wir uns zuerst mal das Prinzip einer Multi-Tier-Architektur an. Der klassische Fall einer Multi-Tier -Architektur ist die 3-Ebenen Architektur. Die drei Ebenen sind:
Benutzeroberfläche: diese stellt den visuellen Teil einer Anwendung dar.
Geschäftslogik: diese Ebene bildet die eigentlichen Geschäftsregeln der Anwendung ab.
Datenhaltung: diese Ebenen stellt die Daten (Verwaltung) der Anwendung bereit.
Bei der Implementierung einer Mehrebenarchitektur ist die Kommunikation zwischen den eigentlichen Schichten zu beachten: damit die Abhängigkeiten nur unidirektional sind, dürfen die Schichten nicht übergreifend kommunizieren, es darf nur von der Benutzeroberfläche (UI) zur Geschäftslogik (BL) und von der Geschäftslogik zur Datenhaltung (DS) unidirektional kommuniziert werden. Dies bedeuted auch, daß eine Schicht nur das Interface der darunterliegenden Schicht kennt, sie kennt nicht das Interface der darüberliegenden Schicht.
Die Benutzeroberfläche ist derjenige Teil der Anwendung, der das Interface zum Benutzer darstellt. Es nimmt die Eingaben des Benutzers entgegen und stellt die Daten der Anwendung dar. Die Steuerung der Oberfläche wird auch von dieser Schicht wahrgenommen.
Die Geschäftslogik enthält alle Kernfunktionalitäten einer Anwendung. Sie übernimmt die Berechnung von Werten und die Gültigkeitsprüfung von Daten. Die Geschäftslogik darf keine Kenntnis über die Darstellung von Daten haben, sie kennt nur das Interface der Datenhaltung und kann dieses in Anspruch nehmen. Jegliche Form der Ausgabe ist normalerweise in dieser Schicht verboten. Die Information über den Zustand der Geschäftslogik und deren Prüfungen kann über ein Messaging System erfolgen. Die Geschäftslogik kann nicht aktiv Nachrichten an den Benutzer senden.
Die Datenhaltung übernimmt die Speicherung und Verwaltung von Daten. Es können hier auch allgemeine RI Regeln definiert und implementiert werden. Die eigentliche Validierung von Werten sollte von der Geschäftslogik übernommen werden, da die Implementierung von RI Regeln auch abhängig vom jeweiligen Datenbanksystem ist. Die Datenhaltung kann nicht aktiv Nachrichten an einen Benutzer senden. Sie darf auch nicht das Interface der Geschäftslogik ansteuern.
Die COM Technologie ist die Weiterentwicklung der OLE Technik von Microsoft. Mit Hilfe dieser Technologie ist möglich, zwischen verschieden Anwendungen zu kommunizieren (Inter-Process-Communikation IPC). Die Verwendung der COM Technologie setzt zur Zeit noch ein 32-Bit Betriebssystem von Microsoft voraus.
Bei der IPC ist zwischen der internen (InProcess) und externen (OutOfProcess) Prozesskommunikation zu unterscheiden. Die IPC unterscheidet zwischen einem (COM) Server und dem Client: der COM Server wird vom Client aufgerufen und nutz die Funktionalität des Servers. VFP kann sowohl als Client wie auch als Server eingesetzt werden.
Die COM Technologie setzt zumindest eine objektbasierte – besser ist eine objektorientierte – Anwendungsentwicklung voraus.
Bei der internen Prozesskommunikation wird ein COM-Server im gleichen Prozess wie die aufrufende Anwendung gestartet und erhält einen eigenen Thread. Das heißt auch, daß beide Anwendungen den gleichen Speicherbereich benutzen. Der Vorteil dieser Instanzierung ist die höhere Performance der Anwendung, da nicht über Speichergrenzen hinweg auf die Daten zugegriffen wird. InProcess Server sind immer als Dynamic Link Library (DLL) realisiert.
Die externe Prozesskommunikation stellt separate Prozesse und Threads für den Client und den Server bereit. Die Datenbereich der Prozessen sind demzufolgen auch getrennt und der Aufwand für die Übergabe von Daten zwischen beiden Anwendungen ist höher. Der Vorteil dieser Kommunikationsart ist jedoch die Möglichkeit, daß der Server und der Client auf verschieden Computern ausgeführt werden können. Der COM Server muß in diesem Fall als ausführbare Datei (.exe) vorliegen.
Die Erstellung einer DLL in VFP erfolgt über den Projektmanager oder den BUILD Befehl. Die VFP Laufzeitumgebung für InProcess Server kann sowohl die VFP6R.DLL wie auch die VFP6T.DLL Bibliothek sein. Diese beiden Laufzeitbibliotheken unterscheiden sich im Funktionsumfang erheblich. Ein OutOfProcess Server setzt die VFP6R voraus. Die Bibliothek VFP6T ist für Multithreading ausgelegt und um alle ausgaberelevanten Befehle und Funktionen reduziert. Die visuellen Klassenstehen jedoch noch zur Verfügung.
Die Erstellung von Servern unterscheidet zwischen SingleInstance und MultiInstance Servern. Hierbei ist zu beachten, daß je nach Typ, die Instanzen gemeinsame Speicherbereiche benutzen. Problematisch kann auch die Verwendung von Tabellen in der Default Datasession. Für die Instanzierung von COM Servern kann zur Sicherheit jeweils ein Sessionobjekt instanziert werden.
InProcess: dll; vfp6r.dll für jede Instanz; Sessions, Variablen
ApartmentModel Threading: Non-GUI, Fehler
Ein VFP COM Server stellt normalerweise die Funktionalitäten der Geschäftslogik und/oder der Datenhaltung bereit. Es kommt eher selten vor, daß ein COM Server das User Interface darstellt, da dies eigentlich die Aufgabe einer Client-Anwendung ist. Die nachfolgende Betrachtung geht davon aus, daß wir einen Server für Geschäftsobjekte erstellen wollen.
Die Instanzierung eines COM Servers erfolgt durch die Instanzierung eines Objekts. Dies bedeutet, daß kein Startprogramm aufgerufen wird, sondern das INIT des Objekt wird ausgeführt. Dies hat zur Folge, daß im INT des Objekts eine Methode zur Definition der Arbeitsumgebung auszuführen ist. Bei der Bereitstellung der Arbeitsumgebung muß auch darauf geachtet werden, daß die durch eine andere Instanz des Servers bereitgestellten globalen Variablen nicht überschrieben werden.
Die Methoden und Eigenschaften eines Serverobjektes sind für den Client sichtbar, sofern sie nicht als hidden oder protected definiert sind. Es ist sehr darauf zu achten, daß interne Methoden und Eigenschaften einer Klasse nicht als öffentliches Interface definiert werden. Die Sichtbarkeit von Objekten für den Client hängt der Art der Assoziation ab: Aggregierte Objekte sind für den Client sichtbar, assoziierte Objekte – mit createobject oder newobject instanzierte Objekte - sind für den Client nicht sichtbar. Sollen die öffentlichen Eigenschaften von Client direkt geändert werden können, so ist zu überlegen, ob auch Access und Assign Methoden benötigt werden.
Die Standardeigenschaften und –methoden von VFP sind nach Möglichkeit auch als PROTECTED zu deklarieren, um so den Zugriff auf diese Eigenschaften/Methoden durch den Client zu verhindern.
Der COM Server für die Geschäftslogik darf keine Ausgaben an den Benutzer vornehmen, hierfür können Methoden und Eigenschaften für die Abfrage von Nachrichten durch den Client vorgesehen werden.
Da ein COM Server kein visuelles Interface hat, kann zur Laufzeit die Funktion COMRETURNERROR() aufgerufen werden, um der Clientanwendung eine Fehlermeldung zu senden.
Ein grundsätzlicher Ansatz für die Bereitstellung eines COM Servers ist die Abgrenzung von Funktionalitäten zwischen dem Server und den eigentlichen Geschäftsobjekten. Der COM Server stellt das Interface und die Verwaltung der Instanzen für die Client zur Verfügung und liefert auf Anforderung Objektreferenzen auf die Geschäftsobjekte. Je nach Anforderung und Einsatzzweck muß der COM Server auch unterschiedliche Benutzer verwalten können – dies ist vor allem als Server für Internetanwendungen relevant.
Ein COM Server kann in VFP nur über entsprechende Klassendefinitionen erstellt werden. Ein für den Einsatz als COM Server freigebene Klasse muß als OLEPUBLIC deklariert sein. Die kann im Klassendesigner über den Menüpunkt KLASSE-Klasseninfo oder im Code durch die Option OLEPUBLIC erfolgen.
Define class VFP_Server as custom OLEPUBLIC
enddefine
Problematisch ist das Verhalten von Visual FoxPro bei der Bestimmung des Startverzeichnisses. Das Verhalten von VFP ist bei der Erstellung einer DLL und EXE unterschiedlich. Am sichersten ist die Verwendung der SYS(16) Funktion von VFP zur Feststellung des Startverzeichnisses. Das Ergebnis dieser Funktion ist entsprechend auszuwerten und kann dann für das Setzen der Pfade in VFP verwendet werden. Bei der Erstellung einer Server DLL können auch andere VFP Funktionen zur Pfadermittlung benutzt werden.
Die eigentliche Erstellung der Server DLL oder EXE kann über den Projektmanager oder programmatisch mit dem Befehl BUILD DLL <Servername> FROM <Projektname> erfolgen.
Das nachfolgende Beispiel beschreibt eine Klasse für den Zugriff auf eine Adressentabelle. Die Eigenschaft ALISTE ist eine Liste der gefundenen Adressen bei der Durchführung einer Suche. Die Anzahl der gefundenen Datensätze wird in nListe festghalten. Die Eigenschaft cTable enthält den Namen der zu benutzenden Tabelle in der die Adressen abgespeichert sind.
Die Methode Search dient zum Suchen von Datensätzen in der Adressentabelle.
Aus dieser Klasse erstellen wir eine DLL mit dem Namen VFP_SERVER.DLL. Diese Klasse kann nun über den Befehl
oPersonen= CreateObject( „VFP_Server.Personen“)
instanziert werden. Anschließend kann in der Adressentabelle mit
Anzahl= oPersonen.Search( „Becker“, „R“)
die Suche erfolgen.
DEFINE CLASS personen AS vfp_server OLEPUBLIC PROTECTED nliste nliste = 0 PROTECTED ctable ctable = "Adressen" Name = "personen" DIMENSION aliste[1] PROCEDURE search LPARAMETERS tcname,tcvorname local lnRows, lcSuche ** Parameter prüfen und bereinigen tcName= iif( vartype( tcName)= "C", lower( ltrim( tcName)), "") tcVorName= iif( vartype( tcVorName)= "C", lower( ltrim( tcVorName)), "") ** hier den Suchstring zusammensetzen lcSuche= iif( empty( tcName), "", "lower(cName)= tcName") if empty( lcSuche) ** nur den Vornamen suchen lcSuche= iif( empty( tcVorname), "", "lower(cVorname)= tcVorname") else ** Name und ggf. Vorname suchen lcSuche= lcSuche+ iif( empty( tcVorname), "", " and lower(cVorname)= tcVorname") endif ** nur Suchen, wenn ein Kriterium angegeben ist if not empty( lcSuche) select cPersnr, cName, cVorName, nAnrede, dGeboren; from (this.cTable) ; where &lcSuche ; order by cName, cVorname; into cursor _Result endif ** und nun prüfen, ob wir etwas gefunden haben this.nListe= _tally if _tally > 0 ** die Ergebnisse in das Listenarray kopieren select cPersNr, cVorname, cName ; from _Result ; into array this.aListe else ** Liste löschen dimension this.aListe[1] this.aListe= "" endif return _tally ENDPROC ENDDEFINE
Die Erstellung eines COM Servers ist mit VFP relativ einfach durchzuführen. Zu beachten ist im wesentlichen, daß ein COM Server keine Ausgabe an den Benutzer direkt vornehmen darf.
Die Verwendung von COM Servern setzt jedoch eine starke Trennung der Architekturebenen voraus, kann aber so in verschiedenen Umgebungen eingesetzt werden, sofern ein COM Interface vorhanden ist. Es ist so auch denkbar, Betriebssysteme für die Clients einzusetzen, die nicht von Microsoft hergestellt werden, da die COM Technologie auch im Netzwerk einsetzbar ist – beispielsweise über das Internet.