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

Dies bedeutet, dass eine Skalierbarkeit vom Singe User Desktop oder Notebook bis hin zu einer Enterprise Architektur mit ein und derselben Codebasis möglich ist! Die Installation der Benutzer, Middle Tier und Data Tier Ebenen kann für den Benutzer völlig transparent erfolgen.

Im Folgenden wird auf die einzelnen Schichten näher eingegangen. Folgende Grafik soll als Veranschaulichung dienen:

Die Präsentations Schicht

Wie aus obiger Abbildung hervorgeht, kann in der Windows DNA Architektur sowohl aus einer Browser Oberfläche als auch aus einer normalen Windows Anwendung auf die Applikations Logik im Transaction Server zugegriffen werden. An dieser Stelle soll eine Windows Oberfläche mit allen bekannten Eigenschaften einer beliebigen Windows Anwendung verwendet und besprochen werden.

HINWEIS: Wie wir später noch sehen werden, ist obige Grafik bzgl. Webservices, welche via XML auf einem Webserver aktiviert werden, nicht ganz vollständig. Korrekterweise müsste auch aus den Windows Clients, und nicht nur den Browser Clients, ein Zugriff auf den Webserver eingezeichnet werden (SOAP/XML/Webservices)!

In einem Intranet, bei welchem alle Clients mit einer direkten Hochgeschwindigkeits Verbindung mit dem Server verbunden sind, kann die Kommunikation zwischen dem Client und dem Middle Tier Server mittels leistungsfähigen Multi Port Protokollen, wie z.B. DCOM, erfolgen. Dies hat den Vorteil, dass der Benutzer performancemässig nicht merkt, dass er mit einem n-Tier Modell arbeitet. Der gesamte Datenzugriff erfolgt zwar aus der Mittelschicht, der Benutzer arbeitet jedoch in gewohnter Art und Weise mit den Daten.

Mindestens genauso wichtig ist in diesem Zusammenhang der Vorteil, dass beim Einsatz von COM/COM+ aus Entwicklersicht grundsätzlich keine speziellen Vorkehrungen zu treffen sind, da sich die Komponentenentwicklung mit VB direkt in COM/COM+ integriert.

Es zeichnet sich ab, dass in Zukunft die User Interface Schicht vermehrt via XML mit der Middle Tier Schicht kommuniziert. In diesem Szenario wird über das standard HTTP Protokoll über den Port 80 kommuniziert. Siehe auch Ausführungen über SOAP/XML weiter unten!

Die Applikations Logik Schicht

Die Applikationslogik wird in Form von VB Klassen in DLL's gekapselt. Diese DLL's übernehmen den gesamten Datenverarbeitungsteil. Sie sind es, die die Datenbankverbindungen herstellen, Daten lesen und schreiben und an Transaktionen teilnehmen. Diese DLL's werden bei einer Enterprise Architektur im Transaction Server untergebracht, was eine stabile Skalierbarkeit im Mehrbenutzerbetrieb ermöglicht.

Um ein und dieselben DLL's sowohl im Mehrbenutzerbetrieb mit Transaction Server, als auch im Single-User Betrieb auf z.B. einem Desktop PC oder Notebook, verwenden zu können, werden die DLL's so ausgelegt, dass sie kontextsensitiv sind und selber erkennen, ob Sie im Kontext eines Transaction Servers betrieben werden, oder nicht.

Visual Basic stellt eine ausgezeichnete Umgebung bereit, DLL's zu erstellen, welche sowohl auf einem Single User PC als auch in einer Enterprise Architektur unter Transation Server betrieben werden können.

Aus Entwicklersicht ist es von grössten Nutzen, dass ein und dieselben Business Logik dll's für verschiedene Implementations Varianten verwendet werden können. Dies ist gewährleistet, da bei COM/DCOM immer zuerst über die Registry festgestellt wird, wo die entsprechende dll referenziert ist. Erst nach dieser Lesung wird die dll entweder lokal (COM) oder remote (DCOM) ausgeführt.

Die Daten Schicht

Der Daten Tier stellt die notwendigen SQL Resourcen zur Verfügung. Insbesondere werden auch ANSI SQL Stored Procedures implementiert, damit vom Middle Tier ankommende Befehle optimiert abgearbeitet werden können.

