[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]  

Skalierbarkeit am Beispiel eines Bankbesuchs

Wenn ein Bankkunde an einen beliebigen Bankschalter gelangt, wird er sich zunächst ausweisen, und auf seinem Konto eine Transaktion in Auftrag geben. Verlässt der Kunde die Bank und kommt 10 Minuten später wieder zurück, so wird er sich vorteilhafterweise an den Bankschalter mit der kürzesten Schlange wenden. Dies ist ein instinktiver Vorgang und erfolgt natürlich in der Hoffnung, rascher seinen neuen Auftrag aufgeben zu können.

Ist er an der Reihe, so muss sich der Kunde erneut ausweisen und seinen neuen Auftrag aufgeben. Der Bankmitarbeiter an diesem Schalter weiss nichts von einem Besuch dieses Kunden vor 10 Minuten. Obwohl der Kunde sich dies vielleicht wünscht, weil sein zweiter Auftrag mit dem ersten in einem bestimmten Zusammenhang steht, muss er sich wieder von neuem authentisieren und alle benötigten Informationen der Bankmitarbeiterin übergeben.

Würde man diesen Sachverhalt als nicht skalierbare Anwendung betrachten, so würde der Kunde gezwungen sein, auch beim zweiten Besuch unbedingt am demselben Schalter, den er beim ersten Besuch angegangen ist, anzustehen. Dies egal, wieviel Leute dort gerade anstehen. Dies wäre natürlich ein völlig unnatürliches Vorgehen.

Nur wenn unsere Software nach dem "Stateless" Prinzip arbeitet, sind wir in der Lage zuzulassen, dass der Kunde an einen x-beliebigen Schalter geht und jedes Geschäft individuell mit allen dazu notwendigen Informationen in Auftrag gibt. Dies kann sogar soweit führen, dass der Kunde nicht nur den Bankschalter (Appartment Thread) sondern auch die Bank frei wählen kann. Auf diese Weise haben wir eine Skalierbarkeit erreicht, die nichts zu wünschen übrig lässt.

Skalierbarkeit bei ASP Anwendungen

Die oben beschriebene Problematik lässt sich nicht nur auf die Entwicklung reiner Middle Tier Komponenten applizieren, sondern auch sehr schön am Beispiel einer Active Server Page Anwendung mit Paging anwenden.

Wenn ein Benutzer für eine Datenbankabfrage auf einer Suchseite seine Suchkriterien eingibt, kann es durchaus sein, dass mehrere Datensätze seiner Suche entsprechen und er durch dieses gesamte Resultateset "navigieren" möchte, um sich die einzelnen Datensätze anzusehen.

Der Benutzer navigiert in folgender Form durch den Resultatrecordset:

Der Paging Mechanismus ist nun entscheidend: Man könnte versucht sein, den Recordset mit den im obigen Beispiel "131" Datensätzen auf dem Server in einer Session Variablen für diese Session zu speichern. Dies ist auf den ersten Anblick durchaus praktisch, die Lösung skaliert aber nicht! Der Grund liegt darin, dass auf diese Weise der Server gezwungen ist, einen Kontext mit einer komplexen Binärreferenz (Recordset!) aufrecht zu erhalten, was dazu führt, dass beim Wunsch, dass der Benutzer auf "Seite 2 von 14" wechseln möchte, zwangsweise auf die bestehende Referenz (State) Rücksicht genommen werden muss. In unserem Bankbeispiel von oben würde das bedeuten, dass wir gewungen wären, wieder an denselben Bankschalter zu gehen, unabhängig davon, wieviele Leute dort gerade anstehen und dies obwohl andere Bankschalter gerade frei wären.

Um dieses Problem zu lösen muss in der Stateless Programmierung darauf geachtet werden, dass bei jedem "Bankbesuch" erneut alle Informationen angegeben werden, um von Neuem eine Datenbankabfrage und eine Positionierung im Recordset vorzunehmen. Die Informationen, welche jedesmal von Neuem zu übergeben sind, sind direkt im "href" (Hyperlink Definition im HTML) des entsprechenden Links gespeichert: Das ist auch der Grund, weshalb z.B. bei Suchabfragen im Internet die URL Zeile immer monströsere Längen annimmt!

