dr. welf löwe und markus noga1 gliederung: teil i - grundlagen 1. einführung –motivation...

Dr. Welf Löwe und Markus Noga 1

Gliederung: Teil I - Grundlagen

1. Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)

2. Industrielle Komponentensysteme der 1. Generation1. CORBA 2. Enterprise JavaBeans3. (D)COM

3. Anpassungen – Daten und Funktion– Interaktion

• Kommunikation• Synchronisation• Protokolle

– Lebendigkeit


Problem

II.1 Anpassungen von Datenformaten


XML

eXtensible Markup Language (XML)Standard des WWW Konsortiums (W3C): http://w3c.orgEntstanden aus SGML/HTMLEntworfen als allgemeines DatenaustauschformatSprache zur Beschreibung von Termen/Bäumen– Eigentlich nichts neues– Funktioniert, weil alle glauben es funktioniert

Erleichtert Zerteilungsaufgaben gegenüber allgemeinen kontextfreien SprachenWohlgeformtes XML Dokument: Klammerung stimmt


XML Beispiel

<treatment> <patient insurer=“1577500”nr=‘0503760072’/> <doctor city =“HD” nr=‘4321’/>

<service> <mkey>1234-A</mkey> <date>2001-01-30</date> <diagnosis>No complications. </diagnosis> </service>

</treatment>


Codierung der Daten

Ist standardisiertLegt jedes Dokument fest– UTF-8 oder -16 (UNICODE)– ISO-8859-1 – ....

Nicht in DTD oder Schema festgelegt– Schnelles Scannen ist nicht trivial

Interne Darstellung DOM


DTD

Document Type Description (DTD)W3C StandardKontextfreie Grammatik zur Definition von XML DokumentstrukturenBasisdatentyp: String (PCDATA)Typkonstruktoren: – Iteration, Sequenz und Alternative – Reguläre strukturierte Inhaltsmodelle – Jedes Element selbst wieder strukturiert (dadurch kontextfrei)

Test auf Konformität von Dokument zu DTD üblicherweise mit validierenden, interpretierenden Zerteilern (Parsern)


DTD Beispiel

<!ELEMENT treatment (patient (doctor|hospital) service+)>

<!ELEMENT patient EMPTY><!ATTLIST patient insurer CDATA “1”

nr CDATA #REQUIRED><!ELEMENT doctor EMPTY>

<!ATTLIST doctor city CDATA #REQUIREDnr CDATA #REQUIRED>

<!ELEMENT hospital EMPTY><!ATTLIST hospital city CDATA #REQUIRED

nr CDATA #REQUIRED><!ELEMENT service (mkey date diagnosis)><!ELEMENT mkey #PCDATA><!ELEMENT date #PCDATA><!ELEMENT diagnosis #PCDATA>


Probleme mit DTDs

Selbst kein XML (unschön, Problem erst bei boot-strapping)Sehr eingeschränktes Typsystem– Keine Basistypen außer String– Keine festen Arrays– Keine Vererbung

Langsame Verarbeitung wegen InterpretationMehrdeutige AbleitungsbäumeSchlechte Integration von Namensräumen


XML Schemas

Selbst XML W3C StandardTypsystem– Übliche Basistypen: String, Integer, ...– Unübliche Basistypen: Date, Time– Einschränkungen darauf möglich– Festen Arrays durch mögliche Einschränkung des

Sequenzenkonstruktors– Kovariante und Kontravariante Vererbung

Integration von Namensräumen

Langsame Verarbeitung wegen InterpretationMehrdeutige Ableitungsbäume


Typen in DTDs und XML Schema

DTD– Typ kein eigenständiges Konzept– Definition eines Elements

• Definiert den zugehörigen Typ• Gültigkeitsbereich ist global

XML Schema– Typ ist eigenständiges Konzept

• Unabhängig von Instanzen• Operationen auf Typen (eine Art von Vererbung)

– Definition eines Elements • Zuweisung eines Typs an einen Namen• Gültigkeitsbereich ist der umgebende Typ


XML Schema – einfache Typen – Beispiel

<simpleType name=‘mkey’ base=‘string’> <pattern value=‘[0-9]+(-[A-Z]+)?’/></simpleType>

