Gliederung: Teil I - Grundlagen · (Services, Facilities) Selbstbeschreibung (Metaobjekte, MOF)...

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-BeschreibungReferenz- und WertesemantikKommunikation (Nachrichten und RMI)Verteilung, Persistenz, Heterogenität

Softwarebus


Gliederung

Literatur, Ziele, BestandteileBasis-Mechanismen für – Kommunikation,– modulare Austauschbarkeit, – Adaption

Mechanismen zur Standardisierung von Schnittstellen(Services, Facilities)Selbstbeschreibung (Metaobjekte, MOF)Corba und das WebAustauschformat XMI


I.2.1.1 Corba Grundlagen

R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. Wiley&Sons. Leicht zu lesen.R. Orfali, D. Harkey, J. Edwards: Instant Corba. Addison-Wesly. Deutsch. Leicht zu lesen, aber einige konzeptionelle ÜbersetzungsfehlerCORBA. Communications of the ACM, Oct. 1998. Neueste Corba-Entwicklungen.Jens-Peter Redlich, CORBA 2.0 / Praktische Einführung für C++ und Java. Verlag: Addison-Wesley, 1996. ISBN: 3-8273-1060-1, 59.90DMCorba 2.2 Specification. OMG. http://www.omg.orgVorträge aus dem Web:– Von der OMG:

• Java Portability and CORBA Integration, Dr. Richard Soley, CEO, OMG, April, 1999

• Application Server Market Summary. Paul Harmon, Editor, Component Development Strategies Newsletter


Corba

Common Object Request Broker ArchitectureGründung der OMG (object management group) 1989. Ziel: plug-and-play components everywhere

When the Object Management Group (OMG) was formed in 1989, interoperabilitywas its founders primary, and almost their sole, objective:

A vision of software components working smoothly together, without regard to details of any component's location, platform, operating system, programming language, or network hardware and software.

Jon Siegel

Corba 1.1 1991 (IDL, ORB, BOA)ODMG-93 (Standard für oo-Datenbanken)Corba 2.0 1995, heute 2.2Corba 3.0 1999


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)



BasisdiensteInteroperabilitätIDL, RPC, ORB

ProtokolleGIOP IIOP

ErweiterteInteroperabilität

DII, Trading

MOF(reflection)

Facilities Services

Scriptsprachen Geschäftsobjecte

(businessobjects)

KomponentenCorbaBeans


Die OMA (object management architecture)

Domain Interfaces Common FacilitiesApplication Interfaces

Object Request Broker

Object Services


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

Server/Object Implementation

DynamicInvocation

IDLStub

ORBInterface

IDLSkeleton

DynamicSkeleton

ORB Kern

Client

ObjectAdapter

ORB-abhängigStandardisiertObjekttyp-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 interfaceDII: Neben normaler Polymorphie kennt Corba das dynamische Suchen eines Services, das transparente Erwecken eines DienstesInteroperable Object Reference (IOR): Objekte und Komponenten erhalten eindeutige IORs


Interface Definition Language

TypenTypenModule <identifier> {

<type declarations><constant declarations><exception declarations>

// Klasseninterface <identifier> : <inheriting-from> {<type declarations><constant declarations><exception declarations>// Methodenoptype <identifier>(<parameters>) {

...}....

}}

Objekte t

Typen(float..float..Typen

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

KonstruktorenKonstruktorenBasistypenBasistypen

Nicht-ObjekteNicht-ObjekteReferenz-Objekte

Referenz-Objekte WertobjekteWertobjekte

Objek e

StructStruct

Reals )Reals ( )

Char, string, Char, string, UnionUnion

SequenceSequenceAnyAny

BoolBool

EnumEnum octetoctet ArrayArray


Ablauf IDL-Codegenerierung

IDL InterfaceIDL InterfaceIDL-

CompilerIDL-

Compiler

ClientImplementation

ClientImplementation

ServerImplementation

