als eine PDF-Datei (schwarz-weiÃ) - IPD Goos

Prof. Dr. G. Goos Software aus Komponenten 1 

Software aus Komponenten 

Prof. Dr. Gerhard Goos 

Fakultät für Informatik 

Universität Karlsruhe 

Karlsruhe, Germany 2002 

c○ Gerhard Goos 2003 

http://www.info.uni-karlsruhe.de/

Organisation 

• Vorlesung: 

◮ dienstags 1400 - 1530, HS -101, wöchentlich 

◮ mittwochs 1400 - 1530, HS -101, vierzehntägig 

• Übungen: 

◮ mittwochs 1400 - 1530, HS -101, vierzehntägig, erstmals 30.4. 

• Übungsleiter: Dirk Heuzeroth 

• Adressen: 

◮ Allgemeines Verfügungsgebäude, 2. OG 

◮ ggoos@ipd.info.uni-karlsruhe.de 

◮ heuzer@ipd.info.uni-karlsruhe.de 

• Sprechstunden: 

◮ Goos: montags 14.00-15.00 Uhr 

◮ Heuzeroth: mittwochs 16:00 - 17:00 Uhr 

• Vorlesungsseite: 

http://www.info.uni-karlsruhe.de/~i44www/lehre/swk/2003SS/ 

Prof. Dr. G. Goos Software aus Komponenten 2

Inhalt 

1 Einleitung, Überblick, Konzepte 

• Ziele, Probleme und Aufgaben 

• Komponentenbegriffe 

• Überblick über 

◮ Klassische Ansätze 

◮ Produktlinien als Beispiel erfolgreicher Wiederverwendung mit 

Merkmalsanalyse als Hilfsmittel 

◮ Industrielle Lösungen 

◮ Akademische Ansätze 

2 Industrielle Lösungen 

• Ziele und Modell 

• CORBA 

• Enterprise JavaBeans (EJBs) 

• (D)COM, .NET 

3 Akademische Ansätze 

• Architektursysteme 

• Aspektorientiertes Programmieren 

• Metaprogrammierung und Invasive Komposition 


Literatur (1) 

• K. Czarnecki, U. W. Eisenecker: Generative Programming. 

Addison-Wesley. Umfassender Überblick. 

• U. Aßmann: Invasive Software Composition. Springer-Verlag 2003 

• Kiczales et al: Aspect-oriented Programming. LNCS ECOOP 1997 

• C. Szyperski. Component software. Beyond object-oriented computing. 

Addison-Wesley. Guter Überblick. 

• Software - Concepts and Tools. Vol. 19(1), 1998. Springer. 

Viele gute Artikel, besonders derjenige von Michael Stal. 

• W. Beer, D. Birngruber, H. Mössenböck, A. Wöß: Die .NET-Technologie. 

dpunkt.verlag 2003 

• Mono Projekt, Open Source Implementierung des .NET Rahmensystems 

http://www.go-mono.com/, V 0.23, 2003 

• R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. 

Wiley & Sons. Leicht zu lesen. 

• Jon Siegel: CORBA 3 Fundamentals and Programming, John Wiley, 2000. 

• Sametinger: Software Reengineering with Reusable Components. Springer 

1998. Überblick, aber mehr auf abstraktem Niveau 


Literatur (2) 


• Gamma et al: Entwurfsmuster. Addison-Wesley. 

Das unentbehrliche Handwerkszeug des Softwareklempners. 

• W. Pree: Metapatterns. ECOOP’94. Strukturierung von Entwurfsmustern. 

• Charles F. Goldfarb, Paul Prescod: The XML Handbook - Fourth Edition. 

Prentice Hall, 2001. 

• Wiebke Möhr und Ingrid Schmidt (Hrsg.): SGML und XML, Anwendungen 

und Perspektiven. Springer Verlag, 1999. 

• William Pardi: XML in Action. Microsoft Press, 1999. 

• Oliver Pott und Gunter Wielage: XML, Praxis und Referenz. Markt & 

Technik Buch- und Software-Verlag, 1999. 

Weitere Literatur auf der WWW-Seite 

http: 

//www.info.uni-karlsruhe.de/~i44www/lehre/swk/2003SS/literatur.html

Standards 

• Common Object Request Broker Architecture (CORBA). OMG spec, 

http://www.omg.org/technology/documents/corba_spec_catalog.htm, speziell: 

http://www.omg.org/technology/documents/formal/corba_iiop.htm 2002. 

• The Component Object Model Specification. Microsoft, 

http://www.microsoft.com/com/resources/comdocs.asp, 1999. 

• Enterprise JavaBeans. Sun, http://java.sun.com/products/ejb/, 2003. 

• Extensible Markup Language (XML) 1.0. W3C Recommendation, 

http://www.w3.org/TR/REC-xml, 2000. 

• Extensible Markup Language (XML) 1.1. W3C Candidate 

Recommendation, http://www.w3.org/TR/xml11/, 2002. 

• Simple Object Access Protocol (SOAP) 1.1. W3C Note, 

http://www.w3.org/TR/SOAP/, 2000. 

• Web Services Description Language (WSDL) 1.1, W3C Note, 

http://www.w3.org/TR/wsdl, 2001. 

• Universal Description, Discovery and Integration (UDDI) 

http://www.uddi.org/specification.html, 2000–2002. 

• C# Language Specification (Standard ECMA-334) 

http://www.ecma-international.org/publications/standards/ECMA-334.HTM, 2002 

• Common Language Infrastructure (Standard ECMA-335) 

http://www.ecma-international.org/publications/standards/ECMA-335.HTM, 2002 


Aufgaben, Visionen und Ziele 


I.1.1 - Ziele 

• Doug McIlroy’s Traum, 1968: 

◮ Wiederverwendung erfolgreicher ‘‘massenproduzierter’’ Teillösungen 

◮ Doug’s wichtigste Erfindung: UNIX pipes 

• erfinde das Rad nicht ständig neu: 

◮ erhöht die Produktivität 

◮ steigert die Verläßlichkeit 

⇒ evolutionäre Softwareentwicklung 

• nicht bauen, anpassen: 

◮ Familien von Systemen mit Varianten, Versionen 

◮ Konfiguration anstelle von Bau 

• kaufen statt bauen 

◮ COTS: components-off-the-shelf 

• sei ein Ingenieur: Baue Software wie andere Elektrogeräte, Maschinen 

oder Gebäude 


Probleme 


• Produktivität in der Software-Produktion zu gering 

• Qualität des Ergebnisses (Korrektheit, Benutzernutzen, . . . ) zu gering 

• zu viel Kunst, zu wenig engineering 

• zu wenig Wiederverwendung vorhandener Teillösungen 

• Programmieren auf der Anweisungsebene, ” 

Programmieren-im-Kleinen“, 

statt Zusammensetzen aus größeren Einheiten, 

” Programmieren-im-Großen“ 

• Hauptprobleme des Zusammensetzens: 

◮ Finden, was existiert 

◮ Anpassungsprobleme 

◮ Berücksichtigung nicht-funktionaler Eigenschaften 

◮ Inkonsistenz der Lösungs- und Implementierungsansätze verschiedener 

Komponenten, d. h. Inkompatibilität der Software-Architekturen der 

beteiligten Komponenten (Stilbruch, architectural mismatch, Garlan et 

al. 1995)

Aufgaben 


• Kennenlernen der vorhandenen, hauptsächlich industriellen Lösungsansätze 

• Systematik der Anforderungsermittlung 

• Methodik der Anpassung von Software-Teilsystemen 

Vision: Software-Konstruktion teilen in 

• Komponenten konstruieren (mit herkömmlicher Programmierung) 

• Komponenten zusammensetzen auf der Basis eines Bauplans 

( ” 

Konfigurationsprogramm“)

Beispiel: Kostenreduktion 


Wiederverwendungsgrad 0% 25% 50% 

Aufwand [AM] 81.5 45 32 

# Entwickler 8 6 5 

Kosten/loc [Euro] 36 19 15 

Zeilen/AM 165 263 370 

Einsparung [Euro] - 200,000 290,000 

Einsparung - 45% 60% 

Aus: C.Jones, The Impact of Reusable Modules and Functions, 

in Programming Productivity , Mc Graw Hill, 1986. 

• Größe von Klassenbibliotheken 

◮ JDK 1.1: circa 1.650 Klassen 

◮ JDK 1.4: circa 2.750 Klassen 

• Je mächtiger, desto höher die Einarbeitungszeit

Weitere Ziele 

• bessere Produktqualität 

◮ Grundlösung ist gegeben, Augenmerk auf Optimierungen 

◮ höhere Verläßlichkeit (aber wer haftet?) 

◮ längere Software-Lebensdauer 

◮ größere Flexibilität 

• besserer Softwareprozeß 

◮ höhere Produktivität 

◮ ‘‘Rapid’’ Prototyping 

◮ frühe Simulation von Systemarchitekturen 

• bessere Dokumentation 

◮ Standardstrukturen für Systeme 


Exkurs Produktqualität: Inspektionen (1) 


Quelle: Freimut et al (Allianz), ESCOM 2000

Exkurs Produktqualität: Inspektionen (2) 



Exkurs: Kosten-Nutzen-Rechnung für Inspektionen 


Inspektionskosten Geschätzte Ersparnisse 

Projekt A 52 Personentage 89 Personentage 

Projekt B 44 Personentage 102 Personentage 


Exkurs: Einfluß von Inspektionen auf den Aufwand (1) 



Exkurs: Einfluß von Inspektionen auf den Aufwand (2) 



Was dämpft die Euphorie? 


Aufwand für das Finden, Erlernen der Schnittstellen und Adaptieren von 

Komponenten ist zu hoch. 

Daher ist der mögliche Markt für Komponenten bis heute nicht richtig 

zustandegekommen. 

Beispiel: Wer hat eine vollständige Übersicht der Klassen in der jdk? 

Es kostet 5 - 10 mal mehr eine Komponente für Wiederverwendung 

aufzubereiten, als sie nur für ein einzelnes Projekt zu entwickeln 

pragmatische Positionen: 

• Butler Lampson: ein System kann nur 3-4, allerdings sehr große 

wiederverwendbare Komponenten enthalten (Linux/Windows, 

Oracle/DB2, . . . ); alles andere kostet zu hohen Lernaufwand und führt zu 

inkonsistenten Systemarchitekturen 

• Produktlinien-Ansatz: viele Komponenten aus einem umgrenzten 

Anwendungsbereich, die alle im Haus entwickelt sind; daher ist das 

know-how der Komponentenentwickler verfügbar, um das Finden, 

Erlernen und Adaptieren zu erleichtern. Entwicklung wiederverwendbarer 

Komponenten kostet 2 -3 mal mehr als Entwicklung einer Kompontente 

für ein einzelnes Projekt. 

• der akademische Ansatz: ein Grundbestand an Komponenten und damit 

konsistenten Systemarchitekturen muß im Studium erlernt werden und 

kann dann angereichert und wiederverwendet werden.

Grundlagen 


Reale Komponentensysteme 

Real Component Systems 

LEGO 

bricks 

• LEGO 

IC 

• Hohlblöcke 

• ICs 

Real Component Systems 

LEGO 

bricks 

IC 

• Hardware-Busse Hardware-Bus 

Hardware-Bus 

• Was unterscheidet Difference to siesoftware von Methoden construction? der Software-Konstruktion? 

Difference to software construction? 

Gerhard Goos, Software from Components, Overview 9 

Prof. Dr. G. Goos Software aus Komponenten 

Gerhard Goos, Software from Components, Overview 

20

Reale Komponentensysteme 


System Schnittstellen Komposition Anpassung 

LEGO Noppen Zusammen- - 

stecken 

Ziegel Form, Profil Mörtel Stücke abbrechen 

ICs, Bus Anschluß-Signal- Zusammen- Signale konvertieren, 

Spezifikation stecken, Löten filtern, puffern, . . . 

Software Signaturen Aufruf Daten, Funktionen, 

Protokolle Umwickeln Protokolle, ...

Komponenten, Komposition und Adaption 

• Entwurf nach Geheimnisprinzip (information hiding) 

◮ explizite Spezifikation von Schnittstellen 

◮ Implementierung bleibt verborgen 

• Komposition 

◮ Zusammensetzen von Komponenten nach lokalen Entwurfsprinzipien, 

die globale funktionale und nichtfunktionale Eigenschaften zusichern 

◮ Adaption von Komponenten, wenn nötig 

interne Adaption von Komponenten an ihren 

Wiederverwendungskontext 

externe Adaption: Anpassung der Schnittstellen für die 

Zusammenarbeit 


I.1.2 - Definition von Komponenten 


• A software component 

is a unit of composition with contractually specified interfaces and explicit 

context dependencies only. It can be deployed independently and is 

subject to composition by third parties. 

Szyperski (ECOOP Workshop WCOP 1997) 

• A reusable software component 

is a logically cohesive, loosely coupled module that denotes a single 

abstraction. 

Booch 

• A software component 

is a static abstraction with plugs. 

Nierstrasz/Dami

Andere Definitionen 


• Software components 

are defined as prefabricated, pretested, self-contained, reusable software 

modules - bundles of data and procedures - that perform specific 

functions. 

MetaGroup (OpenDoc) 

• Reusable software components 

are self-contained, clearly identifiable pieces that describe and/or perform 

specific functions, have clear interfaces, appropriate documentation, and a 

defined reuse status. 

Sametinger

Komponenten - Unsere Definition 

• Programmeinheiten mit standardisierter Basiskommunikation 

◮ Abstrakt (nur Schnittstelle), generisch oder 

konkret (mit Implementierung) 

Klassen und Module sind Komponenten, Objekte nicht! 

• Entworfen mit standardisierten Verträgen zur Komposition: 

◮ Export-Schnittstelle sichert semantische Eigenschaften zu 

◮ Import-Schnittstelle definiert Voraussetzungen dafür 

Explizit oder 

Implizit (Parameter von Konstruktoren oder Methoden) 

◮ Kein implizites Wissen 

• Komponenten sind wiederverwendbar 

• Komponenten können aus Komponenten zusammengesetzt sein 


Eigenschaften von Komponenten 

• Können aus Spezifikation generiert werden 

(generische Komponenten) 

• Unterscheidung funktionaler und nicht-funktionaler Aspekte 

◮ Funktion und Daten, 

◮ Kommunikation und Synchronisation, 

◮ Verteilung, 

◮ Persistenz, usw. 

• Können dynamisch geladen und ersetzt werden 

◮ Programme können Komponenten mit Reflektion betrachten und deren 

Dienste feststellen 

◮ Ignorieren unbekannter funktionaler Aspekte 

Reflektion: Die Fähigkeit eines Programmes, seinen Zustand zur 

Laufzeit zu inspizieren und seine Funktionalität zu bestimmen. 


Komposition 


• Ausfalten generischer Komponenten (homogen/heterogen) 

• Zusammensetzen von Komponenten gemäß Verträgen: 

◮ über Funktionen und Daten 

◮ üer Kommunikation, Synchronisation und Protokolle 

◮ Problem der globalen Lebendigkeit? 

◮ Wie gehen nichtfunktionale Eigenschaften ein? 

• Mangelnde Passung erfordert Adaption (Anpassung) der Komponenten: 

◮ Externe Adaption durch ” 

Klebecode“ (glue code) 

◮ Interne Adaption: 

Offenes Einsetzen 

Invasiver Austausch nicht-funktionaler Aspekte (z.B. 

Basiskommunikation tauschen, Synchronisation einfügen usw.)

Exkurs: Generische Komponenten 


• Beispiel: Auf einem Graphen mit Adjazenzmatix A = (a ij ), 

betrachte folgende Probleme für i ≠ j: 

◮ Existiert ein Pfad von i nach j? 

◮ Länge des kürzesten Pfades von i nach j? 

◮ Maximaler Fluß von i nach j? 

(die Kapazitäten sind durch a ij gegeben) 

• Der generische Floyd-Warshall-Algorithmus löst alle drei Probleme 

◮ ∀k ∈ [1, n] : a kk := c 

∀k ∈ [1, n]: 

∀i ∈ [1, n]: 

∀j ∈ [1, n]: 

a ij := a ij σ (a ik τ a kj ) 

• Übung: Bestimme die Konstante c und die Operationen σ, τ für alle 

Probleme. Welche algebraischen Eigenschaften müssen σ, τ aufweisen? 

• Übung: Schreibe eine Schablone (template) in C++, die mit 

entsprechenden Parametern die Probleme löst. 

◮ Bemerkung: Dieses Beispiel ist nicht OO-spezifisch. Können Sie es in Pascal oder C 

lösen?

Exkurs: Generische Komponenten II 

• Verallgemeinerung und Schlußfolgerungen: 

◮ Eine generische Komponente besteht aus (einer oder mehreren) 

‘‘generischen’’ Klassen, die durch Datentypen, Operationen, 

Implementierungen , . . . parametrisierbar ist 

◮ Die generische Klasse wird ausgefaltet, indem sie mit Exemplaren der 

Parameter versorgt wird. 

◮ Beispiele 

Schablonen in C++ (zu allgemein, unsystematisch definiert) 

Generische Pakete in Ada 

Generische Klassen in Eiffel, Sather, ..., (Pizza, generic Java) 

◮ Hauptanwendung: Behälter (Stacks, Listen, ...) 

◮ Problem: Viele Operationen der generischen Klasse werden auf 

Parameter angewendet. Wie kann man sicherstellen, daß sie alle 

existieren? 

Lösung: Begrenzte Polymorphie (bounded polymorphism) 


Wiederholung: Entwurf mit Verträgen 


• Problem: Programmeinheiten (Klassen, Methoden, . . . ) kommunizieren 

◮ Schnittstellen müssen passen 

• Lösung: Einführen von Zusicherungen (i.A. Formeln im Prädikatenkalkül), 

die die benötigten Eigenschaften beschreiben 

◮ Vorbedingung: muß vom Aufrufer erfüllt werden, damit der Aufruf 

funktionieren kann 

◮ Nachbedingung: kann der Aufrufer nach der Rückkehr verwenden 

(sofern die Vorbedingung erfüllt war) 

◮ Klasseninvariante: Zusicherung über den Zustand einer Datenstruktur 

vor und nach jeder Manipulation.

Wiederholung: Entwurf mit Verträgen II 


• Solche Zusicherungen heißen Verträge (contracts, Bertrand Meyer, Eiffel) 

zwischen Aufrufer und Aufgerufenen 

• Grundlegende OO-Entwurfstechnik: Zunächst nur Verträge zwischen 

Klassen und ihren Methoden definieren 

• Deckt nur funktionale Eigenschaften ab 

• Wendet Standardtechniken der Verifikation (‘‘Hoare logic’’) auf 

Programmieren im Großen an 

◮ Amüsant: ” 

Entwurf mit Verträgen“ wird von Praktikern geschätzt und 

großflächig eingesetzt, aber ‘‘Verifikation’’ gilt als nicht praktikabel; 

allein der Namenswechsel machte den Unterschied.

Wiederholung: Entwurf mit Verträgen III 

• Beschränkungen: Allgemeinheit vs. Spezialfälle 

◮ Ein Programm erfüllt seine Verträge, wenn die Zusicherungen für alle 

gültigen Eingaben erfüllt werden 

(ebenfalls durch Zusicherungen geregelt) 

◮ Aber: Jeder Test einer Zusicherung zur Laufzeit sichert die 

Vertragserfüllung nur für diesen speziellen Aufruf 

◮ Also: Verträge müssen statisch (von Hand) geprüft werden 

◮ Tests zur Laufzeit prüfen nur Spezialfälle 

inakzeptabel für verläßliche Systeme 

akzeptabel, wenn ein Fehlschlag keine Schäden anrichtet 

(abgesehen von Verzögerungen) 


Einige Kommunikationsarten 


• Normaler Prozeduraufruf 

• Rückruf (callback) und Ereignisse 

• Fernaufruf (remote procedure call, remote method invocation) 

◮ Einpacken der Objekte in Byte-Strom, Verschicken, Auspacken 

◮ Kann in heterogenen Systemen eingesetzt werden 

Z.B. Java RMI, CORBA usw. 

• Gemeinsamer Speicher (synchronisiert mit Semaphoren, . . . ) 

• Uni- oder bidirektionale FIFOs (z.B. pipes, sockets) 