<simpleType name=‘insurer’ base=‘integer’> <precision value=‘7’/></simpleType>

<simpleType name=‘myDate’ base=‘date’> <minInclusive value=‘2001-01-01’/> <maxExclusive value=‘2001-04-01’/></simpleType>


XML Schema – komplexe Typen – Beispiel

<complexType name=‘treatment’> <element name=‘patient’ type=‘patient’/>

<choice> <element ref=‘doctor’/> <element ref=‘hospital’/> </choice>

<element ref=‘service’ maxOccurs=‘unbounded’/></complexType>


XML Schema – Attribute – Beispiel

<complexType name=‘patient’ content=‘empty’> <attribute ref =‘insurer’ use=‘required’/>

<attribute name=‘nr’ use=‘required’> <simpleType base=‘integer’> <precision value=‘10’/> </simpleType> </attribute>

<attribute name=‘since’ type=‘myDate’/></complexType>


Namensräume

Problem: Heterogene Systeme– Wieviele Definitionen von z.B. Adresse gibt es?– Wie vermeide ich Probleme beim Zusammenführen?

Ansatz: Einführen von Namensräumen– Name ist Paar (Namensraum, lokaler Name)– International eindeutige Bezeichner für Namensräume

Umsetzung in XML: Mangelhaft– Lange Bezeichner (URI), lokale Platzhalter im Dokument

<ns:ln xmlns:ns=“http://www.noga.de/namespaces/vorlesung”> <ns:xyz/>

</ns:ln> – Gültigkeitsbereich: Element mit Kindern (wie Variable)– Auch Elementname, vorangehende Attribute! – Nicht mit LL(k) oder überhaupt statisch behandelbar


Datentypen in XML Schema

ProgrammiersprachenBasisdatentypen– Unterschiedliche ausgeprägte

Integers, Floats, etc.

Arrays– Statisch– Dynamisch– Flexibel

XML SchemaBasisdatentypen – Erweitert um URL, Datum, Zeit, etc.– Standardtypen mit beliebigen

Einschränkungen auf Wertebereich und Literalen

Arrays durch Attribute der Elemente– Statische Grenzen

minOccurs=‘X’ maxOccurs=‘Y’– Dynamische und Flexible werden nicht

unterschiedenmaxOccurs=‘unbounded’



ProgrammiersprachenRecords– Zugriff über Namen

Variante Records– Records mit/ohne Typetag– Zugriff auf Variante die in

Typetag codiert ist – Typsicher, wenn kein

Variantenwechsel bei ein und demselben Objekt möglich ist

XML SchemaRecords– Struktur von XML (Schema ist XML)– Zugriff über Namen von Unterelementen

und PositionVariante Records durch Element– <choice> Auswahl </choice>– Variante kann nicht erkannt werden, da

nicht eindeutig– Nicht typsicher– Typsicher, wenn Auswahl nur

Elemente


Beispiel Variante Records

<complexType name=„C“> <choice> <sequence maxOccurs=„unbounded“> <element ref=„a“/> <element ref=„b“/> </sequence>

<choice maxOccurs=„unbounded“> <element ref=„a“/> <element ref=„b“/> </choice> </choice></complexType>

Ableitung für <a/><b/> ?Rechts sicher, z.B. <c1><a/><b/></c1>

<complexType name=“C1“> <sequence maxOccurs=“unbounded“> <element ref=“a“/> <element ref=“b“/> </sequence></complexType>

<complexType name=“C2“> <!– analog --></complexType>

<complexType name=“C“> <choice> <element name=“c1“ type=“C1“/> <element name=“c2“ type=“C2“/> </choice></complexType>


Abbildung von Typkonstruktoren auf reguläre Ausdrücke

Datentyp Ausdruck

ARRAY OF X (X)*

RECORD X, Y, ..., Z (X, Y, ..., Z)

UNION X, Y, ..., Z (X |Y |... |Z)


Deterministische Inhaltsmodelle

Eindeutigkeit der regulären Ausdrücke herstellbar – Transformation in Automaten– Deterministisch machen (Teilmengenkonstruktion, exponentiell)– Minimieren (Klassenbildung)

