Robuste und flexible Kommuni-kation in verteilten Anwendungen

Ralf WestphalMSDN Regional Director, freier Autor & Berater

ralfw@ralfw.de

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