6 Implementierung komplexer Systeme 6.1 Verteilte objektorientierte Systeme Analyse Entwurf Implementierung Test, Integration Wartung Literatur: Balzert Band 1, LE 29 T echnische 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 T echnische Universität Dresden Prof. Hußmann Seite 1 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) – 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: zusätzlich Plattform-Transparenz T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II 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 • Arten von Standards – “Offizielle” Gremien, z.B. ISO, ITU (relativ schwerfällig) – Firmen-“Standards”, z.B. Microsoft OLE/DCOM (proprietär) – Industriekonsortien, z.B. OMG (Mittelweg) • CORBA-Standard der OMG wird ISO-Standard – ISO 14750 (IDL), ISO 19500-2 (Interoperability) T echnische Universität Dresden Prof. Hußmann Seite 2 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...... T echnische 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) T echnische Universität Dresden Prof. Hußmann Seite 3 Softwaretechnologie II 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) T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II Generierung von Stubs und Skeletons SchnittstellenDefinition in IDL (statisch) IDL-Compiler Client-Code IDL stub (Code) Servant-Code IDL skeleton (Code) Übersetzen und Binden Übersetzen und Binden Client Servant stub skeleton ORB T echnische Universität Dresden Prof. Hußmann Seite 4 Softwaretechnologie II Proxy-Entwurfsmuster in CORBA Proxy Original ClientObjekt ServantObjekt Original Proxy Proxy Stub Skeleton Proxy Object Request Broker (ORB) T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II 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) Skeletons: Static Skeleton Interface (=SSI) T echnische Universität Dresden Prof. Hußmann Seite 5 DII = Dynamic Invocation Interface DSI = Dynamic Skeleton Interface 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 T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II 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 Java-Interface (umfaßt aber auch ö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 T echnische Universität Dresden Prof. Hußmann Seite 6 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 CORBA Objektreferenz Value-Typ (Objekte als Werte) T echnische Universität Dresden – – – – – – Verbunde (struct) Vereinigung Aufzählung Sequenzen Strings Felder 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 T echnische Universität Dresden Prof. Hußmann Seite 7 Softwaretechnologie II 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, PL/1, Lisp, Python, 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 • CORBA-Implementierungen: – – – – JacORB (frei, im Balzert-Buch benutzt) Borland VisiBroker (für Vorlesungsbeispiele benutzt) IONA Orbix ... und viele andere T echnische 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 Helper- und Holder Klassen in Java » Operationen auf Methoden T echnische Universität Dresden Prof. Hußmann Seite 8 Softwaretechnologie II Java-Bindung: Beispiel // Person.java package BeispielModul; public interface Person extends org.omg.CORBA.Object, BeispielModul.PersonOperations, org.omg.CORBA.portable.IDLEntity {} // PersonOperation.java package BeispielModul; public interface PersonOperations { public java.lang.String name (); public void name (java.lang.String name); public java.lang.String vorname (); public int geburtsjahr (); public BeispielModul.Adresse anschrift (); public void anschrift (BeispielModul.Adresse anschrift); public BeispielModul.Person[] Bekannte (); public void Bekannte (BeispielModul.Person[] Bekannte); public int berechneLebensjahre (int aktJahr); public void berechneLebensjahreP (int aktJahr, org.omg.CORBA.IntHolder lebensJahre); } T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II 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(); }; T echnische Universität Dresden Prof. Hußmann Seite 9 Softwaretechnologie II Zähler-Beispiel: Stubs/Skeletons erzeugen Kommandos: idl2java Counter.idl idl2java CounterFactory.idl Erzeugte Dateien (u.a.): <IDL-Schnittstelle>.java <IDL-Schnittstelle>Operations.java <IDL-Schnittstelle>Helper.java <IDL-Schnittstelle>Holder.java Java-Interface Signaturen d. Operationen Nützliche Hilfsoperationen Hilfsklasse für Parameter _<IDL-Schnittstelle>Stub.java <IDL-Schnittstelle>POA.java <IDL-Schnittstelle>POATie.java Stub-Code Skeleton-Code für POA Objektimpl. f. Tie-Ansatz T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II Zähler: Java-Schnittstelle // Counter.java public interface Counter extends org.omg.CORBA.Object, CounterOperations, org.omg.CORBA.portable.IDLEntity { } // CounterOperations.java public interface CounterOperations { public public public public void count (); void countn (int n); int getcount (); void getcountp (org.omg.CORBA.IntHolder count); } T echnische Universität Dresden Prof. Hußmann Seite 10 Softwaretechnologie II Zähler: "Holder"-Klasse // CounterHolder public final class CounterHolder implements org.omg.CORBA.portable.Streamable { public Counter value; public CounterHolder (final Counter _value) { this.value = _value; } ... } } T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II Zähler: "Helper"-Klasse // CounterHelper.java public final class CounterHelper { // Typanpassung (Cast) - sprachunabhängig! public static Counter narrow (final org.omg.CORBA.Object obj) {...} ... // proprietärer einfacher Namensdienst //(Beispiel gemäß VisiBroker, meist ähnlich in anderen // Implementierungen) public static Counter bind (org.omg.CORBA.ORB orb, java.lang.String name) {...} // weitere Methoden } T echnische Universität Dresden Prof. Hußmann Seite 11 Softwaretechnologie II Zähler: Servant-Implementierung // CounterImpl.java public class CounterImpl extends CounterPOA { private int counter=0; 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; } } T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II Zähler: Server-Implementierung (vereinfacht) // Server.java import org.omg.PortableServer.*; import org.omg.CORBA.ORB; import org.omg.CORBA.Policy; public class Server { public static void main (String args[]) { ORB orb=ORB.init(args,null); POA rootPOA=POAHelper.narrow (orb.resolve_initial_references("RootPOA")); POA myPOA=rootPOA.create_POA ("counter_factory_poa",rootPOA.the_POAManager()); CounterFactoryImpl cfImpl=new CounterFactoryImpl(myPOA); myPOA.activate_object(cfImpl); rootPOA.the_POAManager().activate(); System.out.println (myPOA.servant_to_reference(cfImpl)+" ist bereit."); orb.run(); } } T echnische Universität Dresden Prof. Hußmann Seite 12 Softwaretechnologie II Zähler: Client-Implementierung // Client.java import org.omg.CORBA.ORB; public class Client { public static void main (String args[]) { ORB orb=ORB.init(args,null); //proprietärer Namensdienst CounterFactory cf=CounterFactoryHelper.bind (orb,"CounterFactory"); Counter c=cf.createCounter(); System.out.println(c+"\n"); System.out.println("\n"+c.getcount()); c.count(); System.out.println("\n"+c.getcount()); c.countn(5); System.out.println("\n"+c.getcount()); } } T echnische 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) T echnische Universität Dresden Prof. Hußmann Seite 13 Softwaretechnologie II Interaktion von ORBs Client ORB A Servant KommunikationsNetz ORB B • General Inter-ORB Protocol (GIOP) – – – – Common Data Representation (CDR) für IDL-Datentypen Interoperable Object References (IOR) Internet Inter-ORB Protocol (IIOP) (= GIOP über TCP/IP) Weitere GIOP-Realisierungen (z.B. mit der CORBA-Implementierung TAO geliefert): » z.B. SSLIOP (IOP über Secure Socket Layer) » z.B. SHMIOP (IOP über shared memory) • ORB/ORB-Brücken mit DSI und DII T echnische 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) T echnische Universität Dresden Prof. Hußmann Seite 14 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). – Zusätzliche Funktionen zur Unterstützung von E/A, z.B. für Namen als Strings und URLs (Schnittstelle: NamingContextExt) – Durchsuchen von Namensräumen (Schnittstelle: BindingIterator) • Notwendige Komponenten: ClientObjekt ServantObjekt Object Request Broker (ORB) - Objektbus Name Server T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II CORBA Service: Naming Service (2) • Beispiel für Interaktion Servant-Objekt und Name Server: cfImpl : Counter FactoryImpl : Server : ORB nc: NamingContextExt resolve_initial_references ("NameService") bind_new_context(...) // falls Kontext nicht existiert name=to_name(“de/tud/factories/CounterFactory“) name : Name bind(name,myPOA.servant_to_reference(cfImpl)) T echnische Universität Dresden Prof. Hußmann Seite 15 Softwaretechnologie II CORBA Service: Naming Service (3) • Beispiel für Interaktion Client-Objekt und Name Server: : Client : ORB nc : NamingContextExt cf : Counter Factory resolve_initial_references ("NameService") resolve_str(“de/tud/factories/CounterFactory“) cf createCounter() T echnische Universität Dresden Prof. Hußmann Softwaretechnologie II Evolution von CORBA • 1991-92: CORBA Core 1.0 und 1.1, verbessert in 1.2 (1993) – Objektmodell, IDL, DII, C-Mapping, BOA • 1996: CORBA 2.0 – DSI, Interoperability-Architektur (IIOP etc.), C++- und SmalltalkMapping, Interworking mit OLE/DCOM • 1997-2002: Schrittweise Erweiterungen (CORBA 2.1-2.6), alle Erweiterungen zusammen werden "CORBA 3" genannt (2002) – – – – – – – – – Weitere Sprachabbildungen, insb. IDL-Java und Java-IDL (1998) Portable Object Adapter (POA) Weitere Kommunikationsarten (Callback, Polling) "Objects by Value" (valuetype) Interoperabler Namensdienst ("corbaloc:www.omg.org/NameService") Quality of Service/Policies (Prioritäten, Fristen, Lebenszeiten) Real-Time CORBA CORBAcomponents siehe: www.omg.org unter "Technology Central" T echnische Universität Dresden Prof. Hußmann Seite 16 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 – Extrem hohe Komplexität in neueren Versionen – Speziellere Ansätze bleiben attraktiv » Microsoft COM+ und .NET » Java-Technologien, z.B. RMI, JNDI, JDO, EJB – Völlige Transparenz nicht immer erwünscht T echnische Universität Dresden Prof. Hußmann Seite 17 Softwaretechnologie II