Deterministisches Zerteilen möglichDeterministische Ausdrücke– Definition: beim Zerteilen eines Satzes ist für jedes Symbol ohne

Vorschau das entsprechende Symbol im Ausdruck zuzuordnen– Gegenbeispiel: Satz „aaaaaab“ und Ausdruck „a*b|a*c“

Nicht jeder deterministische Automat hat deterministischen Ausdruck Deterministisches Interpretieren i.a. unmöglich



ProgrammiersprachenKlassen– Records mit Daten und

Funktionskomponenten– Vererbung– Polymorphie

XML SchemaKlassen– Records besprochen– Referencial Transparency: keine

Unterscheidung zwischen 0-stelligen Funktionen und Daten

– Keine Entsprechung für allgemeine Funktionen

Erweiterte Konzepte nötigStandard WSDL


Web Services Description Language (WSDL)

Im Kontext von .NET besprochenBeschreiben Mengen von FunktionenModellierung von Parametern– XML Schema (oder beliebige andere Beschreibungssprachen )

Probleme– Referenzen (auf Dienste) nicht explizit unterstützt– Strukturiertes Programmieren – keine Objektorientierung

Keine Vererbung, keine Polymorphie

Beispiel WSDL

<wsdl:definitions>  <wsdl:message name=“startTreatmentIn”>

 <part name=“body” element=“patient” type=“med:patient”/> </wsdl:message> <wsdl:message name=“startTreatmentOut”> <part name=“body” element=“accepted” type=“xsd:boolean”/> </wsdl:message>

<wsdl:portType name=“treatmentPort“> <wsdl:operation name=“startTreatment“> <wsdl:input message=“startTreatmentIn“/> <wsdl:output message=“startTreatmentOut“/> </wsdl:operation> </wsdl:portType>

</wsdl:definitions>



ProgrammiersprachenKlassenvererbung– Spezialisierende– Konforme

Zeiger– typisiert oder untypisiert– auf beliebig Werteobjekte

XML SchemaRecordeinschränkung, -erweiterung– Abgeleitete Typen– Spezialisierung möglich, durch

Schematypeinschränkung– Konformität möglich, durch

Schematyperweiterung

Zeiger über Attribute der Elemente– ID und IDREF Typen– Keine typisieren Zeiger– Identifikation von Objekten mit

Schlüsselwerten– Keine Referenzen auf WSDL

beschriebene Dienste


Wertung

XML Standards völlig ungeeignet, um Daten und Schnittstellen von Komponenten in höheren Programmiersprachen zu beschreiben– Nur Wertesemantik– Keine Klassen– Keine Vererbungskonzept

Probleme werden beseitigt– Standards ändern sich – XML Schema hat 4 Drafts durchlaufen im

letzten Jahre, standardisiert 4/2001– Forschungsgegenstand

Technik ist stark wegen XML Vorteilen beim Zerteilen und Transformieren


XML und IDL

Beide sollen Typen definierenAnpassungen auf Datenebene anwendungsspezifischAnpassungen auf Beschreibungsebene (Metaebene) – Meta Object Facility (MOF) bietet LösungForschungsgegenstandTechnisch problemlos


IDL und XML Schema

IDL

IDL-Spezifikation

MOF

XMLSchema

Umwandlungs-routinen

Schema-Spezifikation

Daten-Instanz

Daten-Instanz

Abfrage/Navigation


DOM

Document Object Model (DOM)W3C StandardElemente und Attribute – alle gleichen Typs – sind explizite Objekte (unterschieden durch Namen)

Zugriffe– Iteratoren über Kindelemente und Attribute– i-tes Kindelement, erstes Kindelement mit Namen x– Attributwert über Attributnamen

Langsam, umständlich, kein StromformatTypinformation geht verloren


Lesende Methoden

String getNodeName ();String getNodeValue ();short getNodeType ();Node getParentNode ();NodeList getChildNodes ();Node getFirstChild ();Node getLastChild ();Node child (int i);Node getPreviousSibling ();Node getNextSibling ();NamedNodeMap getAttributes ();Document getOwnerDocument ();


Alternative Formate

DOM 2 integriert NamensräumeTypisierte Syntaxbäume – generiert aus DTD oder Schema

