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

Session D-STUD

Flexible n-Tier-Applikations
Entwicklung mit Visual Studio

Arturo Devigus
Devigus Engineering


Zusammenfassung

Als VFP Entwickler ist man in der Microsoft Umgebung vermehrt damit konfrontiert, mit verschiedenen Programmiersprachen und Tools zu Arbeiten. Wir haben eine umfassende und flexible n-Tier Entwicklungsumgebung unter Visual Studio aufgebaut. Diese n-Tier Entwicklungsumgebung basiert auf einem VB Windows User Interface (ganz im Stil von Outlook), aus welchem via DCOM/ SOAP (XML) mit der Mittelschicht kommuniziert wird. Einzig die Mittelschicht kommuniziert mit der Datenschicht und liefert die angeforderten Daten oder Zustände zurück. Unser n-Tier Framework erlaubt es, die Mittelschicht DLL's wahlweise unter dem Transaction Server (klassische "n-Tier" Implementation) oder auch auf dem Client ("Fat Client" Implementation) einzusetzen. Durch den Einsatz der Microsoft Data Engine (MSDE) kann sogar eine Notebook Implementation (quasi eine "Single Tier" Implementation) realisiert werden, indem neben den Business DLL's auch die Datenservices auf ein und derselben Maschine laufen. Auf diese Weise kann die eigene Anwendung, einmal geschrieben, vom Notebook bis hin zur Server Farm beliebig skaliert werden. In dieser Session lernen Sie alles über unser Framework, und wie wir diese Flexibilisierung realisiert haben. Als Alternative zu DCOM wird auch eine mit dem SOAP Toolkit erstellte Applikation vorgestellt. Hier wird aufgezeigt, wie mit Hilfe dieses Toolkits XML als Kommunikationsmedium verwendet werden kann und somit das HTTP Protokoll als Verbindung vom Benutzer Tier zur Middle Tier völlig ausreicht. Diese Session eignet sich unter anderem ganz besonders für diejenigen, welche Ihr VB Wissen gezielt erweitern möchten und eine objektive Gegenübertstellung VB/VFP schätzen um die Entwicklungen rund um das kommende Visual Studio.Net besser einschätzen zu können. VB Wissen ist für diese Session von Vorteil, aber nicht Bedingung.

Software Architektur von n-Tier Anwendungen

Es gibt verschiedene Implementationsvarianten bei Mehrschichten Modellen. Im folgenden wird auf die gebräuchlichsten eingegangen. Dies ist insofern nützlich, als dass man die Vor- und Nachteile der verschiedenen Modelle besser verstehen kann und somit auch die Positionierung der eigenen Mehrschichten Anwendungen professioneller vornehmen kann.

Als erste Variante wird die klassische 2 Schichten Client/Server Architektur besprochen:

Bei einer Vielzahl von Benutzern, mehreren Datenbanken und unsicheren Netzwerkverbindungen stellt diese Lösung nicht die optimale Infrastruktur zur Verfügung:

  • Jeder Benutzer hat eine eigene Verbindung zur Datenschicht. Datenverbindungen binden Resourcen und reduzieren die Performance bei steigender Anzahl Benutzer
  • Ohne Deadlock Detection sind klassische, transaktionale Sperrmechanismen zu implementieren, um eine ausreichende Sicherheit zu erzielen
  • Ausserhalb trusted LAN Verbindungen ist es schwierig, die Sicherheit des Datenzugriffs zu gewährleisten. Ist einmal eine Datenbank für einen Benutzer offen, so kann er auf Datenebene leicht unerwünschte Befehle absetzen
  • Die Wiederverwendbarkeit des einmal geschriebenen Codes ist nicht ohne weiteres möglich, da der Code typischerweise auf bestehende und spezifische Daten explizit zugreift. "Copy and Paste" ist der Normalfall von Wiederverwendung in einem solchen Szenario
  • Klasssche Client Server Systeme können nur ein Datenbanksystem gleichzeitig verwenden. Miteinbezug von mehreren Datenbanken ist aufwendig zu programmieren
  • WICHTIG: Es werden Daten und nicht Methoden exponiert!

Wegen der in einer Client/Server Umgebung verwendeten Lock Mechanismen (siehe auch meine Sessions zum Thema Client/Server) skalieren Client/Server Architekturen nur bis zu einem gewissen Punkt und degradieren anschliessend rasch. Auch die Installation eines leistungsfähigeren Servers löst das Problem nicht nachhaltig.

Um einige der Einschränkungen der reinen Client/Server Architektur zu umgehen, werden häufig auch sogenannte 2 ½ Schichten Modelle implementiert:

