Transcript Robuste und flexible Kommunikation in verteilten Anwendungen Ralf Westphal MSDN Regional Director, freier Autor & Berater [email protected].

Robuste und flexible Kommunikation in verteilten Anwendungen
Ralf Westphal
MSDN Regional Director, freier Autor &
Berater
[email protected]
Kennen Sie das...
Software P
Software Q
Crash!
Komponente K2
K1
Typische Szenarien

Zwei Anwendungen benutzen dieselbe Komponente
•
•
•

Anwendung P erwartet Version 1, der Komponente,
Anwendung Q Version 2
Bei der Installation überschreibt die neue/alte Version der
Komponente die vorher schon auf dem System
vorhandene
Eine der Anwendungen stürzt beim nächsten Start ab
Eine Anwendung ist bei sehr vielen Clients
installiert und greift auf eine Server-Komponente zu
•
•
Die Server-Komponente wird ersetzt
Clients stürzen ab
•
Bei genügend großen System ist es nicht möglich, veränderte
Clients gleichzeitig mit einer neuen Server-Komponente zu
verteilen
Die Interface-Versionshölle

Client und Server (Komponente) werden getrennt
gepflegt
•
•
•

Clients arbeiten nicht mit neuen Server-Versionen
zusammen
•
•

Wenig Kontrolle über Zeitpunkt des Deployment
Komponentenhersteller kennen nicht alle Clients
Die Zahl der Clients ist zu groß für ein Deployment neuer
Clients in Nullzeit
Server-Schnittstelle wurde verändert
Client erwartet alte Server-Schnittstelle
Interface-Versionshölle
•
Microsoft nennt es plattformbezogener die DLL-Hölle
Symptomkuren

Minuziöse Interface-Verwaltung
•
•



Microsoft Windows: Interfaces „von Hand“ in Typelibs
pflegen
Nach Deployment Interfaces nicht mehr ändern!
•
Bei Änderungen komplett neue Interfaces anlegen
Versionskontrollwerkzeuge
•
•
Microsoft Windows: z.B. Versionstamper von Desaware
Installationswerkzeuge mit Versionskontrolle einsetzen
Microsoft Windows: Windows Installer
•
Side-by-side Components
Microsoft .NET
•
•
Private Assemblies
Shared Assemblies mit Versionsnummern
Strong Typing als Grundproblem

Strenge Typisierung
• Methodensignaturen
• Zugriff auf Parameter über Position auf dem Stack
•
(Reihenfolge in Signatur)
Erwartung über die Byteanzahl von Parametern
• Interfaces
• Position von Methoden in einem Interface bestimmt deren
„Adresse“ (z.B. Position in vtable)

Streng Typisierte Interfaces sind „zerbrechlich“
(the brittle interface problem)
• Hohe Performance
• Relativiert sich in verteilten Architekturen
• Kompatibilitätsprüfung zur Übersetzungszeit
• Trügerische Sicherheit in verteilten Architekturen
Strong Tagging

Zugriff auf Parameter per Name (Tag)
•
•
Reihenfolge/Position unerheblich
•
•
Übergabe von Parametern in einer
Container-Datenstruktur
•
•

Einigung auf Name zwingend
Stellung von Parametern in einer Hierarchie muss
konstant bleiben
Collection, PropertyBag, Recordset
XML
Verzicht auf „physikalische“ Typen
•
Empfänger führt Typwandlung explizit durch
•
Container-Datenstruktur kann jedoch auch Typen
bewahren
Vorteile I

Strong Tagging unterstützt die InterfaceEvolution
•
•
•
•
Hinzufügen von Parametern
•
Optionale Parameter erhalten Default-Werte

Defaults können dynamisch bestimmt werden
Wegfall von Parametern
•
„Überzählige“ Parameter werden ignoriert
Positionsänderung von Parametern
•
Zugriff erfolgt per Parametername
Typänderungen
•
Tolerant gegenüber „Typweitungen“ (Integer  String)
Vorteile II

Strong Tagging vergrößert und flexibilisiert die Kontrolle in der
Businesslogik
•
•
•
•
•
Fehlerbehandlung
•
Individuelle Reaktion auf Fehler möglich
Zentraler Eintrittspunkt in Komponente
•
•
Alle Komponentenaufrufe können über eine Methode als Eintrittspunkt
abgewickelt werden
Beliebige Abstufungen in der Granularität der Methoden möglich
Zugriffs-/Transaktionskontrolle
•
Kontrolle kann so fein-granular wie gewünscht ausgeübt werden (z.B.
in Abhängigkeit von Methode, Parameterwert/-konstellation, Benutzer,
Tageszeit usw.)
Parameter Routing
•
Parameter können verteilt oder an tieferliegende Schichten
weitergeleitet werden
Logging
•
Automatisches Logging von Parameterkonstellationen in besonderen
Fällen inkl. Benachrichtigung des Admin
Nachteile

Keine Interface-Konformitätsprüfung zur
Übersetzungszeit
•
•