Schlüsselzugriffe z.B. für ID und IDREFPersistente Formate– Anbindung an Datenbanken– Persistent DOM

Binäres Kodierungsformat– Wahlfreier Zugriff


Eigentliche Transformation

Bislang:– Daten beschrieben mit Typbeschreibung– Interne Darstellung der Daten

Nächster Schritt:– Eigentliche Transformation zwischen Quell- und Zielformat

Vorgehen:– Transformator ausprogrammieren– XSLT (entsprechender XML Standard dafür) – Deskriptiver Ansatz sollte Ergebnis der Transformation definieren,

nicht Operationen dafür– Term- bzw. Graphersetzer (Techniken aus dem Übersetzerbau)


Verarbeitung mit Standard XML Techniken

Zerteiler liest Dokument und DTD/SchemaDokument wird gegen Grammatik validiertDOM wird aufgebautTransformation/Filterung auf dem DOM– Definiert durch XSLT Spezifikation– Ausgabedaten nicht notwendigerweise XML konform


XSLT

eXtensible Stylesheet Language Transformation (XSLT)W3C StandardXML Syntax– XML Schema für XSLT– DTD Beschreibung der Syntax nicht möglich wegen beliebiger Ausgabe

Navigation auf DOM– Mischung zwischen deklarativer Notation und imperativen Anweisungen

Mustererkennung auf DOM– Menge von Pfadausdrücken (XPATH)– Achtung: Keine Baum oder Graphmuster!

Erzeugung von XML-Dokumenten oder anderen Texten


Beispiel - Regeln

<xsl:template match=„treatment"> <html><head/> <body>

<xsl:apply-templates/> </body></html>

</xsl:template>

<xsl:template match=„patient"> <h1>

„Patienten Nr:“ <xsl:value-of select=„nr"/> </h1><xsl:apply-templates/>

</xsl:template> ...


Beispiel - Ausgabe

<?xml version="1.0" encoding="iso-8859-1"?> <html xmlns="http://www.w3.org/TR/xhtml1/strict"> <head/> <body>

<h1>Patienten Nr: 0503760072</h1> ...

</body> </html>


Pfadausdrücke

Pfad bildet (DOM) Knotenmengen zur Weiterverarbeitung– Folge von Schritten schritt1/schritt2/.../schrittN

Schritt bildet neue Knotenmenge aus einer bestehenden– Folge: achse::auswahl[prädikat1][prädikat2]...[prädikatM]

Achsen bilden neue Knotenmenge aus einer bestehenden– Sprünge zu Eltern, Kinder, Nachbarn (Vor / Nachfolger in Pre-Ordnung)– Entsprechende Zugriffe im DOM zur Berechnung der Kontextknoten– Beispiel: ancestors::

Auswahl filtert bestehende Knotenmenge – Elementname Joker: *– @Attributname Joker: @*– Wurzelelement des Dokuments: /– Text, Kommentar, Verarbeitungsanweisungen


Prädikate

Prädikate filtern bestehende Knotenmenge– Ausdruckssyntax

Beispiele: – Ist Attribut definiert element[@attribut]– Hat Attribut bestimmten Wert (immer String)

element[@attribut=wert]– Steht element an Position x (immer int)

element[position()=x]


Einbettung von XPATH in XSLT

XSLT ist Menge von Templates– Matchausdruck (XPATH Ausdruck)– Anweisungen (Ausgaben, rekursive Aufrufe etc.)

Initial enthält die Kontextknotenliste den WurzelknotenAuswahl des passenden Match-Ausdrucks– Ausführung der Anweisungen im Template– Bei Rekursion (apply-templates Anweisung):

Aufbau neuer Kontextmengen

Einschränkungen mittels– Select (XPATH Ausdruck)– Regelmodi und –namen


Weitere Konzepte

Parameter für die Musterauswertung (wie funktionales Programmieren) Definition von Variablen und statische EinmalzuweisungAnbindung an Java Script, die wiederum DOM als Datenmodell kenntSchnitte von Knotenmengen - bereits in Implementierungen von „xp/xt“ (© J.Clark) aber noch nicht im Standard


Beispiel XML nach HTML