Grundsätzlich kann eine beliebige ANSI SQL Datenbank verwendet werden, für welche ADO oder ODBC Treiber existieren. Als Präferenz stellen wir jedoch Microsoft's SQL Server 7.0 hervor, da dieses Produkt in den bei uns eingesetzten Projekten ausgezeichnete Stabilität und Performance bewiesen hat und zusätzlich für den Einsatz auf Standalone PC's und Notebooks eine "abgespeckte Version" Namens MSDE zur Verfügung steht. Ein weiterer Vorteil dieser Plattform stellt das gesamte OLAP Umfeld dar, welches darauf aufgesetzt werden kann.

Wir haben die Installation von MSDE Datenbanken auf Standalone PC's und Notebooks zu 100% automatisiert und in einem MSDE/SE Environment implementiert. Die Installation kann somit direkt ab CD auf jeden beliebigen 32-bit Windows PC erfolgen. Der Speicherbedarf ist harddiskmässig ca. 40 MB und RAM seitig 8 MB.

Der grosse Vorteil liegt auch hier wieder darin, dass man mit ein und derselben Daten Schnittstelle vom Single User PC oder Notebook bis hin zum Enterprise Datenserver arbeiten kann.

Grundsätzlich werden in der Datenschicht zwei verschiedene Methoden angewendet, um Datenverarbeitungslogik zu implementieren. Entweder wird direkt in der dll SQL Syntax geschrieben, oder es wird auf dem Server mit Stored Procedures gearbeitet. Im ersten Fall spricht man auch vom "Embedded SQL" Szenario und im zweiten Fall vom "Stored Procedure" Szenario. Je nachdem, welche Businesslogik zu lösen ist, ist die eine der anderen Methode vorzuziehen. In diesem Zusammenhang ist erwähnenswert, dass beim Embedded SQL Szenario bei einer reinen n-Tier Implementation mit MTS, der SQL Server meint, es kommt immer derselbe Benutzer mit derselben SQL Anweisung (falls mehrere Benutzer dieselbe Business Komponente anwerfen). Dies führt dazu, dass der SQL Server diese Anfrage intern schon längst kompiliert und als interne Stored Procedure abgelegt hat. Das führt natürlich zu drastisch schnelleren Ausführungsgeschwindigkeiten. Dies ist ein krasser Vorteil gegenüber den klassischen Client/Server Anwendungen, wo jeder Benutzer mit einer eigenen Connection auf den Server gelangt, und der Server deshalb für jeden Benutzer die SQL Anfrage erneut kompilieren muss. Das ist auch der Grund, weshalb in einer klassischen Client/Server Architektur, der Einsatz von Stored Procedures einen weit höheren Nutzen bringt.

N-Tier Implementierungs Varianten

N-Tier Entwicklungen werden häufig als ungeeignet angesehen, um kleinere oder mittlere Applikationen zu realisieren. Oftmals steht kein eigener Datenserver oder Middle Tier Server zur Verfügung, um die Daten bzw. die Applikations Schicht zu hosten. Um dennoch mit ein und derselben Software erfolgreich zu sein, ist es wichtig, sich mit den verschiedenen Implementierungs Varianten auseinanderzusetzen.

Damit dies technisch möglich ist, muss auf eine reine Auslegung der DLL's auf die Transaction Server Library verzichtet werden. Transaction Server spezifische Anweisungen wie

Dim ctxtObject As ObjectContext 
Set ctxtObject = GetObjectContext() 
On Error GoTo ErrorHandler 

'some code 
ctxtObject.SetComplete 
Set ctxtObject = Nothing 
Exit Function 

ErrorHandler: 
ctxtObject.SetAbort 
Set ctxtObject = Nothing 
Exit Function

werden nicht in dieser Form verwendet, damit ein Einsatz in einer Transaction Server Less Umgebung (also ohne Vorhandensein der MTXAS.DLL Library) gewährleistet ist.

Stattdessen werden alle Datenbanktransaktionen über eine klassische Transaktionsprogrammierung direkt in den DLL's abgehandelt. Diese Programmiertechnik wird durch die ADO Library ebenfalls explizit unterstützt (oConn.BeginTrans, .CommitTrans, .Rollback). Zudem kann bei Bedarf auch auf dem SQL Server mit T-SQL transaktional gearbeitet werden.

Bei einem Einsatz dieser Komponenten unter einem Transaction Server können trotzdem sofort die Instanziierungs- und Datenzugriffs Pooling Mechanismen verwendet werden. Hierzu sind bei der Erstellung der DLL's unter VB 6.0 keine besonderen Programmierrichtlinen zu berücksichtigen.

