Gliederung Teil I Grundlagen 1 Einfhrung Motivation Definition

Gliederung: Teil I - Grundlagen 1. Einführung – Motivation – Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische) 2. Industrielle Komponentensysteme der 1. Generation 1. CORBA 2. Enterprise Java. Beans 3. (D)COM 3. Anpassungen – Daten und Funktion – Interaktion • Kommunikation • Synchronisation • Protokolle – Lebendigkeit

Problem II. 1 Anpassungen von Datenformaten

XML e. Xtensible Markup Language (XML) Standard des WWW Konsortiums (W 3 C): http: //w 3 c. org Entstanden aus SGML/HTML Entworfen als allgemeines Datenaustauschformat Sprache zur Beschreibung von Termen/Bäumen – Eigentlich nichts neues – Funktioniert, weil alle glauben es funktioniert Erleichtert Zerteilungsaufgaben gegenüber allgemeinen kontextfreien Sprachen Wohlgeformtes 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 standardisiert Legt 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) W 3 C Standard Kontextfreie Grammatik zur Definition von XML Dokumentstrukturen Basisdatentyp: 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 #REQUIRED nr 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 Interpretation Mehrdeutige Ableitungsbäume Schlechte Integration von Namensräumen

XML Schemas Selbst XML W 3 C Standard Typsystem – – Ü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 Interpretation Mehrdeutige 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 <simple. Type name=‘mkey’ base=‘string’> <pattern value=‘[0 -9]+(-[A-Z]+)? ’/> </simple. Type> <simple. Type name=‘insurer’ base=‘integer’> <precision value=‘ 7’/> </simple. Type> <simple. Type name=‘my. Date’ base=‘date’> <min. Inclusive value=‘ 2001 -01 -01’/> <max. Exclusive value=‘ 2001 -04 -01’/> </simple. Type>

XML Schema – komplexe Typen – Beispiel <complex. Type name=‘treatment’> <element name=‘patient’ type=‘patient’/> <choice> <element ref=‘doctor’/> <element ref=‘hospital’/> </choice> <element ref=‘service’ max. Occurs=‘unbounded’/> </complex. Type>

XML Schema – Attribute – Beispiel <complex. Type name=‘patient’ content=‘empty’> <attribute ref =‘insurer’ use=‘required’/> <attribute name=‘nr’ use=‘required’> <simple. Type base=‘integer’> <precision value=‘ 10’/> </simple. Type> </attribute> <attribute name=‘since’ type=‘my. Date’/> </complex. Type>

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 Programmiersprachen Basisdatentypen XML Schema Basisdatentypen – Unterschiedliche ausgeprägte – Erweitert um URL, Datum, Zeit, etc. Integers, Floats, etc. – Standardtypen mit beliebigen Einschränkungen auf Wertebereich und Literalen Arrays – Statisch – Dynamisch – Flexibel Arrays durch Attribute der Elemente – Statische Grenzen min. Occurs=‘X’ max. Occurs=‘Y’ – Dynamische und Flexible werden nicht unterschieden max. Occurs=‘unbounded’ 15

Datentypen in XML Schema Programmiersprachen Records XML Schema Records – 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 – Struktur von XML (Schema ist XML) – Zugriff über Namen von Unterelementen und Position Variante Records durch Element – <choice> Auswahl </choice> – Variante kann nicht erkannt werden, da nicht eindeutig – Nicht typsicher – Typsicher, wenn Auswahl nur Elemente 16

Beispiel Variante Records <complex. Type name=„C“> <choice> <sequence max. Occurs=„unbounded“> <element ref=„a“/> <element ref=„b“/> </sequence> <complex. Type name=“C 1“> <sequence max. Occurs=“unbounded“> <element ref=“a“/> <element ref=“b“/> </sequence> </complex. Type> <choice max. Occurs=„unbounded“> <element ref=„a“/> <element ref=„b“/> </choice> </complex. Type> <complex. Type name=“C 2“> <!– analog --> </complex. Type> Ableitung für <a/><b/> ? Rechts sicher, z. B. <c 1><a/><b/></c 1> <complex. Type name=“C“> <choice> <element name=“c 1“ type=“C 1“/> <element name=“c 2“ type=“C 2“/> </choice> </complex. Type> 17

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öglich Deterministische 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

Datentypen in XML Schema Programmiersprachen Klassen – Records mit Daten und Funktionskomponenten – Vererbung – Polymorphie XML Schema Klassen – Records besprochen – Referencial Transparency: keine Unterscheidung zwischen 0 -stelligen Funktionen und Daten – Keine Entsprechung für allgemeine Funktionen Erweiterte Konzepte nötig Standard WSDL 20

Web Services Description Language (WSDL) Im Kontext von. NET besprochen Beschreiben Mengen von Funktionen Modellierung 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> <!-- missing schema for med: patient import --> <wsdl: message name=“start. Treatment. In”> <!-- only one parameter --> <part name=“body” element=“patient” type=“med: patient”/> </wsdl: message> <wsdl: message name=“start. Treatment. Out”> <part name=“body” element=“accepted” type=“xsd: boolean”/> </wsdl: message> <wsdl: port. Type name=“treatment. Port“> <wsdl: operation name=“start. Treatment“> <wsdl: input message=“start. Treatment. In“/> <wsdl: output message=“start. Treatment. Out“/> </wsdl: operation> </wsdl: port. Type> <!-- missing binding & service definitions --> </wsdl: definitions>