In unserem obigen Beispiel ist im "href" des "gehe auf nächste Seite" Links folgendes vermerkt:

http://publisher.devigus.com/address_search_result.asp?lastname=de&firstname=&zip=&city=&tnPage=2

Alternativ dazu könnte man die Suchkriterien und die aktuelle Seite natürlich auch in "Hidden Fields" abspeichern. Das Prinzip bleibt sich aber das selbe.

SESSION: Ich werde in der Session diese skalierbare Paging Lösung detailliert vorstellen.

Skalierbarkeit bei COM Komponenten

Die Skalierbarkeit bei COM Komponenten beim Datenbezug muss auf dieselbe Art und Weise sichergestellt werden. Jeder einzelne COM Aufruf muss von sich aus alles beinhalten, was die Komponente zum Abarbeiten des Auftrages benötigt. Es darf grundsätzlich nicht davon ausgegangen werden, dass ein State aus einer früheren Anfrage aufrecht erhalten wird.

Beim Beziehen von Daten in Form von Recordsets bedeutet dies, dass Daten natürlich nicht als Referenz, sondern immer effektiv als sogenannte "Disconnected Recordsets", über das Netz geschickt werden. Der konkrete Ablauf sieht hierbei prinzipiell wie folgt aus.

• Client instanziiert die Server Komponente. Aus der Registry ergibt sich, dass es sich um eine Remote Registrierung handelt und die dll auf dem Transaction Server vorhanden ist
• Der Aufruf der Server Komponente erfolgt mit allen erforderlichen Parametern, welche die Komponente benötigt, um den Auftrag auszuführen
• Die Server Komponente stellt eine neue Verbindung zum Data Tier her und setzt entweder via Embedded SQL oder via einem Stored Procedure Aufruf den Datenbefehl ab
• Der erhaltene Recordset wird dem Client zurückgegeben und die Server Komponente schliesst den Recordset und die Verbindung zum Server

SESSION: Ich werde in der Session auf die Implementations Details dieses skalierbaren Ansatzes eingehen und genau erläutern wie das effektive Marshalling der Daten erfolgt.

Beispiel einer n-Tier Anwendung

Das präsentierte Beispiel ist eine reale Anwendung aus einer von uns entwickelten Anwendung für die Agrochemie Branche. In dieser Anwendung, welche vom Benutzer als ganz normale Windows Anwendung wahrgenommen wird, werden weltweit Märkte und Produkte geplant. Die Implementation kann wahlweise in einer der weiter oben beschriebenen Varianten erfolgen. Alle Business Komponenten sind "stateless" implementiert um eine maximale Skalierbarkeit zu erzielen.

Anwendungsbeispiel 1

Hier wird gezeigt, wie für eine bestimmte Selektion die Daten, welche für den Marketing Plan im Treeview benötigt werden, bezogen werden. Dieses Anwendungsbeispiel verwendet auf dem Data Tier eine Stored Procedure. Aus der Mittelschicht wird über das ADO Command Objekt gearbeitet.

Anwendungsbeispiel 2

Hier wird gezeigt, wie für ein bestimmtes Form aus der Benutzeroberfläche heraus eine Methode aus der Mittelschicht aufgerufen wird. Diese verwendet embedded SQL um die Daten zu beziehen. Die bezogenen Daten werden in diesem Beispiel dazu verwendet, eine Combobox in der Benutzeroberfläche zu populieren.

Anwendungsbeispiel 3

In diesem Beispiel wird ein Datenbezug für eine einzelne Dateneingabemaske beschrieben. Es wird detailliert darauf eingegangen, wie die bezogenen Daten in einem Array "aAllData" für alle Tabs abgespeichert und zur Präsentation verwendet werden.

Anwendungsbeispiel 4

Hier wird in Anlehnung an Beispiel 3 aufgezeigt, wie die vom Benutzer veränderten Daten abgespeichert werden. Hierbei werden die Daten als Array an die Business Komponente übergeben.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ]