In diesem Artikel wird eine Einführung gegeben, wie man Visual FoxPro 6.0 im Zusammenhang mit MTS benutzt. Es werden die Grundlagen von MTS behandelt und die Benutzung von VFP zur Erzeugung von COM-Komponenten erklärt.
MTS ist auf die Arbeit als 3-tier Anwendungshilfsmittel ausgelegt, aber leider sind außer dem Export der VFP COM-Komponenten in ein MTS Paket noch weitere Schritte bzw. Überlegungen nötig. Da viele Infrastrukturmaßnahmen von MTS erledigt werden, hat der Entwickler mehr Zeit, sich um Fragen wie Performance und der Skalierbarbeit seiner Anwendung zu kümmern. Gute MTS Anwendungen werden von Anfang an im Hinblick auf MTS konzipiert.
Dieser Vortrag behandelt die folgenden Themen :
Es wird erwartet, daß MTS schon installiert ist. Er ist verfügbar als Bestandteil des Windows NT 4.0 Option Packs. Dies ist u.a. verfügbar von der folgenden Microsoft WebSite :
http:\www.microsoft.com\ntserver\all\downloads.asp
Zusätzlich sollten Sie sich mit den Grundlagen von MTS vertraut machen. Diese sind in den Hilfedateien enthalten, die in MTS nach der Installation enthalten sind.
MTS ist ein komponentenbasiertes Transaktionsverarbeitungssystem, um robuste Internet und Intranet-Anwendungen zu erzeugen, verteilen und zu verwalten. Zusätzlich ermöglicht Ihnen MTS, Ihre MTS-Anwendungen mit einer grafischen Oberfläche (MTS Explorer) zu verteilen und zu verwalten. MTS enthält folgende Bestandteile :
Das MTS-Programmiermodell stellt ein Rahmen zur Komponentenentwicklung dar, der die Business Logic einer Anwendung kapselt. Die MTS-Laufzeitumgebung ist eine Middle-Tier Plattform für diese Komponenten. Der MTS Explorer zur Verwaltung von in der MTS-Laufzeitumgebung ablaufenden Komponenten.
Eine weitere Definition beschreibt den MTS ale eine Kombination zwischen einem Object Request Broker (ORB) und einem Transaction Processing Monitor (TP-Monitor).
Ein Object Request Broker (ORB) ist genau das, wie er heißt, ein Vermittler von Objekten. Wenn ein Aufruf zu einem Server kommt und ein Objekt anfordert, führt der ORB diesen Aufruf durch, überprüft die Verfügbarkeit und stellt schließlich dem aufrufenden Prozeß das Objekt zur Verfügung.
Ein Transaction Processing Monitor (TP-Monitor) ist einfach ausgedrückt eine Umgebung, die sich zwischen dem Client- und dem Server einfügt, um Transaktionen, Resourcen, Load Balancing und Fehlerbehandlung zu verwalten. Das typische TP-Monitor hat keine Kenntnis von Objekten. Es weiß, wie man Anfragen in der bestmöglichen Weise durchführt.
Jeri Edwards schreibt in seinem Buch ' The Essential Distributed Objects Survival Guide', daß Transaction Processing Monitore (TP Monitore) sich zu ORBs entwickeln werden. Diese Entwicklung ist natürlich.
Die Behandlung von Server Resourcen als Objekte und die Überwachung der Aktivitäten der Objekte macht durchaus Sinn. Die Objekte selbst werden Teil der Transaktion. Die Kombination von Object Request Brokering und TP Monitoring bietet ungeahnte Vorteile.
Transaction Server kombiniert beide Konzepte, damit wird DCOM als Verbindung benutzt. Anforderungen an Objekte kommen via DCOM. Der Transaction Server verarbeitet die Anforderungen, erzeugt die benötigten Server Resourcen und beginnt die Transaktion. Er gibt die Referenz auf das Objekt zu dem Client zurück, damit dieser damit machen kann, was er will. Der Transaction Server sitzt immer zwischen dem Objekt und dem Client und überwacht alles was der Client ausführt. Während dies geschieht arbeitet er gleichzeitig als TP Monitor mit den gleichen Aufgaben wie ein herkömmlicher TP Monitor. Er kann Anforderungen zeitlich nacheinander durchführen, Resourcen bündeln etc. Wenn der Client mit seiner Tätigkeit beendet ist, wird das Objekt gelöscht, was den Transaction Server veranlaßt, die Trasnaktion durchzuführen und die Resourcen freizugeben oder im Pool zu belassen.
Microsoft investiert sehr viele Resourcen zur Unterstützung von 3-tier Entwicklungen, weil viele Vorteile aus dieser Anwendungsarchitektur entstehen. Wie in der untenstehenden Grafik beschrieben, repräsentiert Tier 2 oder das sogenannte ‘middle-tier’ die Schicht, wo der Großteil der Anwendungslogik enthalten ist. Visual FoxPro COM Komponenten sind vorzüglich für diese Architektur geeignet und weden eine Schlüsselrolle in dieser Schicht spielen. MTS stellt die Infrastruktur für den ‘middle-tier’ zur Verfügung.
In Zukunft werden Anwendungen aus einem web-basierten Frontend bestehen, welches eine Kombination aus HTML/XML benutzen wird. Obwohl Visual FoxPro Daten benutzt werden können, sollten die Anwendungen so geschrieben werden, daß sie mit einem beliebigen Backend kommunizieren können. Die Anwendung sollten daraufhin getestet werden, wie einfach das Backend gewechselt werden kann – z.B. von einer VFP Datenbank zu SQL SERVER. Es gibt hierzu verschiedene Optionen wie ODBC und OLE DB (ADO), welche generische Schnittstellen zu den Daten zur Verfügung stellen. Die Anwendung sollte so geschrieben werden, daß alle Komponenten in allen Schichten beliebig austauschbar und unabhängig voeinander sind.
Worin liegen nun die Vorteile von MTS für VFP Entwickler ? Durch die Möglichkeit Komponenten zu erzeugen und zu verwenden wird die Wiederverwendbarkeit von Lösungen erleichtert. Weiterhin kann man eine Reduzierung der TCO (Total Cost of Ownership) erreichen. Damit sind die gesamten Aufwendungen für die Aufrechterhaltung eines Corporate Information Systems gemeint.
Zunächst vereinfacht sich die Aktualisierung des Presentation Layer, da eigentlich nur eine Aktualisierung des Browsers vonnöten ist. Frontend-Anwendungen, die mit VFP/VB erstellt wurden, bieten zwar größere Möglichkeiten in der Benutzeroberfläche, aber die Aktualisierung ist wesentlich aufwendiger. (z.B.150 Clients mit einer neuen Version auszustatten kann ein zeitraubender Prozess sein). Weiterhin ist zu erwarten, daß die Möglichkeiten von Benutzeroberflächen sich in Zukunft erweitern werden (DHTML).
Die Backend-Daten ändern sich normalerweise am wenigsten. Die Daten zentral abzuspeichern reduziert ebenfalls die Kosten. Die Daten können durchaus verteilt sein, aber durchaus zentral verwaltet werden. Sie müssen nicht zentral gehalten werden, um auch zentral verwaltet zu werden.
Schließlich haben wir Visual FoxPro in der Mittel-Schicht. Die 'middle-tier'-Komponenten werden oft geändert, da sie die Business Logic repräsentieren, die den aktuellen Gegebenheiten angepaßt werden müssen. Herkömmliche Client/Server-Systeme und monolithische Anwendungen fassen die beiden ersten Schichten in einer zusammen. Dies erhöht die Aufwendungen für die Aktualisierung der Anwendung. Mit einem Browser als Frontend verschwinden viele dieser Verteilungsprobleme. Geschäftsregeln sind meist recht komplex und können vertrauliche Informationen enthalten, so daß es nicht vorteilhaft ist, diese mit dem HTML zu dem Browser zu schicken.Außerdem kann dies zu Performance-Problemen führen.
Dies führt zu einem Dilemma. Einerseits soll die Anzahl der Informationen begrenzt werden, die zu dem Client zurückgesendet wird, andererseits soll auch die Anzahl der Datensatzbewegungen minimiert werden. Die beste Lösung stellt die Einführung eines sogenannten 'Smart-Client' dar. Historisch bedingt wird ein Web Browser als Darstellungsmöglichkeit für statische Webseiten verstanden. Jedes Mal, wenn sich die Inhalte der Webseite ändern sollen, muß eine Aktualiserung der kompletten Webseite vorgenommen werden. Mit Dynamic HTML (DHTML) ist es möglich, nur die Teile der Darstellung zu ändern, die aktualisiert werden müssen. Weiterhin können (oder sollten) Geschäftsregeln auf dem Client ausgeführt werden, was zu einer Verringerung der Kommunikation mit dem Web-Server führt. Zum Beispiel einfache Validierungsregeln zur Überprüfung, ob ein Wert nicht negativ ist. Es ist effizienter, solche Überprüfungen auf dem Client durchzuführen. Die Mehrzahl der Regeln, vor allem diese mit vertraulichem Inhalt verbleiben auf dem Server, ohne daß der Client diese zur Kenntnis bekommt. Die Geschäftsregeln auf dem Client können jedoch genausooft Änderungen unterliegen wie die auf dem Server. Die ATSWeb Anwendung (verfügbar auf der Visual Studio 6.0 WebSite) zeigt ein Beispiel wie Geschäftsregeln sowohl auf dem Client als auch dem Server ausgeführt werden.
VISUAL INTERDEV bietet sich hier als ideales Entwicklungswerkzeug für die Entwicklung Browseranwendungen an, da es u.a. die Erzeugung von DHTML-Code auf dem Client unterstützt. Weitere Informationen hierzu erhalten Sie unter
http://msdn.microsoft.com/vinterdev
MTS stellt eine Infrastruktur zur Verfügung, um VFP middle-tier Objekte einzubinden, da er der allgemeinen Aufgaben übernimmt, einschließlich Ressourcen- und Thread-Management. Zugriffsrechtverwaltung, Verteilung und Transaktionsverwaltung. Der Entwickler kann sich um die eigentliche Entwicklung der Geschäftsregeln kümmern.
Bevor die Benutzung von VFP für den MTS gezeigt wird, noch einige Grundlagen, die man benötigt, um die Vorteile der MTS-Umgebung zu nutzen. Die meisten Informationen befinden sich auch in den Hilfedateien, in denen auch weitergehende Informationen enthalten sind.
Jedes MTS-Objekt erhält automatisch einen Kontext. Dieser enthält Informationen über die Ausführungsumgebung des Objektes, wie die Identität des Objekterzeugers und möglicherweise den Zustand der Transaktion, in die die Komponente eingebunden ist. Der Kontext wird von der MTS-Laufzeitumgebung verwaltet.
Als VFP Entwickler sollte man bedenken, daß jede VFP Komponente, die in einem Paket registriert ist, zur Laufzeit einen Kontext besitzt. Durch die Instanzierung einer Komponente in einem MTS-Paket wird neben der VFP Komponente selbst das zugehörige Kontextobjekt erzeugt. Das folgendes Beispiel zeigt, wie man eine Referenz auf das entsprechende Kontextobjekt erzeugt :
#DEFINE MTX_CLASS "MTxAS.AppServer.1"
LOCAL loMTX, loContext
loMtx = CREATEOBJECT(MTX_CLASS)
loContext = loMtx.GetObjectContext()
Das Kontextobjekt hat die folgenden Methoden und Eigenschaften
| PEM | Beschreibung |
|---|---|
|
Count |
Gibt die Anzahl von Objekteigenschaften zurück. |
|
CreateInstance() |
Instanziert ein anderes MTS-Objekt. |
|
DisableCommit() |
Zeigt an, daß das Objekt seine Arbeit noch nicht beendet hat und seine Aktualisierungen innerhalb einer Transaktion befinden sich in einem inkon-sistenten Stadium. Das Objekt behält seinen Zustand über Methodenaufrufe und jeder Versuch, die Transaktion durchzuführen, bevor das Objekt EnableCommit oder SetComplete aufruft, führt zu einem Rückführen der Transaktion. |
|
EnableCommit() |
Zeigt an, daß die Arbeit des Objektes noch nicht beendet ist, aber die Aktualisierungen innerhalb einer Transaktion befinden sich in einem konsistenten Stadium. Diese Methode erlaubt es die Transaktion durchzuführen, aber das Objekt behält seinen Zustand über Methodenaufrufe bis es SetComplete() oder SetAbort() aufruft oder bis die Transaktion abgeschlossen ist. |
|
IsCallerInRole() |
Überprüft ob der aufrufende Prozess in einer bestimmten Rolle ist (entweder direkt oder als Teil einer Gruppe) |
|
IsInTransaction() |
Überprüft, ob das Objekt innerhalb einer Transaktion ausgeführt wird.. |
|
IsSecurityEnabled() |
Überprüft, ob die Zugriffsrechtsverwaltung aktiviert ist |
|
Item() |
Gibt das Kontextobjekt zurück |
|
Security |
Gibt eine Referenz auf die Security-Eigenschaft des Objektes zurück. |
|
SetAbort() |
Legt fest, daß das Objekt seine Arbeit beendet hat und wieder deaktiviert werden kann. Die Aktualisierungen innerhalb der Transaktion haben zu einem inkonsistenten Zustand geführt oder ein sonstiger Fehler ist aufgetreten. Die Transaktion muß abgebrochen werden. Wenn ein Objekt innerhalb einer Transaktion die SetAbort()-Methode auslöst, wird die komplette Transaktion zurückgefahren. |
|
SetComplete() |
Legt fest, daß das Objekt seine Arbeit beendet hat und deaktiviert werden kann, wenn die aktuelle Methode beendet ist. Die Aktualiserungen innerhalb der Transaktion können durchgeführt werden. Wenn das Objekt die Wurzel der aufrufenden Objekte innerhalb der Transaktion dargestellt, versucht MTS die Transaktion durchzuführen, wenn die Programmausführung die aktuelle Methode abgeschlossen hat. |
Wie man sehen kann, werden die Methoden und Eigenschaften dazu verwendet, um auf Informationen über den Transaktions- und Security-Kontext des Objektes zuzugreifen. Der Kontextzustand kann weitervererbt werden. Ein Objekt, daß von einem anderen Objekt aus demselben Paket aufgerufen wird, erbt dessen Zustand des Kontextobjektes. Da der Kontext auf den gleichen Prozess begrenzt ist, glauben sich die Komponenten untereinander. Jedes Objekt in dem Paket braucht nicht seine eigenen Zugriffsrechte. Wenn das Objekt gelöscht, wird der Kontext ebenfalls entfernt.
Pakete sind Gruppen von Komponenten, die zueinander in Beziehung stehende Funktionalitäten innerhalb der Anwendung durchführen. Alle Komponenten eines Pakets laufen in demselben MTS-Prozess.
Wichtig hierbei ist, einen der Eingangsbemerkungen zu wiederholen : “Gute MTS-Anwendungen werden von Anfang an in Hinblick auf MTS entworfen”. Der Inhalt der Pakete sollte immer im Zusammenhang mit der gesamten Anwendung konzipiert werden. Da jedes Paket einem eigenen Prozess läuft, sollte vermieden werden, daß Komponenten außerhalb des Paketes aufgerufen werden. Obwohl es eine Performanz-steigerung bedeutet, möglichst alle Komponenten einer Anwendung in einem Paket zu halten, können Zugriffsrechtsbeschränkungen eine andere Architektur fordern.
Die Verteilung der Anwendung erfolgt über Pakete. Mit Hilfe des MTS Explorers kann man Export-Pakete (Server und Client) für die installierten Pakete erzeugen.
Eine Rolle ist ein symbolischer Name, der eine Gruppe von Benutzern für eine Ansammlung von Komponenten definiert. Jede Rolle definiert, welchen Benutzern es erlaubt ist, Schnittstellen einer Komponente aufzurufen. Sie ist der Mechanismus, um die Zugriffsrechtsverwaltung sicherzustellen. Die rollen-basierte Zugriffsrechtsverwaltung wird auf Komponentenebene durchgeführt.
Rollen werden in dem Paketen abgespeichert. Jede Komponente eines Paketes kann zu einem oder mehreren Rollen gehören.
Die Zugriffsrechtsverwaltung kann so eingerichtet werden, daß sie automatisch durchgeführt wird. Dies bedeutet, daß Benutzer, die keiner Rolle angehören, automatisch einen Access Denied-Fehler erhalten. Weiterhin kann sie auch per code durchgeführt werden. Dazu kann man die ISCallerInRole()-Methode verwenden.
Ein Resource Dispencer verwaltet den nicht-dauerhaften Zustand von Komponenten innerhalb eines Prozesses. MTS enthält zwei Resource Dispenser :
Die Resourcen werden im gleichen Prozess geteilt. Der gleiche Prozess bedeutet auch das gleiche Paket.
Der ODBC Resource Dispenser verwaltet für die MTS-Komponenten die Pools von Datenbank-verbindungen, die die ODBC-Schnittstelle verwenden. Die Verbindungen werden automatisch den Transaktionen der Objekte zugewiesen und der Resource Dispenser kann automatisch Verbindungen wiederherstellen und entfernen. Der ODBC 3.0 Driver Manager ist der ODBC Resource Dispenser. Er wird automatisch mit MTS installiert.
Der Shared Property Manager liefert den Zugriff zu anwendungsdefinierten, prozessweiten Eigenschaften.
Der Shared Property Manager stellt folgende PEMs zur Verfügung :
| PEM | Beschreibung |
|---|---|
|
CreatePropertyGroup() |
Erzeugt eine neue SharedPropertyGroup über den übergebenen Namen. Falls die Gruppe schon existiert wird die Referenz darauf zurückgeliefert. |
|
Group() |
Gibt nur die Referenz auf eine bereits bestehende Gruppe zurück |
|
CreateProperty() |
Erzeugt eine neue SharedProperty über den übergebenen Namen. Falls die Eigenschaft schon existiert wird die Referenz darauf zurückgeliefert. |
|
Property() |
Gibt nur die Referenz auf eine bereits bestehende Eigenschaft zurück |
|
CreatePropertyByPosition() |
Erzeugt eine neue SharedProperty über einen numerischen Index. Falls die Eigenschaft schon existiert wird die Referenz darauf zurückgeliefert. |
|
PropertyByPosition() |
Gibt nur die Referenz auf eine bereits bestehende Eigenschaft zurück |
|
Value() |
Gibt den Wert der Property zurück |
Ein Resource Manager ist ein Systemdienst, der dauerhafte Daten verwaltet. Serveranwendungen verwenden Resource Manager, um einen dauerhaften Zustand der Anwendung aufrechtzuerhalten. Resource Manager arbeiten mit dem Microsoft Distributed Transaction Coordinator (MSDTC) zusammen, um die Grundprinzipien eines Transaktion (ACID) zu gewährleisten. MTS unterstützt Resource Manager wie SQL SERVER 6.5.
Der Microsoft Distributed Transaction Coordinator (MS DTC) ist ein Systemdienst, der Transaktionen koordiniert. Eine Transaktion kann sich über verschiedenen Resource Manager (Datenbanken) erstrecken, auch auf verschiedenen Computern. MS DTC ist als ein Teil von SQL SERVER 6.5 veröffentlicht worden und ist in MTS eingebettet, wo er die systemnahe Infrastruktur für verteilte Transaktionen zur Verfügung stellt. MS DTC benutzt ein two-phase commit Protokoll, um verteilte Transaktionen über mehrere Resource Manager zu gewährleisten.
WICHTIG : VFP ist kein Resource Manager für MS DTC. Die von VFP verwendeten Transaktionen werden nicht durch MS DTC gesteuert und somit unterstützt MTS keine Transaktionen mit VFP Datenbanken. Die Datenbank muß entweder OLE Transactions (SQL SERVER) oder XA-compliant (ORACLE) sein.
Ein Base Client ist eine Anwendung, die außerhalb des MTS-Laufzeitumgebung läuft und eine Komponente innerhalb MTS aufruft. In einer 3-tier-Architektur ist dies typischerweise ein Presentation Layer, wie ein Anwendungsformular oder eine Webseite. Der Base Client braucht MTS nicht zu kennen. Er erzeugt ein Objekt, welches innerhalb des MTS-Prozesses existiert. Die nachfolgende Tabelle beschreibt die Unterschiede zwischen dem Base Client und einer MTS-Komponente.
| Base Client | MTS Komponente |
|---|---|
|
Kann ein EXE, DLL sein |
Muss eine InProc DLL sein |
|
MTS verwaltet ihren Prozess nicht |
Verwaltet Serverprozesse, dieMTS Komponenten enthalten |
|
MTS erzeugt und verwaltet keine Threads, die von der Anwendung verwendet werden |
Erzeugt und verwaltet Threads |
|
Hat kein Kontextobjekt |
Jedes MTS-Objekt hat sein eigenes Kontextobjekt |
|
Kann keine Resource Dispenser verwenden |
Kann Resource Dispenser verwenden |
Dies ist die Fähigkeit eines MTS-Objekts nur dann aktiviert zu werden, wenn es benötigt wird, um Anfragen von dem Client zu bearbeiten. Die meisten VFP Entwickler sind vertraut mit der Instanzierung eines Objektes.
myObject = CREATEOBJECT(“myclass”)
myObject.myMethod()
myObject.myProperty = 123
RELEASE myObject
Der obenstehende Code beschreibt ein Objekt, welches einen Zustand hat. Das Objekt behält während seiner gesamten Lebenszeit seinen Zustand. Dies bedeutet, daß die Werte der Eigenschaften (wie 'myProperty') während der gesamten Ausführung beibehalten werden. Erst wenn das Objekt schließlich zerstört wird, werden alle Objektreferenzen und der Zustand ebenfalls gelöscht.
Bei jeder neuen Erzeugung einer Objektinstanz, allokiert VFP eine bestimmte Menge von Speicher. Weiterhin wird bei der ersten Objekterzeugung eine geringe Zeitspanne zum Laden der Laufzeitbibliotheken benötigt. Wenn die letzte Instanz aus dem Speicher entfernt ist, wird die komplette VFP-Laufzeitbibliothek ebenfalls entfernt.
JIT-Activation verbessert viele der oben angesprochenen Punkte, welche die Performanz einer Anwendung beeinflussen. Zunächst werden die Laufzeitbibliotheken des Servers im Speicher gehalten, auch wenn keine Referenz auf ein Objekt vorliegt, daß diese benutzt. Beim ersten Aufruf eines VFP-Komponente unter MTS-Verwaltung werden die VFP-Laufzeitbibliotheken in den Speicherbereich von MTS geladen. Man kann diese Einstellung in den Eigenschaften des jeweiligen Pakets ändern.(Standardwert = 3 Minuten). Dies verhindert, daß die VFP-Laufzeitbibliotheken sofort entladen werden, wenn der Instanzenzähler auf 0 steht.
Der Hauptvorteil von JIT Activation ist das Überführen von Objekten von einem Zustand in einen zustandslosen Modus. Wenn man sich obige Beispiel betrachtet, kann man ein zustandsloses Objekt als ein Objekt mit seinen Standardwerten vorstellen. Aus diesem Grunde würde der Wert von 'myProperty' zu ihrem Standardwert zurückgesetzt. Ein zustandsloses Objekt wird von MTS verwaltet und verbraucht nur sehr wenig Speicherplatz. Das zustandslose Objekt wird nur von der Objektreferenz des Clients am Leben erhalten. MTS benützt die Threads, die von dem zustandslosen Objekt benützt wurden, wieder für andere Objekte, die gerade aktiv sind. Sobald wieder eine Methode eines zustandslosen Objekts aufgerufen wird, erhält es wieder ein Zustand und wird einem Thread zugewiesen.
Die Objekte in einen zustandslosen Modus zu versetzen, kann man über das Kontextobjekt erreichen. Der nachfolgende Beispiel, zeigt wie ein Objekt in einen zustandslosen Modus versetzt wird.
#DEFINE MTX_CLASS "MTxAS.AppServer.1"
LOCAL loMTX, loContext
loMtx = CREATEOBJECT(MTX_CLASS)
loContext = loMtx.GetObjectContext()
loContext.SetComplete()
Dieser Code wird von Methode innerhalb des VFP COM-Servers aufgerufen. Man kann überprüfen, ob das Objekt zustandslos ist, indem man den MTS Explorer startet und den Status der Komponente überprüft. Eine zustandslose Komponente wird in der Spalte 'Objects' angezeigt, aber nicht in den Spalten 'Activated' oder 'In Call'.
Um ein Objekt in ein zustandslosen Modius zu versetzen, benutzt man die SetComplete()-Methode. SetComplete() wird ebenfalls dafür benutzt, um eine Transaktion erfolgreich zu beenden. Man kann ebenso die SetAbort()-Methode benutzen, um ein Objekt zustandslos zu machen.
Wenn ein Objekt zustandslos wird, werden alle Eigenschaften auf Ihren Standardwert zurückgesetzt. Wenn eine Methode oder eine Eigenschaft (ACCESS oder ASSIGN-Methode) dieser Komponente aufgerufen wird, erhält das Objekt wieder einen Zustand. Zu diesem Zeitpunkt wird auch wieder das Init-Ereignis des Objektes ausgeführt. SetComplete() (SetAbort()) löst das Destroy-Ereignis des Objektes aus. Daraus ergeben sich einige wichtige Betrachtungen :
· Jeglicher Zustand eines Objektes geht verloren, wenn das Objekt deaktiviert wird (zustandslos wird). Falls es nötig ist, Daten persistent zu halten, müssen diese entweder in einer Datenbank abgespeichert werden oder man benutzt den MTS Shared Property Manager.
· Da das Init-Ereignis bei jeder Aktivierung des Objekts ausgelöst wird, sollte dort möglichst wenig Code ausgeführt werden.
Hier ist ein einfaches Scenario, welches die Interaktion zwischen dem Client und einer MTS-Komponente veranschaulicht :
VFP Server Code:
DEFINE CLASS mts2 AS Custom OLEPUBLIC
MyColor = "Green”
PROCEDURE InUsa (tcCustID)
LOCAL llInUSA, loMTX, loContext
loMtx = CreateObject("MTXAS.APPSERVER.1")
loContext = loMtx.GetObjectContext()
llInUSA = .F.
USE customer AGAIN SHARED
LOCATE FOR UPPER(cust_id) == UPPER(tcCustID)
IF FOUND()
llInUSA = (ATC("USA", country) != 0)
ENDIF
loContext.SetComplete()
RETURN llInUSA
ENDPROC
ENDDEFINE
Base Client führt den folgenden Code aus:
LOCAL loCust, lcCust, llUsa
loCust = CREATEOBJECT("vfp_mts.mts2")
? loCust.MyColor
Green
loCust.MyColor = “Red”
? loCust.MyColor
Red
lcCust = “JONES”
llUsa = loCust.InUsa(lcCust) && Objekt wird zustandslos (deaktiviert)
? loCust.MyColor && object is aktiviert (hat Zustand)
Green
RELEASE loCust && Objekt ist zerstört
In dem obigen Beispiel, wird 'loCust' zustandslos, nachdem 'InUsa'-Methode aufgerufen wird. Die Eigenschaft 'MyColor' gibt nicht mehr 'Red' zurück, sondern den Originalwert 'Green'.
VFP selbst unterstützt auch Transaktionen. Die Verwaltung von Transaktionen ist eine der Kernaufgaben des MTS. MTS bietet die Möglichkeit in Zusammenarbeit mit dem MS DTC verteilte Transaktionen zu verwalten. Transaktionen werden oft mit dem ACID-Prinzip im Zusammenhang gebracht.
| Atomicity | Entweder die komplette Transaction findet statt oder nichts |
| Consistency | Eine Transaktion stellt eine korrekte Änderung des Systemstatus dar |
| Isolation | Schützt unterschiedliche Transaktionen, davor daß sie nicht-durchgeführt oder partielle Resultate sehen |
| Durability | Bereits durchgeführte Aktualisierungen überleben Fehlsituationen |
Die Transaktionsunterstützung von MTS ist nicht kompatibel mit VFP Daten. Sie arbeitet nur mit Datenquellen zusammen, die folgende Protkolle unterstützen :
OLE Transaktionen SQL SERVER, MSMQ
X/Open XA(eXtended Architecture) ORACLE, (INFORMIX)
LU 6.2 Sync Level 2 COM TI für CICS und IMS
Hier ein Beispiel für das Verständnis von Transaktionen :