ServerImplementation

CompilerCompiler

ServerSkeleton

ServerSkeleton

ClientStub

ClientStub

ImplementationRepository

Objektadapter/BOA

Objektadapter/BOA Client Client Server Server


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

Server / Object Implementation

IDLSkeleton

impl_is_ready

object_is_ready

deactivate_obj

deactivate_impl

BOA

ORB Kern


Servermodelle

Gemeinsamer Serverprozess (Shared-Server)– mehrere Objekte in einem Prozess auf dem Server; – BOA initialisiert sie als nebenläufige Fäden (threads) mit gemeinsamen

Adressraum (gemeinsames Apartment)– BOA Funktionen deactivate_impl, impl_is_ready, obj_is_ready abgebildet auf

thread-FunktionenSeparater Serverprozess (Unshared-Server)– Hier wird für jedes Objekt ein eigener Prozess auf dem Server verwaltet.

Methoden-Prozess (Server-per-Method)– Jeder Methodenaufruf erzeugt einen neuen Prozess.

Persistenter Server– Hier startet eine andere Anwendung die Objekte (z.B. Eine Datenbank).– BOA reicht die Anfragen nur durch.


Objektaktivierung auf dem Server

Server Objekt1 Objekt2 CORBA::BOAImpl_is_ready

Createobj_is_ready

get_idobj_is_ready

deactivate_objdeactivate_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öglichDa 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

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


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 KlientenObjekt CORBA ORB

ORB_init Initialisiert den VermittlerBOA_init Initialisiert den Server-BOA

List_initial_services Liefert Strings

resolve_initial_references Liefert Objektreferenzen


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üsselObjekt-

Schlüssel


Beispiel: IOR

Client Server

IDL:MyObj:1.0

IDL:MyObj:1.0

Bobo:1805

Bobo:1805

OA4,obj_999OA4,

obj_999

Obj_997Obj_997

Obj_999Obj_999

Obj_998Obj_998OA4OA4


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/




ProtokolleGIOP IIOP


DII, Trading

MOF(reflection)

Facilities Services


(businessobjects)



Überblick Corba Dienste (Services)

16+ standardisierte Dienstschnittstellen (in IDL definiert). Implementierungsstand je nach Anbieterhttp://www.cetus-links.org/oo_object_request_brokers.htmlEinteilbar in– Objektdienste: Dienste zur Verwaltung von Objekten (d.h.

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

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

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

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

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

Makler

Namen

Allokation

Relationen

Persistenz Serialisierung

Sperren

Transaktionen

Query

Sicherheit

Lizenzen

ContainerRückruf

EreignisseEigenschaften


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önnenEigenes Namensschema, – Verwendet nicht Betriebssystems- oder URL-Konventionen.– Dadurch Transparenz der Implementierung des Namens.– Zur Manipulation von Namen existiert eine eigene Bibliothek

(Entwurfsmuster Fabrik).– Ein Name besteht aus einem Tupel: Id, Type

• Id: eigentlicher Name, das • Art: Repräsentation (z.B. c_source, object_code, executable, postscript,..).

wird nicht vom Namensdienst, sondern nur von der Anwendung manipuliert.Ein Dateisystem bildet ein einfachen Namensraum.


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

};


Erzeugen von Namen

SystemabhängigerName

Bindung

Suche/ErzeugeNamensraum

Corba-Name

Erzeuge Name

Namensraum

Objekt

Suche Name


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 StringsDienst verwaltet Listen von Eigenschaften für ObjekteKonzept bekannt als assoziative Arrays, LISP property lists, Java property classes

Dynamisch erweiterbarIteratoren für EigenschaftswertePropertySetDef als verfeinerte Klasse, die den Eigenschaften mehr semantische Bedeutung zuordnet: readonly, fixed_readonly, …Schnittstelle: define_property, define_properties, get_property_value, get_properties, delete_property, ...


