Robuste und flexible Kommuni-kation in verteilten Anwendungen Ralf Westphal MSDN Regional Director, freier Autor & Berater ralfw@ralfw.de

Interface-Versionskonflikt Kennen Sie das... Interface-Versionskonflikt Software P Software Q Crash! Komponente K1 Komponente K2

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 Versionskontrollwerkzeuge 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 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“ SOAP? 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

Function Execute(Byval cmdXML as String) as String 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 Function Execute(Byval cmdXML as String) as String Server- Komponente

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 Client Server MTS Frontend SQL Server PersonCli PersonSrv Streng typisierte Schnittstelle Aufruf der Execute-Methode Person-Objekt

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 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 .