Post on 31-Aug-2018
transcript
Dr. Welf Löwe und Markus Noga 1
Gliederung: Teil I - Grundlagen
1. Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)
2. Industrielle Komponentensysteme der 1. Generation1. CORBA 2. (D)COM 3. Enterprise JavaBeans
3. Anpassungsprobleme – Daten und Funktion– Interaktion
• Kommunikation• Synchronisation• Protokolle
– Lebendigkeit
Dr. Welf Löwe und Markus Noga 2
Aufgaben kommerzieller Systeme(Corba, (D)COM, EJB)
Daten- und Interface-BeschreibungReferenz- und WertesemantikKommunikation (Nachrichten und RMI)Verteilung, Persistenz, Heterogenität
Softwarebus
Dr. Welf Löwe und Markus Noga 3
Gliederung
Literatur, Ziele, BestandteileBasis-Mechanismen für – Kommunikation,– modulare Austauschbarkeit, – Adaption
Mechanismen zur Standardisierung von Schnittstellen(Services, Facilities)Selbstbeschreibung (Metaobjekte, MOF)Corba und das WebAustauschformat XMI
Dr. Welf Löwe und Markus Noga 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 ÜbersetzungsfehlerCORBA. 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.90DMCorba 2.2 Specification. OMG. http://www.omg.orgVorträ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 Noga 5
Corba
Common Object Request Broker ArchitectureGründung der OMG (object management group) 1989. Ziel: plug-and-play components everywhere
When the Object Management Group (OMG) was formed in 1989, interoperabilitywas 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.2Corba 3.0 1999
Dr. Welf Löwe und Markus Noga 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)
Dr. Welf Löwe und Markus Noga 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)
Dr. Welf Löwe und Markus Noga 8
Bestandteile von Corba
BasisdiensteInteroperabilitätIDL, RPC, ORB
ProtokolleGIOP IIOP
ErweiterteInteroperabilität
DII, Trading
MOF(reflection)
Facilities Services
Scriptsprachen Geschäftsobjecte
(businessobjects)
KomponentenCorbaBeans
Dr. Welf Löwe und Markus Noga 9
Die OMA (object management architecture)
Domain Interfaces Common FacilitiesApplication Interfaces
Object Request Broker
Object Services
Dr. Welf Löwe und Markus Noga 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
Dr. Welf Löwe und Markus Noga 11
ORB
Server/Object Implementation
DynamicInvocation
IDLStub
ORBInterface
IDLSkeleton
DynamicSkeleton
ORB Kern
Client
ObjectAdapter
ORB-abhängigStandardisiertObjekttyp-abhängig
Dr. Welf Löwe und Markus Noga 12
ORB Verfeinerte Sicht
Dr. Welf Löwe und Markus Noga 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 interfaceDII: Neben normaler Polymorphie kennt Corba das dynamische Suchen eines Services, das transparente Erwecken eines DienstesInteroperable Object Reference (IOR): Objekte und Komponenten erhalten eindeutige IORs
Dr. Welf Löwe und Markus Noga 14
Interface Definition Language
TypenTypenModule <identifier> {
<type declarations><constant declarations><exception declarations>
// Klasseninterface <identifier> : <inheriting-from> {<type declarations><constant declarations><exception declarations>// Methodenoptype <identifier>(<parameters>) {
...}....
}}
Objekte t
Typen(float..float..Typen
Ints (short,..)Ints (short,..)
KonstruktorenKonstruktorenBasistypenBasistypen
Nicht-ObjekteNicht-ObjekteReferenz-Objekte
Referenz-Objekte WertobjekteWertobjekte
Objek e
StructStruct
Reals )Reals ( )
Char, string, Char, string, UnionUnion
SequenceSequenceAnyAny
BoolBool
EnumEnum octetoctet ArrayArray
Dr. Welf Löwe und Markus Noga 15
Ablauf IDL-Codegenerierung
IDL InterfaceIDL InterfaceIDL-
CompilerIDL-
Compiler
ClientImplementation
ClientImplementation
ServerImplementation
ServerImplementation
CompilerCompiler
ServerSkeleton
ServerSkeleton
ClientStub
ClientStub
ImplementationRepository
Objektadapter/BOA
Objektadapter/BOA Client Client Server Server
Dr. Welf Löwe und Markus Noga 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ährleistenVerwaltet das Implementation Repository (Registry).Unterstützt auch nicht-oo CodeAufgerufen 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 Noga 17
Serverseite
Server / Object Implementation
IDLSkeleton
impl_is_ready
object_is_ready
deactivate_obj
deactivate_impl
BOA
ORB Kern
Dr. Welf Löwe und Markus Noga 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-FunktionenSeparater 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 Noga 19
Objektaktivierung auf dem Server
Server Objekt1 Objekt2 CORBA::BOAImpl_is_ready
Createobj_is_ready
get_idobj_is_ready
deactivate_objdeactivate_obj
deactivate_impl
Dr. Welf Löwe und Markus Noga 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öglichDa 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 Noga 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
Dr. Welf Löwe und Markus Noga 22
Das Corba-Objekt
CORBA::Object
- get_implementation- get_interface- is_nil- create_request- is_a- duplicate- release- ....
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
Dr. Welf Löwe und Markus Noga 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- ....
Dr. Welf Löwe und Markus Noga 24
ORB-Aktivierung auf dem KlientenObjekt CORBA ORB
ORB_init Initialisiert den VermittlerBOA_init Initialisiert den Server-BOA
List_initial_services Liefert Strings
resolve_initial_references Liefert Objektreferenzen
Dr. Welf Löwe und Markus Noga 25
Beispiel IDL
//TestTimeServer.idl
module TestTimeServer{interface ObjTimeServer{
string getTime();};
};
Dr. Welf Löwe und Markus Noga 26
Beispiel fortgesetzt: Service Implementierung
//TestTimeServerImpl.javaimport CORBA.*;class ObjTestTimeServerImpl extends TestTimeServer.ObjTimeServer_Skeleton //generated from IDL{
//Variables//Constructor//Method (Service) Implementationpublic String getTime() throws CORBA.SystemException{
return “Time: “+currentTime;}
};
Dr. Welf Löwe und Markus Noga 27
Server Implementierung
// TimeServer_Server.javaimport 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 Noga 28
Client Implementierung
//TimeServer_Client.javaimport 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 Noga 29
Beispielausführung
C:\> java TimeServer_Server
IOR:00000000000122342435 …
C:\> java TimeServer_Client IOR:00000000000122342435 …
Time: 14:35:44
Dr. Welf Löwe und Markus Noga 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)Type Name
(repository id)Protokoll u.Adresse
Protokoll u.Adresse
Objekt-SchlüsselObjekt-
Schlüssel
Dr. Welf Löwe und Markus Noga 31
Beispiel: IOR
Client Server
IDL:MyObj:1.0
IDL:MyObj:1.0
Bobo:1805
Bobo:1805
OA4,obj_999OA4,
obj_999
Obj_997Obj_997
Obj_999Obj_999
Obj_998Obj_998OA4OA4
Dr. Welf Löwe und Markus Noga 32
I.2.1.2 Corba Dienste (Corba services)
OMG. CORBAservices: Common Object Service Specifications. http://www.omg.org. Version vom Dez. 98.
Dr. Welf Löwe und Markus Noga 33
Bestandteile von Corba
BasisdiensteInteroperabilitätIDL, RPC, ORB
ProtokolleGIOP IIOP
ErweiterteInteroperabilität
DII, Trading
MOF(reflection)
Facilities Services
Scriptsprachen Geschäftsobjecte
(businessobjects)
KomponentenCorbaBeans
Dr. Welf Löwe und Markus Noga 34
Überblick Corba Dienste (Services)
16+ standardisierte Dienstschnittstellen (in IDL definiert). Implementierungsstand je nach Anbieterhttp://www.cetus-links.org/oo_object_request_brokers.htmlEinteilbar 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 Noga 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)
Dr. Welf Löwe und Markus Noga 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.
Dr. Welf Löwe und Markus Noga 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.
Dr. Welf Löwe und Markus Noga 38
Abhängigkeiten zwischen den Diensten
Makler
Namen
Allokation
Relationen
Persistenz Serialisierung
Sperren
Transaktionen
Query
Sicherheit
Lizenzen
ContainerRückruf
EreignisseEigenschaften
Dr. Welf Löwe und Markus Noga 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.
Dr. Welf Löwe und Markus Noga 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önnenEigenes 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 Noga 41
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 Noga 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;}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 Noga 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 );};
};
Dr. Welf Löwe und Markus Noga 44
Erzeugen von Namen
SystemabhängigerName
Bindung
Suche/ErzeugeNamensraum
Corba-Name
Erzeuge Name
Namensraum
Objekt
Suche Name
Dr. Welf Löwe und Markus Noga 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());}
}
Dr. Welf Löwe und Markus Noga 46
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 Noga 47
Objektdienste: Eigenschaftsdienst
Eigenschaften (properties) sind StringsDienst verwaltet Listen von Eigenschaften für ObjekteKonzept bekannt als assoziative Arrays, LISP property lists, Java property classes
Dynamisch erweiterbarIteratoren für EigenschaftswertePropertySetDef 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 Noga 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, deleteAnbindung von beliebigen Speicherwerkzeugen möglich– Relationale Datenbanken– Filesystem
Dr. Welf Löwe und Markus Noga 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
Dr. Welf Löwe und Markus Noga 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!
Dr. Welf Löwe und Markus Noga 51
Geschäftsprozessdienste: Lizenzen
Kommerzielle Komponenten: gekauft, gemietet, geleast, ersteigertAbstrakte 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 Noga 52
Lizenz-Szenario
KundeKundeKundeKunde
Hole Lizenzdienst
HerstellerabhängigerLizenzdienst
Konkreter Dienst
Hole LizenzLiefere Lizenz
Cos::LicenseManager
Hersteller-strategie
Lizenzsystem(auch entfernt)
Abstrakte Fabrik
Liefere Lizenzdienst
Dr. Welf Löwe und Markus Noga 53
Schnittstelle
LicenseServiceManager– obtain_specific_license_service
SpecificLicenseService– start_use– check_use– end_use
Dr. Welf Löwe und Markus Noga 54
Lizenzprotokoll
Licensemanager
Producer specificlicense service
Licence servicemanager
Eventservice
Kunde
obtain_producer_specific_license
Start_use
Initial check_useInquiry
Ask for eventcheck_use
Event notification (license there)
End_use
Dr. Welf Löwe und Markus Noga 55
Geschäftsprozessdienste: Makler
Makler handeln mitDiensten (services,service types)
Vermittlermuster
Makler
Kunde
ExportiereFunktionalität
ImportiereFunktionalität
DienstInteragiere
Dr. Welf Löwe und Markus Noga 56
Wann ein Dienst gegen anderen ersetzen(Konformität)?
gleiche Schnittstelle oder abgeleitete Schnittstellealle Sucheigenschaften identisch definiert – keine Properties vom Corba Dienst Properties
alle Modi der Eigenschaften stärker oder gleich
Mandatory, readonly
(normal)
Mandatory readonly
Dr. Welf Löwe und Markus Noga 57
Dienstangebote für Makler
Dienstangebot: Paar aus IOR und EigenschaftenEigenschaften – 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 Noga 58
Dienst-Hüpfen (hopping)
Makler 4
Makler 1Makler 1
Makler 3
Makler 2
Fluß derEigenschaftender Dienstanfrage
Angebote der Makler
Policies, die die Werteder Eigenschaften derDienstanfrage verändern
Dr. Welf Löwe und Markus Noga 59
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öglicheAngeboteMöglicheAngebote
BetrachteteAngebote
GefundeneAngebote
Kardinalitäten für Matchen
Kardinalitätenfür Suche
Angebote MöglicheAngebote
Kardinalitätenfür Rückgabe
Dr. Welf Löwe und Markus Noga 60
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 Noga 61
Maklerarten
Lookup Lookup Register LookupRegister Admin
Anfragemakler(query trader)
EinfSelbständiger
Makler(standalone
trader)
acher Makler
(simple trader)
Lookup Register Admin Lookup Register Admin Lookup Register Admin
Sozialer Makler(linked trader)
Link
StellvertreterMakler
(proxy trader)
Komplett-Makler
(full-servicetrader)
Link ProxyProxy
Dr. Welf Löwe und Markus Noga 62
Markus L. Noga:
Was passiert hiermit?
Markus L. Noga:
Was passiert hiermit?
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). Dieverteilte Web-DB kommt in Sicht.Also: happy ORBing.
Dr. Welf Löwe und Markus Noga 63
Bestandteile von Corba
BasisdiensteInteroperabilitätIDL, RPC, ORB
ProtokolleGIOP IIOP
ErweiterteInteroperabilität
DII, Trading
MOF(reflection)
Facilities Services
Scriptsprachen Geschäftsobjecte
(businessobjects)
KomponentenCorbaBeans
Dr. Welf Löwe und Markus Noga 64
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/XMI - The Value of Interchange. Dr. Stephen A. Brodsky, IBM, Vortragam 5.2. 1999, OMG XMI BriefingOverview 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/
Dr. Welf Löwe und Markus Noga 65
I.2.1.3 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 Noga 66
Einige Beispiele
Electronic Commerce
ManufacturingTelecom Utility
VertikalFinancial Transportation Simulation Life Sciences
MOF XMI Data Warehouse
Business ObjectsHorizontal
Dr. Welf Löwe und Markus Noga 67
Beispiele für general facilities
Benutzerschnittstellen – Drucken– email– 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 Noga 68
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 Noga 69
Metadaten
Meta: griech. darüber, jenseitsMetadaten: Daten über Daten– Datenbeschreibung– Modellierung– Können reflexiv sein
Reflektion: Programm greift auf Metadaten zuSelbstmodifikation (intercession)kann Erkenntnisse nutzen
MetaebeneMetaebene((KonzeptebeneKonzeptebene))
MetadatenMetadaten
Daten,Code
Daten,Code
Beschreiben
Zugriff
RealitätRealität
Ändern
Dr. Welf Löwe und Markus Noga 70
Reflektion und Selbstmodifikation
Selbstmodifikation:
for all c in self.classes dohelpClass = makeClass(c.name+"help");for all a in c.attributes do
helpClass.addAttribute(copyAttribute(a));done;self.addClass(helpClass);
done;
Reflektion:
for all c in self.classes dogenerate_class_start(c);for all a in c.attributes do
generate_attribute(a);done;generate_class_end(c);
done;
Dr. Welf Löwe und Markus Noga 71
Ausspähen (Introspection)
Spezialfall der Reflektion: über fremde KomponentenBestimmen semantikbehafteter EigenschaftenWichtig für den Web-Komponenten-Supermarkt.
MetadatenMetadaten
Daten,Code
Daten,Code
MetaebeneMetaebene((KonzeptebeneKonzeptebene))
RealitätRealität
Beschreiben
Daten,Code
Daten,Code
Zugriff
Ändern
Dr. Welf Löwe und Markus Noga 72
Das Corba-Objekt
CORBA::Object
- get_implementation- get_interface- is_nil- create_request- is_a- duplicate- release- ....
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 ImplementierungMittel der Reflektion
Dr. Welf Löwe und Markus Noga 73
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 Noga 74
MOF im Bild
MODL
IDLIDL
IDL-Spezifikation
IDL-Spezifikation
MOFMOF
UMLUML
UML-Spezifikation
UML-Spezifikation
Abfrage/Navigation
Abfrage/Naviga
UmwandlungsroutinenUmwandlungsroutinen
tion
Daten-Instanz
Daten-Instanz
Daten-Instanz
Daten-Instanz
Dr. Welf Löwe und Markus Noga 75
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 Definitionlanguage) 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 manalle Klassen ansprechen kann (Methodeall_of_type)
Dr. Welf Löwe und Markus Noga 76
Zusammenfassung MOF
Die MOF unterstützt beliebige TypsystemeNeue Typsysteme können addiert werden, alte komponiert oder erweitert werdenBeziehungen innerhalb und zwischen TypsystemenInteroperabilität zwischen Typsystemen und -repositorienAutomatische Generierung von IDLReflektion/Introspektion unterstütztAnwendung auf Arbeitsflüsse (workflows), Datenbanken, Groupware, Geschäftsprozesse, data warehouses wird untersuchthttp://www.dstc.edu.au/MOF
Dr. Welf Löwe und Markus Noga 77
XMI
Extensible Markup Language Interchange FormatZweck– 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öglichVorteile– 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 Noga 78
XMI als Zwischenrepräsentation
XMIDevelopment Tools
ReportsDatabase Schema
Design SoftwareAssets
Repository
App2
App4App5
App1
App6 App3
6 Brücken von 6 Herstellern N*N-N = 30 Brücken.
Dr. Welf Löwe und Markus Noga 79
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 2000.– Sun: Java = portable Programme, XML = portable Daten
XMI: Vorgeschlagener Standard für CORBA: – XMI = UML + MOF + XML
Dr. Welf Löwe und Markus Noga 80
XML Austauschströme (Modelle) XML Austauschströme (Modelle)
UMLUML
Instanz UMLCWMInstanz UML
MOFInstanz
XML DTD (MetaModels) (spezifisch pro Typsystem)
XML DTD (MetaModels) (spezifisch pro Typsystem)
CWMDTD
UML 1.1DTD
MOF 1.1DTD
Überblick XMI
MOFMetametaModell
Metadata Definitionen& Management
MOFMetametaModell
Metadata Definitionen& Management
XMLSyntax
XMLSyntax
XMI
XMI
UMLMetamodell
Analysis & Design
UMLMetamodell
Analysis & Design
� Use
W3C
Extensible
Mark
Dr. Welf Löwe und Markus Noga 81
XMI als Zwischenrepräsentation
CaseTool CaseTool UMLUML
UML-Spezifikation
(in UML)
UML-Spezifikation
(in UML)
Abfrage/Navigation
durch WebQL, XML-QL
Abfrage/Navigation
durch WebQL, XML-QL
CaseTool-DTD
CaseTool-DTD UML-DTDUML-DTD
MOFMOF
CaseTool-SpezifikationSpezifikationCaseTool- Umwandlung
durchXML-
Leser/Schreiber
XML-
Umwandlung durch
Umwandlung durchXML-
Leser/Schreiber
XML-
Umwandlung durch
Leser/Schreiber
Leser/Schreiber
CaseTool-Spez. in XMLin XM
CaseTool-Spez.
L
UML-Spez.In XML (Seite)
In XML (Seite
UML-Spez.Darstellung mitStyle Sheetsin Browsern
Darstellung mitStyle Sheetsin Browsern )
Dr. Welf Löwe und Markus Noga 82
Ein reales Austauschszenario
IBM
VisualAge
Select
Unisys
UREP
Oracle
Repository
Rose DTDGen
Enterprise
MOF
DTDGen
Rational
Rose
Select
Enterprise
Oracle
Designer
XMI
XMIXMI
XMI
XMI
XMI
XMIXMI
XMI
Team
ConnectionWebSphere
VA Java
Aus: S. Brodsky, OMG XMI Briefing,Feb 5, 1999