Objektdienste: Persistenz

Dienst– Persistentes (Server) Objekt über IOR kennt einen Persistent Object

Identifier PID, – Identifiziert serialisierten Zustand eines CORBA-Objektes auf dem

Speichermedium. – Protokoll zum Abspeichern/Laden auf/von Sekundärspeicher

Operationen connect, disconnect, store, restore, deleteAnbindung von beliebigen Speicherwerkzeugen möglich– Relationale Datenbanken– Filesystem


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, ersteigertAbstrakte Fabrik für Lizenzmanager, – die für beliebige Komponenten herstellerabhängige Strategien liefert.– Beispiele: Einzelplatzlizenzen, übertragbare Lizenzen (floating licenses),

Netzwerklizenzen, Campuslizenzen, etc. – Flexibel, über die Zeit veränderbar – Anwendung nicht verändert.– Feingranular

Granularität der Lizenzen: – Lizenzen durch ORB-Anfragen bezahlt. – kleine Komponenten Geld zu verlangen und quasi automatisch zu

bezahlen. – Kommerzielle, private Nutzung kann automatisch unterschieden werden.


Lizenz-Szenario

KundeKundeKundeKunde

Hole Lizenzdienst

HerstellerabhängigerLizenzdienst

Konkreter Dienst

Hole LizenzLiefere Lizenz

Cos::LicenseManager

Hersteller-strategie

Lizenzsystem(auch entfernt)

Abstrakte Fabrik

Liefere Lizenzdienst


Schnittstelle

LicenseServiceManager– obtain_specific_license_service

SpecificLicenseService– start_use– check_use– end_use


Lizenzprotokoll

Licensemanager

Producer specificlicense service

Licence servicemanager

Eventservice

Kunde

obtain_producer_specific_license

Start_use

Initial check_useInquiry

Ask for eventcheck_use

Event notification (license there)

End_use


Geschäftsprozessdienste: Makler

Makler handeln mitDiensten (services,service types)

Vermittlermuster

Makler

Kunde

ExportiereFunktionalität

ImportiereFunktionalität

DienstInteragiere


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

gleiche Schnittstelle oder abgeleitete Schnittstellealle Sucheigenschaften identisch definiert – keine Properties vom Corba Dienst Properties

alle Modi der Eigenschaften stärker oder gleich

Mandatory, readonly

(normal)

Mandatory readonly


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


Dienst-Hüpfen (hopping)

Makler 4

Makler 1Makler 1

Makler 3

Makler 2

Fluß derEigenschaftender Dienstanfrage

Angebote der Makler

Policies, die die Werteder Eigenschaften derDienstanfrage verändern


Suche nach Diensten

Parametrisierung von Maklern und Links durch sog. policies. policies beeinflussen verschiedene Phasen von Suche und Weitergabe, z.B.

– max_search_card: Obergrenze für zu suchende Angebote– max_match_card: Obergrenze für Rückgabe passender Angebote– max_hop_count: Obergrenze für Suchtiefe über Makler

MöglicheAngeboteMöglicheAngebote

BetrachteteAngebote

GefundeneAngebote

Kardinalitäten für Matchen

Kardinalitätenfür Suche

Angebote MöglicheAngebote

Kardinalitätenfür Rückgabe


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

Lookup Lookup Register LookupRegister Admin

Anfragemakler(query trader)

EinfSelbständiger

Makler(standalone

trader)

acher Makler

(simple trader)

Lookup Register Admin Lookup Register Admin Lookup Register Admin

Sozialer Makler(linked trader)

Link

StellvertreterMakler

(proxy trader)

Komplett-Makler

(full-servicetrader)

Link ProxyProxy


Markus L. Noga:

Was passiert hiermit?

Markus L. Noga:

Was passiert hiermit?

Korrigendum