WICHTIG: Als Datenbank Anwendungsentwickler und auch als Client/Server Entwickler war es schon immer so, dass man sich um die Datenbanktransaktionen explizit selbst kümmern musste. Um eine grösstmögliche Flexibilität bzgl. der Implementierung der geschriebenen Lösung zu erreichen, ist es unabdingbar, auf den Einsatz der MTXAS.DLL Funktionalität zu verzichten. Weiss man jedoch im Vornherein, dass der Einsatz eines Transaction Servers gegeben ist, kann natürlich auch die Datenbank Transaktionsverarbeitung des Transaction Servers genutzt werden.

Im Folgenden werden die einzelnen Implementierungs Varianten dargestellt:

Variante "Standalone" (Single Tier Replacement)

Hierbei wird auf ein und demselben PC folgendes bereitgestellt

Microsoft Data Engine (MSDE) als lokale Datenbank

• Datenzugriffsmechnismen via ADO/ ODBC
• Middle Tier Komponenten DLL's direkt auf demselben PC registriert
• Applikationsprogramm (Windows FrontEnd)

Diese Variante stellt die Basis für den Einsatz auf einem Notebook oder einem standalone Desktop dar.

Variante "Fat Client" (2 Tier Client/Server Replacement)

Hierbei wird auf einem Datenbankserver im Netz

• Microsoft SQL Server installiert,
• auf den Clients wird folgendes bereitgestellt:
• Datenzugriffsmechnismen via ADO/ ODBC auf die SQL Server Datenbank im Netz
• Middle Tier Komponenten DLL's direkt auf Client registriert
• Applikationsprogramm (Windows FrontEnd)

Diese Variante stellt die Basis für den Einsatz in einem LAN mit vorhandenem SQL Server dar und kann als quasi Ersatz der bewährten Client/Server Infrastruktur betrachtet werden. Die DLL's laufen im Speicher des Clients ab. Jeder Client benötigt ADO/ ODBC Zugriff auf die Datenbank.

Variante "n-Tier mit Transaction Server" (reine n-Tier Architektur)

Hierbei wird auf einem Datenbankserver im Netz

• Microsoft SQL Server installiert,
auf dem Transaction Server werden
• Datenzugriffsmechnismen via ADO/ ODBC, sowie die
• Middle Tier Komponenten DLL's registriert
Auf den Clients wird lediglich das
• Applikationsprogramm (Windows FrontEnd) installiert,
• sowie die Remote Registrierung der DLL's, welche im Transaction Server laufen, vorgenommen.

Diese Variante stellt die ausgewachsene n-Tier Architektur dar, welche sich in einem belasteten LAN ab einer bestimmten Anzahl Benutzer auszahlt. Das "remote Registrieren" der DLL's, welche im Transaction Server laufen, ist eine äusserst einfache Angelegenheit. Der Transaction Server stellt hierzu alle notwendigen Mechanismen zur Verfügung. Auf dem Client muss nur noch auf ein ausführbares Programm auf einem Netzwerkshare geklickt werden, der Rest läuft automatisch ab.

HINWEIS: Unter Settings/ Control Panel/ Add/Remove Programs sind die remote registrierten DLL's als sog. "remote applications" sichtbar. Eine Hantiererei mit dcomcnfg erübrigt sich. Die Remote Registrierung steht ebenfalls in der Registry.

Bei dieser Variante kommt das Instanziierungs- und Connection Pooling des Transaction Servers voll zum Tragen und der Client betreibt als quasi "Thin-Client" lediglich die Benutzerschnittstelle. Die Business Komponenten laufen direkt im Speicher des Transaction Servers ab. Die Clients benötigen keine Datenzugriffe auf die Datenbank.

Folgende Tabelle beschreibt die verschiedenen Implementierungsvarianten im Fall dass die Client Anwendung eine "Rich User Interface" Windows Anwendung ist:

Folgende Tabelle illustriert die Kommunikation zwischen den verschiedenen Schichten.
 

Skalierbarkeit von n-Tier Anwendungen

Skalierbarkeit von n-Tier Anwendungen ist ein sehr, sehr wichtiger Punkt, weshalb hier auch speziell darauf eingegangen wird.

Eine n-Tier Anwendung skaliert nicht automatisch und ohne Zutun des Entwicklers optimal. Die Idee, bei Bedarf mehr Rechenleistung zur Verfügung zu haben, ist bestechend, doch möchte ich am Beispiel eines Bankschalters erläutern, worauf es beim Erstellen von skalierbaren n-Tier Anwendungen tatsächlich ankommt. Im Anschluss zeige ich, wie beim Erstellen einer ASP Anwendung diesem Gedanken nachgelebt werden kann und eine hohe Skalierbarkeit erzielt werden kann.

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