Die TINA Plattform Smalltalk-DPE

Inhalt

"Intellectual violence is the intentional use of terminology unfamiliar to an individual or a group.", [Mow97] p. 267.

Die DPE

Die Applikation Tn_DPE umfasst alle (IDL-spezifizierten) Klassen (bzw. deren abstrakte Oberklassen), die die DPE-Funktionalitaet (teilweise) verwirklichen, wie sie z.B. in [Eck97a], [Eck97b] und [Wun97] beschrieben ist.

Klassen der Applikation Tn_DPE

* = DST bzw. VisualWorks -Klasse


*Dictionary
	TnStruct


*DSTUnion
	TnUnion


*DSTPersistentObject
	TnInterface
		TnCapsuleFinder
		TnCapsuleManager
		TnClusterManager
		TnInterfaceObject
			TnManagementInterface
			more subclasses: Interface classes


*Object
	TnObject
		TnObjectFactory
		TnCoreObject
			subclasses: (optional) CoreObject classes
		TnModule
			TnDpeModule (in Applikation Tn_Common)
			more subclasses: TnXyzModule classes

	

TnStruct

Oberklasse aller IDL-spezifizierten Dictionaries.

TnUnion

Oberklasse aller IDL-spezifizierten Unions.

TnInterface

Abstrakte Oberklasse aller Interfaces (incl. DPE-Klassen).

TnCapsuleFinder

Registriert sich im Nameservice. Jeder CapsuleManager traegt sich (mit einer Liste seiner CO-Typen) unter einer Id im CapsuleFinder ein. COs erhalten auf Anfrage alle CapsuleManager, die alle COs eines gegebenen ClusterTemplates erzeugen koennen. (Siehe unten: Ablauf eines Requests)

TnCapsuleManager

Anlaufstelle fuer Requests zur Erzeugung der Cluster in der Capsule. Registriert sich mit einer Liste der CO-Typen der Capsule im CapsuleFinder. Loescht die Capsule. (Siehe unten: Ablauf eines Requests) (Ersetzt den TnConfigurationManager der ersten DPE)

TnClusterManager

Nach aussen NICHT sichtbare (nicht ansprechbare) Objekte zur Capsule internen Verwaltung derjenigen COs, die mittels eines Request gemeinsam erzeugt wurden. Ein Cluster hat keinen Typ. Welchen Sinn das Cluster (als Teilmenge der COs einer Capsule) macht, bestimmt derjenige, der diese spezifische Zusammenstellung anfordert. Ein Cluster Manager ist lediglich fuer den "life cycle" seiner COs zustaendig, d.h. bisher Erzeugung und Loeschung seiner COs. Er erreicht seine COs nur ueber deren Management-Interfaces, die er aufbewahrt. (Ersetzt den TnLifeCycleManager der ersten DPE)

TnInterfaceObject

Oberklasse der operationalen Interfaces der Capsule (die auf ein CO verweisen). Interfaces koennen eine Vererbungslinie bilden.

TnManagementInterface

Subclass von TnInterfaceObject. Instanzen werden den COs automatisch zugeteilt.

TnObject

Abstrakte Oberklasse aller (moeglichen) Tn-Klassen.

Bietet Methoden an, um das Image und den ORB zu initialisieren:

"TnObject resetCapsule" schliesst alle Tn-GUIs und entfernt Instanzen und Dependencies (ObjectMemory, ORB-StartUpCoordinator).
"TnObject resetORB" initialisiert den ORB und die ORBDaemons und konfiguriert den ORB mittels eines (mit dem TnDSTSystemSettings Tool erzeugten) Configuration Files, falls vorhanden.
"TnObject resetAll" macht beides.

TnObjectFactory

Erzeugt komplette COs incl. Interfaces oder (kuenftig, nachtraeglich) einzelne Interfaces fuer ein CO. (Siehe unten: Zum Factory Begriff in Smalltalk)

TnCoreObject

Optionale Oberklasse der CoreObjects der COs (ersetzt TnComputationalObject)

TnModule

Abstrakte Oberklasse der Moduleklassen der einzelnen IDL-Module. Eine konkrete Modulklasse (z.B. TnDpeModule) implementiert die gemeinsamen Constants (Enums), Exceptions, Exception Signals, Praefixe etc. des Moduls. Die Klasse befindet sich jetzt in der Applikation Tn_DPE und nicht mehr in Tn_Common.

Die DPE Tools

Die Applikation Tn_DPE_Tools enthaelt Tools zur Handhabung der DPE-Objekte (vor allem Klassen und Oberklassen der GUIs und Launcher). (Siehe die Tools-Helptexte)

Klassen der Applikation Tn_DPE_Tools

* = DST bzw. VisualWorks -Klasse


(TnObject in Tn_DPE)
	TnSupport
	TnTranscript


*ApplicationModel
	*DSTSystemSettings
		TnDSTSystemSettings

	TnGui
		TnCapsuleSettings
		TnCapsuleStatistics
		TnLauncher
			TnInstallationLauncher
				TnCapsuleFinderLauncher
				TnEndUserSystemLauncher
			TnCapsuleLauncher
				subclasses: specific Capsule Launcher classes
			TnNameServiceEditor
		TnDataManagement
			TnUserManagement
			TnAuthManagement

TnSupport

TnSupport stellt Utilities zur Verfuegung, um