documentsection

section

entryentry

entryentry

entry

tr

table

tr

tr

th

tr

td

th

td td

td td

td


Beispiel

<xsl:template match="document"> <html> <head> </head> <body> <table> <tr> <xsl:apply-templates select="section"/> </tr> <xsl:call-template name="rowCounter"> <xsl:with-param name="N" select="1"/> </xsl:call-template> </table> </body> </html> </xsl:template>


Beispiel fortgesetzt

<xsl:template name="rowCounter"> <xsl:param name="N" /> <xsl:if test="section/entry[ $N ]"> <tr> <xsl:for-each select="section"> <td> <xsl:apply-templates select="entry[ $N ]"/> <xsl:text> </xsl:text> </td> </xsl:for-each> </tr> <xsl:call-template name="rowCounter"> <xsl:with-param name="N" select="$N + 1"/> </xsl:call-template> </xsl:if> </xsl:template> <xsl:template match="section"> <th><xsl:value-of select="@name"/></th> </xsl:template>


Wertung

XSLT ist turingmächtig– Bedingungen– Rekursionen

Deskriptiv nur in den PfadausdrückenRest ist funktionales ProgrammStandardisierung ohne Verständnis der Standardtechnologie:– Mustererkennungsgeneratoren– Termersetzungsgeneratoren– Graphersetzungsgeneratoren


Probleme mit XSLT

Unschön weil nicht deskriptiv Ineffiziente Implementierung– Standardwerkzuge interpretieren Scripte online

Inhärent ineffizient– Kontextinformation zur Anwendbarkeit einer Transformation muss

u.U. immer wieder neu berechnet werden– Aufwand O(n2) wenn Problem eigentlich O(n) ...


Alternativen

Termersetzungssysteme (TES)– Eingabe: (XML)Term, Match, Ersetzung– Ausgabe: Minimaler Fixpunkt nach iterativem Ersetzen

