Powerpoint

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;
exception CannotProceed {
struct NameComponent {
NamingContext cxt;
Istring id;
Name rest_of_name;
Istring kind;
};
};
exception InvalidName {};
typedef sequence <NameComponent> Name;
exception AlreadyBound {};
enum BindingType { nobject, ncontext };
exception NotEmpty {};
struct Binding {
Name binding_name;
interface BindingIterator {
BindingType binding_type;
boolean next_one(out Binding b);
};
boolean next_n(in unsigned long how_many,
typedef sequence <Binding> BindingList;
out BindingList bl);
interface BindingIterator;
void destroy();
interface NamingContext;
};
} NamingContext {
nterface
enum NotFoundReason { missing_node, not_context, not_object };
exception NotFound {
NotFoundReason why;
Name rest_of_name;
};
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;
try {
cxt= NamingContext._narrow( MyNaming.
resolve_initial_references(MyNaming.NameService));
public static void main(String argv[]) {
CosNaming.NamingContext.Ref cxt;
Calc5.calc_factory.Ref cf;
Frame f;
}
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
Licence service
manager
obtain_producer_
specific_license
License
manager
Producer specific
license service
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
I.2.2.2. Corba Anwendungsstandards
(Corba facilities)
Dr. Welf Löwe und Markus Noga
62
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
63
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
64
2.2. Corba Anwendungsgebiete (facilities)
Spezielle anwendungsspezifische
Komponentenrahmen/schnittstellen zur
Komponentenintegration
Dr. Welf Löwe und Markus Noga
65
2.2.1 Vertikale Anwendungsgebiete
(domain-specific facilities)
Vertikal (anwendungsorientiert)
Electronic
Commerce
Telecom
Manufacturing
Utility
Financial
Transportation
Simulation
Life Sciences
UML
MOF
Data
Warehouse
Business
Objects
Horizontal
(Plattform)
Dr. Welf Löwe und Markus Noga
66
Vertikale Anwendungsgebiete
(domain-specific facilities)
Domain Technology committee DTC ruft domain task forces DTF ins
Leben, um einen Anwendungsbereich zu spezifizieren.
Geschäftsprozessobjekte (business objects)
Finanzwirtschaft (finance/insurance)
–
Currency facility
Elektronischer Handel (electronic commerce)
Produktion (manufacturing)
–
product data management enablers PDM
Medizin (healthcare CorbaMed)
–
–
Lexocon Query Service
Person Identifier Service PIDS
Telekommunikation (telecommunications)
–
–
Audio/visual stream control object
notification service
Transport (transportation)
Manche sind schon implementiert
Dr. Welf Löwe und Markus Noga
67
2.2.2 Horizontale Anwendungsgebiete
(general facilities)
Benutzerschnittstellen
–
–
–
–
Drucken
email
Verbunddokumente: Seit 1996 OpenDoc als VerbunddokumentStandard akzeptiert. Source Code ist von IBM freigegeben worden.
Tot?
Scripting: in Corba 3.0 wird es eine Skriptsprache geben
Informationsmanagement
–
–
–
strukturierter Speicher Bento ist aufgenommen
Metadaten(meta object facility)
Datentransfer: Ein text- und strombasiertes Austauschformat wird
entwickelt (XMI)
Systemmanagment (Instrumentierung, Monitoring)
Dr. Welf Agenten)
Löwe und Markus Noga
Task management (Workflow, Regeln,
68
2.2.2.1 Metaobject Facility MOF
Problem: Wie generiere ich IDL aus einer Java-Anwendung heraus, für
die ich schon ein Datenmodell definiert habe?
Man würde gerne sagen:
for all c in classes do
generate_class_start(c);
for all a in c.attributes do
generate_attribute(a);
done;
generate_class_end(c);
done;
Dazu braucht man aber ein Typsystem, das das Java-Typsystem
beschreibt, also Klassen und Attribute anbietet
Andere ähnliche Probleme:
–
–
–

Wie generiere ich Code zum Datenaustausch zwischen C++ und Java?
Wie tausche ich Daten von OMT und UML-basierten CASE-Werkzeugen aus?
Wie binde ich andere Typsysteme als IDL in Corba ein (UML, ..)?
Wir brauchen also ein Typsystem, das IDL und andere Typsysteme
beschreibt!
Dr. Welf Löwe und Markus Noga 69
2.2.2.1 Metaobject Facility MOF
Die MOF (metaobject facility) ist das Typsystem, das Typsysteme beschreibt
Standardisiert Nov. 97
Dr. Welf Löwe und Markus Noga
70
Metadaten
Meta: (selbst-)beschreibend
Metadaten: beschreibende Daten (auch: sich selbstbeschreibende Daten)
Die Elemente der Metaebene (Metaobjekte) beschreiben die Elemente der Realität
Metamodellierung: Beschreibung der Elemente/Konzepte der Realität mit einem
Datenmodell, dem Metamodell
Metaebene
Konzeptebene
Metadaten
Realität
Daten,
Code,
Information
Dr. Welf Löwe und Markus Noga
71
Reflektion und Selbstmodifikation
Erst bei Verschmelzung des Metamodells mit dem Modell wird Reflektion möglich.
Die Anwendung kann sozusagen ihr eigenes Skelett anschauen und Schlüsse daraus
ziehen.
Manipuliert sie zusätzlich sich selbst und nutzt dabei das mit Reflektion gewonnene Wissen
aus, nennt man dies Selbstmodifikation (intercession).
Metadaten
Metaebene
Konzeptebene
Beschreiben
Daten,
Code,
Information
Realität
Dr. Welf Löwe und Markus Noga
72
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
73
Introspektion
Späht man das Metamodell sowie die Metadaten einer fremden Komponente aus,
um mehr über sie zu erfahren, nennt man dies Ausspähen (Introspektion)..
Die Komponente kann sozusagen das Skelett einer anderen Komponente anschauen
und Schlüsse daraus ziehen.
Typische Anwendung: Eigenschaften herausfinden, die mit Semantik behaftet sind,
Methoden, Attribute, Typen herausfinden.
Sehr wichtig im Web-Komponenten-Supermarkt!
Metadaten
Daten,
Code,
Information
Daten,
Code,
Information
Dr. Welf Löwe und Markus Noga
74
Reflektive Objektschnittstelle
CORBA unterstützt Reflektion und Introspektion schon durch die Pseudoschnittstelle
CORBA::OBJECT.
In Java existieren dazu die Klassen Object, Class, Method, etc.
Weiterhin wird das Interface Repository abgefragt werden (list_initial_references
aus der CORBA::ORB Schnittstelle).
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
75
Die Metaebenen von CORBA(Metahelix)
Die Elemente jeweils einer Ebene beschreiben die Elemente der nächstniederen Ebene.
Ein einfaches Metamodell einer Programmiersprache:
Metaebene
M1
Dinge
Metaobjekte
Modellart
Metamodell
M0
Programmobjekte
Modell
Beispiele
Typen der Abstrakten Syntax (AST mit
Klassen, Methoden, Anweisungen)
Das vollständige Metamodell über Typsystemen und Daten von CORBA:
Metaebene
M3
M2
M1
M0
M-1
Dinge
Metametadaten
Metadaten
Datenobjekte
Reale Objekte
Modellart
Metametamodell
Metamodell
Modell
"Reale Welt"
Reale Welt
Beispiele
MOF Modell
Typsystem (C++, IDL-System)
Typen (C++-Typ, IDL Typ)
Modellierte Systeme, Warenhaus-Datenbanken
Aktenordner, Rechnung, Kunde
Metametamodelle beschreiben beliebige Typsysteme!
Dr. Welf Löwe und Markus Noga
76
Die MOF als UML-Beschreibungsmittel
Auch die UML (unified modelling language) modelliert und kann metamodelliert werden.
Metaebene
M3
MOF Ausdrücke
Modellart
Metametamodell
M2
Metametadaten
Metamodell
M1
Metadaten
Modell
M0
Daten
Beispiele
Beschriebene Dinge (syntaktische
Elemente)
MOF Modell
Klassen, Relationen,
Pakete
UML Metamodell (als
Klassen, Relationen,
Strukturdiagramm), CWMI Zustände, UseCases,
Metamodell(e)
Aktoren
UML Modelle, Warenhaus- Dinge der Welt
Schemata
Modellierte Systeme,
Warenhaus-Datenbanken
Damit können mit Hilfe der MOF beliebige Typsysteme, Modellierungsprachen,
Programmiersprachen, u.ä. beschrieben werden. Mit Hilfe von Introspektion und Reflektion
können die Metadaten der Modelle abgefragt und bearbeitet werden.
Dr. Welf Löwe und Markus Noga
77
Das UML-Metamodell
Dr. Welf Löwe und Markus Noga
78
Die MOF als UML-Metametamodell
Dr. Welf Löwe und Markus Noga
79
Konzepte der MOF
Konzept
Class
Konzept in C++
Class
Constructor
Association inheritance
package Metadaten
exception exception
Abstract class Abstract class
Aggregation,
composition,
containment
RTTI, Java reflection
IDL
Interface
Operation
Äquivalenz von IDL und
C++-Klassen
Modell
exception
Reflexive Schnittstelle
Ein Paket kapselt ein Typsystem
Generische Funktionen, um auf Object zu
arbeiten get_value(Object attribute)
set_value(Object attributevalue)
Dr. Welf Löwe und Markus Noga
80
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
81
MOF - Zweck
Beschreibende Daten können also benutzt werden, um
Wissen über unbekannte Daten zu erlangen
in unbekannten Daten zu navigieren (Relationen sind ein
Konzept der MOF)
von unbekannten Daten aus zu generieren (z.B. IDL aus
Programmiersprachen)
Daten ineinander umzuwandeln (die Abbildung ist dann nur
noch eine Funktion im Metametamodell). Daher kann die
MOF benutzt werden, um Werkzeugaustauschformate zu
beschreiben und automatisch Umwandlungsroutinen zu
generieren.
Daten, die mit MOF-basierten Typsystemen beschrieben
sind, können automatisch in einander umgewandelt
werden, weil die Umwandlungsroutinen automatisch
Dr. Welf Löwe und Markus Noga 82
generiert werden können
Aufbau einer konkreten MOF
MOF Modell
MOF Typmanipulationsschnittstelle
MOF TypsystemManipulationsschnittstelle
TypsystemWerkzeug
(MODL)
IDL Generator
Server mit
Schnittstellenimplem.
Dr. Welf Löwe und Markus Noga
83
Die MOF als kleinster gemeinsamer Nenner
MODL
MOF
IDL
UML
IDLSpezifikation
UMLSpezifikation
DatenInstanz
Abfrage/Navigation
Umwandlungsroutinen
DatenInstanz
Dr. Welf Löwe und Markus Noga
84
Bootstrap
Natürlich kann die MOF mit der MOF durch einen Bootstrap
laufen:
–
–
Da die MOF ein Typsystem ist, kann man sie mit sich selbst
beschreiben und eine IDL für die MOF generieren
Damit kann man MOFs mithilfe von CORBA-ORBs verteilt ansprechen
(und an sich fremde Werkzeuge miteinander kommunizieren lassen)
Die MOF Beschreibungen mit XMI verschickt werden...
Dr. Welf Löwe und Markus Noga
85
Zusammenfassung MOF
Die MOF unterstützt beliebige Typsysteme
Neue Typsysteme können addiert werden, alte komponiert
oder erweitert werden
Beziehungen innerhalb und zwischen Typsystemen werden
unterstützt
Interoperabilität zwischen Typsystemen und -repositorien
Automatische Generierung von IDL
Reflektion/Introspektion unterstützt
Anwendung auf Arbeitsflüsse (workflows), Datenbanken,
Groupware, Geschäftsprozesse, data warehouses wird
untersucht
http://www.dstc.edu.au/MOF
Dr. Welf Löwe und Markus Noga
86
2.2.2.2 XMI - Das Austauschformat
XML: eXtensible Markup Language
–
–
–
–
–
–
–
–
enthält DTD-Definition (Document Type Definition, Semantikbeschreibungen
für Etiketen (tags)).
DTDs enthalten Metaobjekte, d.h. spezifizieren Metamodelle für Multimedia
Einige Ausprägungen: HTML, MathML, SpeechML, MusicML, VectorML
Ziel: erweiterbares, einfach strukturiertes Format zum Datenaustausch über
Programm- und Plattformgrenzen hinweg.
Vereinfachtes SGML (stets hierarchisch, einfachere Semantik)
Dedizierter Nachfolger von HTML
Microsoft: geplantes Datenformat für MS Office 2000.
Sun: Java = portable Programme, XML = portable Daten
XMI: Vorgeschlagener Standard für CORBA: UML in XMI, MOF-basiert
–
–
eXtended Markup language Interchange format
XMI = UML + XML + MOF
Dr. Welf Löwe und Markus Noga
87
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
88
XMI
Zweck
–
–
–
Neutrales, offenes Austauschformat für Metadaten (sprich UML) in
verteilten Umgebungen
Spätere Erweiterung auf data warehouses geplant
Semantische Beschreibung von Diensten (jenseits von
Eigenschaften/Properties) möglich
Vorteile
–
–
–
XMI generiert jeweils eine DTD für ein Typsystem. Die Basierung auf
der MOF sichert zu, dass die DTDs ineinander übersetzt werden
können (Interoperabilität)
Kompatibel mit Web-Standards sowie StandardModellierungssprachen
Unterstützt Übertragung von Differenz-Dokumenten (diffs) sowie
Erweiterungen von Metamodellen
Dr. Welf Löwe und Markus Noga
89
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
90
XMI als Zwischenrepräsentation
MOF
CaseTool
UML
CaseToolDTD
CaseToolSpezifikation
CaseToolSpez.
in XML
Umwandlung durch
XML-Leser/Schreiber
Abfrage/Navigation
durch WebQL,
die XML-QL
UML-DTD
Umwandlung durch
XML-Leser/Schreiber
Darstellung mit
Style Sheets
in Brausern
UMLSpezifikation
(in UML)
UML-Spez.
In XML
(Seite)
Dr. Welf Löwe und Markus Noga
91
Bereits funktionierendes Austauschsczenario
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
92
XMI Beispiel mit UML DTD
Da für jedes Typsystem eine DTD
generiert wird, kann auch für das MOF
eine DTD generiert werden.
Generiert wird nach speziellen
DTD-Generierungsregeln.
Ausserdem wird XML generiert (mit
XML-Generierungsregeln).
Business
Customer
id : CustId
update()
Dr. Welf Löwe und Markus Noga
93
XMI Beispiel mit UML DTD
<!-- Document Prologue, etc. -->
<Model xmi.id="a1">
<name>Business</name>
<visibility xmi.value="public"/>
<ownedElement>
<Class xmi. id="a7"><name>Customer</name>
<feature>
<Attribute><name>id</name>
<multiplicity><XMI.field>1</ XMI.field>
<XMI.field>1</XMI.field>
</multiplicity>
<type>< DataType href=”|a247"/></type> <!-- Custid -->
</Attribute>
<Operation><name>update</name>
<scope xmi.value="instance"/>
</Operation>
</feature>
</Class>
</ownedElement>
</Model>
Dr. Welf Löwe und Markus Noga
94
XMI Beispiel für Makler-Typsystem mit TraderDTD
<!DOCTYPE Trader SYSTEM "Trader.dtd">
<Trader XMI.Id="Trader_12">
<ServiceType XMI.Id="Service_1">
<BaseType.name> "Savings_Account" </BaseType.name>
<PropertyType XMI.Id="Property_1">
...
</PropertyType>
</ServiceType>
</Trader>
Trader-DTD:
<!ELEMENT Trader ((ServiceType|Inherits)*)>
<!ATTLIST Trader XMI.Id ID #IMPLIED >
<!ELEMENT ServiceType (BaseType.name, ServiceType.interface_type, (PropertyType)*)>
<!ATTLIST ServiceType XMI.Id ID #IMPLIED>
...
Dr. Welf Löwe und Markus Noga
95
XMI : Schnelle Standardisierung
12/97
SMIF (Stream based Model Interchange
Format) RFP der OMG
07/98
Erste Vorschläge XMI, CDIF, UOL
10/98
Verbesserter Vorschlag XMI
11/98
Demos
01/99
OMG akzeptiert
03/99
Erste Implementierungen
Dr. Welf Löwe und Markus Noga
96
XMI Zusammenfassung
XMI wird den Austausch von Daten, Metadaten zwischen verteilten
Werkzeugen revolutionieren
Closed systems ade!
DCOM wird nur noch als Verdrahtungsstandard eine Rolle spielen,
Corba enthält mit MOF und XMI das wesentlich flexiblere und
mächtigere Konzept, was zudem mit dem Web konform geht
MOF und XMI unterstützen beliebige erweiterbare Sprachen, sowohl
Modellierungs- als auch Programmiersprachen
–
–
der Weg ist frei für anwendungsspezifische Sprachen, die trotzdem
interoperabel sind
Entwurf kann mit der Anwendung angepassten Konzepten geschehen, und
trotzdem ist Interoperabilität garantiert.

Fixe Modellierungs- und Programmiersprachen sind tot,
es lebe die Metamodellierung!
Dr. Welf Löwe und Markus Noga
97
2.3 Corba, Web und Java
Neben den Standardisierungsbemühungen der OMG hat sich in den
letzten 5 Jahren Java und HTML/HTTP durchgesetzt.
HTTP dient nur zum Transport von Daten (CGI-Skripten-Schlamassel)
–
–
HTTP kann keine Methoden aufrufen, ausser durch CGI-GatewayFunktionalität (common gateway interface)
hinter der CGI-Schnittstelle steckt ein beliebiges Programm, mit dem von
HTTP aus - anstelle von getypten Parameterübergaben - mittels
Umgebungsvariablen kommuniziert wird (HACK!)
•
–
–
Untypisiert, nur einfache Argumente möglich (z.B. Werden Optionen in
merkwürdige Strings gepackt: arg2=xzy&arg3=kdkdkd),
http-Server sind eigentlich ORBs, Seiten entsprechen Objekten, die vermittelt
werden
Das URI/URL-Namensschema kann voll in Corba integriert werden
IIOP wird ein Standard-Internet-Protokoll.
–
Standard ports, URL-Abbildungen und Standard-Proxies für Firewalls werden
ohne Probleme verfügbar sein
CORBA ist also eine Erweiterung von HTTP von Daten auf Code
Dr. Welf Löwe und Markus Noga
98
Corba und Java
Java ist für Corba ein idealer Partner:
–
Bytecode ist mobil, d.h.
•
•
–
Seit 1999 existiert eine direkte Corba Unterstützung im JDK 1.2
•
–
sorgt als Applet dafür, dass Berechnungen auf den Kunden verschoben werden
können (thin/thick client Problem)
kann zur Migration von Objekten, ORBs und Agenten eingesetzt werden
IDL2Java Abbildung, IDL Übersetzer, Java2IDL Übersetzer, Namensdienst, ORB
Corba stellt für Java eine ergänzende verteilte Infrastruktur zur Verfügung
Java imitiert Funktionalitäten von Corba. Einfache Benutzung, aber javaspezifisch
–
–
–
Basisdienste: Remote Method Invocation RMI, Java Native code Interface JNI
Dienste: Serialisierung, Ereignisse
Anwendungsspezifische Dienste (facilities): Reflektion,
Eigenschaften/Properties von JavaBeans
Ansonsten aber komplementäre Funktionalitäten
–
–
DII: Dynamischer Aufruf mittels ORB ist flexibler als Polymorphie, die DispatchTabelle der Programmiersprache ist sozusagen ihr ORB
Gemischtsprachlichkeit. Corba-Protokolle sind
komplexer, da es nicht nur ooDr. Welf Löwe und Markus Noga 99
Programme bedient
Corba und das Web (Orblets)
ORBs können als Bytecode-Applets verschickt werden,
sofern sie nur in Java geschrieben sind (ORBlet)
Damit ergibt sich eine extrem interessante Kopplung von
HTTP und IIOP:



Herunterladen eines ORBlets mit HTTP
Ansprechen dieses ORBs, um mit dem Server Kontakt aufzunehmen
Server-ORB vermittelt Anfrage
Daher entfällt das CGI-Skripten-Schlamassel:
– HTTP kann nämlich keine Methoden aufrufen, ausser durch CGIGateway-Funktion
– hinter der CGI-Schnittstelle steckt ein beliebiges Programm, die
Kommunikation erfolgt über Umgebungsvariablen (HACK!)
Dr. Welf Löwe und Markus Noga
100
ORBlets
1) Hole Seite
Http server
2) Hole ORBlet
ORB
3) Kommuniziere mit IIOP
ORB
Server
Datenbanken
Lotus Notes
Geschäftsobjekte
Web-Client
Webserver
Dr. Welf Löwe und Markus Noga
101
Verschmelzung von CORBA und HTTP
Beides unkorreliert nebeneinander, CORBA mit IIOP auch
über TCP/IP
 Statt Java-Applets ORBlets einsetzen (mit JDK 1.2 ohne
Probleme möglich)
 CGI-CORBA-Gateway: Hinter CGI wird ein ORB