Laut Orfali, Harkey "Instant Corba" gibt es doch wesentlich mehr Dienste, die schon von ORBs unterstützt werden.Alle unterstüten C++, Java, IIOP, DII.Alle unterstützen Ereignisse, Naming, Livecycle,Transaktionen (!!), Sicherheit.Der Rest wird lückenhaft unterstützt.Insbesondere werden damit ORBs zu ernsthaften Konkurrenten für Transaktionsmonitore (TP-Monitore). Dieverteilte Web-DB kommt in Sicht.Also: happy ORBing.




ProtokolleGIOP IIOP


DII, Trading

MOF(reflection)

Facilities Services


(businessobjects)



Literatur

Orfali, Harkey: Client-Server Programming with Java and Corba. Wiley.Schön zu lesen. Empfehlenswert zur Prüfungsvorbereitung.Orfali, Harkey: Instant Corba. Addison-Wesley. Nachttisch-Lektüre.Empfehlenswert zur Prüfungsvorbereitung.OMG: CORBAfacilities: Common Object Facilities Specifications.http://www.omg.org/XMI - The Value of Interchange. Dr. Stephen A. Brodsky, IBM, Vortragam 5.2. 1999, OMG XMI BriefingOverview of XMI. Sridhar Iyengar, Unisys Corporation, 5.2.99, OMG XMI Briefing, XML Metadata Interchange (XMI) Proposal to the OMG RFP3: Stream-based Model Interchange Format SMIF. OMG, 20.10.98 http://www.omg.org/

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


Einige Beispiele

Electronic Commerce

ManufacturingTelecom Utility

VertikalFinancial Transportation Simulation Life Sciences

MOF XMI Data Warehouse

Business ObjectsHorizontal


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, jenseitsMetadaten: Daten über Daten– Datenbeschreibung– Modellierung– Können reflexiv sein

Reflektion: Programm greift auf Metadaten zuSelbstmodifikation (intercession)kann Erkenntnisse nutzen

MetaebeneMetaebene((KonzeptebeneKonzeptebene))

MetadatenMetadaten

Daten,Code

Daten,Code

Beschreiben

Zugriff

RealitätRealität

Ändern


Reflektion und Selbstmodifikation

Selbstmodifikation:

for all c in self.classes dohelpClass = makeClass(c.name+"help");for all a in c.attributes do

helpClass.addAttribute(copyAttribute(a));done;self.addClass(helpClass);

done;

Reflektion:

for all c in self.classes dogenerate_class_start(c);for all a in c.attributes do

generate_attribute(a);done;generate_class_end(c);

done;


Ausspähen (Introspection)

Spezialfall der Reflektion: über fremde KomponentenBestimmen semantikbehafteter EigenschaftenWichtig für den Web-Komponenten-Supermarkt.

MetadatenMetadaten

Daten,Code

Daten,Code

MetaebeneMetaebene((KonzeptebeneKonzeptebene))

RealitätRealität

Beschreiben

Daten,Code

Daten,Code

Zugriff

Ändern


Das Corba-Objekt

CORBA::Object

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

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


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

MODL

IDLIDL

IDL-Spezifikation

IDL-Spezifikation

MOFMOF

UMLUML

UML-Spezifikation

UML-Spezifikation

Abfrage/Navigation

Abfrage/Naviga

UmwandlungsroutinenUmwandlungsroutinen

tion

Daten-Instanz

Daten-Instanz

Daten-Instanz

Daten-Instanz


Beispiel: Makler in MOF MODL

Package trader {class property_type {

attribute string name;attribute TypcCode value_type;

}class service_type {

attribute string name;attribute string interface_type;

}association has {

role single service_type service;role set [0..*] of property_type property;

}association inherits {

role set [0..*] of service_type base;role set [0..*] of service_type derived;

}}

Abbildung von MODL (MOF Definitionlanguage) auf IDL:

- attributes in set/get-Funktionen- associations in Link-Klassen

und Link-Sequence-Klassen- MODL generiert eine Klasse, die

