Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,

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


Aufgaben kommerzieller Systeme(Corba, (D)COM, EJB)

Daten- und Interface-Beschreibung

Referenz- und Wertesemantik

Kommunikation (Nachrichten und RMI)

Verteilung, Persistenz, Heterogenität

Softwarebus


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


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.90DM Corba 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


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, 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.2Corba 3.0 1999


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)


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)



Geschäftsobjecte

(businessobjects)

ErweiterteInteroperabilität

DII, Trading

KomponentenCorbaBeans

Scriptsprachen

MOF(reflection)

Services

ProtokolleGIOP IIOP

Facilities

BasisdiensteInteroperabilitätIDL, RPC, ORB


Die OMA (object management architecture)

Object Request Broker

Object Services

Application Interfaces Domain Interfaces Common Facilities


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


ORB

Client Server/Object Implementation

ObjectAdapter

DynamicInvocation

IDLStub

ORBInterface

IDLSkeleton

DynamicSkeleton

ORB Kern

ORB-abhängig

Standardisiert

Objekttyp-abhängig


ORB Verfeinerte Sicht


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 DienstesInteroperable Object Reference (IOR): Objekte und Komponenten erhalten eindeutige IORs


Interface Definition Language

Module <identifier> { <type declarations> <constant declarations> <exception declarations>

// Klassen interface <identifier> : <inheriting-from> { <type declarations> <constant declarations> <exception declarations> // Methoden optype <identifier>(<parameters>) { ... } .... }}

TypenTypen

TypenTypen

Ints (short,..)Ints (short,..)

KonstruktorenKonstruktorenBasistypenBasistypen

Nicht-ObjekteNicht-ObjekteObjekte Objekte

Reals (float..)Reals (float..)

StructStruct

Char, string, Char, string, UnionUnion

SequenceSequence

ArrayArrayoctetoctetEnumEnum

BoolBool

AnyAny

Referenz-Objekte

Referenz-Objekte WertobjekteWertobjekte


Ablauf IDL-Codegenerierung

IDL InterfaceIDL Interface

ClientImplementation

ClientImplementation

ServerImplementation

ServerImplementation

CompilerCompiler

IDL-Compiler

IDL-Compiler

Server Skeleton

Server Skeleton

ClientStub

ClientStub

Client Client

ImplementationRepository

Objektadapter/BOA

Objektadapter/BOA Server Server


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


Serverseite

BOAIDLSkeleton

ORB Kern

Server / Object Implementation

deactivate_obj

deactivate_impl

impl_is_ready

object_is_ready


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.


Objektaktivierung auf dem Server

Server Objekt1 Objekt2 CORBA::BOA

Create

get_id

obj_is_ready

obj_is_ready

Impl_is_ready

deactivate_obj

deactivate_obj

deactivate_impl


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)


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


Das Corba-Objekt

Das Corba Objekt vererbt sich als Klasse auf alle Corba-Objekte und Programmelemente.

get_interface liefert eine Referenz auf den Eintrag im interface repository.

get_implementation eine Referenz auf die Implementierung

CORBA::Object

- get_implementation- get_interface- is_nil- create_request- is_a- duplicate- release- ....


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


ORB-Aktivierung auf dem Klienten

Objekt CORBA ORB

ORB_init

BOA_init

List_initial_services

resolve_initial_references

Liefert Strings

Liefert Objektreferenzen

Initialisiert den Server-BOA

Initialisiert den Vermittler


Beispiel IDL

//TestTimeServer.idl

module TestTimeServer{ interface ObjTimeServer{ string getTime(); };};


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

};


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

}};


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

}};


Beispielausführung

C:\> java TimeServer_Server

IOR:00000000000122342435 …

C:\> java TimeServer_Client IOR:00000000000122342435 …

Time: 14:35:44


IOR (interoperable object reference)

Verbirgt Objektreferenzen der Programmiersprachen, ist pro Programmiersprache eindeutig abgebildet (für alle ORBs)transient (verschwindet mit Server) oder persistent (lebt weiter). Bestandteile:– Typnamen (type code), d.h. Indices in das Interface Repository– Protokoll und Adressinformation (z.B. beim IIOP TCP/IP port #, host name), auch für

verschiedene zugleich unterstützte Protokolle– Objektschlüssel (object key).

• Opaques Datum, nur vom erzeugenden ORB lesbar (Zeiger)• Object-Adaptername (für den BOA), Objectname

Type Name(repository id)

Type Name(repository id)

Protokoll u.Adresse

Protokoll u.Adresse

Objekt-Schlüssel

Objekt-Schlüssel


Beispiel: IOR

IDL:MyObj:1.0

IDL:MyObj:1.0

Bobo:1805

Bobo:1805

OA4,obj_999

OA4,obj_999

Obj_997Obj_997

Obj_999Obj_999

Obj_998Obj_998OA4OA4

Client Server


I.2.1.2 Corba Dienste (Corba services)

OMG. CORBAservices: Common Object Service Specifications. http://www.omg.org. Version vom Dez. 98.

http://www.omg.org/

http://www.omg.org/

http://www.omg.org/



Geschäftsobjecte

(businessobjects)


DII, Trading


Scriptsprachen

MOF(reflection)

Services

ProtokolleGIOP IIOP

Facilities



Überblick Corba Dienste (Services)

16+ standardisierte Dienstschnittstellen (in IDL definiert).

Implementierungsstand je nach Anbieterhttp://www.cetus-links.org/oo_object_request_brokers.html

Einteilbar in– Objektdienste: Dienste zur Verwaltung von Objekten (d.h.

Komponenten im CORBA-Sinn)– Zusammenarbeitsdienste: Dienste, die Zusammenarbeit von

Objekten betreffen– Geschäftsprozessdienste: Dienste, die stärker in Richtung

Anwendung definiert sind und vorgefertigte Funktionalitäten für Geschäftsanwendungen bereitstellen.

http://www.cetus-links.org/oo_object_request_brokers.html

















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)


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.


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.


