Verteilte Objektsysteme - Verteilte Systeme

9.
Verteilte Objektsysteme
9.1
Grundidee
• Ausgangssituation: Programmierung objektorientierter Anwendungen.
• Verteilung der Objekte auf verschied. Rechner eines verteilten Systems:
- verteilungs- und ortstransparenter Methodenaufruf,
- aber keine Konsistenz von replizierten Objekten,
- und i.d.R. auch keine Persistenz
respektive Fehlertoleranz.
• Herausforderung:
- Kommunikationsaufwand unterscheidet sich enorm gegenüber dem lokalen Fall,
- Datenübertragung von Referenzen (Hüllenbildung),
• Unterstützung von verteilten Objekten im Programiermodell:
- Middleware-Ansätze: z.B. Corba, .NET, AspectX, ...
- Verteilte objekt-orientierte Betriebssysteme: Amoeba, Chorus, Plurix, ...
207
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2
9.2.1
.NET und Historie
Historie
COM - Grundlagen
• COM = Component Object Model, 1992
- sprachunabhängig (C++, Java, Basic, ...).
- Objekte in DLLs oder Programmen,
• Grundidee: Zusammenfassen
von Funktionen eines
Serverobjektes zu
Einheiten (Interfaces): Æ
COMObjekt
Klient
• COM definiert binäres Speicherlayout von Interfaces
- Speicherformat entspricht dem einer abstrakten C++ Klasse.
• Grundlage für viele weitere Dienste:
- OLE (Open Link Embedding), DCOM (Distributed COM), OCX, ActiveX, .NET.
208
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Instanzierung
• Objekte nicht mit „new“ instanziieren, sondern über COM-Laufzeitbib.
• Erzeugen von COM-Objekten erfolgt durch Klassenfabrik.
• Objekte durch UUID weltweit eindeutig identifizierbar.
• UUID = Universal Unique Identifier
- mit Tool guidgen.exe erzeugen,
- Abbildung auf DLL oder
(1)
eIn
ad
L
i br
eat
Cr
209
ce
Bem.: Für Klienten bleibt
unsichtbar, ob das Objekt
in einer DLL oder in
einem Programm
untergebracht ist.
n
sta
•
ClassFactory
ary
Co
(4)
Lo
• Ablauf der Instanziierung: Æ
COMObjekt
Klient
( 3)
Programm in Registry.
Server
(4)
t
ea
r
C
e
nc
a
t
s
e In
COM-Bibliothek
(2)
Registry
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Registrierung der Objekte:
Aufsuchen eines Interfaces über die GUID und Einträge in der Registry.
210
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Local Server
• Wird in einem fremden Adreßraum ausgeführt,
Æ COM Objekte in einem separaten Programm
• Server:
- eigenständiges Programm,
- Kommunikation über RPC,
- registriert seine Klassenfabrik beim Start.
• Proxy-Stub-Objekte für Interfaces eines fremden Adreßraumes:
- Signatur gemäß RPC Notation,
- Erzeugung mittels MIDL-Compiler,
- es gibt vordefinierte Interfaces: IStream, IStorage, ...
Klient
ProxyDLL
• Ablauf der Instanziierung:
-
Klient ruft „CoGetClassObject“,
COM-Bib. lädt LocalServer und Proxy-Dll,
Klient ruft „CreateInstance“ der ClassFactory,
LocalServer gibt Klient Zeiger auf Interface.
Class
Factory
COMObject
Server
211
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.2 DCOM
• DCOM = Distributed Component Object Model.
• DCOM ist ab NT 4.0 standardmäßig enthalten.
• DCOM Objekte:
- gleich implementiert wie ein Local-Server Objekt,
- aber auf anderen Maschine Æ Remote-Server,
- Klient muß für die Instanziierung einen Server angeben.
• Sicherheitseinstellungen durch dcomcnfg.exe.
• Adressierung:
- über Ort im verteilten Dateisystem,
- über GUID,
- über URL.
212
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.3 .NET Überblick
• Anwendungsplattform Æ
zur Entwicklung von
verteilten XML-basierten
Web-Anwendungen
• Merkmale des .NET
Frameworks:
Framework &
Tools
Common Language Runtime
Einheitliche Klassenbibliothek
Visual Studio.NET
Building Block
Services
Ständig verfügbare Internet-Dienste
(Code-Updates, Suchdienste, Messenger)
- sprachunabhängig durch
Common Type System,
- plattformunabhängig durch
Zwischencode,
- sprachübergreifende
Laufzeitumgebung,
- Kommunikation über HTTP &
XML.
Infrastruktur
Devices
Heutige „2000-Produktfamilie“
(zukünftig .NET Enterprise Servers)
Mobile Geräte, auf denen .NET
Anwendungen laufen (Handy, Handheld)
• Wesentliche Teile standardisiert Æ ECMA
- OpenSource Implementierung Mono.
213
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.4 Common Language Runtime
• Compiler generieren Zwischencode:
Oberon
C#
C++
Compiler
Compiler
Compiler
IL Code
IL Code
IL Code
ASM Code
Common Language Runtime
JIT Compiler
Betriebssystem
214
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Common Language Runtime (CLR):
-
sprachübergreifende Laufzeitumgebung,
sprachübergreifende Klassenbibliothek,
erweiterbares Format für Meta-Daten,
sprachübergreifendes Typsystem.
• Microsoft Intermediate Language (IL=MSIL)
Æ IL für eine abstrakte Stackmaschine (vgl. Java Virtual Machine).
• Managed Code/Data:
-
automatische Freispeichersammlung (GC),
wird unter Regie der CLR ausgeführt,
Fehlerbehandlung (Exceptions),
Sicherheitsprüfungen,
Versionsprüfungen.
• Ausführung durch Execution Engine (EE):
- Exe-Datei: IL-Code + Stub zum Laden der Execution Engine,
- nach Laden wird native Code erzeugt (IL wird nie interpretiert),
- Bem.: EE ist als COM-Komponente realisiert.
• Unmanaged Code/Data:
- Brücke zu anderen Code-Teilen z.B. C-DLLs,
- bzw. explizit verwaltetem Speicher (malloc & free).
215
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
MSIL – MicroSoft Intermediate Language
• Im Vergleich mit reinen Assembler-Sprachen eher an höhere
Programmiersprachen angelehnt:
.assembly hello {}
.method public static void Main() il managed
{
.entrypoint
.locals(int32 V_0) // lokale 'var'
ldc.i4.2
// push '2'
ldc.i4.3
// push '3'
add
// addiere
stloc.0
// speichere in 'var'
ldloc.0
// push var
call void [mscorlib]System.Console::WriteLine(int32)
ret
}
216
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
.NET Klassenbibliotheken
• Umfangreiche Bibliotheken, z.B. System:
System.Web
Services
Description
UI
HtmlControls
Discovery
WebControls
System.WinForms
Design
Protocols
ComponentModel
System.Drawing
Caching
Security
Drawing2D
Printing
Configuration
SessionState
Imaging
Text
System.Data
System.Xml
ADO
SQL
XSLT
Design
SQLTypes
XPath
Serialization
System
217
Collections
IO
Security
Runtime
InteropServices
Configuration
Net
ServiceProcess
Diagnostics
Reflection
Text
Remoting
Globalization
Resources
Threading
Serialization
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.5 Common Type System
• Typen sind sprachübergreifend eindeutig.
• Objektmodell Æ
Typen im
Object
Namespace
System
Value Type
218
Type
Enum
Boolean
Struct
Char
String
Array
Int32
Exception
...
...
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Werte-Typen: primitive Datentypen, Aufzählungen und Records.
• Referenz-Typen: Arrays, Klassen, Interfaces, und Delegates.
• Vererbung:
- einfache Klassenvererbung,
- mehrfaches Subtyping durch Interfaces.
• Boxing:
- Umwandlung zwischen primitiven Datentypen und Objekten,
- Man vergleiche Typklassen (Integer, Double, ...) in Java.
x
5
public static void main() {
int
x = 5;
object
o = x;
int
y = (int)o;
}
System.Int32
o
y
219
5
5
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.6 Assemblies
• Assemblies sind Container für eines oder mehrere Module:
-
äquivalent zu Java JAR-Dateien,
ersetzen DLL- und Exe-Dateien,
dynamisch ladbar von Disk oder Internet,
enthalten:
o MSIL-Code,
o Reflectioninformation,
o Versionskennung Æ „avoid DLL hell“,
o Manifest (Import-, Export- & Sicherheitsanweisungen).
Assembly (app1.dll)
Modul
Manifest
MSIL
(Typ A)
MSIL
(Typ B)
MSIL
(Typ C)
Metadaten fürA, B und C
220
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Assembly Kategorien
• Private Assemblies:
-
normalerweise nur von einer Anwendung nutzbar,
typischerweise im Anwendungsverzeichnis,
Identifikation anhand einfachen Namens,
keine Versionsprüfung.
• Shared Assemblies:
- Installation in Global Assembly Cache,
- sind global für alle Anwendungen,
- obligatorische Versionsprüfung.
• Strong Names für Shared
Assemblies:
- Name + Version,
- und Key (Signatur).
Æ kein Austausch möglich.
221
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Signieren von Assemblies
• Verfahren mit öffentlichen Schlüsseln.
• Öffentlicher Schlüssel im Manifest ablegen.
• Rechtmässiger Erzeuger signiert Dateien mit privatem Schlüssel.
• Mithilfe des öffentlichen Schlüssels ist Echtheit der Signatur prüfbar.
• Klienten speichern mit
Key-Pair
dem Namen auch den
Compiler
Compiler
öffentlichen Schlüssel.
Quellen
Æ Strong Name
MyLib
• Schlüsselpaar erzeugen: Main
- sn.exe –k c:\outf
- sn = strong name (utility).
Manifest
Ref.: MyLib
PK=34e25c…
Manifest
PK=34e25c…
Strong Name
Signature
222
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Versionierung
• Version im Manifest: Major.Minor.Revision.Build
• Annahme: Assembly kompatibel, falls Major- & Minor-nr. gleich.
• Klient per Default an Version gebunden, die sein Manifest referenziert.
• Side-by-Side Execution: Æ
Calc.DLL
App.exe
- veschiedene Versionen einer DLL
in einem Prozess gleichzeitig ladbar.
• Abschaffung der „DLL-Hölle”
- Anpassung der Bindung explizit durch eine
CFG-Datei steuerbar z.B. client.exe.config
Æ Lösung des DLL-Problems
(hier kein Versionsmanagement vorhanden).
• Culture-Attribute für Lokalisierung.
Ref-1:
Calc.DLL
1.2.3.4
22acab57
Ref-2:
AdvMath.DLL
(private)
1.2.3.4
22acab57
AdvMath.DLL
Ref-1:
2.0.0.0
56ab8157
Calc.DLL
2.0.0.0
56ab8157
223
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.7 Application Domains
• CLR abstrahiert von OS-Prozessen u. arbeitet mit virtuellen Prozessen.
• Application Domain = isolierter Ausführungsraum für eine Anwendung.
• Sicherheit & Isolierung durch strenges Typsystem und Code-Verifier.
• Marshalling für Aufrufe zwischen Application Domains.
Marshaling
Prozeß 1
AppDomain
Objekt
Prozeß 2
AppDomain
AppDomain
Objekt
Objekt
Objekt
Objekt
Marshaling
224
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Marshalling
• Marshalling: Serialisierungsformat XML / SOAP.
• Marshal-By-Value:
-
Kopie an Ziel senden (Standard),
keine Verbindung zw. Kopie & Original,
auto. Serialisierung mit Klassen-Attribut Serializable,
Einschränkung durch Variablen-Attribut NonSerialized,
individuelle Serialisierung durch das Interface ISerializable.
• Marshal-By-Reference:
- nur Referenz an Ziel senden – keine Kopien,
- Verbindung zwischen Referenz & Original durch Stellvertreter-Objekt (Proxy).
- Implementierung durch Ableiten einer Klasse von System.MarshalByRefObject.
225
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.8 Remoting
• Framework für Kommunikation zw. (entfernten) Application-Domains.
• Messages: Was wird gesendet?
• Channels: Wohin wird gesendet?
• Formatter: Datenformat für die Kommunikation
• Proxy: Umwandlung von Methodenaufrufe in Messages.
• Dispatcher: Umwandeln von Messages in Methodenaufrufe.
Client
"Proxy"
226
Channel
Server
Dispatcher
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Channel & Formatter
• Channel: Wohin wird gesendet?
- bidirekt. Kommunikation zw. 2 Endpunkten, TcpChannel, HttpChannel & SmtpChannel,
- eigene Channels mögl. Æ IChannel.
- Adressierung Æ
• Formatter: Datenformat
- definiert Wire-Format (Channel-Protokoll).
• Formate:
-
Soap über HTTP Æ interoperabel,
Binary über TCP Æ schnell,
eigene Formate möglich Æ IFormatter,
wird vom Channel dynamisch angefordert.
• Serialisierung mithilfe der
Metainformation im Assembly.
MyObj
MyService
MyObj
HTTPChannel
StackBuilderSink
(URI:MyObj)
CLR AppDomain
User Prozeß
Winsock: Socket
TCP:345
345 Å 80
BS Kern
myhost.org
http://myhost.org:345/MyObj
227
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Beispiel:
[Serializable] class Point : ISerializable {
private int x,y;
public void GetObjectData(SerializationInfo info, StreamingContext ctx) {
Type t = this.GetType(); . . . .
info.AddValue("x",x); info.AddValue("y",y);
}
}
public void ToFile (string file) {
FileStream fs = new FileStream(file,FileMode.Create);
SoapFormatter form = new SoapFormatter();
form.Serialize(fs,this);
}
class FormatterTester {
static void Main(string[] args) {
Point p = new Point();
p.ToFile("test.dat");
}
}
228
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Proxy
• Transparent-Proxy (TP):
-
automatisch generiert aus Schnittstelle,
wandelt Aufrufe in ein IMessage-Objekt um,
und ruft dann Invoke des Real-Proxy.
TP kann nicht erweitert oder
Klient
ersetzt werden,
• Real-Proxy:
- kann ersetzt werden,
- für eigene Erweiterungen,
- z.B. für Lastverteilung, ...
Proxy
Server
IMessageSink
Channel
Transparent
Proxy
mthA
Invoke
SyncProcessMessage
mthB
varV
Real Proxy
229
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Sinks
• Ein Channel kann mehrere Sinks implementieren.
• Werden dynamisch erzeugt und installiert.
• Bei Bedarf mehrere miteinander verkettet.
ObjRef
• Zum Überwachen
und Logging, ...
TP
RP
Sink
Sink
Sink
Sink
Formatter
Channels
Compiler
Sink
Sink
Sink
Sink
Object
230
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Aktivierung von Objekten durch den Server
• Server meldet Objekt im System an und Klienten verbinden sich damit.
• SingleCall: pro Aufruf ein neues Obj. (kein Status Æ skaliert gut).
• Singleton: ein Objekt für alle Klienten (Synchronisierung?).
Server:
public class ServerObject : MarshalByRefObject {
public int print(string s) {}
}
public class MyServer {
public static int Main(string [] args) {
HttpChannel chan = new HttpChannel(999);
ChannelServices.RegisterChannel(chan);
}
231
}
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(ServerObject), "myendpoint", WellKnownObjectMode.Singleton);
Console.ReadLine();
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Klient:
public class Client {
}
232
public static int Main(string [] args) {
ServerObject factory;
string
EP="http://localhost:999/myendpoint";
factory = (ServerObject) RemotingServices.Connect(typeof(ServerObject), EP);
factory.print("hallo");
}
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Aktivierung von Objekten durch den Klienten
• Der Server meldet die Klasse im System an.
• Die Klienten können selbst Objekte erzeugen.
• Klient kann die Lebensdauer der Objekte steuern.
• Verbindungsorientiert (vgl. DCOM).
Server:
public class MyServer {
public static int Main(string [] args) {
HttpChannel chan = new HttpChannel(999);
ChannelServices.RegisterChannel(chan);
}
233
}
RemotingConfiguration.ApplicationName = “myobj";
RemotingConfiguration.RegisterActivatedServiceType(typeof(ServerObject));
Console.ReadLine();
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Klient:
public class Client {
public static int Main(string [] args) {
object[] attrs = new object[1];
Object[0] = new UrlAttribute("http://localhost:999/myobj");
ObjectHandle oh = Activator.CreateInstance("Server","ServerObject",attrs);
if (oh!=null) {
ServerObject so = (ServerObject)oh.Unwrap();
so.print("hallo");
}
}
}
234
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Lease Manager pro Domain
• Verwaltet die Lebenszeit der klientenaktivierten Objekte.
• Objekte deren Lebenszeit abgelaufen ist, werden der GC zugeführt.
• Verlängerung durch Sponsor oder via Methodenaufruf des Klienten.
• Jeder Aufruf des Objektes verlängert die Lebenszeit um konfig. Wert.
public class ServerObject : MarshalByRefObject {
public int v=0;
public override Object InitializeLifetimeService() {
ILease lease = (ILease)base.InitializeLifetimeService();
if (lease.CurrentState == LeaseState.Initial) {
lease.InitialLeaseTime = TimeSpan.FromSeconds(10);
lease.SponsorshipTimeout = TimeSpan.FromSeconds(20);
lease.RenewOnCallTime = TimeSpan.FromSeconds(20);
}
return lease;
}
}
235
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.2.9
Web-Programmierung
Active Server Pages
• Script-Code eingebettet in HTML-Seiten wird auf Server ausgeführt.
• Erzeugt dynamische HTML-Seiten für den Klienten.
• Skriptsprachen: VBScript & JScript.
• Microsoft Web-Server (IIS) notwendig.
• ASP-Dateien (bestehende Technik vor .NET),
• Beispiel: Cookie auslesen und Inhalt in HTML-Seite einfügen
<HTML>
<BODY>
Ich lese ein Cookie vom Klienten:
<%
a=Request.Cookies("Name")
Response.Write(a)
%>
</BODY>
</HTML>
236
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
ASP.NET – Web Applikationen
• Web Applikationen:
-
ASPX-Dateien in Web-Server Verzeichnis,
Code in separaten Dateien (*.cs, *.mod),
Kompilation beim ersten Aufruf,
Klient erhält nur HTML.
• Web Controls:
- laufen auf dem Server,
- ersetzen HTML Input-Tags,
- im Code über ID zugreifbar.
• Klient erzeugt Ereignis,
Server verarbeitet es:
Web Client
Event
Event
Message
Server
Parse Message
Aufruf Event
Handler
Event Handler
Antwort
237
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Beispiel.aspx:
<%@ Page Inherits="SeiteBerechnen" Src="Simple.cs" %>
<html>
<head><title>ASP.NET Hypotheken Rechner</title></head>
<body>
<form runat="server">
<asp:Button Text="knopf" OnClick="click" RunAt="server" id="button1" />
</form>
</body>
</html>
• Simple.cs:
public class SeiteBerechnen : Page {
protected Button button1;
public void click(Object sender, EventArgs e) { … }
}
238
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
ASP.NET – Web Dienste
• Idee: Dienste über das Web anbieten aufbauend auf http & XML.
• Web Dienste:
- ASMX-Dateien (*.asmx),
- Methoden mit Attribut „WebMethod“
(können von entferntem Klient gerufen werden),
- plattform- und sprachunabhängige Komponenten,
- einfach einbindbar durch auto. erzeugte Proxy-Objekte.
• Web Dienst allgemein:
- ein Dienst, dessen Schnittstelle mit WSDL beschrieben, mit
UDDI registriert und gefunden und mit SOAP angesprochen wird.
• Techniken:
-
239
XML: Datenaustausch,
DISCO (Discovery): XML-File zum Erforschen eines bekannten URLs,
SOAP (Simple Object Access Protocol): XML-basierter Methodenaufruf,
WSDL (Web Service Description Language): Beschreibung eines Dienstes,
UDDI (Universal Service Description, Discovery, and Integration): Auffinden von Diensten.
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Beispiel.asmx:
<%@ WebService Language="C#" Class="MyService" %>
using System;
using System.Web.Services;
public class MyService : WebService {
[WebMethod]
public int add(int a, int b) {
return a+b;
}
}
• Interaktives Testen auf WebServer-Maschine über HTTP:
http://localhost/Service/Service.asmx?op=add
• Mehr Infos: Architekturen für verteilte Internetdienste (F. Hauck).
240
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3
Corba
9.3.1 Standardisierung
• CORBA = Common Object Request Broker Architecture:
- plattformunabhängige Middleware-Architektur für verteilte Objekte,
- aufgesetzt auf ein vorhandenes Betriebssystem,
- auch für heterogene verteilte Systeme.
• OMG = Object Management Group:
- Standardisierungsorganisation mit etwa 1000 Mitgliedern,
- Publikation verschiedener Standard-Dokumente,
- Definition von CORBA –Kompatibilität.
• Teilbereiche der Standardisierung:
- CORBA – Softwarearchitektur für Komponenten,
- UML – Unified Modelling Language,
- XMI – XML Metadata Interchange ...
• Entwurf von Systemen mit hoher Komplexität ...
241
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.2 Zielsetzung
• Verteilte objektbasierte Programmierung:
- verteilte Objekte mit definierter Schnittstelle.
Obj
Obj
Obj
• Heterogenität in Verteilten Systemen:
- verschiedene Betriebssystem-Architekturen,
- verschiedene Hardware-Architekturen,
- verschiedene Programmiersprachen.
• Anbindung an Altsysteme (Legacy):
- insbesondere C, Pascal und Visual Basic,
- CORBA-Anwendungen sollen mit
Middleware
OS OS
OS
OS
Altsystemen interagieren.
• Freiheitsgrade bei der Middleware-Implementierung:
- CORBA schreibt keine Implementierung vor, sondern die Funktionalität,
- CORBA fordert Interoperabilität verschiedener Implementierungen,
- partielle Implementierung zulässig.
242
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.3 OMA - Object Management Architecture
• ORB als “Softwarebus” bzw. „Komponentenbus“:
- Services: systemorientierte Dienste,
- Facilities: anwendungsorientierte Dienste.
Anwendungsobjekte
Vertikale
Vertikale
VerticalFacilities
Facilities
Facilities
Horizontal
Facilities
ORB
CORBA Services
243
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Anwendungsobjekte
• Verteilte CORBA-Objekte:
- Ein Objekt immer auf einem bestimmten Rechner (keine verteilten Objektfragmente),
- Kommunikation zwischen den Objekten über ORB,
- Objekte bilden gemeinsam eine Anwendung.
• Implementierungsperspektive:
- interne Implementierung über Stellvertreterobjekte,
- Legacy-Anwendungen können Objektaufrufe durchführen,
- Der Aufrufer muss nicht unbedingt ein CORBA-Objekt sein:
non-object
object
Knoten
244
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
CORBA-Services
• Services bieten weitergehende systemorientierte Dienstleistungen an:
- allgemein brauchbare und standardisierte Dienstleistungen,
- Mit Objektschnittstelle und Methoden zum Aufruf,
- ORB-Erweiterungen.
• Konkret zum Beispiel:
-
245
Namensdienst (zum Auffinden von Objekten),
Zeitdienst (zum Synchronisieren der Zeit),
Sicherheitsdienst (zur Zugriffskontrolle).
Concurrency, Transactions,
Licensing …
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
CORBA-Facilities
• Facilities sind anwendungsorientierte Dienstleistungen:
- im Gegensatz zu CORBA-Services (systemorientierte Dienstleistungen),
- könnten auch vom Anwendungsprogrammierer erstellt werden.
• Horizontale CORBA-Facilities:
- über Anwendungsgebiete hinweg nutzbare Dienstleistungen,
- z.B. Dokumentenbearbeitung, Druckdienst, Mobile Agenten, ...
• Vertikale CORBA-Facilities:
-
246
Betrachtung einer Anwendungsdomäne (Domain Facilities)
z.B. Dienste für Gesundheitswesen (Patientenverwaltung CORBAmed),
Finanzdienstleistungsgewerbe,
Produktmanagement,
Telekommunikation, ...
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
ORB - Object Request Broker
• Rückgrat einer CORBA-Middleware.
• Vermittelt Methodenaufrufe von einem zum anderen Objekt.
• Interne Komponenten im ORB:
Language Mapping,
Dynamic Interfaces,
Inter Orb Protocols,
Objekt-Adapter, …
Objekte
(im Servant)
Klient
Interface
Repository
DII
247
IDL Stubs
GIOP / IIOP
Skeleton
ORB Intf.
DSI
Object Adapter
ORB Core
Implementation
Repository
-
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.4 CORBA Objekte
• Eigenschaften eines CORBA-Objekts
-
Attribute (von außen zugreifbare Instanzvariablen),
Operationen (von außen zugreifbare Methoden),
verteilt bzw. remote aufrufbar,
Identität der Instanz,
Zustand.
• Stub enthält GET- und SET-Routinen für exportierte Variablen.
• Zum Thema „Objektorientierung“:
- CORBA-Objekt muss nicht identisch mit einem Objekt in einer Programmiersprache sein,
- CORBA kann auch „objektlose“ Programmiersprachen unterstützen, z.B. C.
248
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.5
Interface Definition Language
Schnittstellenkonzept
• Von außen zugreifbare Attribute und Operationen müssen in
Schnittstellendefinition deklariert werden.
• Schnittstelle wird unabhängig von der benutzten Programmiersprache in
einer Interface-Definition-Language (IDL) beschrieben
• Language-Mapping:
- Abbildung zwischen Programmiersprache und IDL-Syntax/Typen,
- Von CORBA unterstützte Sprachen:
o Ada, C, C++, Java, Lisp, PL/I, Python, Smalltalk,
o weitere inoffizielle Language-Mappings existieren, z.B. für Perl.
• IDL angelehnt an C++:
-
249
geringer Lernaufwand für C++ Programmierer,
Basistypen, Aufzählungstyp, Strukturen,
Vererbung, geschachtelte Module,
Exceptions, ...
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Parameterübergabesemantik
• Call-by-Value: Wert wird kopiert
- für Basistypen, z.B. byte, int, long, …
- für zusammengesetzte Typen: arrays, union, …
• Call-by-Object-Reference: Referrenz auf das Objekt wird kopiert
- für Objekttypen,
• Value-Types (seit CORBA 2.3):
- Call-by-Value-Übergabe für CORBA Objekte (optional),
- Parameter wird serialisiert (ähnlich Java),
- Z.B. für struct, record, Objekte, …
valuetype AccountVal{
public short accoutnNr;
private double balance;
double withdraw( in double amount ) ;
double deposit( in double amount );
factory init( in short accountNr );
}
250
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Beispiel: Umsetzung von IDL in Sprachkonstrukte (z.B. Java)
• Java IDL-Compiler: idlj hello.idl
module HelloApp {
interface Hello {
string sayHello();
};
};
• Java Version des IDL-Interfaces:
/* Hello.java as generated by idlj */
package HelloApp;
public interface Hello extends org.omg.CORBA.Object {
String sayHello();
}
• Ausgabe des IDLJ Präcompilers:
_HelloStub.java: Client Stub,
Hello.java: Java version des IDL-Interfaces
HelloPOA.java: stream-basierter Server Skeleton,
HelloOperations.java: Operationen des Interfaces (extends Hello),
HelloHolder.java: Operationen (read & write) für out- und inout-Parameter,
HelloHelper.java: u.a. Hilfsfkt. zur Typumwandlung von CORBA- auf Java-Typen.
251
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Java Holder-Klassen: für mehrfache Ergebnisse / inout-Parameter
- manche Programmiersprachen können nicht mehrere Ergebnisse zurückzugeben
- Lösung: Java Holder-Klassen Æ Rückgabewerte gepackt in ein Objekt,
welches zurückgegeben wird.
• Java Helper-Klassen: für Typumwandlung bei Vererbung
- Umwandlung in spezifischeren Typ ist nur möglich, wenn tatsächlich vorliegend,
- Umwandlung in weniger spezifischen Typ ist immer möglich,
- narrow-Operation (CORBA-Cast) benötigt
sprachabhängige Umsetzung.
• Vorteile:
- Schnittstellenbeschreibung unabhängig von Implementierungssprache,
- ermöglicht Unterstützung vieler Programmiersprachen,
- IDL ist sehr ausdrucksstark.
• Nachteile:
- Objektschnittstelle muss in IDL und in der Implementierungssprache
beschrieben werden (letzteres kann teilweise automatisiert werden),
- Sprachabbildung für IDL-Konstrukte, die in einer Programmiersprache nicht direkt vorhanden sind, ist kompliziert,
- Einige besondere Fähigkeiten einer Sprache,
können nicht genutzt werden.
252
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.6 Objekterzeugung auf dem Server
• Beschreibung der Objekt-Schnittstelle in IDL.
• Implementierung des Servant:
- Servant realisiert ein (oder auch mehrere) CORBA-Objekte,
- Entscheidung für eine Programmiersprache,
- Umsetzung der IDL-Schnittstelle in ein Skeleton,
- Skeleton (HelloPOA.java) wird in der Regel ausgefüllt mit Implementierungscode,
- Prä-Compiler wird i.d.R. IDL-Compiler genannt.
253
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Schritt-1: Instanzieren des CORBA-Objekts (Servant):
• Schritt-2: Aktivieren des Portable Object Adapter (POA):
- mindestens eine POA-Instanz pro Adressraum (Server-Prozess),
- Aufruf von activate() am POA, um diesen zu aktivieren:
• Schritt-3: CORBA-Objektreferenz erzeugen:
- Aufruf von servant_to_reference(ServantRef) am POA,
- liefert Objektreferenz auf CORBA-Objekt (nicht Servant).
• Schritt-4: CORBA-Objekt im Namensdienst registrieren:
- zunächst Referenz auf Namensdienst beschaffen:
o Initiale entfernte Objektreferenz muss irgendwie beschafft werden,
o ORB-Interface: z.B. orb.resolve_initial_reference( “NameService” ).
- dann Objekt mir rebind(Pfad, ObjektReferenz) registrieren.
254
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Java-Beispiel: HelloServer.java
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
import java.util.Properties;
public class HelloServer {
public static void main(String args[]) {
try {
ORB orb = ORB.init(args, null);
// create and initialize the ORB
// step-1: create servant
HelloServant helloObj = new HelloServant();
// step-2: get reference to rootpoa & activate the POAManager
POA rootpoa = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
// step-3: get object reference from the servant
org.omg.CORBA.Object ref = rootpoa.servant_to_reference(helloObj);
Hello href = HelloHelper.narrow(ref);
255
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
// step-4: get reference to name service
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
// bind the Corba object reference in the name service
String name = "Hello";
NameComponent path[] = ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println("HelloServer ready and waiting ...");
// wait for invocations from clients
orb.run();
}
catch (Exception e) { … }
}
}
• Beispiel: HelloServant (extends Skeleton HelloPOA):
public class HelloServant extends HelloPOA {
public String sayHello() {
return "\nHello world!\n";
}
256
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Portable Object Adapter
• Aufgaben eines Objektadapters (OA):
-
Generierung der Objektreferenzen,
Aktivierung und Deaktivierung von Servants,
Authentisierung des Aufrufers (im Security-Service),
Entgegennahme/Weiterleitung eingehender Methodenaufruf-Anfragen.
• Portable-Object-Adaptor (POA):
- definierte Funktionalität für die häufigsten Aufgaben,
- Obligatorischer Adapter für alle ORBs.
• Jeder Servant kennt seine OA-Instanz:
- OA-Instanz kennt die an ihm angemeldeten Objekte,
- OA stellt Kommunikationsplattform bereit,
- nimmt Aufrufe entgegen für seine Obj.
• Root-POA existiert in jedem ORB:
- voreingestellte Konfiguration,
- Anfrage am ORB mit: orb.get_initial_references( “RootPOA” ),
- kann zur Aktivierung von Objekten und weiteren OAs verwendet werden.
257
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.7 Objektnutzung durch den Klienten
• Erzeugung eines Stubs durch den Pre-Compiler:
- Auswahl einer Programmiersprache für die Client-Seite,
- Umsetzung der IDL-Schnittstelle in einen Stub.
• Zugriff:
- Schritt-1: zunächst Referenz auf Namensdienst beschaffen,
- Schritt-2: CORBA-Objekt per Namen suchen,
- Schritt-3: Methoden rufen.
• Bem.: Empfang eines Parameters mit Objekttyp:
- autom. Erzeugung einer neuen Objektreferenz mit Hilfe des Stub-Code,
- Objekttyp ist zur Compile-Zeit bekannt: Stub-Code kann erzeugt werden.
258
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
Java-Beispiel: HelloClient.java
import HelloApp.*;
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
public class HelloClient {
public static void main(String args[]) {
try {
ORB orb = ORB.init(args, null);
// create and initialize the ORB
// step-1: get the root naming context
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
// step-2: resolve the Object Reference in name service
String name = "Hello";
Hello helloObj = HelloHelper.narrow(ncRef.resolve_str(name));
System.out.println("Obtained a handle on server object: " + helloObj);
// step-3: use CORBA object
System.out.println(helloObj.sayHello());
} catch (Exception e) { … }
}}
259
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.8 Dynamic Invocation Interface
• Der Typ eines Objekts ist zur Compilierungszeit evtl. nicht bekannt.
• Interface-Repository:
-
wird über den ORB abgefragt,
hier müssen Schnittstellendefinitionen hinterlegt werden,
Abfrage der Objektschnittstelle beim Interface Repository,
Methoden, Parameter und deren Typen können erfragt werden.
• Dynamische Konstruktion des Aufrufobjekts:
-
Durch den Programmierer,
zunächst Request-Objekt erzeugen,
Benennung der Methode und Param. als String,
Typ des Rückgabewertes setzen,
(vgl. textueller Aufruf in Plurix).
• Aufruf durch Invoke() am Request-Objekt.
• Bem.: sehr umständlich zu programmieren.
260
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.9 Kommunikationsprotokolle
• Innerhalb einer ORB-Instanz können Objekte mit
herstellerspezifischem Protokoll kommunizieren.
• Zwischen ORBs verschiedener Hersteller: GIOP oder IIOP.
• GIOP – General Inter-ORB Protocol (standardisiert in CORBA):
- Austauschformat zwischen ORBs verschiedener Hersteller,
- Common Data Representation (CDR) definiert Marshalling & Unmarshalling von IDL-Typen
- GIOP Request Typen:
o
o
o
o
o
LocateRequest & LocateReply zum Auffinden eines Objektes,
Request & Reply für einen Methodenaufruf,
MessageError, Fragment,
CloseConnection,
CancelRequest.
• IIOP – Internet Inter-ORB Protocol: GIOP über TCP/IP.
• Bem.: GIOP-Implementierungen über andere Protokolle möglich.
261
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
IOR – Interoperable Object Reference
• Darstellung einer Objektreferenz als IDL-Datenstruktur:
- muss verwendet werden für GIOP,
- Repräsentation als String möglich (object_to_string).
• Profile in der IOR:
- für jede Protokollfamilie eigenes Profil möglich,
- Objekt kann theoretisch mehrere Protokolle unterstützen,
z.B. IIOP neben herstellerspezifischem Protokoll.
- Inhalt:
o Repository-ID: Objekttyp,
o Host-ID: IP-Adresse,
o POA-ID: Server-POA,
o Object-ID: Servant, …
• Typische Implementierung
in Standard-ORBs:
- IOR wird als
IOR
eindeutiger
Objektbez.benutzt,
- Nutzung von IIOP
auch innerhalb
des ORBs?
262
Repository ID
POA
Object Server
Identifier Identifier spec.
IIOP Host Port
Version ID number
Profile
ID
Profile
Data
...
Object
Key
Components
Next
Profile
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.3.10
CORBA Perspektive
• Verknüpfung mit RMI:
-
RMI kann mit IIOP betrieben werden,
standardisierte Abbildung von Remote-Schnittstellen auf IDL (und zurück),
CORBA-Objekt erscheinen als RMI-Objekte,
RMI-IIOP-Objekte können als CORBA-Objekte auftreten.
• Fault-Tolerant-CORBA:
- CORBA-Erweiterung (ab Version 3.0) für fehlertolerante Objekte,
- Middleware-Erweiterung für Objektgruppen-Referenzen,
- Transparente Replikation von CORBA-Objekten:
o Aufruf wird automatisch an alle Replikate verteilt,
o strikte Konsistenz oder manuell durch Programmierer gesteuert.
• Quellen:
-
263
Hauck F., Vorlesung „Architektur für verteilte Objekte“,
Th. Guenkova-Luy, Vorlesung „Verteilte Betriebssysteme“, WS01/02,
Weber M., Verteilte Systeme, 2002,
Tanenbaum A., v. Steen M., Distributed Systems, Prentics Hall 2002,
Bengel G., Verteilte Systeme, Vieweg 2000.
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
9.4
Zusammenfassung
• Verteilung der Objekte auf verschied. Rechner eines verteilten Systems:
- verteilungs- und ortstransparenter Methodenaufruf,
- aber keine Konsistenz von replizierten Objekten,
- punktuell mit Fehlertoleranz (z.B. Corba 3.0).
• Microsoft .NET:
- sprachübergreifende Laufzeitumgebung und ein gemeinsames strenges Typsystem,
- Versionsmanagement für Assemblies (i. Geg. zu DLLs),
- Remoting:
o Channel: Wohin wird gesendet?
o Formatter: Datenformat (z.B. SOAP über HTTP)
o Proxy: Umwandlung von Aufrufen in Nachrichten
o Dispatcher: Servergengstueck für Proxy
o Sinks: dyn. erzeugbar; mehrere pro Channel mögl.; zum Überwachen ...
o Objektaktivierung: durch Server oder Klient (mit Timeout / Lease)
- ASP.NET Anwendungen: .NET Code in Webserver-Verz.
Æ reagiert z.B. auf Klient-Ereignisse.
- ASP.NET WebDienste:
o Services über WebServer per SOAP zugreifbar,
o Proxies auto. generierbar,
o nicht nur für .NET.
264
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner
• Corba:
- plattformunabhängige Middleware-Architektur für verteilte Objekte,
- verschied. kompatible Implementierungen für beliebige Betriebssysteme,
- wesentliche Bestandteile:
o ORB: vermittelt Methodenaufrufe zwischen CORBA-Objekten,
o Anwendungsobjekte (auch in nicht-objekt-orientierten Sprachen mögl.),
o Services: systemorientierte Dienste (z.B. Naming),
o Facilities: anwendungsorientierte Dienste,
o kein gemeinsames Typsystem, sondern IDL Sprache für Interfaces,
- Instanziierung:
o Servant stellt ein oder mehrere Objekte bereit,
o Objekte werden beim POA aktiviert,
o POA erzeugt CORBA-Referenzen,
o diese werden im Namensdienst registriert,
o Klient greift ueber Stub (generiert durch IDL-Comp.) hierauf zu.
- Kommunikationsprotokolle: GIOP bzw. IIOP zw. ORBs verschied. Hersteller,
- IOR:
o unterstützt mehrere Protokolle,
o Inhalt (u.a.): IP-Adr., Port, POA-ID, Object-ID, ...
265
Verteilte Betriebssysteme, Winter 2005 © Verteilet Systeme, Universität Ulm, M. Schöttner