• Anschlagtafeln (blackboards, strukturierte Anschlagtafeln (Linda 

Tupelraum) 

• Transaktionsdienste (Datenbank) 

• Migration von Code (z.B. Java Applets)


Beispiel: Rückruf und Ereignisse: Konzepte 

Example: Callbacks and Events I 

abstract solution 

goal: communication client-server whenever a situation 

(event, state change) arises at the server requiring action 

• Ziel: Kommunikation zwischen Dienstnehmer und Dienstgeber, wenn eine 

Situation by the client (Ereignis, Zustandsübergang) im Dienstgeber Aktivität des 

Dienstnehmers erfordert 

abstract solution: introduce event server between client and 

• Abstrakte Lösung: Ereignisdienst als Zwischenschicht einführen 

server 

event 

client 

server 

server 

◮ Dienstnehmer abonniert relevante Ereignisse beim Dienstgeber 

client notifies event server in advance about all events of interest 

‘‘relevant’’ durch Nebenbedingungen weiter einschränkbar 

◮ Dienstgeber “interest” may benachrichtigt constraint by Dienstnehmer mentioning additional über conditions Ereignisse (mit 

Nutzdaten) 

server notifies event server about all incoming events (state 

changes) including additional information 

◮ Ereignis kann keinen, einen, oder beliebig viele Dienstnehmer erreichen 

event server may notify zero, one or several clients about the event 

◮ Synchrone oder asynchrone Benachrichtigung 

notification by event server may be synchronous or asynchronous 

◮ Ereignisdienst oft im Dienstgeber integriert (Ereignisschleife) 

event server often integrated into the server (“event loop”) 

Gerhard Goos, Software from Components, Overview 22

Beispiel: Rückruf und Ereignisse II 


• Aufrufer übergibt Prozedurvariable oder Verweis auf Objekte (anonyme 

Klasse in Java, Rückruf-Dienst in Corba, delegate in C#, Dotnet) 

◮ Rückruf durch Rahmensystem, Bibliothek oder Dienstgeber 

◮ Zuerst eingesetzt zur Anbindung von Programm und 

Benutzerschnittstelle 

• Ereignisse zur asynchronen Kommunikation 

◮ technisch über Rückruf gelöst 

◮ Reihenfolge meist nicht zugesichert 

• dynamisch variierbarer Empfänger 

• Ereignisquellen sind meist Dienste 

• Z.B. in Java Beans, Corba Event Service

Echtzeitbedingungen 


Vorlesung betrachtet o.B.d.A. keine Echtzeitsysteme 

• Echtzeitbedingungen lassen sich in einem Automaten separat zu den 

Zustandsübergängen (funktionaler Automat) des betrachteten Systems 

spezifizieren und mit diesem bei Bedarf zusammenfügen (Dissertation 

Lötzbeyer). 

⇒ Zeitbedingungen lassen sich in die Komponentenschnittstelle 

aufnehmen. 

• Wichtig für die Analyse: Scharfe Unterscheidung zwischen Eingabewerten, 

Ausgabewerten und lokalen Variablen in einer Komponente, d. h. 

transiente Parameter nicht zugelassen 

⇒ Komponente kann zu einer Menge von Zuweisungen 

ausgabeparameter := f(eingabewert) 

abstrahiert werden.

I.1.3 Klassische Konzepte 

◮ UNIX 

◮ XML - Lösungen 

◮ Module 

◮ Klassen und Vererbung 

◮ Rahmensysteme (framework) 

• betrachtet als Komponentensysteme 

mit Diskussion der Probleme 


UNIX 


• Basiskommunikation: Byte-Ströme von Quelle zu Senke 

◮ Einfach und flexibel 

◮ In einem Rechner: Pipes 

◮ In Rechnernetzen: Sockets 

• Komponenten sind eigenständige Programme 

◮ Schnittstellen: Standardeingabe, Standardausgabe 

◮ Generierung: durch make usw. 

• Komposition mit Pipes in Shells und Skriptsprachen 

• Adaption: 

◮ externe Adaption durch eigenständige Komponenten, meist 

programmierbare Filter (awk, cut, grep, sed, usw.) 

◮ interne Adaption nicht unterstützt

Probleme 

• Komponenten haben jeweils nur einen Ein- und Ausgang 

• Einschränkung auf Ketten von Filtern (Pipelines) 

◮ Allgemeinerer Einsatz von Pipes und Sockets möglich. 

◮ Programme in C/C++ können so außerhalb des Modells agieren. 

◮ Komposition mit Werkzeugen wie Shells, Skripte dort unmöglich. 

• Einschränkung auf asynchrone Protokolle ohne Rückkanal 

• Adaption schwierig 

◮ Formale Modellierung der Daten fehlt 

◮ Standardwerkzeuge beherrschen maximal reguläre Muster 

• Allgemeine Probleme mit Skripten: 

◮ Schlecht skalierbar 

◮ Schlecht wartbar 


Einsatz von XML 

• Allgemeine Idee: 

◮ Ersetze UNIX’ Byteströme durch strukturierte Daten (Bäume) 

◮ Lasse mehrere benannte Ein- und Ausgaben zu 

◮ Erlaube syntaktische und semantische Datentransformationen 

• Komponenten sind eigenständige Programme oder Teile davon 

• XML als Austauschformat 

• XSLT für Datenanpassungen 

◮ Pfadsprache zur Musterbeschreibung, regelbasierte Ersetzung 

◮ andere Graphersetzungssysteme denkbar, nicht Standard 

• SOAP (Simple Object Access Protocol) als Basiskommunikation 

◮ Transport meist über HTTP 

• UNIX als Komponentensystem kann subsumiert werden 


Module (à la Parnas) 


Every module hides an important design decision behind a well-defined 

interface which does not change when the decision changes. 

David Parnas 

• Eigenschaften 

◮ Feste Schnittstellen 

◮ Kapselung, Geheimnisprinzip (information hiding) 

◮ Statische Bindung: Keine dynamische Erzeugung 

• Durchdringt viele moderne Sprachen (Modula, Ada, Java, C/C++ usw.) 

• Betrachtung als Komponentensystem: 

◮ Basiskommunikation: Prozeduraufruf 

◮ Schnittstellen: Prozeduren mit Parametern, globale Variable 

◮ Generierung: sprachspezifisch für generische Module 

◮ Adaption explizit und manuell

Probleme 

• Sprachabhängigkeit der 

◮ Basiskommunikation 

◮ Spezifikation von Daten und Prozeduren 

◮ Synchronisation 

• Protokolle nicht spezifiziert 

• Fehlende Werkzeuge für 

◮ Komposition 

◮ Adaption 

◮ Verteilung 

• Heterogene, verteilte Lösungen erfordern viel Handarbeit! 


Objektorientierte Klassensysteme 

• Klassen sind Module 

◮ können mehrere zur Laufzeit erzeugte Objekte haben 

◮ Objekte haben Zustände (evtl. persistent) 

• Vererbung und Untertypbeziehungen 

◮ Polymorphie 

◮ Späte Bindung von Aufrufen ( ” 

faule Auswertung“) 

• Betrachtung als Komponentensystem: 

◮ Basiskommunikation: (Polymorphe) Methodenaufrufe, Variable 

◮ Schnittstellen: Polymorphe Methoden, Objekt- und Klassenvariable 

◮ Generierung: sprachspezifisch, oft mit generischen Klassen 

◮ Adaption: durch Vererbung oder Delegation 


Generische oder Abstrakte Klassen 


generic/abstract class 

instance 

system 

implementation

Probleme 

• Sprachabhängigkeit der 


◮ Spezifikation von Daten und Prozeduren 


• Protokolle nicht spezifiziert 

• Adaption durch Spracheigenschaften eingeschränkt 

(Kontravarianz oder Kovarianz bei Vererbung) 

• Fehlende Werkzeuge zur Verteilung 

• Heterogene, verteilte Lösungen erfordern viel Handarbeit! 


Rahmensysteme (Frameworks) 

• Rahmensysteme sind Klassensysteme mit ” 

Rahmen“ 

◮ Der Rahmen bestimmt, welche zusätzlichen Klassen mit welchen 

Eigenschaften hinzugefügt werden müssen, um ein lauffähiges System 

zu erhalten. 

◮ Der Rahmen spezifiziert also auch einen Bauplan für das Gesamtsystem 

• Das Rahmensystem bestimmt Ablauf und Kommunikation einer 

Anwendung 

• Parametrisierung durch Klassen 

• Rahmensysteme als Komponentensysteme: 

◮ Basiskommunikation: Methodenaufrufe 

◮ Schnittstellen: Brennpunkte (hot spot) — Mengen von polymorphen 

Methoden 

◮ Generierung: Instantiierung der Parameterklassen oder Implementierung 

der abstrakten Klassen gemäß den Einschränkungen des Rahmens 

◮ Adaption: durch Vererbung oder Delegation 


Rahmensysteme 


parameter classes 

instances 

system 

implementation 

implementation

Probleme 


• Oft sprachabhängig 

• Keine Wiederverwendung in fremdem Kontext 

(Grund: zu starke Standardisierung) 

• Rahmen legt Möglichkeiten im voraus fest: 

◮ Adaption 

◮ Verteilung 

◮ Art der Kommunikation 

◮ Heterogene Lösungen

Modellieren mit UML Komponenten-Diagrammen 


Billing.exe 

Billing 

System 

Register.exe 

Course.dll 

Course 

People.dll 

User 

Student 

Professor 

Course 

Course 

Offering 

Copyright © 1997 by Rational Software 

Corporation

Probleme 


• Semantik sehr flexibel 

• Nichts ist definiert, also keine Anpassung nötig 

• Problem der Implementierung 

• Probleme je nach Implementierungssprache oder -system

I.1.4 Kommerzielle Komponentensysteme 

• Komponentensystem (Plattform, Rahmensystem) definiert Standards für 

Komponenten: Schnittstellen, Protokolle, Kommunikations- und 

Implementierungsbasis 

• stellt Grundvoraussetzungen für Einsatz der Komponenten sicher 

• reguliert Interaktionen zwischen den Komponenten 

• Beispiele: 

◮ Corba 

◮ (D)COM, .Net 

◮ (Enterprise) JavaBeans 

◮ IBM SOM 

◮ OpenDoc 


(D)COM, DotNet, CORBA und JavaBeans 

• Basiskommunikation: 

◮ Normale Prozeduraufrufe an Kommunikationssystem 

◮ Weiterleitung über normale Aufrufe und Fernaufrufe 

• Standardisierte Schnittstellen 

◮ set/get Properties, 

◮ IUnknown (COM), QueryInterface (Corba) 

◮ Namensdienste usw. 

• Generierung: aus Klassen und Definitionssprachen 

• Nur externe Adaption: 

◮ Für verteilte Systeme (Weiterleiten von Aufrufen über Fernaufrufe, 

marshaling) 

◮ Für gemischtsprachliche Systeme (IDL) 


Komponenten in kommerziellen Systemen 

Components in Commercial 

Systems 

• Objects Objekte, to be die plugged in einen into Softwarebus a softwarebus gesteckt werden können 

• bus Mit + set demof standardized Bus und einer interface Menge implementations von standardisierten + objectsSchnittstellen bilden 

result sie ein a Komponentensystem component (platform) (Plattform) 

softwarebus 

Prof. Dr. G. Goos Gerhard Goos, Software Software from Components, aus Komponenten Overview 40 53

CORBA 


CORBA 

• Offener Standard, siehe http://www.corba.org 

• Unabhängig von Sprache und Verteilung 

open standard, see http://www.corba.org 

• Schnittstellendefinitionssprache (interface definition language IDL 

independent from programming language and distribution 

• Komponenten als Quellcode oder binär 

interface definition language IDL 

source code or binary components 

client 

Java 

IDL stub 

client 

C 

IDL stub 

server 

C++ 

IDL skeleton 

object adapter 

Object Request Broker (ORB), Trader, Services

(D)COM 

(D)COM 

• Microsoft proprietär, siehe http://www.activex.org 

Microsoft proprietary, see http://www.activex.org 

• Ähnelt CORBA, aber einige Einschränkungen 

similar to CORBA 

• Rein binärer Standard 

only binary standard 

client 

VBasic 

COM stub 

client 

C++ 

COM stub 

server 

C++ 

COM skeleton 

monikers, registry 



JavaBeans 


JavaBeans 

• Offener Standard, siehe http://www.javasoft.com 

• Sprachabhängig: nur Java 

open standard, see http://www.javasoft.com 

• Unabhängig von Verteilung (durch RMI) 

• 

language 

Quellcode 

dependent: 

oder Bytecode 

Java only 

independent from distribution (by RMI) 

components in source or byte code 

Java 

Bean 

Java 

Bean 

Java 

Bean 

Bean Container 

Event InfoBus, RMI

DotNet 


• Alle Komponenten abgebildet auf Zwischensprache CLR (common 

language runtime) 

• Kommt dem Bild des Softwarebus am nächsten 

• Sprachunabhängig (aber Verweis-Arithmetik verboten) 

• Viele Elemente durch ECMA-Norm festgelegt 

Aber 

◮ auf Verwendung von Windows zugeschnitten 

◮ unter Kontrolle von Microsoft 

⇒ Weiterentwicklung von den Geschäftsinteressen von Microsoft, nicht 

von denen der Kunden, abhängig

Probleme 

• Unterschiedliche Basiskommunikation der Systeme, 

◮ z.B. können Corba Komponenten nicht direkt COM Komponenten 

verwenden 

◮ Wrapping mit zusätzlicher Indirektion oder 

◮ Invasive Änderung der Komponente nötig (unmöglich bei Binärlösung) 

• Keine formale Definition von Protokollen 

◮ Komponenten mit gleichen Schnittstellen i.a. nicht wiederverwendbar 

◮ Lösung Standardisierung: 

Schnittstellenidentifikation ist eindeutig (COM) 

Reflektion 


I.1.5 Programmfamilien und Produktlinien 


We consider a set of programs to constitute a family whenever it is 

worthwhile to study programs from the set by first studying the common 

properties of the set and then determining the special properties of the 

individual family members. (Parnas, 1976) 

A software product line is a set of software-intensive systems sharing a 

common, managed set of features that satisfy the specific needs of a 

particular market segment or mission and that are developed from a common 

set of core assets in a prescribed way (Clements, 2002)

Produktlinien als Beispiel erfolgreicher Wiederverwendung 


Produktlinien: 

• Fest definierte Anwendungsdomäne 

⇒ ermöglicht umfassende Domänenanalyse: 

◮ Merkmalsanalyse liefert Gemeinsamkeiten und Variabilitäten der 

Mitglieder der Produktlinie. 

⇒ ◮ Menge geeigneter Komponenten 

◮ Generische Architektur: Beschreibung der Zusammensetzung aller 

Mitglieder der Produktlinie durch Variabilitäten, 

d. h. Menge der Komponenten, die ein konkretes Mitglied bilden, 

wird nach fest vorgegebenem Verfahren anhand konkreter Werte 

gebildet. 

Eine Architektur gibt also die Menge der Komponenten und deren 

Zusammensetzung zu einem konkreten System an. 

⇒ Vermeidung von Paßfehlern 

• Erfordert präzise Planung, um Variabilitäten zu erfassen. 

• Erfordert Konfiguration, um Variabilitäten passend zu belegen.

Produktfamilien 


Quelle: Lars Geyer, Universität Kaiserslautern

Der Entwicklungsprozeß 



Prozeßschritte 



Konstruktion eines Mitglieds einer Produktlinie 



Merkmalsdiagramm mit Korrelation 



Einschränkungen 

• Funktioniert nicht oder nur teilweise mit COTS: 

◮ COTS passen i. a. nicht in generische Architektur, weil COTS nicht aus 

der Domänenanalyse hervorgehen. (vgl. Architekturinkompatibilität) 

• Merkmale beschreiben hauptsächlich funktionales Verhalten 

⇒ Interaktionsverhalten ist schlecht oder überhaupt nicht durch Merkmale 

faßbar und damit nicht konfigurierbar 

⇒ Architektur sollte konfigurierbar sein 

• Evolution bzgl. neuer Anforderungen ist sehr aufwendig: 

◮ Anpassung der Produktlinienarchitektur statt einzelner Produkte 


Konsequenzen 


• Wiederverwendung funktioniert im Falle von Produktlinien 

• Die Einschränkung bzgl. COTS ist praktisch irrelevant, 

denn nach (Lampson, 2003) funktionieren COTS ohnehin nicht 

(vgl. Beginn der Vorlesung). 

• Interaktionsanpassungen erfordern Architekturevolution: 

Änderung der Interaktion zwischen Komponenten bedeutet im allgemeinen 

eine Änderung der Zusammensetzung des Systems oder beeinflußt diese. 

⇒ Änderung von Interaktionsbeziehung impliziert Änderung der 

Architektur. 

• Neue Anforderungen erfordern komplette Überarbeitung der Produktlinie

Architektur 


Bewerkstelligung von Interaktionsanpassungen: 

• Man muß Abstraktionen finden für: 

◮ Schnittstellenkonsistenz 

◮ Protokollkonsistenz 

◮ Architekturkompatibilität 

• Die gesuchte Abstraktion heißt ein Konnektor (Garlan et al, 1993): Ein 

Konnektor kapselt die Interaktion zwischen Komponenten.

Architektur: Probleme 


Problem: Explizite Konnektoren zur Laufzeit 

verringern meist die Systemleistung. 

Lösung: Eliminiere explizite Konnektoren, wenn möglich. 

Beispiel: Interaktion zwischen Symbolentschlüsseler und Zerteiler in einem 

Übersetzer. 

Ausgangssituation: Symbolentschlüßler produziert Symbolstrom. 

Symbolstrom ist eine Datenstruktur, auf die der Zerteiler zugreift. 

Der Symbolstrom ist damit ein expliziter Konnektor. 

Konnektorelimination: Zerteiler ruft direkt den Symbolentschlüßler auf, 

um sich jeweils das nächste Symbol liefern zu lassen. Die Daten werden 

somit nach Bedarf des Zerteilers vom Symbolentschlüßler erzeugt.

Architekturevolution 

• Architekturevolution = 

◮ Austausch von Konnektoren 

◮ Erweiterung um neue Konnektoren und Komponenten 

• Aber: Komponenten müssen zum Architekturstil passen 

⇒ Bei COTS invasive Anpassung an vorherrschenden Architekturstil 

notwendig. 


Software-Evolution 


Beliebige unvorhergesehene Änderung einer Anforderung 

⇒ Beliebige invasive Änderung muß möglich sein. 

⇒ Im allgemeinen keine Vorkehrung möglich. 

Lösungsansätze im nächsten Abschnitt.

I.1.6 Akademische Konzepte 


• Architektursysteme 

• Aspektorientiertes Programmieren 

• Metaprogrammieren und invasive Programmadaptation als Technik zur 

Komposition 

• ‘‘Akademisch’’: Noch nicht großflächig und systematisch von der Industrie 

eingesetzt

Architektursysteme 

• Z.B. Unicon, Darwin 

• Basiskommunikation: 

◮ Prozeduraufrufe an Tore (communication ports) 

◮ Art der Kommunikation ist transparent 

• Schnittstellen: 

◮ Tore, an denen Konnektoren angreifen 

◮ Expliziter Gebrauch von Konnektoren bei jeder Kommunikation 

(in objektorientierten Systemen wird Kommunikation gemeinsam durch 

Vererbung verändert) 

◮ Schnittstellen bleiben zur Laufzeit erhalten 

• Interne Adaption: durch Vererbung 

• Externe Adaption: Klebe- oder Umwickelcode durch Konnektoren 




Tor 

Tor 

Komponente 

Komponente 

Tor 

Tor 

Kon− 

nek− 

tor 

Kon− 

nek− 

tor 

Kon− 

nek− 

tor 

Tor 

Tor 

Komponente 

Tor 

Komponente 

Tor 

Tor 

Tor 

Konnektoren trennen die Kommunikation von den Komponenten

Probleme 


• Keine Standardisierung 

• Künstliche Unterscheidung von Konnektoren und Komponenten 

• Keine Wiederverwendung von Konnektoren 

• Schnittstellen von Komponenten und Konnektoren im laufenden Code


Aspekttrennung & Komposition 

paration of Aspects & 

mposition 

walls 

electric 

water 

gas 

separate the 

designs for 

different Trenne aspects, die Pläne für verschiedene 

Aspekte weave them und webe sie zu einem System 

together zusammen to obtain 

one system 

exchange Austausch and development der Aspekte of aspects unabhängig voneinander 

(mostly) independent from each other 


Aspekt-orientiertes Programmieren (AOP) 


• Aspekt (aspect, concern): logisch abgrenzbare Teilaufgabe, die in der 

Lösung mit anderen Aspekten verzahnt werden muß (überschneidender 

cross-cutting concern) 

• Beispiele: anwendungsspezifische Funktionalität (der Kernaspekt), 

Kommunikation, Synchronisation, Verteilung, Persistenz 

• Spezialfall Architektursystem: die ersten beiden Aspekte 

• Grundprinzip: Aspekte bestehen aus (mehreren) Programmfragmenten. 

Diese werden durch einen Weber zusammengewoben (ereignisgesteuert, 

. . . , oder statisch) 

• Transparenz durch getrennte Beschreibung der Aspekte 

• Basiskommunikation: ein Aspekt 

• Generierung: Weben aus Aspektspezifikationen 

• Schnittstellen: Webepunkte (Haken), an denen verwoben wird 

• Adaption: 

◮ interne Adaption: Einfügen oder Austausch von Aspekten 

◮ externe Adaption: Weben von Klebecode um Komponenten

Dynamisches und statisches Weben 


Aspekte 

Aspekt 

1 

Ereignis 

dynamisches statisches 

Weben 

Webe− 

Punkt 

Aspekt 

1 

1 

2 

Aspekt 

2 

Ereignis 

gefüllt 

von 

Aspekt 

2 

1 

2 

Weber

Aspekte eines Programms (Algorithmus und Animation) 


/** The black code is the algorithmic aspect */ 

import java.io.*; 

public class Hanoi { 

public Hanoi() { 

// ... 

} 

protected void 

compute(int n, String s, String t, String h) { 

if(n > 1){ 

compute( n - 1, s, h, t ); 

} 

} 

transfer(s,t); 

if(n > 1){ 

compute( n - 1, h, t, s ); 

} 

/** The black code is the algorithmic aspect */ 

/* The red code is the animation aspect. */ 

import java.io.*; 

public class Hanoi extends java.util.Observable 

implements java.util.Observer { 

public Hanoi() { 

addObserver( new PrintObserver() ); 

} 

protected void 

compute(int n, String s, String t, String h) { 

if(n > 1){ 

compute( n - 1, s, h, t ); 

} 

transfer(s,t); 

setChanged(); 

notifyObservers( new displayPack( s, t ) ); 

if(n > 1){ 

compute( n - 1, h, t, s ); 

} 

}

Aspekte als Sichten 

Aspects as Views 

aspect 1 aspect 2 aspect 3 

instantiation 

= 

weaving 

abstraction 

= 

aspect 

system 



Probleme 

• Orthogonale Aspekte 

◮ Keine Interaktionen zwischen den Aspekten 

◮ Weben einfach 

• Nicht-orthogonale Aspekte (überschneidende, crosscutting Aspekte) 

◮ Z.B. Funktionalität und Synchronisation, Funktionalität und 

Verteilung, Protokolle und Synchronisation usw. 

◮ Getrennte Spezifikation unmöglich 

◮ Weben unklar 

• Aspekt als Sicht 

◮ Abstraktion von Systemeigenschaften 

◮ Umkehrungsfunktion nicht immer 

Eindeutig 

Widerspruchsfrei mit anderen Aspekten 


Merkmalanalyse 

• Arten der Variation 

◮ Innerhalb eines Systems zur Laufzeit 

◮ Zwischen einzelnen Läufen eines Systems 

◮ Zwischen Mitgliedern der Systemfamilie 

• Merkmalanalyse (Feature Analysis) modelliert Systemfamilien 

◮ Identifiziere Variationspunkte 

◮ Zähle Alternativen auf 

◮ Bilde Hierarchien (momentan starr) 

• Darstellung als Merkmaldiagramme (Feature Diagrams) 

◮ Untermenge regulärer Ausdrücke (kein Kleene’scher Stern) 

◮ Graphische Darstellung als Baum 

◮ Redundante Repräsentation → Normalformen 

• Abbildung auf Sprachmechanismen 

• Abgrenzung zu Aspekten? 


Invasive Komposition 


• Webepunkte: statisch eindeutig berechenbare Programmstellen 

• Komponenten kapseln Entwurfsentscheidungen hinter 

Kompositionsschnittstellen mit wohldefinierten Webepunkten 

• Programmtransformatoren (auch Kompositionsoperatoren) erkennen und 

transformieren Webepunkte einer Kompositionsschnittstelle. 

• Klassifikation: 

◮ Kein Komponentensystem! 

◮ Technik zur Komposition beliebiger Systeme

Invasive Komposition 


Invasive Composition 

standard weaving points, e.g. for wrapping: method.begin 

and method.end 

method.begi 

n 

method m 

(){ 

• Standard-Webepunkte, z.B. für 

wrapping: method.begin abc.. und 

method.end cde.. 

method m 

method.begin 

method.end 

} 

return; 


Transformation eines Webepunktes 


• Einfügen eines Test-Aspekts 

method m (){ 

} 

abc.. 

cde.. 

return; 

method m (){ 

print("enter m") 

abc.. 

cde.. 

print("exit m") 

return; 

}


Mehrfache Bindung eines Webepunktes 

Binding a weaving point 

repeatedly 

method.begin 

method m 

method.end 

print aspect 

transaction 

aspect 


Deklarierte Webepunkte 

Declared Weaving Points 

• Z.B. Kommunikationstore: 

use of port objects 

Ansprache von Torobjekten (port objects) 

method m (){ 

e.g. communication ports: 

method m (){ 

portOut.out 

} 

OUT port 

portOut.out(d); 

portIn.in(e); 

IN } 


portIn.in(e); 

method m 

portIn.in 

Prof. Dr. G. Goos Gerhard Goos, Software from ausComponents, Komponenten Overview 59 87

Transformationen für Tore 


m (){ 

m (){ 

... 


portIn.in(e); 

... 

} 

} 

/** ports */ 

e = x(d); 

m (){ 

/** ports */ 

setChanged(d); 

notifyObservers(d); 

listen_to(e); 

}

Einfache Bindung von Toren 


Simple Binding of Ports 

portOut.out 

call 

method m 

portIn.in 

call 

method x 


Transformation mit Kompositoren 

• Ein Kompositor ist ein Metaprogramm: 

◮ Programmtransformator 

◮ Bindet ungebundene Webepunkte an Code 

• Aufgaben 

◮ Erkennen von Webepunkten 

◮ Transformation durch Manipulation von Webepunkten 

(Binden der Webepunkte, Weben, weaving) 

◮ Codegenerierung 


Vergleich der Komponentensysteme 


System Kommunik. Schnittstellen Generierung Adaption 

Module Aufrufe Prozeduren Je nach Je nach 

Sprache Sprache 

Frameworks Polymorphe Methoden Generische Vererbung, 

Aufrufe Klassen Delegation 

CORBA RMI Methoden - Wrapper 

& Co. 

(nach IDL) 

Architektur- Aufrufe Tore - Konnektoren 

systeme an Tore 

AOP Aspekt Join points Weben Weben 

(beliebig) Webepunkte

Historische Ansätze 

• Netscape ONE: 

◮ HTML, Java, JavaScript 

◮ Internet foundation classes (Java Klassen für Netzwerk) 

◮ Internet inter-ORB protocol (IIOP, Konnektoren basierend auf 

CORBA) 

◮ Transport und applikationsspezifischer Protokolle 

• IBM Visual Age und ComponentBroker 

◮ Entwicklungsumgebung auf VisualAge-Basis 

◮ CBToolkit (Komponenten auf CORBA IDL basierend) 

◮ CBConnector (Verknüpfung und Management) 


Weitere historische Ansätze 

• IBM System Object Model (SOM) 

◮ Sprachunabhängiges Binärformat mit Versionen 

◮ Binäre Aufwärtskompatibilität (‘‘release order’’, Erhalt alter Offsets in 

Komponenten) 

◮ Unterstützung von Metadaten (Reflexion, Introspektion, Intercession): 

wie in Smalltalk können Klassen über Klassen nachdenken und Code 

transformieren 

◮ Mehrfachvererbung von Code 

• Apple OpenDoc: Aktive strukturierte Dokumente (setzt auf IBM SOM 

auf) 

◮ ‘‘compound document’’, ‘‘document parts’’ 

◮ Teile: ‘‘native data’’ / andere Teile 

◮ Open Scripting Architecture basierend auf AppleScript 

◮ Structured files mit Bento (ähnlich zu Microsofts COM/OLE) 

Dokument-Versionen von Dokumentbäumen mit Deltatechnik 

Flexibles Speichermodell für Datenströme und Einzeldateien 

Annotationen für Modifikationen an Dateien 

◮ Mittlerweile in Corba integriert 


Probleme der bisherigen Systeme 

• Fehlen von Standards für Anwendungsbereiche: 

◮ Verbindungsstandards nicht genug 

◮ Wie einen Standard erreichen? 

Marktmacht Microsoft, Corba Facilities, ... 

• Höhere Sicherheitsansprüche an Komponenten 

◮ erweiterte Verträge: Protokolle (Corba IIOP), 

◮ Spezifikation nicht-funktionaler Eigenschaften 

• Dienstvermittlung: 

◮ Semantikerkennung unmöglich 

◮ Standardisierung, aber Versionen zerstören Konsistenz 

• Technische Probleme 

◮ Speicherbereinigung (garbage collection) 

◮ Problem der fragilen Basisklassen: bei Versionsänderungen 

◮ Persistenzprobleme: müssen bereits ausgelieferte Komponenten 

nachübersetzt werden 

◮ Austauschformate: Standard oder XML Lösungen 

◮ Objekt-Mobilität, -Migration: 

Senden kleiner Objekte statt Referenzen 

• Wasserkopfprobleme (besonders bei Corba deutlich) 


Probleme des Systementwurfs 

• Produktlinien vs. COTS (vgl. Lampson 2003) 

• Alte Entwurfskonzepte nicht auf Komponenten übertragbar 

◮ Top-down Entwurf bei vorgegebenen Komponenten? 

◮ Verfeinerung unvollständig spezifizierter Komponenten 

Aspekte fehlen 

generische Komponenten 

Komponenten vor invasiver Kopplung 

◮ unabhängige Erweiterungen, viele Quellen 

◮ Globale Lebendigkeit 

◮ Anpassungsprobleme 

Daten 

Schnittstellen 

Protokolle 

Architektur (Basiskommunikation, etc.) 

• Managementprobleme 

◮ Qualitätssicherung bei anzupassenden Komponenten 

◮ Softwareprozeß 

• Rechtliche Probleme 

◮ Urheberrecht an Komponenten 

◮ Haftung bei Fehlern 


Gliederung 


1. Einführung 

◮ Motivation 

◮ Definition, 

◮ Konzepte für Komponenten (klassische, kommerzielle, akademische) 

2. Industrielle Komponentensysteme der 1. Generation 

1. Ziele und Modell 

2. CORBA 

3. Enterprise JavaBeans 

4. (D)COM, .Net 

3. Anpassungsprobleme 

◮ Daten und Funktion 

◮ Interaktion 

Kommunikation 

Synchronisation 

Protokolle 

◮ Lebendigkeit 

4. Akademische Ansätze 

◮ Architektursysteme 

◮ Aspektorientiertes Programmieren 

◮ Metaprogrammierung und Invasive Komposition

Komponentenbegriffe 


• Drei Ebenen 

1. Eine Komponente ist eine Kollektion von Programmfragmenten mit 

einem Bauplan, um für eine bestimmte Aufgabe eine ausführbare 

Programmeinheit zu erzeugen. 

2. Eine Komponente ist ein Modul. Es gibt jeweils genau eine davon. 

3. Eine Komponente ist ein großes, in sich abgeschlossenes Teilsystem, 

welches eine bestimmte Aufgabe erledigt. 

• Beobachtung 

◮ Ursprüngliche Definition deckt sich mit 1. 

◮ 2. und 3. sind technisch äquivalent 

◮ Aber: Allein 3. garantiert ökonomische Skalierbarkeit.

Motivation, Vertreter, Probleme 

• Pragmatisch motiviert 

◮ Wie baue ich große Systeme in einer heterogenen Welt? 

• Grad der Umsetzung ist unterschiedlich 

◮ Mustergültig: CORBA 

◮ Sprachgebunden: JavaBeans, EJB 

◮ Plattformgebunden: COM, DCOM, .NET 

• Zunächst: Ziele, Ansätze und Umsetzungen im Modell 

◮ Sprachtransparenz 

◮ Ortstransparenz 

◮ Reflektion 

◮ Dienste 


Ziele industrieller Systeme 


Aufgaben kommerzieller Systeme 

(Corba, (D)COM, EJB) 

A vision of software components working smoothly together, without regard 

to details Daten- of any component’s und Interface-Beschreibung 

location, platform, operating system, 

programming language, or network hardware and software. 

Referenz- und Wertesemantik 

Jon Siegel, Object Management Group (OMG), 1989 

Kommunikation (Nachrichten und RMI) 

Verteilung, Persistenz, Heterogenität 

• Busse garantieren Hardware-Interoperabilität 

• Komponentensysteme liefern Äquivalent für Software: 

Softwarebus 

Dr. Welf Löwe und Markus Noga 2

Motivation, Vertreter, Probleme 

• Pragmatisch motiviert 

◮ Wie baue ich große Systeme in einer heterogenen Welt? 

• Grad der Umsetzung ist unterschiedlich 

◮ Mustergültig: CORBA 

◮ Sprachgebunden: JavaBeans, EJB 

◮ Plattformgebunden: COM, DCOM, .NET 

• Zunächst: Ziele, Ansätze und Umsetzungen im Modell 


◮ Ortstransparenz 

◮ Reflektion 

◮ Dienste 


Sprachtransparenz: Ziel 

• Ein Komponentensystem ist sprachtransparent, wenn für die Verwendung 

einer Komponente belanglos ist, in welcher Sprache sie implementiert ist. 

• Problem: Heterogenität mehrsprachiger Systeme 

◮ Aufrufkonzept 

Prozedur, Koroutine, Nachrichten 

◮ Aufrufrepräsentation 

Übergabekonventionen: Register, Stapel, ... 

Wer alloziert, wer räumt ab? 

◮ Datentypen 

Werte, Referenzen 

Arrays, Unions, Records 

Ko-/kontravariante Vererbung 

◮ Datenrepräsentation 

Breite und Kodierung primitiver Typen 

Layout zusammengesetzter Typen 

◮ Laufzeitumgebung 

Speicherverwaltung, Lebenszyklus 


Sprachtransparenz: Ansatz 

• Allgemeine Alternativen: 

◮ Direktes Anpassen: 

Konvertierung von jeder Sprache in jede andere 

⇒ Aufwand O(n 2 ) bei n Sprachen 

◮ Anpassen an Austauschformat: 

Bei n Sprachen n Abbildungen auf ein Austauschformat 

⇒ Aufwand O(n) 

◮ Standardisieren: Keine Anpassung, aber restriktiv. 

Aufwand O(1) für Erstellung des Standards. 

• In industrielle Komponentensystemen: 

◮ Aufrufkonzept 

Standardisiert auf Prozedur (Fernaufruf) 

◮ Aufrufrepräsentation 

Standardisiert auf C 

◮ Datentypen 

Anpassung an Austauschformat (IDL) 

◮ Datenrepräsentation 

Anpassung an Austauschformat (IDL) 

◮ Laufzeitumgebung 

Standardisiert als Dienste 


Sprachtransparenz: Umsetzung 

• Interface Definition Language (IDL) 

◮ Sprachunabhängiges Typsystem 

◮ Obermenge gängiger Sprachen 

◮ Beschreibt Daten und Schnittstellen von Komponenten 

• Standardisierte Sprachbindungen (language bindings) 

◮ Umsetzung von IDL-Konzepten mit Sprachmitteln 

◮ Werkzeug: sprachspezifische IDL-Übersetzer 

• Vorgehen zum Bau einer Komponente: 

◮ Beschreibe Schnittstellen in IDL 

◮ Erzeuge Gerüst in gewünschter Sprache mit IDL-Übersetzer 

◮ Fülle Gerüst mit Implementierung 


Beispiel für Sprachtransparenz: JavaIDL 


IDL Typ 

Java Typ 

module 

package 

boolean 

boolean 

char, wchar 

char 

octet 

byte 

string, wstring 

java.lang.String 

short, unsigned short 

short 

long, unsigned long 

int 

long long, unsigned long long 

long 

float 

float 

double 

double 

fixed 

java.math.BigDecimal 

enum, struct, union 

class 

sequence, array 

array 

signature interface and an operations interface, 

interface (non-abstract) 

helper class, holder class 

interface (abstract) 

signature interface, helper class, holder class 

constant (not within an interface) public interface 

fields in the Java signature interface for nonabstract, 

or the sole Java interface for abstract 

constant (within an interface) 

exception 

class 

Any 

org.omg.CORBA.Any 

type declarations nested within interfaces “scoped” package 

typedef 

helper classes 

pseudo objects 

pseudo interface 

readonly attribute 

accessor method 

readwrite attribute 

accessor and modifer methods 

operation 

method

Ortstransparenz: Ziel 

• Ein Komponentensystem ist ortstransparent, wenn für die Verwendung 

einer Komponente belanglos ist, wo sie sich befindet. 

• Problem: Heterogenität verteilter Systeme 

◮ Werte weitgehend unproblematisch 

◮ Gültigkeitsbereiche von Referenzen 

Thread / Prozeß, 

Rechner 

Kommunikationspartner 

Netz 

Zeitschranken (Speicherbereinigung, garbage collection) 

◮ Zugriffsarten auf Referenzen 

Speicherzugriff auf Felder 

Lokale Aufrufe 

Fernaufrufe 


Ortstransparenz: Ansatz 


• Weltweit eindeutige Referenzen (GUUID, URI, etc.) 

◮ Z.B. Rechneradresse + lokale Referenz 

◮ Umsetzungstabelle für lokale Referenzen 

Keine lokale Freigabe extern bekannter Komponenten 

Konsistente Änderung lokaler Adressen extern unsichtbar 

• Fernzugriff über transparente Stellvertreter (Proxies) 

◮ Implementiert alle Schnittstellen der Komponente 

◮ Aufrufe an Stellvertreter stets lokal 

◮ Weitergeleitet an Komponente durch Fernaufrufe 

Daher: Feldzugriffe nur über Zugriffsfunktionen 

Rechner 1 Rechner 2 

Komponente 

Objekt 

? 

Komponente 

Skelett 

RPC 

Stell− 

vertreter 

Konnektor

Ortstransparenz: Umsetzung I 

• Erzeuge Stellvertreter aus IDL 

◮ stub: eigentlicher Stellvertreter 

Leitet lokale Aufrufe als Byteströme über das Netz 

◮ skeleton: macht Komponente für Fernaufrufe zugänglich 

Dekodiert Byteströme und setzt sie in lokale Aufrufe um 


Ortstransparenz: Umsetzung II 


• Komponentenbehälter: Zentraler Eintrittspunkt (pro Rechner) 

◮ Allgemeine Infrastruktur für Fernaufrufe 

Kommunikationsprotokoll 

Authentifizierung (wer ist X?) 

Autorisierung (was darf X?) 

Lebenszyklus von Komponenten 

Elementare Dienste 

• Weiterleitung von Aufrufen: 

Local 

Remote 

Client XStub 

Container Container 

XSkeleton 

X

Reflektion: Probleme, Ansatz, Umsetzung 

• Mit Reflektion können die Schnittstellen einer (unbekannten) Komponente 

zur Laufzeit ermittelt und verwendet werden. 

• Motivation 

◮ Automatische Konfiguration 

◮ Einsatz in Entwicklungsumgebungen 

• Probleme 

◮ Inkompatibilitäten: bereits duch Sprachtransparenz ausgeräumt 

◮ Noch offen: Standardisierter Zugriff auf Schnittstellen 

• Ansatz 

◮ IDL ist bereits standardisiert 

◮ Standardisiere Laufzeitrepräsentation 

◮ Standardisiere Zugriff darauf 

• Umsetzung 

◮ Beschreibe abstrakten Syntaxbaum für IDL in IDL 

◮ Mache Definitionstabelle im Behälter zugänglich 


Dienste 

• Dienste sind die Grundfunktionalität des Laufzeitsystems. Sie stellen die 

von Komponenten allgemein benötigte Funktionalität bereit und sind 

selbst Komponenten. 

• Motivation 

◮ Standardisierung 

◮ Wiederverwendung 

• Beispiele 

◮ Namensauflösung 

◮ Vermittler (Makler, Trader ) 

◮ Synchronisation und Transaktionsschutz 

◮ Drucker, EMail, ... 


Beispiel: Namensdienst 

• Henne-Ei-Problem: 

◮ Woher kennt eine Komponente andere Komponenten? 

◮ Durch vom Aufrufer übergebene Referenzen. 

◮ Woher kennt der Aufrufer die Komponente? 

• Lösung 

◮ Führe (menschenlesbare) Namen für Komponenten ein 

◮ Stelle Dienst zur Namensauflösung bereit 

Auffinden des Namensdienstes ist Behälterfunktion 

Komponenten registrieren sich mit Name und Referenz 

Auffinden weiterer Komponenten über Namen 

Component 

NameService 

+resolve(in name : string(idl)) : Component 

+register(in comp : Component, in name : string(idl)) 

X 

Container 

+getNameService() : Component 


Beispiel: Vermittler 

• Erweitere das Auffindungsproblem: 

◮ Name unbekannt 

◮ Eigenschaften bekannt 

• Lösung 

◮ Stelle Dienst zur Vermittlung bereit 

Auffinden des Vermittlers über Namensdienst 

Komponenten registrieren sich mit Eigenschaften und Referenz 

Auffinden weiterer Komponenten über Vermittler 

◮ Standardisiere Eigenschaften (Terminologie, Ontologie) 

Funktionale Eigenschaften: Domänenmodell 

Nichtfunktionale Eigenschaften: Dienstgüte, ... 


Beispiel: Persistenz 

• Verändere das Auffindungsproblem: 

◮ Eigenschaften bekannt 

◮ Instanz möglicherweise passiviert (Datenbank) 

• Lösung 

◮ Stelle Dienst zur Vermittlung bereit 

Auffinden der Instanz über Schlüssel 

Bei Bedarf aktivieren (Objekt erzeugen) 

Bei Nutzungsende erneut passivieren 

◮ Nutzen 

Alle Objekte erscheinen permanent lebendig 

Handhabung des Objektlebenszyklus vereinfacht 

• Alternative 

◮ Auch denkbar: verallgemeinerte Referenzen 

◮ Aber: erfordert Änderungen der Basisplattform 


Zusammenfassung der Aufgaben 


Gesamtaufgabe: Zusammenspiel von Komponenten in einer heterogenen Welt 

organisieren, den ” 

Softwarebus“ realisieren 

• Sprachtransparenz 

• Ortstransparenz 

• Dienste: Namensdienste, Makler, Persistenz, Behälterdienste, DB-Zugriff, 

Drucken, . . . 

• Reflektion beim dynamischen Zusammenbinden von Komponenten

Konkrete industrielle Systeme 

• Modell 

◮ Mechanismen zur Transparenz von 

Sprachen (IDL), 

Plattformen, 

Betriebssystemen, 

Ausführungsort (Eindeutige Referenz, stub/skeleton). 

◮ Wiederverwendbare Dienste, u.a. 

Namen 

Makler 

Persistenz 

• Jetzt: Ausprägung in 

◮ Corba 

◮ COM/DCOM/.NET 

◮ JavaBeans / Enterprise JavaBeans 


Corba 

• Common Object Request Broker Architecture 

• Gründung der OMG (object management group) 1989. 

• Ziele: 

◮ Plug-and-play components everywhere (siehe Zitat im Modell) 

◮ Unterstützung für domänenspezifische Entwicklung 

Für Medizin, Finanzwirtschaft, Maschinenbau, etc. 

Geschichtete Dienste (layered services) 

• Entwicklung 

◮ Corba 1.1 1991 (IDL, ORB, BOA) 

◮ ODMG-93 (Standard für oo-Datenbanken) 

◮ Corba 2.0 1995 

◮ Corba 3.0 1999 (Java/EJB, Scripting, QoS) 

Aktuell: Version 3.0.2 aus 12/2002 


Corba: Literatur 


• R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. 

Wiley&Sons. Leicht zu lesen. 

• R. Orfali, D. Harkey, J. Edwards: Instant Corba. Addison-Wesley. 

Deutsch. Leicht zu lesen, aber einige konzeptionelle Übersetzungsfehler 

• CORBA. Communications of the ACM, Oct. 1998. Neueste 

Corba-Entwicklungen. 

• Jens-Peter Redlich, CORBA 2.0 / Praktische Einführung für C++ und 

Java. Verlag: Addison-Wesley, 1996. ISBN: 3-8273-1060-1, 59.90DM 

• Corba 3 Specification. OMG. http://www.omg.org, speziell 

http://www.omg.org/technology/documents/corba_spec_catalog.htm 

• Jon Siegel, CORBA 3 Fundamentals and Programming, Wiley & Sons. 

• Vorträge aus dem Web (OMG): 

◮ Java Portability and CORBA Integration, Dr. Richard Soley, CEO, 

OMG, April, 1999 

◮ Application Server Market Summary. Paul Harmon, Editor, Component 

Development Strategies Newsletter

Corba-Jargon für Einsteiger: OMA 

• Object Management Architecture 

◮ Objekt-Anfrage-Vermittler, Object Request Broker (ORB) 

Management für verteilte Objekte 

Kommunikation zwischen Objekten 

◮ General Service Interfaces (Object Services) 

Objekterzeugung, -zugriff, -verschiebung (relocation) 

Generische Laufzeitumgebung für Objekte 

◮ Common Facilities 

Standarddienste: Druckdienste, Datenbankzugriff, e-mail etc. 

◮ Non-Standard Application Specific Interfaces 

Anbieterspezifische Dienste 

Nicht standardisiert durch die OMG 

◮ Vertical Domain Specific Interface 

Kombinieren Object Services und Common Facilities 

Markt- oder industriespezifische Dienste 


Corba-Jargon für Einsteiger: Modell (1) 


• Ein Objekt ist eine identifizierbare, gekapselte Entität, die einen oder 

mehrere Dienste anbietet, die von Klienten angefragt weren können. 

CORBA-Objekte sind also Komponenten. 

• Ein Klient stellt Anfragen. 

• Damit ein Klient einen Dienst eines Dienstgebers anfragen kann, muß er 

die entsprechende Schnittstelle kennen. 

Eine Schnittstelle deklariert eine Menge von Operationen, Ausnahmen und 

Attributen. 

Jede Operation hat eine Signatur, die ihren Namen, ihre Parameter, ihr 

Ergebnis und ihre Ausnahmen definiert. 

Die Schnittstelle wird mit der Schnittstellenbeschreibungssprache 

CORBA-IDL beschrieben. 

• Eine Ausnahme (engl. exception) ist ein IDL-Konstrukt, das eine 

Ausnahmesituation repräsentiert, die als Antwort eines Aufrufs 

zurückgeliefert werden kann. Die Ausnahmebehandlung selbst ist nicht in 

CORBA spezifiziert, sondern Angelegenheit der jeweiligen 

Programmiersprache.

Corba-Jargon für Einsteiger: Modell (2) 


• Eine Objektreferenz ist ein Konstrukt, das die Informationen enthält, die 

man benötigt, um ein Objekt über den ORB zu identifizieren. Eine 

undurchsichtige (engl. opaque) Objektreferenz identifziert immer dasselbe 

CORBA-Objekt. 

• Ein Pseudoobjekt ist wie ein gewöhnliches CORBA-Objekt in IDL 

spezifiziert, aber kann nicht durch eine Objektreferenz herumgeschickt 

werden. Man kann es auch nicht auf einen bestimmten Typ anpassen oder 

eine Zeichenkettendarstellung von ihm erhalten. Pseudoobjekte sind also 

Objekte im lokalen Namensraum. Beispiele von Pseudoobjekten sind die 

Schnittstellenablage und die dynamische Aufrufschnittstelle. 

• Eine Objektimplementierung ist eine konkrete Klasse, die das Verhalten 

aller Operationen und Attribute der IDL-Schnittstelle, die sie unterstützt, 

definiert also implementiert. Zu einer Schnittstelle kann es mehrere 

Objektimplementierungen geben. 

• Ein ” 

Servantobjekt“ ist eine Instanz einer Objektimplementierung einer 

IDL-Schnittstelle. Das Servantobjekt ist beim ORB registriert, damit der 

ORB Aufrufe an es weiterleiten kann. Das Servantobjekt führt letztlich die 

Operationen aus, die ein Klient bei einem CORBA-Objekt anfragt. 

• Ein Server ist ein Programm, das die Implementierungsobjekte von 

IDL-Schnittstellen enthält und diese beim ORB registriert.

Kernproblem: Wasserkopf 


• Wasserkopf technisch und sprachlich aufgeblasener Probleme, der 

eigentlich nötig ist: 

◮ Corba bietet saubere Detaillösungen 

• Wasserkopf eher soziologisch bedingt: 

◮ Die OMG ist extrem heterogen 

◮ Standard deckt sehr breites Spektrum ab 

◮ Teilweise Folgen mangelnder Einigkeit sichtbar 

• Wasserkopf eher linguistisch und didaktisch bedingt: 

◮ Die Corba-Community spricht ihre eigene Sprache 

◮ Ballung von Akronymen oft unverständlich 

◮ Erweckt Eindruck höherer Komplexität 

• Hier: Vereinfachung durch Rückführung auf Modell

Sprachtransparenz in Corba 


Interface Definition Language 

Typen 

Typen 

• Im Modell: IDL 

• In Corba: Corba IDL 

◮ Standard: ISO 14750 

◮ Viele standardisierte 

Sprachanbindungen 

(C/C++, COBOL, 

Java, . . . ) 

• Reichhaltiges Typsystem 

Referenz- 

Referenz- 

Objekte 

Objekte 

Any 

Any 

Objekte 

Objekte 

Wertobjekte 

Wertobjekte 

Basistypen 

Basistypen 

Ints (short,..) 

Ints (short,..) 

Reals Typen (float..) 

Reals Typen (float..) 

Nicht-Objekte 

Nicht-Objekte 

Konstruktoren 

Konstruktoren 

Struct 

Struct 

Sequence 

Sequence 

Bool 

Bool 

Char, string, 

Char, string, 

Union 

Union 

Enum 

Enum 

octet 

octet 

Array 

Array 


Beispiel für einen Typ: Das Corba-Objekt 


Das Corba-Objekt 

CORBA::Object 

- get_implementation 

- get_interface 

- is_nil 

- create_request 

- is_a 

- duplicate 

- release 

- .... 

Das Corba Objekt vererbt sich als 

Klasse auf • CORBA::Objekt alle Corba-Objekte istund 

Komponente in 

Programmelemente. unserem Sinne 

get_interface • Vererbt liefert eine sichReferenz 

auf alle Corba-Objekte 

auf den Eintrag und im Programmelemente 

interface 

repository. • get_interface liefert eine Referenz 

get_implementation auf die eine Schnittstellenbeschreibung 

Referenz 

auf die Implementierung 

im interface repository 

• get_implementation liefert eine Referenz 

auf die Implementierung 


Ortstransparenz in Corba 

• Im Modell: 

◮ Stellvertreter aus IDL erzeugen (stub/skeleton) 

◮ Behälter (Zugriff, Verbindungen, Sicherheit) 

◮ Eindeutige Referenzen 

• In Corba: 

◮ Stellvertreter aus Corba IDL erzeugen (stub/skeleton) 

◮ Object Request Broker (ORB) 

Grundlegender Zugriff über Basic Object Adapter (BOA) 

Dynamische Aufrufe über Dynamic Invocation Interface (DII) 

Nicht die reine Lehre: ORB hat auch Dienstcharakter 

◮ Interoperable Object Reference (IOR) 


IDL-Codegenerierung: Ablauf 


Ablauf IDL-Codegenerierung 

IDL 

IDL 

Interface 

Interface 

IDL- 

IDL- 

Compiler 

Compiler 

Server 

Server 

Implementation 


Server 

Server 

Skeleton 

Skeleton 

Client 

Client 

Stub 

Stub 

Client 

Client 




Repository 

Compiler 

Compiler 

Objektadapter/ 

Objektadapter/ 

BOA 

BOA 

Server 

Server 

Client 

Client 


Der (Basis-)Objektadapter BOA 


Der (Basis-)Objektadapter BOA 

CORBA::BOA 

- Create 

- change_implementation 

- get_id 

- dispose 

- set_exception 

- impl_is_ready 

- obj_is_ready 

- deactivate_impl 

- deactivate_obj 

• Kapselt 

Gaukelt dem Klienten ein ständig 

◮ Aktivierung (Start, Stop, Dispose), 

lebendes Objekt vor. 

◮ 

Kapselt 

Persistenzaspekte 

– Aktivierung • Muß in(Start, jedem Stop), ORB vorhanden sein, 

– Persistenzaspekte 

um einen minimalen Service zu 

Muss in gewährleisten 

jedem ORB vorhanden 

sein, • um Verwaltet einen minimalen das Implementation Service Repository 

(Registry ). 

zu gewährleisten 

Verwaltet das Implementation 

Repository • Unterstützt (Registry). auch nicht-oo Code 

Unterstützt • Aufgerufen auch nicht-oo von Client Code (über ORB Kern) 

Aufgerufen und von Server Client (direkt) (über ORB 

Kern) und Server (direkt) 



BOA: Serverseite 

Serverseite 

Server / Object Implementation 

impl_is_ 

ready 

object_is_ 

ready 

deactivate_ 

obj 

deactivate_ 

impl 

BOA 

IDL 

Skeleton 

ORB Kern 


ORB 

ORB 

• Object request broker (entspricht Behälter im Modell) 

Client 

Server/Object Implementation 

Dynamic 

Invocation 

IDL 

Stub 

ORB 

Interface 

IDL 

Skeleton 

Dynamic 

Skeleton 

Object 

Adapter 

ORB-abhängig 

Standardisiert 

Objekttyp-abhängig 

ORB Kern 

Dr. Welf Löwe und Markus Noga 11 


ORB: Verfeinerte Sicht 


ORB Verfeinerte Sicht 



Der Objektanfrage-Vermittler ORB 

Der Objektanfragen-Vermittler ORB 

CORBA::ORB 

- object_to_string 

- string_to_object 

- create_list 

- create_operation_list 

- get_default_context 

- create_environment 

- BOA_init 

- list_initial_services 

- resolve_initial_references 

- .... 

Der ORB ist ein Vermittler 

(Entwurfsmuster) • Der ORB zwischen ist Client ein Vermittler (Entwurfsmuster) 

zwischen Client und 

und Server. 

Er verbirgt die 

Server. 

Umgebung vor dem 

Klienten. 

• Er verbirgt die Umgebung vor dem 

Er sucht für dynamische Aufrufe 

Klienten. 

Dienstgeber. 

• Er sucht für dynamische Aufrufe 

Er kann andere ORBs ansprechen, 

insbesondere 

Dienstgeber. 

solche auf dem Web. 

• Er kann andere ORBs ansprechen, 

insbesondere solche auf dem Web. 


ORB-Aktivierung auf dem Klienten 


Objekt CORBA ORB 

ORB_init 

BOA_init 

Initialisiert den Vermittler 

Initialisiert den Server-BOA 

List_initial_services 

resolve_initial_references 

Liefert Strings 

Liefert Objektreferenzen

Umsetzung: Verschiedene Servermodelle 

• Gemeinsamer Serverprozeß (shared server ) 

◮ Mehrere Objekte in einem Prozeß auf dem Server 

◮ BOA initialisiert sie als nebenläufige Fäden (threads) mit 

gemeinsamem Adreßraum (gemeinsames Apartment) 

◮ BOA Funktionen deactivate_impl, impl_is_ready, obj_is_ready 

abgebildet auf thread-Funktionen 

• Separater Serverprozeß (unshared server ) 

◮ Für jedes Objekt ein eigener Prozeß auf dem Server 

• Methoden-Prozeß (per-method server ) 

◮ Jeder Methodenaufruf erzeugt einen neuen Prozeß 

• Persistenter Server 

◮ Fremdanwendung startet Objekte (z.B. Datenbank) 

◮ BOA reicht die Anfragen nur durch 


Objektaktivierung auf dem Server 


Objektaktivierung auf dem Server 

Server Objekt1 Objekt2 CORBA::BOA 

Impl_is_ready 

Create 

obj_is_ready 

get_id 

obj_is_ready 

deactivate_obj 

deactivate_obj 

deactivate_impl 


CORBA Kommunikation: Übersicht 


• Statischer Methodenaufruf 

• Dynamischer Aufruf 

• Global eindeutige Referenzen (interoperable object reference, IOR) 

• Sprachbindung 

• CORBA Dienste: Häufig benötigte (Basis-)Dienste 

• CORBA Facilities: Horizontale und vertikale (bereichsspezifische) Dienste 

• Metaebene: Meta Object Facility / XMI

Bestandteile von Corba 


Bestandteile von Corba 

Basisdienste 

Interoperabilität 

IDL, RPC, ORB 

Erweiterte 

Interoperabilität 

DII, Trading 

Protokolle 

GIOP IIOP 

MOF 

(reflection) 

Facilities 

Services 

Scriptsprachen 

Geschäfts 

objecte 

(business 

objects) 

Komponenten 

CorbaBeans 


Statische Aufträge (Methodenaufrufe) 

• Methoden der Teilnehmer sind statisch bekannt, dynamisch nur 

Verbindungsaufbau durch Anmeldung erforderlich. 

◮ Aufruf durch Stummel und Skelette, 

◮ Keine Suche nach Diensten (in der Ablage), 

◮ Keine Suche nach Dienstobjekten, 

◮ Schnell 

• Statische Typprüfung durch Übersetzer möglich 

• Da der Aufruf an die Skelette durch den Objekt-Adapter geht, erscheint 

dem Klienten das Dienstobjekt durchgängig lebendig (transparentes 

Leben) 


Dynamischer Aufruf (Request Broking) 

• Dynamischer Aufruf (dynamische Abfrage) 

◮ Komponenten dynamisch ausgetauscht oder nachträglich eingebracht 

◮ Neuübersetzung entfällt 

◮ Beispiel: Plugins für Browser, Zeichenprogramme etc. 

• Beschreibung der Komponentensemantik zur Suche 

◮ Object Interface 

◮ Informationen 

Metadaten (beschreibende Daten) 

Schnittstellendaten 

Verzeichnisse von Komponenten (interface repository , 

implementation repository ) 

• Such-Vermittler - ORB interface 


IOR (interoperable object reference) 

• Verbirgt Objektreferenzen der Programmiersprachen 

• Pro Programmiersprache eindeutig abgebildet (für alle ORBs) 

• Transient (verschwindet mit Server) oder persistent (lebt weiter) 

• Bestandteile 

◮ Typnamen (type code), d.h. Zeiger in das Interface Repository 

◮ Protokoll und Adreßinformation (z.B. beim IIOP TCP/IP port, host 

name), 

auch für verschiedene zugleich unterstützte Protokolle 

◮ Objektschlüssel (object key). 

Name des Objektadapters (für den BOA) 

Gekapseltes Datum (nur vom erzeugenden ORB lesbar) 

Interface 

Repository 


Beispiel: IOR 


Sprachbindung (language binding) 

• Bijektive Abbildung: Corba IDL ↔ spezielles Typsystem 

• Vorgehen: Strukturelle Induktion 

◮ Definiere Abbildung für alle primitiven Typen 

◮ Definiere Abbildung für alle Typkonstruktoren 

◮ Fertig 

• Leistet Transparenz von 

◮ byte order 

◮ Wortbreiten 

◮ Speicherlayout 

◮ Speicherverwaltung 

◮ Referenzen 

• Wo nötig Anpasser erzeugen (Kopien minimieren) 


Ausführliches Beispiel: Zeitdienst 

• Aufruf liefert aktuelle Uhrzeit 

• Bestandteile 

◮ Schnittstellenbeschreibung mit IDL 

◮ Eigentlicher Dienst 

◮ Server (für dieses Beispiel) 

Startet ORB 

Initialisiert Dienst 

Gibt IOR dem Menschen bekannt 

◮ Client 

Nimmt IOR vom Menschen entgegen 

Dienstaufruf 


Beispiel: IDL 


//TestTimeServer.idl 

module TestTimeServer{ 

interface ObjTimeServer{ 

string getTime(); 

}; 

};

Beispiel: Dienst 


//TestTimeServerImpl.java 

import CORBA.*; 

class ObjTestTimeServerImpl extends 

TestTimeServer.ObjTimeServer_Skeleton { //generated from IDL 

//Variables 

//Constructor 

//Method (Service) Implementation 

public String getTime() throws CORBA.SystemException{ 

return "Time: "+currentTime; 

} 

};

Beispiel: Server 


// TimeServer_Server.java 


public class TimeServer_Server{ 

public static void main(String[] argv){ 

try{ 

CORBA.ORB orb = CORBA.ORB.init(); 

... 

ObjTestTimeServerImpl obj = 

new ObjTestTimeServerImpl(...); 

... 

System.out.println(orb.object_to_string(obj)); 

} 

catch (CORBA.SystemException e){ 

System.err.println(e); 

} 

} 

};

Beispiel: Client 


//TimeServer_Client.java 


public class TimeServer_Client{ 

public static void main(String[] argv){ 

try{ 

CORBA.ORB orb= CORBA.ORB.init(); 

... 

CORBA.object obj = orb.string_to_object(argv[0]); 

... 

TestTimeServer.ObjTimeServer timeServer= 

TestTimeServerImpl.ObjTimeServer_var.narrow(obj); 

... 

System.out.println(timeServer.getTime()); 

} 

catch (CORBA.SystemException e){ 

System.err.println(e); 

} 

} 

};

Beispiel: Ausführung 


C:\> 

java TimeServer_Server 

IOR:00000000000122342435 ... 

C:\> java TimeServer_Client IOR:00000000000122342435 ... 

Time: 14:35:44

I.2.1.2 Corba Dienste (Corba services) 


• OMG. CORBAservices: Common Object Service Specifications. Version 

vom Dez. 98. 

http://www.omg.org/technology/documents/formal/corbaservices.htm 

oder 

http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm

Überblick Corba Dienste (services) 

• Wiederverwendbare Bibilotheken oft benötigter Funktionen 

• Dienst ist Komponente 

(im Corba-Jargon: Objekt, definiert in IDL) 

• Eingeteilt in 

◮ Objektdienste 

Verwalten Komponenten (im Corba-Jargon: Objekte) 

◮ Zusammenarbeitsdienste 

Unterstützen die Zusammenarbeit von Komponenten 

◮ Geschäftsprozeßdienste 

Funktionalität für Geschäftsanwendungen 

• Umsetzung 

◮ Nicht jeder ORB-Anbieter unterstützt alle Dienste 

◮ http://www.cetus-links.org/oo_object_request_brokers.html 


Objektdienste 

• Namen (directory service) 

◮ Das Dateisystem (directory tree) ist eigentlich ein Namensdienst. 

◮ Auf beliebige Internet-Objekte ausdehnbar. 

• Allokation (lifecycle service) 

◮ keine Semantik bei Deallocation 

◮ keine Destruktoren 

• Eigenschaften für Objekte (property service) 

• Persistenz 

◮ Objektzustand bleibt über Programmaufrufe erhalten 

• Serialisierung in Ströme (externalization) 

• Relationen (relationship service) 

◮ Relationen, Rollen, Kanten sind Objekte 

◮ Standardrelationen reference, containment 

◮ Standardrollen references, referenced, contains, containedIn 

• Behälter (collections) 



Wiederholung: Rückruf und Ereignisse 

Example: Callbacks and Events I 

abstract solution 

goal: communication client-server whenever a situation 

(event, state change) arises at the server requiring action 

• Ziel: Kommunikation zwischen Dienstnehmer und Dienstgeber, wenn eine 

Situation by the client (Ereignis, Zustandsübergang) im Dienstgeber Aktivität des 

Dienstnehmers erfordert 

abstract solution: introduce event server between client and 

• Abstrakte Lösung: Ereignisdienst als Zwischenschicht einführen 

server 

event 

client 

server 

server 

◮ Dienstnehmer abonniert relevante Ereignisse beim Dienstgeber 

◮ ‘‘relevant’’ 

client notifies 

durch 

event 

Nebenbedingungen 

server in advance about 

weiter 

all events 

einschränkbar 

of interest 

◮ Dienstgeber “interest” may benachrichtigt constraint by Dienstnehmer mentioning additional über conditions Ereignisse (mit 

Nutzdaten) 

server notifies event server about all incoming events (state 

changes) including additional information 

◮ Ereignis kann keinen, einen, oder beliebig viele Dienstnehmer erreichen 

event server may notify zero, one or several clients about the event 

◮ Synchrone oder asynchrone Benachrichtigung 

notification by event server may be synchronous or asynchronous 

◮ Ereignisdienst oft im Dienstgeber integriert (Ereignisschleife) 

event server often integrated into the server (“event loop”) 


Zusammenarbeitsdienste 

• Kommunikation 

◮ Rückrufservice (callbacks) 

◮ Ereignisse über entsprechende Kanäle 

Rollen von Komponenten auf Kanälen 

· Schiebt Ereignisse in den Kanal (push) 

· Zieht Ereignisse aus dem Kanal (pull) 

• Parallelität 

◮ Sperren (concurreny service) 

Einzelne oder Mengen von Sperren 

Innerhalb von oder ohne Transaktionen 

◮ Transaktionen (object transaction service, OTS) 

Flache und geschachtelte Transaktionen über Objektgraphen 


Geschäftsprozeßdienste 

• Makler (Händler, trading service) 

◮ Gelbe Seiten 

◮ Lokalisierung von Diensten mittels Dienstbeschreibungen 

• Abfrage (query ) 

◮ Suchen von Komponenten 

◮ Mit Attributen und OQL, SQL (ODMG-93) 

• Lizenzierung von Komponenten 

◮ license managers, license service 

• Sicherheit 

◮ Einsatz von SSL und anderen Basisdiensten 

◮ Alle ORBs arbeiten zusammen 


Abhängigkeiten zwischen den Diensten 


Abhängigkeiten zwischen den Diensten 

Transaktionen 

Makler 

Query 

Lizenzen 

Persistenz 

Serialisierung 

Sicherheit 

Container 

Allokation 

Sperren 

Rückruf 

Eigenschaften 

Namen 

Relationen 

Ereignisse 


Entwurfsprinzipien für Dienste 

• Normiert: funktionale Schnittstelle 

• Offen: nichtfunktionale Eigenschaften (QoS, . . . ) 

• Orthogonalität von Diensten 

◮ Selbstanspruch des Standards 

◮ KISS (keep it simple, stupid) 

• Arbeit auf Komponenten (CORBA::Object) 

◮ Prinzipiell: Beliebige Komponenten 

◮ Dienstdefinition schränkt evtl. ein. 

◮ Reflektion über Komponenten möglich 

• Verschiedene Sichten auf einen Dienst 

• Prinzipien für Schnittstellendefinition 

◮ Ausnahmebehandlung wird benutzt 

◮ Operationen sind explizit (nicht durch Flags parametrisiert) 

◮ Mehrfachvererbung von Schnittstellen 


Objektdienste: Namen 

• Bindet Namen an Komponenten 

• Namen sind keine Komponenten (Corba-Jargon: Pseudoobjekte) 

• Bindung erfolgt in einem Namensraum (scope, naming context) 

◮ Komponente, die eine Menge von Bindungen enthält. 

◮ Wechselseitige Bezüge möglich (Namensgraphen) 

• Corba definiert eigenes Namensschema 

◮ Not invented here: keine Wiederverwendung von URLs etc. 

◮ Angestrebt: transparente Umsetzung möglich 

◮ Bibiliothek zur Manipulation von Namen (Entwurfsmuster Fabrik) 

◮ Name ist Tupel (id, type) 

id: eigentlicher Name 

type: Repräsentation (z.B. c_source, object_code, . . . ) 

· Nur von der Anwendung manipuliert 

• Ein Dateisystem bildet einen einfachen Namensraum 


Namensdienst 


Namensdienst 

CosNaming::NamingContext 

-bind(in Name n, in Object obj) 

-rebind(in Name n, in Object obj) 

-bind_context 

-rebind_context 

-Object resolve 

-unbind(in Name n) 

-NamingContext new_context; 

-NamingContext bind_new_context(in Name n) 

-void destroy 

-list 


IDL Namensdienst 


module CosNaming{ 

typedef string Istring; 

struct NameComponent { 

Istring id; 

Istring kind; 

}; 

typedef sequence Name; 

enum BindingType { nobject, ncontext }; 

struct Binding { 

Name binding_name; 

BindingType binding_type; 

}; 

typedef sequence BindingList; 

interface BindingIterator; 

interface NamingContext; 

} 

interface BindingIterator { 

boolean next_one(out Binding b); 

boolean next_n(in unsigned long how_many, 

out BindingList bl); 

void destroy(); 

}; 

interface NamingContext { 

enum NotFoundReason { missing_node, 

not_context, not_object 

}; 

exception NotFound { 

NotFoundReason why; 

Name rest_of_name; 

}; 

exception CannotProceed { 

NamingContext cxt; 

Name rest_of_name; 

}; 

exception InvalidName {}; 

exception AlreadyBound {}; 

exception NotEmpty {}; 

// continued on next page

IDL Namensdienst 


void bind(in Name n, in Object obj) 

raises( NotFound, CannotProceed, InvalidName, 

AlreadyBound ); 

void rebind(in Name n, in Object obj) 

raises( NotFound, CannotProceed, InvalidName ); 

void bind_context(in Name n, in NamingContext nc) 

raises( NotFound, CannotProceed, InvalidName, 

AlreadyBound ); 

void rebind_context(in Name n, in NamingContext nc) 


Object resolve(in Name n) 


void unbind(in Name n) 


NamingContext new_context(); 

NamingContext bind_new_context(in Name n) 

raises( NotFound, AlreadyBound, CannotProceed, InvalidName ); 

void destroy() 

raises( NotEmpty ); 

void list(in unsigned long how_many, 

out BindingList bl, out BindingIterator bi ); 

}; 

};

Erzeugen von Namen 


Systemabhängiger 

Name 

Erzeuge Name 

Suche / Erzeuge 

Namensraum 

Corba-Name 

Corba- 

Namensraum 

Binde 

Komponente 

(Corba-Objekt) 

Suche Name

Namensdienst: Beispiel 


// Quelle: Redlich, Calculator example 

class MyNaming extends CosNaming { 

// ... 

} 

public class Client extends Frame { 

private Calc5.calc.Ref calc; 

private TextField inR, inI; 

private Button setB, addB, multB, 

divB, quitB, zeroB; 

public static void main(String argv[]) { 

CosNaming.NamingContext.Ref cxt; 

Calc5.calc_factory.Ref cf; 

Frame f; 

} 

try { 

cxt= NamingContext._narrow(MyNaming. 

resolve_initial_references( 

MyNaming.NameService)); 

cf=Calc5.calc_factory._narrow( 

cxt.resolve(MyNaming.mk_name( 

"calcfac"))); 

f= new client(cf.create_new_calc()); 

f.pack(); 

f.show(); 

} catch (Exception ex) { 

System.out.println("Calc-5/Init:"+ 

ex.toString()); 

}

Naming 


public class MyNaming { 

public static final String NameService = "NameService"; 

public static IE.Iona.Orbix2.CORBA.Object.Ref 

resolve_initial_references(String id) { 

ORB orb = _CORBA.Orbix; 

if(id.compareTo(NameService)!=0) 

return NamingContext._nil(); 

try { 

File inputFile = new File("/tmp/coss-naming/root"); 

FileInputStream fis = new FileInputStream(inputFile); 

DataInputStream dis = new DataInputStream(fis); 

... 

return orb.string_to_object(obj_ref); 

} catch(Exception ex) { 

System.out.println("CosNaming:Init:" + ex.toString()); 

} 

return NamingContext._nil(); 

} 

public static Name mk_name(String str) { 

int last, k, i= 0; 

... 

return name; 

} 

}

Objektdienste: Eigenschaftsdienst 


• Mechanismus für dynamische Erweiterungen 

• Eigenschaften (properties) sind Tupel von Strings (name, value) 

• Dienst verwaltet Eigenschaften von Komponenten 

komponente1: ("makelbar" , "ja") 

("kategorie", "geschäftsdienst") 

• Konzept bekannt: 

◮ assoziative Arrays 

◮ LISP property lists 

◮ Java property classes 

• Iteratoren für Eigenschaftswerte 

• Verfeinerung PropertySetDef 

◮ Definierte Semantik für: readonly, fixed_readonly, . . . 

• Schnittstelle: define_property, define_properties, get_property_value, 

get_properties, delete_property, . . .

Objektdienste: Persistenz 

• persistent object identifier PID 

◮ Identifiziert persistente Komponente auf Speichermedium 

• Persistenzdienst 

◮ Zuordnung IOR ↔ PID 

◮ Protokoll zum Speichern auf/Laden von Speichermedium 

• Operationen connect, disconnect, store, restore, delete 

• Anbindung beliebiger Speicherwerkzeuge möglich 

◮ Relationale Datenbanken 

◮ Dateisystem 


Zusammenarbeitsdienste: Ereignisse 

• Ausprägung der Nutzerrollen Producer und Consumer 

◮ push: Ablegen aktiv / Auslieferung automatisch 

◮ pull: Ablegen auf Anfrage / Auslieferung auf Anfrage 

• Ereigniskanal-Komponenten als optionale Zwischeninstanzen 

◮ puffern, vermitteln, replizieren, filtern Ereignisse 

◮ Anpassung von push und pull 

◮ Optionale Typisierung mit IDL (separate Schnittstellen) 

• Vorteile: 

◮ Asynchrones Arbeiten möglich (IIOP, dynamischer Aufruf) 

◮ Einfache Anbindung: Java (seit 1.2), Altsysteme . . . 

• Nachteile: 

◮ Untypisierte Schnittstelle zu allgemein 

◮ Jede typisierte Schnittstelle separat (Mehraufwand) 


Zusammenarbeitsdienste: Transaktionen 

• Standard-Datenbanktechnik 

◮ Einfache Transaktionen 

begin 

rollback 

commit (two-phase-commit) 

◮ Geschachtelte Transaktionen 

Zusätzliche Hierarchie 

• Beispiele 

◮ Bankkonten als Komponenten 

Operationen Abheben, Einzahlen 

Überweisung ist Transaktion über zwei Komponenten 

◮ Webseiten 

Bidirektionale Verweise 

Wie erziele ich Konsistenz? 


Geschäftsprozeßdienste: Lizenzen 

• Lizenzmodelle für kommerzielle Komponenten 

◮ Einzelnutzung (one-time license) 

◮ Einzelplatzlizenzen 

◮ Übertragbare Lizenzen (floating licenses) 

◮ Netz-/Campuslizenzen 

• Dienst: Abstrakte Fabrik für Lizenzmanager 

◮ Ermöglicht individuelle Modelle für beliebige Komponenten 

◮ Flexibilität ohne Änderung der Anwendung 

• Feingranulare Lizenzen 

◮ Bezahlung durch ORB-Anfragen 

◮ Nutzungsart unterscheidbar (kommerziell, private) 

◮ Micropayments für Komponenten möglich 

(nicht allgemein etabliert) 


Geschäftsprozeßdienste: Makler 


Geschäftsprozessdienste: Makler 

Makler handeln mit 

Diensten (services, 

service types) 

Makler 

Vermittlermuster 

Exportiere 

Funktionalität 

Importiere 

Funktionalität 

Dienst 

Interagiere 

Kunde 



Ersetzen von Diensten (Konformität)? 

Wann ein Dienst gegen anderen ersetzen 

(Konformität)? 

gleiche Schnittstelle oder abgeleitete Schnittstelle 

alle Sucheigenschaften identisch definiert 

• gleiche Schnittstelle – keine Properties oder abgeleitete vom Corba Schnittstelle Dienst Properties 

• alle Sucheigenschaften identisch definiert 

◮ keine Properties vom Corba Dienst Properties 

• alle Modi der Eigenschaften stärker oder gleich 

alle Modi der Eigenschaften stärker oder gleich 

Mandatory, readonly 

Mandatory 

readonly 

(normal) 


Makler: Dienstangebote 

• Dienstangebot: Paar aus IOR und Eigenschaften 

• Eigenschaften 

◮ von Maklern genutzt für Anfragen nach Diensten 

◮ Dynamische Eigenschaften (!) 

• Zum Vergleich spezielle Anfragesprache 

(standard constraint language) 

◮ boolesche Ausdrücke über Eigenschaften 

◮ numerische und Stringvergleiche 

• Findet ein Makler keinen passenden Dienst 

◮ kann er Nachbarn beauftragen (Entwurfsmuster Zuständigkeitskette, 

chain of responsibility ) 

◮ Dazu ist ein Graph aus Maklern aufgebaut 

◮ Filtern beim Weitergeben der Dienstsuchanfrage 


Dienst-Hüpfen (hopping) 


Dienst-Hüpfen (hopping) 

Makler 1 

Fluß der 

Eigenschaften 

der Dienstanfrage 

Angebote der Makler 

Policies, die die Werte 

der Eigenschaften der 

Dienstanfrage verändern 

Makler 2 

Makler 4 

Makler 3 


Suche nach Diensten 


Suche nach Diensten 

• policy : Parametrisierung von der Maklern Dienstgüte und Links durch sog. policies. 

policies beeinflussen verschiedene Phasen von Suche und Weitergabe, z.B. 

• Bei Maklern: Anwendung auf Suche und Weitergabe 

– max_search_card: Obergrenze für zu suchende Angebote 

◮ max_search_card: Obergrenze für durchsuchte Angebote 

– max_match_card: Obergrenze für Rückgabe passender Angebote 

◮ max_match_card: – max_hop_count: Obergrenze Obergrenze zurückzugebender für Suchtiefe über Makler Ergebnisse 

◮ max_hop_count: Obergrenze für Suchtiefe über Makler 

Mögliche 

Angebote 

Kardinalitäten 

für Suche 

Betrachtete 

Angebote 


für Matchen 

Gefundene 

Angebote 

Angebote 


für Rückgabe 

Mögliche 

Angebote 


Makler: Schnittstellen 

• Schnittstellen 

◮ Lookup (Anfragen stellen) 

◮ Offer Iterator 

◮ Register (zum Export und Zurückziehen von Diensten) 

◮ Link (Aufbau des Maklernetzes) 

◮ Proxy (Stellvertreter-Objekte, die Makler vertreten) 

Stellvertretung für andere Makler 

Erlaubt Kapselung von Altsystemen 

◮ Admin (Eigenschaften von Dienste) 

Lookup.Query( 

in ServiceTypeName,in Constraint, in PolicySeq, 

in SpecifiedProps, in howMany, 

out OfferSequence, out offerIterator 

) 


Maklerarten 


Maklerarten 

Lookup 

Lookup 

Register 

LookupRegister Admin 

Anfragemakler 

(query trader) 

Einfacher 

Makler 

(simple trader) 

Selbständiger 

Makler 

(standalone 

trader) 

Lookup Register Admin 



Sozialer Makler 

(linked trader) 

Stellvertreter 

Makler 

(proxy trader) 

Komplett- 

Makler 

(full-service 

trader) 

Link 

Proxy 

Link 

Proxy 


I.2.1.3 Corba facilities 

• Horizontale (general) facilities 

◮ Dienste, Werkzeuge 

◮ Unabhängig von Anwendungsbereich 

◮ Spezifikation durch OMG 

◮ Kenntnis nützlich 

◮ Abgrenzung zu Corba services unklar 

• Vertikale (domain-specific) facilities 

◮ Rahmensysteme, Schnittstellen 

◮ Spezifisch für einen Anwendungsbereich 

◮ Spezifikation durch Industriegremien 

Domain Technology Committee (DTC) gründet 

Domain Task Forces (DTF), die spezifizieren 

◮ Bei Bedarf nachschlagen 


Einige Beispiele 


Einige Beispiele 

Vertikal 

Electronic 

Commerce 

Telecom Manufacturing Utility 

Financial Transportation Simulation Life Sciences 

Horizontal 

MOF XMI Data 

Warehouse 

Business 

Objects 


Beispiele für general facilities 

• Benutzerschnittstellen 

◮ Drucken 

◮ email 

◮ Verbunddokumente: Seit 1996 OpenDoc. Source Code ist frei. Tot? 

◮ Scripting: ab Corba 3.0 

• Informationsmanagement 

◮ strukturierter Speicher Bento 

◮ Metadaten (meta object facility, MOF) 

◮ Datentransfer: text- und strombasiertes Austauschformat (XMI) 

• Systemmanagement (Instrumentierung, Monitoring) 

• Task management (Workflow, Regeln, Agenten) 


Metaobject Facility (MOF) 

• Problem: IDL für viele Anwendungen unbekannt 

◮ Annahme: Beschreibung vorhanden (UML, OMT, . . . ) 

◮ Ansatz: Auffassen als Typsystem, IDL erzeugen 

◮ Nötig: Beschreibungssprache für Typsysteme 

• CORBA-Lösung: MOF 

◮ Meta-Typsystem 

◮ Beschreibt IDL und andere Typsysteme 

◮ Standardisiert November 1997 

• Neue Möglichkeiten 

◮ Erzeugen allgemeiner Anpasser 

◮ Zusammenarbeit heterogener CASE-Werkzeuge 

◮ Einbindung weiterer Typsysteme in Corba 


Metadaten 


Metadaten 

Meta: griech. darüber, jenseits 

Metadaten: Daten über Daten 

• Meta: griech. – Datenbeschreibung 

darüber, jenseits 

• Metadaten: – Modellierung Daten über Daten 

◮ Datenbeschreibung 

– Können reflexiv sein 

◮ Modellierung Reflektion: Programm greift auf 

◮ Können Metadaten reflexivzusein 

• Reflektion: Selbstmodifikation Programm greift (intercession) 

auf Metadaten kann Erkenntnisse zu nutzen 

• Selbstmodifikation kann 

Erkenntnisse nutzen 

Metadaten 

Metadaten 

Beschreiben 

Daten, 

Daten, 

Code 

Code 

Ändern 

Zugriff 

Metaebene 

(Konzeptebene) 

Realität 


Beschreibungsebenen 


• Hierarchie von Beschreibungsebenen 

• Reale Objekte (Akte, Ordner etc) 

• Programmobjekte (CORBA Objekte) 

• Typen (int, char, zusammengesetzte IDL Typen etc) 

• Typsysteme (IDL oder UML) 

• MOF beschreibt Typsysteme

Reflektion und Selbstmodifikation 


Reflektion: 

for all c in self.classes do 

generate_class_start(c); 

for all a in c.attributes do 

generate_attribute(a); 

done; 

generate_class_end(c); 

done; 

Selbstmodifikation: 

for all c in self.classes do 

helpClass = makeClass(c.name+"help"); 

for all a in c.attributes do 

helpClass.addAttribute(copyAttribute(a)); 

done; 

self.addClass(helpClass); 

done; 

Reflektion bietet Zugriff auf Typinformationen 

für ein Programm. Es wird 

dabei nicht geändert. 

Selbstmodifikation ändert das laufende Programm 

anhand reflektierter Information.


Ausspähen (Introspection) 

Ausspähen (Introspection) 

• Falscher Sprachgebrauch: gemeint ist inspection 

• Spezialfall der Reflektion: über fremde Komponenten 

• Bestimmen Bestimmen semantikbehafteter semantikbehafteter Eigenschaften Eigenschaften 

• Wichtig für den Web-Komponenten-Supermarkt 

Spezialfall der Reflektion: über fremde Komponenten 

Wichtig für den Web-Komponenten-Supermarkt. 

Metadaten 

Metadaten 

Metaebene 

(Konzeptebene) 

Zugriff 

Beschreiben 

Realität 

Daten, 

Daten, 

Code 

Code 

Daten, 

Daten, 

Code 

Code 

Ändern

Zusammenfassung MOF 


• Unterstützt beliebige Typsysteme 

• Hinzufügen neuer, komponieren oder erweitern alter Typsysteme 

• Beziehungen innerhalb und zwischen Typsystemen 

• Interoperabilität zwischen Typsystemen und -repositorien 

• Automatische Generierung von IDL 

• Reflektion/Inspektion unterstützt 

• Anwendung auf Arbeitsflüsse (workflows), Datenbanken, Groupware, 

Geschäftsprozesse, data warehouses wird untersucht 

• http://www.dstc.edu.au/MOF 

• Unklar: Reflektion auf IDL möglich, warum Metaebene? 

◮ IDL vollständig → MOF überflüssig 

◮ IDL unvollständig → IDL erweitern

XMI 

• Problem: Austausch von Metadaten zwischen Werkzeugen 

◮ Eigentlich durch MOF gelöst 

◮ Format nicht zumutbar? 

• Lösung: Abbildung auf grundlegenderen Standard 

◮ XML Metadata Interchange (XMI) 

◮ Typsystem in MOF → XML 1.0 DTD oder XML Schema (XMI 

Schema) 

◮ Typen im Typsystem → DTD- oder Schema-konformes XML 

◮ Anpassungen möglich, da alle Typsysteme auf MOF beruhen 


Vorteil von XMI 


Design 

Software 

Assets 

App1 

App2 

Development 

Tools 

XMI 

Repository 

App6 

App3 

Database 

Schema 

Reports 

App5 

App4 

6 Brücken von 6 Herstellern N*N-N = 30 Brücken

Überblick XMI 


Überblick XMI 

MOF 

MOF 

MetametaModell 

MetametaModell 

Metadata Definitionen 

Metadata Definitionen 

& Management 

& Management 

UML 

UML Instanz 

CWM 

UML Instanz 

MOF 

UML Instanz 

XML Austauschströme (Modelle) 

XML Austauschströme (Modelle) 

UML 

UML 

Metamodell 

Metamodell 

Analysis & Design 

Analysis & Design 

X 

X 

M 

M 

I 

I 

UML 1.1 

DTD 

CWM 

DTD 

MOF 

1.1 

DTD 

XML 

XML 

Syntax 

Syntax 

XML DTD (MetaModels) 

XML DTD (MetaModels) 

(spezifisch pro Typsystem) 

(spezifisch pro Typsystem) 


XMI als Zwischenrepräsentation 

` 


XMI als Zwischenrepräsentation 

MOF 

MOF 

CaseTool 

CaseTool 

CaseTool- 

CaseTool- 

DTD 

DTD 

UML-DTD 

UML-DTD 

UML 

UML 

UML- 

UML- 

Spezifikation 

Spezifikation 

(in UML) 

(in UML) 

CaseTool- 

CaseTool- 

Spez. 

Spez. 

in XML 

in XML 

Abfrage/Navigatin 

Abfrage/Navigation 

n 

durch WebQL, 

durch WebQL, 

XML-QL 

XML-QL 

Umwandlung 

Umwandlung 

durch 

durch 

XML- 

XML- 

Leser/Schreiber 


Darstellung mit 

Darstellung mit 

Style Sheets 

Style Sheets 

in Browsern 

in Browsern 

CaseTool- 

CaseTool- 

Spezifikation 

Spezifikation 

Umwandlung 

Umwandlung 

durch 

durch 

XML- 

XML- 



UML-Spez. 

UML-Spez. 

In XML 

In XML 

(Seite) 

(Seite)


Ein reales Austauschszenario 

Ein reales Austauschszenario 

Web 

Sphere 

Rose 

Team 

Connection 

DTD 

Gen 

VA 

Java 

Oracle 

XMI 

IBM 

VisualAge 

XMI 

Repository 

XMI 

XMI 

Select 

XMI 

Oracle 

Designer 

XMI 

Rational 

Rose 

Unisys 

UREP 

XMI 

MOF 

DTDGen 

XMI 

Select 

Enterprise 

XMI 

Enterprise 

Aus: S. Brodsky, OMG XMI Briefing, 

Feb 5, 1999

Literatur 


• Orfali, Harkey: Client-Server Programming with Java and Corba. Wiley. 

Schön zu lesen. Empfehlenswert zur Prüfungsvorbereitung. 

• Orfali, Harkey: Instant Corba. Addison-Wesley. Nachttisch-Lektüre. 

Empfehlenswert zur Prüfungsvorbereitung. 

• OMG: CORBAfacilities: Common Object Facilities 

Specifications.http://www.omg.org/ 

• XMI - The Value of Interchange. Dr. Stephen A. Brodsky, IBM, Vortrag 

am 5.2. 1999, OMG XMI Briefing 

• Overview of XMI. Sridhar Iyengar, Unisys Corporation, 5.2.99, OMG XMI 

Briefing, 

• XML Metadata Interchange (XMI) Proposal to the OMG RFP3: 

Stream-based Model Interchange Format SMIF. OMG, 20.10.98 

http://www.omg.org/

Gliederung 








2. CORBA 






Kommunikation 


Protokolle 






Java und Enterprise Java Beans 


• Arnold, Gosling. Java Language Specification, 2. Auflage, 2000. Privat 

einmal ausdruckbar. http://java.sun.com/docs/books/jls/index.html 

• JavaSoft. Java Beans Specification. www.javasoft.com. Gut lesbar, schöne 

Einführung zu den Konzepten. 

• JavaSoft. Enterprise Java Beans Specification 2.0. www.javasoft.com. Der 

Standard. v2.2 ist Proposed Public Draft. 

• Richard Monson-Haefel. Enterprise JavaBeans. O’Reilly, 1999. Leicht 

zugängliche Einführung.

Geschichte von Java 


• Ursprung: Eingebettete Systeme für Hausgeräte 

◮ Neue Sprache an C++ angelehnt 

◮ Reduktion der Komplexität 

◮ Exakt und sauber spezifiziert 

• Verbreitung durch Java-Applets in Netscape (1994) 

◮ Java benutzt das Web als Zugpferd, so wie C UNIX 

◮ Write once, run anywhere (WORA) durch Virtual Machine 

◮ Frei nutzbar, doch feste Schnittstellen (Lizenzvertrag) 

• Klassenbibliotheken: 

◮ AWT, Swing (GUI) 

◮ Java Beans (1997) 

◮ Enterprise Java Beans (1998/99)

Spracheigenschaften 

• Objektorientiert 

• Mehrfachvererbung von Schnittstellen 

• Einfachvererbung von Code 

• Automatische Speicherbereinigung 

◮ Speicher ist uniforme Halde 

◮ Benutzerdefinierte Verwaltung unmöglich 

• Keine Zeiger, nur Referenzen 

◮ Keine Funktionsparameter 

◮ Callbacks durch Hilfsklassen möglich 

• Synchronisation mit Monitoren 

• Einfaches, hierarchisches Paketkonzept 

◮ Entspricht Namensräumen 

• Keine Generizität 

• Extraktion von Dokumentation (javadoc) 


Laufzeitumgebung 

• Java Virtual Machine 

◮ Abstraktion von konkreter Maschine und Plattform 

◮ prinzipiell sprachunabhängig 

◮ Übersetzer für andere Sprachen, z.B. 

ADA, COBOL, ECMAscript, Eiffel, Scheme, . . . 

• Java Bytecode 

◮ Stapelorientiert (Interpretation durch Java Virtual Machine) 

◮ Plattformunabhängig 

◮ Volle Typinformation 

◮ Sicherheit durch bytecode verifier prüfbar 


Klassen und Dateien 

• Einbettung in Dateisystem 

◮ Eine öffentliche Klasse pro Datei 

◮ Pakete entsprechen Verzeichnissen 

◮ Auffindung: Suchpfad CLASSPATH 

Definiert Abbildung von Namen auf Klassen 

Primitive Registrierdatenbank 

Pendant zu CORBA interface/implementation repositories 

Eintragen von Klassen durch Kopieren im Dateisystem 

• Java Archive Format (JAR) 

◮ Im Prinzip ZIP 

◮ Klassendateien 

◮ Serialisierte Objekte 

◮ Dokumentation 


Dienste der Bibliothek 


• Parallelität mit java.lang.Thread 

• Ereignisse mit EventListener 

• Persistenz durch Serialisierung mit java.io.ObjectOutputStream 

• Verteilung mit Java RMI 

• Makeln mit Java Intelligent Network Infrastructure (JINI) 

• Anbindung fremder Sprachen über Java Native Interface (JNI) 

• Enterprise APIs: normierte Schnittstellen zu (Fremd-)Diensten 

◮ Namen über Java Naming Directory Interface (JNDI) 

◮ Datenbankzugriff über Java Database Connection (JDBC) 

◮ Transaktionen mit Java Transaction Server (JTS) 

• Java Spaces (Tuple space à la LINDA, typisierte Whiteboards) 

• Reflektion mit Klassenobjekten java.lang.Class 

◮ Zugriff auf Felder mit java.lang.Field 

◮ Zugriff auf Methoden mit java.lang.Method

Kardinalproblem Leistung 

• Sprache teilweise überdefiniert 

◮ Reihenfolge der Operanden- und Parameterberechnung 

◮ Reihenfolge von Ausnahmen 

• Bytecode ist Kellerarchitektur 

◮ gut interpretierbar 

◮ schlecht auf reale Maschinen abzubilden 

Registerzuteilung 

Superskalarität 

Codeauswahl 

• Nur primitive Skalare als Wertetypen / primitive Typen nicht als 

Objekttypen 

◮ Objektidentität ist Overhead (Objekte min. 32 Byte) 

◮ Objekterzeugung ist teuerste Operation 


Standardisierung 

• Java gehört Sun Microsystems 

◮ Definition von Schnittstellen in einem öffentlichen Prozess 

◮ Jeder kann Vorschläge einbringen 

◮ Java Community Process, Java Developer Connection 

◮ Ziel: Abwenden von Zersplitterung durch Konkurrenten 

• Ob Java ein ISO-Standard wird, ist fraglich 

◮ Standard eingereicht, dann zurückgezogen 

• Was passiert, wenn ein proprietäres Java den Markt dominiert? 


Einordnung von Java in unser Komponentenmodell 


◮ Nein (daher IDL unnötig) 

• Plattformtransparenz 

◮ Ja (durch Java VM) 


◮ Teils (Java RMI vorhanden, uniforme Referenz fehlt) 

• Reflektion 

◮ Dynamisch (mit java.lang.Class) 

• Dienste 

◮ Namen, Datenbanken, . . . 

◮ Keine typisierten Behälterdatentypen 

• Also: beinahe ein Komponentensystem 


JavaBeans 

• Erste Komponentenarchitektur für Java (1997) 

• Ziel: Visuelle Komposition in Entwicklungsumgebungen (IDE) 

◮ motiviert durch Borland/Inprise Delphi 

• Problem: Schnittstellen benutzerdefinierter Komponenten 

◮ Java Reflection findet alle öffentlichen Methoden und Felder 

◮ Viele sind nicht Teil der GUI-Schnittstelle 

• Problem: Große Systeme brauchen statische Typprüfung 

◮ Reflection → dynamische Typprüfung 

• Ansatz: 

◮ Konventionen für benutzerdefinierte Schnittstellen 

◮ Metainformationen speichern 

◮ Codeerzeugung 


Bean und BeanInfo 

• Bean 

◮ Enthält Funktionalität 

◮ Standardisierte Namensgebung 

set/getXXX für Attribute 

add/RemoveXXXListener für Ereignisse 

◮ Unterstützung für Ereignisadapter 

• BeanInfo 

◮ Enthält Metainformation über Attribute, Ereignisse 

◮ Erlaubt Reflektion über Beans 

• Problem: Annotation schwach 

◮ Nichtfunktionale Eigenschaften nur über Namensgebung 

◮ Nicht zur Laufzeit erweiterbar 


XML Beans 


• Lösung: BeanInfo in erweiterbarem Format kodieren 

• IBM Bean Markup Language nutzt XML 

 

 

 

 

• Auch Komposition, Referenzen auf Beans 

• Serialisierung von Java-Objekten als XML-Daten 

• BML Compiler komponiert statisch 

• Siehe www.alphaworks.ibm.com

Zusammenfassung: Java Beans 






◮ Nein (Java RMI nicht genutzt) 


◮ Dynamisch und statisch 

• Dienste 

◮ Grundlegende GUI-Komponenten 

◮ Keine Namen, Datenbanken, . . . 

• Also: eher ein Rückschritt gegenüber Java in unserem Modell 

• Heute hauptsächlich als Grundlage von enterprise beans und von 

historischem Interesse 


Enterprise JavaBeans (EJBs) 

• Ziel: Industrielles Komponentenmodell für Java 

◮ Sprachspezifisch 

◮ Plattformtransparent 

◮ Ortstransparent 

◮ Dienste: Namen, Persistenz, Transaktionen, Ressourcen, . . . 

• Weitere Vorgaben 

◮ Dynamische Dienstanbindung: Komposition ohne Übersetzen 

◮ Offene Anbindung fremder Komponenten und Werkzeuge 

Normierte Schnittstellen zu Fremdlösungen (z.B. JNDI, JDBC) 

Anbindung an CORBA 

• Gemeinsamkeiten mit einfachen JavaBeans 

◮ Name 

◮ Namensgebung der Schnittstellen 


EJBs, Behälter und Deskriptoren 


• EJBs sind Komponenten, die ein EJB Interface implementieren. Sie 

bestehen aus bestimmten Klassen, für 

◮ Lebenszyklus 

◮ Geschäftsfunktionalität 

◮ entfernte oder lokale Zugriffe 

◮ Beschreibung durch XML Deployment Descriptors 

• Verpackt als EJB JAR 

◮ Klassenbytecode 

◮ Deployment Descriptor 

• Behälter (Bean Container ) enthalten Komponenten 

◮ Auffindung 

◮ Stellt Ausführungskontext bereit, z.B. thread 

◮ Kontrolle aller Außenkontakte 

◮ Verwaltet Lebenszyklus, Persistenz von Zuständen 

◮ Sicherheits- und Transaktionsverwaltung 

• Server (Bean Server ) enthalten Container 

◮ Verwalten und koordinieren Ressourcenzuteilung 

◮ Zugriff auf Systemdienste


Szenario 

Szenario 

EJB 

Aardvark 

Lohnbuch 

Jar 

Assembling 

Berdvark 

Dienst 

Berdvark 

Datensatz 

Aardvark 

Lohnbuch 

Jar mit Kompositionsanweisungen 

Deployment 

Web 

Server 

Berdvark 

Dienst 

Cerdvark 

FIBU 

Berdvark 

Datensatz 

Aardvark 

Lohnbuch 

Datenbank 

Formulare 

Angewendete EJB 

Cerdvark EJB Container 

Cerdvark EJB Server 

Altsysteme

Drei Sorten EJBs 

• Zustandslose Session Beans 

◮ Träger von Geschäftslogik 

◮ gebunden an eine Benutzersitzung 

◮ Klasse, kein Objekt, daher ununterscheidbar 

• Zustandsbehaftete Session Beans 

◮ wie oben, nur mit Zustand und damit unterscheidbar 

• Entity Beans 

◮ Träger von Geschäftsdaten 

◮ persistent 

◮ entsprechen meist einem Datenbankeintrag 

◮ Persistenz selbst oder durch Container verwaltet 


EnterpriseBeans aus Kundensicht 


Beans aus Kundensicht 


Die Kundenschnittstelle (client view) 

• Invariant bezüglich Server und Container 

• Heimatschnittstelle (erbt von javax.ejb.EJBHome) 

◮ Standardisiert 

◮ Auffinden von Beans mit JNDI 

◮ Erzeugen, Löschen 

◮ evtl. globale Identifikatoren mit getPrimaryKey() 

• Entfernte Schnittstelle (erbt von javax.ejb.EJBObject) 

◮ Definiert durch Anbieter der EJB 

◮ Bietet Geschäftsfunktionalität 

• Ab EJB 2.0: 

◮ Lokale Heimatschnittstelle: Finden und Erzeugen von Beans im selben 

Container. 

◮ Lokale Version der entfernten Schnittstelle: Funktionsaufrufe statt RMI 

◮ Behälter (Container) unterstützen auch behälterverwaltete 

Assoziationen 

• Metadaten (erbt von javax.ejb.Metadata) 

◮ zur Reflektion über die Bean 


Die Container-Komponenten-Schnittstelle 

• Entspricht CORBA BOA 

• Schnittstellen für Container und Komponente 

◮ SessionBean-Schnittstellen javax.ejb.SessionBean 

◮ EntityBean-Schnittstelle javax.ejb.EntityBean 

◮ Container-verwaltete Persistenz 

◮ Session-Kontext-Schnittstelle 

◮ JNDI-Namenskontext 

◮ Transaktionsverwaltung 


Deployment descriptor 

• EJB Eigenschaften 

◮ Namen: Name, Klasse, Name der Heimatschnittstelle, Name der 

Remote-Schnittstelle, Klasse des primären Schlüssels 

◮ Typ (session, entity ) 

◮ Zustand 

◮ Persistenzverwaltung 

◮ Referenzen auf andere EJB 

• Zusatzinformation für Anwendungsersteller 

◮ Name, Umgebungswerte, Beschreibungsfelder 

◮ Einbettung in Transaktionen 

• Deskriptor ist XML-Dokument zu spezieller DTD 


Beispiel: deployment descriptor 


 

 

This is an EJB 

 

Session bean 1 here 

EmployeeService 

com-wombat.empl.EmployeeServiceHome 

com.wombat.empl.EmployeeService 

com.wombat.empl.EmployeeServiceBean 

ejb-EmplRecords ... 

 

... 

... ... 

 

 

.... 

... 

... 

 

Anpassungen in der Deployment Phase 

• Erzeugung von Klassen 

◮ Implementierung des remote interface (Stub) 

◮ Lokale Handles und Klebecode (Skeleton) 

◮ Metadaten 

• Generierte Anpassungen 

◮ Anpassung Bean / Container 

analog zu CORBA BOA 

◮ Einweben von Aspekten aus dem deployment descriptor 

Persistenz 

Transaktionsverwaltung 

Komposition 


Entwicklerrollen bei EJB 

• Komponentenersteller (bean provider ) 

◮ Anwendungsexperte 

◮ Baut EJBs mit fachspezifischen Methoden 

• Anwendungsersteller (application assembler ) 

◮ Anwendungsexperte 

◮ Komponiert EJBs zu grösseren EJBs (Anwendungseinheiten) 

◮ Erweitert die Deployment-Deskriptoren 

• Einsetzer (deployer ) 

◮ Setzt die EJB in eine Umgebung ein 

◮ Umgebung = EJB Server und Container 

• EJB-Container-Hersteller (container provider ) 

◮ Spezialist für Konfiguration, Klebecode, Persistenz, . . . 

• EJB-Server-Hersteller (server provider ) 

◮ Spezialist für Systemdienste 

(oft identisch mit container provider ) 


Sitzungsbohnen (session beans) 

• Transient oder halb-transient 

• Ausgeführt auf Anfrage eines einzelnen Kunden 

(möglicherweise in Transaktion) 

• Stirbt mit dem Bohnen-Container 

• Zustandsbehaftet oder auch nicht 

• Passivierung bedeutet 

◮ Serialisierung aller Objekte, die transitiv von nicht-transienten 

Attributen aus erreichbar sind 

• Aktivierung bedeutet Deserialisierung. 

• Session-Kontext hält den jeweiligen Zustand fest 


Erzeugen von Sitzungsbohnen 


Erzeugen von Sitzungsbohnen 

Kunde 

EJB 

Heimat 

EJB 

Objekt 

Sitzungs- 

Kontext 

Instanz 

Create 

New 

New 

New 

SetSessionContext 

ejbCreate(args) 

Das ist nur eine 

von sehr vielen 

Protokollspezifikationen 

der EJB Standardkomponenten. 

Die Protok 

definieren zusätzlich zum 

Typcheck verschärfte 

Zusammensetzbarkeitskriterien. 


Dauerbohnen (entity beans) 


• persistent 

• mehrbenutzerfähig, transaktionsorientiert 

• globaler Identifikator (analog GUID, IOR) 

• ähnlich zu Corba-Objekten (und Monikers unter DCOM)

Szenario 


Context initialContext = new InitialContext(); 

CartHome cartHome = (CartHome)javax.rmi.PortableRemoteObject.narrow( 

initialContext.lookup("applications/mail/freds-carts"), 

CartHome.class); 

Cart cart = cartHome.create(...); // EJB spezifisch, vom Bohnenbauer spezifiziert 

cart.addItem(66); 

cart.addItem(44); 

// Speichere die Sitzungsbohne 

Handle cartHandle = cart.getHandle(); 

// ... serialisiere in Datei 

Handle cartHandle = .. deserialisiere von Datei 

Cart cart = (Cart)javax.rmi.PortableRemoteObject.narrow( 

cartHandle.getEJBObject(), Cart.class); 

cart.purchase(); 

cart.remove();

Zusammenfassung: Enterprise JavaBeans 






◮ Ja (durch remote interface) 


◮ Dynamisch und statisch 

• Dienste 

◮ Namen, Transaktionen, Datenbanken, . . . 

• Industriell sehr bedeutsames Komponentensystem 


JINI 

• Java intelligent network interface (JINI) 

◮ Dynamischer Aufruf, Dienstvermittlung 

◮ Dienstbeschreibung: Schnittstellen, Eigenschaften (properties) 

◮ Erzeuge Stellvertreter für Dienst auf Kundenseite 

◮ Nutzt RMI, JNDI, Migration 

◮ Verschickt Klassen im Bytecode 

• Makler suchen Dienste im Netz (lookup service LUS) 

◮ Verschiedene Suchprotokolle 

• Leases-Schnittstelle erlaubt Miete von Diensten 

• Organisation von Diensten in Gruppen 

◮ Ein Drucker kann sich der Hardware-, Drucker- oder Raum111-Gruppe 

zuordnen 


JINI - Generelles Schema 

• Anbieten 

◮ Suchen des Maklers (discovery ) 

◮ Anbieten beim Makler (join) 

◮ Dienst wird nur zeitbegrenzt angeboten (leasing) 

• Finden 

◮ Suche nach Makler (discovery ) 

◮ Suche nach Dienst (lookup) 

◮ Benutzung (use) 

• Also: nichts Neues unter der Sonne 


Zusammenfassung 

• Neu oder anders gegenüber CORBA: 

◮ Deployment Phase 

◮ Unterscheidung zwischen Sitzungs- und Dauerbohnen 

◮ Behälter statt ORB. Menge der Behälter kann man als ORB 

interpretieren. 


Gliederung: Industrielle Systeme 








2. CORBA 






Kommunikation 


Protokolle 






Literatur 


• Es scheint keine guten COM Bücher zu geben. 

• Don Box. Essential COM. Addison-Wesley. 1998. Viel zu detailliert, zu 

wenig abstrakte Konzepte. Eher ein Hacker Buch. 

• Plasil, F, Stal, M. An architectural view of distributed objects and 

components in CORBA, Java RMI, and COM/DCOM. Software - 

Concepts and Tools, 19: 14-28. Technischer Überblick. Recht knapp und 

gut. Empfohlen zur Prüfungsvorbereitung.

Wiederholung: Modell 

• Komponentenbegriff 

1. Eine Komponente ist eine Kollektion von Programmfragmenten mit 

einem Bauplan, um für eine bestimmte Aufgabe eine ausführbare 

Programmeinheit zu erzeugen. 


◮ Schnittstellen mit IDL beschreiben 


◮ Plattformunabhängiges Typsystem in IDL 


◮ Erzeugen von stubs und skeletons aus IDL 

• Reflexion 

◮ Ermitteln von Metadaten 

◮ Dynamischer Aufruf, Dynamische Erzeugung 

• Dienste 

◮ Namen, Lebenszyklus, Transaktionen, Datenbanken, . . . 


DCOM: Entwicklung 


• DCE (distributed computing environment) 

• OLE (object linking and embedding) 

◮ ActiveX (OLE-Erweiterung) 

• COM (component object model) 

• DCOM (distributed COM) 

Grenzen fließend!

DCE 


• Ursprung: OSF (open software foundation) 

◮ ähnlich Corba OMG 

◮ nicht dominiert durch Microsoft 

• Verteiltes Betriebssystem 

• Plattformunabhängig 

• Basiskommunikation via RPC 

• Konzept einer IDL 

• Generierte stubs, skeletons

COM 

Prof. Dr. G. Goos Software aus Komponenten Dr. Welf Löwe und Markus Noga 8 227 

• COM (component object model) 

• Komponentenarchitektur für Microsoft Windows (1993) 

• Schnittstellenbeschreibungen mit MIDL (Microsoft IDL), 

Wiederverwendete Technologie 

◮ aus DCE (distributed computing environment) abgeleitet 

◮ ähnlich CORBA IDL 

Object- 

Oriented 

Model 

Client/Server 

Model 

Dynamic 

Linking 

Component Object Model (COM)

OLE/ActiveX 

• OLE (object linking and embedding) 

• Ursprung: Microsoft Office, 1980er Jahre 

• Kernidee: Verbunddokumente 

◮ Primitive Dokumente 

(Spreadsheet, Graphik, Text, . . . ) 

◮ Werkzeuge zur Bearbeitung 

◮ Registratur speichert Werkzeuge 

◮ Einbettung von Dokumenten / Werkzeugen 

• Controls 

◮ Wiederverwendbare GUI-Komponenten 

◮ Zunächst lokal, mit ActiveX aus Internet geladen 


Ursprüngliche Trennung OLE und COM 


Ursprüngliche Trennung OLE und COM 

OLE 

application 

services 

Basis 

COM ist Basiskomponentenarchitektur für aufgesetzte Dienste 


Entwurfsziele für (D)COM 


• Aufrufe zwischen Komponenten 

◮ Sprachtransparent 

◮ Plattformabhängig (Windows) 

◮ Ortstransparent 

• Reflexion 

• Dynamisches Nachladen von Komponenten 

• Versionierung von Komponenten und Schnittstellen

Grundideen von (D)COM 

• Komponente implementiert Menge von Schnittstellen 

◮ Verwirrend: COM Object = Komponente, nicht Instanz! 

• Schnittstellen (interfaces) sind Mengen von Signaturen, die eine 

Komponente anbietet 

◮ Nur schwach typisiert, nicht statisch typsicher. 

◮ Mehrfachvererbung möglich 

◮ Jede Schnittstelle erbt transitiv IUnknown 

Schnittstellen abfragen (dynamische Reflexion) 

Lebenszyklus von Instanzen überwachen (Referenzen zählen) 

◮ Standardisierte Komponentenfabriken IClassFactory 

◮ Konventionen zur Namensgebung: Ungarische Notation (Simonyi) 

• Eindeutige IDs für Komponenten und Schnittstellen (general unique ID, 

GUID) 

◮ Ursprung DCE UUID (universal unique ID) 

◮ 128-bit ID mit expliziter Zuordnung menschenlesbarer Namen 

◮ eindeutig in Raum und Zeit 

• Binärstandard 

◮ Funktionsaufruf über vtables, Layout durch MS-C-Übersetzer 

◮ Plattformabhängig 


Komponentenmodell 


Komponentenmodell 

MyComponent (DLL or EXE) 

IUnknown 

IUnknown 

IViewer 

(COM Interface) 

CoViewer 

(COM Object) 

ILoveCom 

IHateCom 

CoPersonality 

IUnknown 

ISecure 

IPersist 

CoSecure 

• Unterschied Komponente, Instanz einer Komponente! 


GUIDs und Versionen 


• Klassen-ID (CLSID) bestimmt Komponente eindeutig 

• Schnittstellen-ID (IID) bestimmt Schnittstelle eindeutig 

• Was bedeutet Versionierung? 

◮ Neue Versionen von Komponenten 

◮ Neue Versionen von Schnittstellen 

• Neue Implementierungen einer Schnittstelle verwenden 

◮ Entkoppele Erzeugung von Komponenten durch Fabriken 

◮ Aufruf von Funktionen über bekannte vtable 

◮ Auch bekannt als: Polymorphie 

• Neue Versionen einer Schnittstelle verwenden 

◮ Fehlender Zusammenhang zwischen IIDs 

◮ In (D)COM ungelöst 

• Also: angebliche automatische Versionierung ist kein Hexenwerk

GUIDs: Vorteile und Nachteile 

• Vorteile 


◮ Keine Namenskollisionen 

◮ Keine fragile base classes 

◮ Verwenden der neuesten Implementierung einfach 

• Nachteile 

◮ Viele ähnliche Schnittstellen 

◮ Zusammenführen von Entwicklungen sehr schwer 

◮ Zusammenhänge zwischen Schnittstellen bleiben unklar 

◮ Verwenden der neuesten Schnittstellen schwer 

Wiederholung: zerbrechliche Oberklasse: Unterklassen sollen nicht immer neu 

übersetzt werden, nur weil sich die Oberklasse ändert 


Interface IUnknown 


• Geerbt von allen COM Schnittstellen 

• Implementiert von allen COM Komponenten 

• Funktionalität 

◮ Schnittstellen einer Instanz abfragen 

◮ Referenzzählen für eine Instanz 

interface IUnknown { 

virtual HRESULT QueryInterface(IID& iid, void** ppvObj) = 0; 

virtual ULONG AddRef() = 0; 

virtual ULONG Release() = 0; 

}

QueryInterface 


• Prüft ob eine Instanz eine Schnittstelle unterstützt 

• Liefert Zeiger auf eine Schnittstelleninstanz 

LPLOOKUP *pLookup; 

TCHAR szNumber[64]; 

HRESULT hRes; 

// Call QueryInterface on the component object 

// PhoneBook, asking for a pointer to the ILookup 

// interface identified by a unique interface ID. 

hRes = pPhoneBook->QueryInterface(IID_ILOOKUP, &pLookup); 

if( SUCCEEDED( hRes ) ) { 

// use Ilookup interface pointer 

pLookup->LookupByName("Daffy Duck", &szNumber); 

// finished using the IPhoneBook interface pointer 

pLookup->Release(); 

}

QueryInterface: Interpretation 

• Was passiert da? 

if(p instanceof L) { 

L l=(L) p; 

l.lookupByName(...); 

l.release(); 

} 

• Typsysteme unterscheiden 

◮ Statischer Typ (Typ des Behälters), ändert sich durch Casts 

◮ Dynamischer Typ (Typ der Instanz), invariant 

• In COM nur Behältertyp, insbesondere p≠l! 

◮ Schnittstelleninstanz ≠ Komponenteninstanz 

◮ Verschlimmert aliasing 


Referenzzähler und Lebenszyklus 

• Schnittstelle 

◮ AddRef: Neue Referenz auf Komponenteninstanz anmelden 

◮ Release: Bestehende Referenz freigeben 

Letzte Freigabe → Löschen der Komponenteninstanz 

• Einfach umsetzbar 

void AddRef () { refCount++; } 

void Release() { if(!(--refCount)) finalize(); } 

• Extrem fehlerträchtig 

◮ Falsches AddRef → floating garbage 

◮ Falsches Release → dangling reference 

◮ Kann keine zirkulären Referenzen erkennen 


Interface IClassFactory 

• Allgemeine Fabrik für Komponenteninstanzen 

• Eine Instanz der Fabrik pro Rechner 

◮ CreateInstance: Neue Komponenteninstanz erzeugen 

◮ LockServer: Schnellere Erzeugung (nichtfunktional) 

• Problem: CreateInstance liefert IUnknown 

• Daher nicht statisch typsicher 


COM Bibliothek 

• Implementiert Standard-Funktionen für Kommunikation 

• Selbst eine (System-)Komponente 

◮ Laufzeitunterstützung von COM 

◮ Dynamische Bibliotheken 

◮ COMPOBJ.DLL, OLE32.DLL 

• Verantwortlich 

◮ Erzeugung von Instanzen 

◮ Herstellen und Koordinieren von Verbindungen 


Registratur (registry) 


• Übernommen aus COM 

• Verwaltet Schnittstellen, Implementierungen von Klassen 

◮ registry in NT 4.0 und Nachfolgern: hierarchische Datenbank 

◮ Entspricht CORBA interface/implementation repositories 

◮ Schlüssel: CLSID 

• service control manager (SCM) kapselt registry 

◮ findet Klassen und ihren Code in der Registratur 

◮ aktiviert Fabrik einem Prozeß 

◮ erzeugt Objekte aktiver Fabriken

Einträge 

Einträge 

Servertyp 

Pathname of server EXE 

(local, out-of-process) 

CLSID 

12345678-ABCD-1234-5678-9ABCDEF00000 

Server Code 

LocalServer32 = C:\MyDir\MyServer.exe 

12345678-ABCD-1234-5678-9ABCDEF00012 

InprocServer32 = C:\object\textrend.dll 

Pathname of server DLL 

(in-process) 



Reihenfolge der Suche 


Reihenfolge der Suche 

Client 

1 

3 

SCM 

COM Cache 

... 

2 

4 

5 

Registry 

InprocServer 

LocalService 

LocalServer 


Zugriff einer Komponente 


Zugriff einer Komponente 

Client 

Client 

Application 

(1) Anfrage mit 

CLSID 

(5) Aufruf 

Object 

Interface 

(4) 

Objekt Interface 

Zeiger an Klienten 

Server 

Object 

(3) Finde (Objekt-) 

Implementierung, 

Lade server code 

COM 

Bibliothek 

Registry 

CLSID 

Server 

Code 

(2) Nachschlagen 

in der Registry

Erzeugen des Objekts 


Erzeugen des Objekts 

Client 

Server 

(7) 

Client 

Application 

(6) 

IClassFactory 

Object 

(5) Erzeuge Objekt 

Fabrik 

(1) CoCreateInstance 

(4) 

(3) 

SCM 

(2) 

Registry 


Erzeugen der Fabrik 


Erzeugen der Fabrik 

Client 

Server 

Client 

Application 

(5) CreateInstance 

IClassFactory 

Object Object 

Fabrik 

(5‘) Erzeuge Objekt 

(1) CoGetClassObject 

(6) 

(4) 

(3) 

SCM 

(2) 

Registry 


DCOM: verteiltes COM 


COM 

Standard für 

Interoperabität 

zwischen 

Adreßräumen auf 

einem Rechner 

−→ 

DCOM 

Standard für 

Interoperabität 

zwischen 

Rechnern 

• Lokale Transparenz 

• Fernaktivierung 

• Fernaufruf 

• Management für Nebenläufigkeit 

• Management für Sicherheit 

• Alles bereits im Design von COM vorbereitet

Transparenz 


Transparenz 

Gleicher 

Prozess 

Client 

Component 

Gleiche 

Maschine 

Client Process 

Client 

COM 

Server Process 

Component 

Über 

Rechner- 

grenze 

Client 

Client Machine 

COM 

DCE 

RPC 

Server Machine 

COM 

Component

DCOM Aufruf 


DCOM Aufruf 

Basiert auf DCE (RPC) 

Objektorientierter RPC (ORPC) 

• Basiert auf DCE (RPC) 

• Objektorientierter – RPC + Dispatch RPC (ORPC) 

◮ RPC Plattformneutral, + Dispatch integriert in Windows 

• im Prinzip plattformneutral, integriert in Windows 

COM 

Machine A 

Distributed COM 

DCE RPC 

ORPC 

RPC 

Machine B 

Distributed COM 

DCE RPC 

COM 


Distributed Computing Environment (DCE) 


Distributed Computing Environment (DCE) 

Distributed Applications 

Time 

Service 

Cell / 

Global 

Directory 

Service 

Security 

Service 

Distributed 

File 

System 

Diskless 

Support 

Remote Procedure Call 

Thread Service 

Local OS and Transportation Services 


Kommunikation in DCE 


Communikation in DCE 

Client 

(Application 

program) 

virtual 

Connection 

Server 

(Application 

program) 

RPC - Interface 

Client 

Stub 

Server 

Stub 

Runtime 

Interface 

Transport 

Interface 

RPC Runtime 

Services 

Transport 

Services 

Remote Call 

Return 

RPC Runtime 

Services 

Transport 

Services 


Kommt uns bekannt vor... 


Kommt bekannt vor... 

IDL-File 

idl 

Client Stub 

Header File 

Server Stub 

RPC 

Runtime 

Client Appl. 

#include 

Server Appl. 

RPC 

Runtime 

Link 

Link 

Client 

Server 


Interface Definition 


• Microsoft Interface Definition Language (MIDL) 

• Erweiterung von DCE IDL 

• Erzeugung von nutzerdefinierten Schnittstellen 

• Nicht neu, aber anders!

Transparenz 


Transparenz 

Client 

Process 

Client 

App 

DLL 

In- 

Process 

Object 

In-Process 

Server 

Local 

Object 

Proxy 

Remote 

Object 

Proxy 

COM 

lightweight 

RPC 

(local) 

RPC RPC 

(network) 

Local Server Process 

Stub 

COM 

Stub 

COM 

EXE 

Local 

Object 

Local 

Server 

Remote Server 

Machine 

Remote Server 

Process 

Remote 

Object 

Remote 

Server 


Fernzugriff in DCOM 


Fernzugriff in DCOM 

Client 

1 

SCM 

7 

1 

SCM 

3 

3 

COM 

Cache... 

2 

4 

5 

6 

Registry 

InprocServer 

NTService 

LocalServer 

RemoteServer 

COM 

Cache... 

2 

4 

5 

6 

Registry 

NTService 

LocalServer 

RemoteServer 

DLLSurrogate 


Wie CORBA 

• Marshalling 

◮ Übermittlung von Daten in verteilten Systemen mittels 

Serialisierung/Deserialisierung 

◮ generiert aus IDL-Spezifikationen 

• Statischer und dynamischer Aufruf über Makler möglich 

• Objekte auf dem Server können sequentiell oder mehrfädig sein 

◮ ein Faden im Adreßraum (Apartment, apartment model) 

◮ vielfädiger Adreßraum (free threading model) 

• Jedes Objekt unterstützt die Schnittstelle IUnknown zur Reflexion 

• Jedes Objekt trägt eindeutigen Identifikator OBJREF bestehend aus: 

◮ OXID (Object Exporter Identifier ), Bezeichner für Adreßraum 

(Apartment) 

◮ OID (Object Identifier ), Objekt im Adreßraum 

◮ IPID (Interface Pointer Identifier ), Schnittstelle in einem Adreßraum 

• Persistenzdienste 


Persistente Objekte 


Spitznamen (Moniker ) kapseln Persistenz von Objekten 

• entsprechen CORBA-Objektadaptern (BOAs) auf Serverseite 

• Wie Stellvertreterobjekte 

◮ Einer pro Objekt 

◮ Nicht einer pro Servicekomponente 

• Namensraum beliebig (meist URL) 

◮ können hierarchisch strukturiert sein

Vermitteln in DCOM (broking) 

• Broker nicht explizit ansprechbar (kein ORB-Konzept) 

◮ Statt dessen werden Stellvertreterobjekte, die das entfernte Objekt in 

der eigenen Komponente vertreten (proxy-Objekte), angesprochen. 

• Standardfall: dynamischer Aufruf flüchtiger, nicht-persistenter Objekte 

◮ Klasse finden und aktivieren, dann Objekte erzeugt 

◮ Allokation von Objekten mit abstrakter Fabrik auf Server, die die 

Verteilung verbirgt (IClassFactory ist Objektfabrik) 

◮ Ansprechen der entfernten Objekte per OBJREF oder per Stellvertreter 

◮ Entferntes, dynamisch aufgerufenes Objekt muß die Schnittstelle 

IDispatch (indirekte Aufrufschnittstelle invoke(method,args)) selbst 

implementieren (keine Unterstützung durch Broker) 

• Statischer Aufruf, wenn Stellvertreter und Objekt identisch 


Fassadenkomponenten 

• Zusammengesetzte Komponenten, die Fassadenobjekte enthalten 

◮ Mehrere Schnittstellen pro Komponente werden auf verschiedene 

interne Objekte mithilfe eines Fassadenobjektes delegiert 

◮ Mächtiger aber langsamer als Mehrfachvererbung, denn 

Mehrfachvererbung ersetzt Delegation durch zusammenhängendes 

Speicherlayout eines Objektes 

Delegation und Aggregation: Indirektion aber keine Layout- und 

Namenskonflikte 

• Schnittstellen bei Allokation festgelegt 

◮ Abhängig von Zusammensetzung der Komponente 

◮ Evtl. statisch nicht sichtbar (Rekursion) 

◮ Nicht dynamisch um neue Dienste erweiterbar 

Fassadenobjekt: Objekt, das mehrere Schnittstellen als eine erscheinen läßt. 


Komponentenkategorien 


Komponenten, die die gleiche Menge von Schnittstellen erfüllen, gehören zur 

gleichen Kategorie (Schlüssel CATID) 

• Ersatz für Vererbung von Eigenschaftsschnittstellen 

• Eine Kategorie beschreibt Merkmale 

• Verwaltet durch den Kategorien-Manager 

CLSID_StdComponentCategoriesMgr 

• Registrierung und Abmeldung von Kategorien in der Registratur

Dienste in DCOM 

• Vorhandene Dienste: (services) 

◮ Alle Microsoft-Werkzeuge (Word, Excel, Powerpoint, Access, . . . ), 

aber Funktionen nicht standardisiert! 

◮ Referenzzählende Speicherbereinigung 

◮ Microsoft Transaction Server (MTS) ermöglicht flache und 

geschachtelte Transaktionen 

◮ Ereignisdienst (publisher/subscriber pattern): 

Schnittstelle registrieren 

Aufruf bei Auslösung des Ereignisses (outgoing interface) 

Schnittstelle durch connection point Objekt repräsentiert. 

Publisher erfüllen IconnectionPointContainer 

Keine eigenständigen Ereignisobjekte. 

• Fehlende Dienste 

◮ Makler 

◮ Lizenzierung 


Diskussion 

• Kein offener, sondern ein proprietärer Standard 

◮ Keine standardisierten Dienste 

◮ Änderungen jederzeit möglich und schon öfters durchgeführt 

• Sprachen und Plattformen 

◮ Ursprünglich C++ / Windows 

◮ Jetzt Brücken für andere Sprachen (VisualBasic, MS Java). 

◮ Erzeugen das Aufrufformat des Microsoft C++-Übersetzers 

◮ EntireX DCOM für Unix (Software AG) 

• Probleme mit der Sicherheit 

◮ kein Behälterkonzept, das Sicherheit prüfen könnte 

◮ DCOM ist binärer Standard - Binärcodes (Viren) 

◮ I love you virus: ein VDB script wird ausgeführt und wirft die 

Mailerkomponente an, die lawinenartig Mails verschickt 


Die Konkurrenz 


• DCOM ist wegen der Marktdominanz von Microsoft nicht mehr aus dem 

Komponentenmarkt wegzudenken. 

• Es gibt Brücken 

◮ von Corba nach DCOM, 

◮ von Java nach DCOM, 

◮ von Java nach Corba, 

◮ Nebeneinander der Ansätze möglich. 

• Java (EJB) - härtester DCOM-Konkurrent.

.NET: Ziele 

• Ziele: 


◮ Plattformabhängigkeit, 

weil .NET auf Windows am besten unterstützt wird. 

◮ Ortstransparenz: Web-Dienste 

◮ Reflexion 

◮ Versionierung 

◮ Dynamisches Laden: Es gibt genau einen Klassenlader 


.NET - Literatur 

• W. Beer, D. Birngruber, H. Mössenböck, A. Wöß: Die .NET-Technologie. 

dpunkt.verlag 2003 

• Michael Stal: C#- und .NET-Tutorial, iX 12/2001 - 02/2002. 

• J. Gough: Stacking Them Up: A Comparison of Virtual Machines. ACSAC 

2001. 

• J. Gough: Compiling for the .NET Commmon Language Runtime (CLR). 

Prentice-Hall, 2002. 

• Mono Projekt, Open Source Implementierung des .NET Rahmensystems 

http://www.go-mono.com/, V 0.23, 2003 

• Portable .NET, Freie Implementierung von .NET und C# 

http://www.southern-storm.com.au/portable_net.html 


.NET: Sprachtransparenz 

• Plattform zur Integration vieler Programmiersprachen durch 

◮ Umfangreiches Typsystem (Common Type System, CTS) 

Minimales Teilsystem von Typen für Interoperabilität 

(Common Language Specification, CLS) 

◮ Laufzeitumgebung (Common Language Runtime, CLR) 

Kellermaschine 

(Zwischensprache: CIL = Common Intermediate Language, 

Synonym: MSIL = Microsoft Intermediate Language) 

automatische Speicherbereinigung 

Versionierung ohne DLL-Hell 

Sicherheitsmechanismen 

◮ objektorientierte Klassenbibliothek für 

graphische Benutzeroberflächen (Windows Forms) 

Web-Oberflächen (Web Forms) 

Datenbankanschluß (ADO.NET) 

Behälterklassen (Collections) 

Parallele Ausführungsfäden (Threads) 

Reflexion 

etc. 


Sprachunabhängiges Objektmodell I (CTS) 


• Objektmodell heißt Common Type System (CTS): 

◮ Menge der Typen, die eine beliebige .NET-Programmiersprache 

verwenden darf: Kein Minimalsystem 

◮ Alle Datentypen sind Objekte (keine Zweiklassengesellschaft) 

◮ Unterscheidung von 

Werttypen (value types): Datentypen, Aufzählungstypen (enum) und 

benutzerdefinierte Werttypen (struct) 

Referenztypen (reference types): Reihungen, Klassen, getypte 

Funktionszeiger (Delegates), Zeiger 

◮ Boxing: Konvertierung eines Wertobjekts in ein Referenzobjekt 

◮ Unboxing: Konvertierung eines Referenzobjekts in ein Wertobjekt

Sprachunabhängiges Objektmodell II (CLS) 


• CLS (Common Language Specification) = minimales Typsystem 

• Zweck: Interoperabilität der .NET-Sprachen 

◮ Untermenge der CTS-Eigenschaften und -Typen, die jeder Übersetzer 

einer .NET-Sprache unterstützen muß, wenn die Sprache mit Typen 

aus anderen CLS-konformen Sprachen arbeiten will. 

◮ Alle exportierten Typen und Schnittstellen müssen die (41) 

CLS-Richtlinien einhalten, z. B.: 

CLS-Regel 15: Die Typen von Reihungselementen müssen 

CLS-konform sein. Reihungen müssen eine fixe Anzahl von 

Dimensionen haben und ihr Index muß bei 0 beginnen. . . .

Datentypen des CTS 


CIL abgebildet auf Beschreibung 

Systembibliothek 

bool System.Boolean 1 Byte, 0 = . false, ≠ 0 = . true 

char System.Char 16-Bit Unicode Zeichen 

string System.String Unicode-Text 

object System.Object verwalteter Verweis auf Halde 

typedref System.TypedReference Paar (Verweis, Typ) 

float32 System.Single IEEE-Gleitpunktzahl 32 Bit 

float64 System.Double IEEE-Gleitpunktzahl 64 Bit 

int8 System.SByte 2 Komplement Zahl: 8Bit 

int16 System.Int16 2 Komplement Zahl: 16Bit 



unsigned int8 System.Byte vorzeichenlose Zahl: 8Bit 

unsigned int16 System.UInt16 vorzeichenlose Zahl: 16Bit 



native int System.IntPtr maschinenabhängig m. Vorz. 

native unsigned int System.UIntPtr maschinenabhängig o. Vorz. 

nicht in CLS: typedref, int8, unsigned int16, unsigned int32, unsigned int64, 

native unsigned int

CLR 


CLR 

• ist Laufzeitumgebung für .NET-Anwendungen (Ähnlichkeit zu Java) und 

• basiert auf abstrakter Kellermaschine, die ausschließlich Anweisungen des 

Zwischencodes CIL verarbeitet.

CIL Beispiel 


public static Point operator+(Point op1, Point op2) { 

return new Point(op1.x+op2.x,op1.y+op2.y); 

} 

→ 

.method public hidebysig specialname static 

valuetype ComplexNumbers.Point op_Addition(valuetype ComplexNumbers.Point op1, 

valuetype ComplexNumbers.Point op2) cil managed 

{ 

// Code size 40 (0x28) 

.maxstack 4 

.locals ([0] valuetype ComplexNumbers.Point CS$00000003$00000000) 

IL_0000: ldarga.s op1 

IL_0002: call instance float64 ComplexNumbers.Point::get_x() 


IL_0009: call instance float64 ComplexNumbers.Point::get_x() 

IL_000e: add 

IL_000f: ldarga.s op1 

IL_0011: call instance float64 ComplexNumbers.Point::get_y() 


IL_0018: call instance float64 ComplexNumbers.Point::get_y() 

IL_001d: add 

IL_001e: newobj instance void ComplexNumbers.Point::.ctor(float64, 

float64) 

IL_0023: stloc.0 

IL_0024: br.s IL_0026 

IL_0026: ldloc.0 

IL_0027: ret 

} // end of method Point::op_Addition

Vergleich zu Java(-Bytecode) 

public static Point plus(Point p1, Point p2) { 

return new Point(p1.getX() + p2.getX(), p1.getY() + p2.getY()); 

} 

→ 

public static Point plus(Point arg0, Point arg1) 

Code(max_stack = 8, max_locals = 2, code_length = 26) 

0: new (9) 

3: dup 

4: aload_0 

5: invokevirtual Point.getX ()D (10) 

8: aload_1 

9: invokevirtual Point.getX ()D (10) 

12: dadd 

13: aload_0 

14: invokevirtual Point.getY ()D (11) 

17: aload_1 

18: invokevirtual Point.getY ()D (11) 

21: dadd 

22: invokespecial Point. (DD)V (12) 

25: areturn 

Man beachte: 

• Java Bytecode enthält getypte Operatoren (dadd), weil der Bytecode 

interpretiert wird (werden kann) 

• CIL Operatoren sind typfrei (add), weil CIL nicht interpretiert wird 

(werden kann), sondern immer in Maschinensprache übersetzt wird. 


.NET-Laufzeitsystem 


• CIL-Code wird nicht interpretiert, sondern vom VES (virtual execution 

system) in Maschinencode übersetzt, entweder vor der 

Programmausführung oder währenddessen. 

• .NET-Laufzeitumgebung enthält 

◮ Just-in-time Übersetzer (JIT) 

◮ Speicherbereiniger (Garbage Collector) 

◮ Klassenlader (Class Loader): Dynamisches Laden von Päckchen 

◮ Codeinspektor (Verifier): Prüft CIL-Programme auf Typsicherheit.

Code- und Datenverwaltung 


• Verwalteter Code (Managed Code): Ausführung erfolgt unter Aufsicht der 

.NET-Laufzeitumgebung. 

• Nicht-verwalteter Code (Unmanaged Code): sonstiger Code 

• Interoperabilität zwischen ” 

managed“ und ” 

unmanaged“ Code: 

◮ Einbinden von existierenden DLLs mit P/Invoke (Platform Invoke) 

◮ COM/COM+-Anbindung über die COM-Interop-Abbildung 

• Verwaltete Daten (Managed Data): Vom Speicherbereiniger verwaltete, 

nicht persistente Daten. 

• Nicht-verwaltete Daten (Unmanaged Data (Unsafe Code)): Manuell vom 

Programmierer allozierte und deallozierte Daten. 

• Achtung: In verwaltetem Code darf der Programmierer sowohl verwaltete 

als auch nicht-verwaltete Daten verwenden.

Codeprüfung 


• Problem: Unsafe Code, insbesondere Zeigerarithmetik 

⇒ Codeprüfung durch Verifizierer und Klassenlader 

◮ Verifizierer prüft konservativ vor Übersetzung in Maschinencode, ob 

sich das Programm an alle Regeln bezüglich Speicherzugriffen hält: 

Das Programm greift nur auf Speicherbereiche zu, die für es 

eingerichtet wurden. 

Das Programm verwendet Objekte nur über deren Schnittstelle. 

◮ Klassenlader prüft, ob alle Eingangswerte die vorgeschrieben 

Typsignatur aufweisen. 

• Verifizierer abschaltbar: Verwendung von Zeigerarithmetik oder 

Funktionszeigern möglich 

⇒ Unterstützung von ANSI C, Mehrfachvererbung

Päckchen (Assemblies) 


Päckchen = .NET-Komponente: 

• Logische Einheit ähnlich DLL oder EXE 

• Atomare Einheit bzgl. Installation, Konfiguration, Sicherheit, 

Versionierung und Laufzeitmanagement 

• Beim Laden des Päckchens aktiviert das VES einen so genannten Runtime 

Host, der die Kontrolle über Übersetzung und Ausführung übernimmt.

Päckchen: Inhalt 

Päckchen enthält: 

• Ein oder mehrere Module (Program Executables, PE): ausführbarer Code 

für die bereitgestellten Typen des Moduls 

• Versionsnummer (strong name) spezifiziert durch .assembly: 

◮ Name 

◮ Version: (Major.Minor.Build.Revision) 

◮ Sprache (en-US, de-DE, . . . ) 

◮ Öffentlicher Schlüssel des Produzenten 

• Manifest-Information, die innerhalb eines Moduls oder global im Päckchen 

sein kann: 

◮ Identifiziert die zum Päckchen gehörenden Module und Ressourcen 

◮ Bedarfsschnittstelle: detaillierte Information über Referenzen auf 

importierte Päckchen 

◮ Angebotsschnittstelle: exportierte Typen und Ressourcen 

• Kennzeichnung der CLR-Version mit der das Päckchen ausgeführt werden 

will. 


Päckchen: Reflexion und Verwaltung (Versionierung) 

• Metadaten sind explizit im Päckchen vorhanden (generiert). 

• Metadaten sind 

◮ Defintionstabellen: Beschreiben Elemente, die in dem Modul selbst 

definiert sind. 

◮ Referenztabellen: Beschreiben Elemente, die im Modul nicht definiert 

sind, aber verwendet werden. 

◮ Manifest(tabellen) 

• dynamische Abfrage mit Reflexionsmechanismen 

• Metadaten + Reflexionsmechanismen 

⇒ 

◮ keine IDL mehr 

◮ keine Registratur von Päckchen (keine Registry ) mehr: 

Ablage von Päckchen im Dateisystem 

private Päckchen liegen im lokalen Verzeichnisbaum der Anwendung 

gemeinsame Päckchen liegen meist in globalem Verzeichnis (Global 

Assembly Cache): 

Installation erfordert Signieren mit privatem Schlüssel 

· Vermeidung von Namenskollisionen durch strong name 


Versionierung und Nebeneinanderausführung 


• Versionierung: 

⇒ Nebeneinanderausführung verschiedener Versionen eines Programms. 

⇒ Gleichzeitige Ausführung verschiedener Versionen einer Komponente in 

demselben Prozeß. 

• Abschirmung: Einteilung des CLR-Prozesses in abgeschirmte Bereiche 

(Application Domains) für auszuführende Applikationen

C# 


Man nehme Java . . . und füge hinzu/ändere: 

• Werttypen, z.B. Verbundtypen (Wertklassen, die auch Methoden 

enthalten können) 

• Aufzählungstypen 

• Parameterübergabe: Wert-, Referenz- oder Ergebnisaufruf 

• vernünftige Reihungen 

• Überladen von Operatoren 

• foreach-Schleife mit indexer : Strom über collections, Reihungen, Texte, 

aber nur ein Strom pro Objekt 

• weitergehende Reflektion als Java 

• delegates (Variable, die Mengen von Methoden enthalten können, die alle 

zugleich aufgerufen werden) 

• Attribute: Objekte, die mit Klassen, Methoden, Päckchen assoziiert sind 

• properties: Attribute mit expliziten set/get-Methoden (auch in 

Schnittstellenklassen!) 

• events: spezielle, nur lokal sichtbare delegates 

• geschachtelte Referenz- und Werteklassen 

• unsichere Klassen/Methoden (unsafe); sie erlauben Adreßarithmetik 

Hauptunterschied: für die CIL gibt es keinen Interpretierer; es wird alles in 

Maschinencode übersetzt

C#: Attribute 


• Attribute sind Objekte einer Unterklasse der Klasse System.Attribute. 

• Attribute werden automatisch mit einer Klasse, Methode, einem 

Parameter oder einem Päckchen assoziiert, indem man vor deren 

Vereinbarung in eckigen Klammern einen Konstruktor angibt: 

[Serializable] class Liste { ...} 

• Die Existenz, Merkmale und Methoden des Attributs kann man zur 

Laufzeit abfragen bzw. aufrufen. 

• Auch mehrere Attribute können gleichzeitig hinzugefügt werden. 

• Eigentlich ist das ein beschränkter Ersatz für Mehrfachvererbung 

• (Die Existenz von Attributen kann von Präprozessorkommandos abhängig 

sein.) 

• Attribute sind also benutzerdefinierte Metainformationen.

C#-Attribute: Beispiel 


Attribut zur Kennzeichnung des Autors des Codes: 

[AuthorIs("Gerhard")] 

class MyClass { 

... 

} 

Definition des AuthorIs-Attributs: 

[AttributeUsage(AttributeTargets.All)] 

public class AuthorIsAttribute : Attribute { 

private string m_Name; 

public AuthorIsAttribute(string name) { 

m_Name = name; } 

} 

• Die Attributklasse ist selbst rekursiv mit einem Attribut deklariert, das 

spezifiziert, daß AuthorIs für beliebige Elemente anwendbar sein soll 

(AttributeTargets.All). 

• Alternative: Beschränkung des Attributs auf Klassen mit 

AttributeTargets.Class

C#-Attribute: Zugriff 


class MainClass { 

public static void Main() { 

foreach (object attribute in 

typeof(MyClass).getCustomAttributes(AuthorIsAttribute,false)) { 

Console.WriteLine(attribute); 

} 

} 

}

C#: Properties 

public struct Point { 

private double m_x; 

private double m_y; 

... 

public double x { 

set { m_x = value; } 

get { return m_x; } 

} 

} 

Zugriff auf obige Eigenschaft: 

Point q = new Point(); 

q.x = 20; 

// set-Methode wird implizit aufgerufen 

Console.WriteLine(q.x); // get-Methode wird implizit aufgerufen 


C#: Properties, Spezialfall: Indexer 


public double this[CoordinateKind which] { 

get { if (which == CoordinateKind.X) return m_x; 

else return m_y; } 

set { if (which == CoordinateKind.X) m_x = value; 

else m_y = value; } 

} 

Zugriff: 

p[Point.CoordinateKind.X] = 22; 

p[Point.CoordinateKind.Y] = 33;

Gültigkeitsbereiche und Vererbung in C# 

• Blockschachtelungsregelungen wie üblich 

• Parameter gehören zum Gültigkeitsbereich des Prozedurrumpfs 

• Die for-Schleife definiert ihren Zähler als neue, schleifenlokale Variable 

• internal: Ein so vereinbarter Name ist in allen in einem Päckchen 

zusammengefaßten Programmeinheiten bekannt 

• Vererbung: 

◮ private und public wie üblich; Grundannahme ohne Spezifikation ist 

private 

◮ protected: nur in der eigenen und in Unterklassen sichtbar 

◮ virtual, override: für polymorphen Zugriff muß eine Methode in der 

Oberklasse als virtuell vereinbart sein; sie kann dann in der Unterklasse 

überschrieben werden 

◮ virtual, new: virtual nicht zwingend erforderlich; die Unterklasse 

verdeckt die Vereinbarung in der Oberklasse, keine Polymorphie möglich 

◮ Für Überschreiben und Verdecken ist identische Signatur nötig, sonst 

liegt Überladen vor. 

◮ Eine Klasse, von der nicht mehr geerbt werden kann, heißt in C# 

sealed 

◮ Vererben von Wertklassen ist verboten; aber diese können von 

Schnittstellenklassen erben 


C#: Namensräume 

• Hierarchische Namensräume: Java-ähnliches Paketkonzept, können 

Klassen, Aufzählungstypen, Delegierte und andere Namensräume 

enthalten: 

namespace MyNameSpace { ... } 

• keine Abbildung auf gleichnamige Verzeichnishierarchien und Dateinamen 

• Klassen außerhalb eines expliziten Namensraums gehören zu einem 

anonymen Namensraum 

• Namensräume können auf mehrere Quelldateien verteilt sein 

• Alle Bezeichner der zu einem Namensraum gehörigen Einheiten sind im 

gesamten Namensraum sichtbar 

• Angabe einzubindender existierender Pakete durch Übersetzerschalter: 

/reference 

• Verwendung von Typen aus anderen Namensräumen: 

◮ vollqualifizierte Punktnotation, z. B. System.Console.WriteLine 

◮ Abkürzung durch using-Anweisung, ähnlich import in Java. 

◮ Bezeichner aus anderen Namensräumen müssen dort mit public oder 

internal vereinbart sein. 

• .NET-Päckchen können mehrere öffentliche Klassen enthalten, 

• auch mehrere Klassen mit einer statischen Main-Methode: Man muß dem 

Übersetzer dann mitteilen, welchen Einstiegspunkt er konkret verwenden 

soll. 


C#-Beispiel 


• HelloWorld.cs: 

using System; 

namespace MyNameSpace 

{ 

public class MyFirstExample 

{ 

public static void Main(string[] args) 

{ 

Console.WriteLine("Hallo {0} im Jahr 1", "IPD", 2003); 

} 

} 

}

Implementierungen 


Es gibt mindestens drei Implementierungen: 

• sscli: die offizielle Implementierung von Microsoft für win und FreeBSD, 

die zentrale Laufzeitumgebung heißt ” 

rotor“ 

• sscli linux 20020821: Adaption von sscli an Linux 

unter Redhat 7.3 und 8.0 einwandfrei installiert 

◮ aber Vorsicht: sscli linux belegt samt Doku > 1,1GB und übersetzt 

selbst auf Gigahertz-Maschinen mehr als eine halbe Stunde! 

• mono-0.16: open source Implementierung der ECMA-Standards (von 

XIMIAN) 

• pnet: eine australische open source Implementierung, 

noch nicht ausprobiert, enthält einen C → CLR Übersetzer 

Wegen der Lizenzbedingungen sollte man keinen sscli-Code von MS im 

Zusammenhang mit eigenen Entwicklungen lesen! Auch der 

Leistungsvergleich sscli vs. andere CLR-Implementierung ist verboten!

Ortstransparenz: .NET-Remoting 


• Transparenter Fernaufruf:

Entferntes Objekt 


using System; 

namespace RemoteObject 

public class Grid : System.MarshalByRefObject { 

const int LENGTH = 10; 

double [,] matrix = new double[LENGTH,LENGTH]; 

public Grid() { Console.WriteLine("Ready!"); } 

~Grid() { Console.WriteLine("Destroyed!"); } 

public int Length { get { return LENGTH; } } 

public double this[int i1, int i2] { 

set { 

if (OutOfBounds(i1,i2)) throw new ArgumentException(); 

else matrix[i1,i2] = value; 

} 

get { 

if (OutOfBounds(i1,i2)) throw new ArgumentException(); 

else return matrix[i1,i2]; 

} 

} 

} 

} 

bool OutOfBounds(int i1, int i2) { 

return (i1 < 0) || (i1 >= LENGTH) || 

(i2 < 0) || (i2 >= LENGTH) ? true : false; 

}

Server 


using System; 

using RemoteObject; 

using System.Runtime.Remoting.Channels.Tcp; 

using System.Runtime.Remoting.Channels; 

using System.Runtime.Remoting; 

namespace ServerDomain { 

class Server { 

static void Main(string[] args) { 

TcpServerChannel ch = new TcpServerChannel(8888); 

ChannelServices.RegisterChannel(ch); 

RemotingConfiguration.RegisterWellKnownServiceType( 

typeof(Grid), "Grid", WellKnownObjectMode.Singleton); 

Console.WriteLine("Waiting forever"); 

while(true); 

} 

} 

}

Kunde 


using System; 

using System.Runtime.Remoting.Channels; 

using System.Runtime.Remoting.Channels.Tcp; 

using RemoteObject; 

namespace GridClient { 

class Client { 

static void Main(string[] args) { 

ChannelServices.RegisterChannel(new TcpClientChannel()); 

Grid myGrid = (Grid)Activator.GetObject 

(typeof(Grid), "tcp://localhost:8888/Grid"); 

if (myGrid == null) { 

Console.WriteLine("Could not connect!"); 

return; 

} 

for (int i = 0; i < myGrid.Length; i++) { 

for (int j = 0; j < myGrid.Length; j++) { 

myGrid[i,j] = (double)(i*10 + j); 

Console.WriteLine(myGrid[i,j]); 

} 

} 

} 

} 

}

Ortstransparenz: Webdienste in .NET 


Ortstransparenz: Webdienste in .NET 


• Offene Standards (W3C) als Schnittstelle zum Web 

• Werkzeuge vereinfachen Anbindung an .NET 

• Ebenen laut Microsoft: 

Ebenen 

Standard 

Datenformat 

XML 

Nachrichtenformat 

SOAP 

Dienstbeschreibung 

WSDL 

Auffindung von Diensten auf Servern ? 

Auffindung von Servern 

UDDI 

• Problematische Unterscheidungen 

◮ Datenformat - Nachrichtenformat 

◮ Ebenen des Auffindens 

• Funktionalität steht im Vordergrund, nicht Performanz.

Webdienst: Beispiel 


 

using System.Web; 

using System.Web.Services; 

public class TimeService : WebService { 

[WebMethod(Description="Returns the current time.")] 

public string GetTime() { 

return System.DateTime.Now.ToLongTimeString(); 

} 

}

Simple Object Access Protocol (SOAP) 

• XML-basiertes Nachrichtenformat 

• Nachricht ist Umschlag mit Kopf und Körper 

◮ Kopf enthält Adressaten und Verarbeitungsinformation 

◮ Körper enthält Nutzdaten oder Fehlercodes 

• Wirre Mechanismen zur Typdefinition 

◮ Reihungen 

◮ sonst Rückgriff auf Namensräume (implizit also Schemata) 

• Transport ist transparent, vordefinierte Kanäle 

◮ HTTP (mit Rückkanal) 

◮ SMTP (Simple Mail Transport Protokoll) 

◮ TCP (mit Rückkanal) 

• Problem: Beliebigkeit wegen zu vieler nicht standardisierter Eigenschaften 


Was ist WSDL? 


WSDL beantwortet folgende Fragen: 

• Welche Dienste bieten welche Methoden an? 

• Über welche Ports, Protokolle und Nachrichten können die Methoden 

aufgerufen werden? 

• Welche Namen und welche Parameter hat eine Nachricht? 

• Wie sehen die verwendeten Datentypen aus?

WSDL-Aufbau 

Eine WSDL besteht aus 5 hierarchisch aufeinander aufbauenden Abschnitten: 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Protokollinfo 

 

 

 

 

 

 

• abstakter Teil: , , 

• konkreter Teil: , 


Web Services Description Language (WSDL) 

• XML-basierte Beschreibungssprache für Webdienste 

• Gegenstand: Mengen von Funktionen 

◮ Strukturiertes Programmieren 

◮ Keine Objektorientierung - keine Vererbung 

• Modellierung von Parametern 

◮ XML Schema oder beliebige andere Beschreibungssprachen 

◮ Referenzen (auf Dienste) nicht explizit unterstützt 

• Abbildung auf konkrete Schnittstellen 

◮ SOAP 

◮ MIME (Multi-Purpose Internet Mail Extensions) für SMTP 

• Probleme: Beliebigkeit, fehlende Objektorientierung 


Uniform Description, Discovery and Integration (UDDI) 

• Beschreibt Dienste 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 

• UDDI ist kein Makler oder Marktplatz 

◮ Keine geographischen Anfragen 

◮ Keine Preisanfragen 

◮ Keine Zeitanfragen 

• Also: Wie DNS oder JINI, nur komplexere Felder 


.NET myServices 


.NET myServices (HailStorm) is the user-centric architecture and set of 

services for .NET that deliver personally relevant information through the 

Internet to a user, to software running on the user’s behalf, or to devices 

working for the user. 

Microsoft 

• Kurz: Dienste für personenbezogene Daten unter .NET 

• Einordnung in CORBA: service oder facility 

• Kern standardisiert durch Microsoft 

• Weitere Definitionen durch Microsoft Open Process

Die heilige Privatsphäre 


• .NET myServices verwaltet private Daten 

• Sicherheit entscheidet über Akzeptanz 

• Große Kundenstämme als Referenzen 

◮ MSN 

◮ Hotmail (zugekauft) 

◮ Passport (zugekauft): Sicherheitsprobleme 

• Beteiligung an Privatsphäre-Initiativen 

◮ TRUSTe 

◮ Code of fair information practices 

• Kodex: Keine Werbung, kein Mining, keine Weitergabe

Motivation für .NET myServices 

• Was Microsoft sagt 

◮ Heute: Anwendungen und ihre Daten leben nebeneinander her 

◮ Beispiel: Integration Flugbuchungssystem - Terminkalender 

◮ Morgen: Verteilung, Vielzahl von Geräten führt ins Chaos 

◮ Ausweg: Standardisierung mit .NET myServices 

persönliche Daten 

Verwaltung, Zugriffe, Austausch 

• Was Microsoft will 

◮ Den Zugang zu Netzdiensten kontrollieren 

◮ Offene Standards in .NET sind Feigenblatt 

◮ Kontinuierliche Zahlungsströme von 

Endbenutzern für Verwaltung und Transaktionen 

Dienstanbietern für Infrastruktur und nötige Zertifikate 

Entwicklern für Werkzeuge etc. 


Die üblichen Tricks 


• Wer die Schnittstelle beherrscht, beherrscht das Geschäft: 

Microsoft will electronically and physically secure data managed by 

.NET myServices to prevent unauthorized access or use. 

• Implementierungen austauschbar 

◮ PCs (DOS, Windows) 

◮ SEGA Dreamcast (Windows CE, Direct-X) 

◮ Webdienste? (.NET, .NET myServices) 

• Nutzung von Marktmacht 

◮ Bekannt: Bündelung von Windows 9x und Internet Explorer 

◮ Ebenso: Bündelung von Windows XP und Media Player 8 

◮ Variante: Integration von XP- und .NET myServices-Anmeldung 

Integration in Office, Spiele, Xbox (Spielekonsole), 

Stinger (SmartPhone), ...

Fazit 

• Ziele von .NET ähnlich wie CORBA: Vereinheitlichung einer heterogenen 

Welt, aber 

◮ Monopolisierungsabsicht. 

◮ Mittelfristig oder langfristig Plattformabhängigkeit 

◮ Kellercode nicht ausführbar 

◮ Verifizierer nicht validiert und außerdem abschaltbar 

◮ praktische Tauglichkeit noch nicht nachgewiesen 

◮ manche Eigenschaften noch nicht ausreichend klar: 

Mehrfachvererbung, mehrfädige Programmierung 

◮ deutliche Ausrichtung auf web-Dienste 

• technisch: 

◮ im Vergleich zu CORBA und EJB der bisher systematischste Ansatz 

◮ wesentlich bessere Unterstützung von Versionierung 

◮ sowohl für sequentielle als auch für verteilte Systeme 

◮ explizite Bereitstellung von Übersetzungsdaten in Päckchen stellt die 

Metaprogrammierung auf eine durchsichtige Grundlage 

◮ der (seit 40 Jahren) überzeugendste Ansatz zur Lösung des 

UNCOL-Problems 

◮ Konzept des managed code könnte erhebliche Auswirkungen auf den 

künftigen Gebrauch von C und C++ haben. 


Komponentensysteme im Vergleich 


Komponenten: erwünschte Eigenschaften 

• Programmeinheiten mit standardisierter Basiskommunikation 

◮ abstrakt (nur Schnittstelle), generisch oder konkret (mit 

Implementierung) 

◮ Klassen und Module sind Komponenten 

• entworfen mit standardisierten Verträgen zur Komposition: 

◮ Export-Schnittstelle sichert semantische Eigenschaften zu 

◮ Import-Schnittstelle definiert Voraussetzungen zur ihrer Garantie 

explizit oder 

implizit (als Parameter von Konstruktoren oder anderen Methoden) 

◮ kein verstecktes Wissen 

• Komponenten sind wiederverwendbar 

• Komponenten können aus Komponenten zusammengesetzt sein 


Komposition 


• Generische Komponenten ausprägen (mit Argumenten für generische 

Parameter) 

• Zusammensetzen von Komponenten laut Verträgen: 

◮ über Funktionen und Daten 

◮ über Kommunikation, Synchronisation und Protokolle 


◮ Wie erreicht man nicht-funktionale Eigenschaften? 

• Mangelnde Passung erfordert Adaption der Komponenten: 

◮ Externe Adaption durch Umwickeln 

◮ Interne Adaption: 

Offenes Einsetzen 

Invasiver Austausch nicht-funktionaler Aspekte (z.B. 

Basiskommunikation tauschen, Synchronisation einfügen etc.)

Vergleichskriterien 

• Komponenten 

◮ Generische Komponenten 

◮ Abstrakte Komponenten (Schnittstellen) 

◮ Konkrete Komponenten (Implementierungen) 

◮ Zusammengesetzte Komponenten 


• Wiederverwendbarkeit 

• Anpassung (extern und intern) von 

◮ Funktionen und Daten 

◮ Kommunikation, Synchronisation und Protokolle 



Generische Komponenten - Spezifikationen 

• Corba 

◮ Schnittstellen werden aus IDL generiert 

◮ kein ähnliches Konzept für Implementierungen 

• EJB 

◮ Deployment entsprechend Descriptor 

• DCOM 

Generierung von Stummeln und Skeletten wie aus IDL, 

Anpassungen an Behälter, 

Einweben von Persistenz, Transaktion, ... 

◮ Schnittstellenklassen und Stellvertreter werden aus MIDL generiert 

◮ Kein ähnliches Konzept für Implementierungen 

• .NET 

◮ Metadaten pro Päckchen, ersetzt IDL 

◮ für Webdienste Generieren von Schnittstellen (WSDL) und 

Stellvertretern aus Implementierung 


Abstrakte Komponenten - Schnittstellen 

• Corba 

◮ Schnittstellen werden aus IDL generiert 

◮ Stummel und Skelette 

◮ Mehrfachvererbung 

• EJB 

◮ Generierung bei Deployment, 


• DCOM 

◮ Schnittstellen werden aus MIDL generiert 

◮ Schnittstellenobjekte 


◮ Unveränderliche Schnittstellen (immer und überall) 

• .NET 

◮ Schnittstellen sind Typen, vermerkt in den Metadaten eines Päckchens 


Konkrete Komponenten - Implementierungen 

• Corba 

◮ Mit Transaktionskonzept / Persistenzkonzept 

◮ Sprach- / Plattformunabhängig 

◮ Vererbungskonzept der jeweiligen Sprache 

• EJB 


◮ Java / Plattformunabhängig 

◮ Einfachvererbung 

• DCOM 


◮ Sprachunabhängig (aber de facto MS C-Compilerabhängig) / 

Plattformunabhängig (aber de facto Windows) 

◮ Vererbungskonzept der jeweiligen Sprache 

• .NET 


◮ ” 

Plattformunabhängig“ 

◮ Einfachvererbung, Mehrfachvererbung von Schnittstellen 


Zusammengesetzte Komponenten 

• Corba 

◮ Aufruf über ORB 

◮ Aggregation über Entwurfsmuster Fassade (auch dynamisch) seit 

Corba 3.0 

• EJB 

◮ Aufruf über Behälter 

◮ Java Sprachkonzepte zur Delegation 

• DCOM 

◮ Aufruf über (D)COM Bibliothek und Stellvertreter 

◮ Delegation in Komponenten über Umwickler 

◮ Aggregation von Klassen über Entwurfsmuster Fassade (nur statisch) 

◮ Aggregation von Schnittstellen 

• .NET 

◮ Aggregation von Moduln in Päckchen, (logische, keine physische) 

Schachtelung von Päckchen 

◮ Delegation 


Basiskommunikation 

• Corba 

◮ Erzeugung und Fernaufruf über ORB (Object Request Broker ) 

◮ Zentrale Vermittlung über ORB 

◮ Fernaufruf GIOP/IIOP (General/Internet Inter ORB Protokoll) 

• EJB 

◮ Erzeugung und RMI (Remote Message Invocation) über Container 

◮ Anbindung an Corba 

◮ Zentrale Vermittlung über Behälter 

◮ Migration von Javacode 

• DCOM 

◮ Erzeugung (Fabrik) über lokale Bibliotheksdienste 

◮ Objekterzeugung ist Fabrikmethodenaufruf 

◮ Objektorientierter Fernaufruf basierend auf DCE über Stellvertreter 

(proxies) 

◮ Dezentrale Vermittlung 

• .NET 

◮ Fernaufruf über Stellvertreter (.NET-Remoting-Rahmensystem) 

◮ Webdienste 


Wiederverwendung 

• Corba 

◮ Vordefinierte Facilities und Services 

◮ Vertical Facilities (Fachkomponenten) schwach 

• EJB 

◮ Keine Standardisierungen von Beans 

◮ AWT und Swing (JavaBeans) meistverwendete Java Bibliothek 

◮ Industriestandards: SanFrancisco gescheitert, Fiscus-Projekt? 

◮ Derzeit wird eher die Architektur wiederverwendet, um firmenintern 

Komponenten wiederzuverwenden 

• DCOM 

◮ Keine Standardisierungen von DCOM Objekten (Klassen) 

◮ Industriestandard: Microsoft Anwendungen stark 

• .NET 

◮ Umfangreiche Bibliothek 

◮ Vordefinierte Dienste (schwach, Datenschutz?) 

◮ Webdienste (aufkommend) 


Generierung aus Spezifikationen 

• Corba 

◮ Stummel-Skelett-Generierung aus IDL 

• EJB 

◮ Klare Trennung von Entwicklung und Einpassung (deployment) 

◮ Unterschiedliche Rollen im Entwurf 

◮ Ausbaufähiges Konzept zur Entwicklung von Komponentensystemen 

durch Trennung von 

Entwurfsentscheidungen aus Komponentensicht 

(Implementierungsdetails) 

Entwurfsentscheidungen aus Kontextsicht (Transaktion, Persistenz, 

aber auch verteilte Protokolle zur Diensterfüllung) 

◮ Schnittstellen-Stellvertreter Generierung 

• DCOM 

◮ Schnittstellen-Stellvertreter Generierung aus MIDL 

• .NET 

◮ Generierung von Spezifikationen aus Implementierungen (Webdienste) 

◮ Generierung der Stellvertreter aus generierten Spezifikationen 


Anpassungen (Corba, EJB, DCOM, .NET) 

• Aspekttrennung schafft Voraussetzungen 

◮ Trennung von Schnittstellen und Implementierungen 

◮ Mehrere Schnittstellen pro Komponente 

◮ Trennung von Persistenz-, Transaktions-, Verteilungsaspekt 

• Reflexion erlaubt das Erkennen der Notwendigkeit 

• Kommunikationsanpassung — Brücken zwischen den Welten 

◮ EJB - Corba 

◮ Java - DCOM 

◮ Corba - DCOM 

• Konzepte zur Anpassung 

◮ Explizites Adaptieren und Delegieren 

◮ IDL Generatoren erzeugen Code für Sprach- und 

Verteilungsanpassungen 

◮ siehe Konzepte zur Komposition 

• .NET: Vereinheitlichung 

◮ Brücke zu (D)COM 


Weitere Anpassungen mit Corba MOF 

• Meta Object Facility (MOF) 

◮ Beschreibung mit gleicher Sprache 

◮ zur Anpassung verschiedener Typsysteme (z.B. IDL und UML) 

• XMI, um automatisch Stromformate von Werkzeugen ineinander 

umzusetzen 

• Anpassung der Metadaten (Datenbeschreibungen) und nicht der Daten 

selber 


Weitere Anpassungen EJB Deployment 


• Komposition entsprechend Bean Descriptor 

• Einweben von Aspekten aus Bean Descriptor 

◮ Persistenz 

◮ Transaktionsverwaltung 

• Interne Adaption dieser Aspekte 

• Hier weitere (automatische) Anpassungen denkbar 

◮ Forschungsgegenstand 

◮ Architektur vorhanden

Fehlende Anpassungen 


• Daten, Funktionen, Kommunikation werden explizit und extern angepaßt 

• Synchronisation und Protokollanpassungen entsprechen Anpassungen von 

Transaktionen und Sessions (siehe vorige Folien) 

• Keine Konzepte zur globalen Lebendigkeit 

◮ Synchronisationskonzepte unter Komposition 

◮ Lebendigkeitstests

Fazit Corba 


• Die Corba-Schnittstellen sind sehr flexibel, funktionieren und können in 

der Praxis eingesetzt werden - aber auch komplex und umfangreich, 

vielleicht zu flexibel für die Praxis 

• Corba ist ein offener Standard. 

• Geht normiert über den Verdrahtungsstandard hinaus (facilities, services) 

• MOF/XMI zur Integration von Typsystemen von Programmiersprachen, 

Entwurfs- und Entwicklungssystemen, Datenbankschemata etc. 

• Freie ORBs beflügeln Corba 

• Java für neue Software, Corba für gemischte Alt-Neu-Systeme

Fazit EJB 


• Die Java-Schnittstellen sind sehr flexibel, funktionieren und können in der 

Praxis eingesetzt werden 

• Standard in Firmenhand Sun Microsystems - kann die gleichen Probleme 

bereiten wie bei Microsoft 

• Java/Beans/EJB wird die Basis für Geschäftsobjekte 

• Die Definition von Beans und EJB als Standardkomponenten erhöht den 

Grad der Modularisierung und Wiederverwendung, bislang aber noch keine 

Komponenten von der Stange am Markt 

• Die Dokumentation ist gut 

• Deployment in EJB gehen weiter als andere Konzepte, da Anpassungen 

generiert werden (das kann Corba/DCOM nur für Verteilung)

Fazit DCOM 


• Vorwiegend Verdrahtungsstandard 

• Dezentrale Kommunikationsvermittlung über Stellvertreter 

• Kein offener Standard - bei bekannter Firmenpolitik von Microsoft 

besonders kritisch 

• Anstelle der Facilities und Services Microsoft Anwendungen 

◮ Office ist Quasistandard (Formate von allen Konkurrenten unterstützt) 

◮ Weitere Verbreitung als Corba 

◮ Schnittstellen / Formate können durch Microsoft geändert werden 

• Windows als Plattform vorausgesetzt (auch wenn EntireX von Software 

AG auf Linux existiert)

Fazit .NET 


• Technisch guter Ansatz zur Vereinheitlichung 

• ECMA-Standard 

• Umfangreiche Bibliothek 

• Ortstransparenz durch .NET-Remoting und Webdienste über Stellvertreter 

• Volle Reflexion durch Metainformationen in Päckchen, damit weder IDL 

noch Registratur nötig 

• ABER: 

◮ Verifizierer nicht validiert und außerdem abschaltbar. 

◮ Mittelfristig oder langfristig Plattformabhängigkeit. 

◮ Praktische Tauglichkeit noch nicht nachgewiesen. 

◮ Keine Anpassungskonzepte.

Fazit kommerzielle Komponentensysteme 


+ Komponenten- und Verdrahtungsstandard 

+ Transparenz bzgl. Verteilung, Sprache, Plattform, Persistenz 

+ Transaktionskonzepte 

+ Vordefinierte Dienste, Komponenten, Anwendungen 

− Komplex, hoher Einarbeitungsaufwand 

− hoher Kommunikationsaufwand, da (außer COM, .NET) für verteilte 

Anwendungen vorgesehen 

− Flexibilität führt zur hoher Komplexität auch im Produktionscode 

(Laufzeitprobleme) 

− Objektorientierte Entwurfskonzepte nicht auf Komponentenebene 

umgesetzt 

− Kaum Unterstützung für Anpassungen der Komponenten

Gliederung 







2. CORBA 


4. (D)COM, .NET 

3. Schnittstellen- und Datenanpassung mit XML 




◮ Metaprogrammierung und Invasive Komposition 


Ziel 


Spezifikation und Anpassung von Komponenten: 

Schnittstellen und Datenformate

Datenformate: Historie 

• Cobol 

◮ Grundprinzip: alle Ausgaben als Text (Serialisierung) 

◮ Textelemente typisiert 

• Unix 

◮ alle Ausgaben serielle (Text-)Dateien 

◮ typfrei: Typisierung der Systemdateien nicht explizit codiert 

daher alle Systemdateien einheitlich mit Texteditor bearbeitbar, falls 

der Benutzer das Format (Typ) kennt 

Unterschied zu Windows und neueren Ansätzen unter Linux 

• SGML - Standard Generalized Markup Language 

◮ Ziel: einheitliche Beschreibungssprache für Textformatierung 

◮ Definieren eigener Unterformate (Typen) möglich 

◮ syntaktisch sehr flexibel 

• HTML - Hypertext Markup Language 

◮ Ein Unterformat von SGML 

◮ Keine eigenen Unterformate möglich 

◮ Siegeszug mit dem WWW 


eXtensible Markup Language (XML) 

• Problem: 

◮ Datenaustausch zwischen Programmen, nicht nur Textformatierung 

◮ aus SGML entwickelt, aber erweitertes Aufgabengebiet 

◮ HTML zu spezifisch, nur für Hypertext 

• Lösung: Datenaustauschformat, allgemeine Sprachen zur 

◮ Beschreibung von attributierten Termen/Bäumen 

◮ Typdefinition für attributierte Terme/Bäume 

◮ Querverweise durch Attribute 

◮ Untermenge von SGML 

◮ Syntax an HTML angelehnt 

• Umsetzung: XML 

◮ Standard des WWW Konsortiums (W3C): http://w3c.org 

◮ kritische Masse erreicht 


XML Beispiel 


 

 

 

 

1234-A 

2001-01-30 

No complications. 

 

 

XML Standards 


benutzt 

Wohlgeformtes 

XML 

benutzt 

benutzt 

ersetzt 

DOM 

Gültiges 

XML 

benutzt 

DTD 

ersetzt 

ersetzt 

DOM2 

Schema-gültiges 

XML 

benutzt 

XML Schema 

benutzt 

benutzt 

XPath 

benutzt 

XML Namespaces 

benutzt 

XSLT

XML als Format 

• Leichter zerteilbar als allgemeine kontextfreie Sprachen 

◮ Elemente durch Separatoren "" ausgezeichnet 

◮ Explizite Schachtelung von Elementen (schließende Klammern) 

◮ Grammatik für Kinderelemente ist regulär 

• Einschränkung 

◮ Format ist auf Unicode definiert 

◮ Konvertierung in Bytestrom (Serialisierung) nicht in Grammatik 

festgelegt 

Unicode UTF-8 oder UTF-16 

ISO-8859-1, -15, . . . 

• Formen der Korrektheit 

◮ Wohlgeformtes (well-formed) XML: 

Korrekte Syntax und Klammerung 

◮ Gültiges (valid) XML: 

Wohlgeformt und konform zu einer DTD 

◮ Schema-gültiges (schema-valid) XML: 

Wohlgeformt und konform zu einem XML Schema 


Namensräume 

• Problem: Heterogene Systeme 

◮ Wieviele Definitionen von z.B. Behandlung 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 

◮ Lange Bezeichner für Namensräume, lokale Platzhalter im Dokument 

◮ URIs als Bezeichner eines Namensraums (aber nicht vorgeschrieben) 

◮ 

 

 

• leider ein technisch nicht ausgereifter Standard: 

◮ Gültigkeitsbereich eines Namensraum-Bezeichners: XML-Element mit 

Kindern (wie Variable) einschl. Elementname, vorangehende Attribute! 

◮ Daher nicht LL(k) wie der Rest von XML 

◮ Pässe: 

Zerteile wohlgeformtes XML, löse Namensräume auf, prüfe Typen 


Document Type Description (DTD) 

• Typbeschreibung für XML-Dokumente (kontextfreie Grammatik) 

• Selbst kein XML-Dokument 

• Basisdatentypen für Elemente 

◮ Zeichenkette (PCDATA) 

• Typkonstruktoren für Elemente 

◮ Iteration 

◮ Sequenz 

◮ Alternative 

◮ Schachtelungen davon 

• Basisdatentypen für Attribute 

◮ Zeichenkette (CDATA) 

◮ Schlüssel und Bezüge (ID, IDREF) 

◮ . . . 

• Typkonstruktoren für Attribute 

◮ Aufzählung 


DTD Beispiel 


 

 

 

 

 

 

 

 

 

 


Typkonstruktoren und reguläre Ausdrücke 

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) 


Probleme mit DTDs 

• selbst kein XML (Problem bei boot-strapping) 

• sehr eingeschränktes Typsystem 

◮ keine Basistypen außer Zeichenketten 

◮ keine festen Reihungen 

◮ keine Vererbung 

• mehrdeutige Ableitungsbäume 

◮ Ursache: Schachtelung von Konstruktoren 

◮ Beispiel: 

DTD-Fragment 

Ableitung von ist nicht eindeutig 

• Namensräume nicht integriert 

• langsame Verarbeitung wegen Interpretation 


XML Schemata 


die (nachträglich erfundene) Verallgemeinerung von DTDs 

• Zweck: Beschreibung der Struktur und Einschränkung des Inhalts von 

XML-Dokumenten 

• XML Schema ist selbst XML-Dokument 

• W3C Standard 

• Typsystem 

◮ übliche Basistypen: String, Integer, . . . 

◮ unübliche Basistypen: Date, Time 

◮ Einschränkungen darauf möglich 

◮ Feste Reihungen durch Einschränkung des Sequenzenkonstruktors 

◮ Kovariante und kontravariante Vererbung 

• Namensräume integriert 

• langsame Verarbeitung wegen Interpretation 

• mehrdeutige Ableitungsbäume

XML-Schema: Bestandteile 

Bestandteile von XML-Schema: 

• Primäre Komponenten, die einen Namen haben können (Typdefinitionen) 

oder müssen (Element und Attributdeklarationen): 

◮ Einfache Typdefinitionen 

◮ Komplexe Typdefinitionen 

◮ Attributdeklarationen 

◮ Elementdeklarationen 

• Sekundäre Komponenten, die Namen haben müssen: 

◮ Attributgruppendefinitionen 

◮ Identity-constraint-Definitionen 

◮ Modellgruppendefinitionen 

◮ Notationsdeklarationen 

• Hilfskomponenten: 

◮ Annotationen 

◮ Modellgruppen 

◮ Partikel 

◮ Wildcards 

◮ Attributverwendungen 


XML-Schema: Elemente 

• Definition eines Elements: 

◮ Zuordnung eines Typs zu einem Namen 

◮ Gültigkeitsbereich ist der umgebende Typ 

• Typ durch Attribut zuordnen: 

 

• Typ explizit angeben: 

 

 

 

 

 

 

 

 


Typen in DTDs und XML Schemata 

• DTD 

◮ Typ kein eigenständiges Konzept 

◮ Definition eines XML-Elements 

definiert den zugehörigen Typ 

mit globalem Gültigkeitsbereich 

• XML Schema 

◮ Typ ist eigenständiges Konzept 

Konstruktoren für benutzerdefinierte Typen 


XML Schema - einfache Typen - Beispiel 

• Konstruktoren 

◮ Einschränkung 

◮ Vereinigung 

◮ Iteration 

• Hier nur Einschränkung 

 

 

 

 

 

 

 

 

 


XML Schema - komplexe Typen - Beispiel 

• Konstruktoren 

◮ Einschränkung 

◮ Erweiterung 

• Hier nur Einschränkung 

 

 

 

 

 

 

 

 

 


XML Schema - Attribute - Beispiel 


• Attribute werden innerhalb komplexer Typen definiert 

• Definition bindet einfachen Typ an Namen 

• Unterschiedliche Syntax: Bezug auf Typ, Inline-Definition 

 

 

 

 

 

 

 

 

Datentypen in XML Schema 

Programmiersprachen 

• Basisdatentypen 

◮ unterschiedliche Integers, 

Floats, usw. 

• Reihungen 

◮ statisch 

◮ dynamisch 

◮ flexibel 

XML Schema 

• Basisdatentypen 

◮ erweitert um URL, Datum, Zeit, 

etc. 

◮ Standardtypen mit beliebigen 

Einschränkungen auf Wertebereiche 

und Literale 

• Reihungen durch Attribute 

◮ dynamische Grenzen (min=max 

→ statisch) 

minOccurs=’X’ maxOccurs=’Y’ 

◮ dynamische und flexible Reihungen 

werden nicht unterschieden 

maxOccurs=’unbounded’ 


Datentypen in XML Schema 


• Verbunde 

◮ Zugriff über Namen 

• Verbunde mit Varianten 

◮ Verbunde mit/ohne Typkennung 

◮ Zugriff auf Variante, die in Typkennung 

codiert ist 

◮ typsicher, wenn kein Variantenwechsel 

bei ein und demselben 

Objekt möglich ist 

XML Schema 

• Verbunde 

◮ Struktur von XML (Schema ist 

XML) 

◮ Zugriff über Namen von Unterelementen 

und/oder Position 

• Verbunde mit Varianten durch Elemente 

mit Auswahl 

◮ Auswahl 

◮ aktuelle Variante i. a. nicht erkennbar, 

da nicht eindeutig 

◮ nicht typsicher 

◮ typsicher, wenn Auswahl nur unter 

Elementen (siehe Beispiel auf 

nächster Folie) 


Beispiel: Verbunde mit Varianten 


 

 

 

 

 

 

 

 

 

 

 

 

Ableitung für ? 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

hier sicher, z.B.

Deterministische Inhaltsmodelle 


• Inhalt von Elementen (Kinder) jeweils durch regulären Ausdruck 

beschrieben 

⇒ Typsicherheit, wenn regulärer Ausdruck deterministsich: Beim Zerteilen 

eines Satzes ist jedem Symbol ohne Vorschau das entsprechende Symbol 

im Ausdruck zuzuordnen. 

◮ Nicht deterministisch: Satz “aaaaaab“ und Ausdruck “a*b|a*c“ 

• Eindeutigkeit der regulären Ausdrücke herstellbar 

◮ Transformation in Automaten 

◮ deterministisch machen 

(Teilmengenkonstruktion, exponentiell) 

◮ minimieren (Klassenbildung) 

• deterministisches Zerteilen möglich 

• nicht jeder deterministische Automat hat deterministischen Ausdruck 

• deterministisches Interpretieren i.a. unmöglich

Beschreibung von Schnittstellen: Daten und Funktionen 


• Klassen 

◮ Verbunde mit Daten und 

Funktionen 

◮ Vererbung 

◮ Polymorphie 

XML Schema 

• Klassen 

◮ Verbunde wie besprochen 

◮ Referentielle Transparenz: 

keine Unterscheidung zwischen 

0-stelligen Funktionen und Daten 

◮ Keine Entsprechung für 

allgemeine Funktionen 

• Beschreibung von Funktionen erfordert 

Erweiterungen 

◮ Standard: WSDL 


Web Services Description Language (WSDL) 

• Im Kontext von .NET besprochen 

• Beschreibt Mengen von Funktionen 


◮ XML Schema (oder beliebige andere Sprachen ;-) 

• Probleme 


◮ Strukturiertes Programmieren - keine Objektorientierung 

◮ Keine Vererbung, keine Polymorphie 


Wiederholung: Web Services Description Language (WSDL) 

• XML-basierte Beschreibungssprache für Webdienste 

• Gegenstand: Mengen von Funktionen 

◮ Strukturiertes Programmieren 

◮ Keine Objektorientierung - keine Vererbung 


◮ XML Schema oder beliebige andere Beschreibungssprachen 


• Abbildung auf konkrete Schnittstellen 

◮ SOAP 

◮ MIME (Multi-Purpose Internet Mail Extensions) für SMTP 

• Probleme: Beliebigkeit, fehlende Objektorientierung 


Beispiel WSDL 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Datentypen in XML Schemata 


• Klassenvererbung 

◮ Spezialisierung 

(Kovarianz) 

◮ Konformität 

(Kontravarianz) 

• Referenzen 

◮ typisiert oder untypisiert 

◮ auf beliebige Werteobjekte 

XML Schema 

• Ableitung von Verbundtypen 

◮ Einschränkung entspricht Spezialisierung 

◮ Erweiterung entspricht Konformität 

• Referenzen durch Attribute 

◮ ID und IDREF Typen 

◮ Untypisiert 

◮ Identifikation von Objekten mit 

Schlüsselwerten 

◮ Keine Referenzen auf WSDL- 

Dienste 


Wertung 

XML erlaubt die Spezifikation von Daten und der Parametrisierung von 

Diensten in Schnittstellen. 

• Vorteile 

◮ standardisierte Syntax 

◮ standardisierte Transformation 

• Nachteile 

◮ nur Wertesemantik 

◮ nur Verbunde, keine Klassen 

◮ kein Vererbungskonzept 

• Es besteht also noch Verbesserungsbedarf, um Komponenten speziell 

objektorientierte mit XML zu spezifizieren. 


XML und IDL 


• beide sollen Typen definieren 

• Anpassungen auf Datenebene anwendungsspezifisch 

• Anpassungen auf Beschreibungsebene (Metaebene)- 

Meta Object Facility (MOF) bietet Lösung 

• Abbildung über MOF technisch problemlos

IDL und XML Schema 


IDL und XML Schema 

MOF 

MOF 

IDL 

IDL 

XML 

XML 

Schema 

Schema 

Abfrage/ 

Abfrage/ 

Navigation 

Navigation 

IDL- 

IDL- 

Spezifikation 

Spezifikation 

Umwandlungsroutinen 

Umwandlungsroutinen 

Schema- 

Schema- 

Spezifikation 

Spezifikation 

Daten- 

Daten- 

Instanz 

Instanz 

Daten- 

Daten- 

Instanz 

Instanz 


Verarbeiten von XML-Dokumenten 


Verarbeitung von XML-Dokumenten: Zugriff auf Baumstruktur notwendig 

• Document Object Model (DOM) 

◮ Ziel: Navigieren in einem XML-Baum ermöglichen 

(zur Implementierung von (Datenbank-)Abfragen) 

◮ Baumstruktur implizit durch Navigation gegeben. 

◮ 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 

◮ alles explizit, daher langsam, umständlich, kein Stromformat 

◮ Typinformation geht verloren 

• SAX: push- statt pull-Modus. 

• 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)

DOM: 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 ();

Anpassungen: Transformation von XML-Dokumenten 


• Schnittstellen und Daten durch XML-Dokumente beschrieben 

⇒ Transformation der XML-Dokumente zur Beseitigung von 

Inkompatibilitäten zwischen Komponenten und damit Anpassung der 

Schnittstellen oder Nachrichten (inkl. Prozeduraufrufen)

Transformation von XML-Dokumenten 

• bislang: 

◮ Daten beschrieben mit Typbeschreibung 

◮ Interne Darstellung der Daten 

• nun: 

◮ Transformation eines XML-Dokuments in ein anderes oder in 

Nicht-XML-Form 

• Vorgehen: 

◮ Transformator ausprogrammieren 

◮ XSLT (entsprechender XML Standard dafür) benutzen 

◮ deskriptiver Ansatz 

beschreibe Ergebnis der Transformation 

nicht die nötigen Operationen! 

◮ 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 

◮ Transformation definiert durch XSLT Spezifikation 

◮ Ausgabe nicht notwendig XML 


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 


Beispiel - Regeln 


 

 

 

 

 

 

Patient Nummer: 

 

 

...

Beispiel - Ausgabe 


 

 

 

 

Patient Nummer: 0503760072 

... 

 

Pfadausdrücke (XPATH) 

• Pfad bildet (DOM-) Eckenmengen zur Weiterverarbeitung 

◮ Folge von Schritten schritt1/schritt2/.../schrittN 

• Schritt bildet neue Eckenmenge aus einer bestehenden 

◮ Folge: achse::auswahl[prädikat1][prädikat2]...[prädikatM] 

• Achsen bilden neue Eckenmenge 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 Eckenmenge 

◮ Joker für Elementnamen: * 

◮ Joker für Attributnamen: @* 

◮ Wurzel des Dokuments: / 

◮ Text, Kommentar, Verarbeitungsanweisungen 


Prädikate 

• Prädikate filtern bestehende Eckenmenge 

◮ 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 Schablonen bestehend aus 

◮ Muster (XPATH Ausdruck) 

◮ Anweisungen (Ausgaben, rekursive Aufrufe etc.) 

• initial enthält die Kontextknotenliste den Wurzelknoten 

• Auswahl des passenden Musters 

◮ Ausführung der Anweisungen in der Schablone 

◮ bei Rekursion (apply-templates Anweisung): 

Aufbau neuer Kontextmengen 

• Einschränkungen mittels 

◮ Select (XPATH Ausdruck) 

◮ Regelmodi und -namen

Beispiel Kopierer 


 

 

 

 

 

 

 

 

 

 

 

Weitere Möglichkeiten von XSLT 

• Klassische Funktionsaufrufe mit Parametern 

• Rekursion 

• Fallunterscheidung 

• Variable mit statischer Einmalzuweisung 

• Schnitte von Eckenmengen 

• Anbindung an Skriptsprachen 

◮ möglicher Indikator für mangelnde Mächtigkeit von XSLT 

◮ bisher kaum genutzt 


Beispiel mit Rekursion: XML → HTML 


Beispiel XML nach HTML 

document 

section 

entry 

entry 

entry 

section 

entry 

entry 

table 

tr 

tr 

tr 

tr 

th 

th 

td 

td 

td 

td 

td 

td 


Beispiel 


 

 

 

 

 

 

 

|\\ 

 

 

 

 

 

 

Beispiel fortgesetzt 


 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Wertung 


• XSLT ist turingmächtig 

◮ Bedingungen 

◮ Rekursionen 

• deskriptiv 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 Skripte online 

• inhärent ineffizient 

◮ Kontextinformation zur Anwendbarkeit einer Transformation muß u.U. 

immer wieder neu berechnet werden 

◮ Aufwand O(n 2 ), obwohl Problem eigentlich O(n) . . . 


Alternativen 

• Nachteil aller Alternativen: Transformationsspezifikation ist kein 

XML-Dokument. 

• Dafür: Saubere, mächtige Spezifikations- und Transformationskonzepte: 

◮ Termersetzungssysteme (TES) 

Eingabe: (XML)Term, Muster, 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 (IPD) oder Progress (RWTH Achen) 

◮ Durchmustern 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 für XML → HTML 


PATTERNDEF { document < sections:section* > } MyDoc; 

PATTERNDEF { section < entries:entry* > } Section; 

PATTERNDEF { tr } TableRow; 

PATTERNDEF { td } TableData; 

PATTERNDEF { html < head body > } HTMLRoot; 

PROCEDURE transform 

{ 

WITH d

DOM kritisch betrachtet 


• Generatoren brauchen explizite Typ- und Strukturinformation in den 

AST-Ecken 

◮ DOM hat beides nicht 

• DOM unterstellt, daß der komplette XML-Baum (alle Ecken) aufgebaut 

wird 

• Transformation filtert Ecken, solche Ecken müssten gar nicht erst erzeugt 

werden 

◮ Standard Übersetzerbautechnik 

◮ Übergang vom konkreten zum abstrakten Strukturbaum (AST) 

• XSLT ist an DOM aufgehängt, nicht an XML-Schema 

⇒ ◮ Übertragung der Probleme von DOM 

◮ Umständliche Spezifikation der Transformationen und deren Steuerung.

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 muß automatisch generiert werden 


Generierte Transformationen 

Schema 


Generierte Transformationen 

DTD 

Generator 

XSLT 

Generator 

Generator 

XML 

Zerteiler 

Transformation 

XML 


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×10 6 Zeilen pro Sekunde 

◮ 12 MB / sec auf Intel Pentium III mit 500 MHz 

◮ 15 MB / sec auf Athlon mit 800 MHz 

• Web Compiler 


Web Compiler 



Potential generierte Zerteilung 


Potential generierte Zerteilung 


Potential Transformation XSLT 


Potential Transformation 


Potential Transformation GES 


Potential Transformation GES 


Potential generierte Zerteilung - Java 


• Objekterzeugung für Zwischenstrukturen dominiert die Laufzeit 

• Für große Dateien: Analyse der DTD vernachlässigbar 

◮ 15% Gewinn bei 5MByte Dokument 

◮ 1,5% Gewinn bei 50MByte Dokument 

• Standard-Zerteilung ist hinreichend schnell

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 ;-)

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 


Ausblick 


• Datenanpassung geleistet 

• Offene Anpassungen 

◮ Funktionalität 

◮ Kommunikation 


◮ Protokolle 

◮ Globale Korrektheit 

• Zuvor XML Standards für Kommunikation zwischen Komponenten, deren 

Schnittstellen etc. 

◮ Im Kontext von .NET besprochen 

◮ Allgemeine Standards

Gliederung 







2. CORBA 


4. (D)COM, .NET 

3. Schnittstellen- und Datenanpassung mit XML 




◮ Metaprogrammierung und invasive Komposition 


Softwarekomposition und Metaprogrammierung 


Literatur 


• SOP: http://www.research.ibm.com/sop/sophome.htm 

• LambdaN: Dami, Laurent. Software Composition. Dissertation Universität 

Genf. 1997 

• Mulet, P., Malenfant, J., Cointe, P. Towards a Methodology for Explicit 

Composition of MetaObjects. OOPSLA 98. 

• Aksit, M., Bergmans, L., Vural, S. An object-oriented language-database 

integration model: The composition-filters approach. ECOOP 92. LNCS 

615, Springer. 

• Template Metaprogramming: K. Czarnecki, U.W. Eisenecker: Generative 

Programming - Methods, Tools, and Applications. Addison-Wesley, 2000 

• GenVoca: Batory, Don. Subjectivity and GenVoca Generators. 

In Sitaraman, M. (ed.). Proceedings of the Fourth Int. Conference on 

Software Reuse, April 23-26, 1996, Orlando Florida. IEEE Computer 

Society Press, pages 166-175 

• IPD-Literatur am Ende der Folien

Aufgaben und Ziele: Rückblick 


Komponentenbegriff: Modul, Klasse, Menge von Klassen (keine oo-Objekte!) 

CORBA, EJB, DCOM, .NET: 

• Schnittstellenbeschreibung mit IDL, 

• Verknüpfung durch Prozedur- bzw. Fernaufruf (RMI, . . . ) 

• geeignet für nebenläufige und verteilte Systeme 

• Serialisierung der Aufrufargumente, . . . 

• Aufrufe teils direkt, teils über Behälter, teils über Makler 

• Anpassung von Argumenten (und deren Typ), Argumentreihenfolge, 

. . . limitiert 

• Anpassung während Komponentenentwicklung, Systemkonfiguration 

(deployment), Laufzeit

Aufgaben und Ziele: Rückblick II 


Komponentenbegriff: Modul, Klasse, Menge von Klassen (keine oo-Objekte!) 

CORBA, EJB, DCOM, .NET: 

• Aktivierung/Deaktivierung von Objekten, Persistenz unterstützt 

• dynamische Auswahl der aufzurufenden Komponenten durch 

Makler/Namensdienste möglich 

• Hilfsdienste: Synchronisation, Transaktionsmanagement, . . . 

• führt zu dreischichtiger Architektur: 

Anwendungskomponenten 

Vermittlungsschicht 

(ORB, Behälter,. . . ) 

Datenbasis 

(Datenbank, Dienstverzeichnisse, . . . ) 

Mit einem Wort: Komponentenkomposition ist Mittel zum Verfügbarmachen 

von Diensten, vorzugsweise mit normierten Schnittstellen

Kritik 


• allgemein akzeptierte Standardisierung von Schnittstellen nicht möglich 

(ein Lern- und ein Aufwandsproblem, geht aber vermutlich prinzipiell 

nicht) 

• mangelhafte Anpassungsmöglichkeiten für Schnittstellen 

• großer Verwaltungsaufwand zur Laufzeit 

• Konzentration auf Nebenläufigkeit/Verteilung (außer COM) 

• Kopplung von Komponenten dynamisch, mangelhafte statische 

Integrationsmöglichkeit 

• ungeeignet für lokale Kopplung unter hohen Effizienzanforderungen 

• ungeeignet zur Integration von Programmfragmenten unterhalb der 

Modul/Klassen-Ebene

Aufgaben und Ziele 


Komponentenbegriff: Modul, Klasse, Menge von Klassen (keine oo-Objekte!), 

allgemein: Kollektion von Programmfragmenten 

• effiziente Kopplung von Komponenten, möglichst ohne Laufzeitaufwand 

• Integration von Programmfragmenten als Komponenten 

(geht nur statisch, wird aber dynamisch spezifiziert) 

• flexible Anpassung von Schnittstellen 

• Unterstützung überschneidender Belange (crosscutting concern), d. h. der 

Integration von Aspekten, die Änderungen in mehreren Komponenten an 

mehreren Stellen gleichzeitig erfordern 

Im folgenden und zunächst hauptsächlich Konzentration auf Komposition 

sequentieller Systeme

Der Kompositionsprozeß I 


1. Problemlösung: 

a Systemidentifikation: Bestimmung der verlangten funktionalen und 

nicht-funktionalen Eigenschaften des Gesamtsystems 

b Klassifikation dieser Eigenschaften (feature analysis) 

c Auswahl (oder Generierung oder Programmierung) der Komponenten 

zu diesen Eigenschaften 

d Resultat: Sammlung von Komponenten und Spezifikation, wie diese 

statisch/dynamisch zusammenwirken 

e Validierung des Resultats 

erwünschte Nebenbedingungen: 

• Prozeß nach Modifikation des Anwendungsproblems leicht wiederholbar 

einschl. Validierung (Software-Evolution, Wartung, Konstruktion von 

Produktfamilien) 

• Komponenten wiederverwendbar (evtl. nach Parametrisierung)

Der Kompositionsprozeß II 


2. Komposition: 

• ereignisgesteuerte dynamische Komposition (dynamisches Weben, 

Modellvorstellung, in der Implementierung möglichst vermeiden) 

• nicht-invasive Komposition: Komponenten (Module/Klassen) als 

schwarze Kästen, Verknüpfung direkt oder mit Klebecode 

(Entwurfsmuster Umschlag, Delegation, . . . ), Weben (Klebecode) 

statisch oder statisch vorbereitet 

• invasive Komposition: Komponenten beliebig, Weben durch Integration 

von Programmfragmenten, Weben statisch oder statisch vorbereitet 

• Resultat: Spezifikation von Haken und Kompositionsoperationen

Dynamisches und statisches Weben 


Aspekte 

Aspekt 

1 

Ereignis 

dynamisches statisches 

Weben 

Webe− 

Punkt 

Aspekt 

1 

1 

2 

Aspekt 

2 

Ereignis 

gefüllt 

von 

Aspekt 

2 

1 

2 

Weber

Der Kompositionsprozeß III 

3. Implementierung der Komposition: 

• von Hand: Inspektion der Quellen, Änderungen explizit programmieren 

◮ fehleranfällig, nicht reproduzierbar, für größere Systeme nicht 

durchführbar 

• generativ: Komponenten oder Komponentengruppen automatisch 

erzeugt, z. B. durch Spezialisierung generischer Komponenten, 

Ergebnisse direkt verknüpfbar (generatives Programmieren) 

• statisches Metaprogrammieren: Analyse der Komponenten zum 

Zeitpunkt der Komponentenkonstruktion oder Systemkonfiguration, 

darauf aufbauend Transformation der Komponenten bzw. automatische 

Erzeugung von Klebecode 

• dynamisches Metaprogrammieren: Analyse der Komponenten zur 

Laufzeit (Reflexion) und automatische, dynamische Anpassung von 

Schnittstellen 

◮ allgemeine Modellvorstellung, praktisch nur in Verbindung mit 

statischer Metaprogrammierung 


Terminologie, Validierungsbedingungen 


• Belang, Merkmal, (System-)Eigenschaft: 

◮ in der feature analysis: concept, feature 

◮ in AOP: concern, aspect 

• überschneidender Belang (crosscutting concern): ein Belang, der 

gleichzeitig Änderungen in mehreren Komponenten verlangt 

Validierungs- bzw. Korrektheitsbedingungen: 

• Problemlösung: Ist das (Anwendungs-)Problem durch die Konmponentenund 

Verknüpfungsspezifikationen richtig gelöst? 

• Komposition: Ist die Verknüpfungsspezifikation durch die resultierenden 

Kompositionsoperationen korrekt implementiert? 

• Implementierung der Komposition: ist jede einzelne 

Kompositionsoperation korrekt implementiert? 

Vorsicht: Die Literatur über AOP, SOP, adaptives Programmieren, usw. 

behandelt alle drei Schritte des Kompositionsprozesses integriert und 

unterscheidet die verschiedenen Validierungsbedingungen meist nicht!

Trennung der Belange (separation of concerns) 


Belang: Systemeigenschaft (funktional/nicht-funktional) 

unterscheide 

• Problem-Belang: Eigenschaft, die aus der Aufgabe herrührt 

• Lösungs-Belang: Eigenschaft, die aus der Lösungstechnik resultiert 

Das Wort concern kommt erstmals in E.W. Dijkstra: A Discipline of 

Programming 1976 vor

Trennung der Belange: Aufgabe 


beschreibe die problem- und lösungsspezifischen Belange so, daß 

• sie kanonisch sind: Auch bei unterschiedlichen Lösungsansätzen treten sie 

immer auf (allgemeinste Form wählen, Komplexität reduzieren, von 

Einzelheiten abstrahieren) 

• sie komponierbar sind: C = C 1 ⊕ C 2 liefert Belang C komponiert aus 

Belangen C 1 , C 2 mit Kompositionsoperator ⊕. Kompositionszeitpunkt: 

Übersetzungszeit, Bindezeit, Programmstart, Objektkonstruktion, Laufzeit 

◮ Problem: überschneidende Belange, z. B. Synchronisation, lassen sich 

nicht so trennen, daß sie komponierbar werden 

• sie implementierbar ist: Belang als Code repräsentieren 

• sie abgeschlossen sind: Fortgesetzte Komposition C = C 1 ⊕ C 2 , C ′ = C ⊕ · · · 

liefert das Gesamtsystem mit einzeln ersetzbaren 

Belang-Implementierungen 

• sie validierbar sind: Qualitätskontrolle der funktionalen und 

nicht-funktionalen Belange und ihrer Komposition gewährleisten

Vorhandene Ansätze zur Komposition 

• Architektursysteme: Funktionale Komposition und Kapselung des 

Interaktionsaspekts 

• Externe Adaption: 

◮ Erweiterungen des objekt-orientierten Paradigmas (composition filters) 

• Invasive Komposition: 

◮ Generative Ansätze: 

Generatives Programmieren in C++ 

(am Beispiel. Template Metaprogramming/GenVoca) 

Kalküle für Komponentensysteme (λN-Kalkül) 

Metaobjekt-Komposition 

Subjekt-orientiertes Programmieren SOP 

◮ Modifizierende Ansätze: 

Konzepte: Haken (Webepunkte), Kompositionsschnittstelle 

Anwendungsbeispiele 

Werkzeuge und Architekturen (AspectJ, RECODER, InjectJ) 




• Formalisierung von Blockdiagrammen: 

◮ Block = Komponente 

◮ Linie = Konnektor 

• Detaillierung der Verbindungen: Linien werden auch zu Blöcken 

⇒ Kapselung des Interaktionsaspekts in Konnektoren (Adapter) 

• Sprache zur Spezifikation der Systemzusammensetzung (Komponenten 

und Konnektoren)

Konnektoren 

• Elementare Konnektoren: 

◮ Voraussetzung: Tore passen zusammen. 

◮ Realisiert durch: 

Kommunikation über gemeinsamen Speicher 

Kanäle 

Prozeduraufruf 

Nachrichtaustausch 

Ereigniskommunikation 

• Aufgaben komplexer Konnektoren: 

◮ Schnittstellenanpassung 

◮ Datenanpassung 

◮ Protokollanpassung 

◮ Überbrücken von Systemgrenzen (Adreßräume, Verteilung): Fernaufruf 

(Marshalling: Serialisierung, Deserialisierung) 


Architekturstile 


• Wenn eine Architektur nur eine bestimmte Art von Konnektoren 

verwendet, sagt man, sie hält sich an einen Architekturstil. 

• Ein Architekturstil ist eine Abstraktion über eine Menge von 

Software-Architekturen. Er definiert ein Vokabular von Komponenten- und 

Konnektortypen sowie eine Menge von Regeln nach denen man 

Komponenten und Konnektoren legal kombinieren darf. 

• Ein Architekturstil sagt nichts über die Protokolle der Interaktion 

zwischen Komponenten aus. 

• Eine erste Klassifikation von Architekturstilen findet sich in 

[Shaw,Clements1996] 

• Beispiele für Architekturstile sind: 

Datenfluß: Datenflußkonnektoren verbinden die Komponenten zu einem 

Datenflußgraph. 

Aufruf: Funktionsaufrufe verbinden die Komponenten zu modularen 

Systemen, abstrakte Datentypen, objektorientierten Systemen oder 

Dienstleistungssystemen (speziell Client-Server-Systeme).

Systemkonstruktion mit Architektursystemen 

• Vorgehen: Gegeben eine Menge von Komponenten und Konnektoren. 

◮ Anordnen zu einem Gesamtsystem 

◮ Prüfen der Zweckmäßigkeit 

◮ Simulation 


Standardarchitekturen I: Fließband 


Fließband (engl. pipeline): Konnektoren beschreiben den Datenfluß und die 

Synchronisation zwischen den einzelnen Teilen des Fließbandes. Steuerund 

Datenfluß müssen nicht der gleichen Richtung folgen.

Standardarchitekturen II: Client/Server 


Dienstnehmer/Dienstgeber (engl. client/server):

Standardarchitekturen III: Ablage 


Ablage (engl. repository oder blackboard): Gemeinsam genutzte 

Datenverwaltungskomponente. 

Unterscheide: 

1. Ablage ist Datenbank: 

• Datenproduzenten legen Daten ab. 

• Datenkonsumenten haben bestimmte Aufgabe, wissen, welche Daten 

sie bei der Datenbank abfragen.

Standardarchitekturen III: Ablage (Fortsetzung) 


2. Ablage verwaltet Aufträge 

• Es werden Aufträge abgelegt bzw. abgeholt. 

⇒ Workflowsystem 

3. Verteilung der Datenverwaltungskomponente

Standardarchitekturen IV: Schichten 


Schichten: Jede Schicht bietet der darüber liegenden eine gewisse 

Funktionalität an, stellt sich dieser also als virtuelle Maschine dar.

Architektursysteme: Konzepte und Anwendung 

• Binden von Toren an interne Dienste 

• Komposition als parallele, hierarchische Komposition von Prozessen. 

Speziell in Darwin: Dienste sind Tore. 

◮ Unterscheidung zwischen Import- und Exportschnittstelle. 

◮ Explizites Verbinden von exportierten und importierten Toren 

(Diensten) 

• Trennung von Schnittstelle (Spezifikation) und Implementierung von 

Komponenten 

• Spezifikation durch Ereignisse und Protokolle 

⇒ Simulation möglich 

◮ Implementierung ebenfalls durch Simulation 

• Große Menge an vorgegebenen Konnektoren (UniCon) 

• Benutzerdefinierte Konnektoren möglich 

• Bearbeiten der Architekturrepräsentation mit Werkzeugen 

⇒ Austauschformat für Architekturbeschreibungen notwendig 

◮ Format der Community“: ACME 

” 


Modellierung des Bindens von Toren: Darwin (1) 


• Beispiel: Systembeschreibung für ein einfaches 

Erzeuger-Verbraucher-System in Darwin, Implementierung offen: 

#include 

#include 

struct producer: public process { 

portref output; 

producer { 

for (int i=1; 100; i++) 

output.out(char i); 

exit(0); 

} 

} 

component producer 

{ require output; } 

component consumer 

{ provide input; } 

component producer-consumer { 

inst 

p : producer@"charles"; 

c : consumer@"babbage"; 

bind 

p.output -- c.input; 

}

Exkurs: Modellierung mit dem π-Kalkül 

• Prinzip: Alles wird mit Prozessen modelliert. 

• Prozesse kommunizieren über Kanäle durch Ein- und Ausgabeaktionen. 

Kanäle sind durch ihren Namen identifiziert. 

• Aktionen von Prozessen sind: 

• Prozeß: 

α ::= āx Ausgabe von x auf Kanal a 

a(x) Einlesen von x von Kanal a 

τ Stille Aktion 

P ::= 0 Leerer Prozeß: keine Aktion, terminiert sofort 

α.P Präfix: Ausführen der Aktion α, dann weiter mit P 

P + P Indeterministische Auswahl 

P | P Parallele Komposition 

[x = y]P P falls x = y, [x ≠ y]P P falls x ≠ y 

(νx)P Einschränkung: Kanal x ist nur in P bekannt 

!P unendliche Replikation von P 

A(y 1 , . . . , y n ) Definition eines Prozeßnamens 

• Kommunikation kommt bei passenden Ein- und Ausgabepräfixen zwischen 

τ 

Prozessen zustande: (ȳx.P | y(z).Q) −→ (P | Q{x/z}) 


Modellierung des Bindens von Toren: Darwin (2) 


Modellierung mit dem π-Kalkül 

• Anbieten eines Dienstes s an dem Tor p (provide p;) ist modelliert durch 

den Prozeß: 

Prov(p, s) 

def = !(p(x).¯xs) 

s = Referenz auf den angebotenen Dienst, 

x = Stelle, an der der Dienst benötigt wird. 

• Verlangen nach einem Dienst an der Benutzt-Schnittstelle r (require r;) 

ist modelliert durch den Prozeß: 

Req(r, l) 

def = r(y).ȳl 

l = Stelle an der der Dienst benötigt wird, 

y = Name des Dienstanbieters (des entsprechenden Tores). 

• Binden von Diensten (bind r -- p) ist modelliert durch den Prozeß: 

Bind(r, p) 

def = ¯rp

Darwin (3): Herstellen einer Bindung 

• Herstellen einer Bindung = parallele Komposition der Prozesse Prov, Req 

und Bind: 

Req(r, l) | Bind(r, p) | Prov(p, s) 

≡ r(y).ȳl | ¯rp | !(p(x).¯xs) 

≡ ¯pl | !(p(x).¯xs) 

≡ ¯ls | !(p(x).¯xs) 

Die Referenz auf den Dienst s wird korrekt zum Ort l transportiert, an der 

der Dienst benötigt wird. 


Systemsimulation: Rapide (1) 


• Simulation durch Modellierung mit Ereignissen möglich. 

• Beispiel: System von Num Anwendungen und Num von den Anwendungen 

genutzten Ressourcenverwaltern, die über parametrisierte Ereignisse 

miteinander kommunizieren. 

type Application is interface 

extern action Request(p : params); 

public action Results(p : params); 

end Application; 

type Resource is interface 

public action Receive(Msg : String); 

extern action Results(Msg : String); 

constraint 

match 

((?S in String)(Receive(?S) -> Results(?S)))^(*~); 

end Resource; 

architecture AP-RM-Only(Num : Integer) 

return X/Open is 

P : array(Integer) of Application; 

Q : array(Integer) of Resource; 

connect 

for i : Integer in 1..Num generate 

(?M in String) 

P(i).Request(?M) to Q(i).Receive(?M); 

end generate 

end AP-RM-Only

Modellierung mit Ereignissen: Rapide (2) 

• Legende 

◮ -> spezifiziert die kausale Abhängigkeit von Ereignissen, 

◮ ? ist der Existenzquantor, 

◮ ~ bedeutet Disjunktheit, 

◮ * mindestens eine bis beliebig viele wiederholte Anwendungen des 

folgenden Operators auf alle links davon stehenden Ereignismuster. 


Protokolle: Wright 


• definiert die Semantik von Toren, Konnektoren und Rollen formal im 

Prozeßkalkül CSP als Prozesse, die Interaktionsprotokolle spezifizieren. 

• Die Semantik eines Konnektors ist die parallele Komposition der Prozesse, 

die seine Rollen und seinen Kleber (engl. glue) repräsentieren. 

• Das System sieht die statische Prüfung von Protokollen durch 

Modellprüfung vor. 

• Benutzerdefinierte Komponenten- und Konnektortypen möglich. 

• Es lassen sich aber nur statische Konfigurationen beschreiben.

Wright: Beispiel 


• Dienstleistungssystem: 

System SimpleExample 

component Server = 

port provide [provide protocol] 

spec [Server specification] 

component Client = 

port request [request protocol] 

spec [Client specification] 

connector C-S-connector = 

role client = (request!x → result?y → client) ⊓ $ 

role server = (invoke?x → return!y → server) ✷ $ 

glue (client.request?x → server.invoke!x → 

server.return?y → client.result!y → glue) ✷ $ 

spec = ... 

Instances 

s : Server 

c : Client 

cs : C-S-connector 

Attachements 

s.provide as cs.server; 

c.request as cs.client 

end SimpleExample

Wright: Beispiel 

• Legende 

◮ $ = Prozeß, der das Erfolgsereignis akzeptiert und dann terminiert, 

◮ ⊓ (interne Auswahl): 

bedeutet nicht-deterministische Auswahl eines der verbundenen 

Prozesse, wobei der zusammengesetzte Prozeß selbst die Auswahl 

trifft, 

Interne Auswahl beschreibt verfügbares Verhalten 

◮ ✷ bedeutet externe Auswahl. 

Externe Auswahl beschreibt notwendig erforderliches Verhalten. 


Austauschformat ACME 


System simple-client-server = { 

Component client = { 

Port send-request; 

Properties { source-code : external = "CODE-LIB/client.c" } 

} 

Component server = { 

Port receive-request; 

Properties { idempotence : boolean = true; 

max-concurrent-clients : integer = 1; 

source-code : external = "CODE-LIB/server.c" 

} 

} 

Connector rpc = { 

Roles { caller, callee } 

Properties { synchronous : boolean = true; 

max-roles : integer = 2; 

protocol : Wright = "..." 

} 

} 

} 

Attachements : { 

client.send-request to rpc.caller; 

server.receive-request to rpc.callee 

}

Parametrisierung in ACME (1) 


Style client-server = { 

Component Template client(rpc-call-ports : Ports) = { 

Ports rpc-call-ports; 

Properties { source-code : external = "CODE-LIB/client.c" } 

} 

Component Template server(rpc-receive-ports : Ports) = { 

Ports rpc-receive-ports; 

Properties { source-code : external = "CODE-LIB/server.c" } 

} 

Template rpc(caller-port, callee-port : Port) 

defining (conn : Connector) = { 

} 

} 

conn = Connector { 

Roles { caller, callee } 

Properties { synchronous : boolean = true; 

max-roles : integer = 2; 

protocol : Wright = "..." 

} 

} 

Attachements { conn.caller to caller-port; 

conn.callee to callee-port 

}

Parametrisierung in ACME (2): Anwendung 


System complex-client-server : client-server = { 

c1 = client(send-request); c2 = client(send-request); 

c3 = client(send-request); 

s1 = server(receive-request); s2 = server(receive-request); 

} 

rpc(c1.send-request, s1.receive-request); 

rpc(c2.send-request, s1,receive-request); 

rpc(c3.send-request, s2,receive-request);

Architektursysteme: Beurteilung 


• Kapselung des Interaktionsaspekts 

• Anpassungen durch Konnektoren 

• Systemrekonfiguration = Austauschen von Konnektoren. 

• Nicht-invasive Anpassung 

• Komponentenbegriff: Modul/Klasse (rekursiv) 

• ABER: 

◮ Tore müssen bereits in den Komponenten gekennzeichnet sein (meist 

manueller Prozeß) 

◮ Nachträgliches Hinzufügen von Toren nur manuell möglich. 

◮ Eingeschränkte Adaptionsmöglichkeiten: Z.B. keine Anpassung von 

Komponenten bzgl. angebotener Dienste 

◮ Viele verschiedene Sprachen und Formalismen, jeweils für bestimmten 

Zweck. 

+ Formalisierung von Blockdiagrammen 

+ Integration von Protokollen 

– Geringe Akzeptanz, weil neue Sprachen erfunden wurden oder die 

Formalismen nicht in die (Basis-)Programmiersprachen integriert sind: 

andere Syntax und Semantik. 

– Manuelles Abgleichen der Abstraktion und des Quelltextes notwendig 

⇒ Inkonsistenzen möglich (vgl. Model Driven Architecture)

Kompositionsfilter (composition filters, CF) 


Hauptentwickler: Mehmed Aksit et al., U Twente 

• Ältester Ansatz (seit 1992) 

• Idee: Botschaften zwischen Objekten werden gefiltert

Kompositionsfilter: Beispiele 

• Beispiele für Filter 

◮ Botschaften verschlucken 

◮ Botschaften delegieren (Vererbung, Delegation) 

◮ Botschaften verzögert weiterleiten 

◮ mit anderen Objekten synchronisieren (Synchronisationsprotokolle) 

◮ Objekt(e) modifizieren (Anpassung) 


Kompositionsfilter: Umsetzung (1) 


eingehende Botschaften 

Eingangs− 

filter 

• Umwicklen eines Objekts mit Schnittstellenobjekt, 

das die Filter enthält. 

◮ Botschaft: Methodenaufruf + Absender 

+ Empfänger 

◮ Kernobjekt: das Objekt, dessen 

Ein/Ausgang gefiltert wird. 

◮ Eingangsbotschaften durchlaufen alle 

Filter, bevor sie (eventuell) an das 

Kernobjekt gehen, Ausgangsbotschaften 

analog 

externe Objekte 

interne Objekte 

Kern− 

objekt 

Schnittstellenobjekt 

Ausgangs− 

filter 

ausgehende Botschaften

Kompositionsfilter: Umsetzung (2) 

• Implementierung: 

◮ Sicherstellen, daß Kommunikation immer Schnittstellenobjekte trifft 

und nicht direkt das umwickelte Objekt. Das Umgehen der Filter darf 

nicht möglich sein! 

◮ Problem: Selbstreferenzen (Objektschizophrenie) 

Kernobjekt identifiziert durch Pseudovariable inner. 

Kernobjekt + Schnittstellenobjekt identifiziert durch Pseudovariable 

self. self wird nicht dynamisch gebunden. 

Pseudovariable server entspricht dynamisch gebundener 

Selbstreferenz: Objekt an das die ursprüngliche Nachricht ging. 

• Auslegung der Filter als Objekte 

⇒ Dynamische Anpassung durch Filtertausch möglich 

• Konsequenz: Sehr mächtiges Konzept, besonders zur Anpassung 


CF: Sandkasten 

• Fängt alle Botschaften von und an Komponente ab 

• Technik bekannt aus EJB Container 

◮ Dort keine echte Delegation 

◮ In Methoden des Kernobjekts ist this das Kernobjekt 

◮ Direkte Aufrufe an eigene Methoden 

◮ Weitergabe von Referenzen auf this möglich 

(wird nur bei Fernaufrufen auf stub umgesetzt) 

• Echte Delegation einfach in nachrichtenbasierten Sprachen (z.B. 

Smalltalk) 

• In aufrufbasierten Sprachen 

◮ Korrektheitsannahme: Komponente kann sich selbst ohne Filter nutzen 

◮ Granularitätsannahme: es gibt nur Komponenten, alles unter dieser 

Ebene ist uninteressant 

◮ Also sind Eingangs- und Rückgabefilter hinreichend 

◮ Biege dort alle Referenzen auf Kernobjekte zu den Filterobjekten um 


CF: Beispiele Eingangsfilter 


• Ausnahme: Aufruf abweisen (argument-/absender-/zeitabhängig) 

• Delegation: Aufruf an anderes Objekt weiterleiten 

• Warten: Aufruf zwischenpuffern (Kommunikationsprotokoll einhalten) 

• Anpassen: andere Methode aufrufen, Argumente umordnen, Werte oder 

Typen ändern, Argumente ergänzen 

• Zusatz: zusätzlichen Aufruf (auch eines anderen Objekts) einfügen 

Filter können von Bedingungen über den Zustand des Schnittstellen-, des 

Kernobjekts oder anderer Objekte abhängen

CF: überschneidende Belange 


Methodik (Überlagern von Filtern, superimposition of concerns): 

• Filtermethode verallgemeinern zu Methode eines eigenständigen 

Filterobjekts 

• Folge der Filter eines Schnittstellenobjekts zur Laufzeit änderbar 

• Filterobjekt bestimmt bei Initialisierung (oder später) die 

Schnittstellenobjekte, bei denen es Filter hinzufügt (oder zurückzieht) 

Beispiel Zugriffssynchronisation: 

• Zugriffe auf ein Objekt müssen warten, wenn Objekt gesperrt 

• Bei Freigabe wird wartender Zugriff reaktiviert

CF: Implementierung 


• derzeit Implementierung von Hand 

• Spezifikationssprache zur deklarativen Beschreibung von 

Schnittstellenobjekten und Filtern vorhanden 

• aus Beschreibungssprache generierte Implementierung in Arbeit 

(CompositionJ-System) 

Einzelheiten unter http://trese.cs.utwente.nl/aksit/aksit_trese.htm

CF: Beispiel (1) 


Vererbung durch Delegation: Bestimmte Methoden der Oberklasse 

(ClaimDocument) dürfen nur in bestimmten Objektzuständen aufgerufen 

werden. 

concern ProtectedClaimDocument begin 

filterinterface documentWithViews begin 

internals 

document: ClaimDocument; // Verweis auf Objekt der Oberklasse 

externals // keine externen Objekte notwendig 

// Seiteneffektfreie Methoden zum Abfragen des 

// Objektzustands, der bei der Auswertung der Filter benötigt wird. 

conditions 

inactiveRequestHandler; inactiveRequestDispatcher; 

inactiveMedicalCheck; inactivePayment; inactiveOutputHandler; 

methods // aufrufbare, gewöhnliche Methoden 

activeTask();

CF: Beispiel (2): Eingabefilter 


inputfilters 

// Filter ::= Filtername: Filtertyp = Menge von Filterelementen 

// Filterelement ::= Bedingung => Nachrichtenausdruck 

// d.h. bei erfüllter Bedingung werden die Nachrichten im 

// Nachrichtenausdruck akzeptiert. 

// 

// Filterelement ::= Bedingung ~> Nachrichtenausdruck 

// d.h. bei erfüllter Bedingung werden alle Nachrichten 

// akzeptiert, außer den im Nachrichtenausdruck angegebenen 

// 

viewP: Error = { inactivePayment ~> 

{putApprovedClaim, approvedClaim} }; 

viewMC: Error = { inactiveMedicalCheck ~> 

{putMedicalCheckData, medicalCheckData}}; 

// etc. 

// Delegation der Aufrufe zur Realisierung von Vererbung: 

// inner verweist auf das Kernimplementierungsobjekt 

inh: Dispatch = { inner.*, document.* }; 

end filterinterfaceDocumentWithViews

CF: Beispiel (3): Implementierung 


implementation in Java // beispielsweise 

class ProtectedClaimDocument { 

boolean inactiveRequestHandler() { ... } 

boolean inactiveRequestDispatcher() { ... } 

boolean inactiveMedicalCheck() { ... } 

boolean inactivePayment() { ... } 

boolean inactiveOutputHandler() { ... } 

String activeTask() { ... } 

} 

end implementation 

end concern ProtectedClaimDocument

CF: Beispiel (4): Superimposition (Aspektweben) 


concern Locking begin // Synchronisation 

filterinterface lockBehavior begin 

internals 

lockState : boolean; // wahr, falls gesperrt 

methods 

lock(); 

unlock(); 

conditions 

Unlocked(); 

inputfilters 

// unlock geht immer, alles andere nur im Zustand Unlocked: 

// 

lockAll: Wait = { unlock, Unlocked => * }; 

disp: Dispatch = { lock, unlock }; 

end filterinterface lockBehavior; 

superimposition begin // abstrakter Belang 

end superimposition 

implementation in Java; 

class LockingSupport { 

void lock() { lockstate = true; } 

void unlock() { lockstate = false; } 

boolean Unlocked() { return !lockstate; } 

} 

end implementation 

end concern Locking;

CF: Beispiel (5): Superimposition Anwendung 


// Anwendung des Locking-Belangs auf die Workflow-Applikation 

concern WorkflowLocking begin 

superimposition begin 

selectors 

// Belang anwenden auf Unterklassen von Document und 

// TaskProcessor: 

// 

applObjects = { *:Document, *:TaskProcessor}; 

methods // Einzuwebende Methoden 

applObjects

CF: Beurteilung 


• nicht-invasive Komposition 

• Komponentenbegriff: Klasse/Gruppe von Klassen 

• Filterobjektklassen als Komponenten auffaßbar ( ” 

Konnektorklasse“) 

+ sehr mächtiges Verfahren: CORBA usw lassen sich als Spezialfälle 

darstellen 

• Verallgemeinerung der Idee der UNIX-pipe 

+ sequentiell und verteilt benutzbar 

+ Spezifikationsverfahren vorhanden 

+ bei kleinen Systemen sehr einfach von Hand implementierbar 

− für große Systeme fehlt bislang Werkzeugunterstützung 

− Validierungsmethodik angedacht, aber noch nicht ausgearbeitet 

± mittlere Effizienz: u. U. zahlreiche zusätzliche Methodenaufrufe

Übersicht 

















LambdaN-Kalkül (λN) 

• Erster Kalkül zur Codekomposition 

• Erweiterung des Lambda-Kalküls 

◮ Benannte Argumente 

◮ Namensabhängige Reduktionsregeln 

• Zweck 

◮ Mehrfachdefinition von Funktionen 

◮ Einfache Vereinigung ihres Codes 

• Prinzip: Elimination von Konnektoren, indem man von einem Aufrufer 

durch Integration des Codes direkt zum Ziel umschaltet (Vereinigung 

zweier Komponenten). 

• Realisierung: Mischregeln 

◮ Umbenennung von Parametern 

◮ Vereinigung von Ausdrücken 


Beispiel 


f = lambda x y z . 

let r = x+z in 

let s = y*x in 

record(r+s) 

. 

↓ 

Vereinigung (union) ← 

↓ 

f = lambda x y z a b . 

let r = x+z in 

let s = y*x in 

let t = a+b in 

record(r+s,t) 

. 

f = lambda a b . 

let x = a+b in 

record(x) 

. 

↓ 

Umbenennung (rename) 

↓ 

f = lambda a b . 

let t = a+b in 

record(t) 

. 

λN-vereinigte datenunabhängige Slices 

f(x=1,y=2,z=3) f(a=1,b=2) 

↓ 

↓ 

f(x=1,y=2,z=3,a=1,b=2)

Metaobjektkomposition: Hintergrund 


• Erweiterung von LISP um Objektorientierung 

→ Zwei Systeme: Flavors und CLOS (Common LSIP Object System) 

• Problem: Beide Systeme unterscheiden sich bzgl. der Semantik von 

Vererbung, Polymorphie und des Zugriffs auf Oberklassen 

⇒ Integration von CLOS- und Flavors-Programmen erfordert umfangreiche 

manuelle Anpassungen 

• Beobachtung: LISP wird interpretiert 

⇒ Semantik der Operationen wird im Interpreter festgelegt und kann dort 

abhängig von der Herkunft des Objekts (Flavors oder CLOS) 

entsprechend eingestellt werden. 

⇒ Man muß Objekten ihre Herkunft (im Beispiel Flavors oder CLOS) 

ansehen können. 

⇒ Kennzeichnung der Objekte auf Metaebene durch Metaobjekte


• Ziel: Separate Realisierung von Belangen mit anschließendem 

Zusammenmischen für konkrete Anwendung (Klassen). 

• Realisierung: 

◮ Klasseneigenschaften als Metaobjekt darstellen 

(tracing, counting, verbose, persistent,..) 

◮ Kombination durch Aggregation auf Metaebene 

◮ Der eigentliche Code einer Klasse ergibt sich aus 

den Methoden 

dem Code der Metaobjekte 

(auf irgendeine Weise komponiert; 

de facto beschränkt auf Prozedurein-/ausgang) 

• Simulation mit LambdaN möglich 



Beispiel 

Beispiel 

Class c { 

Procedure p() { 

fetch_from_db(self); 

print("enter p"); 

Normale 

Klasse 

Metaobjekt-Klassen 

persistence 

composing 

Metaobjekt- 

Methoden 

precode 

postcode 

p_counter++; 

/* algorithm */ 

c 

verbosity 

precode 

postcode 

// counting: nothing 

print("exit p"); 

counting 

precode 

postcode 

} 

} 

store_to_db(self); 

p 

Algorithmus 

• Keine Aussage über Reihenfolge des Einwebens! 

• Aspektinteraktion ist noch offene Forschungsfrage 


Generatives Programmieren: Prinzip 


• Nicht mehr jede einzelne Komponente in der Komponentenbibliothek 

vorrätig, sondern nur Schablonen, die durch Spezialisierung eine Gruppe 

von Komponenten erzeugen können. 

• Interpretation am Beispiel yacc/bison: 

1 Generator 

2 Instantiierung eines Rahmensystems: 

Eingabe: Kontextfreie Grammatik + Versatzstücke, die Code an 

Anknüpfungspunkten darstellen. 

3 Sammlung von Klassen, die zusammen eine generische Komponente 

darstellen. yacc/bison sind der Bauplan, der er es uns ermöglicht 

zusätzliche Informationen und Versatzstücke zu nehmen und 

zusammenzubinden. 

→ algorithmischer Bauplan


am Beispiel Template Metaprogramming/GenVoca 

• Templates in C++ 

◮ Parametrisierte Typausdrücke 

◮ Auswertung bei Übersetzung 

• Idee: Nutze Templates zur Komposition 

• Nachteil: Unlesbare Programme (Zweckentfremdung!) 

• Umsetzung auch denkbar mit 

◮ statisch ausgewertetem Lambda-Kalkül 

◮ offener Programmiersprache (z.B. OpenC++): Spracherweiterung über 

Metaobjektprotokoll, z.B. Abbildung neuer Syntax auf vorhandene. 

• GenVoca (Batory) 

◮ Mehrfach-Parametrisierung mit geschachtelten Template-Parametern 

(Konfiguration in mehreren Dimensionen) 

◮ Hauptsächlich für innere Anpassung 


GP am Beispiel STL 


Kontrollstrukturen mit Schablonen in C++ 


// Statisch ausgewerteter SWITCH als Typ 

template struct SWITCH { 

typedef aCase::next nextCase; 

// Statische Berechnung bei Übersetzung 

enum { tag = aCase::tag, 

nextTag = nextCase::tag, 

found = (tag == Tag || tag == DEFAULT) }; 

// Statische Auswertung bei Übersetzung 

typedef IF ::RET nextSwitch; 

typedef IF::RET RET; 

};

Generische Klassen und Rahmensysteme 


Generische Klassen (templates) und 

Rahmenwerke (frameworks) 

Formale 

Parameterklasse Parameterklasseninstanz 

Template 

Template 

class 

class 

Hook 

Hook 

class 

class 


enVoca: Komposition durch Schachtelung generischer Klassen 

GenVoca: Komposition durch 

Schachtelung von generischen Klassen 

Template T< T1< T2 ,T4 > > 

T2 

T3 

T 

T1 

T4 

T5 

Alle Ti sind unabhängig voneinander austauschbar, d.h. konfigurierbar! 

Alle Ti sind unabhängig (statische voneinander Komposition) austauschbar, d.h. konfigurierbar! 

(statische Komposition) 



Komponentensicht 


Komponentensicht 

T3 

T3 

T5 

T5 

T1 

T2 

T4 

T 

Komponenten werden intern adaptierbar, da innere Einheiten unabhängig von 

Komponenten werden intern adaptierbar, da innere Einheiten unabhängig vo 

äußeren ausgetauscht werden können. 

äusseren ausgetauscht werden können 


Subjekt-orientiertes Programmieren (SOP) 

Hauptentwickler: Ossher, Harrison (IBM research) 

• Idee: Klassen fassen verschiedene subjektive Sichten auf Objekte 

zusammen. Ein Subjekt ist eine solche Sicht. Also: 

◮ Teile von Klassen als Subjekte beschreiben 

◮ Subjekte durch Mischregeln zu Klassen zusammenführen 

• Subjekte umfassen 

◮ Operationen (generische Methoden) 

◮ Klassen- und Objektvariable 

◮ Umsetzung der Operationen in konkreten Klassen 

(Realisierung mittels Generator) 

◮ Beschreibung mit eingebettetem C++ 

• Mischregeln 

◮ Beschreibung mit einfacher Operatorsprache 


Beispiel 

• Ein einfaches Subjekt 

Subject: PAYROLL 

Operations: print() 

Classes : Employee() 

with InstanceVariables: _emplName; 

Mapping : Class Employee, Operation Print() 

implemented by 

&Employee::Print() 

// others... 

• Mischen nach Regeln 

◮ Zielklassen erhalten Operationen der beteiligten Subjekte 


Mischregeln in SOP 

• Komposition mit fest vorgegebenen Operatoren 

◮ Bindungen zwischen Subjekt und Implementierung 

equate (Zuweisung) 

correspond (Delegation) 

◮ Kombination verschiedener Subjekte 

replace (Überschreiben) 

join (Verbinden von Subjektteilen) 

◮ Mischformen von Bindung und Kombination 

merge = join; equate 

override 

• Anwendungen aus C++ leicht erweiterbar 

• Mischmodell dank fester Regeln kaum erweiterbar! 


Weiterentwicklungen von SOP 

• subject-oriented design (SOD) 

◮ Schritt von der Programmiertechnik zum Entwurfsverfahren 

◮ Im wesentlichen: SOP auf UML-Diagrammen 

• multidimensional separation of concerns 

◮ Subjekte heißen jetzt hyperslices 

Neuerung: Explizite Importschnittstelle: 

Deklaration aller verwendeten fremden Felder und Methoden 

◮ hyperspace 

Boolesche Matrix der Belange und umsetzenden hyperslices 

Strukturiert die Komposition 

◮ hypermodules 

Menge von hyperslices 

Kompositionsoperatoren wie in SOP 

◮ Werkzeug HyperJ: http://www.alphaworks.ibm.com/tech/hyperj 


Übersicht 

















Invasive Softwarekomposition 


• Invasive Komposition adaptiert und erweitert Komponenten an Haken 

durch Programmtransformation 

• Allgemeiner Mechanismus 

• Anwendungsgebiete 

◮ Anpassung 

◮ sichtenorientierte Entwicklung (u. a. SOP) 

◮ Aspektorientierte Entwicklung 

• Haken sind Ansatzpunkte für Adaption und Erweiterung 

◮ implizit (durch Sprachsyntax definiert) 

◮ vereinbart (explizit als Kompositionsschnittstelle ausgewiesen) 

• Bemerkung: Sichten sind orthogonale Aspekte

Terminologie 


• Komponentenbegriff: Kollektion von Programmfragmenten 

• Haken, Webepunkt, Anknüpfungspunkt (join point): Programmstelle, an 

der ein Programmfragment eingesetzt wird 

• Tor (port): Kommunikationsschnittstelle einer Komponente, an der 

Konnektoren ansetzen. 

Tore werden alternativ durch Haken ersetzt oder bleiben bestehen, weil 

wir invasive und nicht-invasive Komposition mischen. 

• Konnektor (Kanal, Filter, . . . ): Programmeinheit, die Komponenten 

verbindet (und ev. bei invasiver Komposition aufgelöst wird) 

Unterscheide: 

• (funktionale) Schnittstelle: gegeben durch Signatur einer Klasse 

• Kompositionsschnittstelle: Verzeichnis der Haken und Tore, an denen 

invasive oder nicht-invasive Komposition ansetzt 

Beide Begriffe sind nicht deckungsgleich: 

• Kompositionsschnittstelle umfaßt immer die funktionale Schnittstelle. 

• Tore gehören immer auch zur funktionalen Schnittstelle.

Haken 


• durch Sprachsyntax definiert: Methodenanfang/Ende, Vereinbarungen, . . . 

• Beispiel: Methodeneintritt/austritt für Umwicklung (wrapping), z.B. zum 

Umwickeln Beispiel: eines Test-Aspekts 

Methodeneintritt/austritt für Umwicklung 

• Haken in(wrapping), AspectJ (Kiczales): 

z.B. zum 

vor 

Umwickeln 

und nacheines Methodenaufrufen 

Test-Aspektsoder 

Zugriffen auf Attribute. 

m(...) { 

// Method.entry 

abc(); Method.entry 

// ... 

cde(); 

// Method.exit Method.exit 

return 

} 

Implizite Webepunkte 

m (){ 

} 

abc.. 

cde.. 

Method.entry 

Method.exit 


Haken in COMPOST 

Deklarierte Webepunkte 


Die Kompositionsschnittstelle einer Komponente besteht aus ihren 

explizit deklarierten Webepunkten 

Deklarationen 

Vereinbarung von Haken durch explizite Kennzeichnung von 

Deklaration von Programmstellen Webepunkten durch alsSpracherweiterungen Tore, z. B. durch oder z.B. 

– Standardisierte Namenspräfixe 

◮ Spracherweiterung 

– Vererbungsbeziehungen 

◮ standardisierte Namenspräfixe 

– Standardisierte Kommentar-Marken 

◮ Vererbungsbeziehungen 

◮ standardisierte Kommentar-Marken 


◮ standardisierte Methodenaufrufe

Haken für Kommunikation (Tore) 


m (){ 

} 

• Deklaration durch Aufruf abstrakter Kommunikationsmethoden 

m (){ 

// Aufruf 

e = p(d); 

} 

out(d); // Ausgangstor 

in(e); // Eingangstor 

m (){ 

// Ereignis 

notifyObservers(d); 

e = listen_to(); 

} 

⇒ Verallgemeinerung des Entwurfsmusters Schablonenmethode

Beispiel Kunde/Buchhandlung 


• Kunde 

import Buchhandlung; 

• Buchhandlung 

public class Buchhandlung { 

public class Kunde { 

public bestelle(String server) { 

// allocate new server 

Buchhandlung bh= 

holeBuchhandlung(server); 

} 

// call the services 

bh.sucheAus(); 

bh.kaufe(); 

} 

} 

public Buchhandlung() {...} 

public void sucheAus() { 

System.out.println( 

"suche aus.." ); 

} 

public void kaufe() { 

System.out.println( 

"kaufe" ); 

}

Invasive Anpassung an CORBA 


• Den Haken bh.sucheAus kann man invasiv auch durch einen anderen Aufruf 

ersetzen, falls in der Schnittstelle der Buchhandlung die gesuchte Methode 

beispielsweise choose heißt. Gleiches gilt für den Haken bh.kaufe.

Systematik der Komposition 


gegeben: mehrere Programmeinheiten (Komponenten, Aspekte, . . . ), die 

verknüpft werden sollen, um bestimmte Ziele (Kontrakte) Z zu erreichen 

1 bestimme Kompositionsstrategie (CF, invasiv, . . . ) 

2 bestimme Kompositionsschnittstelle (vereinbare bei Bedarf Haken) 

3 löse die Verknüpfung auf in eine Menge einzelner Verknüpfungsschritte, 

die zusammengenommen (!) die gewünschte Verknüpfung ergeben 

4 prüfe die Korrektheit von Schritt 3 mit Bezug auf Z 

5 identifiziere die Haken (Kompositionsschnittstelle) 

6 prüfe die Anwendungsbedingungen der einzelnen Verknüpfungsschritte 

7 führe die Verknüpfungsschritte aus 

Jeder Verknüpfungsschritt ist eine Programmtransformation, die Anwendung 

eines Kompositors

Invasive Komposition mit Kompositoren 


Invasive Komposition mit Kompositoren 

• Kompositoren werden realisiert durch Transformatoren, Optimierer, 

Übersetzer, Metaoperatoren, Metaprogramme 

Kompositoren sind Transformatoren, Optimierer, 

Übersetzer, Metaoperatoren, Metaprogramme 

Kompositor 

Kompositor 

Erkennen (ungebundener) 

Webepunkte 

Konsistentes 

Transformieren 

zu gebundenen 

Webepunkten 

Invasiv transformierter Code 


Geheimnisprinzip der invasiven Komposition 


• Komposition verwendet nur syntaktische und semantische Eigenschaften 

der Kompositionsschnittstelle, der Rest der Komponente bleibt unberührt. 

⇒ die Kompositionsschnittstelle kapselt die Komponente 

• Austausch gegen eine Variante wird möglich 

• Entspricht dem Geheimnisprinzip in 

◮ Moduln 

◮ Rahmensystemen 

◮ Architektursprachen 

◮ Aspect/J 

• aber wesentlich flexibler


Vererbung und Delegation sind Kompositoren 

Vererbung und Delegation sind Kompositoren 

K 

Passe 

Passe 

invasiv an 

invasiv an 

Vererbe 

Vererbe 

Delegiere 

Delegiere 

K 

K-Unterklasse 

K 

K-privat 

Prinzip: 

• Vererbung = statische Komposition 

• Delegation = dynamische Komposition 


Erweiterungsoperatoren für Klassen sind Kompositoren 


Anwendung auf SOP: 

Erweiterungsoperatoren für Klassen 

(z.B. SOP) sind Kompositoren 

K 

+ + 

K 

Physikalische Sicht als 

Verschmelzung der 

logischen Sichten 

K 

+ + 

Jede Komponente 

behält ihre logische 

Sicht 


Ziele invasiver Modifikation 


• seiteneffektfreie konsistente Komposition (Technik: Vererbung) 

• dynamischer Austausch (Technik: Delegation) 

• Erweiterungen um Sichten (Sichtenkonzept) 

• aspektorientierte Entwicklung (invasives Einmischen wie in AOP) 

• transparenter Komponentenwechsel 

Bemerkung: Vererbung und Delegation sind Spezialfälle invasiver 

Komposition. Beide Kompositoren kann man auch nicht invasiv einsetzen.

Wie implementiert man Kompositoren? 

• Weben und invasives Komponieren. 

◮ Wie webt man Aspektcode? 

◮ Wie komponiert man invasiv? 

◮ Antwort: Durch Metaprogrammieren auf der Grundlage konventioneller 

Übersetzertechnik. 

• Ein Programm verarbeitet Daten. 

Ein Programm ist ein Datum. (→ Strukturgraph) 

• Ein Metaprogramm verarbeitet Programme. 

Ein Metaprogramm ist ein Programm. 


Dynamisches und statisches Komponieren 


• Kompositoren arbeiten dynamisch (vgl. Veranschaulichung von AOP, 

Folie 0): Sie beeinflussen Abläufe. 

• Kompositoren müssen statisch vorbereitet werden. Dabei kann der 

Kompositor selbst bereits eliminiert werden. 

⇒ 

• Arbeitseinheiten der Komposition sind Module, Funktionsvereinbarungen, 

Anweisungsfolgen, Ausdrücke, . . . 

• Solche Programmfragmente entsprechen dynamisch gesehen Abläufen, 

oder Mengen von Abläufen 

• Einfügen neuer Zustände oder Zustandsübergänge 

◮ dynamisch zur Laufzeit. 

◮ statisch durch Einfügen neuer Variablen oder Anweisungen. 

• Ein Programm enthält neben Berechnungsschritten auch Schnittstellen, 

die der Gliederung und Konsistenzsicherung dienen.

Idee: Komposition als Programmtransformation 


Programmtransformation ist Elementartechnik. 

• Bekanntes Beispiel: Funktionsrumpf einsetzen (Substitution, offener 

Einbau) 

f(x) { A(x) } wird zu f(x) { A(x) } 

... f(z) ... ... A(x)[z/x] ... 

Anwendungsbedingung: f nicht rekursiv. 

• Beispiel für Schnittstellentransformation: Partielle Klassenabstraktion 

(fügt eine polymorphe Variationsstelle ein) 

class A { abstract class AA { 

R f(int x) { ... } wird zu abstract R f(int x) { ... } 

} } 

class A extends AA { ...} 

... A z = new A() ... ... AA z = new A() ... 

• Hier als Quell-zu-Quell-Transformation notiert: 

◮ verständliche Darstellung 

◮ geeignet zur Weiterverarbeitung 

(Softwareevolution, -sanierung)

Was heißt ” 

verhaltensbewahrend“ bei Komposition? 


• Programmtransformationen sind üblicherweise unär 

t : P → P ′ 

⇒ t ist bedeutungserhaltend, wenn P und P ′ das gleiche beobachtbare 

Ausführungsverhalten zeigen. 

• Kompositionsoperationen sind mehrstellig 

t : P 1 , . . . , P n → P ′ 

⇒ t ist bedeutungserhaltend, wenn t wohldefiniert ist und P 1 , . . . , P n 

zusammen mit der Kompositionsvorschrift t das gleiche beobachtbare 

Ausführungsverhalten zeigen wie P ′ .

Programmtransformationen zum Programmieren im Kleinen 

• Transformieren mit Erhaltung des beobachtbaren Verhaltens eines 

Programms 

• Basistransformationen: 

◮ (Einseitiges) Vertauschen von Abfragen 

◮ Vertauschen von Anweisungen 

◮ Erzeugen von Funktionsvereinbarungen 

◮ Einsetzen von Funktionsrümpfen 

◮ Falten von Funktionsrümpfen (u. a. partielle Auswertung) 

◮ Konstantenfaltung 

◮ Funktionen verallgemeinern 

• Zusammengesetzte Anwendungen: 

◮ Parameterübergabe durch offenen Einbau (Einsetzen und Falten) 

◮ Entrekursivierung von Programmen 

Funktionsumkehr 

Operandenvertauschung 

Umklammern 

◮ Optimierung von Programmen 

(z.B. Schleifentransformationen) 

◮ Programmverfeinerung 


Angewandte Programmtransformationen 


• bisher für funktionale, applikative Sprachen. 

• Wie geht das beim Programmieren im Großen? 

◮ Zustandsbehandlung bei imperativen Sprachen? 

Schwierigkeit: Ausdrücke mit Nebenwirkungen 

◮ Umgang mit hierarchischen Namensräumen? 

Schwierigkeit: überlappende Verdeckungsregeln 

(Importe, Überladung, Vererbung, Schachtelung) 

· Auflösung von Zuordnungen 

· Nebenbedingungen bei Vereinbarungen

Programmtransformationen (2) 


• Basistransformationen für die Anwendung Komposition / Dekomposition 

Basistransformation Typ benutzt 

T1 Anweisungsfolge einfügen IK – 

T1.1 . . . zu Methodenvereinbarungen IK – 

T1.1.1 . . . beim Eintritt IK – 

T1.1.2 . . . vor Austritt IK H1 

T1.2 . . . zu Variablenvereinbarungen IK – 

T1.2.1 . . . vor Initialisierung IK H1 

T1.2.2 . . . nach Initialisierung IK – 

T1.3 . . . zu Methodenaufrufen IK – 

T1.3.1 . . . vor Aufruf IK H1 

T1.3.2 . . . nach Aufruf IK H1 

T1.4 . . . zu Variablenzugriffen IK – 

T1.4.1 . . . vor Zugriff IK H1 

T1.4.2 . . . nach Zugriff IK H1 

T2 Merkmalsvereinbarung einführen var – 

T2.1 Methodenvereinbarung einführen MK – 

T2.1.1 Methode falten IK – 

T2.1.1.1 Zugriffsmethode einfügen IK – 

T2.1.2 Methode verallgemeinern MK – 

T2.2 Variablenvereinbarung einführen MK – 

T2.2.1 Parametervereinbarung einführen MK – 

T2.2.2 Lokale Variablenvereinbarung einführen MK – 

T2.2.3 Klassenattributsvereinbarung einführen MK – 

T2.3 Klassenvereinbarung einführen MK – 

T2.3.1 Klassenabstraktion einführen MK H2.2.2 

T2.3.2 Trampolinklasse einführen MK – 

T3 Merkmalsvereinbarung entfernen var – 

T3.1 Methodenvereinbarung entfernen MD – 

T3.1.1 Methode offen einbauen R – 

T3.2 Variablenvereinbarung entfernen var – 

T3.2.1 Parametervereinbarung entfernen ID – 

T3.2.1.1 Parameter bündeln ID T2.3 

T3.2.2 Lokale Variablenvereinbarung entfernen ID – 

T3.2.3 Klassenattributsvereinbarung entfernen MD – 

T3.3 Klassenvereinbarung entfernen MD –




T4 Merkmalsgruppe verschieben R T5 

T4.1 . . . entlang der Schachtelungshierarchie R T5 

T4.2 . . . entlang der Vererbungshierarchie R T5 

T4.2 . . . zwischen beliebigen Klassen R T5 

T5 Merkmalsvereinbarung verschieben R T2/3 

T5.1 Methodenvereinbarung verschieben R – 

T5.1.1 . . . entlang der Schachtelungshierarchie R H3.1 

T5.1.2 . . . entlang der Vererbungshierarchie R – 

T5.1.3 . . . zwischen beliebigen Kontexten R H3.1 

T5.2 Variablenvereinbarung verschieben R – 

T5.2.1 Parametervereinbarung verschieben R – 

T5.2.1.1 . . . innerhalb der Signatur R – 

T5.2.1.2 . . . als Klassenattribut nach außen R H3.2 

T5.2.1.3 . . . als lokale Variable nach innen R – 

T5.2.2 Lokale Variablenvereinbarung verschieben R – 

T5.2.2.1 . . . als Parameter nach außen R – 

T5.2.2.2 . . . als Klassenattribut nach außen R H3.2 

T5.2.3 Klassenattributsvereinbarung verschieben R – 

T5.2.3.1 . . . innerhalb der Klasse R – 

T5.2.3.2 . . . als Parameter nach innen R H3.2 

T5.2.3.3 . . . als lokale Variable nach innen R – 

T5.2.3.4 . . . entlang der Schachtelungshierarchie R H3.2 

T5.2.3.5 . . . entlang der Vererbungshierarchie R – 

T5.2.3.6 . . . zwischen beliebigen Klassen R H3.2 

T5.3 Klassenvereinbarung verschieben R – 

T5.3.1 . . . entlang der Schachtelungshierarchie R H3.3 

T5.3.2 . . . entlang der Vererbungshierarchie R – 

T5.3.3 . . . zwischen beliebigen Klassen R H3.3 

T5.3.4 . . . zwischen Paketen R H3.3




H1 Ausdruck abflachen R T2.2.2 

H2 Typisierung ändern R – 

H2.1 Vererbungsbeziehungen ändern R – 

H2.1.1 Neue Vererbungsbeziehung einführen IK – 

H2.1.2 Vererbungsbeziehung entfernen ID – 

H2.2 Variablentypen ändern R – 

H2.2.1 Variablentypen verfeinern R – 

H2.2.1.1 Parametertyp verfeinern R – 

H2.2.1.2 Lokalen Variablentyp verfeinern R – 

H2.2.1.3 Klassenattributstyp verfeinern R – 

H2.2.2 Variablentypen verallgemeinern R – 

H2.2.2.1 Parametertyp verallgemeinern R – 

H2.2.2.2 Lokalen Variablentyp verallgemeinern R – 

H2.2.2.3 Klassenattributstyp verallgemeinern R – 

H3 Merkmal umbenennen R – 

H3.1 Methode umbenennen R – 

H3.2 Variable umbenennen R – 

H3.3 Klasse umbenennen R – 

H3.4 Paket umbenennen R – 

• IK = invasive Komposition 

• MK = modulare Komposition 

• ID = invasive Dekomposition 

• MD = modulare Dekomposition 

• R = Restrukturierung

Charakterisierung invasiver Komposition 


• Programmfragmente haben Vor- und Nachbedingungen bezüglich ihrer 

Umgebung, ihre funktionale Schnittstelle. 

• Programmfragmente haben eine Menge von Haken (Anknüpfungspunkte, 

Webepunkte, hot spots, generische Parameter, ...), die ebenfalls Vor- und 

Nachbedingungen unterliegen: die Kompositionsschnittstelle. 

• modulare Komposition spezialisiert die Nach- bzw. Vorbedingung bzgl. der 

Umgebung der beteiligten Fragmente. 

◮ Beispiel: Anweisungen {P A } A {Q A }, {P B } B {Q B } lassen sich sequentiell 

komponieren zu {P A } A; B {Q B }, wenn Q A ⇒ P B . 

• invasive Komposition spezialisiert einen Haken des äußeren Fragments.

Wiederholung: Typische Haken 


• syntaktisch implizit vorhanden: 

◮ Vererbungsliste 

◮ Anweisungsblock 

◮ Klassenvereinbarung, . . . 

• syntaktisch explizit zu diesem Zweck vorbereitet: 

◮ Sprungmarken 

◮ Bezeichner mit speziellem Namensbestandteil 

◮ generische Parameter, . . . 

• berechenbar: 

◮ Methodeneintritt/-austritt 

◮ Zugriffe auf eine Variable, . . .

Übersicht: Technische Umsetzung 

• Programmrepräsentation 

◮ Auf welchen Datenstrukturen transformieren wir? 

◮ Wie baut man diese auf? 

• Welche Spracheigenschaften sind vorteilhaft? 

• Grundlegenden Operationen 

• Metaprogramme 

• Steuerung von Metaprogrammen 


Einsatz klassischer Übersetzerbautechnik 

• Programmrepräsentationen: Text, Symbole, AST, Steuerflußgraph, 

Datenflußgraph, etc. 

• Programmanalyse zur Prüfung von Vorbedingungen (Anwendbarkeit von 

Transformationen) 

◮ attributierte Grammatiken 

◮ Typprüfungen 

◮ Datenflußanalyse 

◮ abstrakte Interpretation 

• Programmtransformation 

◮ globale Musterersetzung (Ersetzungssysteme) 

◮ lokale Musterersetzung 

◮ Elimination 


Programmrepräsentation Quelltext 


package example; 

/** this is a dummy class format **/ 

public class A extends Element { 

private int s = -1; 

} 

public void format(Stream s) { 

s.write("\n"); 

} 

• primäres Kommunikationsmittel mit dem Entwickler. 

• das Programm ist vollständig wiedergegeben. 

• wie unterscheiden wir zwischen Schlüsselwort, Kommentar, Zeichenreihe?

Programmrepräsentation Quelltext (2) 


#define MYCONFIG 

using System.IO; 

namespace example { 

// this is a dummy class format 

public class A : Element { 

#ifdef MYCONFIG 

private int s = -1; 

#else 

private double s = 3.1415; 

#endif 

public void format(TextWriter s) { 

s.WriteLine("",this.s); 

} 

} 

} // end namespace 

• Problem: Abhängigkeit vom Präprozessor

Programmrepräsentation Symbolfolge 


PACKAGE IDENTIFIER["example"] SEMICOLON COMMENT[...] PUBLIC 

CLASS IDENTIFIER["A"] EXTENDS IDENTIFIER["Element"] 

LBRACE PRIVATE INT IDENTIFIER["s"] ASSIGN MINUS 

INTLITERAL["-1"] SEMICOLON PUBLIC VOID IDENTIFIER["format"] 

LPAREN IDENTIFIER["Stream"] IDENTIFIER["s"] RPAREN LBRACE 

IDENTIFIER["s"] DOT IDENTIFIER["write"] LPAREN 

STRLITERAL["\n"] RPAREN SEMICOLON RBRACE RBRACE 

• Ergebnis der Symbolentschlüsselung 

• es ist klar, was was ist, aber wie ordnen wir die Symbole einander zu?

Programmrepräsentation Syntaxbaum 


• Ergebnis der syntaktischen Analyse (Zerteilung), in LISP explizit als 

Datenstruktur 

• die logische Struktur ist klar, aber was bedeuten die Namen? 

• immerhin: Programme sind Terme und Programmtransformationen sind 

Termersetzungen

Programmrepräsentation Strukturgraph: attributierter Baum 


• Ergebnis der Namensanalyse 

• wir kennen die kontextabhängigen Zuordnungen im Programm und 

können die Semantik unmittelbar ablesen 

• Namensanalyse ist für statisch formulierbare Aufgaben ausreichend! 

• Einsicht: Programme sind Graphen und Programmtransformationen sind 

Graphersetzungen.

Weitere mögliche Programmrepräsentationen 


• Maschinencode 

• Objektcode 

• Tupelfolge mit Maschinenbefehlen 

• SSA-Graphen 

• Datenflußgraphen 

• . . . 

SSA- und Datenflußgraphen sind für viele Programmanalysen vorteilhaft!

Die für Komposition ideale Programmiersprache hat. . . 


• keine Präprozessoranweisungen 

• strenge Typisierung und statische Typsicherheit. 

• keine Zeigerarithmetik. 

• keine ” 

beliebigen“ Sprünge. 

• keine Mechanismen der Kompositionsebene in der Sprache, wie Reflexion 

oder typeof. 

◮ Extremfall: Ein Programm, das über Reflexion seinen eigenen Quelltext 

ausgibt, zeigt nach jeder Transformation anderes Verhalten. 

• mögliche Folgerung: Trenne Basissprache und Kompositionssprache? Wie 

geht dann rekursive Komposition?

Syntax und Semantik von Transformationen 

• Alle Programmtransformationen ändern syntaktisch den Strukturbaum 

• Grundoperationen: 

◮ stutze(x, Vater(x)): beseitige Unterbaum x 

◮ propfe(y, Vater(y)): setze Unterbaum y ein 

◮ ersetze(x, y) = stutze(x, Vater(x)); pfropfe(y, Vater(x)) 

• stutze und pfropfe sind 

◮ ein vollständiges Grundsystem 

◮ atomar 

◮ invertierbar 

stutze = pfropfe −1 

• Syntaktische Transformationen garantieren keine Programmeigenschaften! 

• Solche Garantien sind Aufgabe der semantischen Steuerung der 

Transformationen. 


Metaprogramme 

• Ein Programm verarbeitet Daten. 

Ein Programm ist ein Datum. (→ Strukturgraph) 

• Ein Metaprogramm verarbeitet Programme. 

Ein Metaprogramm ist ein Programm. 

• Bekannte Beispiele 

◮ Übersetzer 

◮ Generatoren (z.B. IDL-basierte) 

◮ . . . 


Metaprogrammarten 


• Als Teil eines Übersetzers (z.B. Optimierer, Codegenerator) 

• Als Quell-zu-Quelltransformation (z.B. manche Präprozessoren, 

Softwareentwicklungswerkzeuge) 

• der Binder (einschl. Binden dynamischer Bibliotheken) 

• Zur Laufzeit ausgeführt (z.B. Lader) 

◮ Reflexion: Zugriff auf eine Programmrepräsentation zur Laufzeit 

◮ Selbstmodifizierende Programme sind schwer handhabbar

Speicherungsart von Objektattributen 


• Beispiel für die Umsetzung eines Aspekts 

• Je nach Zugriffshäufigkeit, -art und Belegung sind für logische 

Objektattribute (“Properties”) verschiedene Speicherungsarten sinnvoll. 

◮ lokal : als Feld des Objekts 

◮ global : in einer assoziativen Reihung 

• Aspektdefinition, um die Attributierung für eine Klasse festzulegen: 

Sichtbarkeit, Speicherungsart, Typ, Name, Vorgabebelegung. 

properties p.A { 

public local X x = null; 

public global Y y = Y.DEFAULT; 

}

Metaprogramme als Weber 


• Ein einfaches Metaprogramm webt den Aspekt in p.A ein: 

package p; 

public class A { 

/* ASPECT public local X x = null; */ 

private X x; 

public X getX() { return x; } 

public void setX(X x) { this.x = x; } 

{ setX(null); } // Object initializer 

} 

/* ASPECT public global Y y = Y.DEFAULT; */ 

private static Map ymap = new IdentityHashMap(); 

public Y getY() { return ymap.get(this); } 

public void setY(Y y) { ymap.put(this, y); } 

{ setY(Y.DEFAULT); } // Object initializer 

...

Das Metaprogramm näher betrachtet 

• Was muß das Metaprogramm tun? 

◮ Lokalisiere die Klassenvereinbarungen und die genannten Attribute. 

◮ Erzeuge den Code für die Attribute, entweder lokale Variable oder eine 

globale assoziative Reihung, mit Zugriffsmethoden und 

Initialisierungsblöcken. 

◮ Füge die erzeugten Vereinbarungen und Anweisungsblöcke in die 

Klassenvereinbarung ein. 

• Was ist dazu notwendig? 

◮ Namensanalyse (Ergebnisse im Strukturgraph enthalten) 


Aspect/J (http://aspectj.org) 

• Präprozessor für 

◮ Java-Quellen 

◮ Aspektdefinitionen (proprietär) 

• Weben: Code an Haken einfügen 

• Mögliche Haken 

◮ Methodeneintritt 

◮ Methodenausgänge 

◮ Methodenaufruf 

◮ Attributzugriff 

• Auffinden von Signaturen mit regulären Mustern 

• Bietet vorgefertigte Aspektsprachen zur Instrumentierung 


◮ Protokollierung 

◮ Profiling 

◮ Zusicherung von Verträgen 


Aspect/J: Beispiel 


class Point implements FigureElement { 

private int x = 0, y = 0; 

int getX() { return x; } 

int getY() { return y; } 

void setX(int x) { this.x = x; } 

void setY(int y) { this.y = y; } 

} 

void moveBy(int dx, int dy) { 

... 

} 

aspect DisplayUpdating { 

pointcut move(FigureElement figElt): 

target(figElt) && 

(call(void FigureElement.moveBy(int, int)) || 

call(void Line.setP1(Point)) || 

call(void Line.setP2(Point)) || 

call(void Point.setX(int)) || 

call(void Point.setY(int)) 

); 

} 

after(FigureElement fe) returning: move(fe) { 

Display.update(fe); 

}

Aspect/J AOP 

• Deklarativ, aber unklare Semantik: Steuerflußgraph als zugrundeliegendes 

Modell 

◮ Weben in imperativen Sprachen hat Nebenwirkungen 

◮ Ist operationale Beschreibung günstiger? 

• Die unterstützten Aspekte sind eher trivial. 

• Keine benutzerdefinierten 

◮ Navigationspfade 

◮ Analysen 

◮ Haken 

◮ Einmischoperationen 

• Kein Modell für Abhängigkeiten zwischen Aspekten 

◮ Wird erst synchronisiert oder erst protokolliert? 

◮ Wenn sich der funktionale Code ändert, 

welche Aspekte müssen angepaßt werden? 


RECODER (http://recoder.sf.net) 


• Rahmensystem für Metaprogramme in Java, für Java (demnächst auch für 

C, C#). 

• arbeitet auf quelltextnaher Programmrepräsentation 

◮ Strukturgraph enthält Querverweise 

(erfordert abgeschlossene Welt) 

◮ Detaillierte Strukturbäume erhalten Kommentare, Leerräume 

• Inkrementelle Aktualisierung nach Änderungen 

(effiziente Nachberechnung ist nächster Meilenstein) 

• Enthält Bibliothek von Transformationen und Analysen 

(noch unvollständig)

RECODER: Prinzipieller Ablauf 


RECODER: Programmodell 


RECODER: Dienstkonfigurationen 


RECODER: Dienstkopplung 


• Verwaltung von Modifikationen durch die Klasse ChangeHistory. 

• Aktualisierung des Programmodells nur bei Anfragen: Meldung an alle bei 

der ChangeHistory angemeldeten Dienste.

Recoder-Benutzung (1): Zerteilen einer Datei 


// Zuerst Dienstkonfiguration anlegen: 

ServiceConfiguration serviceConfig = new DefaultServiceConfiguration(); 

// Dateiverwaltungsdienst besorgen: 

SourceFileRepository sfr = serviceConfig.getSourceFileRepository(); 

try { // Datei zerteilen 

CompilationUnit cu = sfr.getCompilationUnitFromFile(filename); 

// filename ist vom Typ String 

} catch (ParserException pe) { 

// do something 

}

Recoder-Benutzung (2): Besuchen von Syntaxknoten 


• Tiefensuche im pull-Modus: 

// cu ist damit Wurzel des zu traversierenden Baumes 

TreeWalker walker = new TreeWalker(cu); 

while (walker.next()) { 

visit(walker.getProgramElement()); 

} 

• Die Methode visit ist nicht vordefiniert, sondern dient als Beispiel.

Recoder-Benutzung (3): Besuchen von Syntaxknoten 


• Tiefensuche im push-Modus: 

class TreeIteratorListener extends ASTIteratorAdapter { 

public void enteringNode(ASTIterator it, ProgramElement node) { 

// Auszuführende Aktionen beim ersten Besuch des Knotens node 

} 

} 

public void leavingNode(ASTIterator it, ProgramElement node) { 

// Auszuführende Aktionen beim letzten Besuch des Knotens node 

} 

TreeIteratorListener til = new TreeIteratorListener(); 

ASTIterator ai = new ASTIterator(til); 

ai.iterate(cu); // Start des Iterierens

Recoder-Benutzung (4): AST-Modifikation 


• Einfügen einer Typdeklaration d in eine Übersetzungseinheit cu: 

TypeDeclarationMutableList list = cu.getDeclarations(); 

if (list == null) { 

list = new TypeDeclarationArrayList(); 

cu.setDeclarations(list); 

} 

list.add(d); 

d.setParent(cu); // Doppelverkettung 

• Die Knoten des AST sind doppelt verkettet: Jeder AST-Knoten kennt 

seine Kinder und seinen Vater!

Recoder-Benutzung (5): Ausgabe 


• Ausgeben der Übersetzungseinheit cu 

ProgramFactory pf = serviceConfig.getProgramFactory(); 

PrettyPrinter pp = pf.getPrettyPrinter(new PrintWriter(System.out)); 

cu.accept(pp); 

oder kurz: 

System.out.println(cu.toSource());

Graphische Oberfläche 


Kontextinformation 

Strukturbaum 

Quelltext

Operationen der Metaprogrammierbibliothek 

• Auflistung in den Tabellen von Seite 0 bis 0. 

• Hier: Konkretisierung: 

• Füge Vereinbarung x in Kontext y ein 

◮ Teste, ob und welche Randbedingungen verletzt sind 

(mehr als ein Dutzend solcher Fälle sind möglich) 

◮ Suche geeignete Einfügeposition (gemäß Konventionen) 

◮ Setze Vereinbarung syntaktisch ein 

• Benenne Merkmal x um (z.B. zur Konfliktauflösung) 

• Verschiebe Vereinbarung x von Kontext y nach Kontext z 

◮ Es gibt in Java ca. 25 sinnvolle und logisch verschiedene 

Kombinationen für x, y und z. 

◮ Die Komplexität schwankt stark: Verschiebungen entlang der 

Vererbungshierarchie (gleiches Objekt!) sind einfacher als 

Querverschiebungen (verschiedene Objekte) 

• . . . 


Beispiel: Umbenennen der Methode B.f (1/4) 


• Welche Methodenvereinbarungen müssen umbenannt werden?



• Auswirkung auf andere Oberklassen



• Auswirkung auf Schwippschwager & Co.



• Wollen Sie das wirklich von Hand machen?

Steuerung von Metaprogrammen 


• eingebettet 

(Präprozessor interpretiert und entfernt Meta-Anweisungen) 

• interaktiv 

(Entwicklungswerkzeuge mit Assistenten) 

• skriptgesteuert 

(Metaprogrammiersprache) 

• automatisiert 

(Expertensystem)

Inject/J (http://injectj.fzi.de) 

• Operationale Skriptsprache zur invasiven Komposition. 

◮ Iteration über Elemente eines vereinfachten Strukturgraphen. 

◮ Steuert Analysen und Transformationen von RECODER. 

• Benutzerdefinierte 

◮ Navigationspfade 

◮ Haken 

• Keine benutzerdefinierten 

◮ Analysen 

◮ Einmischoperationen 


Inject/J: Operationen 


• Navigation: 

foreach class ´*´ do { 

foreach method ’*(*)’ do { 

foreach access ’methodName(*)’ 

to subclass ’SomeSuperClass’ do { 

} 

} 

} 

• Transformation: 

before$ $ 

• Kontrollstrukturen: 

if (introduceThrows) do { 

add to throws ${ ResourceAccessException }$; 

} 

• Benutzerinteraktion: 

ask("Please choose an name for a \ temporary variable", name);

Inject/J-Anwendungsbeispiel 


Einmischen von Kontrollanweisungen in alle Ausprägungen eines Kellers 

(java.util.Stack): 

aspect StackChecker { 

// Visit all classes in namespace 

foreach class ’*’ do { 

// Visit all Methods in this class 

foreach method ’*(*)’ do { 

// Visit all calls of method peek() on objects 

// of static type (or subtype) java.util.Stack 

foreach access ’peek()’ to subclass ’java.util.Stack’ do { 

//Insert the following code before each call to peek() 

before${ 

if (.empty()) 

System.out.println("Can’t peek stack, stack is empty."); 

}$; 

} 

// Visit all calls of method pop() ... analogously ... 

} } }

Inject/J: Oberfläche 


Weitere Anwendungen mit Inject/J und RECODER 

• Erzeugen von Entwurfsmustern 

◮ Erzeugen von Fabrikmethoden (abstrakte Fabrik) 

◮ Einmischen von Besuchsanweisungen (Besucher) 

◮ Einfügen von Beobachtungspunkten (Beobachter) 

• Refaktorisierungen und allgemeinere Transformationen 

◮ Attribute durch Zugriffsmethoden kapseln 

(Enterprise JavaBeans Architekturstil) 

◮ Methodensignaturen modifizieren 

(z.B. Parameter in ein Objekt bündeln) 

◮ Klassen ausfaktorisieren 

(Gemeinsamkeiten in Oberklassen auslagern) 

◮ Kommunikationsmechanismen austauschen 

(→ Konnektoren) 


Fortschritte 

• Invasive Komposition ist 

◮ sprachunabhängig 

◮ zur Aufarbeitung von Altsystemen geeignet 

◮ zur Produktion von Produktfamilien geeignet 

◮ die Basis zur Entwicklung abstrakterer und ausdrucksstärkerer 

Kompositionssprachen 

• Kompositoren bilden die Maschinensprache der Komposition 

• Erfolg durch Übertragung von Übersetzerbau-Techniken 

◮ Spezifikationstechniken (Graphersetzung, Termersetzung) 

◮ Analysetechniken 

◮ Generierungstechniken 


Sprachunabhängige Komposition 


Sprachunabhängige Komposition 

Generic AST (DOM) 

Analyzers 

Type description 

Transformators 

Type description 

Java AST 

C++ AST 


Fortschritte gegenüber... 

• objektorientierten Systemen 

◮ Kompositoren verallgemeinern 

Delegation 

Vererbung (spezielle Form der Delegation) 

Entwurfsmuster 

◮ Invasive Anpassung entfernt die Kompositionsschnittstellen 

◮ Erweiterungsmechanismen ermöglichen Sichtenkonzept 

• aspekt-orientiertem Programmieren 

◮ AOP wird mit invasiver Komposition implementiert 

◮ Verallgemeinerung von Navigation, Analysen, Webeprozeß 


Zusammenfassung und Ausblick 

• Konzepte: 

◮ AOP definiert die Problemlösung richtig 

◮ Kompositoren definieren das Zusammenfügen richtig 

◮ Elementare Programmtransformationen sorgen für syntaktisch korrekte 

Ersetzungen 

• Implementierung: 

◮ Recoder definiert Mechanismus 

◮ Inject/J definiert Taktik 

◮ Definition der Strategie??? 

→ Hier gibt es derzeit noch ein Loch! 


IPD-Literatur (1) 


• Dirk Heuzeroth, Thomas Holl, Gustav Högström, Welf Löwe, Automatic 

Design Pattern Detection, 11th Internatinal Workshop on Program 

Comprehension, co-located with 25th International Conference on 

Software Engineering, Portland, IEEE, May 2003. 

• Dirk Heuzeroth, Welf Löwe, Understanding Architecture Through 

Structure and Behavior Visualization, Chapter 9 in book: 

Software-Visualization - From Theory to Practice, Kluwer, 2003. 

• Stefan Schonger, Elke Pulvermüller, Stefan Sarstedt, Aspect-Oriented 

Programming and Component Weaving: Using XML Representations of 

Abstract Syntax Trees, Proceedings of the 2nd German GI Workshop on 

Aspect-Oriented Software Development (In: Technical Report No. 

IAI-TR-2002-1), University of Bonn, p. 59 – 64, Rheinische 

Friedrich-Wilhelms-Universität Bonn, Institut für Informatik III, February 

2002. 

• Dirk Heuzeroth, Thomas Holl, Welf Löwe, Combining Static and Dynamic 

Analyses to Detect Interaction Patterns, Proceedings of the Sixth 

International Conferenceon Integrated Design and Process Technology 

(IDPT), Jun 2002.



• Welf Löwe, Markus L. Noga, Component Communication and Data 

Adaptation, IDPT 2002, Jun 2002. 

• Andreas Speck, Elke Pulvermüller, Michael Jerger, Bogdan Franczyk, 

Component Composition Validation, International Journal of Applied 

Mathematics and Computer Science 12(4), p. 581 – 589, December 2002. 

• Elke Pulvermüller, Composition and Correctness, In: SC 2002: Workshop 

on Software Composition, Electronic Notes in Theoretical Computer 

Science (ENTCS), Elsevier Science Publishers, April 2002. 

• Markus L. Noga, Krüper, Content Management System Deployment - 

Merging Separate Concerns, LNCS 2487, GPCE 2002, Springer, Oct 

2002. 

• Markus L. Noga, Welf Löwe, Data Types and XML Schema, Journal of 

Markup Languages - Theory and Practice , Mar 2002. 

• Welf Löwe, Markus L. Noga, Thilo Gaul, Foundations of Fast 

Communication via XML, Annals of Software Engineering 13(1-4), p. 

357-379, Jan 2002. 

• Welf Löwe, Markus L. Noga, Metaprogramming Applied to Web 

Component Deployment, ENTCS 65(4), ETAPS SC 2002, Elsevier, Apr 

2002.



• Andreas Speck, Elke Pulvermüller, Matthias Clauß, Ragnhild Van Der 

Straeten, Ralf Reussner, Model-Based Software Reuse, Universität 

Karlsruhe, Fakultät für Informatik, Nr. 2002-4, 

http://www.info.uni-karlsruhe.de/˜pulvermu/workshops/ECOOP2002/, 

September 2002. 

• Welf Löwe, Markus L. Noga, Scenario-Based Connector Optimization - 

An XML Approach, LNCS 2370, IFIP/ACM CD 2002, p. 170-184, 

Springer, Jun 2002. 

• Pascal Costanza, Günter Kniesel, Katharina Mehner, Elke Pulvermüller, 

Andreas Speck, Second German Workshop on Aspect-Oriented Software 

Development, Rheinische Friedrich-Wilhelms-Universität Bonn, Nr. 

IAI-TR-2002-1, http://www.informatik.unibonn.de/III/forschung/publikationen/tr/#2002, 

February 

2002. 

• Andreas Speck, Silva Robak, Elke Pulvermüller, Matthias Clauß, 

Version-based Approach for Modelling Software Systems, Proceedings of 

the Workshop on Model-based Software Reuse, In Association with the 

16th European Conference on Object-Oriented Programming (ECOOP) 

2002, p. 15 - 22, Universität Karlsruhe, Fakultät für Informatik, June 

2002.



• Andreas Speck, Elke Pulvermüller, Matthias Clauß, Versioning in Software 

Modeling, Proceedings of the 6th International Conference on Integrated 

Design and Process Technology (IDPT 2002), Society for Design and 

Process Science (SDPS), June 2002. 

• Elke Pulvermüller, Andreas Speck, James O. Coplien, A Version Model for 

Aspect Dependency Management, Proceedings of the 3rd International 

Symposium on Generative and Component-Based Software Engineering 

(GCSE) 2001, Springer, Sep 2001. 

• Dirk Heuzeroth, Welf Löwe, Andreas Ludwig, Uwe Assmann, 

Aspect-Oriented Configuration and Adaptation of Component 

Communication, Jan Bosch (Ed.), Generative and Component-Based 

Software-Engineering, Third International Conference, GCSE 2001, 

Springer, Sep 2001. 

• Katharina Mehner, Mira Mezini, Elke Pulvermüller, Andreas Speck, 

Aspektorientierung - Workshop der GI-Fachgruppe 2.1.9 Objektorientierte 

Software-Entwicklung, Nr. tr-ri-01-223, May 2001. 

• Trent Jaeger, Dirk Heuzeroth, Uwe Assmann, Automating the 

Management of Reusable System Components, Proceedings of the 7th 

HotOS-Workshop, Jan 2001. 

• Dirk Heuzeroth, Thomas Holl, Welf Löwe, Combining Static and Dynamic 

Analyses to Detect Interaction Patterns, Dec 2001.



• Elke Pulvermüller, Andreas Speck, Maja D’Hondt, Wolfgang DeMeuter, 

James O. Coplien, Feature Interaction in Composed Systems, ECOOP 

2001 - Proceedings, TR No. 2001-14, Nr. 2001-14, Sep 2001. 

• Andreas Speck, Elke Pulvermüller, Feature Modeling, Wolfgang Goerigk 

(Ed.), Proceedings of the Joint Workshop of the GI-Fachgruppe 2.1.4 

(Programmiersprachen und Rechenkonzepte) and 2.1.9 

(Objekt-Orientierte Softwareentwicklung), Christian-Albrechts-Universität 

zu Kiel, May 2001. 

• Welf Löwe, Andreas Ludwig, Andreas Schwind, Understanding Software - 

Static and Dynamic Aspects, 17th International Conference on Advanced 

Science and Technology, 2001. 

• Andreas Speck, Elke Pulvermüller, Versioning in Software Engineering, 

Proceedings of 27th Annual Conference of the IEEE Industrial Electronics 

Society (IECON´01), Denver, CO, IEEE Press, Dec 2001. 

• Welf Löwe, Alexander Liebrich, VizzScheduler - A Framework for the 

Visualization of Scheduling Algorithms, Proc. of the Euro-Par 2001, 

Springer, Aug 2001. 

• Awais Rashid, Peter Sawyer, Elke Pulvermüller, A Flexible Approach for 

Instance Adaptation during Class Versioning, Proceedings of the 

Symposium on Objects and Databases (OODB 2000), Co-hosted with 

ECOOP 2000, Jun 2000.


• Herbert Klaeren, Elke Pulvermüller, Awais Rashid, Andreas Speck, Aspect 

Composition applying the Design by Contract Principle, Proceedings of 

the GCSE 2000, Second International Symposium on Generative and 

Component-Based Software Engineering, 2000, Oct 2000. 

• Andreas Speck, Elke Pulvermüller, Component Frameworks for Software 

Generators, Proceedings of the 17th Workshop of the GI-FachgSpruppe 

2.1.4, Programmiersprachen und Rechnerkonzepte, May 2000. 

• Elke Pulvermüller, Andreas Speck, Awais Rashid, Implementing 

collaboration-based Designs using Aspect-Oriented Programming, 

Proceedings of TOOLS-USA, 2000 (Technology of Object-Oriented 

Languages and Systems), p. 95 - 104, IEEE Computer Society Press, Jul 

2000. 

• Andreas Ludwig, Dirk Heuzeroth, Metaprogramming in the Large, 2nd 

International Conference on Generative and Component-based Software 

Engineering (GCSE). Also available as LNCS 2177 (c) by Springer, 

Springer, Jan 2000. 

• Andreas Speck, Elke Pulvermüller, Mira Mezini, Reusability of Concerns, 

Proceedings of the Workshop on Aspects and Dimensions of Concerns, 

2000, in conjunction with ECOOP 2000, Jun 2000. 

• Dirk Heuzeroth, Ralf Reussner, A Meta-protocol and Type System for the 

Dynamic Coupling of Binary Components, OORASE’99 - 

OOSPLA’99Workshop on Reflection and Software Engineering 

(Proceedings) by the University of Milano - Bicocca, Italy, Nov 1999. 




• Uwe Assmann, Aspect Weaving by Graph Rewriting, Generative 

Component-based Software Engineering(GCSE), p. 24-36, Oct 1999. 

• Elke Pulvermüller, Herbert Klaeren, Andreas Speck, Aspects in 

Distributed Environments, Proceedings of the GCSE 1999, Sep 1999. 

• Uwe Assmann, Andreas Ludwig, Introducing Connections into Classes 

with Static Metaprogramming, Coordination 1999, Springer, Apr 1999. 

• Publikationen unserer FZI-Gruppe: 

http://www.fzi.de/prost/publikationen.php

als eine PDF-Datei (schwarz-weiÃ) - IPD Goos

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?

als eine PDF-Datei (schwarz-weiÃ) - IPD Goos