Transcript Software aus Komponenten

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
Dr. Welf Löwe und Markus Noga
1
Problem
II.1 Anpassungen von Datenformaten
Dr. Welf Löwe und Markus Noga
2
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
Dr. Welf Löwe und Markus Noga
3
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>
Dr. Welf Löwe und Markus Noga
4
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
Dr. Welf Löwe und Markus Noga
5
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)
Dr. Welf Löwe und Markus Noga
6
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>
Dr. Welf Löwe und Markus Noga
7
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
Dr. Welf Löwe und Markus Noga
8
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
Dr. Welf Löwe und Markus Noga
9
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
Dr. Welf Löwe und Markus Noga
10
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>
Dr. Welf Löwe und Markus Noga
11
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>
Dr. Welf Löwe und Markus Noga
12
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>
Dr. Welf Löwe und Markus Noga
13
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
Dr. Welf Löwe und Markus Noga
14
Datentypen in XML Schema
Programmiersprachen
Basisdatentypen
XML Schema
Basisdatentypen
– Unterschiedliche ausgeprägte
Integers, Floats, etc.
Arrays
– Statisch
– Dynamisch
– Flexibel
– 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’
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
16
Beispiel Variante Records
<complexType name=„C“>
<choice>
<sequence maxOccurs=„unbounded“>
<element ref=„a“/>
<element ref=„b“/>
</sequence>
<complexType name=“C1“>
<sequence maxOccurs=“unbounded“>
<element ref=“a“/>
<element ref=“b“/>
</sequence>
</complexType>
<choice maxOccurs=„unbounded“>
<element ref=„a“/>
<element ref=„b“/>
</choice>
</choice>
</complexType>
<complexType name=“C2“>
<!– analog -->
</complexType>
Ableitung für <a/><b/> ?
Rechts sicher, z.B. <c1><a/><b/></c1>
<complexType name=“C“>
<choice>
<element name=“c1“ type=“C1“/>
<element name=“c2“ type=“C2“/>
</choice>
</complexType>
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
18
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
Dr. Welf Löwe und Markus Noga
19
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
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
21
Beispiel WSDL
<wsdl:definitions>
<!-- missing schema for med:patient import -->
<wsdl:message name=“startTreatmentIn”>
<!-- only one parameter -->
<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>
<!-- missing binding & service definitions -->
</wsdl:definitions>
Dr. Welf Löwe und Markus Noga
22
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
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
24
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
Dr. Welf Löwe und Markus Noga
25
IDL und XML Schema
MOF
XML
Schema
IDL
IDLSpezifikation
DatenInstanz
Abfrage/
Navigation
Umwandlungsroutinen
SchemaSpezifikation
DatenInstanz
Dr. Welf Löwe und Markus Noga
26
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
Dr. Welf Löwe und Markus Noga
27
Lesende Methoden
String
String
short
Node
NodeList
Node
Node
Node
Node
Node
NamedNodeMap
Document
getNodeName ();
getNodeValue ();
getNodeType ();
getParentNode ();
getChildNodes ();
getFirstChild ();
getLastChild ();
child (int i);
getPreviousSibling ();
getNextSibling ();
getAttributes ();
getOwnerDocument ();
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
29
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)
Dr. Welf Löwe und Markus Noga
30
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
Dr. Welf Löwe und Markus Noga
31
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
Dr. Welf Löwe und Markus Noga
32
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>
...
Dr. Welf Löwe und Markus Noga
33
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>
Dr. Welf Löwe und Markus Noga
34
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
Dr. Welf Löwe und Markus Noga
35
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]
Dr. Welf Löwe und Markus Noga
36
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
Dr. Welf Löwe und Markus Noga
37
Beispiel Kopierer
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.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>
Dr. Welf Löwe und Markus Noga
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
Dr. Welf Löwe und Markus Noga
39
Beispiel XML nach HTML
document
table
section
tr
entry
th
th
entry
entry
tr
td
td
section
entry
tr
td
td
entry
tr
td
td
Dr. Welf Löwe und Markus Noga
40
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>
Dr. Welf Löwe und Markus Noga
41
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>
Dr. Welf Löwe und Markus Noga
42
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
Dr. Welf Löwe und Markus Noga
43
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) ...
Dr. Welf Löwe und Markus Noga
44
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
Dr. Welf Löwe und Markus Noga
45
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
Dr. Welf Löwe und Markus Noga 46
}
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
Dr. Welf Löwe und Markus Noga
47
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
Dr. Welf Löwe und Markus Noga
48
Generierte Transformationen
Dr. Welf Löwe und Markus Noga
49
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
Dr. Welf Löwe und Markus Noga
50
Dr. Welf Löwe und Markus Noga
51
Potential generierte Zerteilung
Dr. Welf Löwe und Markus Noga
52
Potential Transformation XSLT
Dr. Welf Löwe und Markus Noga
53
Potential Transformation GES
Dr. Welf Löwe und Markus Noga
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 5MByte Dokument
– 1,5% Gewinn bei 50MByte Dokument
Standard-Zerteilung ist hinreichend schnell
Dr. Welf Löwe und Markus Noga
55
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 
Dr. Welf Löwe und Markus Noga
56
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
Dr. Welf Löwe und Markus Noga
57
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
Dr. Welf Löwe und Markus Noga
58
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)
Dr. Welf Löwe und Markus Noga
59
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
Dr. Welf Löwe und Markus Noga
60
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
Dr. Welf Löwe und Markus Noga
61
UDDI
Ansatz
– Beschreibt Dienste auf 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
Dr. Welf Löwe und Markus Noga
62
XAML
Keine Ahnung
Dr. Welf Löwe und Markus Noga
63