Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,

Präsentation zum Thema: "Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,"—  Präsentation transkript:

1 Dr. Welf Löwe und Markus Noga1 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 JavaBeans 3. (D)COM 3. Anpassungen –Daten und Funktion –Interaktion Kommunikation Synchronisation Protokolle –Lebendigkeit

2 Dr. Welf Löwe und Markus Noga2 Problem II.1 Anpassungen von Datenformaten

3 Dr. Welf Löwe und Markus Noga3 XML eXtensible Markup Language (XML) Standard des WWW Konsortiums (W3C): http://w3c.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

4 Dr. Welf Löwe und Markus Noga4 XML Beispiel 1234-A 2001-01-30 No complications.

5 Dr. Welf Löwe und Markus Noga5 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

6 Dr. Welf Löwe und Markus Noga6 DTD Document Type Description (DTD) W3C 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)

7 Dr. Welf Löwe und Markus Noga7 DTD Beispiel <!ELEMENT treatment (patient (doctor|hospital) service+)> <!ATTLIST patientinsurer CDATA “1” nr CDATA #REQUIRED> <!ATTLIST doctorcity CDATA #REQUIRED nr CDATA #REQUIRED> <!ATTLIST hospital city CDATA #REQUIRED nr CDATA #REQUIRED>

8 Dr. Welf Löwe und Markus Noga8 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

9 Dr. Welf Löwe und Markus Noga9 XML Schemas Selbst XML W3C 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

10 Dr. Welf Löwe und Markus Noga10 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

11 Dr. Welf Löwe und Markus Noga11 XML Schema – einfache Typen – Beispiel

12 Dr. Welf Löwe und Markus Noga12 XML Schema – komplexe Typen – Beispiel <element ref=‘service’ maxOccurs=‘unbounded’/>

13 Dr. Welf Löwe und Markus Noga13 XML Schema – Attribute – Beispiel

14 Dr. Welf Löwe und Markus Noga14 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 –Gültigkeitsbereich: Element mit Kindern (wie Variable) –Auch Elementname, vorangehende Attribute! –Nicht mit LL(k) oder überhaupt statisch behandelbar

15 Dr. Welf Löwe und Markus Noga15 Datentypen in XML Schema Programmiersprachen Basisdatentypen –Unterschiedliche ausgeprägte Integers, Floats, etc. Arrays –Statisch –Dynamisch –Flexibel XML Schema Basisdatentypen –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 unterschieden maxOccurs=‘unbounded’

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

17 Dr. Welf Löwe und Markus Noga17 Beispiel Variante Records Ableitung für ? Rechts sicher, z.B.

18 Dr. Welf Löwe und Markus Noga18 Abbildung von Typkonstruktoren auf reguläre Ausdrücke DatentypAusdruck ARRAY OF X(X)* RECORD X, Y,..., Z(X, Y,..., Z) UNION X, Y,..., Z(X |Y |... |Z)

19 Dr. Welf Löwe und Markus Noga19 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

20 Dr. Welf Löwe und Markus Noga20 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

21 Dr. Welf Löwe und Markus Noga21 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

22 Dr. Welf Löwe und Markus Noga22 Beispiel WSDL

23 Dr. Welf Löwe und Markus Noga23 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

24 Dr. Welf Löwe und Markus Noga24 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

25 Dr. Welf Löwe und Markus Noga25 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

26 Dr. Welf Löwe und Markus Noga26 IDL und XML Schema IDL IDL- Spezifikation IDL- Spezifikation MOF XML Schema XML Schema Umwandlungs- routinen Schema- Spezifikation Schema- Spezifikation Daten- Instanz Daten- Instanz Daten- Instanz Daten- Instanz Abfrage/ Navigation

27 Dr. Welf Löwe und Markus Noga27 DOM Document Object Model (DOM) W3C 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

28 Dr. Welf Löwe und Markus Noga28 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 ();

29 Dr. Welf Löwe und Markus Noga29 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

30 Dr. Welf Löwe und Markus Noga30 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)

31 Dr. Welf Löwe und Markus Noga31 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

32 Dr. Welf Löwe und Markus Noga32 XSLT eXtensible Stylesheet Language Transformation (XSLT) W3C 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

33 Dr. Welf Löwe und Markus Noga33 Beispiel - Regeln „Patienten Nr:“...

34 Dr. Welf Löwe und Markus Noga34 Beispiel - Ausgabe Patienten Nr: 0503760072...

35 Dr. Welf Löwe und Markus Noga35 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 –ElementnameJoker: * –@ Attributname Joker: @* –Wurzelelement des Dokuments: / –Text, Kommentar, Verarbeitungsanweisungen

36 Dr. Welf Löwe und Markus Noga36 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]

37 Dr. Welf Löwe und Markus Noga37 Einbettung von XPATH in XSLT 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

38 Dr. Welf Löwe und Markus Noga38 Beispiel Kopierer <xsl:template match="*|@*|comment()|processing-instruction()|text()"> <xsl:apply-templates select="*|@*|comment()|processing-instruction()|text()"/>

39 Dr. Welf Löwe und Markus Noga39 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

40 Dr. Welf Löwe und Markus Noga40 Beispiel XML nach HTML document section entry tr table tr th tr td th td

41 Dr. Welf Löwe und Markus Noga41 Beispiel

42 Dr. Welf Löwe und Markus Noga42 Beispiel fortgesetzt

43 Dr. Welf Löwe und Markus Noga43 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

44 Dr. Welf Löwe und Markus Noga44 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)...

45 Dr. Welf Löwe und Markus Noga45 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

46 Dr. Welf Löwe und Markus Noga46 Beispiel Termersetzung PATTERNDEF { document } MyDoc; PATTERNDEF { section } Section; PATTERNDEF { tr } TableRow; PATTERNDEF { td } TableData; PATTERNDEF { html > } 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 }

47 Dr. Welf Löwe und Markus Noga47 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

48 Dr. Welf Löwe und Markus Noga48 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

49 Dr. Welf Löwe und Markus Noga49 Generierte Transformationen

50 Dr. Welf Löwe und Markus Noga50 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-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://i44pc29.info.uni-karlsruhe.de

51 Dr. Welf Löwe und Markus Noga51

52 Dr. Welf Löwe und Markus Noga52 Potential generierte Zerteilung

53 Dr. Welf Löwe und Markus Noga53 Potential Transformation XSLT

54 Dr. Welf Löwe und Markus Noga54 Potential Transformation GES

55 Dr. Welf Löwe und Markus Noga55 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 5MByte Dokument –1,5% Gewinn bei 50MByte Dokument Standard-Zerteilung ist hinreichend schnell

56 Dr. Welf Löwe und Markus Noga56 Weitere Optimierungen Serialisierer und AST Aufbauer filtern die Daten Abstrakte Interpretation der XSLT Skripte oder der 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

57 Dr. Welf Löwe und Markus Noga57 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/RemoteInterfaces eingewoben

58 Dr. Welf Löwe und Markus Noga58 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

59 Dr. Welf Löwe und Markus Noga59 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)

60 Dr. Welf Löwe und Markus Noga60 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

61 Dr. Welf Löwe und Markus Noga61 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

62 Dr. Welf Löwe und Markus Noga62 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

63 Dr. Welf Löwe und Markus Noga63 XAML Keine Ahnung