Quelle: Gartner Group
Diese Session ist als Einführungssession in das Thema Client/Server gedacht. Es geht darum die prinzipiellen Möglichkeiten wie mit VFP Client/Server Applikationen entwickelt werden können aufzuzeigen. Es wird erläutert welche Gründe für eine C/S Lösung sprechen und wie eine C/S Architektur aussieht. Im konkreten VFP Teil wird es um solche Themen wie remote Views, SQL Pass Through und Data Buffering gehen. Es wird gezeigt wie Daten auf einem SQL Server von VFP aus angesprochen werden können und welche Möglichkeiten der Entwickler hat, über Parameter die Performance dieser Zugriffe zu beeinflussen. Der Upsizing Wizard von VFP wird das abschließende Thema der Session sein.
Client/Server ist eines der Buzz Words der letzten Jahre im gesamten Computer Business. Welche Vorteile bringen Client/Server Architekturen und was sind die Gründe warum sie so ‘modern’ sind?
Was ist Client/Server überhaupt? Client/Server bedeutet mehr als einfach ein Netzwerk mit einem zentralen Fileserver, auf dem die Daten liegen und auf den alle konkurrierend zugreifen. Es bedeutet vielmehr, daß auf mehreren Rechnern gemeinsam die Bearbeitung einer Applikation stattfindet. Das heißt, auch auf dem Server findet eine Verarbeitung statt.
Der Trend zum Client/Server Computing wurde hauptsächlich ausgelöst von einem Trend in der Welt der Mainframes. Das Schlagwort dazu ist ‘Downsizing’. Das bedeutet, Applikationen die bisher auf dem Mainframe abliefen, in eine C/S Umgebung (Pcs, Workstations) zu portieren. Wobei man das Portieren nicht zu wörtlich nehmen darf. Es muß meist (oder immer) ein komplettes Redesign stattfinden. Hauptsächlich aus dieser Umgebung kommen auch die meistgenannten Argumente für Client/Server Architekturen.
Die meisten Gründe für Client/Server Systeme kommen aus dem Bereich des Downsizing. C/S Architekturen, die Maiframes ablösen, sind für größere Firmen eine gute Möglichkeit in der EDV Geld zu sparen, auch wenn dieser Vorteil oft überschätzt wird. Auch PCs benötigen Wartung und auch Client/Server Applikationen haben hohe Entwicklungs und Wartungskosten wenn sie eine größere Mainframe Applikation ablösen sollen. Von der Seite der PC Entwickler gesehen gibt es im wesentlichen drei (oder vier) Gründe für Client/Server: Die Sicherheit der Daten, Anwendungen mit WAN Anbindung, sehr große Datenmengen (im Gigabyte Bereich) und der Wunsch des Kunden.
Für eine Standard Applikation reicht ein Programm, das auf einen Fileserver zugreift völlig aus. Die Multiuser Funktionalität ist gegeben und die Geschwindigkeit wird oft besser sein, als bei einer Client/Server Architektur, bei der der Server ‘unterdimensioniert’ oder schlecht konfiguriert ist.
Client/Server Architekturen entstehen durch die Aufteilung einer Applikation in einen Client (Front-End) und einen Server (Back-End) Teil. Die Applikation kann an verschiedenen Stellen ‘aufgetrennt’ werden.
Grundsätzlich betrachtet man bei dieser Aufteilung einer Applikation drei Schichten:
Quelle: Gartner Group
Bei einer Verteilung der drei Bereiche in einen Client und einen Server Teil entstehen die obigen Architekturmodelle. Die ersten Beiden Modelle spielen in der heutigen Praxis kaum eine Rolle. Es gibt Ansätze (und Tools) um Mainframe Applikationen auf Pcs zu bringen, indem man die Charakter basierten Masken in Windows Masken ‘umsetzt’ und die eigentliche Applikation weiter auf dem Host abläuft.
Wichtiger sind die weiteren Architekturmodelle. Alle drei Architekturen sind mit Visual FoxPro bzw. einer Kombination von Visual FoxPro und einem Datenbank Server System (z.B. SQL-Server) möglich.
Von einer Verteilung der Applikationslogik kann man schon dann ausgehen, wenn auf einem Datenbank Server Stored Procedures einsetzt werden, die Funktionen der Applikation darstellen, und nicht nur der Datenintegrität (Trigger) dienen. Dieses Modell wird mit der Einführung von verteiltem OLE durch Microsoft wohl einen starken Boom erleben.
Das nächste Modell stellt eine Architektur mit einem ‘reinen’ Datenbank Server dar. Der Server stellt nur die Datenfunktionalität zur Verfügung die gesamte Steuerlogik und der User Interface liegen auf dem Client.
Mit Visual FoxPro ist auch die letzte Version der Architekturmodell möglich, nämlich eine Verteilung der Datenbankfunktionalität zwischn Server und Client. In einer Anendung können lokale Daten und Server Daten gemischt verwendet werden.
In den weiteren Betrachtungen wird hier nur die Zusammenarbeit von Visual FoxPro mit SQL-Server vorgestellt. Grundsätzlich ist aber eine Zusammenarbeit von VFP aus mit jeder ODBC Datenquelle möglich. Wieviel Funktionalität dann gewährleistet werden kann hängt von der tatsächlichen Datenquelle (das Datenbank System) und den ODBC Treibern ab.
Die Client/Server Möglichkeiten von Visual FoxPro werden grundsätzlich über ODBC Verbindungen realisiert (es sind auch andere Möglichkeiten denkbar, aber diese sind nicht im Lieferumfang von VFP enthalten).
ODBC heißt Open Database Connectivity. ODBC ist eine Standard Schnittstelle zum Datenaustausch zwischen Applikationen. Für die jeweilige Datenquelle wird ein spezieller ODBC Treiber benötigt. Es gibt ODBC Treiber für alle wichtigen Datenbanksysteme. Einige werden mit VFP ausgeliefert. ODBC Treiber können sehr unterschiedlich aufgebaut sein: Es gibt Treiber, die die gesamte Datenbankfunktionalität beinhalten müssen (Access, Dbase) und Treiber, die nur Funktionsaufrufe an das eigentlich Datenbanksystem weitergeben (SQL- Server, Oracle). Die zweite Kategorie ist wesentlich performanter, da die Funktionen von einem ‘echten’ Datenbanksystem ausgeführt werden und nicht durch den Treiber selbst.
Nun zur Praxis: Wie verbindet man Visual FoxPro mit einer ODBC Datenquelle (SQL-Server)? Zuerst muß die ODBC Datenquelle in der Systemsteuerung eingerichtet werden. Im Falle SQL Server bedeutet dies: Eine Verbindung zum Server muß in der ODBC Verwaltung (VFP Programm Gruppe oder Systemverwaltung) eingerichtet werden.
Nachdem dies geschehen ist kann in einem Datenbankcontainer eine Verbindung auf diese Datenquelle eingerichtet werden. Dies kann mit dem ‘Verbindungsdesigner’ mit ein paar Mausclicks erledigt werden:
Man kann Benutzerkennung und Paßwort auch offen lassen, dan wird der Benutzer bei einer Verwendung der Verbindung nach Benutzerkennung und Paßwort gefragt.
Mit SPT (SQL Pass Through) war es bereits unter FoxPro 2.6, in Verbindung mit dem Connectivity Kit, möglich Client Server Anwendungen zu erstellen. Die Verbindung mußte dabei aber ‘von Hand’ aufgebaut werden, mit:
nConHandle=SQLCONNECT(‘Upsizt’, ‘sa’)
Auch bei der weiteren Verarbeitung war man auf reine Befehle (besser gesagt Funktionen angewiesen). Diese Art von Verarbeitung ist auch mit VFP noch möglich und kann sehr gut für Batch Processing eingesetzt werden. SPT ist außerdem notwendig um Stored Procedures auf dem Server aufzurufen. Ein SPT Befehl sieht folgendermaßen aus:
=SQLEXEC(nConHandle, ‘Select * from authors’).
Der SQL Befehl kann auch in einer Variablen übergeben werden. Damit besteht die Möglichkeit per Programm einen SQL Behl ‘zusammenzubauen’ und diesen auf den Datenbank Server abzusetzen. Der Befehl wir dort abgearbeitet, und das Ergebnis (wenn es eines gibt) kommt in einem Cursor zurück. Die SQL Befehle, die in diesem String übergeben werden müssen der (SQL) Server Syntax genügen.
Auch wenn mit dieser Technik bereits alle Client/Server Möglichkeiten bestehen, (und bereits in FoxPro 2.6 vorhanden waren) gibt es eine wesentlich einfachere Möglichkeit Client/Server Anwendungen zu realisieren:
Mit Remote Ansichten kann man sich Daten vom Server in einen lokalen Cursor holen. Dort kann mit ‘normalen’ FoxPro Befehlen auf diesen Daten gearbeitet werden. Die Veränderungen der lokalen Daten können auch auf den Server ‘durchgereicht’ werden.
Remote-Ansichten werden im Remote-Ansichten Designer in einem Datenbank Container angelegt. Beim Anlegen einer Remote-Ansicht wird zuerst nach der Verbindung gefragt (die im DBC vorhandenen Verbindungen werden angezeigt). Zunächst definiert man welche Tabellen in der Remote-Ansicht verwendet werden sollen. Anschließend wird die Where Klausel des Selects bestimmt. Man muß bei Client/Server Anwendungen beachten, daß man sich nicht alle Datensätze einer Tabelle auf die Workstation holt sondern nur einen möglichst kleinen Teil (Netzbelastung, Performance). Weiter kann man definieren welche Felder, aus welchen Server Tabellen im View enthalten sein sollen (Projektion). Mit einer so definierten Ansicht kann man bereits Daten auf dem Server sehen.
Mit Remote-Ansichten können auch Daten auf dem Server verändert werden. Dazu muß die Ansicht aktualisierbar gemacht werden.
Schlüsselfelder können nicht bei jeder Server Datenbank aktualisiert werden. Dafür ist es dann eventuell nötig die Updates per Delete und Insert zu erledigen (Option). Auf dieser ‘Aktualisierung’ Seite des Designers kann also genau festgelegt werden welche Daten upgedatet werden und auf welche Weise dies geschieht. So kann hier festgelegt werden, wie das System die Where-Bedingung des Update Statements zusammensetzen soll. Damit ist es möglich mit konkurrierenden Updates umzugehen.
Client/Server Verbindungen können vom System unterschiedlich behandelt werden. Es gibt eine Reihe von Parametern, die das Verhalten von ODBC Verbindungen bzw. Remote-Ansichten beeinflussen.
Die generellen Parameter einer ODBC Verbindung können mit der Funktion SQLSETPROP(ConHandle, Parameter, Wert) bestimmt bzw. mit der Funktion SQLGETPROP(ConHandle, Parameter) eingesehen werden. Die Befehle bekommen als Parameter ein Connection Handle und den Namen des jeweiligen Parameters so wie dessen gewünschten Wert (ähnlich wie ‘SET’). Mit einer Null für den Connection Handle Parameter können die Default Einstallungen beeinflußt werden. Die Default Settings können auch im Optionen Dialog verändert werden. Die meisten Parameter sind ‘visual’ im Verbindungsdesigner einzustellen.
Vorsicht die Default Einstellung ist 4 K (4096) Byte!
Manche Systeme funktionieren aber nur mit der Einstellung 512 Byte! |
Diese Aufzählung der Parameter ist nicht vollständig, insbesondere wurden alle Read-Only Parameter weggelassen mit denen Informationen zu einer Verbindung angeschaut werden können.
Die Parameter von Remote-Ansichten können mit CURSORSETPROP(Parameter, Wert, Alias) und CURSORGETPROP(Parameter, Alias) ähnlich behandelt werden, wie die Parameter der Verbindung. Die Funktionen bekommen jedoch nicht ein Connection Handle, sondern den Alias (oder die Workarea) einer Ansicht übergeben:
Auch diese Liste ist nicht vollständig, es sind aber insbesondere einige für die Performance wichtige Parameter erwähnt.
Je nach Zeit der Session wird hier noch kurz der Upszing Wizard gezeigt werden.