Datentypen in XML Schema Programmiersprachen Klassenvererbung – Spezialisierende – Konforme Zeiger – typisiert oder untypisiert – auf beliebig Werteobjekte XML Schema Recordeinschrä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 23

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 definieren Anpassungen auf Datenebene anwendungsspezifisch Anpassungen auf Beschreibungsebene (Metaebene) – Meta Object Facility (MOF) bietet Lösung Forschungsgegenstand Technisch problemlos

IDL und XML Schema MOF XML Schema IDLSpezifikation Daten. Instanz Abfrage/ Navigation Umwandlungsroutinen Schema. Spezifikation Daten. Instanz 26

DOM Document Object Model (DOM) W 3 C Standard Elemente 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 Stromformat Typinformation geht verloren

Lesende Methoden String get. Node. Name (); String get. Node. Value (); short get. Node. Type (); Node get. Parent. Node (); Node. List get. Child. Nodes (); Node get. First. Child (); Node get. Last. Child (); Node child (int i); Node get. Previous. Sibling (); Node get. Next. Sibling (); Named. Node. Map get. Attributes (); Document get. Owner. Document (); 28

Alternative Formate DOM 2 integriert Namensräume Typisierte Syntaxbäume – generiert aus DTD oder Schema Schlüsselzugriffe z. B. für ID und IDREF Persistente 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/Schema Dokument wird gegen Grammatik validiert DOM wird aufgebaut Transformation/Filterung auf dem DOM – Definiert durch XSLT Spezifikation – Ausgabedaten nicht notwendigerweise XML konform

XSLT e. Xtensible Stylesheet Language Transformation (XSLT) W 3 C Standard XML 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"> <h 1> „Patienten Nr: “ <xsl: value-of select=„nr"/> </h 1> <xsl: apply-templates/> </xsl: template>. . . 33

Beispiel - Ausgabe <? xml version="1. 0" encoding="iso-8859 -1"? > <html xmlns="http: //www. w 3. org/TR/xhtml 1/strict"> <head/> <body> <h 1>Patienten Nr: . . . </body> </html> 0503760072</h 1> 34

Pfadausdrücke Pfad bildet (DOM) Knotenmengen zur Weiterverarbeitung – Folge von Schritten schritt 1/schritt 2/. . . /schritt. N Schritt bildet neue Knotenmenge aus einer bestehenden – Folge: achse: : auswahl[prädikat 1][prädikat 2]. . . [prädikat. M] 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 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 ist Menge von Templates – Matchausdruck (XPATH Ausdruck) – Anweisungen (Ausgaben, rekursive Aufrufe etc. ) Initial enthält die Kontextknotenliste den Wurzelknoten Auswahl 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

Beispiel Kopierer <xsl: stylesheet version="1. 0" xmlns: xsl="http: //www. w 3. org/1999/XSL/Transform"> <xsl: strip-space elements="*"/> <xsl: output. . . /> <xsl: template match="*|@*|comment()|processing-instruction()|text()"> <xsl: copy> <xsl: apply-templates select="*|@*|comment()|processing-instruction()|text()"/> </xsl: copy> </xsl: template> </xsl: stylesheet> 38

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

Beispiel XML nach HTML document table section tr entry th th entry tr td td section entry tr td td 40

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

Beispiel fortgesetzt <xsl: template name="row. Counter"> <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="row. Counter"> <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ücken Rest ist funktionales Programm Standardisierung 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(n 2) 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 werden Generatoransatz: – 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* > } My. Doc; PATTERNDEF { section < entries: entry* > } Section; PATTERNDEF { tr } Table. Row; PATTERNDEF { td } Table. Data; PATTERNDEF { html < head body <t: table> > } HTMLRoot; PROCEDURE transform { WITH d <- My. Doc IN source DO { max. Entries = 0; WITH sec <- Section IN d. sections DO { max. Entries = max(max. Entries, length(sec. entries)); } hroot = CREATE HTMLRoot; i = 0; WHILE (i < max. Entries) { trow = CREATE Table. Row; APPEND trow TO hroot. t; WITH sec <- Section IN d. sections DO { APPEND CREATE Table. Data 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-Knoten DOM hat beides nicht Transformation 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 49

Generatortechnik a. XMLelerate 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 -4 106 Zeilen pro Sekunde – 12 MB / sec auf Intel Pentium III mit 500 MHz – 15 MB / sec auf Atlon mit 800 MHz Web Compiler http: //i 44 pc 29. info. uni-karlsruhe. de

51

Potential generierte Zerteilung 52

Potential Transformation XSLT 53

Potential Transformation GES 54

Potential generierte Zerteilung - Java Objektgenerierung der Zwischenstrukturen dominiert Gesamtlaufzeit Für große Dateien ist der Anteil der DTD Analyse dann zu vernachlässigen – 15% Gewinn bei 5 MByte Dokument – 1, 5% Gewinn bei 50 MByte Dokument Standard-Zerteilung ist hinreichend schnell

Weitere Optimierungen Serialisierer und AST Aufbauer filtern die Daten Abstrakte Interpretation der XSLT Skripte oder Graphersetzungsbechreibungen Bottom-Up Rewrite Systems (BEG) – Alternative lokale Ersetzungen – Kostenmaße – Globale Optimierung Einweben der Serialisierer in Senderkomponente Einweben der Zerteiler und Transformatoren in Empfängerkomponente Studien- und Diplomarbeiten

Datenanpassungen mit XML Komponentenbauer beschreibt gelieferte Datenformate in IDL Automatische Transformation in XML Schema mit Hilfe von MOF Komponenten-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/Remote. Interfaces eingewoben

Ausblick Datenanpassung geleistet Offene 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 Geschäftsebene – Registrierung ist XML Deskriptor • White Page: • Yellow Page: • Green Page: Adresse, Erreichbarkeit Semantik (basiert auf Standard-Taxonomie) 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