angeschlossen, der allerdings dann nur über CGI
angesprochen werden kann
 HTTP-IIOP-Gateway. Hierbei muss ein CORBA HTTPDienstanbieter die HTTP Anfragen bearbeiten. Damit
könnten die HTTP-Dienstanbieter sukzessive ersetzt
werden, um echte Interoperabilität zu erhalten

Dr. Welf Löwe und Markus Noga
102
ORBs
http://www.omg.org, Universität Wien (Wolfgang Lugmayer)
Java-basiert
–
–
–
–
–
–
IBM SOMObjects
SUN NEO, Joe: eigenes Protokoll sowie IIOP. Der Java Transaction Service
JTS ist der JOE Corba Object Transaction Service OTS.
IONA Orbixweb: In Java entwickelt, d.h. ORBlets möglich, C++, JavaAnwendungen
Visibroker (in Netscape integriert), ebenfalls IIOP basiert. Umgebung
Caffeine auf Visibroker ermöglicht es, aus Java IDL zu generieren. Damit
werden IDL Spezifikationen überflüssig.
Voyaer (ObjectSpace) (mit Mobilen Agenten)
Frei: JacORB, ILU, Jorba, DynaORB,
C-basiert
–
–
–
ACE ORB TAO, Universität Washington (Trader!9
Linux ORBIT (gnome)
Linux MICO (kde)
Python-basiert
–
fnorb
Dr. Welf Löwe und Markus Noga
103
Produkte
Jumping Beans: migrierende Beans auf der Basis von
mobilem Corba, Fehlertoleranz
Applixware
WebIntelligence (Business Objects America): OLAP
Transaktionsverarbeitung auf Webobjekten
Dr. Welf Löwe und Markus Noga
104
Corba OpenDoc
1996 wurde OpenDoc als Standard für zusammengesetzte
Dokumente angenommen
OpenDoc-Seiten sind Container von Corba-Komponenten
(shippable places)
–
–
–
Gegenüber html-Seiten bietet eine OpenDoc-Seite sie den Vorteil,
beliebig strukturiert zu sein, sowie aktive Komponenten zu enthalten
..in strukturierten Dateien ablegbar zu sein, auch verteilt
Verweise, Drag-and-drop von aktiven Seitenteilen möglich
Aus Corba-Sicht sind die Dokumente nur Objekte, die für
ihre Teile Bearbeitungsobjekte kennen
Fragen:
–
–
Integration mit HTML/XML/XMI?
Integration mit JavaBeans?
Dr. Welf Löwe und Markus Noga
105
Visionen für ein neues Komponenten-Web
Brauser ist ein Komponentendokument ist eine (OpenDoc-)Seite ist ein
shippable place
–
Brauser
•
•
–
Dokumente
•
•
–
–
–
Volle Verschiebbarkeit von Brauserfunktionalitäten: Schieben von URLs als aktive
Objekte in den Brauser und die Dokumente hinein, z.B. Als toolbars
Erweiterbarkeit durch neue Komponenten
beliebige Formen von aktiven Dokumententeilen
Volle visuelle Verschiebbarkeit von aktiven Seitenteilen, in-place editing aller Teile
Laden von Seiten entspricht dem drag-and-drop von Komponenten in
Komponenten
Einkaufen als Drag-and-drop in Container hinein
Der Desktop wird zum Brauser (als Container von aktiven verteilten Objekten)
Gamelons (www.gamelon.com) sind Containersysteme für
Komponenten (verschieben, speichern, verteilen)
Dr. Welf Löwe und Markus Noga
106
Shippable Places
Ein shippable place ist ein visuelles Ensemble von
Komponenten, der über das Netz verschickt werden kann.
(visible bean, Bohne, jar, EJB, ActiveX)
– eine Miniwelt (personalisiert als Desktop,
HTML-Seiten wearable, Autoeinstellung)
–HTMLpersistent, kommunizierend mit ORBs
HTTP
Applets
IIOP
CGI
ORB-HTTP
Server
ORB
Shippable
Places
Datenbanken
Lotus Notes
Geschäftsobjekte
Dr. Welf Löwe und Markus Noga
107
2.4 Corba 3.0 - 1999
–
–
–
–
–
–
–
–

Basisdienste:
POA, die 2. Generation von BOAs
SFA, Server Framework Adapter
Mehrfachschnittstellen (multiple interfaces) und
zusammengesetzte (komponierte) Objekte
Wertobjekte
Versionen
Services:
Message Service MOM. Objekte als asynchrone
gepufferte Botschaften
Corba Beans-Komponenten
Skriptsprache
Facilities: Zusammengesetzte Dokumente, Mobile
Agenten, BOF (business object facility)
Dr. Welf Löwe und Markus Noga
108
POA Portable Object Adapter
Der POA ist eine Weiterentwicklung der BOA Schnittstelle,
die Erfahrungen der letzten Jahre sind eingebaut. Flexibler
Geschachtelte POAs möglich, dadurch geschachtelte
Namensräume
ORB kann hinter POA ausgetauscht werden, war mit BOA
nicht möglich
Policies für Objektverwaltung: Anmeldung von
benutzergeschriebenen Instanzenmanagern möglich zur
Verwaltung von Objektinstanzen
Liste von Instanzmanagern
Liste von aktiven Dienst-Objekten
Dr. Welf Löwe und Markus Noga
109
SFA Server Framework Adapter
.. sind sprachspezifische Adapterschnittstellen für den POA.
.. vereinfachen die Benutzung eines POA
.. benutzen Spracheigenschaften wie Vererbung, um die
Anbindung an Corba so einfach wie möglich zu gestalten
Dr. Welf Löwe und Markus Noga
110
Objekt-Komposition
durch mehrere Schnittstellen pro Objekt
–
–
Mehrfachvererbung auf Schnittstellen (statisches Konzept)
Entwurfsmuster Fassade: Aggregation und Delegation können verwendet
werden, um Funktionen der Schnittstelle auf andere Objekte abzuwälzen.
Damit ist eine Schnittstelle nur eine Fassadenklassen. Konzept auch in
Request
DCOM/ActiveX realisiert
Dog
Cat
Mouse
Animal
Create
Dr. Welf Löwe und Markus Noga
111
MOM - Message Oriented Middleware
Jedes Objekt im Web soll eine Mailbox bekommen
–
–
–
–
–
Pufferung aller Nachrichten (auch strukturierte Dateien)
Nachrichten können selbst Objekte sein (Objektmigration)
Laptops, Palmtops werden unterstützt
Callback-Objekte können mit Nachrichten mitgegeben werden. Diese
werden vom Empfänger der Nachricht aufgerufen
MOA: Message Object Adapter spielt eine Rolle ähnlich zum BOA und
POA, die Vermittlung zwischen Netz und Dienstgeber
Dr. Welf Löwe und Markus Noga
112
Corbabohnen (Corba Beans)
Mehrfachschnittstellen (multiple interfaces)
Wertobjekte
Introspektion
Direkte AbbildungBOF
aufBusiness
Java Beans
Object Facility
 Geschäftsbasisobjekte (analog zu Enterprise JavaBeans) bauen auf mehreren Diensten auf (Persistenz,
Transaktionen, Ereignisse, Lizensierung)
 anwendungsspezifische alsabgeleitete Objekte
 Komponentendefinitionssprache als Erweiterung von IDL.
 Anreicherung von semantischen Eigenschaften wie Verhalten, Aussichten, Regeln, Triggern, Restriktionen
 Geschäftsobjekt-Dienst: Container, Qualitätsmerkmale (Quality of Service), Query
 Semantische Nachrichten: selbstbeschreibende Nchrichten
Dr. Welf Löwe und Markus Noga
113
2. 5. Was haben wir gelernt?
Was zeichnet Corba als Komponentensysteme aus?
Wie erfüllt Corba unsere Kriterien aus der Einleitung?
Dr. Welf Löwe und Markus Noga
114
Ziele erfüllt?
 Erhöhung Wiederverwendung
 Produktqualität
 Qualitätsverbesserung
 Effektivität durch Konzentration auf
 ja
 ja
 ?
 ja, wegen mehr Transparenz
Optimierungen
 Verlässlichkeit
 Verlängerung Lebensdauer
 Flexibilisierung
 Verbesserungen am Softwareprozess
 Produktivität
 Schneller Prototypenbau
 Simulation von Architekturen
 Dokumentation
 Klare Systemstrukturen
 ? (Sicherheit)
 ja
 ja
 jein
 ? nein
 nein
 ja
 ja
 ja
Dr. Welf Löwe und Markus Noga
115
Desiderata für flexible Systemkomposition
 Modularer Austausch von Komponenten

Geheimnisprinzig (information hiding): explizite Spezifikation von Schnittstellen (Kontakt- oder Austauschpunkte)
 Adaption von Komponenten
 Interne Adaption von Komponenten an ihren Wiederverwendungskontext

Offene Implementierung, Austausch von nicht-funktionalen Aspekten
 Externe Adaption: Generierung von Klebecode für Zusammenarbeit

Kommunikation, Synchronisation, Verteilung
 Aspekttrennung (Aspektkomposition)
 klarere Spezifikationen und trotzdem effiziente Implementierungen
 Transparenz
 Verteilung, Service-Identität, Programmiersprache, Persistenz
 Migration (Mobilität)
Dr. Welf Löwe und Markus Noga
116
Corbas Mechanismen zur Modularisierung

Schnittstellen für Gemischtsprachlichkeit




IDL wird zur Spezifikation von Schnittstellen benutzt
..und die MOF zur Spezifikation von Typsystemen incl. IDL
Schnittstellen werden im Interface Repository gespeichert und
nachgeschlagen
Standardisierung von Schnittstellen für


DII, Dienste, Anwendungsdienste
wesentliches Merkmal eines Komponentensystems
Technische vs. Anwendungsspezifische vs
Fachkomponenten: Corba bietet zwar
– Standards für technische und anwendungsspezifische Komponenten
– .. aber an Fachkomponenten-Standards muss noch viel gefeilt werden
(vertical facilities) (that´s where the money is)
Dr. Welf Löwe und Markus Noga
117
Corbas Mechanismen zur Adaptierbarkeit
IDL Generatoren werden zur Erzeugung von Kleister-Code
eingesetzt
 Object Adapter kapseln Objekte auf Dienstgeberseite


Schnittstellen BOA, POA
Objektidentität (IOR) verbirgt Implementierungsdetails der
Objekte
 Metadaten:MOF und die XMI werden eingesetzt, um
automatisch Stromformate von Werkzeugen ineinander
umzusetzen
 GIOP General Inter ORB Protocol spezifiziert einen
Rahmenprotokoll, dass die ORBs verstehen
 keine interne Adaptierbarkeit

Dr. Welf Löwe und Markus Noga
118
Mechanismen zur Aspekttrennung

Mehrere Schnittstellen pro Objekt



Mehrfachvererbung auf Schnittstellen (statisch, mit CodeWiederverwendung)
Dynamisch ab 3.0 durch Komposition, Aggregation mit Entwurfsmuster
Fassade
keine statische Aspekttrennung
Dr. Welf Löwe und Markus Noga
119
Mechanismen zur Transparenz
OMA 3-Schichtenarchitektur (3-tier architecture) mit
statischem Aufruf und dynamischem Aufruf
 Marshalling durch IDL
 IOR
 Lebendigkeit oder Nichtlebendigkeit wird verborgen durch
Objekt-Adapter
 Persistenz
 Bei MOF-basierten Typsystemen Konvertierbarkeit garantiert
 Migration durch Java und mobile Agenten

Dr. Welf Löwe und Markus Noga
120
Fazit
Die Corba-Schnittstellen sind sehr flexibel, funktionieren und können in
der Praxis eingesetzt werden
.. aber auch komplex und umfangreich, vielleicht zu flexibel für die
Praxis
Corba hat den Vorteil, ein offener Standard zu sein, DCOM kommt da
erst so langsam nach. Gegenüber DCOM wird wesentlich schon über
den Verdrahtungsstandard hinaus normiert (facilites, services)
XMI könnte ein grosser Knüller werden, ebenso OpenDoc
Freie ORBs in Linux könnten Corba schieben
Java für neue Software, Corba für gemischte Alt-Neu-Systeme
Wann kommt das Komponenten-Web? Gibt es ein Leben nach HTML?
Wann kommt Elektronischer Handel, und auf welcher Basis?
Wann können alle Corba 3.0?
Dr. Welf Löwe und Markus Noga
121