- CORBA-Instanzen lokaler Klassen zu erhalten,
- CapsuleManager vom CapsuleFinder zu erhalten,
- Templates (BEO-, Cluster-) zu erzeugen,
- ASCII-Helptexte einzulesen und anzuzeigen sowie HTML-Helptexte an Netscape zu uebergeben,
- Informationen ueber ein Objekt anzuzeigen, ohne den Inspector zu benutzen,
- BOSS-Files zu schreiben und zu lesen,
- Den Klassennamen zu einer Interface RepositoryId zu erhalten.
u.a.

(Ersetzt TnORBConnection)

TnTranscript

Sollte statt Transcript verwendet werden, da die Anzeige ueber TnTranscript per CapsuleLauncher abschaltbar ist.

TnDSTSystemSettings

Sind erweiterte DSTSystemSettings. Neu daran ist die Moeglichkeit, die Settings-Parameter zu speichern und zu laden. Das kann auch ohne Oeffnen des GUIs (per Methodenaufruf) erfolgen. Nuetzlich zum schnellen und/oder automatischen Konfigurieren des Images.

TnGui

Die Oberklasse aller Guis und Launcher.

TnCapsuleSettings

Ein Tool mit dem die Listen der COs und der Interfaces, sowie die CapsuleId, die ein CapsuleManager verwaltet, editiert werden koennen. (Ausbaubar fuer alle Settings und Options der Capsule.) (Siehe unten Capsule handling)

TnCapsuleStatistics

Ein Tool das Informationen ueber die Cluster und deren COs einer Capsule anzeigt. Es ist nuetzlich, weil ein "inspect" im CapsuleLauncher auf den CapsuleManager ohne weiteres nur dessen ClusterManager und deren Sammlungen von Management-Interfaces zugaenglich macht. (Nach Bedarf ausbaubar.)

TnLauncher

Die Oberklasse aller Launcher

TnInstallationLauncher

Die abstrakte Oberklasse der Launcher, die dazu dienen, ein Objekt handhaben (starten) zu koennen, ohne Code in einen Workspace schreiben zu muessen (so wie ein CapsuleLauncher den CapsuleManager verwaltet), die aber keine weiteren Funktionen (buttons) anbieten. Subclasses sind der CapsuleFinderLauncher und der EndUserSystemLauncher.

TnCapsuleFinderLauncher

Handhabt den CapsuleFinder. Ein CapsuleFinder kann mit dem Launcher aus jedem Image heraus gestartet, im NameService registriert und inspiziert werden.

TnEndUserSystemLauncher

