3 Folien/Seite

6
Implementierung komplexer Systeme
6.1
Verteilte objektorientierte Systeme
Analyse
Entwurf
Implementierung
Test,
Integration
Wartung
.KVGTCVWT
$CN\GTV$CPF.'
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Offene verteilte Systeme
• Situation: Heterogene, vernetzte Computersysteme:
– heterogene Hardware, Betriebssysteme, Programmiersprachen,
Formate, Netztechnologien
– Anwendungen im Normalfall verteilt
» Client/Server-Architekturen
• Ziele:
– Portabilität (Objektcode, Quellcode, Entwurf)
– Interoperabilität
– Lokations- und Netzwerk-Transparenz
• Hilfsmittel:
– Standards für “offene Systeme”
– Eindeutige Definition von Schnittstellen
– Flexible Erweiterung um neue Schnittstellen
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Realisierung von Client/Server-Systemen
• Sockets ("Peer-to-Peer"-Kommunikation über den TCP/IP Stack)
– Niedriges Abstraktionsniveau
– Plattform-Transparenz (z.B. Java Package java.net )
• Remote Procedure Call (RPC)
– Höheres Abstraktionsniveau als Sockets (Prozedurebene)
– Einbettung in prozedurale Programmiersprachen (z.B. C)
– Realisierung von synchronen entfernten Prozeduraufrufen
• Java Remote Methode Invocation (RMI)
– Hohes Abstraktionsniveau (Objektebene)
– Java-spezifischer Mechanismus (Java Package java.rmi)
– Ort- und Plattform-Transparenz
• "Middleware" für verteilte Objekte (CORBA, Microsoft DCOM)
– Hohes Abstraktionsniveau (Objektebene)
– Transparenz von Ort und Programmiersprache
– Bei CORBA: auch Plattform-Transparenz
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 1
Standards der Object Management Group
• Object Management Group (OMG):
– Zusammenschluß von Anbietern und Anwendern objektorientierter
Softwaretechnologie
– Gegründet 1989, mehr als 600 Mitglieder
– Standards und Spezifikationen, aber
mit Verpflichtung zur kommerziellen Implementierung
– “Middleware” für verteilte objektorientierte Anwendungen (CORBA)
– Interoperabilität verschiedenener CORBA-Implementierungen
ist Realität
• De-facto-Standards
– “Offizielle” Standardisierungsgremien, z.B. ISO:
» vergleichsweise schwerfällig
– Firmen-“Standards”, z.B. Microsoft OLE/DCOM:
» nicht wirklich “offen”, d.h. plattformunabhängig
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Object Management Architecture (OMA)
Finanzen
Finanzen
Telekommunikation
Telekommunikation
Electronic
ElectronicCommerce
Commerce
......
Vertikale
CORBAfacilities
Nicht standardisiert:
Anwendungsspezifische
Objekte
Objekte der
Anwendung
Nutzerschnittstelle
Nutzerschnittstelle
Informationsmanagement
Informationsmanagement
Systemmanagement
Systemmanagement
......
Horizontale
CORBAfacilities
Object Request Broker (ORB) - Objektbus
Lifecycle
Lifecycle
Event
Event
Naming
Naming
Persistence
Persistence
Transactions
Transactions......
Technische Universität Dresden
Objektdienste
(CORBAservices)
Prof. Hußmann
Externalization
Externalization
Security
Security
Time
Time
Properties
Properties
Licensing
Licensing......
Softwaretechnologie II
Dienstanforderungen (object requests)
• Client-Objekte senden Anforderungen (requests) an abstrakte
Referenzen, über die sie an Objektimplementierungen (servants)
zugestellt werden.
• Bestandteile einer Anforderung:
– Angabe des angesprochenen Server-Objekts (Objekt-Referenz)
– Name der angeforderten Operation
– Kommunikationsart
» synchron, asynchron oder abgesetzt synchron
– Ein- und Ausgabeparameter
– (optional) Ausnahmebedingungen
– (optional) Kontextangaben (z.B. Ort des Clients)
• Schnittstellen:
– Beschreibung von Anforderungstypen
– Zusammenfassung in Schnittstellen
– Interface Definition Language (IDL)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 2
Statischer Aufruf: Stubs und Skeletons
• stub und skeleton vermitteln zwischen der universellen IDL und der
konkreten Programmiersprache.
• stub: wird vom Client-Code aufgerufen
• skeleton: ruft den Servant-Code auf
Objekt in
"Client"-Rolle
Objekt in
"Servant"-Rolle
stub
skeleton
"Suggestion"
einer einheitlichen
Schnittstelle
über IDL
Object Request Broker (ORB)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Generierung von Stubs und Skeletons
SchnittstellenDefinition in IDL
(statisch)
Servant-Code
IDL-Compiler
Client-Code
IDL stub (Code)
IDL skeleton (Code)
Übersetzen und Binden
Übersetzen und Binden
Client
Servant
stub
skeleton
ORB
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Proxy-Entwurfsmuster in CORBA
Proxy
Original
ClientObjekt
ServantObjekt
Original
Proxy
Proxy
Stub
Skeleton
Proxy
Object Request Broker (ORB)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 3
ORB-Architektur in CORBA
ServantObjekt
ClientObjekt
dynamisch
statisch
IDL Stub
(statisch)
DII
IDL Skeleton DSI
(statisch)
ORB
interface
object adapter
Object request Broker (ORB) core
Interface Repository
Implementation Repository
Stubs £ Static Invocation Interface (=SII)
DII = Dynamic Invocation Interface
Skeletons £ Static Skeleton Interface (=SSI) DSI = Dynamic Skeleton Interface
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Objekt-Adapter
• Aufgaben eines Objektadapters:
– Zustellung von Requests an registrierte Objekte
– Erzeugung von Objekten und Referenzen
– Aktivierung/Deaktivierung von Objekten
• Beispiele:
– Basic Object Adapter (BOA)
» bis CORBA 2.1
» proprietäre Realisierungen
– Portable Object Adapter (POA)
» ab CORBA 2.2
– andere, z.B. Adapter für DBMS
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Statische und Dynamische Schnittstellen
• Statische Aufrufschnittstelle (Static Invocation Interface, SII)
– Festlegung der Operation (und Typinformation) zur Übersetzungszeit
(aber dynamische Bindung an Objektinstanzen)
– Generierung von stubs
• Dynamische Aufrufschnittstelle(Dynamic Invocation Interface, DII):
– Festlegung der Operation und Typinformation zur Laufzeit
– Flexibler in der Kommunikationsart (auch "abgesetzt synchron")
• Statische Skeleton-Schnittstelle (Static Skeleton Interface, SSI)
– Festlegung der Operation (und Typinformation) zur Übersetzungszeit
– Generierung von skeletons
• Dynamische Skeleton-Schnittstelle (Dynamic Skeleton Interface,
DSI)
– Bereitstellung eines flexiblen Skeletons
– Analyse von Operation, Parametern, Typinformation zur Laufzeit
• Unabhängige Wahl: SII/DII (Client), SSI/DSI (Servant)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 4
Schnittstellen-Spezifikation mit IDL
• Interface Definition Language (IDL):
– Spezifikation von Schnittstellen für CORBA
– Orientiert an C++, aber sprachunabhängig
– Streng getypt (sprachunabhängig)
• Grundeinheit: interface
– ähnlich class (umfaßt öffentliche Attribute und Operationen)
– Vererbung
– Module zur Gruppierung von Interfaces
• Syntax von Operationen:
– Name, Typ und Art (in, out, inout) für alle Parameter
– Ergebnistyp
– Kommunikationsart (oneway)
– Ausnahmesituationen (raises exception)
– Kontextangaben
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
IDL: Datentypen
• Einfache Datentypen
• Strukturierte Datentypen
– Ganzzahltypen
» short , long, long long
» signed und unsigned
– Gleitpunkttypen
» float , double,
long double, fixed
– char, wchar, boolean, octet
– Any
–
–
–
–
–
–
Verbunde (struct)
Vereinigung
Aufzählung
Sequenzen
Strings
Felder
– CORBA Objektreferenz
– Value-Typ (Objekte als Werte)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
IDL: Beispiel
module BeispielModul {
struct Adresse {
string strasse;
string plz;
string ort;};
interface Person {
attribute string name;
readonly attribute string vorname;
readonly attribute long geburtsjahr;
attribute Adresse anschrift;
typedef sequence <Person> PersonListe;
attribute PersonListe Bekannte;
long berechneLebensjahre (in long aktJahr);
void berechneLebensjahreP
(in long aktJahr, out long lebensJahre);
}; // Interface
}; // Modul
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 5
IDL-Sprachbindungen
• Standardisierte Sprachbindungen
– Abbildung der IDL-Konstrukte auf spezifische Konstrukte der
Programmiersprache
– IDL-Sprachbindungen existieren u.a. für:
» C, C++, Smalltalk, Ada, COBOL, Java
• IDL Compiler:
– IDL Compiler generiert automatisch Stubs und Skeletons
– Optional: Generierung von "Templates"
(Vorlagen für die Objektimplementierung)
– Übertragung von Schnittstellen in das Interface Repository
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Abbildung IDL-Programmiersprache
• Abbildung von Schnittstellen und Operationen
– C:
» Keine direkte Abbildung von Schnittstellen
(Schnittstellenname wird in Funktionsname übernommen, Parameter vom
Schnittstellentyp ist erster Parameter der Funktionen einer Schnittstelle)
» Operationen werden Funktionen
– C++:
» Module werden auf C++ Namespaces abgebildet
» Schnittstellen auf Klassen
» Operationen auf Methoden
– Java:
» Module werden auf Java Packages abgebildet
» Schnittstellen auf öffentliche Java Schnittstellen sowie Helperund Holder Klassen in Java
» Operationen auf Methoden
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Java-Bindung: Beispiel
// Person.java
package BeispielModul;
public interface Person extends org.omg.CORBA.Object
{
public void name(java.lang.String name);
public java.lang.String name();
public java.lang.String vorname();
public int geburtsjahr();
public void anschrift
(BeispielModul.Adresse anschrift);
public BeispielModul.Adresse anschrift();
public void Bekannte
(BeispielModul.Person[] Bekannte);
public BeispielModul.Person[] Bekannte();
public int berechneLebensjahre(int aktJahr);
public void berechneLebensjahreP
(int aktJahr,
org.omg.CORBA.IntHolder lebensJahre);
}
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 6
Zähler-Beispiel: IDL-Schnittstelle
// Counter.idl
interface Counter {
void count ();
void countn (in long n);
long getcount();
void getcountp(out long count);
};
// CounterFactory.idl
#include "Counter.idl"
interface CounterFactory {
Counter createCounter();
};
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Zähler-Beispiel: Stubs/Skeletons erzeugen
Kommandos:
idl2java Counter.idl
idl2java CounterFactory.idl
Erzeugte Dateien (u.a.):
<IDL-Schnittstelle>.java
Java-Interface
<IDL-Schnittstelle>Helper.java
Nützliche Hilfsoperationen
<IDL-Schnittstelle>Holder.java
Hilfsklasse für Parameter
_st_<IDL-Schnittstelle>.java
_<IDL-Schnittstelle>ImplBase.java
Stub-Code
Skeleton-Code
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Zähler: Java-Schnittstelle und "Helper"
// Counter.java
public interface Counter extends org.omg.CORBA.Object
{
public void count();
public void countn( int n );
public int getcount();
public void getcountp( org.omg.CORBA.IntHolder count
);
}
// CounterHelper.java
abstract public class CounterHelper {
public static Counter narrow
(org.omg.CORBA.Object object)
{// ...}
public static Counter bind
(org.omg.CORBA.ORB orb, java.lang.String name)
{ // ... }
// weitere Methoden
}
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 7
Zähler: "Holder"-Klasse
// CounterHolder
final public class CounterHolder implements
org.omg.CORBA.portable.Streamable {
public Counter value;
public CounterHolder() { };
public CounterHolder(Counter value)
{ this.value = value; }
public void _read
(org.omg.CORBA.portable.InputStream input)
{ value = CounterHelper.read(input); }
public void _write
(org.omg.CORBA.portable.OutputStream output)
{ CounterHelper.write(output, value);}
public org.omg.CORBA.TypeCode _type()
{ return CounterHelper.type(); }
}
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Zähler-Beispiel: Stub und Skeleton
// _st_Counter.java
public class _st_Counter extends
org.omg.CORBA.portable.ObjectImpl implements Counter {
// ...
// Stub-Implementierung
public void count() {// ...}
// ...
}
// _CounterImplBase.java
abstract public class _CounterImplBase extends
org.omg.CORBA.portable.Skeleton implements Counter {
// Skeleton-Implementierung
}
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Zähler: Servant-Implementierung
// CounterImpl.java
public class CounterImpl extends _CounterImplBase {
private int counter=0;
/** Construct a persistently named object. */
public CounterImpl(java.lang.String name)
{super(name);}
/** Construct a transient object. */
public CounterImpl() {super();}
public void count() {counter++;}
public void countn(int n) {counter=counter+n;}
public int getcount() {return counter;}
public void getcountp(org.omg.CORBA.IntHolder count) {
count.value=counter;}
}
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 8
Interaktion von ORBs
Client
Servant
KommunikationsNetz
ORB A
ORB B
• General Inter-ORB Protocol (GIOP)
–
–
–
–
Common Data Representation (CDR) für IDL-Datentypen
Interoperable Object References (IOR)
Selbstbeschreibende Profile
Internet Inter-ORB Protocol (IIOP)
• Environment-Specific Inter-ORB Protocols (ESIOPs)
– Derzeit nur DCE/ESIOP
• ORB/ORB-Brücken mit DSI und DII
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Spezielle Objektdienste (CORBAservices)
• CORBAservices vervollständigen die Funktion des ORB
• Beispiele:
–
–
–
–
–
–
–
–
–
–
–
–
Namensdienst (naming service)
Such- und Vermittlungsdienst (object trading service)
Objektverwaltung (life cycle service)
Ereignisverwaltung (event service)
Persistenzdienst (persistent object service)
Transaktionsdienst (transaction service)
Objektauslagerung (externalization service)
Abfragedienst (query service)
Lizenzdienst (licensing service)
Eigenschaftsverwaltung (property service)
Zeitdienst (time service)
Sicherheitsdienst (security service)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
CORBA Service: Naming Service (1)
• Syntaxunabhängiger Namensdienst
– Zuordnen eines aussagekräftigen Namens zu einer Objektreferenz
– Anordnung und Verwaltung von Namen in Namensräumen
(Schnittstelle: NamingContext), in denen jeder Name jeweils
eindeutig ist (Bildung von Namenshierarchien).
– Durchsuchen von Namensräumen (Schnittstelle: BindingIterator)
• Notwendige Komponenten:
ClientObjekt
ServantObjekt
Object Request Broker (ORB) - Objektbus
Name Server
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 9
CORBA Service: Naming Service (2)
• Beispiel für Interaktion Servant-Objekt und Name Server:
cf : Counter
Factory
: Servant-Objekt
: ORB
MyNameSpace :
NamingContext
MyFactories :
NamingContext
MyNameSpace=resolve_initial_references ("NameService")
n=erzeuge_Namen
MyFactories=bind_new_context(n:Name)
bind(n:Name,cf)
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
CORBA Service: Naming Service (3)
• Beispiel für Interaktion Client-Objekt und Name Server:
: Client-Object
: ORB
MyNameSpace :
NamingContext
cf : Counter
Factory
MyNameSpace=resolve_initial_references ("NameService")
n=erzeuge_Namen
resolve(n:Name)
cf
anforderung()
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Evolution der OMA
• 1991:
CORBA Core 1.0
– Architektur, Kommunikation
– Interoperabilität
• 1995:
1999:
CORBA 2.0
CORBA 3.0
• 1994-1996:
CORBAservices
– Grunddienste für objektorientierte Anwendungen
• seit 1995:
CORBAfacilities
– Dienste für spezielle Anwendungsbereiche
– Allgemeine übergreifende Systemdienste
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 10
Neuere CORBA-Versionen (2.4 und 3.0)
• Neuigkeiten in CORBA (1999):
– Portable Object Adapter
» bessere Portierbarkeit von Applikationen zwischen ORBs
verschiedener Anbieter
– Weitere Kommunikationsarten
» Callback
» Polling
– "Objects by Value"
» Mobile Objekte
– "Quality of Service"
» Beeinflussung von Transport und Weiterleitung von
Anforderungen
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
CORBA: Perspektiven
• Chancen:
– Flexible, plattformunabhängige, heterogene Systeme
– Steigerung des Abstraktionsniveaus
(z.B. von Datenbankanbindung zur Objektverwaltung)
– Einbindung von Altsystemen möglich
• Probleme:
– Tempo der Standardisierung und Realisierung
– Performance bestehender Implementierungen
– “Angriffe” durch speziellere Systeme
(weniger Eleganz, höhere Leistung)
– Bruch mit bewährten Konzepten (z.B. SQL)
– Völlige Transparenz nicht immer erwünscht
Technische Universität Dresden
Prof. Hußmann
Softwaretechnologie II
Seite 11