PDF in Farbe - 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 2004 

c○ Gerhard Goos, Dirk Heuzeroth, 

Elke Pulvermüller, Volker Kuttruff 

2004 

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

Organisation 

• Vorlesung: 

◮ 1. Dienstag 14:00 – 15:30, -101, wöchentlich 

◮ 2. Mittwoch 14:00 – 15:30, -101, vierzehntägig 

• Übungen: 

◮ Mittwoch 14:00 – 15:30, -101, vierzehntägig, erstmals 28.04.2004 

• Übungsleiter: Dr. Dirk Heuzeroth, Mamdouh Abu-Sakran, Volker Kuttruff 

• Adressen: 

◮ Allgemeines Verfügungsgebäude, 2. OG 

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

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

kuttruff@fzi.de 

• Sprechstunden: 

◮ Goos: Dienstags 16:00 – 17:00 

◮ Heuzeroth, Abu-Sakran, Kuttruff: Mittwochs 16:00 – 17:00 

• Vorlesungsseite: 

http://www.info.uni-karlsruhe.de/lehre/2004SS/swk 

Prof. Dr. G. Goos Software aus Komponenten 2

Gliederung 

1. Einführung 

◮ Überblick über Ziele, Probleme und Aufgaben 

◮ Komponentenbegriffe 

◮ Vorgehensweisen 

◮ Überblick über klassische Ansätze, kommerzielle Lösungen und 

akademische Ansätze) 

◮ Probleme und generelle Lösungen 

2. Industrielle Komponentensysteme 

1. CORBA 

2. (Enterprise) JavaBeans 

3. (D)COM, .Net 

4. Webdienste, XML 

3. Akademische Ansätze 

◮ Architektursysteme 

◮ Aspektorientiertes Programmieren 

◮ Metaprogrammierung und Invasive Komposition 



2. Konkrete industrielle Systeme 

• Pragmatisch motiviert 

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

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

• Man braucht Mechanismen zur Transparenz von 

◮ Sprachen (IDL) 

◮ Plattformen 

◮ Betriebssystemen 

◮ Ausführungsort: 

Global eindeutige Referenz 

Stellvertreterobjekte (stub/skeleton) 

Wiederverwendbare Dienste zum Ermitteln von Komponenten und 

deren Eigenschaften (z.B. für dynamische Komposition): 

· Namensdienst 

· Makler 

· Persistenz (Objekte aus Datenbank holen) 

· Reflexion (Schnittstellen erfragen) 

Objektverwaltung (Lebenszyklus) 

• Jetzt: Ausprägung in 

◮ Corba (Mustergültig) 

◮ Java / JavaBeans / EnterpriseJavaBeans (Sprachgebunden) 

◮ COM/DCOM/.NET (Plattformgebunden) 

◮ Webdienste/XML

DCOM: Entwicklung 

• Entwickler: Microsoft 

• OLE (object linking and embedding) 

◮ ActiveX (OLE-Erweiterung) 

• COM (component object model) 

◮ Einführung 1993 als Teil von OLE 2.0 SDK 

◮ definiert COM Component Object Model und Laufzeitunterstützung in 

der Component Object Library 

◮ rein lokale Komponenteninteraktion 

• DCOM (distributed COM) 

◮ Einführung 1996 integriert in Windows NT 4.0 

◮ verteilte, rechnerübergreifende Kommunikation 

Grenzen fließend! 


COM 

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

• 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 

Dr. Welf Löwe und Markus Noga 7

Grundideen des Komponentenmodells von (D)COM 

• Komponente implementiert Menge von Schnittstellen 

◮ Verwirrend: COM Object = Komponente, nicht Instanz! 

◮ Referenz auf Instanz einer Komponente ist stets Referenz auf Instanz 

einer Schnittstelle 

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



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! 


Komponentenmodell: 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. 


Komponentenmodell: Delegation und Aggregation (1) 






• Wiederverwendung durch Delegation oder Aggregation als Ersatz für 

Implementierungsvererbung. 

• IUnknown des äusseren Objekts kontrolliert den Lebenszyklus der inneren 

Objekte 

• Aggregation stellt ein oder mehrere Schnittstellen der inneren Objekte als 

seine eigenen direkt nach aussen aus 

• Bei Aggregation delegiert das innere Objekt Aufrufe auf IUnknown zum 

äusseren Objekt