Hat in verteilten Architekturen nur begrenzten Wert
Kann durch Wrapper-Klassen z.T. umgangen werden
Geringere Performance
•
•
Abhängig von Container-Datenstruktur
Relativiert sich, je stärker Client und Server von einander
getrennt sind
Größeres Datentransfervolumen
•
•
•
Abhängig von Container-Datenstruktur
Relativiert sich mit steigender Bandbreite
Wird z.T. durch „spärlich gefüllte“ Parameterlisten wett
gemacht
Demos I

Selbstbau eines Strong Tagging
Containers
•
PropertyBag
Strong Tagging und XML

XML-Formate als ideale „Container“
•
•
•
•

Plattformunabhängig
•
Unterstützt über Schema-Sprache skalare Typen
Kann beliebig komplexe Strukturen formulieren
Bietet DOM als universelle Datenstruktur
Einfacher Zugriff auch auf einzelne Parameter mit XPath
SOAP?
•
•
Nicht überall wo XML drauf steht ist auch Strong Tagging
drin
SOAP wurde im Hinblick auf streng typisierte Interfaces
entwickelt
•
Letztlich hängt die Position von SOAP bzgl. Strong Tagging
aber vom konkreten Gebrauch ab

Microsoft .NET: Strong Tagging mit SOAP Extensions
möglich
XML-Grundszenario
Dim s as String
s = "<params>"
s = s & "<name>Peter</name>"
s = s & "<gebDat>31.5.1966</gebDat>"
s = s & "<groesse>1,82</groesse>"
s = s & "</params>"
PersonAnlegen s
Sub PersonAnlegen(Byval sXML as String)
Dim xml as new MSXML.DOMDocument
xml.loadXML sXML
Dim rs as new ADODB.Recordset
...
rs!dob = DateValue(xml.documentElement.selectSingleNode("gebDat").Text)
...
End Sub
Demos II

Strong Tagging mit einem XMLbasierten Container
•
•
COM/DCOM
HTTP/ASP
Wrapper-Klassen I
Client
Client-Klasse
Function PersonAnlagen(Byval name as String, ...) as String
Sub PersonLöschen(Byval id as String)
Sub PersonÄndern(Byval id as String, Byval name as String, ...)
Sub FamilienstandÄndern(Byval id as String, Byval fStand as Integer)
Wrapper-Klasse
XML
ServerKomponente
Function Execute(Byval cmdXML as String) as String
Wrapper-Klassen II

Verbergen der Strong TaggingKommunikation
•
Bieten lokales streng typisiertes
Interface
•
•
•
Setzen Parameter um in ContainerDatenstruktur
Unterstützen IntelliSense durch
ausführliche Methodensignaturen
Werden zusammen mit Client gepflegt
•
Nachführung bei Interfaceänderungen
nicht sofort zwingend!
XML-Repositorys

Zentrale Sammelstelle für XML-Datenstrukturen
•
•
Komponenten können Schemas zur
Laufzeitvalidation von XML-Datenstrukturen laden
Annotation von Schemas
Zugriffsrechte

Transaktionsattribute

Log-Informationen

usw.
Deklarative Kontrolle von Strong Tagging-Aufrufen

Tiefergeschachtelte Server-Komponenten/-Methoden
müssen nicht verändert werden, wenn sich
Kontrollinformationen ändern

•
Demos III

Feingranulare Kontrolle in einer Strong
Tagging Server-Komponente
•
Transaktionen auf Methodenebene
Strong Tagging in der Praxis

Strong Tagging ist kein rein theoretisches
Konzept, sondern praxiserprobt
•
•
•
•

Windows 2000 DNA
Microsoft Site Server Commerce Edition
Brokat Twister
OpenX-Framework der Hamburger Verwaltung
Bisher jedoch kein breit anerkanntes
„Design Pattern“
•
•
Komponentenbasierte Entwicklung und verteilte
Anwendungen sind vergleichsweise neu
Die Strong Typing-Lobby ist zu stark
Bsp. Windows 2000 DNA

Einsatz von Recordsets als ContainerDatenstruktur
•
•
•
•
Kommunikation zwischen Businesslogik
und Frontend/Objektmodell
Persistierbare Datenstruktur
Transport von Datenbankinhalten
•
2-dimensionale Datenstruktur
Transport beliebiger, benannter und
typisierter Daten
Bsp. Commerce Server

Scriptor-Komponenten
•
•
Order Processing Pipeline (OPP)
Nur eine Verarbeitungsmethode
•
Dictionary als Container-Datenstruktur
Function MSCSExecute(config as Dictionary,
orderForm as Dictionary,
context as Dictionary, flags) as Long
•
Jede Komponente hat auf die für sie
relevanten Parameter Zugriff, unabängig
davon, wo sie in der Pipeline eingesetzt wird
Bsp. Brokat Twister I

Die e-Services Plattform Twister ermöglicht
verteilte Anwendungsentwicklung nach dem
Strong Tagging-Konzept
•
•
•