Startet - wie in der ersten DPE - die UserApplication (das kann erst geschehen, wenn die ORB-Verbindung da ist. Der Launcher ist deshalb zwingend zum Start eine Runtime Images noetig.

TnCapsuleLauncher

TnCapsuleLauncher handhabt den CapsuleManager. (Ersetzt TnApplicationLauncher).

- oeffnet TnCapsuleSettings,
- oeffnet TnCapsuleStatistics,
- oeffnet TnDSTSystemSettings,
- ermoeglicht automatische ORB-Configuration beim Image-Start.
- ermoeglicht Installation/Deinstallation/Inspect des CapsuleManagers (Reregister-Funktion faellt weg, da nicht mehr sinnvoll),
- bietet frei belegbare Buttons an.

TnNameServiceEditor

Neu im Vergleich zum ehemaligen NameServiceLauncher: Der NameServiceEditor ermoeglicht interaktive Eingabe und permanentes Speichern einer NameSpace Hierarchie.
Statt den NameSpace hart codiert in einer Methode zu implementieren (wie in der ersten DPE), wird er im Editor aufgebaut und dann als Default (in einer Klassenvariable) gespeichert. Dieser Default kann auch in ein File geschrieben oder aus ihm gelesen werden.
Objekte (z.B. Channel) sollten nicht mehr vom NameServiceEditor vorgegeben werden, sondern von den (bzw. einem) Benutzer(n) initial eingetragen werden.

Diese Tools Hierarchie ist im Lauf des Projekts durch wachsende Anforderungen entstanden, um vor allem das etwas umstaendliche Objekt Handling mittels in Workspaces geschriebenen und ausgefuehrten Code (Templates) zu ersetzen, das fuer Smalltalk-Entwickler zwar immer noch die am schnellsten zu verwirklichende Form der Systembedienung waere, jedoch externen Interessenten nur schwer zu vermitteln waere und eine Runtime Applikation voellig unmoeglich machen wuerde.

Um die Tools effizienter zu implementieren, koennte jedoch - wenn die dazu noetige Zeit im Rahmen des Projektzieles gerechtfertigt waere - z.B. die Wiederverwendung von Teilen (z.B. GUI-Subpanes, Helptext-Bausteine etc.) vergroessert werden (vgl. [How95], [Tro97], siehe auch unten: Abhaengigkeiten zwischen DPE-Objekten und DPE-Capsule-Tools.)

Zur Implementation gibt es ein Logbuch der Verwirklichung der "Ideen fuer DPE und DPE Tools". Weitere technische Details finden sich in den Methoden- und Klassenkommentaren der Objekte.

Die Administration Tools

Die Applikation Tn_Administration_Tools (http://www-vst.fokus.gmd.de/ovma/tangram/project/sw-doc/apps/adminTools/adminTools.html) zaehlt zur Anwendungsseite und nicht zur DPE, da die darin enthaltenen Tools spezifisch fuer die Anwendung (bisher: Access Session) sind. Die Tools wurden von den COs, mit denen sie kommunizieren, um deren Daten sie manipulieren, getrennt, damit die GUIs auch in Capsules, die die COs nicht enthalten (sollen), zur Verfuegung stehen koennen.

Die folgenden Daten-Manipulations GUIs dienen nur zu Testzwecken und erfuellen nicht die Anforderungen (z.B. an Sicherheit oder Concurrency Control), die Daten(bank)-Eingabe Tools haben sollten.

TnUserManagement (Smalltalk)

TnUserManagement (Java)

TnAuthenticationManagement (Smalltalk)

TnAuthenticationManagement (Java)

Es sind einfache GUIs zur Userdatenverwaltung und Passwortvergabe fuer Testzwecke. Das Smalltalk User Management Tool kann mit dem Smalltalk Authentication Tool zusammen arbeiten. (Siehe auch "On functions of the TnUserManagement tool" und "On functions of the TnAuthenticationManagement tool" sowie "Anleitung fuer die Java Administration Tools" (draft) und "Dateiliste der Java Administration Tools").

Tn_Common ab V. 3.0

Tn_Common_Temp ist obsolet, wird aber noch als V. "2.0 dummy" ohne jeglichen Inhalt angeboten, um Ladeprobleme - bevor die prerequisites der Applikationen geaendert sind - umgehen zu koennen.

Neu ist die Klasse TnTiCTTPropertyList (eine Spezialisierung der OrderedCollection), die Methoden zur einfacheren Handhabung von Propertylisten anbietet (eine Idee von som).

TnModule

Der Name "Module" leitet sich ab vom IDL-Modul-Namensraum.

Die Subklassen von TnModule (genannt TnXYZModule, wobei XYZ durch den IDL Module Namen bzw. sein Kuerzel ersetzt wird) sind Traeger fuer Module-spezifische Exceptions, Exception Signals, Constants (Enumerations) u.a.

Ein aeusseres Rahmenmodul ("Tn" in der ersten DPE) wird es nicht mehr geben. Das Modul "Dpe" spezifiziert die von allen anderen Modulen benutzten IDL-Elemente. Die Klasse, die die allen gemeinsamen Exceptions etc. implementiert, heisst jetzt entsprechend TnDpeModule und liegt in der Applikation Tn_Common. Die anderen Modulklassen werden in den jeweiligen Applikationen liegen, die die Capsules verwirklichen.

IDL Module Namen

Schon verwendet werden zur Zeit in DST:

'Agent' 'ApplicationBasics' 'Audio' 'Chart' 'Claim' 'CompoundLifecycles' 'CORBA' 'CosConcurrencyControl' 'CosEventChannelAdmin' 'CosEventComm' 'CosLifeCycle' 'CosNaming' 'CosTransactions' 'CosTypedEventChannelAdmin' 'CosTypedEventComm' 'DataViews' 'Debugging' 'DisplayViews' 'DistributedSmalltalk' 'DTOLinks' 'DynamicInvocation' 'Field' 'Forum' 'Hierarchy' 'InvalidLink' 'IOR' 'Layout' 'Map' 'MediaObjects' 'Message' 'Notebook' 'Office' 'OrderProc' 'Pixmap' 'ProtectedProperties' 'PSSplit' 'ResourceManager' 'RoleNegotiations' 'Security' 'Shape' 'SharedIR' 'SmalltalkTypes' 'StorageServer' 'Table' 'Task' 'Text' 'Transparency' 'TSInteroperation' 'UIContexts' 'User' 'Video'

Vom Projekt gibt es momentan drei IDL Module bzw. Dateien (Instanz-Methoden der Klasse DSTRepository) innerhalb Smalltalks:

'Dpe' 'TINACommonTypes' und 'CosTrading' (abgekuerzt 'Dpe, 'TiCT' und 'CosTr').

Fuer jeden IDL-Modul-Namen muss, wenn er laenger als 5 Zeichen ist, ein max. 5 Zeichen langer Ersatz-Begriff (sinnvollerweise eine Abkuerzung oder ein Akronym) zur Verfuegung gestellt werden. Die Namen werden dann in Klassennamen-Praefix-Ketten durch den Kurzbegriff ersetzt.

Ersetzt werden - durch:

'CosTrading' 			: 'CosTr'
'TINACommonTypes' 		: 'TiCT'
'TINA_RP_accessCommonTypes' 	: 'TRACT'
'TINA_RP_commonTypes' 		: 'TRCT'
'TINA_RP_accessInitialTypes' 	: 'TRAIT'
'TINA_RP_streamTypes' 		: 'TRST'

CORBANames

Die CORBANames beginnen mit dem vollstaendigen IDL-Module-Namen, z.B. "::Dpe" bzw. "::TINACommonTypes" usw. Um nachtraeglich den Modulnamen leichter aendern zu koennen, ohne alle CORBAName-Methoden editieren zu muessen, sollten diese CORBAName-Methoden sich den Modulenamen von der das Module repraesentierenden Klasse (z.B. TnDpeModule) mit der Methode #modulePrefix holen, z.B.

	CORBAName
		"Return the name of my CORBA interface in the repository"

		^TnDpeModule modulePrefix, '::i_ClusterManagement'

wobei "TnDpeModule modulePrefix" den String 'Dpe' zurueckliefert (Idee von hw). (Modulpraefix und Klassenpraefix sind hier identisch).

Die Module-Klasse sollte ausserdem die Klassenmethode #classPrefix haben, die entweder den Kurzbegriff zurueckliefert (oder - falls identisch - einfach #modulePrefix aufruft), z.B.

	modulePrefix
		^'TINACommonTypes'

	classPrefix
		^'TiCT'

Klassen-Namenskonventionen

Die in der ersten DPE gebraeuchlichen Namenskonventionen werden beibehalten.

Allgemeines Projekt-Klassenpraefix: "Tn".

Modulenamen (bzw. ihre Kuerzel, s.o.) verkettet vor Klassennamen.

"I", "O", "T" als Kuerzel vor den Klassennamen von "I"nterfaces, Core"O"bjects und Da"T"enstrukturen (Dictionaries, Unions).

Also z.B. TnAssPcsOUsageContext

Ausgenommen davon sind die Basis- und Tool-Klassen. Sie erhalten nur das Projekt-Praefix "Tn" (Sonst wuerde z.B. TnCapsuleManager TnDpeICapsuleManager heissen).

Capsule handling

Capsule COType List und InterfaceType List

Zur Capsule Konfiguration in einem Smalltalk-Image gehoeren:

-Setzen der Capsule Id
-Auswahl der CO Typen (anhand ihrer ODL Namen) des Images (oder automatische Erkennung (s.u.)), mit denen sich der CapsuleManager im CapsuleFinder registrieren soll.
-Auswahl der Interface Typen (mittels ihrer RepositoryIds (IDL Namen)) eines Images (oder automatische Erkennung (s.u.)).

Dazu dienen die CapsuleSettings, gestartet vom CapsuleLauncher

Capsule Id

Der CapsuleManager meldet sich im CapsuleFinder mit einer Id (String) an.

Die Id muss ueber den CapsuleLauncher (bzw. das von ihm gestartete CapsuleSettings Tool) gesetzt werden. Als Default wird in ENVY die User-Kennung genommen. Nach Anmeldung eines CapsuleManagers zeigt der CapsuleLauncher die verwendete Id in seinem Label an.

Ist die mitgesendete Id schon in Gebrauch, so modifiziert der CapsuleFinder die CapsuleId (und gibt die modifizierte Version zurueck). Ausserdem wird bei Gleichheit der Id die Identitaet der anmeldenden und der schon vorhandenen CapsuleManager-Instanzen durch Instanz-Variablen Vergleich (objectId, adapterId) festgestellt. Das funktioniert (getestetermassen) fuer Smalltalk und C++ Instanzen (und vorausgesetzt, dass alle nicht Smalltalk-Instanzen von DST uniform behandelt werden, auch fuer Java und andere nicht DST-ORBs).

Die Entscheidung, dass es keine Ids fuer Capsules bzw. deren Manager geben soll (analog zum ConfigurationManager in der alten DPE, der sich mit seinem applicationName, z.b. "Accounting", anmeldete), wurde also zurueckgenommen. Anlass war, dass das Deregistrieren eines nicht DST-CapsuleManagers (C++, Java) im DST-CapsuleFinder speziell behandelt werden musste. Eine einfache Loesung innerhalb DST waere es, den Instanzen-Identitaetstest im CapsuleFinder durch einen Instanzen-Attributstest zu ersetzen. Das funktioniert (getestetermassen) fuer Smalltalk und C++ Instanzen (und wahrscheinlich auch fuer Java). Vorteil dieser "schnellen" Loesung waere es gewesen, dass sie keine IDL-Aenderung oder Aenderung anderer Objekte erforderte. Aber um das Problem universell zu loesen, wurde (von wow) der aufwendigere Ansatz favorisiert, die CapsuleManager mit einer Id im CapsuleFinder zu registrieren.
Das hat den Vorteil, dass es sich auch in jeder Nicht-DST-DPE-Plattform implementieren laesst und dass es (aus DST heraus gesehen) mit jedem DST-fremden Objekt funktioniert.

CoreObject und Interface Deklaration und automatische Erkennung

CoreObjects koennen subclass von TnCoreObject sein. Dann erben sie die Klassen-Methode #isCoreObject, die "^true" zurueckliefert, wodurch sie vom Capsule Manager erkannt werden.
CoreObjects, die subclasses anderer Klassen sind, koennen nur dann automatisch als COs erkannt werden, wenn sie diese Methode selber implementieren.
CoreObjects, die subclass von TnCoreObject sind, aber nicht automatisch als CO erkannt werden sollen, muessen diese Methode selber implementieren und "^false" zurueckliefern.

Interfaces sind immer subclass von TnInterfaceObject. Sie erben die Methode #isInterfaceObject, die "^true" zurueckliefert, wodurch die Klasse als Interface erkannt wird.
Interfaces, die subclass von TnInterfaceObject sind, aber nicht automatisch als Interface erkannt werden sollen, muessen diese Methode selber implementieren und "^false" zurueckliefern. Solche Interface-Klassen werden bei der CO-Erzeugung nicht beruecksichtigt.

Unabhaengig von der automatischen Erkennung kann jede Smalltalk Klasse (ob als CO oder Interface) mit Hilfe der CapsuleSettings in die Liste der CO- bzw. Interface-Typen der Capsule aufgenommen werden.

Ablauf eines Requests

1. Ein Object (z.B. ein CO) holt sich den CapsuleFinder vom NameService.

2. Das Object holt sich einen CapsuleManager vom CapsuleFinder (indem dem CapsuleFinder eine CO-Typenliste (ClusterTemplate = Sammlung von BEOTemplates) geschickt wird und der CapsuleFinder den oder die passenden CapsuleManager zurueckliefert).

3. Das Object sendet dem erhaltenen CapsuleManager dasselbe ClusterTemplate als Anforderung von COs.

4. Der CapsuleManager erzeugt einen neuen ClusterManager und veranlasst die CO-Erzeugung nach dem erhaltenen ClusterTemplate (CO-Typenliste). Er liefert die initialen Interfaces der erzeugten COs zurueck an den lokalen oder remote Anforderer, und die ManagementInterfaces an den dafuer erzeugten, lokalen ClusterManager.

4.1 Interfaces werden von der TnObjectFactory erzeugt und im CO aufbewahrt.

4.2 COs werden nicht vom ClusterManager aufbewahrt; sie sind von diesem nur ueber ihr ManagementInterface erreichbar.

4.3 Die einzige Moeglichkeit fuer ein remotes CO, diese soeben fuer es erzeugten COs spaeter zu erreichen, besteht darin, die zurueckgelieferten initialen Interfaces (oder die mit seiner Hilfe angeforderten speziellen Interfaces) zu speichern. Eine spaetere Anfrage an den CapsuleManager zum Erhalt vorhandener COs gibt es nicht mehr! Nachtraeglich werden einzelne Interfaces bei Bedarf vom CO auf Anforderung hin erzeugt (die bei der CO-Erzeugung nicht erzeugt worden waren).

Die einzelnen Schritte werden - vereinfachend - unterstuetzt von TnSupport Methoden. Ein Objekt, das ein Cluster benoetigt, kann sich ein ClusterTemplate sowie das Cluster selber (unter Angabe der gewuenschten COs und Interfaces) von der Klasse TnSupport erzeugen bzw. besorgen lassen (Siehe /net/fb/ovma/tangram/images/base/mit_RetRP/templates.txt).

CO Programmierung

Ansprechen von remote COs

Es gibt keine InstanceIds fuer COs mehr.

Existierende remote COs bzw. Cluster koennen NICHT (mehr, wie bisher,) angesprochen werden. Nur wer sie angefordert hat oder die Referenz vom urspruenglichen Anforderer (evtl. ueber Dritte) bekommen hat, kann existierende Cluster bzw. deren COs mit Requests begluecken.

Die Referenz kann dabei das InitialInterface eines COs sein, mit dem seine anderen speziellen Interfaces angefordert werden koennen, oder gleich ein operationales Interface des Ziel-COs.

Das bedeutet, die Messages zum Erlangen eines Interface eines CO via ConfigurationManager (#selectIntRef:instanceId:interfaceType:, #getIntRefs meist unter Verwendung von TnORBConnection) sind vollstaendig zu ersetzen (Dazu habe ich die beim Umstieg zu bearbeitenden Stellen in den Kapseln (Applikationen), die mir aufgefallen sind, aufgelistet in "VomUmtauschNichtAusgeschlossen.txt" (Fundstellen obsoleter/zu modifizierender Aufrufe, ohne Gewaehr auf Vollstaendigkeit).

Interface Vererbung

Es besteht die Moeglichkeit, Interfaces in einer Vererbungshierarchie zu deklarieren (IDL-Vererbung) und zu implementieren (Klassenhierarchie).

Wird lokal (vom CO) eine Interface-Instanz mit #addInterface:anInterfaceType erzeugt (d.h. seine Erzeugung von der ObjectFactory angefordert (siehe unten)), dann wird, wenn die Erzeugung der Instanz scheitert, eine Instanz einer Subklasse des Interfaces (falls vorhanden) erzeugt und zurueckgeliefert (in der Annahme, dass diese die Methoden der Oberklasse geerbt hat und (nicht modifizert, also ueberschrieben) ausfuehren kann. (Prinzip von som, Automatik-Loesung von hw).

Wird per Request (#getInterface: anInterfaceType desiredProperties: aPropertyList) ein Interface angefordert, von dem es noch keine Instanz gibt, so wird sie NICHT automatisch erzeugt.

InitialInterfaces

Jedes operationale Interface kann vom CO zum 'InitialInterface' erklaert werden (Die urspruenglich vorgesehene IDL Deklaration der InitialInterfaces faellt weg).

In Smalltalk erbt jedes Interface die 'InitialInterface'-Methoden von der abstrakten Oberklasse TnInterfaceObject. Ein Interface, dass als InitialInterface dienen soll, kann in der IDL vom interface "i_InterfaceAccess", das die Methoden zum Erhalten von Interfaces eines CO deklariert (#getInterfaces usw.), erben. So koennen die ererbten Methoden per Request nur von den durch die IDL dazu ausersehenen Objekten benutzt werden. Was das InitialInterface eines COs tatsaechlich anbietet, ist jedoch nicht vorgeschrieben, sondern liegt beim CO-Programmierer.

Das CO muss auf der Klassenseite eine Methode #initialInterfaceType haben, die die RepositoryId des Interfaces zurueckgibt, das als initiales Interface dienen soll.

Bei Anforderung eines Interfaces wird nicht mehr das Interface selbst, sondern ein Dictionary zurueckgeliefert, das das Interface, seinen Typ und (fuer kuenftige Verwendung) eine Propertylist enthaelt.

Interface Typen eines CO

Jede CO-Klasse muss folgende Klassen-Methoden implementieren:

#initialInterfaceType
eine RepositoryId spezifiziert, welches Interface die Rolle des InitialInterface spielen soll (in der IDL muss dieses interface von "i_InterfaceAccess" erben, die entsprechenden Methoden erbt jedes Smalltalk-Interface von TnInterfaceObject).

#standardInterfaceTypes
eine Liste von RepositoryIds gibt an, welche Interfaces die Standard-Konstellation ausmachen. Diese Zusammenstellung wird erzeugt, wenn der CO-Anforderer im BEOTemplate keine interfaces spezifiziert.

#supportedInterfaceTypes
listet alle RepositoryIds der Interfaces die das CO haben (erzeugen lassen) kann.

#requiredInterfaceTypes
listet alle RepositoryIds der "required interfaces" des CO (nach ODL). Die Methode wird in der DPE nicht benutzt und ist aus Gruenden der Vollstaendigkeit vorgesehen.

(Siehe "Anleitung zum Umstieg von DPE 1 auf DPE 2")

Jedes CO muss eine Klassenmethode #ODLName aufweisen, die seinen ODL Namen als String zurueckgibt.

Gebrauch der CO- bzw. Interface Factory (TnObjectFactory)

Eine Instanz von TnObjectFactory erzeugt (fuer einen ClusterManager) ein CO durch Aufruf der Methode #createCOs:aBEOTemplateList for:aClusterManager. Zurueck gibt sie ein Dictionary, dass die Management- und InitialInterfaces- Listen enthaelt. Die CO-Erzeugung sollte nicht von anderen Objekten der Capsule benutzt werden (Absicherung dagegen waere moeglich).

Von jedem CO aus (nicht nur Subklassen von TnCoreObject), kann der Aufruf zur Erzeugung eines (oder mehrerer) Interfaces #createInterfaces:anInterfaceTemplateList for:aCO benutzt werden. Zurueck kommt ein Dictionary, dass alle genannten Interfaces enthaelt.

Examples, Templates, Images

Zur Unterstuetzung der Anwendung gibt es Examples und Code-Templates im /net/fb/ovma/tangram/images/base/mit_RetRP/templates.txt, die in Smalltalk mit einem FileEditor benutzt werden koennen.

Ein image /net/fb/ovma/tangram/images/base/mit_RetRP/visual.im wird hin und wieder auf den neuesten Stand gebracht (gegebenenfalls die neuesten Versionen nachladen).

Wer sich das image selbst aufbauen will, muss beim Laden der Tn_RetRP Applikation beachten, dass ENVY die Module (Methoden im protocol "Tangram IF" der Klasse DSTRepository) in alphabetischer Reihenfolge laden will, was aber nicht geht, da die Module in einer Abhaengigkeitsbeziehung zueinander stehen, die durch die alphabetische Reihenfolge der Namen nicht gespiegelt wird. Es hilft nur, die Methoden einzeln zu laden in der (zur Zeit von RetRP 1.2 gueltigen, von som gelieferten) Reihenfolge: TINAAccessCommonTypes, TINASBComSCommonTypes, TINAStreamCommonTypes, TINAInviteCommonTypes, TINAProviderAccess, TINAUserAccess, TINAProviderInitial, TINAUserInitial, TINAConsumerAccess, TINAConsumerInitial, TINARetailerAccess, TINARetailerInitial (und nicht TINAUserInvite). Einfacher ist es, ein vorbereitetes image zu nehmen, und darin gegebenenfalls nur die neueste Version der Tn_RetRP Applikation nachzuladen.

Umstellungsschritte

Die einzelnen Arbeitsschritte zur Umstellung der alten Module (Ass, Act, Svs, Cos, EUS, GSEP?, Sub (Smalltalk-Anteil?)) auf die neue DPE werden durch folgende Texte unterstuetzt:

- nuetzlich dazu kann eine Liste der Klassen / Methoden sein, die die alten DPE-Funktionen benutzen (ConfigurationManager, TnORBConnection etc.):
"Fundstellen obsoleter/zu modifizierender Aufrufe" (ohne Gewaehr auf Vollstaendigkeit).

- Konfiguration der Capsule mit dem CapsuleSettings tool: TnCapsuleSettingsHelp.html für TINA Platform Capsule Settings.

- dabei Erzeugen einer DST Configuration Datei mittels TnDSTSystemSettings: TnDSTSystemSettingsHelp.html für TINA Platform DST System Settings.

-Konkrete Beispiele dazu koennen auch den COs oder dem Launcher der /net/fb/ovma/tangram/doc/DieTnTestEnvironment.html entnommen werden.

Zum Factory Begriff in Smalltalk

In Smalltalk arbeitet jede Klasse (Instanzen der class Metaclass) als Factory ihrer Instanzen. Besondere typspezifische Factories und deren Instantiierung sind nicht noetig.

Ein Spezialfall sind diejenigen Klassen, die in IDL als "Interface" spezifiziert, im Code als CORBA-Factories deklariert und vom ORB durch Anwenden von "Initialize Factories" registriert worden sind. Ihre Instanzen werden von der Klasse mit der ORB-Methode #createObjectKey:criteria: bezogen und vom Smalltalk-GarbageCollector erst dann wieder abgeraeumt, wenn sie vorher vom ORB freigegeben worden sind (was durch Senden der message #destroy an das freizugebende Objekt ausgeloest werden kann). COs sind (in diesem Projekt) meist "normale" Klassen. TINA Platform Interfaces sind immer als ORB-Factories deklarierte Klassen.

Als Factory wird schliesslich auch ein Objekt bezeichnet, dass andere, komplexe Gebilde zusammensetzt (Vgl. [Gam96] p. 116 ff.).

In der Smalltalk DPE delegiert der CapsuleManager die CO-Produktion an den ClusterManager. Der ClusterManager wiederum veranlasst eine Instanz der Klasse TnObjectFactory, von der jeweiligen CO Klasse (eine Subklasse von TnCoreObject oder einer beliebigen anderen Klasse) als Factory ein vom Smalltalk Garbage Collector beaufsichtigtes CoreObject-Exemplar anzufordern und dann die jeweiligen Interface-Klassen als CORBA-Factories zur Erzeugung der vom ORB verwalteten Interface-Instanzen anzusprechen. Alle Interface Instanzen werden dem CoreObject uebergeben, eine Referenz auf das Management-Interface bleibt beim ClusterManager, eine Referenz auf das Initial-Interface geht an den CapsuleManager, der es dem Anfordernden zurueckreicht.

Die Veranlassung der Interface-Erzeugung koennte (bzw. die wenigen "Interface-Erzeugungs-Veranlassungs-Methoden" koennten) auch direkt in der Klasse TnCoreObject als Instanzen-Methoden implementiert sein, unter der Voraussetzung, dass alle COs ausschliesslich Subklassen von TnCoreObject waeren. Da COs aber Subklassen beliebiger Klassen sein duerfen, ist hier ein separates Factory-Objekt, das das komplette CO mit seinen Interfaces zusammensetzt, sinnvoll.

Instanzen der Klasse TnObjectFactory haben somit eine Doppelfunktion: Fuer einen ClusterManager stellen sie die Factory zur CO-Erzeugung dar, fuer ein CO sind sie Factories zur Erzeugung eines (oder eines Satzes von) Interfaces.

Da die Anforderung von ORB verwalteten Instanzen (via FactoryFinder) als Eingabe den Klassennamen verlangt, wir aber die Interfaces eines CO durch ihre RepositoryId benennen, ist ein Mapping von RepositoryId auf Smalltalk-Klassennamen noetig. Da der ORB das nicht kann, bietet die Klasse TnSupport die Methode #classForId:aRepositoryId an, die den Klassennamen anhand der CORBANames der Interfaces aktuell ermittelt. Dieses Mapping koennte auch fest codiert sein (z.B. im CO oder in TnObjectFactory).

IDL to Smalltalk Generator

Die Implementierung der Smalltalk-Capsules bzw. ihrer Interfaces, COs und Datenstrukturen wird unterstuetzt durch einen IDL to Smalltalk Generator, der aus IDL deklarierten Elementen (im DST Repository der Capsule) Smalltalk Klassen mit ihren Methoden erzeugt. Der Generator ist kein IDL-Compiler, sondern er benutzt das DST Repository nachdem DST die IDL compiliert hat. Er erzeugt die Skeletons (Klassen und Methodenaufrufe, die vom Applikationsentwickler ausprogrammiert werden muessen) fuer die COs als Server (Request-Empfaenger). Aus der Sicht des COs als Client (Request-Sender) liegen die aufzurufenden Stubs in den von DST angebotenen Proxy-Objekten auf den Request-Empfaenger (vgl. [Pud97]).

Der Generator ist spezifisch fuer das TINA Platform Framework implementiert, da er nicht einfach IDL-Interfaces als singulaere Klassen erzeugt, wie es der CORBA IDL-Standard erwartet, sondern im TINA Platform Framework ein Interface mit seinen (per ORB-Request) remote aufrufbaren Methoden per default auf das ebenfalls generierte CoreObject verweist, das die tatsaechliche Bearbeitung des Requests vornimmt. Der Capsule-Programmierer implementiert den Code zu diesen generierten CoreObject Methodenaufrufen (bzw. modifiziert bei Bedarf die generierten (delegierenden) Interface-Methoden).

Im TINA Platform Framework koennen mehrere Interfaces jeweils Teilmengen der Methoden ihres Cores anbieten. Das ermoeglicht einen flexiblen Objekt-Aufbau wie ihn das TINA Consortium zur Modellierung von "Computational Objects" vorsieht (vgl. [Han96]).

Innerhalb der TINA Platform wird Interface-Vererbung zwischen Smalltalk Klassen von som in der Access Session eingesetzt. Der Generator bietet deshalb Optionen zur Oberklassenauswahl der Interfaces in einer Vererbungslinie an (siehe TINA Platform specific DST based IDL to Smalltalk Generator).

Abhaengigkeiten zwischen DPE-Objekten und DPE-Capsule-Tools

Auf Smalltalk Capsule-interner Ebene sind die IDL-spezifizierten DPE-Objekte verbunden mit Tools (GUIs), die die Handhabung der ersteren erleichtern.

Ein routinierter Smalltalker koennte die DPE-Objekte auch mit ausfuehrbarem Code (und evtl. einigen globalen Variablen) mittels eines Workspace oder Texteditor manipulieren. So ein Verfahren wenden z.B. DST in seinem DSTWorkspace und ENVY in seinem Preferences Workspace an: Ein Workspace wird geoeffnet, der den Codetext, zusammen mit erlaeuternden Kommentaren, anzeigt. Jeder Smalltalk-Programmierer weiss sofort, was er damit anfangen kann, jeder EDV-Profi (Nicht-Smalltalker) kann es sofort - durch die integrierten Kommentare - verstehen: Gewuenschte "Kommandozeile" selektieren und per Mausbutton-Menu "do it" ausfuehren.

Andere Capsule-Benutzer jedoch werden GUIs (Launcher usw.) vorziehen. Fuer eine Smalltalk Runtime-Capsule ("gestripptes Image") sind sie unerlaesslich.

So entsteht innerhalb der Capsule ein Tools-Framework (CapsuleLauncher, InstallationLauncher usw.), das - waeren wir nicht ein "unabhaengiges Projekt", sondern eine Entwicklungsabteilung innerhalb der Produktpalette eines Industrieunternehmens - weiter ausgebaut werden koennte (z.B. durch ererbte Menus, GUI-Subpanes, Helptext-Bausteine etc.) (siehe [How95], [Tro97]).

Zwischen den GUIs und den DPE-Objekten gibt es nun verschiedene Arten der Abhaengigkeit und der Zusammenstellung von Objekten zu funktionalen Gruppen:

Die Launcher sind mit weiteren Capsule-internen Objekten verbunden: Jeder Launcher meldet sich an beim

• Smalltalk-System-Objekt "ObjektMemory" (als dependent), um von diesem beim Starten der Capsule benachrichtigt zu werden. Das dient dazu, das System beim Image- (Capsule-) Start automatisch konfigurieren bzw. hochfahren zu koennen.

• ORB-Objekt "ORBDaemon startUpRequestBroker" (als dependent der Instanzvariable "state"), um beim Start/Stop des ORB benachrichtigt zu werden. Das macht die Launcher unabhaengig vom Vorhandensein anderer Fenster (DSTRequestBrokerPanel, DSTLauncher).

Um diese Abhaengigkeiten aufzuloesen und Objekt-Instanzen der Tools und DPE-Objekte zu entfernen, bietet TnObjekt die Methode #resetCapsule an. Zusammen mit der Methode #resetORB kann eine Capsule incl. ORB in einen definierten Zustand gebracht werden.

DST Patches

Die verwendeten DST Patches in den Smalltalk-Images sind notiert in http://www-vst.fokus.gmd.de/ovma/tangram/products/dst5.5/patches/entry.html. Darunter befinden sich zwei bug fixes, die in /net/WWWVST/html/ovma/tangram/experiences/hpdst/bugfixes.html beschrieben sind. Den in /net/WWWVST/html/ovma/tangram/experiences/hpdst/processes.html erklärten ProcessorScheduler Patch fuer das ORB Request handling verwenden wir nicht, solange es keine Probleme mit Nebenlaeufigkeit von Requests gibt.

Literatur

[Eck97a] Eckert, K.-P., Ed.; Introduction to the TANGRAM Distributed Processing Environment; BERKOM - TANGRAM; Deliverable for the 7th milestone of the TANGRAM Project; 30. June 30 1997; Release 1.0. (Siehe: /net/fb/ovma/tangram/ms7/dpe/dpe.ps).

[Eck97b] Eckert, K.-P.; TANGRAM DPE Konzepte (http://www-vst.fokus.gmd.de/ovma/tangram/project/dpe/dpe97.html).

[Gam96] Gamma, E., et al.; Entwurfsmuster; Addison-Wesley; Bonn; 1996.

[Han96] Handegard, T., Ed.; Computational Modelling Concepts; TINA-C Stream Deliverable; 17th May 1996; Version 3.2.

[How95] Howard, T.; The Smalltalk Developer's Guide to VisualWorks; SIGS; New York; 1995; [MVC].

[Mow97] Mowbray, T. J., Malveau, R. C.; CORBA Design Patterns, Wiley, New York, 1997.

[Pud97] Puder, A.; Verteilte Objekte: DCOM versus CORBA; iX 8/1997, 44-51.

[Tro97] Troyer, K.-H., MVC ausgereizt - Entfernung von Redundanzen erspart Oberflaechenprogrammierung, OBJEKTSpektrum 2/97, 44 - 53.

[Wun97] Wunderlich, W.; Konkretisierung der DPE - Konzepte Capsule- und Cluster-Manager (http://www-vst.fokus.gmd.de/ovma/tangram/project/dpe/dpe.html).

(Mehr Literatur zu Smalltalk, Frameworks, Mustern und CORBA wird aufgelistet in "LitNachThemen.html").

Tn - Klassenhierarchie

* = DST bzw. VisualWorks -Klasse


*Dictionary
	TnStruct

*DSTUnion
	TnUnion

	
*Object
	TnObject
		TnObjectFactory
		TnCoreObject
			subclasses: (optional) CoreObject classes
		TnModule
			TnDpeModule (in Applikation Tn_Common)
			more subclasses: TnXyzModule classes
	TnSupport
	TnTranscript

*DSTPersistentObject
	TnInterface
		TnCapsuleManager
		TnClusterManager
		TnCapsuleFinder
		TnInterfaceObject
			TnManagementInterface
			more subclasses: Interface classes

*ApplicationModel
	*DSTSystemSettings
		TnDSTSystemSettings

	TnGui
		TnCapsuleSettings
		TnCapsuleStatistics
		TnLauncher
			TnInstallationLauncher
				TnCapsuleFinderLauncher
				TnEndUserSystemLauncher
			TnCapsuleLauncher
				subclasses: specific Capsule Launcher classes
			TnNameServiceEditor
		TnDataManagement
			TnUserManagement
			TnAuthManagement