Komponente 

Sprachtransparenz: 

kann mehreren 

binärer 

Schnittstellen 

Aufrufstandard 

genügen 

Komponentenreferenz ist immer Referenz auf eine 

Schnittstelle 

IUnknown 

Client 

COM 

Object 

• Wie in C++ 

• Aufruf der Funktionen über vtables 

Dr. Welf Löwe und Markus Noga 13 

• Möglich in Sprachen, die Funktionen über Zeiger aufrufen können (C, 

C++, SmallTalk, Ada, Basic, . . . ) 

• Layout der vtables definiert durch MS-C-Übersetzer 

• Plattformabhängigkeit 

• zusätzliche Indirektion

Orts- und Entwicklungszeittransparenz: GUIDs und Versionen 


• 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 

• 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 

• “So, in a sense, COM solves the versioning problem by not supporting it” 

(Orfali)

GUIDs: Vorteile und Nachteile 

• Vorteile 

◮ Sprachtransparenz 

◮ Keine Namenskollisionen 

◮ Keine fragile base classes 

◮ Verwenden der neuesten Implementierung einfach 

• Nachteile 

◮ Viele Schnittstellen mit ähnlichen Namen und ähnlicher Funktionalität 

◮ 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 


Ortstransparenz: Dienstsuche mit Interface IUnknown (1) 

• COM definiert die spezielle Schnittstelle IUnknown 

• Jede COM Schnittstelle erbt IUnknown 

• Jede COM Komponente muß das IUnknown Interface implementieren 

• Funktionalität 

◮ Schnittstellen einer Instanz abfragen 

◮ Referenzzählen für eine Instanz (Objekt Lebenszyklus) 

interface IUnknown { 

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

virtual ULONG AddRef() = 0; 

virtual ULONG Release() = 0; 

} 



Ortstransparenz: Beispiel für Schnittstelle und IUnknown (2) 

Beispiel 

IUnknown 

ILookup 

COM 

Object 

interface ILookup : public IUnknown 

{ 

interface ILookup : public IUnknown 

public: { 

public: 

virtual HRESULT _stdcall 

virtual 

LookupByName 

HRESULT __stdcall LookupByName 

(LPTSTR lpName, TCHAR (LPTSTR **lplpNumber) lpName,TCHAR = 0; **lplpNumber) = 0; 

virtual HRESULT _stdcall LookupByNumber 

virtual HRESULT __stdcall LookupByNumber 

(LPTSTR lpNumber, TCHAR **lplpName) = 0; 

(LPTSTR lpNumber, TCHAR **lplpName) = 0; 

}; 

}; 

• Definition in MIDL 

• Interface Ermittlung zur Laufzeit 


Ortstransparenz: IUnknown / QueryInterface (3) 


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

}

tstransparenz: IUnknown / QueryInterface: Interpretation (4) 

• 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 


Ortstransparenz: Die COM Bibliothek 


• Implementiert Standard-Funktionen für Kommunikation 

• Selbst eine (System-)Komponente 

◮ Laufzeitunterstützung von COM 

◮ Dynamische Bibliotheken 

◮ COMPOBJ.DLL, OLE32.DLL 

• Verantwortlich für 

◮ Erzeugung von Instanzen 

◮ Herstellen und Koordinieren von Verbindungen

Ortstransparenz: Registratur (registry) 

• 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 die Registratur (registry ) 

◮ findet Klassen und ihren Code in der Registratur 

◮ aktiviert Fabrik in einem Prozeß 

◮ erzeugt Objekte aktiver Fabriken 


Ortstransparenz: Registratur 


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) 

• Drei Möglichkeiten: in-process, cross-process, remote 


Ortstransparenz: Server Lokalisation 


Reihenfolge der Suche 

Client 

1 

3 

SCM 

COM Cache 

... 

2 

4 

5 

Registry 

InprocServer 

LocalService 

LocalServer 


Ortstransparenz: Zugriff auf eine Komponente 


C l ie n t 

C l ie n t 

A p p l ic a tio n 

(1 ) 

A n f rage 

(A rg u m e n t: C L S ID 

d e r C o m p o n e n t 

O b ject C lass) 

(5 ) A u f ru f d e r M e th o d e n 

d e r S c h n itts te l le 

O b je k t 

S c h n itts te l le 

(4 ) 

R e fe re n z a u f 

O b je k tschnitts te l le 

