Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,

Präsentation zum Thema: "Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,"—  Präsentation transkript:

1 Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle, akademische) 2. Industrielle Komponentensysteme der 1. Generation 1. CORBA 2. (D)COM 3. Enterprise JavaBeans 3. Anpassungsprobleme –Daten und Funktion –Interaktion Kommunikation Synchronisation Protokolle –Lebendigkeit

2 Dr. Welf Löwe und Markus Noga2 Aufgaben kommerzieller Systeme (Corba, (D)COM, EJB) Daten- und Interface-Beschreibung Referenz- und Wertesemantik Kommunikation (Nachrichten und RMI) Verteilung, Persistenz, Heterogenität Softwarebus

3 Dr. Welf Löwe und Markus Noga3 Gliederung Literatur, Ziele, Bestandteile Basis-Mechanismen für –Kommunikation, –modulare Austauschbarkeit, –Adaption Mechanismen zur Standardisierung von Schnittstellen (Services, Facilities) Selbstbeschreibung (Metaobjekte, MOF) Corba und das Web Austauschformat XMI

4 Dr. Welf Löwe und Markus Noga4 I.2.1.1 Corba Grundlagen R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. Wiley&Sons. Leicht zu lesen. R. Orfali, D. Harkey, J. Edwards: Instant Corba. Addison-Wesly. Deutsch. Leicht zu lesen, aber einige konzeptionelle Übersetzungsfehler CORBA. Communications of the ACM, Oct. 1998. Neueste Corba- Entwicklungen. Jens-Peter Redlich, CORBA 2.0 / Praktische Einführung für C++ und Java. Verlag: Addison-Wesley, 1996. ISBN: 3-8273-1060-1, 59.90DM Corba 2.2 Specification. OMG. http://www.omg.org Vorträge aus dem Web: –Von der OMG: Java Portability and CORBA Integration, Dr. Richard Soley, CEO, OMG, April, 1999 Application Server Market Summary. Paul Harmon, Editor, Component Development Strategies Newsletter

5 Dr. Welf Löwe und Markus Noga5 Corba Common Object Request Broker Architecture Gründung der OMG (object management group) 1989. Ziel: plug-and- play components everywhere When the Object Management Group (OMG) was formed in 1989, interoperability was its founders primary, and almost their sole, objective: A vision of software components working smoothly together, without regard to details of any component's location, platform, operating system, programming language, or network hardware and software. Jon Siegel Corba 1.1 1991 (IDL, ORB, BOA) ODMG-93 (Standard für oo-Datenbanken) Corba 2.0 1995, heute 2.2 Corba 3.0 1999

6 Dr. Welf Löwe und Markus Noga6 Ziel: Standardisierte Dienste für Anwendungen Interoperabilität (Interoperability Services) –Gemischtsprachlichkeit (Multi Language System) –Architekturunabhängigkeit (Multi Platform) –Dienstgeber-Transparenz –Internetzdienste (Internet/Web Services) Domänenspezifische, anwendungsorientierte Spezifikationen (Domain Specifications) –Für Medizin, Finanzwirtschaft, Maschinenbau, etc. –Geschichtete Dienste (layered services) Portabilitätsdienst (Portability Services)

