Robuste und flexible Kommuni- kation in verteilten Anwendungen Ralf Westphal MSDN Regional Director,...
-
Upload
kunigunde-radder -
Category
Documents
-
view
106 -
download
0
Transcript of Robuste und flexible Kommuni- kation in verteilten Anwendungen Ralf Westphal MSDN Regional Director,...
Robuste und flexible Kommuni-kation in verteilten Anwendungen
Ralf WestphalMSDN Regional Director, freier Autor & Berater
Kennen Sie das...
Software P
Software Q
Komponente K1Komponente K2
Crash!
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• 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
Clients arbeiten nicht mit neuen Server-Versionen zusammen• 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
• Einigung auf Name zwingend
• Stellung von Parametern in einer Hierarchie muss konstant bleiben
• Übergabe von Parametern in einer Container-Datenstruktur• 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 Interface-Evolution• 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 XML-basierten Container
• COM/DCOM
• HTTP/ASP
Wrapper-Klassen I
Client-Klasse
Wrapper-Klasse
Server-KomponenteXML
Function Execute(Byval cmdXML as String) as String
Function PersonAnlagen(Byval name as String, ...) as StringSub 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)
Client
Wrapper-Klassen II
Verbergen der Strong Tagging-Kommunikation
• Bieten lokales streng typisiertes Interface• Setzen Parameter um in Container-
Datenstruktur
• 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 Container-Datenstruktur
• 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. Ausgabe-Parameter 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
PersonSrvPersonCli SQL ServerFrontend
ServerClient
MTS
Person-Objekt
Aufruf der Execute-MethodeStreng typisierte Schnittstelle
Bsp. OpenX-Framework III
Public Function Execute(ByVal v As Variant) As VariantDim 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 Container-Datenstrukturformat
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 go-ing 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 Envi-ronment; 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