Herausforderung: - Kommunikationsaufwand unterscheidet sich enorm gegenüber dem lokalen Fall, - Datenübertragung von Referenzen (Hüllenbildung),

Transkript

1 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, Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

2 9.2.NET und Historie Historie COM - Grundlagen COM = Component Object Model, sprachunabhängig (C++, Java, Basic,...). - Objekte in DLLs oder Programmen, Grundidee: Zusammenfassen von Funktionen eines Serverobjektes zu Einheiten (Interfaces): Klient COM- Objekt 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

3 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 Programm in Registry. Ablauf der Instanziierung: Klient Server COM- Objekt Class- Factory Bem.: Für Klienten bleibt unsichtbar, ob das Objekt in einer DLL oder in einem Programm untergebracht ist. (1) CoCreateInstance COM-Bibliothek Registry 209 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner (4) (3) LoadLibrary (4) CreateInstance (2)

4 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

5 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,... 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 Server Klient Proxy- DLL COM- Object 211 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

6 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

7 9.2.3.NET Überblick Anwendungsplattform zur Entwicklung von verteilten XML-basierten Web-Anwendungen Merkmale des.net Frameworks: - sprachunabhängig durch Common Type System, - plattformunabhängig durch Zwischencode, - sprachübergreifende Laufzeitumgebung, - Kommunikation über HTTP & XML. Framework & Tools Building Block Services Infrastruktur Devices Wesentliche Teile standardisiert ECMA - OpenSource Implementierung Mono. Common Language Runtime Einheitliche Klassenbibliothek Visual Studio.NET Ständig verfügbare Internet-Dienste (Code-Updates, Suchdienste, Messenger) Heutige 2000-Produktfamilie (zukünftig.net Enterprise Servers) Mobile Geräte, auf denen.net Anwendungen laufen (Handy, Handheld) 213 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

8 9.2.4 Common Language Runtime Compiler generieren Zwischencode: Oberon C# C++ Compiler Compiler Compiler ASM Code IL Code IL Code IL Code Common Language Runtime JIT Compiler Betriebssystem 214 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

9 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

10 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

11 .NET Klassenbibliotheken Umfangreiche Bibliotheken, z.b. System: Services Description Discovery Protocols Caching Configuration System.Web UI HtmlControls WebControls Security SessionState Design Drawing2D Imaging System.WinForms ComponentModel System.Drawing Printing Text System.Data System.Xml ADO SQL XSLT Serialization Design SQLTypes XPath System Collections Configuration Diagnostics Globalization IO Net Reflection Resources Security ServiceProcess Text Threading Runtime InteropServices Remoting Serialization 217 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

12 9.2.5 Common Type System Typen sind sprachübergreifend eindeutig. Objektmodell Typen im Namespace System Object Value Type Type Enum Struct Boolean Char Int32... String Array Exception Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

13 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; } o y 5 5 System.Int Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

14 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

15 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

16 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 dem Namen auch den Key-Pair öffentlichen Schlüssel. Compiler Strong Name Schlüsselpaar erzeugen: - sn.exe k c:\outf - sn = strong name (utility). Main Manifest Quellen MyLib Manifest Ref.: MyLib PK=34e25c Compiler PK=34e25c Strong Name Signature 222 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

17 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: App.exe Calc.DLL - veschiedene Versionen einer DLL in einem Prozess gleichzeitig ladbar Ref-1: 22acab57 Calc.DLL Abschaffung der DLL-Hölle Anpassung der Bindung explizit durch eine 22acab57 CFG-Datei steuerbar z.b. client.exe.config Ref-2: AdvMath.DLL Lösung des DLL-Problems AdvMath.DLL Ref-1: (hier kein Versionsmanagement vorhanden). (private) ab8157 Culture-Attribute für Lokalisierung. Calc.DLL ab Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

18 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 Prozeß 2 AppDomain AppDomain AppDomain Objekt Objekt Objekt Objekt Objekt Marshaling 224 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

19 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

20 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" Channel Server Dispatcher 226 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