z u rü c k a n K l ie n te n 

C O M 

C o m p o n e n t 

O b ject L ib ra ry 

R egis t ry 

S e rver 

O b ject 

(2 ) N achschlagen in 

d e r R eg is t ra tu r (a l le 

regis t r ie r te n S e rver ) 

(3 ) F in d e (O b je k t) 

Im p le m e n tie ru n g , 

L a d e S e rver C o d e 

C L S ID 

S e rv e r 

C o d e 

• Alternativen: direkter Objektzugriff mit vorhandener Referenz auf 

Objektschnittstelle, Erzeugen eines Objekts mit einer Fabrik, die nicht für 

den Klienten sichtbar ist (CoCreateInstance), Erzeugen eines Objekts über 

eine Fabrik direkt durch den Klienten (CoGetClassObject + CreateInstance)

Objektdienste: Referenzzähler und Objektlebenszyklus 


• Schnittstelle IUnknown enthält zwei weitere wichtige Methoden 

◮ 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

Objektdienste: Objektlebenszyklus und Fabrik 

• COM Interface IClassFactory 

• Allgemeine Fabrik für Komponenteninstanzen 

• Eine Instanz der Fabrik pro Rechner 

◮ CreateInstance: Neue Komponenteninstanz erzeugen 

◮ LockServer: Schnellere Erzeugung (nicht-funktional) 

• Problem: CreateInstance liefert IUnknown 

• Daher nicht statisch typsicher 


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 

• Verbindungsmanagement 

• Management für Nebenläufigkeit 

• Management für Sicherheit 

• Alles bereits im Design von COM vorbereitet

Ortstransparenz (in DCOM erweitert) 

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

Ortstransparenz: 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 


Ortstransparenz: DCE (Exkurs) 


• 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

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 


Ortstransparenz: Interface Definition 


• Microsoft Interface Definition Language (MIDL) 

• Erweiterung von DCE IDL 

• Erzeugung von nutzerdefinierten Schnittstellen 

• Nicht neu, aber anders!

Transparenz 

Ortstransparenz 


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 

• Ansprechen der entfernten Objekte per OBJREF oder per Stellvertreter 

Dr. Welf Löwe und Markus Noga 42 

• Statischer Aufruf, falls Stellvertreter und Objekt identisch sind 

• Entferntes, dynamisch aufgerufenes Objekt muß die Schnittstelle 

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

implementieren (keine Unterstützung durch Broker)

Ortstransparenz: 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 


Objektdienste 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 


Anpassungen 

• Konzepte zur Anpassung 

◮ Explizites Adaptieren und Delegieren 

◮ IDL Generatoren erzeugen Code für Sprach- und 

Verteilungsanpassungen 

◮ siehe Konzepte zur Komposition 

• 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 


DCOM Zusammenfassung (1) 

• Generische Komponenten: 

◮ Schnittstellenklassen und Stellvertreter werden aus MIDL generiert 

◮ Kein ähnliches Konzept für Implementierungen 

• Abstrakte Komponenten und Schnittstellen: 

◮ Schnittstellen werden aus MIDL generiert 

◮ Schnittstellenobjekte 

◮ Mehrfachvererbung 

◮ Unveränderliche Schnittstellen (immer und überall) 

• Konkrete Komponenten: 

◮ Mit Transaktionskonzept / Persistenzkonzept 

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

Plattformunabhängig (aber de facto Windows) 

◮ Vererbungskonzept der jeweiligen Sprache 

• Zusammengesetzte Komponenten: 

◮ Aufruf über (D)COM Bibliothek und Stellvertreter 

◮ Delegation in Komponenten über Umwickler 

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

◮ Aggregation von Schnittstellen 


DCOM Zusammenfassung (2) 

• Basiskommunikation: 

◮ Erzeugung (Fabrik) über lokale Bibliotheksdienste 

◮ Objekterzeugung ist Fabrikmethodenaufruf 

◮ Objektorientierter Fernaufruf basierend auf DCE über Stellvertreter 

(proxies) 

◮ Dezentrale Vermittlung 

• Wiederverwendung: 

◮ Keine Standardisierungen von DCOM Objekten (Klassen) 

◮ Industriestandard: Microsoft Anwendungen stark 

• Generierung aus Spezifikationen: 

◮ Schnittstellen-Stellvertreter Generierung aus MIDL 


