Transcript Software aus Komponenten SS 2001

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 Noga
1
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 Noga
2
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 Noga
3
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 CorbaEntwicklungen.
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
Dr. Welf Löwe und Markus Noga
4
Corba
Common Object Request Broker Architecture
Gründung der OMG (object management group) 1989. Ziel: plug-andplay 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
Dr. Welf Löwe und Markus Noga
5
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
6
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
7
Bestandteile von Corba
Basisdienste
Interoperabilität
IDL, RPC, ORB
Erweiterte
Interoperabilität
DII, Trading
Protokolle
GIOP IIOP
MOF
(reflection)
Facilities
Services
Scriptsprachen
Geschäfts
objecte
(business
objects)
Komponenten
CorbaBeans
Dr. Welf Löwe und Markus Noga
8
Die OMA (object management architecture)
Application Interfaces Domain Interfaces
Common Facilities
Object Request Broker
Object Services
Dr. Welf Löwe und Markus Noga
9
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
10
ORB
Client
IDL
Dynamic
Invocation Stub
Server/Object Implementation
ORB
Interface
IDL
Dynamic
Skeleton
Skeleton
Object
Adapter
ORB Kern
ORB-abhängig
Standardisiert
Objekttyp-abhängig
Dr. Welf Löwe und Markus Noga
11
ORB Verfeinerte Sicht
Dr. Welf Löwe und Markus Noga
12
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 Noga
13
Interface Definition Language
Typen
Module <identifier> {
<type declarations>
<constant declarations>
<exception declarations>
Objekte
Nicht-Objekte
ReferenzObjekte
// Klassen
interface <identifier> : <inheriting-from> {
<type declarations>
<constant declarations>
<exception declarations>
// Methoden
optype <identifier>(<parameters>) {
...
Any
}
....
Bool
}
}
Enum
Wertobjekte
Basistypen
Konstruktoren
Ints (short,..)
Struct
Reals
Typen
(float..)
Sequence
Char, string,
Union
octet
Array
Dr. Welf Löwe und Markus Noga
14
Ablauf IDL-Codegenerierung
IDL Interface
Server
Implementation
Implementation
Repository
Objektadapter/
BOA
IDLCompiler
Server
Skeleton
Client
Stub
Client
Implementation
Compiler
Server
Client
Dr. Welf Löwe und Markus Noga
15
Der (Basis-)Objektadapter BOA
CORBA::BOA
-
Create
change_implementation
get_id
dispose
set_exception
impl_is_ready
obj_is_ready
deactivate_impl
deactivate_obj
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)
Dr. Welf Löwe und Markus Noga
16
Serverseite
Server / Object Implementation
impl_is_
ready
deactivate_
obj
object_is_
ready
deactivate_
impl
IDL
BOA
Skeleton
ORB Kern
Dr. Welf Löwe und Markus Noga
17
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 Noga
18
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
Dr. Welf Löwe und Markus Noga
19
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 Noga
20
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
21
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
22
Der Objektanfragen-Vermittler ORB
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
....
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.
Dr. Welf Löwe und Markus Noga
23
ORB-Aktivierung auf dem Klienten
Objekt
CORBA
ORB
ORB_init
Initialisiert den Vermittler
BOA_init
List_initial_services
resolve_initial_references
Initialisiert den Server-BOA
Liefert Strings
Liefert Objektreferenzen
Dr. Welf Löwe und Markus Noga
24
Beispiel IDL
//TestTimeServer.idl
module TestTimeServer{
interface ObjTimeServer{
string getTime();
};
};
Dr. Welf Löwe und Markus Noga
25
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 Noga
26
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 Noga
27
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 Noga
28
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
29
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
ObjektSchlüssel
Dr. Welf Löwe und Markus Noga
30
Beispiel: IOR
Client
IDL:My
Obj:1.0
Server
Bobo:
1805
OA4,
obj_999
Obj_999
OA4
Obj_998
Obj_997
Dr. Welf Löwe und Markus Noga
31
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
32
Bestandteile von Corba
Basisdienste
Interoperabilität
IDL, RPC, ORB
Erweiterte
Interoperabilität
DII, Trading
Protokolle
GIOP IIOP
MOF
(reflection)
Facilities
Services
Scriptsprachen
Geschäfts
objecte
(business
objects)
Komponenten
CorbaBeans
Dr. Welf Löwe und Markus Noga
33
Überblick Corba Dienste (Services)
16+ standardisierte Dienstschnittstellen (in IDL definiert).
Implementierungsstand je nach Anbieter
http://www.cetus-links.org/oo_object_request_brokers.html
Einteilbar in
– Objektdienste: Dienste zur Verwaltung von Objekten (d.h.
Komponenten im CORBA-Sinn)
– Zusammenarbeitsdienste: Dienste, die Zusammenarbeit von
Objekten betreffen
– Geschäftsprozessdienste: Dienste, die stärker in Richtung
Anwendung definiert sind und vorgefertigte Funktionalitäten für
Geschäftsanwendungen bereitstellen.
Dr. Welf Löwe und Markus Noga
34
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
35
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
36
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
37
Abhängigkeiten zwischen den Diensten
Makler
Transaktionen
Query
Persistenz
Lizenzen
Serialisierung
Sicherheit
Container
Eigenschaften
Allokation
Namen
Sperren
Relationen
Rückruf
Ereignisse
Dr. Welf Löwe und Markus Noga
38
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
39
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 Noga
40
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
-
Dr. Welf Löwe und Markus Noga
41
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
42
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
43
Erzeugen von Namen
Systemabhängiger
Name
Suche/Erzeuge
Namensraum
Erzeuge Name
Namensraum
Corba-Name
Bindung
Objekt
Suche Name
Dr. Welf Löwe und Markus Noga
44
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
45
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
46
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 Noga
47
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 Noga
48
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
49
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
50
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 Noga
51
Lizenz-Szenario
Hole Lizenzdienst
Kunde
Hole Lizenz
Liefere Lizenz
Liefere
Lizenzdienst
Cos::
License
Manager
Abstrakte Fabrik
Hersteller
abhängiger
Lizenzdienst
Konkreter Dienst
Lizenzsystem
(auch entfernt)
Herstellerstrategie
Dr. Welf Löwe und Markus Noga
52
Schnittstelle
LicenseServiceManager
– obtain_specific_license_service
SpecificLicenseService
– start_use
– check_use
– end_use
Dr. Welf Löwe und Markus Noga
53
Lizenzprotokoll
Kunde
obtain_producer_
specific_license
License
manager
Producer specific
license service
Licence service
manager
Event
service
Start_use
Initial check_use
check_use
Ask for event
Event notification (license there)
End_use
Dr. Welf Löwe und Markus Noga
54
Geschäftsprozessdienste: Makler
Makler handeln mit
Diensten (services,
service types)
Vermittlermuster
Makler
Exportiere
Funktionalität
Dienst
Importiere
Funktionalität
Interagiere
Kunde
Dr. Welf Löwe und Markus Noga
55
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
Mandatory, readonly
Mandatory
readonly
(normal)
Dr. Welf Löwe und Markus Noga
56
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 Noga
57
Dienst-Hüpfen (hopping)
Makler 1
Fluß der
Eigenschaften
der Dienstanfrage
Angebote der Makler
Policies, die die Werte
der Eigenschaften der
Dienstanfrage verändern
Makler 2
Makler 4
Makler 3
Dr. Welf Löwe und Markus Noga
58
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
Betrachtete
Angebote
Gefundene
Angebote
Kardinalitäten
für Matchen
Kardinalitäten
für Suche
Angebote
Mögliche
Angebote
Kardinalitäten
für Rückgabe
Dr. Welf Löwe und Markus Noga
59
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
60
Maklerarten
Lookup
Lookup
Anfragemakler
(query trader)
Lookup
Register
Sozialer Makler
(linked trader)
Link
Register
Lookup
Lookup
Register
Stellvertreter
Makler
(proxy trader)
Proxy
Admin
Selbständiger
Makler
(standalone
trader)
Einfacher Makler
(simple trader)
Admin
Register
Admin
Lookup
Register
Admin
KomplettMakler
(full-service
trader)
Link
Proxy
Dr. Welf Löwe und Markus Noga
61
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). Die
verteilte Web-DB kommt in Sicht.
Also: happy ORBing.
Dr. Welf Löwe und Markus Noga
62
Bestandteile von Corba
Basisdienste
Interoperabilität
IDL, RPC, ORB
Erweiterte
Interoperabilität
DII, Trading
Protokolle
GIOP IIOP
MOF
(reflection)
Facilities
Services
Scriptsprachen
Geschäfts
objecte
(business
objects)
Komponenten
CorbaBeans
Dr. Welf Löwe und Markus Noga
63
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, Vortrag
am 5.2. 1999, OMG XMI Briefing
Overview of XMI. Sridhar Iyengar, Unisys Corporation, 5.2.99, OMG
XMI Briefing,
XML Metadata Interchange (XMI) Proposal to the OMG RFP3: Streambased Model Interchange Format SMIF. OMG, 20.10.98
http://www.omg.org/
Dr. Welf Löwe und Markus Noga
64
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
65
Einige Beispiele
Electronic
Commerce
Telecom
Manufacturing
Utility
Financial
Transportation
Simulation
Life Sciences
MOF
XMI
Vertikal
Horizontal
Data
Warehouse
Business
Objects
Dr. Welf Löwe und Markus Noga
66
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
67
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
68
Metadaten
Meta: griech. darüber, jenseits
Metadaten: Daten über Daten
Zugriff
Reflektion: Programm greift auf
Metadaten zu
Selbstmodifikation (intercession)
kann Erkenntnisse nutzen
Metadaten
Beschreiben
– Datenbeschreibung
– Modellierung
– Können reflexiv sein
Metaebene
(Konzeptebene)
Realität
Daten,
Code
Ändern
Dr. Welf Löwe und Markus Noga
69
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 Noga
70
Ausspähen (Introspection)
Spezialfall der Reflektion: über fremde Komponenten
Bestimmen semantikbehafteter Eigenschaften
Wichtig für den Web-Komponenten-Supermarkt. Metaebene
(Konzeptebene)
Metadaten
Beschreiben
Daten,
Code
Ändern
Realität
Daten,
Code
Dr. Welf Löwe und Markus Noga
71
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
Mittel der Reflektion
Dr. Welf Löwe und Markus Noga
72
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
73
MOF im Bild
MODL
MOF
IDL
UML
IDLSpezifikation
UMLSpezifikation
DatenInstanz
Abfrage/Navigation
Umwandlungsroutinen
DatenInstanz
Dr. Welf Löwe und Markus Noga
74
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 Noga
75
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
http://www.dstc.edu.au/MOF
Dr. Welf Löwe und Markus Noga
76
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 Noga
77
XMI als Zwischenrepräsentation
Software
Assets
Design
Development
Tools
Database
Schema
XMI
Repositor
y
Reports
6 Brücken von 6 Herstellern
App1
App2
App6
App3
App5
App4
N*N-N = 30 Brücken.
Dr. Welf Löwe und Markus Noga
78
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
79
 U