Einheitliche Methodensignatur für verteilte Objekte
(RDOs)
Jeweils einen Datenpool für Eingabe- bzw. AusgabeParameter mit beliebiger Parameteranzahl
Transport einzelner Parameter Key/Value-Paare über
sog. BAnythingPool-Container
Erfolgreicher Einsatz in zahlreichen e-Business
Anwendungen seit mehr als 5 Jahren
•
•
•
e-Banking (ABN Amro, first-e, Advance Bank, ...)
e-Brokerage (Consors, Allianz, ...)
e-Commerce (Postfinance,Telecash, … )
Bsp. Brokat Twister II

Maximale Entkopplung von server- und clientseitiger
Entwicklung
•
•
•
•

Kein Generieren, Compilieren und Verteilen von
objektspezifischen Stubs
Clients können dynamisch auf die gesamte zur Verfügung
stehende Funktionalität zurückgreifen
Variable Parameteranzahl und Überprüfung zur Laufzeit
Transparente Erweiterung von serverseitigen Schnittstellen
Generische Verarbeitung ankommender Requests im
Gateway
•
Umwandlung beliebiger Anfragen und Weiterleitung an
Serverobjekte
BAnythingPool inPool = new BAnythingPool();
BAnythingPool outPool = new BAnythingPool();
inPool.add("ItemID", "TW100021");
rdo.process("order", inPool, outPool);
Bsp. OpenX-Framework I

Framework für verteilte Anwendungen in der
Hamburger Verwaltung
•
•
•
•

Realisierung: BRP GmbH, Hamburg
Ausgerichtet auf Windows NT/2000-Netzwerke
Ab Juni 800 Anwender, später mehrere Tausend
Transport der Parameter in PropertyBag-Objekten
Strong Tagging hat sich in der Praxis bewährt:
• Schnittstellen auf der Server-Seite ändert sich nie
• Die Objekte/Daten sind „routbar“
• Eine späte Bindung mit unterschiedlichen Servern ist einfach
•
•
•
•
möglich
Der Datenverkehr kann aufgezeichnet werden
Es besteht eine zentrale Transaktionsteuerung in nur einer
Routine
Standardisierung bei großen Objekten
Einfache Kommunikation innerhalb von Anwendungsservern
Bsp. OpenX-Framework II
Client
Server
MTS
Frontend
PersonCli
PersonSrv
SQL Server
Person-Objekt
Streng typisierte
Schnittstelle
Aufruf der Execute-Methode
Bsp. OpenX-Framework III
Public Function Execute(ByVal v As Variant) As Variant
Dim p_pb As New PropertyBag, p_objPers As Person
'Fehlerbehandlung und Transaktionscontext setzen
...
p_pb.Contents = v
Select Case p_pb.ReadProperty("oXObject_Name", "")
Case "PERSONCLI"
Set p_objPers = New Person
Select Case p_pb.ReadProperty("oXObject_CMD","")
Case "UPDATE"
With Person
.Contents = p_pb.Contents
.update
Execute = .Contents
Call to Action

Entgehen Sie der Interface-Versionshölle mit Strong
Tagging
•
•
•


Prüfen Sie, wo Strong Tagging Sinn macht in Ihren
Anwendungen
Achten Sie auf die Performance
Wählen Sie XML als persistentes ContainerDatenstrukturformat
Erweitern Sie die Funktionalität Ihrer Businesslogik
•
•
Richten Sie zentrale Eintrittspunkte ein
Profitieren Sie von der feineren Kontrolle über Parameter
Bauen Sie eine Kontroll-Infrastruktur auf
•
•
Benutzen sie XML als Transportformat
Annotieren Sie Ihre XML Schemas mit
Kontrollinformationen
Fragen?
Ressourcen
[And2000] Rick Anderson (Microsoft): The End of DLL Hell;
http://msdn.microsoft.com/library/techart/dlldanger1.htm
[Apple2000] Dan Appleman (Desaware): VersionStamper and DLL Hell - What's really going on here?; http://www.desaware.com/articles/VSBelieveL3.htm
[Brokat] Informationen zu Twister: http://www.brokat.com/de/twister/index.html
[Box2000] Don Box et al.: SOAP: Simple Object Access Protocol;
http://msdn.microsoft.com/workshop/xml/general/soapspec.asp
[Buch1994] Marcellus Buchheit: Die Gestaltung von APIs; BasicPro 3/94, S. 21
[Herz2000] Peter Herzum, Oliver Sims: Business Component Factory; John Wiley &
Sons, Inc. 2000: Peter Herzum führt hier den Begriff “Strong Tagging” ein und
erklärt das “Design Pattern” grundsätzlich.
[Msft2000] Microsoft: Sharing Components – Terminology and Concepts;
http://msdn.microsoft.com/training/offers/WINVBO_BLD/Topics/winvb00873.htm
[Pat2000] Ted Pattison, Brian A Randell (Microsoft): Visual Basic Design Time
Techniques to Prevent Runtime Version Conflicts;
http://www.microsoft.com/msj/0100/versioning/versioning.asp
[Sald1998] Alan Saldanha: Scriptor Component 101: Executing Scripts in a Pipeline Environment; http://msdn.microsoft.com/workshop/server/commerce/scriptor101.asp
[Wong2000] Franky Wong (Desaware): DLL HELL: The inside story;
http://www.desaware.com/articles/dllhellL3.htm