1 / 82

Gliederung: Teil I - Grundlagen

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 Java Beans 3. Anpassungsprobleme Daten und Funktion

essien
Download Presentation

Gliederung: Teil I - Grundlagen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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. Aufgaben kommerzieller Systeme(Corba, (D)COM, EJB) • Daten- und Interface-Beschreibung • Referenz- und Wertesemantik • Kommunikation (Nachrichten und RMI) • Verteilung, Persistenz, Heterogenität Softwarebus

  3. 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. 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. 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. 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. 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. Bestandteile von Corba Basisdienste Interoperabilität IDL, RPC, ORB Protokolle GIOP IIOP Erweiterte Interoperabilität DII, Trading MOF (reflection) Facilities Services Scriptsprachen Geschäfts objecte (business objects) Komponenten CorbaBeans

  9. Die OMA (object management architecture) Domain Interfaces Common Facilities Application Interfaces Object Request Broker Object Services

  10. 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. ORB Client Server/Object Implementation IDL Stub ORB Interface IDL Skeleton Dynamic Skeleton Object Adapter Dynamic Invocation ORB Kern ORB-abhängig Standardisiert Objekttyp-abhängig

  12. ORB Verfeinerte Sicht

  13. 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. Interface Definition Language Typen Module <identifier> { <type declarations> <constant declarations> <exception declarations> // Klassen interface <identifier> : <inheriting-from> { <type declarations> <constant declarations> <exception declarations> // Methoden optype <identifier>(<parameters>) { ... } .... } } Objekte Nicht-Objekte Referenz- Objekte Wertobjekte Basistypen Konstruktoren Ints (short,..) Struct Any Reals (float..) Typen Sequence Bool Char, string, Union Enum octet Array

  15. Ablauf IDL-Codegenerierung Implementation Repository IDL- Compiler IDL Interface Server Implementation Server Skeleton Client Stub Client Implementation Compiler Objektadapter/BOA Server Client

  16. 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. Serverseite Server / Object Implementation deactivate_obj deactivate_impl impl_is_ready object_is_ready BOA IDL Skeleton ORB Kern

  18. 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. Objektaktivierung auf dem Server Server Objekt1 Objekt2 CORBA::BOA Impl_is_ready Create obj_is_ready get_id obj_is_ready deactivate_obj deactivate_obj deactivate_impl

  20. 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. 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. 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. 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. ORB-Aktivierung auf dem Klienten Objekt CORBA ORB ORB_init Initialisiert den Vermittler BOA_init Initialisiert den Server-BOA List_initial_services Liefert Strings resolve_initial_references Liefert Objektreferenzen

  25. Beispiel IDL //TestTimeServer.idl module TestTimeServer{ interface ObjTimeServer{ string getTime(); }; };

  26. 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. 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. 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. Beispielausführung C:\> java TimeServer_Server IOR:00000000000122342435 … C:\> java TimeServer_Client IOR:00000000000122342435 … Time: 14:35:44

  30. 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) Protokoll u. Adresse Objekt- Schlüssel

  31. Beispiel: IOR Client Server Obj_999 IDL:My Obj:1.0 Bobo: 1805 OA4, obj_999 OA4 Obj_998 Obj_997

  32. I.2.1.2 Corba Dienste (Corba services) • OMG. CORBAservices: Common Object Service Specifications. http://www.omg.org. Version vom Dez. 98.

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

  34. Überblick Corba Dienste (Services) • 16+ standardisierte Dienstschnittstellen (in IDL definiert). • Implementierungsstand je nach Anbieterhttp://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. 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. 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. 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. Abhängigkeiten zwischen den Diensten Makler Transaktionen Query Lizenzen Persistenz Serialisierung Sicherheit Container Allokation Sperren Rückruf Ereignisse Relationen Eigenschaften Namen

  39. 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. 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. Namensdienst CosNaming::NamingContext • 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

  42. IDL Namensdienst module CosNaming{ typedef string Istring; struct NameComponent { Istring id; Istring kind; }; typedef sequence <NameComponent> Name; enum BindingType { nobject, ncontext }; struct Binding { Name binding_name; BindingType binding_type; }; typedef sequence <Binding> BindingList; interface BindingIterator; interface NamingContext; } 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(); }; interface NamingContext { enum NotFoundReason { missing_node, not_context, not_object }; exception NotFound { NotFoundReason why; Name rest_of_name; };

  43. 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. Erzeugen von Namen Systemabhängiger Name Suche/Erzeuge Namensraum Erzeuge Name Namensraum Corba-Name Bindung Objekt Suche Name

  45. 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. Naming public static Name mk_name(String str) { int last, k, i= 0; ... return name; } } 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(); }

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

More Related