spezielle Methoden enthält, mit der manalle Klassen ansprechen kann (Methodeall_of_type)


Zusammenfassung MOF

Die MOF unterstützt beliebige TypsystemeNeue Typsysteme können addiert werden, alte komponiert oder erweitert werdenBeziehungen innerhalb und zwischen TypsystemenInteroperabilität zwischen Typsystemen und -repositorienAutomatische Generierung von IDLReflektion/Introspektion unterstütztAnwendung auf Arbeitsflüsse (workflows), Datenbanken, Groupware, Geschäftsprozesse, data warehouses wird untersuchthttp://www.dstc.edu.au/MOF

http://www.dstc.edu.au/MOF

http://www.dstc.edu.au/MOF


XMI

Extensible Markup Language Interchange FormatZweck– Neutrales, offenes Austauschformat für Metadaten (sprich UML) in

verteilten Umgebungen– Spätere Erweiterung auf data warehouses geplant– Semantische Beschreibung von Diensten (jenseits von

Eigenschaften/Properties) möglichVorteile– XMI generiert jeweils eine DTD für ein Typsystem. Die Basierung auf der

MOF sichert zu, dass die DTDs ineinander übersetzt werden können(Interoperabilität)

– Kompatibel mit Web-Standards sowie Standard-Modellierungssprachen– Unterstützt Übertragung von Differenz-Dokumenten (diffs) sowie

Erweiterungen von Metamodellen


XMI als Zwischenrepräsentation

XMIDevelopment Tools

ReportsDatabase Schema

Design SoftwareAssets

Repository

App2

App4App5

App1

App6 App3

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


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)

UMLUML

Instanz UMLCWMInstanz UML

MOFInstanz

XML DTD (MetaModels) (spezifisch pro Typsystem)

XML DTD (MetaModels) (spezifisch pro Typsystem)

CWMDTD

UML 1.1DTD

MOF 1.1DTD

Überblick XMI

MOFMetametaModell

Metadata Definitionen& Management

MOFMetametaModell

Metadata Definitionen& Management

XMLSyntax

XMLSyntax

XMI

XMI

UMLMetamodell

Analysis & Design

UMLMetamodell

Analysis & Design

� Use

W3C

Extensible

Mark


XMI als Zwischenrepräsentation

CaseTool CaseTool UMLUML

UML-Spezifikation

(in UML)

UML-Spezifikation

(in UML)

Abfrage/Navigation

durch WebQL, XML-QL

Abfrage/Navigation

durch WebQL, XML-QL

CaseTool-DTD

CaseTool-DTD UML-DTDUML-DTD

MOFMOF

CaseTool-SpezifikationSpezifikationCaseTool- Umwandlung

durchXML-

Leser/Schreiber

XML-

Umwandlung durch

Umwandlung durchXML-

Leser/Schreiber

XML-

Umwandlung durch

Leser/Schreiber

Leser/Schreiber

CaseTool-Spez. in XMLin XM

CaseTool-Spez.

L

UML-Spez.In XML (Seite)

In XML (Seite

UML-Spez.Darstellung mitStyle Sheetsin Browsern

Darstellung mitStyle Sheetsin Browsern )


Ein reales Austauschszenario

IBM

VisualAge

Select

Unisys

UREP

Oracle

Repository

Rose DTDGen

Enterprise

MOF

DTDGen

Rational

Rose

Select

Enterprise

Oracle

Designer

XMI

XMIXMI

XMI

XMI

XMI

XMIXMI

XMI

Team

ConnectionWebSphere

VA Java

Aus: S. Brodsky, OMG XMI Briefing,Feb 5, 1999

Gliederung: Teil I - Grundlagen · (Services, Facilities) Selbstbeschreibung (Metaobjekte, MOF)...

Documents

Transcript of Gliederung: Teil I - Grundlagen · (Services, Facilities) Selbstbeschreibung (Metaobjekte, MOF)...