7 Dr. Welf Löwe und Markus Noga7 Bestandteile von Corba Basisdienste (Verdrahtungsstandard) –Transparente Verteilung (fast), transparente Plattform Entfernter Methodenaufruf Verallgemeinerter Methodenaufruf durch Dienstvermittlung (Request Broking (ORB, DII) Proxies –Gemischsprachlichkeit durch einheitliche Schnittstellenbeschreibung (IDL) –Transparente (Netz-)Protokolle –Codevererbung Object management Architecture OMA –CorbaServices –CorbaFeatures (horizontal vs. vertikal) –Selbstbeschreibung (metaobject facility)

8 Dr. Welf Löwe und Markus Noga8 Bestandteile von Corba Geschäfts objecte (business objects) Erweiterte Interoperabilität DII, Trading Komponenten CorbaBeans Scriptsprachen MOF (reflection) Services Protokolle GIOP IIOP Facilities Basisdienste Interoperabilität IDL, RPC, ORB

9 Dr. Welf Löwe und Markus Noga9 Die OMA (object management architecture) Object Request Broker Object Services Application Interfaces Domain InterfacesCommon Facilities

10 Dr. Welf Löwe und Markus Noga10 Die OMA (object management architecture) Object Request Broker (ORB, Corba) –Management für verteilte Objekte –Kommunikation zwischen Objekten General Service Interfaces (Object Services) –Objekterzeugung, -zugriff, -verschiebung (relocation) –Generische Laufzeitumgebung für Objekte Common Facilities (Corba Facilities) –Standarddienste: Druckdienste, Datenbankzugriff, e-mail etc. Non-Standard Application Specific Interfaces –Anbieterspezifische Dienste –Nicht standardisiert durch die OMG Vertical Domain Specific Interface –Kombinieren Object Services und Common Facilities –Markt- oder Industriespezifische Dienste

11 Dr. Welf Löwe und Markus Noga11 ORB Client Server/Object Implementation Object Adapter Dynamic Invocation IDL Stub ORB Interface IDL Skeleton Dynamic Skeleton ORB Kern ORB-abhängig Standardisiert Objekttyp-abhängig

12 Dr. Welf Löwe und Markus Noga12 ORB Verfeinerte Sicht

13 Dr. Welf Löwe und Markus Noga13 Mechanismen für modulare Austauschbarkeit IDL (interface definition language), die Schnittstellenbeschreibungssprache (ISO 14750), schildert Schnittstellen –Gemischtsprachlichkeit: Es existieren Sprachanbindungen für etliche Sprachen, auch alte wie COBOL –Verteilung: Aus IDL wird Code generiert, der auf dem Netz kommunizieren hilft (marshalling, demarshalling) Statischer Methodenaufruf mittels statischen Rümpfen und Skeletten (stubs and skeletons): Aus IDL generiert man auch Stellvertreterobjekte (Entwurfsmuster proxy) Request Broking (request binding) und dynamic invocation interface DII: Neben normaler Polymorphie kennt Corba das dynamische Suchen eines Services, das transparente Erwecken eines Dienstes Interoperable Object Reference (IOR): Objekte und Komponenten erhalten eindeutige IORs

14 Dr. Welf Löwe und Markus Noga14 Interface Definition Language Module { // Klassen interface : { // Methoden optype ( ) {... }.... } Typen Ints (short,..) Konstruktoren Basistypen Nicht-Objekte Objekte Reals (float..) Struct Char, string, Union Sequence Array octet Enum Bool Any Referenz- Objekte Referenz- Objekte Wertobjekte

15 Dr. Welf Löwe und Markus Noga15 Ablauf IDL-Codegenerierung IDL Interface Client Implementation Client Implementation Server Implementation Server Implementation Compiler IDL- Compiler IDL- Compiler Server Skeleton Server Skeleton Client Stub Client Stub Client Implementation Repository Objektadapter/ BOA Server

16 Dr. Welf Löwe und Markus Noga16 Der (Basis-)Objektadapter BOA Gaukelt dem Klienten ein ständig lebendes Objekt vor. Kapselt –Aktivierung (Start, Stop), –Persistenzaspekte Muss in jedem ORB vorhanden sein, um einen minimalen Service zu gewährleisten Verwaltet das Implementation Repository (Registry). Unterstützt auch nicht-oo Code Aufgerufen von Client (über ORB Kern) und Server (direkt) CORBA::BOA - Create - change_implementation - get_id - dispose - set_exception - impl_is_ready - obj_is_ready - deactivate_impl - deactivate_obj

17 Dr. Welf Löwe und Markus Noga17 Serverseite BOA IDL Skeleton ORB Kern Server / Object Implementation deactivate_ obj deactivate_ impl impl_is_ ready object_is_ ready

18 Dr. Welf Löwe und Markus Noga18 Servermodelle Gemeinsamer Serverprozess (Shared-Server) –mehrere Objekte in einem Prozess auf dem Server; –BOA initialisiert sie als nebenläufige Fäden (threads) mit gemeinsamen Adressraum (gemeinsames Apartment) –BOA Funktionen deactivate_impl, impl_is_ready, obj_is_ready abgebildet auf thread-Funktionen Separater Serverprozess (Unshared-Server) –Hier wird für jedes Objekt ein eigener Prozess auf dem Server verwaltet. Methoden-Prozess (Server-per-Method) –Jeder Methodenaufruf erzeugt einen neuen Prozess. Persistenter Server –Hier startet eine andere Anwendung die Objekte (z.B. Eine Datenbank). –BOA reicht die Anfragen nur durch.

19 Dr. Welf Löwe und Markus Noga19 Objektaktivierung auf dem Server ServerObjekt1Objekt2CORBA::BOA Create get_id obj_is_ready Impl_is_ready deactivate_obj deactivate_impl

20 Dr. Welf Löwe und Markus Noga20 Statische Aufträge (Methodenaufrufe) Methoden der Teilnehmer sind statisch bekannt. –Aufruf durch Stummel und Skelette, –Keine Suche nach Diensten (im Repository), –Keine Suche nach Serviceobjekten, –Schnell Statische Typprüfung durch Übersetzer möglich Da der Aufruf an die Skelette durch den Objekt-Adapter geht, erscheint dem Klienten das Serverobjekt durchgängig lebendig (Transparentes Leben)

21 Dr. Welf Löwe und Markus Noga21 Dynamischer Aufruf (Request Broking) Dynamischer Aufruf (dynamische Abfrage) –Komponenten dynamisch ausgetauscht oder nachträglich eingebracht –Neuübersetzung entfällt –Beispiel: Plugins für Browser, Zeichenprogramme etc. Beschreibung der Komponentensemantik zur Suche –Object Interface –Informationen Metadaten (beschreibende Daten) Schnittstellendaten Verzeichnisse von Komponenten (interface repository, implementation repository) Such-Vermittler - ORB interface

22 Dr. Welf Löwe und Markus Noga22 Das Corba-Objekt Das Corba Objekt vererbt sich als Klasse auf alle Corba-Objekte und Programmelemente. get_interface liefert eine Referenz auf den Eintrag im interface repository. get_implementation eine Referenz auf die Implementierung CORBA::Object - get_implementation - get_interface - is_nil - create_request - is_a - duplicate - release -....

23 Dr. Welf Löwe und Markus Noga23 Der Objektanfragen-Vermittler ORB Der ORB ist ein Vermittler (Entwurfsmuster) zwischen Client und Server. Er verbirgt die Umgebung vor dem Klienten. Er sucht für dynamische Aufrufe Dienstgeber. Er kann andere ORBs ansprechen, insbesondere solche auf dem Web. CORBA::ORB - object_to_string - string_to_object - create_list - create_operation_list - get_default_context - create_environment - BOA_init - list_initial_services - resolve_initial_references -....

24 Dr. Welf Löwe und Markus Noga24 ORB-Aktivierung auf dem Klienten ObjektCORBAORB ORB_init BOA_init List_initial_services resolve_initial_references Liefert Strings Liefert Objektreferenzen Initialisiert den Server-BOA Initialisiert den Vermittler

25 Dr. Welf Löwe und Markus Noga25 Beispiel IDL //TestTimeServer.idl module TestTimeServer{ interface ObjTimeServer{ string getTime(); };

26 Dr. Welf Löwe und Markus Noga26 Beispiel fortgesetzt: Service Implementierung //TestTimeServerImpl.java import CORBA.*; class ObjTestTimeServerImpl extends TestTimeServer.ObjTimeServer_Skeleton //generated from IDL { //Variables //Constructor //Method (Service) Implementation public String getTime() throws CORBA.SystemException{ return Time: +currentTime; } };

27 Dr. Welf Löwe und Markus Noga27 Server Implementierung // TimeServer_Server.java import CORBA.*; public class TimeServer_Server{ public static void main(String[] argv){ try{ CORBA.ORB orb = CORBA.ORB.init(); … ObjTestTimeServerImpl obj = new ObjTestTimeServerImpl(…); … System.out.println(orb.object_to_string(obj)); } catch (CORBA.SystemException e){ System.err.println(e); } };

28 Dr. Welf Löwe und Markus Noga28 Client Implementierung //TimeServer_Client.java import CORBA.*; public class TimeServer_Client{ public static void main(String[] argv){ try{ CORBA.ORB orb= CORBA.ORB.init(); … CORBA.object obj = orb.string_to_object(argv[0]); … TestTimeServer.ObjTimeServer timeServer= TestTimeServerImpl.ObjTimeServer_var.narrow(obj); … System.out.println(timeServer.getTime()); } catch (CORBA.SystemException e){ System.err.println(e); } };

29 Dr. Welf Löwe und Markus Noga29 Beispielausführung C:\> java TimeServer_Server IOR:00000000000122342435 … C:\> java TimeServer_Client IOR:00000000000122342435 … Time: 14:35:44

30 Dr. Welf Löwe und Markus Noga30 IOR (interoperable object reference) Verbirgt Objektreferenzen der Programmiersprachen, ist pro Programmiersprache eindeutig abgebildet (für alle ORBs) transient (verschwindet mit Server) oder persistent (lebt weiter). Bestandteile: –Typnamen (type code), d.h. Indices in das Interface Repository –Protokoll und Adressinformation (z.B. beim IIOP TCP/IP port #, host name), auch für verschiedene zugleich unterstützte Protokolle –Objektschlüssel (object key). Opaques Datum, nur vom erzeugenden ORB lesbar (Zeiger) Object-Adaptername (für den BOA), Objectname Type Name (repository id) Type Name (repository id) Protokoll u. Adresse Protokoll u. Adresse Objekt- Schlüssel Objekt- Schlüssel

31 Dr. Welf Löwe und Markus Noga31 Beispiel: IOR IDL:My Obj:1.0 IDL:My Obj:1.0 Bobo: 1805 Bobo: 1805 OA4, obj_999 OA4, obj_999 Obj_997 Obj_999 Obj_998 OA4 ClientServer

32 Dr. Welf Löwe und Markus Noga32 I.2.1.2 Corba Dienste (Corba services) OMG. CORBAservices: Common Object Service Specifications. http://www.omg.org. Version vom Dez. 98.http://www.omg.org

33 Dr. Welf Löwe und Markus Noga33 Bestandteile von Corba Geschäfts objecte (business objects) Erweiterte Interoperabilität DII, Trading Komponenten CorbaBeans Scriptsprachen MOF (reflection) Services Protokolle GIOP IIOP Facilities Basisdienste Interoperabilität IDL, RPC, ORB

34 Dr. Welf Löwe und Markus Noga34 Überblick Corba Dienste (Services) 16+ standardisierte Dienstschnittstellen (in IDL definiert). Implementierungsstand je nach Anbieter http://www.cetus-links.org/oo_object_request_brokers.html http://www.cetus-links.org/oo_object_request_brokers.html Einteilbar in –Objektdienste: Dienste zur Verwaltung von Objekten (d.h. Komponenten im CORBA-Sinn) –Zusammenarbeitsdienste: Dienste, die Zusammenarbeit von Objekten betreffen –Geschäftsprozessdienste: Dienste, die stärker in Richtung Anwendung definiert sind und vorgefertigte Funktionalitäten für Geschäftsanwendungen bereitstellen.

35 Dr. Welf Löwe und Markus Noga35 Objektdienste Namen (directory service) –Das Dateisystem (directory tree) ist i.W. ein Namensdienst. –Auf beliebige Internet-Objekte ausdehnbar. Allokation (lifecycle service) –keine Semantik bei Deallocation –keine Destruktoren Eigenschaften für Objekte (property service) Persistenz –Objektzustand bleibt über Programmaufrufe erhalten Serialisierung in Ströme (externalization) Relationen (relationship service) –Relationen, Rollen, Kanten sind Objekte –Standardrelationen reference, containment –Standardrollen references, referenced; contains, containedIn Container (collections)

36 Dr. Welf Löwe und Markus Noga36 Zusammenarbeitsdienste Kommunikation –Rückrufservice (callbacks) –Ereignisse über entsprechende Kanäle –Typen von Kanälen Schub-Modell (push model): die Komponenten stopfen Ereignisse in den Ereigniskanal Zug-Modell (pull model): die Komponenten warten am Ereigniskanal und entnehmen selbsttätig Parallelität –Sperren (concurreny service) Sperren, Sperrenmengen, in Transaktionsmodus oder ohne Transaktionen –Transaktionen (object transaction service, OTS) Flache und ev. geschachtelte Transaktionen über Objektgraphen.

37 Dr. Welf Löwe und Markus Noga37 Geschäftsprozessdienste Makler (Händler, Trading service) –Gelbe Seiten –Lokalisierung von Diensten mittels Dienstbeschreibungen Abfrage (Query) –Suchen von Objekten mit Attributen und der OQL, SQL (ODMG-93) Lizensierung –License managers, licence service Sicherheit –Einsatz von SSL und anderen Basisdiensten. –Alle ORBs arbeiten zusammen.

38 Dr. Welf Löwe und Markus Noga38 Abhängigkeiten zwischen den Diensten Namen Allokation Relationen PersistenzSerialisierung Sperren Transaktionen Query Makler Eigenschaften Sicherheit Ereignisse Lizenzen Container Rückruf

39 Dr. Welf Löwe und Markus Noga39 Entwurfsprinzipien Die Qualität eines Dienstes (schnell, langsam, zuverlässig,..) ist implementierungsabhängig, aber die Schnittstelle ist genormt. Dienste sind orthogonal zueinander –Selbstanspruch des Standards –KISS (keep it simple, stupid) Alle Schnittstellen sind auf CORBA::Object definiert –Prinzipiell können alle Objekttypen übergeben werden. –IDLs schränken evtl. ein. –Reflektion - dynamisch kann der Typ eines Objektes abgefragt werden Verschiedene Sichten auf einen Dienst Prinzipien für Schnittstellendefinition –Ausnahmebehandlung wird benutzt. –Operationen sind explizit, d.h., nicht durch Flags parametrisiert. –Schnittstellen können mehrfach vererbt werden.

40 Dr. Welf Löwe und Markus Noga40 Objektdienste: Namen Binden eines Namens an ein Objekt in einem Namensraum (scope, naming context). –Ein Namensraum ist ein Objekt, das eine Menge von Bindungen enthält. Sie können sich gegenseitig referenzieren und so Namensgraphen aufbauen –Namen sind Pseudoobjekte, um schnell bearbeitet werden zu können Eigenes Namensschema, –Verwendet nicht Betriebssystems- oder URL-Konventionen. –Dadurch Transparenz der Implementierung des Namens. –Zur Manipulation von Namen existiert eine eigene Bibliothek (Entwurfsmuster Fabrik). –Ein Name besteht aus einem Tupel: Id, Type Id: eigentlicher Name, das Art: Repräsentation (z.B. c_source, object_code, executable, postscript,..). wird nicht vom Namensdienst, sondern nur von der Anwendung manipuliert. Ein Dateisystem bildet ein einfachen Namensraum.

41 Dr. Welf Löwe und Markus Noga41 Namensdienst - bind(in Name n, in Object obj) - rebind(in Name n, in Object obj) - bind_context - rebind_context - Object resolve - unbind(in Name n) - NamingContext new_context; - NamingContext bind_new_context(in Name n) - void destroy - list CosNaming::NamingContext

42 Dr. Welf Löwe und Markus Noga42 IDL Namensdienst module CosNaming{ typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence Name; enum BindingType { nobject, ncontext }; struct Binding { Name binding_name; BindingType binding_type; }; typedef sequence BindingList; interface BindingIterator; interface NamingContext; } interface NamingContext { enum NotFoundReason { missing_node, not_context, not_object }; exception NotFound { NotFoundReason why; Name rest_of_name; }; exception CannotProceed { NamingContext cxt; Name rest_of_name; }; exception InvalidName {}; exception AlreadyBound {}; exception NotEmpty {}; interface BindingIterator { boolean next_one(out Binding b); boolean next_n(in unsigned long how_many, out BindingList bl); void destroy(); };

43 Dr. Welf Löwe und Markus Noga43 IDL Namensdienst void bind(in Name n, in Object obj) raises( NotFound, CannotProceed, InvalidName, AlreadyBound ); void rebind(in Name n, in Object obj) raises( NotFound, CannotProceed, InvalidName ); void bind_context(in Name n, in NamingContext nc) raises( NotFound, CannotProceed, InvalidName, AlreadyBound ); void rebind_context(in Name n, in NamingContext nc) raises( NotFound, CannotProceed, InvalidName ); Object resolve(in Name n) raises( NotFound, CannotProceed, InvalidName ); void unbind(in Name n) raises( NotFound, CannotProceed, InvalidName ); NamingContext new_context(); NamingContext bind_new_context(in Name n) raises( NotFound, AlreadyBound, CannotProceed, InvalidName ); void destroy() raises( NotEmpty ); void list(in unsigned long how_many, out BindingList bl, out BindingIterator bi ); };

44 Dr. Welf Löwe und Markus Noga44 Bindung Suche/Erzeuge Namensraum Erzeugen von Namen Systemabhängiger Name Corba-Name Suche Name Namensraum Erzeuge Name Objekt

45 Dr. Welf Löwe und Markus Noga45 Namensdienst: Beispiel // Quelle: Redlich import java.io.*; import java.awt.*; import IE.Iona.Orbix2.CORBA.SystemException; import CosNaming.NamingContext; import CosNaming.NamingContext.*; import Calc5.calc.complex; class MyNaming extends CosNaming {... } public class client extends Frame { private Calc5.calc.Ref calc; private TextField inR, inI; private Button setB, addB, multB, divB, quitB, zeroB; public static void main(String argv[]) { CosNaming.NamingContext.Ref cxt; Calc5.calc_factory.Ref cf; Frame f; try { cxt= NamingContext._narrow( MyNaming. resolve_initial_references(MyNaming.NameService)); cf= Calc5.calc_factory._narrow( cxt.resolve(MyNaming.mk_name("calcfac"))); f= new client(cf.create_new_calc()); f.pack(); f.show(); } catch (Exception ex) { System.out.println("Calc-5/Init:" + ex.toString()); }

46 Dr. Welf Löwe und Markus Noga46 Naming import java.io.*; import IE.Iona.Orbix2.*; import IE.Iona.Orbix2.CORBA.*; import CosNaming.*; public class MyNaming { public static final String NameService = "NameService"; public static IE.Iona.Orbix2.CORBA.Object.Ref resolve_initial_references(String id) { ORB orb = _CORBA.Orbix; if (id.compareTo(NameService)!=0) return NamingContext._nil(); try { File inputFile = new File("/tmp/coss-naming/root"); FileInputStream fis = new FileInputStream(inputFile); DataInputStream dis = new DataInputStream(fis);... return orb.string_to_object(obj_ref); } catch (Exception ex) { System.out.println("CosNaming:Init:" + ex.toString()); } return NamingContext._nil(); } public static Name mk_name(String str) { int last, k, i= 0;... return name; }

47 Dr. Welf Löwe und Markus Noga47 Objektdienste: Eigenschaftsdienst Eigenschaften (properties) sind Strings Dienst verwaltet Listen von Eigenschaften für Objekte Konzept bekannt als assoziative Arrays, LISP property lists, Java property classes Dynamisch erweiterbar Iteratoren für Eigenschaftswerte PropertySetDef als verfeinerte Klasse, die den Eigenschaften mehr semantische Bedeutung zuordnet: readonly, fixed_readonly, … Schnittstelle: define_property, define_properties, get_property_value, get_properties, delete_property,...

48 Dr. Welf Löwe und Markus Noga48 Objektdienste: Persistenz Dienst –Persistentes (Server) Objekt über IOR kennt einen Persistent Object Identifier PID, –Identifiziert serialisierten Zustand eines CORBA-Objektes auf dem Speichermedium. –Protokoll zum Abspeichern/Laden auf/von Sekundärspeicher Operationen connect, disconnect, store, restore, delete Anbindung von beliebigen Speicherwerkzeugen möglich –Relationale Datenbanken –Filesystem

49 Dr. Welf Löwe und Markus Noga49 Zusammenarbeitsdienste: Ereignisse Schnittstellen: –PushConsumer/PushSupplier: Objekt legt Ereignis ab, Ereignis wird automatisch ausgeliefert. –PullSupplier/PullConsumer: Objekt wartet auf Ereignis, Synchrones und Asynchrones Warten ist möglich. Ereigniskanal-Objekte als mögliche Zwischeninstanzen –puffern, vermitteln, replizieren, filtern Ereignisse –bilden push- und pull model aufeinander ab. Typisierung mit IDL möglich (Zugriff über separate Schnittstelle) Vorteile: –Asynchrones Arbeiten im Web möglich (mit IIOP und dynamischem Aufruf) –Anbindung beliebiger Systeme: Java (einfach seit 1.2), Altsysteme... Nachteile: –Schnittstelle recht allgemein, –Unterschied typisierte, nicht typisierte Ereignisse ist ärgerlich

50 Dr. Welf Löwe und Markus Noga50 Zusammenarbeitsdienste: Transaktionen Standard-Datenbanktechnik –Einfach: begin_ta, rollback, commit (2pc). –Geschachtelt: begin_subtransaction, rolback_subtransaction, commit_subtransaction Beispiele –Konten als Objekte. Überweisung (Abheben, Einzahlen) als Transaktion über den Objekten mehrerer Banken. –Paralleles Erneuern von Webseiten-Geflechten: Wie macht man sie konsistent? Noch nicht implementiert!

51 Dr. Welf Löwe und Markus Noga51 Geschäftsprozessdienste: Lizenzen Kommerzielle Komponenten: gekauft, gemietet, geleast, ersteigert Abstrakte Fabrik für Lizenzmanager, –die für beliebige Komponenten herstellerabhängige Strategien liefert. –Beispiele: Einzelplatzlizenzen, übertragbare Lizenzen (floating licenses), Netzwerklizenzen, Campuslizenzen, etc. –Flexibel, über die Zeit veränderbar –Anwendung nicht verändert. –Feingranular Granularität der Lizenzen: –Lizenzen durch ORB-Anfragen bezahlt. –kleine Komponenten Geld zu verlangen und quasi automatisch zu bezahlen. –Kommerzielle, private Nutzung kann automatisch unterschieden werden.

52 Dr. Welf Löwe und Markus Noga52 Lizenz-Szenario Kunde Cos:: License Manager Hersteller abhängiger Lizenzdienst Hersteller- strategie Lizenzsystem (auch entfernt) Abstrakte Fabrik Konkreter Dienst Hole Lizenzdienst Liefere Lizenzdienst Hole Lizenz Liefere Lizenz

53 Dr. Welf Löwe und Markus Noga53 Schnittstelle LicenseServiceManager –obtain_specific_license_service SpecificLicenseService –start_use –check_use –end_use

54 Dr. Welf Löwe und Markus Noga54 Lizenzprotokoll Kunde Licence service manager Producer specific license service License manager Event service obtain_producer_ specific_license Start_use Initial check_use Inquiry Ask for event Event notification (license there) check_use End_use

55 Dr. Welf Löwe und Markus Noga55 Geschäftsprozessdienste: Makler Makler Kunde Dienst Vermittlermuster Interagiere Importiere Funktionalität Exportiere Funktionalität Makler handeln mit Diensten (services, service types)

56 Dr. Welf Löwe und Markus Noga56 Wann ein Dienst gegen anderen ersetzen (Konformität)? gleiche Schnittstelle oder abgeleitete Schnittstelle alle Sucheigenschaften identisch definiert –keine Properties vom Corba Dienst Properties alle Modi der Eigenschaften stärker oder gleich (normal) Mandatory, readonly Mandatoryreadonly

57 Dr. Welf Löwe und Markus Noga57 Dienstangebote für Makler Dienstangebot: Paar aus IOR und Eigenschaften Eigenschaften –von Maklern genutzt für Anfragen nach Diensten –Dynamische Eigenschaften (!) Zum Vergleich spezielle Anfragesprache (standard constraint language) –boolesche Ausdrücke über Eigenschaften –numerische und Stringvergleiche Findet ein Makler keinen passenden Dienst –kann er einen Nachbarmakler beauftragen (Entwurfsmuster Zuständigkeitskette, chain of responsibility). –Dazu ist ein Graph aus Maklern aufgebaut –Filtern beim Weitergeben der Dienstsuchanfrage

58 Dr. Welf Löwe und Markus Noga58 Makler 4 Makler 1 Dienst-Hüpfen (hopping) Makler 1 Makler 3 Makler 2 Policies, die die Werte der Eigenschaften der Dienstanfrage verändern Fluß der Eigenschaften der Dienstanfrage Angebote der Makler

59 Dr. Welf Löwe und Markus Noga59 Suche nach Diensten Parametrisierung von Maklern und Links durch sog. policies. policies beeinflussen verschiedene Phasen von Suche und Weitergabe, z.B. –max_search_card: Obergrenze für zu suchende Angebote –max_match_card: Obergrenze für Rückgabe passender Angebote –max_hop_count: Obergrenze für Suchtiefe über Makler Mögliche Angebote Mögliche Angebote Mögliche Angebote Gefundene Angebote Betrachtete Angebote Kardinalitäten für Suche Kardinalitäten für Matchen Kardinalitäten für Rückgabe

60 Dr. Welf Löwe und Markus Noga60 Schnittstellen Makler Schnittstellen –Lookup (Anfragen stellen) –Offer Iterator –Register (zum Export und Zurückziehen von Diensten) –Link (Aufbau des Maklernetzes) –Proxy (Stellvertreter-Objekte, die Makler vertreten) Dienst stellvertretend für einen anderen Makler angeboten Dient zur Kapselung von Altsystemen. –Admin (Eigenschaften von Dienste) Lookup.Query( in ServiceTypeName,in Constraint, in PolicySeq, in SpecifiedProps, in howMany, out OfferSequence, out offerIterator )

61 Dr. Welf Löwe und Markus Noga61 Maklerarten Anfragemakler (query trader) Lookup Einfacher Makler (simple trader) Lookup Selbständiger Makler (standalone trader) LookupRegister Admin Sozialer Makler (linked trader) LookupRegister Admin Link Stellvertreter Makler (proxy trader) LookupRegisterAdmin Proxy Komplett- Makler (full-service trader) LookupRegisterAdmin Link Proxy

62 Dr. Welf Löwe und Markus Noga62 I.2.2.2. Corba Anwendungsstandards (Corba facilities)

63 Dr. Welf Löwe und Markus Noga63 Literatur Orfali, Harkey: Client-Server Programming with Java and Corba. Wiley. Schön zu lesen. Empfehlenswert zur Prüfungsvorbereitung. Orfali, Harkey: Instant Corba. Addison-Wesley. Nachttisch-Lektüre. Empfehlenswert zur Prüfungsvorbereitung. OMG: CORBAfacilities: Common Object Facilities Specifications.http://www.omg.org/http://www.omg.org/ XMI - The Value of Interchange. Dr. Stephen A. Brodsky, IBM, Vortrag am 5.2. 1999, OMG XMI Briefing Overview of XMI. Sridhar Iyengar, Unisys Corporation, 5.2.99, OMG XMI Briefing, XML Metadata Interchange (XMI) Proposal to the OMG RFP3: Stream- based Model Interchange Format SMIF. OMG, 20.10.98 http://www.omg.org/ http://www.omg.org/

64 Dr. Welf Löwe und Markus Noga64 Korrigendum Laut Orfali, Harkey "Instant Corba" gibt es doch wesentlich mehr Dienste, die schon von ORBs unterstützt werden. Alle unterstüten C++, Java, IIOP, DII. Alle unterstützen Ereignisse, Naming, Livecycle, Transaktionen (!!), Sicherheit. Der Rest wird lückenhaft unterstützt. Insbesondere werden damit ORBs zu ernsthaften Konkurrenten für Transaktionsmonitore (TP-Monitore). Die verteilte Web-DB kommt in Sicht. Also: happy ORBing.

65 Dr. Welf Löwe und Markus Noga65 2.2. Corba Anwendungsgebiete (facilities) Spezielle anwendungsspezifische Komponentenrahmen/schnittstellen zur Komponentenintegration

66 Dr. Welf Löwe und Markus Noga66 UML MOF Data Warehouse Business Objects Financial Transportation Simulation Life Sciences Electronic Commerce TelecomManufacturing Utility Vertikal (anwendungsorientiert) Horizontal (Plattform) 2.2.1 Vertikale Anwendungsgebiete (domain-specific facilities)

67 Dr. Welf Löwe und Markus Noga67 Domain Technology committee DTC ruft domain task forces DTF ins Leben, um einen Anwendungsbereich zu spezifizieren. Geschäftsprozessobjekte (business objects) Finanzwirtschaft (finance/insurance) –Currency facility Elektronischer Handel (electronic commerce) Produktion (manufacturing) –product data management enablers PDM Medizin (healthcare CorbaMed) –Lexocon Query Service –Person Identifier Service PIDS Telekommunikation (telecommunications) –Audio/visual stream control object –notification service Transport (transportation) Manche sind schon implementiert Vertikale Anwendungsgebiete (domain-specific facilities)

68 Dr. Welf Löwe und Markus Noga68 2.2.2 Horizontale Anwendungsgebiete (general facilities) Benutzerschnittstellen –Drucken –email –Verbunddokumente: Seit 1996 OpenDoc als Verbunddokument- Standard akzeptiert. Source Code ist von IBM freigegeben worden. Tot? –Scripting: in Corba 3.0 wird es eine Skriptsprache geben Informationsmanagement –strukturierter Speicher Bento ist aufgenommen –Metadaten(meta object facility) –Datentransfer: Ein text- und strombasiertes Austauschformat wird entwickelt (XMI) Systemmanagment (Instrumentierung, Monitoring) Task management (Workflow, Regeln, Agenten)

69 Dr. Welf Löwe und Markus Noga69 2.2.2.1 Metaobject Facility MOF Problem: Wie generiere ich IDL aus einer Java-Anwendung heraus, für die ich schon ein Datenmodell definiert habe? Man würde gerne sagen: for all c in classes do generate_class_start(c); for all a in c.attributes do generate_attribute(a); done; generate_class_end(c); done; Dazu braucht man aber ein Typsystem, das das Java-Typsystem beschreibt, also Klassen und Attribute anbietet Andere ähnliche Probleme: –Wie generiere ich Code zum Datenaustausch zwischen C++ und Java? –Wie tausche ich Daten von OMT und UML-basierten CASE-Werkzeugen aus? –Wie binde ich andere Typsysteme als IDL in Corba ein (UML,..)? Wir brauchen also ein Typsystem, das IDL und andere Typsysteme beschreibt!

70 Dr. Welf Löwe und Markus Noga70 2.2.2.1 Metaobject Facility MOF Die MOF (metaobject facility) ist das Typsystem, das Typsysteme beschreibt Standardisiert Nov. 97

71 Dr. Welf Löwe und Markus Noga71 Metadaten Meta: (selbst-)beschreibend Metadaten: beschreibende Daten (auch: sich selbstbeschreibende Daten) Die Elemente der Metaebene (Metaobjekte) beschreiben die Elemente der Realität Metamodellierung: Beschreibung der Elemente/Konzepte der Realität mit einem Datenmodell, dem Metamodell Metadaten Daten, Code, Information Daten, Code, Information Metaebene Konzeptebene Realität

72 Dr. Welf Löwe und Markus Noga72 Reflektion und Selbstmodifikation Metadaten Daten, Code, Information Daten, Code, Information Metaebene Konzeptebene Realität Beschreib en Erst bei Verschmelzung des Metamodells mit dem Modell wird Reflektion möglich. Die Anwendung kann sozusagen ihr eigenes Skelett anschauen und Schlüsse daraus ziehen. Manipuliert sie zusätzlich sich selbst und nutzt dabei das mit Reflektion gewonnene Wissen aus, nennt man dies Selbstmodifikation (intercession).

73 Dr. Welf Löwe und Markus Noga73 Reflektion und Selbstmodifikation Reflektion: for all c in self.classes do generate_class_start(c); for all a in c.attributes do generate_attribute(a); done; generate_class_end(c); done; Selbstmodifikation: for all c in self.classes do helpClass = makeClass(c.name+"help"); for all a in c.attributes do helpClass.addAttribute(copyAttribute(a)); done; self.addClass(helpClass); done ;

74 Dr. Welf Löwe und Markus Noga74 Introspektion Metadaten Daten, Code, Information Daten, Code, Information Besch reiben Späht man das Metamodell sowie die Metadaten einer fremden Komponente aus, um mehr über sie zu erfahren, nennt man dies Ausspähen (Introspektion).. Die Komponente kann sozusagen das Skelett einer anderen Komponente anschauen und Schlüsse daraus ziehen. Typische Anwendung: Eigenschaften herausfinden, die mit Semantik behaftet sind, Methoden, Attribute, Typen herausfinden. Sehr wichtig im Web-Komponenten-Supermarkt! Daten, Code, Information Daten, Code, Information

75 Dr. Welf Löwe und Markus Noga75 Reflektive Objektschnittstelle CORBA unterstützt Reflektion und Introspektion schon durch die Pseudoschnittstelle CORBA::OBJECT. In Java existieren dazu die Klassen Object, Class, Method, etc. Weiterhin wird das Interface Repository abgefragt werden (list_initial_references aus der CORBA::ORB Schnittstelle). - Das Corba Objekt vererbt sich als Klasse auf alle Corba-Objekte und Programmelemente. - Get_interface liefert eine Referenz auf den Eintrag im interface repository. - get_implementation eine Referenz auf die Implementierung CORBA::Object get_implementation get_interface is_nil create_request is_a duplicate release....

76 Dr. Welf Löwe und Markus Noga76 Die Metaebenen von CORBA(Metahelix) Die Elemente jeweils einer Ebene beschreiben die Elemente der nächstniederen Ebene. Ein einfaches Metamodell einer Programmiersprache: Das vollständige Metamodell über Typsystemen und Daten von CORBA: Metametamodelle beschreiben beliebige Typsysteme!

77 Dr. Welf Löwe und Markus Noga77 Die MOF als UML-Beschreibungsmittel Auch die UML (unified modelling language) modelliert und kann metamodelliert werden. Damit können mit Hilfe der MOF beliebige Typsysteme, Modellierungsprachen, Programmiersprachen, u.ä. beschrieben werden. Mit Hilfe von Introspektion und Reflektion können die Metadaten der Modelle abgefragt und bearbeitet werden.

78 Dr. Welf Löwe und Markus Noga78 Das UML-Metamodell

79 Dr. Welf Löwe und Markus Noga79 Die MOF als UML-Metametamodell

80 Dr. Welf Löwe und Markus Noga80 Konzepte der MOF

81 Dr. Welf Löwe und Markus Noga81 Beispiel Makler in MOF MODL Package trader { class property_type { attribute string name; attribute TypcCode value_type; } class service_type { attribute string name; attribute string interface_type; } association has { role single service_type service; role set [0..*] of property_type property; } association inherits { role set [0..*] of service_type base; role set [0..*] of service_type derived; } Abbildung von MODL (MOF Definition language) auf IDL: - attributes in set/get-Funktionen - associations in Link-Klassen und Link-Sequence-Klassen - MODL generiert eine Klasse, die spezielle Methoden enthält, mit der man alle Klassen ansprechen kann (Methode all_of_type)

82 Dr. Welf Löwe und Markus Noga82 MOF - Zweck Wissen über unbekannte Daten zu erlangen in unbekannten Daten zu navigieren (Relationen sind ein Konzept der MOF) von unbekannten Daten aus zu generieren (z.B. IDL aus Programmiersprachen) Daten ineinander umzuwandeln (die Abbildung ist dann nur noch eine Funktion im Metametamodell). Daher kann die MOF benutzt werden, um Werkzeugaustauschformate zu beschreiben und automatisch Umwandlungsroutinen zu generieren. Daten, die mit MOF-basierten Typsystemen beschrieben sind, können automatisch in einander umgewandelt werden, weil die Umwandlungsroutinen automatisch generiert werden können Beschreibende Daten können also benutzt werden, um

83 Dr. Welf Löwe und Markus Noga83 Aufbau einer konkreten MOF MOF Modell MOF Typsystem- Manipulations- schnittstelle MOF Typsystem- Manipulations- schnittstelle MOF Typ- manipulations- schnittstelle MOF Typ- manipulations- schnittstelle Server mit Schnittstellenimpl em. Server mit Schnittstellenimpl em. Typsystem- Werkzeug (MODL) Typsystem- Werkzeug (MODL) IDL Generator Benutzt

84 Dr. Welf Löwe und Markus Noga84 Die MOF als kleinster gemeinsamer Nenner IDL IDL- Spezifikation IDL- Spezifikation MOF UML Umwandlungsrout inen UML- Spezifikation UML- Spezifikation Daten- Instanz Daten- Instanz Daten- Instanz Daten- Instanz Abfrage/Navigatio n MODL

85 Dr. Welf Löwe und Markus Noga85 Bootstrap Natürlich kann die MOF mit der MOF durch einen Bootstrap laufen: –Da die MOF ein Typsystem ist, kann man sie mit sich selbst beschreiben und eine IDL für die MOF generieren –Damit kann man MOFs mithilfe von CORBA-ORBs verteilt ansprechen (und an sich fremde Werkzeuge miteinander kommunizieren lassen) Die MOF Beschreibungen mit XMI verschickt werden...

86 Dr. Welf Löwe und Markus Noga86 Zusammenfassung MOF Die MOF unterstützt beliebige Typsysteme Neue Typsysteme können addiert werden, alte komponiert oder erweitert werden Beziehungen innerhalb und zwischen Typsystemen werden unterstützt Interoperabilität zwischen Typsystemen und -repositorien Automatische Generierung von IDL Reflektion/Introspektion unterstützt Anwendung auf Arbeitsflüsse (workflows), Datenbanken, Groupware, Geschäftsprozesse, data warehouses wird untersucht http://www.dstc.edu.au/MOF

87 Dr. Welf Löwe und Markus Noga87 2.2.2.2 XMI - Das Austauschformat XML: eXtensible Markup Language –enthält DTD-Definition (Document Type Definition, Semantikbeschreibungen für Etiketen (tags)). –DTDs enthalten Metaobjekte, d.h. spezifizieren Metamodelle für Multimedia –Einige Ausprägungen: HTML, MathML, SpeechML, MusicML, VectorML –Ziel: erweiterbares, einfach strukturiertes Format zum Datenaustausch über Programm- und Plattformgrenzen hinweg. –Vereinfachtes SGML (stets hierarchisch, einfachere Semantik) –Dedizierter Nachfolger von HTML –Microsoft: geplantes Datenformat für MS Office 2000. –Sun: Java = portable Programme, XML = portable Daten XMI: Vorgeschlagener Standard für CORBA: UML in XMI, MOF-basiert –eXtended Markup language Interchange format –XMI = UML + XML + MOF

88 Dr. Welf Löwe und Markus Noga88 XMI Development Tools Reports Database Schema Design Software Assets Repositor y App2 App4App5 App1 App6App3 6 Brücken von 6 Herstellern N*N-N = 30 Brücken. XMI als Zwischenrepräsentation

89 Dr. Welf Löwe und Markus Noga89 XMI Zweck –Neutrales, offenes Austauschformat für Metadaten (sprich UML) in verteilten Umgebungen –Spätere Erweiterung auf data warehouses geplant –Semantische Beschreibung von Diensten (jenseits von Eigenschaften/Properties) möglich Vorteile –XMI generiert jeweils eine DTD für ein Typsystem. Die Basierung auf der MOF sichert zu, dass die DTDs ineinander übersetzt werden können (Interoperabilität) –Kompatibel mit Web-Standards sowie Standard- Modellierungssprachen –Unterstützt Übertragung von Differenz-Dokumenten (diffs) sowie Erweiterungen von Metamodellen

90 Dr. Welf Löwe und Markus Noga90 XML Austauschströme (Modelle) XML Austauschströme (Modelle) XML DTD (MetaModels) (spezifisch pro Typsystem) XML DTD (MetaModels) (spezifisch pro Typsystem) CWM DTD UML 1.1 DTD MOF 1.1 DTD Überblick XMI XML Syntax XML Syntax MOF MetametaModell Metadata Definitionen & Management MOF MetametaModell Metadata Definitionen & Management XMIXMI XMIXMI UML Metamodell Analysis & Design UML Metamodell Analysis & Design UML UML Instanz UML CWM Instanz UML MOF Instanz - U s e W 3 C E x t e n s i b l e M a r k u p L a n g u a g e ( X M L ) f o r t h e t r a n s f e r s y n t a x a n d i n t e r c h a n g e f o r m a t Å S p e c i f y X M L D o c u m e n t T y p e D e f i n i t i o n s ( D T D ) t o e n a b l e t r a n s f e r a n d v e r i f i c a t i o n o f U M L b a s e d m o d e l s ( u s i n g U M L D T D ) M O F b a s e d m e t a m o d e l s a n d t h e i r i n s t a n c e s ( A l l o w s u s e o f X M I i n n e w d o m a i n s - D a t a W a r e h o u s e, C o m p o n e n t s … ) - S p e c i f y a p r e c i s e M O F t o X M L m a p p i n g Å A l l o w s i n t e r c h a n g e o f a n y M O F b a s e d m e t a m o d e l a n d c o r r e s p o n d i n g m o d e l s ( M O F - - > X M L S t r e a m ) Å E n a b l e s a u t o m a t i c g e n e r a t i o n o f D T D s f o r a n y M O F b a s e d m e t a m o d e l ( M O F - - > X M L D T D ) - U s e U M L a n d M O F f o r m e t a m o d e l d e s i g n

91 Dr. Welf Löwe und Markus Noga91 XMI als Zwischenrepräsentation CaseTool CaseTool- Spezifikation CaseTool- Spezifikation MOF UML Umwandlung durch XML- Leser/Schreiber Umwandlung durch XML- Leser/Schreiber UML- Spezifikation (in UML) UML- Spezifikation (in UML) CaseTool- Spez. in XML CaseTool- Spez. in XML UML-Spez. In XML (Seite) UML-Spez. In XML (Seite) Abfrage/Navigatio n durch WebQL, die XML-QL Abfrage/Navigatio n durch WebQL, die XML-QL Darstellung mit Style Sheets in Brausern Darstellung mit Style Sheets in Brausern CaseTool- DTD CaseTool- DTD UML-DTD Umwandlung durch XML- Leser/Schreiber Umwandlung durch XML- Leser/Schreiber

92 Dr. Welf Löwe und Markus Noga92 Aus: S. Brodsky, OMG XMI Briefing, Feb 5, 1999 IBM VisualAge Select Unisys UREP Oracle Repository Rose DTD Gen Enterprise MOF DTDGen Rational Rose Select Enterprise Oracle Designer XMI Team Connection Web Sphere VA Java Bereits funktionierendes Austauschsczenario

93 Dr. Welf Löwe und Markus Noga93 XMI Beispiel mit UML DTD Business Customer id : CustId update() Da für jedes Typsystem eine DTD generiert wird, kann auch für das MOF eine DTD generiert werden. Generiert wird nach speziellen DTD-Generierungsregeln. Ausserdem wird XML generiert (mit XML-Generierungsregeln).

94 Dr. Welf Löwe und Markus Noga94 XMI Beispiel mit UML DTD Business Customer id 1 1 update

95 Dr. Welf Löwe und Markus Noga95 XMI Beispiel für Makler-Typsystem mit Trader- DTD "Savings_Account"... Trader-DTD:...

96 Dr. Welf Löwe und Markus Noga96 12/97SMIF (Stream based Model Interchange Format) RFP der OMG 07/98Erste Vorschläge XMI, CDIF, UOL 10/98Verbesserter Vorschlag XMI 11/98Demos 01/99OMG akzeptiert 03/99Erste Implementierungen XMI : Schnelle Standardisierung

97 Dr. Welf Löwe und Markus Noga97 XMI Zusammenfassung XMI wird den Austausch von Daten, Metadaten zwischen verteilten Werkzeugen revolutionieren Closed systems ade! DCOM wird nur noch als Verdrahtungsstandard eine Rolle spielen, Corba enthält mit MOF und XMI das wesentlich flexiblere und mächtigere Konzept, was zudem mit dem Web konform geht MOF und XMI unterstützen beliebige erweiterbare Sprachen, sowohl Modellierungs- als auch Programmiersprachen –der Weg ist frei für anwendungsspezifische Sprachen, die trotzdem interoperabel sind –Entwurf kann mit der Anwendung angepassten Konzepten geschehen, und trotzdem ist Interoperabilität garantiert. Fixe Modellierungs- und Programmiersprachen sind tot, es lebe die Metamodellierung!

98 Dr. Welf Löwe und Markus Noga98 2.3 Corba, Web und Java Neben den Standardisierungsbemühungen der OMG hat sich in den letzten 5 Jahren Java und HTML/HTTP durchgesetzt. HTTP dient nur zum Transport von Daten (CGI-Skripten-Schlamassel) –HTTP kann keine Methoden aufrufen, ausser durch CGI-Gateway- Funktionalität (common gateway interface) –hinter der CGI-Schnittstelle steckt ein beliebiges Programm, mit dem von HTTP aus - anstelle von getypten Parameterübergaben - mittels Umgebungsvariablen kommuniziert wird (HACK!) Untypisiert, nur einfache Argumente möglich (z.B. Werden Optionen in merkwürdige Strings gepackt: arg2=xzy&arg3=kdkdkd), –http-Server sind eigentlich ORBs, Seiten entsprechen Objekten, die vermittelt werden –Das URI/URL-Namensschema kann voll in Corba integriert werden IIOP wird ein Standard-Internet-Protokoll. –Standard ports, URL-Abbildungen und Standard-Proxies für Firewalls werden ohne Probleme verfügbar sein CORBA ist also eine Erweiterung von HTTP von Daten auf Code

99 Dr. Welf Löwe und Markus Noga99 Corba und Java Java ist für Corba ein idealer Partner: –Bytecode ist mobil, d.h. sorgt als Applet dafür, dass Berechnungen auf den Kunden verschoben werden können (thin/thick client Problem) kann zur Migration von Objekten, ORBs und Agenten eingesetzt werden –Seit 1999 existiert eine direkte Corba Unterstützung im JDK 1.2 IDL2Java Abbildung, IDL Übersetzer, Java2IDL Übersetzer, Namensdienst, ORB –Corba stellt für Java eine ergänzende verteilte Infrastruktur zur Verfügung Java imitiert Funktionalitäten von Corba. Einfache Benutzung, aber java- spezifisch –Basisdienste: Remote Method Invocation RMI, Java Native code Interface JNI –Dienste: Serialisierung, Ereignisse –Anwendungsspezifische Dienste (facilities): Reflektion, Eigenschaften/Properties von JavaBeans Ansonsten aber komplementäre Funktionalitäten –DII: Dynamischer Aufruf mittels ORB ist flexibler als Polymorphie, die Dispatch- Tabelle der Programmiersprache ist sozusagen ihr ORB –Gemischtsprachlichkeit. Corba-Protokolle sind komplexer, da es nicht nur oo- Programme bedient –Corba bietet wesentlich mehr Dienste, MOF für mehrere Sprachen, XMI

100 Dr. Welf Löwe und Markus Noga100 Corba und das Web (Orblets) ORBs können als Bytecode-Applets verschickt werden, sofern sie nur in Java geschrieben sind (ORBlet) Damit ergibt sich eine extrem interessante Kopplung von HTTP und IIOP: Herunterladen eines ORBlets mit HTTP Ansprechen dieses ORBs, um mit dem Server Kontakt aufzunehmen Server-ORB vermittelt Anfrage Daher entfällt das CGI-Skripten-Schlamassel: –HTTP kann nämlich keine Methoden aufrufen, ausser durch CGI- Gateway-Funktion –hinter der CGI-Schnittstelle steckt ein beliebiges Programm, die Kommunikation erfolgt über Umgebungsvariablen (HACK!)

101 Dr. Welf Löwe und Markus Noga101 ORBlets ORB Http server ORB Server ORB Server Web-ClientWebserver 1) Hole Seite 2) Hole ORBlet Geschäftsobjekte 3) Kommuniziere mit IIOP Datenbanken Lotus Notes

102 Dr. Welf Löwe und Markus Noga102 Verschmelzung von CORBA und HTTP Beides unkorreliert nebeneinander, CORBA mit IIOP auch über TCP/IP Statt Java-Applets ORBlets einsetzen (mit JDK 1.2 ohne Probleme möglich) CGI-CORBA-Gateway: Hinter CGI wird ein ORB angeschlossen, der allerdings dann nur über CGI angesprochen werden kann HTTP-IIOP-Gateway. Hierbei muss ein CORBA HTTP- Dienstanbieter die HTTP Anfragen bearbeiten. Damit könnten die HTTP-Dienstanbieter sukzessive ersetzt werden, um echte Interoperabilität zu erhalten

103 Dr. Welf Löwe und Markus Noga103 ORBs http://www.omg.orghttp://www.omg.org, Universität Wien (Wolfgang Lugmayer) Java-basiert –IBM SOMObjects –SUN NEO, Joe: eigenes Protokoll sowie IIOP. Der Java Transaction Service JTS ist der JOE Corba Object Transaction Service OTS. –IONA Orbixweb: In Java entwickelt, d.h. ORBlets möglich, C++, Java- Anwendungen –Visibroker (in Netscape integriert), ebenfalls IIOP basiert. Umgebung Caffeine auf Visibroker ermöglicht es, aus Java IDL zu generieren. Damit werden IDL Spezifikationen überflüssig. –Voyaer (ObjectSpace) (mit Mobilen Agenten) –Frei: JacORB, ILU, Jorba, DynaORB, C-basiert –ACE ORB TAO, Universität Washington (Trader!9 –Linux ORBIT (gnome) –Linux MICO (kde) Python-basiert –fnorb

104 Dr. Welf Löwe und Markus Noga104 Produkte Jumping Beans: migrierende Beans auf der Basis von mobilem Corba, Fehlertoleranz Applixware WebIntelligence (Business Objects America): OLAP Transaktionsverarbeitung auf Webobjekten

105 Dr. Welf Löwe und Markus Noga105 Corba OpenDoc 1996 wurde OpenDoc als Standard für zusammengesetzte Dokumente angenommen OpenDoc-Seiten sind Container von Corba-Komponenten (shippable places) –Gegenüber html-Seiten bietet eine OpenDoc-Seite sie den Vorteil, beliebig strukturiert zu sein, sowie aktive Komponenten zu enthalten –..in strukturierten Dateien ablegbar zu sein, auch verteilt –Verweise, Drag-and-drop von aktiven Seitenteilen möglich Aus Corba-Sicht sind die Dokumente nur Objekte, die für ihre Teile Bearbeitungsobjekte kennen Fragen: –Integration mit HTML/XML/XMI? –Integration mit JavaBeans?

106 Dr. Welf Löwe und Markus Noga106 Visionen für ein neues Komponenten-Web Brauser ist ein Komponentendokument ist eine (OpenDoc-)Seite ist ein shippable place –Brauser Volle Verschiebbarkeit von Brauserfunktionalitäten: Schieben von URLs als aktive Objekte in den Brauser und die Dokumente hinein, z.B. Als toolbars Erweiterbarkeit durch neue Komponenten –Dokumente beliebige Formen von aktiven Dokumententeilen Volle visuelle Verschiebbarkeit von aktiven Seitenteilen, in-place editing aller Teile –Laden von Seiten entspricht dem drag-and-drop von Komponenten in Komponenten –Einkaufen als Drag-and-drop in Container hinein –Der Desktop wird zum Brauser (als Container von aktiven verteilten Objekten) Gamelons (www.gamelon.com) sind Containersysteme für Komponenten (verschieben, speichern, verteilen)www.gamelon.com

107 Dr. Welf Löwe und Markus Noga107 Shippable Places Ein shippable place ist ein visuelles Ensemble von Komponenten, der über das Netz verschickt werden kann. (visible bean, Bohne, jar, EJB, ActiveX) –eine Miniwelt (personalisiert als Desktop, wearable, Autoeinstellung) –persistent, kommunizierend mit ORBs ORB-HTTP Server ORB-HTTP Server HTTP IIOP Geschäftsobjekte Datenbanken Lotus Notes HTML Applets Shippable Places HTML-Seiten CG I ORB

108 Dr. Welf Löwe und Markus Noga108 2.4 Corba 3.0 - 1999 Basisdienste: – POA, die 2. Generation von BOAs – SFA, Server Framework Adapter – Mehrfachschnittstellen (multiple interfaces) und zusammengesetzte (komponierte) Objekte – Wertobjekte – Versionen Services: – Message Service MOM. Objekte als asynchrone gepufferte Botschaften – Corba Beans-Komponenten – Skriptsprache Facilities: Zusammengesetzte Dokumente, Mobile Agenten, BOF (business object facility)

109 Dr. Welf Löwe und Markus Noga109 POA Portable Object Adapter Der POA ist eine Weiterentwicklung der BOA Schnittstelle, die Erfahrungen der letzten Jahre sind eingebaut. Flexibler Geschachtelte POAs möglich, dadurch geschachtelte Namensräume ORB kann hinter POA ausgetauscht werden, war mit BOA nicht möglich Policies für Objektverwaltung: Anmeldung von benutzergeschriebenen Instanzenmanagern möglich zur Verwaltung von Objektinstanzen Liste von Instanzmanagern Liste von aktiven Dienst-Objekten

110 Dr. Welf Löwe und Markus Noga110 SFA Server Framework Adapter.. sind sprachspezifische Adapterschnittstellen für den POA... vereinfachen die Benutzung eines POA.. benutzen Spracheigenschaften wie Vererbung, um die Anbindung an Corba so einfach wie möglich zu gestalten

111 Dr. Welf Löwe und Markus Noga111 Objekt-Komposition durch mehrere Schnittstellen pro Objekt –Mehrfachvererbung auf Schnittstellen (statisches Konzept) –Entwurfsmuster Fassade: Aggregation und Delegation können verwendet werden, um Funktionen der Schnittstelle auf andere Objekte abzuwälzen. Damit ist eine Schnittstelle nur eine Fassadenklassen. Konzept auch in DCOM/ActiveX realisiert Dog Cat Mouse Create Request Animal

112 Dr. Welf Löwe und Markus Noga112 MOM - Message Oriented Middleware Jedes Objekt im Web soll eine Mailbox bekommen –Pufferung aller Nachrichten (auch strukturierte Dateien) –Nachrichten können selbst Objekte sein (Objektmigration) –Laptops, Palmtops werden unterstützt –Callback-Objekte können mit Nachrichten mitgegeben werden. Diese werden vom Empfänger der Nachricht aufgerufen –MOA: Message Object Adapter spielt eine Rolle ähnlich zum BOA und POA, die Vermittlung zwischen Netz und Dienstgeber

113 Dr. Welf Löwe und Markus Noga113 Corbabohnen (Corba Beans) Mehrfachschnittstellen (multiple interfaces) Wertobjekte Introspektion Direkte Abbildung auf Java Beans BOF Business Object Facility Geschäftsbasisobjekte (analog zu Enterprise JavaBeans) bauen auf mehreren Diensten auf (Persistenz, Transaktionen, Ereignisse, Lizensierung) anwendungsspezifische alsabgeleitete Objekte Komponentendefinitionssprache als Erweiterung von IDL. Anreicherung von semantischen Eigenschaften wie Verhalten, Aussichten, Regeln, Triggern, Restriktionen Geschäftsobjekt-Dienst: Container, Qualitätsmerkmale (Quality of Service), Query Semantische Nachrichten: selbstbeschreibende Nchrichten

114 Dr. Welf Löwe und Markus Noga114 2. 5. Was haben wir gelernt? Was zeichnet Corba als Komponentensysteme aus? Wie erfüllt Corba unsere Kriterien aus der Einleitung?

115 Dr. Welf Löwe und Markus Noga115 Ziele erfüllt? Erhöhung Wiederverwendung Produktqualität Qualitätsverbesserung Effektivität durch Konzentration auf Optimierungen Verlässlichkeit Verlängerung Lebensdauer Flexibilisierung Verbesserungen am Softwareprozess Produktivität Schneller Prototypenbau Simulation von Architekturen Dokumentation Klare Systemstrukturen ja ? ja, wegen mehr Transparenz ? (Sicherheit) ja jein ? nein nein ja

116 Dr. Welf Löwe und Markus Noga116 Desiderata für flexible Systemkomposition Modularer Austausch von Komponenten Geheimnisprinzig (information hiding): explizite Spezifikation von Schnittstellen (Kontakt- oder Austauschpunkte) Adaption von Komponenten Interne Adaption von Komponenten an ihren Wiederverwendungskontext Offene Implementierung, Austausch von nicht-funktionalen Aspekten Externe Adaption: Generierung von Klebecode für Zusammenarbeit Kommunikation, Synchronisation, Verteilung Aspekttrennung (Aspektkomposition) klarere Spezifikationen und trotzdem effiziente Implementierungen Transparenz Verteilung, Service-Identität, Programmiersprache, Persistenz Migration (Mobilität)

117 Dr. Welf Löwe und Markus Noga117 Corbas Mechanismen zur Modularisierung Schnittstellen für Gemischtsprachlichkeit IDL wird zur Spezifikation von Schnittstellen benutzt..und die MOF zur Spezifikation von Typsystemen incl. IDL Schnittstellen werden im Interface Repository gespeichert und nachgeschlagen Standardisierung von Schnittstellen für DII, Dienste, Anwendungsdienste wesentliches Merkmal eines Komponentensystems Technische vs. Anwendungsspezifische vs Fachkomponenten: Corba bietet zwar –Standards für technische und anwendungsspezifische Komponenten –.. aber an Fachkomponenten-Standards muss noch viel gefeilt werden (vertical facilities) (that´s where the money is)

118 Dr. Welf Löwe und Markus Noga118 Corbas Mechanismen zur Adaptierbarkeit IDL Generatoren werden zur Erzeugung von Kleister-Code eingesetzt Object Adapter kapseln Objekte auf Dienstgeberseite Schnittstellen BOA, POA Objektidentität (IOR) verbirgt Implementierungsdetails der Objekte Metadaten:MOF und die XMI werden eingesetzt, um automatisch Stromformate von Werkzeugen ineinander umzusetzen GIOP General Inter ORB Protocol spezifiziert einen Rahmenprotokoll, dass die ORBs verstehen keine interne Adaptierbarkeit

119 Dr. Welf Löwe und Markus Noga119 Mechanismen zur Aspekttrennung Mehrere Schnittstellen pro Objekt Mehrfachvererbung auf Schnittstellen (statisch, mit Code- Wiederverwendung) Dynamisch ab 3.0 durch Komposition, Aggregation mit Entwurfsmuster Fassade keine statische Aspekttrennung

120 Dr. Welf Löwe und Markus Noga120 Mechanismen zur Transparenz OMA 3-Schichtenarchitektur (3-tier architecture) mit statischem Aufruf und dynamischem Aufruf Marshalling durch IDL IOR Lebendigkeit oder Nichtlebendigkeit wird verborgen durch Objekt-Adapter Persistenz Bei MOF-basierten Typsystemen Konvertierbarkeit garantiert Migration durch Java und mobile Agenten

121 Dr. Welf Löwe und Markus Noga121 Fazit Die Corba-Schnittstellen sind sehr flexibel, funktionieren und können in der Praxis eingesetzt werden.. aber auch komplex und umfangreich, vielleicht zu flexibel für die Praxis Corba hat den Vorteil, ein offener Standard zu sein, DCOM kommt da erst so langsam nach. Gegenüber DCOM wird wesentlich schon über den Verdrahtungsstandard hinaus normiert (facilites, services) XMI könnte ein grosser Knüller werden, ebenso OpenDoc Freie ORBs in Linux könnten Corba schieben Java für neue Software, Corba für gemischte Alt-Neu-Systeme Wann kommt das Komponenten-Web? Gibt es ein Leben nach HTML? Wann kommt Elektronischer Handel, und auf welcher Basis? Wann können alle Corba 3.0?