Graphersetzungssysteme (GES)– Eingabe: (XML)Term (über Namen und Referenzen eigentlich ein

Graph, Match, Ersetzung– Ausgabe: Minimaler Fixpunkt nach iterativem Ersetzen– Systeme: Optimix (Uni Ka) oder Progress (RWT Achen)

Matching kann durch Prioritäten gesteuert werdenGeneratoransatz:– Erzeugt Term- oder Graphersetzungssystem aus Term-(Graph-)

Typ (DTD oder XML Schema) und Match-, Ersetzungsregeln– Eigentliche Ersetzung durch generiertes Programm


Beispiel Termersetzung

PATTERNDEF { document < sections:section* > } MyDoc; PATTERNDEF { section < entries:entry* > } Section; PATTERNDEF { tr } TableRow; PATTERNDEF { td } TableData; PATTERNDEF { html < head body <t:table> > } HTMLRoot; PROCEDURE transform { WITH d <- MyDoc IN source DO { maxEntries = 0; WITH sec <- Section IN d.sections DO { maxEntries = max(maxEntries, length(sec.entries)); }

hroot = CREATE HTMLRoot; i = 0; WHILE (i < maxEntries) { trow = CREATE TableRow; APPEND trow TO hroot.t; WITH sec <- Section IN d.sections DO { APPEND CREATE TableData TO trow; } i = i + 1; } // while REPLACE d WITH hroot ADJOIN hroot.t; } // document iteration }


DOM kritisch betrachtet

Generatoren brauchen explizite Typ- und Strukturinformation in den AST-KnotenDOM hat beides nichtTransformation filtert Knoten, diese Knoten müssen nicht kodiert werden – Standard Übersetzerbautechnik– Übergang vom konkreten zum abstrakten Strukturbaum (AST)

DOM baut alle Knoten auf


Beobachtung

Anpassungen fallen in der Entwurfsphase auf– DTDs/Schemata bekannt Transformation kann ausprogrammiert werden

Sowohl das vorhandene Format als auch das gewünschte Format sind dann fest– In unterschiedlichen Kontexten der Komponente unterschiedlich– Ändern sich mit der Evolution der Komponente oder des

Komponentenkontexts Transformation muss automatisch generiert werden


Generierte Transformationen

GeneratorGenerator

TransformationZerteilerSchem

a

XSLT

Generator

DTD

XMLXML


Generatortechnik

aXMLelerate Werkzeugkasten– Zerteilergeneratoren für C und Java Zerteiler

(DTD und XML Schema)– Transformationsgenerator für Java (XSL-T)– Transformationsgenerator für C (Graphgrammatik)

Laufzeiten der generierten Zerteiler in C– 3-4106 Zeilen pro Sekunde – 12 MB / sec auf Intel Pentium III mit 500 MHz– 15 MB / sec auf Atlon mit 800 MHz

Web Compiler http://i44pc29.info.uni-karlsruhe.de


Potential generierte Zerteilung


Potential Transformation XSLT


Potential Transformation GES


Potential generierte Zerteilung - Java

Objektgenerierung der Zwischenstrukturen dominiert GesamtlaufzeitFür große Dateien ist der Anteil der DTD Analyse dann zu vernachlässigen– 15% Gewinn bei 5MByte Dokument– 1,5% Gewinn bei 50MByte Dokument

Standard-Zerteilung ist hinreichend schnell


Weitere Optimierungen

Serialisierer und AST Aufbauer filtern die DatenAbstrakte Interpretation der XSLT Skripte oder der GraphersetzungsbechreibungenBottom-Up Rewrite Systems (BEG)– Alternative lokale Ersetzungen– Kostenmaße– Globale Optimierung

Einweben der Serialisierer in SenderkomponenteEinweben der Zerteiler und Transformatoren in EmpfängerkomponenteStudien- und Diplomarbeiten


Datenanpassungen mit XML

Komponentenbauer beschreibt gelieferte Datenformate in IDLAutomatische Transformation in XML Schema mit Hilfe von MOFKomponenten-Deployer beschreibt – geforderte Formate in IDL oder XML Schema– Transformation in XSLT oder durch GES Beschreibung

Deploymentphase – Erzeugung von Parsern, Zwischenstrukturen, Transformatoren– Optimierungen möglich – Entsprechender Code wird in die Stubs/Proxies/RemoteInterfaces

eingewoben


Ausblick

Datenanpassung geleistetOffene Anpassungen– Funktionalität – Kommunikation– Synchronisation– Protokolle– Globale Korrektheit

Zuvor XML Standards für Kommunikation zwischen Komponenten, deren Schnittstellen etc.– Im Kontext von .NET besprochen– Allgemeine Standards


XML Standards

Austausch von Nachrichten mit SOAP(Simple Object Access Protocol)Beschreibung von Schnittstellen mit WSDL(Web Services Description Language)Auffindung von Diensten mit UDDI(Uniform Description, Discovery and Integration)Absicherung von Transaktionen mit XAML(XML Transaction Authority)


SOAP

Ansatz– Nachricht ist Umschlag mit Kopf und Körper– Kopf enthält Adresse etc. (weitgehend fest)– Körper enthält Nutzdaten (frei gestaltbar)– Datenkanal ist transparent(de facto HTTP)

Probleme– Typen der Nutzdaten a priori unbekannt – Festlegen von Typen in der Nachricht– Interpretation nötig, daher ineffizient


WSDL

Ansatz– Schnittstellen sind Mengen von Signaturen– Typsystem transparent (XML Schema)– Nachrichtenformat transparent (SOAP)

Probleme– Keine Vererbung– Typsystem nicht standardisiert– XML Schema kennt nur Werttypen– Gewünscht: Typisierte WSDL Referenzen


UDDI

Ansatz– Beschreibt Dienste auf auf Geschäftsebene – Registrierung ist XML Deskriptor

• White Page: Adresse, Erreichbarkeit• Yellow Page: Semantik (basiert auf Standard-Taxonomie)• Green Page: Technische Spezifikation (URL, WSDL, etc.)

– Logisch zentralisierte, physisch verteilte Datenbank

Problem– UDDI ist kein Makler oder Marktplatz

• Keine geographischen Anfragen• Keine Preisanfragen• Keine Laufzeitanfragen


XAML

Keine Ahnung

dr. welf löwe und markus noga1 gliederung: teil i - grundlagen 1. einführung –motivation...

Documents