Bewertung (1) 

• Standardisierung: 

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

◮ Weitere Verbreitung als Corba 

◮ Vorwiegend Verdrahtungsstandard 

◮ Kein offener, sondern ein proprietärer Standard 

Keine standardisierten Dienste 

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

• Sprach- und Plattformtransparenz: Jein 

◮ Windows als Plattform vorausgesetzt (auch wenn EntireX von Software 

AG auf Linux existiert) 

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


Bewertung (2) 

• 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 

• “Versionierung” führt zur Explosion ähnlich benannter Schnittstellen (z.B. 

IClassFactory und IClassFactory2) 

• Ortstransparenz: Ja 

◮ Dezentrale Kommunikationsvermittlung über Stellvertreter 

◮ Aber: Keine uniforme Implementierung lokaler (DLL) und entfernter 

(EXE) Komponenten 


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, 

◮ von DCOM nach .NET 

◮ Nebeneinander der Ansätze möglich. 

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

.NET: Ziele 

• Ziele: 

◮ Sprachtransparenz, 

aber Fokus auf C# 

◮ Plattformabhängigkeit, 

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

◮ Ortstransparenz: Remoting, Web-Dienste 

◮ Reflexion 

◮ Versionierung 

◮ Dynamisches Laden: Es gibt genau einen Klassenlader 


.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

Plattformunabhängigkeit“: CLR 

” 


CLR (Common Language Runtime) 

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

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

Zwischencodes CIL verarbeitet. 

• CIL-Code wird nicht interpretiert, sondern immer in die Maschinensprache 

der Zielmaschine übersetzt

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 vorgeschriebene 

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 

⇒ Ortstransparenz: 

◮ keine IDL mehr 

(Schnittstellenbeschreibung durch Metadaten, Abfrage durch Reflexion) 

◮ 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", 2004); 

} 

} 

}

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 



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

} 

} 

} 

} 

}

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

.NET Zusammenfassung (1) 

• Generische Komponenten: 

◮ Metadaten pro Päckchen, ersetzt IDL 

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

Stellvertretern aus Implementierung 

• Abstrakte Komponenten und Schnittstellen: 

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

• Konkrete Komponenten: 

◮ Mit Transaktionskonzept / Persistenzkonzept 

◮ ” 

Plattformunabhängig“ 

◮ Einfachvererbung, Mehrfachvererbung von Schnittstellen 

• Zusammengesetzte Komponenten: 

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

Schachtelung von Päckchen 

◮ Delegation 


.NET Zusammenfassung (2) 

• Basiskommunikation: 

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

◮ Webdienste 

• Wiederverwendung: 

◮ Umfangreiche Bibliothek 

◮ Vordefinierte Dienste (schwach, Datenschutz?) 

◮ Webdienste (aufkommend) 

• Generierung aus Spezifikationen: 

◮ Generierung von Spezifikationen aus Implementierungen (Webdienste) 

◮ Generierung der Stellvertreter aus generierten Spezifikationen 


.NET Bewertung (1) 


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

Welt 

• politische Bewertung: 

+ ECMA-Standard 

◦ deutliche Ausrichtung auf Web-Dienste 

− Monopolisierungsabsicht. 

− Mittelfristig oder langfristig Plattformabhängigkeit 

− praktische Tauglichkeit noch nicht nachgewiesen 

− manche Eigenschaften noch nicht ausreichend klar: 

Mehrfachvererbung, mehrfädige Programmierung



• technisch: 

+ im Vergleich zu CORBA und EJB der bisher systematischste Ansatz 

zur Vereinheitlichung 

+ 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 

+ Umfangreiche Bibliothek 

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

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

◦ Kellercode nicht ausführbar 

− Verifizierer nicht validiert und außerdem abschaltbar 

− Keine Anpassungskonzepte.


• Sprachtransparenz 

◮ Ja (CTS, aber Fokus auf C#) 

• Plattformtransparenz 

◮ Ja (durch CLR/CIL und automatische Übersetzung in 

Maschinensprache der Zielplattform) 

• Ortstransparenz 

◮ Ja (durch Remoting-Rahmensystem sowie auch die Ausrichtung auf 

Web-Dienste) 

• Reflexion 

◮ Dynamisch und statisch 

• Dienste 

◮ Transaktionen, Datenbanken, . . .

PDF in Farbe - IPD Goos

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?