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

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

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

Dr. Welf Löwe und Markus Noga4 I 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 Neueste Corba- Entwicklungen. Jens-Peter Redlich, CORBA 2.0 / Praktische Einführung für C++ und Java. Verlag: Addison-Wesley, ISBN: , 59.90DM Corba 2.2 Specification. OMG. 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

Dr. Welf Löwe und Markus Noga5 Corba Common Object Request Broker Architecture Gründung der OMG (object management group) 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 (IDL, ORB, BOA) ODMG-93 (Standard für oo-Datenbanken) Corba , heute 2.2 Corba

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)

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)

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

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

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, 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

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

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

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

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

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

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

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

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.

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

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)

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

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 -....

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 -....

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

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

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; } };

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); } };

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); } };

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

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

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

Dr. Welf Löwe und Markus Noga32 I Corba Dienste (Corba services) OMG. CORBAservices: Common Object Service Specifications. Version vom Dez. 98.

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

Dr. Welf Löwe und Markus Noga34 Überblick Corba Dienste (Services) 16+ standardisierte Dienstschnittstellen (in IDL definiert). Implementierungsstand je nach Anbieter 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.

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)

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.

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.

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

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.

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.

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

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(); };

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 ); };

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

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()); }

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; }

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,...

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

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

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!

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.

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

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

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

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)

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

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

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

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

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 )

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

Dr. Welf Löwe und Markus Noga62 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. Markus L. Noga: Was passiert hiermit? Markus L. Noga: Was passiert hiermit?

Dr. Welf Löwe und Markus Noga63 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

Dr. Welf Löwe und Markus Noga64 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. XMI - The Value of Interchange. Dr. Stephen A. Brodsky, IBM, Vortrag am , OMG XMI Briefing Overview of XMI. Sridhar Iyengar, Unisys Corporation, , OMG XMI Briefing, XML Metadata Interchange (XMI) Proposal to the OMG RFP3: Stream- based Model Interchange Format SMIF. OMG,

Dr. Welf Löwe und Markus Noga65 I Corba facilities Horizontale (general) facilities –Dienste, Werkzeuge –Unabhängig von Anwendungsbereich –Spezifikation durch OMG –Kenntnis nützlich –Abgrenzung zu Corba services unklar Vertikale (domain-specific) facilities –Rahmenwerke, Schnittstellen –Spezfisch für einen Anwendungsbereich –Spezifikation durch Industriegremien Domain Technology Committe (DTC) gründet Domain Task Forces (DTF), die spezifizieren –Bei Bedarf nachschlagen

Dr. Welf Löwe und Markus Noga66 MOF XMI Data Warehouse Business Objects Financial Transportation Simulation Life Sciences Electronic Commerce TelecomManufacturing Utility Vertikal Horizontal Einige Beispiele

Dr. Welf Löwe und Markus Noga67 Beispiele für general facilities Benutzerschnittstellen –Drucken – –Verbunddokumente: Seit 1996 OpenDoc. Source Code ist frei. Tot? –Scripting: ab Corba 3.0 Informationsmanagement –strukturierter Speicher Bento –Metadaten (meta object facility, MOF) –Datentransfer: text- und strombasiertes Austauschformat (XMI) Systemmanagment (Instrumentierung, Monitoring) Task management (Workflow, Regeln, Agenten)

Dr. Welf Löwe und Markus Noga68 Metaobject Facility (MOF) Viele Anwendungen wurden nicht für Corba entwickelt –Annahme:Implementierung in Java –Problem:Klassen nicht mit IDL definiert –Ansatz:IDL aus Klassen generieren –Nötig:Konforme Abbildung des Java-Typsystems (Klassen/Attribute) Ähnliche Probleme: –Generieren von Code zum Datenaustausch zwischen C++ und Java –Datenaustausch zwischen verschiedenen CASE-Werkzeugen (OMT, UML) –Einbindung weiterer Typsysteme in Corba Lösung: MOF –Ein Meta-Typsystem, das IDL und andere Typsysteme beschreibt –Standardisiert im November 97

Dr. Welf Löwe und Markus Noga69 Metadaten Meta: griech. darüber, jenseits Metadaten: Daten über Daten –Datenbeschreibung –Modellierung –Können reflexiv sein Reflektion: Programm greift auf Metadaten zu Selbstmodifikation (intercession) kann Erkenntnisse nutzen Metadaten Daten, Code Daten, Code Metaebene(Konzeptebene) Realität Beschreiben Zugriff Ändern

Dr. Welf Löwe und Markus Noga70 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 ;

Dr. Welf Löwe und Markus Noga71 Ausspähen (Introspection) Spezialfall der Reflektion: über fremde Komponenten Bestimmen semantikbehafteter Eigenschaften Wichtig für den Web-Komponenten-Supermarkt. Metadaten Daten, Code Daten, Code Metaebene(Konzeptebene) Realität Beschreiben Daten, Code Daten, Code Zugriff Ändern

Dr. Welf Löwe und Markus Noga72 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 Mittel der Reflektion CORBA::Object - get_implementation - get_interface - is_nil - create_request - is_a - duplicate - release -....

Dr. Welf Löwe und Markus Noga73 Beschreibungsebenen Hierarchie von Beschreibungsebenen Reale Objekte (Akte, Ordner etc) Programmobjekte (CORBA Objekte) Typen (int, char, zusammengesetzte IDL Typen etc) Typsysteme (IDL oder UML) MOF beschreibt Typsysteme

Dr. Welf Löwe und Markus Noga74 MOF im Bild IDL IDL- Spezifikation IDL- Spezifikation MOF UML Umwandlungsroutinen UML- Spezifikation UML- Spezifikation Daten- Instanz Daten- Instanz Daten- Instanz Daten- Instanz Abfrage/Navigatio n MODL

Dr. Welf Löwe und Markus Noga75 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)

Dr. Welf Löwe und Markus Noga76 Zusammenfassung MOF Die MOF unterstützt beliebige Typsysteme Neue Typsysteme können addiert werden, alte komponiert oder erweitert werden Beziehungen innerhalb und zwischen Typsystemen 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

Dr. Welf Löwe und Markus Noga77 XMI Extensible Markup Language Interchange Format 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

Dr. Welf Löwe und Markus Noga78 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

Dr. Welf Löwe und Markus Noga79 XMI - Das Austauschformat XML: eXtensible Markup Language –Ziel: erweiterbares, einfach strukturiertes Format zum Datenaustausch über Programm- und Plattformgrenzen hinweg. –Vereinfachtes SGML (stets hierarchisch, einfachere Semantik) –Definition von Dokumenttypen mit DTDs –DTDs enthalten Metaobjekte, d.h. spezifizieren Metamodelle für Multimedia –Ausprägungen: HTML, MathML, SpeechML, MusicML, VectorML –Microsoft: Datenformat für MS Office –Sun: Java = portable Programme, XML = portable Daten XMI: Vorgeschlagener Standard für CORBA: –XMI = UML + MOF + XML

Dr. Welf Löwe und Markus Noga80 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

Dr. Welf Löwe und Markus Noga81 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, XML-QL Abfrage/Navigatio n durch WebQL, XML-QL Darstellung mit Style Sheets in Browsern Darstellung mit Style Sheets in Browsern CaseTool- DTD CaseTool- DTD UML-DTD Umwandlung durch XML- Leser/Schreiber Umwandlung durch XML- Leser/Schreiber

Dr. Welf Löwe und Markus Noga82 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 Ein reales Austauschszenario