Daten Gateways erlauben es, Daten, welche auf anderen Systemen und Datenbanken liegen, aus ein und derselben Datenbank heraus anzusprechen. Dies erlaubt es, aus ein und derselben Client/Server Lösung gleichzeitig auch meherere Datenquellen anzusprechen. Nachteile solcher Lösungen sind:

  • Datenbank Verantwortliche müssen einen generellen, unkontrollierten Datenzugriff über eine andere Datenplattform zulassen. Dies führt zu Verantwortlichkeits-Diskussionen und Sicherheitsproblemen.
  • Werden Datenstrukturen angepasst, müssen alle bestehenden Abfragen nochmals getestet werden
  • Wenn die Drittdaten nicht in relationaler Form vorliegen, müssen diese zunächst in relationale Form gebracht werden, was zeitaufwändig ist.

Eine andere Möglichkeit stellen Stored Procedures dar:

Bei dieser sehr häufig verwendeten Implementationsform spricht man auch von 2 ½ Schichten Modellen. Obwohl dieser Ansatz sehr leistungsfähig ist und viele Business Probleme damit vorteilhaft gelöst werden können, stellt dieser Ansatz auch Nachteile dar:

  • Stored Procedures (TSQL, PSQL oder ähnliches) können typischerweise schlecht wiederverwendet werden. Es gibt keine COM Unterstützung, keine Security Integration und auch keine Transaktions Automatismen
  • Stored Procedures von verschiedenen Datenbankherstellern sind völlig inkompatibel zueinander
  • Stored Procedures benötigen wiederum individuelle Datenbank Verbindungen der Clients zum Daten Server. Dies reduziert die Performance bei steigender Benutzerzahl bei immer höher werdendem Systemresourcen Bedarf.

Bei    der    expliziten    n-Tier    Software    Architektur    findet    eine    Trennung    in     die    Schichten

  • Präsentation,
  • Applikations Logik und
  • Daten
  • statt. Man spricht in diesem Zusammenhang auch von Client, Middle Tier Services und Data Services. Die Vorteile einer solchen Software Architektur gegenüber einer 1- (auch Single Tier genannt) bzw. 2-Schichten (auch Client/Server genannt) Architektur sind u.A. folgende:
  • Beste Ausgangsbasis für spätere Ausrichtung auf eine reine Weblösung und somit grösstmögliche Investitionssicherheit
  • Die Mittelschicht verwendet eine gemeinsame Datenverbindung zum Daten Tier. Dies trotz vieler einzelner Client Anfragen. Connection Pooling verbessert zusätzlich das gesamte Performance Verhalten bei starker Belastung.
  • Bessere Skalierbarkeit der gesamten Anwendung und der darin verwendeten Komponenten (Achtung: Stateless!). Ist die eingesetzte Software Stateless implementiert, kann die Skalierbarkeit durch den Einsatz von mehreren Middle Tier Servers weiter erhöht werden.
  • Bessere Wiederverwendbarkeit von einmal geschriebenem Code dank Komponenten Design und objektorientierten Eigenschaften des Source Codes
  • Erhöhte Betriebssicherheit und leistungsfähigere Verwaltung dank modularer Verwaltung in separaten, geschützten und stabilen Schichten (Benutzer Schnittstelle, Transaction Server, SQL Server).
  • WICHTIG: Es werden Methoden und nicht Daten exponiert! Dies erhöht die Betriebssicherheit massiv, da es nur bekannte Datenzugriffe gibt und nicht die Datenbank direkt "geöffnet" wird.

Selbstverständlich bietet eine Ausrichtung auf das Komponentenmodell vor allem eines: Investitionssicherheit. Als beste Ausgangsbasis für eine spätere Ausrichtung auf eine Weblösung ist man für spätere Entwicklungen im Internet bestens gerüstet.

Aus technischer Sicht ergeben sich folgende Stärken einer Windows DNA n-Tier Architektur:

  • Entwicklung der Komponenten kann z.B. mit Microsoft Visual Basic 6.0 erfolgen, der Datenzugriff mit ADO (ActiveX Data Objects)
  • Falls die Belastung dies erfordern würde, kann die Applikation optional auf mehr als einem Middle Tier Transaction Server betrieben werden (Stateless!)
  • Nur die Applikations Komponenten greifen auf die Daten zu und die Datenbank Verbindungen können somit optimiert werden. Nicht jeder Client benötigt einen direkten Zugriff auf die Daten.
  • Die Applikations Komponenten können optional unter Microsoft Transaction Server durch ein leistungsfähiges, zentrales Sicherheits Konzept gesichert werden
  • Auch ein Einsatz auf einem Singe-User Notebook durch einfaches Registrieren der verschienenen DLL's auf ein und derselben Maschine ist möglich.
  • Durch das Auslegen auf einen optionalen Einsatz unter einem Transaction Server können dieselben Business Komponenten wahlweise auch beim Client (ohne vorhandenen Transaction Server) direkt eingesetzt werden und somit eine klassische "Fat-Client" oder sogar "Standalone" Installation nachgebildet werden.

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


dFPUG c/o ISYS GmbH

Frankfurter Str. 21 b

 

D-61476 Kronberg

per Fax an:

+49-6173-950904

oder per e-Mail an:

konferenz@dfpug.de

© Texte, Grafiken und Inhalt: ISYS GmbH