s
e
W
3
C
E
x
t
e
n
s
i
b
l
e
M
a
r
k
u
p
Überblick XMI
UML
Instanz
UML
MOF
MetametaModell
Metadata Definitionen
& Management
UML
Metamodell
Analysis & Design
MOF
Instanz
UML
XML Austauschströme (Modelle)
X
M
I
UML 1.1
DTD
XML
Syntax
CWM
Instanz
UML
CWM
DTD
MOF 1.1
DTD
XML DTD (MetaModels)
(spezifisch pro Typsystem)
Dr. Welf Löwe und Markus Noga
80
XMI als Zwischenrepräsentation
MOF
CaseTool
UML
CaseToolDTD
CaseToolSpezifikation
CaseToolSpez.
in XML
Umwandlung durch
XML-Leser/Schreiber
Abfrage/Navigation
durch WebQL,
XML-QL
UML-DTD
Umwandlung durch
XML-Leser/Schreiber
Darstellung mit
Style Sheets
in Browsern
UMLSpezifikation
(in UML)
UML-Spez.
In XML
(Seite)
Dr. Welf Löwe und Markus Noga
81
Ein reales Austauschszenario
Web
Sphere
Team
Connection
Rose
XMI
DTD
Gen
IBM
VA
Java
XMI
VisualAge
Oracle
Repository
XMI
XMI
Select
XMI
Oracle
Designer
XMI
Unisys
XMI
UREP
XMI
Rational
Rose
MOF
DTDGen
Enterprise
XMI
Select
Enterprise
Aus: S. Brodsky, OMG XMI Briefing,
Dr. Welf Löwe und Markus Noga
Feb 5, 1999
82