Abhängigkeiten zwischen den Diensten

Namen

Allokation

Relationen

Persistenz

Serialisierung

Sperren

Transaktionen

Query

Makler

Eigenschaften

Sicherheit

Ereignisse

Lizenzen

ContainerRückruf


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.


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.


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


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


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

};


Bindung

Suche/ErzeugeNamensraum

Erzeugen von Namen

Systemabhängiger Name

Corba-Name

Suche Name

Namensraum

Erzeuge Name

Objekt


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


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


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


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


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


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!


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.


Lizenz-Szenario

KundeKundeKundeKundeCos::LicenseManager

HerstellerabhängigerLizenzdienst

Hersteller-strategie

Lizenzsystem(auch entfernt)

Abstrakte Fabrik

Konkreter Dienst

Hole Lizenzdienst

Liefere Lizenzdienst

Hole Lizenz

Liefere Lizenz


Schnittstelle

LicenseServiceManager– obtain_specific_license_service

SpecificLicenseService– start_use– check_use– end_use


Lizenzprotokoll

Kunde Licence servicemanager

Producer specificlicense service

Licensemanager

Eventservice

obtain_producer_specific_license Start_use

Initial check_useInquiry

Ask for event

Event notification (license there)

check_use

End_use


Geschäftsprozessdienste: Makler

Makler

KundeDienst

Vermittlermuster

Interagiere

ImportiereFunktionalität

ExportiereFunktionalität

Makler handeln mitDiensten (services,service types)


Wann ein Dienst gegen anderen ersetzen (Konformität)?

gleiche Schnittstelle oder abgeleitete Schnittstelle

alle Sucheigenschaften identisch definiert – keine Properties vom Corba Dienst Properties

alle Modi der Eigenschaften stärker oder gleich

(normal)

Mandatory, readonly

Mandatory readonly


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


Makler 4

Makler 1

Dienst-Hüpfen (hopping)

Makler 1

Makler 3

Makler 2

Policies, die die Werteder Eigenschaften derDienstanfrage verändern

Fluß derEigenschaftender Dienstanfrage

Angebote der Makler


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

Angebote MöglicheAngebote

GefundeneAngebote

BetrachteteAngebote

Kardinalitätenfür Suche

Kardinalitäten für Matchen

Kardinalitätenfür Rückgabe


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

)


Maklerarten

Anfragemakler(query trader)

Lookup

Einfacher Makler

(simple trader)

Lookup

Selbständiger Makler

(standalone trader)

LookupRegister RegisterAdmin

Sozialer Makler(linked trader)

Lookup Register Admin

Link

Stellvertreter Makler

(proxy trader)


Proxy

Komplett- Makler

(full-service trader)


Link Proxy


Korrigendum

Laut Orfali, Harkey "Instant Corba" gibt es doch wesentlich mehr Dienste, die schon von ORBs unterstützt werden.

Alle unterstüten C++, Java, IIOP, DII.

Alle unterstützen Ereignisse, Naming, Livecycle, Transaktionen (!!), Sicherheit.

Der Rest wird lückenhaft unterstützt.

Insbesondere werden damit ORBs zu ernsthaften Konkurrenten für Transaktionsmonitore (TP-Monitore). Die verteilte Web-DB kommt in Sicht.

Also: happy ORBing.

Markus L. Noga:

Was passiert hiermit?

Markus L. Noga:

Was passiert hiermit?



Geschäftsobjecte

(businessobjects)


DII, Trading


Scriptsprachen

MOF(reflection)

Services

ProtokolleGIOP IIOP

Facilities



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: Stream-based Model Interchange Format SMIF. OMG, 20.10.98 http://www.omg.org/

http://www.omg.org/

http://www.omg.org/

http://www.omg.org/

http://www.omg.org/


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


MOF XMI Data Warehouse

Business Objects

Financial Transportation Simulation Life Sciences

Electronic Commerce

Telecom Manufacturing Utility