21 Channel & Formatter Channel: Wohin wird gesendet? - bidirekt. Kommunikation zw. 2 Endpunkten, TcpChannel, HttpChannel & SmtpChannel, - eigene Channels mögl. IChannel. - Adressierung Formatter: Datenformat MyObj - definiert Wire-Format (Channel-Protokoll). MyService Formate: MyObj StackBuilderSink - Soap über HTTP interoperabel, (URI:MyObj) - Binary über TCP schnell, HTTPChannel CLR AppDomain - eigene Formate möglich IFormatter, - wird vom Channel dynamisch angefordert. Winsock: Socket Serialisierung mithilfe der TCP: Metainformation im Assembly. User Prozeß BS Kern myhost.org 227 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

22 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

23 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 ersetzt werden, Klient Real-Proxy: - kann ersetzt werden, - für eigene Erweiterungen, - z.b. für Lastverteilung,... Proxy Transparent Proxy IMessageSink Channel Server mtha mthb varv Invoke SyncProcessMessage Real Proxy 229 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

24 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 Compiler Channels Object Sink Sink Sink Sink 230 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

25 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); } } RemotingConfiguration.RegisterWellKnownServiceType( typeof(serverobject), "myendpoint", WellKnownObjectMode.Singleton); Console.ReadLine(); 231 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

26 Klient: public class Client { } public static int Main(string [] args) { ServerObject factory; string EP=" factory = (ServerObject) RemotingServices.Connect(typeof(ServerObject), EP); factory.print("hallo"); } 232 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

27 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); } RemotingConfiguration.ApplicationName = myobj"; RemotingConfiguration.RegisterActivatedServiceType(typeof(ServerObject)); Console.ReadLine(); 233 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

28 Klient: public class Client { public static int Main(string [] args) { object[] attrs = new object[1]; Object[0] = new UrlAttribute(" 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

29 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

30 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

31 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 Aufruf Event Handler Server Parse Message Event Handler Antwort 237 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

32 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

33 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: - 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. 239 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

34 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: Mehr Infos: Architekturen für verteilte Internetdienste (F. Hauck). 240 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

35 9.3 Corba 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 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

36 9.3.2 Zielsetzung Verteilte objektbasierte Programmierung: - verteilte Objekte mit definierter Schnittstelle. Heterogenität in Verteilten Systemen: Obj Obj Obj - verschiedene Betriebssystem-Architekturen, - verschiedene Hardware-Architekturen, Middleware - verschiedene Programmiersprachen. Anbindung an Altsysteme (Legacy): - insbesondere C, Pascal und Visual Basic, - CORBA-Anwendungen sollen mit Altsystemen interagieren. OS OS OS OS 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

37 9.3.3 OMA - Object Management Architecture ORB als Softwarebus bzw. Komponentenbus : - Services: systemorientierte Dienste, - Facilities: anwendungsorientierte Dienste. Anwendungsobjekte Vertikale Vertikale Vertical Facilities Facilities Facilities Horizontal Facilities ORB CORBA Services 243 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

38 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

39 CORBA-Services Services bieten weitergehende systemorientierte Dienstleistungen an: - allgemein brauchbare und standardisierte Dienstleistungen, - Mit Objektschnittstelle und Methoden zum Aufruf, - ORB-Erweiterungen. Konkret zum Beispiel: - Namensdienst (zum Auffinden von Objekten), - Zeitdienst (zum Synchronisieren der Zeit), - Sicherheitsdienst (zur Zugriffskontrolle). - Concurrency, Transactions, - Licensing 245 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

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

41 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 Skeleton DSI Interface Repository DII IDL Stubs ORB Intf. Object Adapter GIOP / IIOP ORB Core Implementation Repository 247 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

42 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

43 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++: - 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

44 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

45 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

46 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

47 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

48 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

49 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

50 // 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

51 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

52 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

53 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

54 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

55 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 LocateRequest & LocateReply zum Auffinden eines Objektes, o Request & Reply für einen Methodenaufruf, o MessageError, Fragment, o CloseConnection, o 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

56 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 eindeutiger Objektbez.benutzt, - Nutzung von IIOP auch innerhalb des ORBs? IOR Repository ID Profile ID IIOP Version Host ID Profile Data POA Identifier Port number... Object Identifier Object Key Server spec. Components Next Profile 262 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

57 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: - 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 Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner

58 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

59 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, Verteilte Betriebssysteme, Winter 2005 Verteilet Systeme, Universität Ulm, M. Schöttner