Vertikal

Horizontal

Einige Beispiele


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)


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


Metadaten

Meta: griech. darüber, jenseits

Metadaten: Daten über Daten– Datenbeschreibung

– Modellierung

– Können reflexiv sein

Reflektion: Programm greift auf Metadaten zu

Selbstmodifikation (intercession) kann Erkenntnisse nutzen

MetadatenMetadaten

Daten,Code

Daten,Code

MetaebeneMetaebene(Konzeptebene)(Konzeptebene)

RealitätRealität

Beschreiben

Zugriff

Ändern


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;


Ausspähen (Introspection)

Spezialfall der Reflektion: über fremde Komponenten

Bestimmen semantikbehafteter Eigenschaften

Wichtig für den Web-Komponenten-Supermarkt.

MetadatenMetadaten

Daten,Code

Daten,Code

MetaebeneMetaebene(Konzeptebene)(Konzeptebene)

RealitätRealität

Beschreiben

Daten,Code

Daten,Code

Zugriff

Ändern


Das Corba-Objekt

Das Corba Objekt vererbt sich als Klasse auf alle Corba-Objekte und Programmelemente. get_interface liefert eine Referenz auf den Eintrag im interface repository.get_implementation eine Referenz auf die ImplementierungMittel der Reflektion

CORBA::Object

- get_implementation- get_interface- is_nil- create_request- is_a- duplicate- release- ....


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


MOF im Bild

IDLIDL

IDL-Spezifikation

IDL-Spezifikation

MOFMOF

UMLUML

Umwandlungsroutinen

Umwandlungsroutinen

UML-Spezifikation

UML-Spezifikation

Daten-Instanz

Daten-Instanz

Daten-Instanz

Daten-Instanz

Abfrage/Navigation

Abfrage/Navigation

MODL


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 man alle Klassen ansprechen kann (Methode all_of_type)


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







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


XMIDevelopment Tools

Reports

Database

Schema

Design Software

Assets

Repository

App2

App4App5

App1

App6 App3

6 Brücken von 6 Herstellern N*N-N = 30 Brücken.

XMI als Zwischenrepräsentation


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


XML Austauschströme (Modelle)

XML Austauschströme (Modelle)

XML DTD (MetaModels) (spezifisch pro Typsystem)

XML DTD (MetaModels) (spezifisch pro Typsystem)

CWMDTD

UML 1.1DTD

MOF 1.1DTD

Überblick XMI

XMLSyntax

XMLSyntax

MOFMetametaModell

Metadata Definitionen

& Management

MOFMetametaModell

Metadata Definitionen

& Management

XMI

XMI

UMLMetamodell

Analysis & Design

UMLMetamodell

Analysis & Design

UML

UML Instanz UML

CWM Instanz UML

MOF Instanz

Use W3C Extensible Markup Language (XML) for the transfer syntax and interchange format

Specify XML Document Type Definitions (DTD) to enable transfer and verification of

UML based models (using UML DTD)

MOF based metamodels and their instances (Allows use of XMI in new domains - Data Warehouse, Components…)

Specify a precise MOF to XML mapping

Allows interchange of any MOF based metamodel and corresponding models (MOF--> XML Stream)

Enables automatic generation of DTDs for any MOF based metamodel (MOF --> XML DTD)

Use UML and MOF for metamodel design


XMI als Zwischenrepräsentation

CaseTool CaseTool

CaseTool-Spezifikation

CaseTool-Spezifikation

MOFMOF

UMLUML

Umwandlung durch

XML-Leser/Schreiber

Umwandlung durch

XML-Leser/Schreiber

UML-Spezifikation

(in UML)

UML-Spezifikation

(in UML)

CaseTool-Spez. in XML

CaseTool-Spez. in XML

UML-Spez.In XML (Seite)

UML-Spez.In XML (Seite)Abfrage/

Navigationdurch WebQL,

XML-QL

Abfrage/Navigation

durch WebQL, XML-QL

Darstellung mitStyle Sheetsin Browsern

Darstellung mitStyle Sheetsin Browsern

CaseTool-DTD

CaseTool-DTD UML-DTDUML-DTD

Umwandlung durch

XML-Leser/Schreiber

Umwandlung durch

XML-Leser/Schreiber

Dr. Welf Löwe und Markus Noga 82Aus: S. Brodsky, OMG XMI Briefing, Feb 5, 1999

IBM

VisualAge

Select

Unisys

UREP

Oracle

Repository

Rose

DTDGen

Enterprise

MOFDTDGen

Rational Ros

e

SelectEnterpris

e

OracleDesigne

r

XMI

XMIXMI

XMI

XMI

XMI

XMIXMI

XMI

TeamConnectio

n

WebSphere

VA Java

Ein reales Austauschszenario

Documents

Dr. Welf Löwe und Markus Noga1 Gliederung: Teil I - Grundlagen 1. Einführung –Motivation –Definition, –Konzepte für Komponenten (klassische, kommerzielle,