Auflistung der JavaSpaces-spezifischen Annotationen für AID

Auflistung der JavaSpaces-spezifischen Annotationen für AID

Auflistung der JavaSpaces-spezifischen
Annotationen für AID
Thomas Ewender
17. August 2006
Inhaltsverzeichnis
1 Annotationen für die Vertreterseite von JavaSpaces
2
2 Annotationen für die Treiberseite von JavaSpaces
2.1 Header . . . . . . . . . . . . . . . . . . . . . .
2.2 Component . . . . . . . . . . . . . . . . . . .
2.2.1 spacename_in . . . . . . . . . . . .
2.2.2 spacename_out . . . . . . . . . . .
2.3 Interface . . . . . . . . . . . . . . . . . . . . .
2.3.1 spacename_in . . . . . . . . . . . .
2.3.2 spacename_out . . . . . . . . . . .
2.4 Exception . . . . . . . . . . . . . . . . . . . .
2.5 Tuple . . . . . . . . . . . . . . . . . . . . . .
2.5.1 classname . . . . . . . . . . . . . .
2.6 Constructor . . . . . . . . . . . . . . . . . . .
2.6.1 classname . . . . . . . . . . . . . .
2.6.2 property . . . . . . . . . . . . . . .
2.6.3 option . . . . . . . . . . . . . . . .
2.6.4 creation_mode . . . . . . . . . . .
2.6.5 path . . . . . . . . . . . . . . . . . .
2.6.6 classname . . . . . . . . . . . . . .
2.7 IN-Event . . . . . . . . . . . . . . . . . . . .
2.7.1 attribute_in . . . . . . . . . . . .
2.7.2 spacename_in . . . . . . . . . . . .
2.7.3 classname_in . . . . . . . . . . . .
2.8 OUT-Event . . . . . . . . . . . . . . . . . . .
2.8.1 attribute_out . . . . . . . . . . .
2.8.2 spacename_out . . . . . . . . . . .
2.8.3 classname_out . . . . . . . . . . .
2.9 INOUT-Event . . . . . . . . . . . . . . . . . .
2
2
4
4
4
4
4
4
4
5
5
5
6
6
6
7
7
7
7
8
8
8
9
9
10
10
10
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.9.1
Ledigliches Entfernen eines Entry-Objekts aus dem Tupelraum . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.9.2 Schreiben und anschließendes Lesen von Entry-Objekten .
2.9.3 attribute_out . . . . . . . . . . . . . . . . . . . . .
2.9.4 attribute_in . . . . . . . . . . . . . . . . . . . . . .
2.9.5 spacename_in . . . . . . . . . . . . . . . . . . . . . .
2.9.6 classname_in . . . . . . . . . . . . . . . . . . . . . .
2.9.7 attribute_out . . . . . . . . . . . . . . . . . . . . .
2.9.8 spacename_out . . . . . . . . . . . . . . . . . . . . .
2.9.9 classname_out . . . . . . . . . . . . . . . . . . . . .
2.10 OUTIN-Event . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.10.1 attribute_out . . . . . . . . . . . . . . . . . . . . .
2.10.2 attribute_in . . . . . . . . . . . . . . . . . . . . . .
2.10.3 spacename_in . . . . . . . . . . . . . . . . . . . . . .
2.10.4 classname_in . . . . . . . . . . . . . . . . . . . . . .
2.10.5 attribute_out . . . . . . . . . . . . . . . . . . . . .
2.10.6 spacename_out . . . . . . . . . . . . . . . . . . . . .
2.10.7 classname_out . . . . . . . . . . . . . . . . . . . . .
2.11 Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11.1 take . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11.2 write . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11.3 matching_param . . . . . . . . . . . . . . . . . . . .
11
11
11
12
12
12
12
12
12
13
13
13
13
13
14
14
14
14
14
14
14
1 Annotationen für die Vertreterseite von JavaSpaces
TBD
2 Annotationen für die Treiberseite von JavaSpaces
Ein Treiber für eine tupelraumbasierte Komponente ermöglicht die Kommunikation dieser Komponente mit einer andersartig interagierenden Umgebung. Aufgabe
der AID-Spezifikation zusammen mit den interaktionsstilspezifischen Annotationen ist es, die tupelraumbasierte Komponente so detailliert zu beschreiben, dass eine Umsetzung der abstrakten AID-Ereignisse in konkrete Tupelraum-Operationen
möglich ist. Die für JavaSpaces notwendigen Annotationen werden im Folgenden
vorgestellt.
2.1 Header
Für das AID-Element Header sind keine Annotationen vorgesehen.
2
Abbildung 1: Treiber für eine JavaSpaces-Komponente in einer Umgebung mit
inkompatiblem Interaktionsstil.
3
2.2 Component
2.2.1 spacename_in
Bezeichnet den Tupelraum1 , über den alle Ereignisse dieser Komponente interagieren. Ist für ein Interface oder ein Ereignis dieses Component-Elements eine eigene
Annotation spacename_in vorhanden, so wird diese verwendet. Anderenfalls wird
der Tupelraum des Component-Elements vererbt.
2.2.2 spacename_out
Bezeichnet den JavaSpace, in den die Komponente ihre Entry-Objekte schreibt.
Ist für ein Interface oder ein Event-Element eine separate Annotation spacename_in vorhanden, so wird diese verwendet. Aus dem mit spacename_out spezifizierten Tupelraum werden die Entry-Objekte gelesen, die den OUT-Teil von OUT-,
INOUT- und OUTIN-Ereignissen darstellen.
2.3 Interface
2.3.1 spacename_in
Bezeichnet den JavaSpace, über den alle Ereignisse dieses Interfaces interagieren. Ist für ein Event-Element dieses Interfaces eine separate Annotation spacename_in vorhanden, so wird diese verwendet. Ist weder für das Interface noch für das
Event-Element ein JavaSpace spezifiziert, muss ein JavaSpace für das ComponentElement vorhanden sein, dass entsprechend vererbt wird.
2.3.2 spacename_out
Bezeichnet den JavaSpace, in den die Komponente Entries dieses Interfaces schreibt.
Ist für ein Event-Element eine separate Annotation spacename_out vorhanden, so
wird diese verwendet. Aus diesem Tupelraum werden die Entry-Objekte gelesen,
die den OUT-Teil von OUT-, INOUT- und OUTIN-Ereignissen darstellen.
2.4 Exception
Es sind keine Annotationen für Exceptions vorgesehen. Für den Interaktionsstil JavaSpace gibt es keine benutzerdefinierten Ausnahmen.
Für das Schreiben und Lesen von Entry-Objekten sind nur Ausnahmen definiert, die sich auf den Kommunikationsvorgang an sich beziehen und nicht auf das
1
Der Wert der Annotation spacename_in wird über den Namensdienst Reggie der JiniLaufzeitumgebung aufgelöst und in eine Referenz (exakt: einen Fernverweis) auf ein JavaSpaceObjekt umgewandelt. Spricht man von Tupelraum, bezieht man sich immer auf ein unter einem
bestimmten Namen registrierten JavaSpaces-Objekt.
4
Ereignis, das durch das Schreiben/Lesen des Entry-Objekts repräsentiert wird. Es
sind fünf Systemausnahmen für die Operationen read, take und write definiert:
• UnusableEntryException (falls ein serialisiertes Feld des Entry-Objekts, das
gelesen wird, aus irgendwelchen Gründen nicht deserialisert werden kann)
• TransactionException (falls bei der Transaktion ein Fehler auftritt)
• InterruptedException (falls der Thread, in dem die Operation aufgerufen
wird, unterbrochen wird)
• RemoteException (falls ein Kommunikationsfehler auftritt)
• IllegalArgumentException (falls ein negativer Wert für den timeout-Parameter
benutzt wird oder ein Objekt einer Klasse benutzt wird, das nicht public deklariert ist)
Letztendlich existiert also für JavaSpaces-Komponenten keine Möglichkeit, Ausnahmen im Sinne von AID zu realisieren. Die Software, die die Vermittlung zur
JavaSpaces-Komponente, realisiert muss sich demnach auf die Weitergabe dieser
fünf Ausnahmen beschränken.
2.5 Tuple
Das AID-Element Tuple als Datenkapsel ermöglicht die Verwendung von Objekten als Attribute eines Entry-Objekts. Um eine Musteranpassung von Seiten der
Komponente zu ermöglichen, muss die Klasse der Komponente bekannt sein, die
vordefinierte Klasse muss demnach dem Generator zur Verfügung stehen. Dazu
dient die Annotation classname.
2.5.1 classname
Bezeichnet die Klasse, die für das Tupel verwendet werden soll. An dieser Stelle
muss auf Konsistenz geachtet werden, da die Member-Variablen des Tupels den öffentlichen Attributen der durch classname spezifizierten Klasse entsprechen müssen. Namensgleichheit ist dazu notwendig, um die entsprechenden Attribute des
Objekts setzen zu können. Um Kapselung zu berücksichtigen, kann man auch die
Benutzung entsprechender Getter- und Setter-Methoden unterstützen.
2.6 Constructor
INIT-Ereignisse können zwei verschiedene Initialisierungsarten in JavaSpaces darstellen.
5
1. Ein INIT-Ereignis signalisiert den Aufruf eines Java-Programms mit allen
dazugehörigen Konfigurationsmöglichkeiten. Dazu zählen Kommandozeilenargumente und System-Properties2 (notwendig, um die Properties für die
Codebase3 , den SecurityManager4 und die Policy5 zu übergeben). Dazu sind
zudem auch der Pfad sowie der Klassenname notwendig, mit dem das Programm gestartet werden soll. Ferner sollte eventuell die Möglichkeit bestehen, Standardoptionen, die an den java-Befehl übergeben werden sollen (wie
-jar) zu unterstützen.
2. Ein INIT-Ereignis steht für den Aufruf eines Konstruktors einer Java-Klasse.
Dem neu zu erzeugenden Objekt werden sämtliche zur Konfiguration notwendigen Parameter über den Konstruktor übergeben. Eine korrekt konfigurierte Laufzeitumgebung ist Voraussetzung für die Erzeugung dieses Objekts. Die hierfür notwendigen Annotationen beschränken sich auf den Klassennamen des zu erzeugenden Objekts.
Diese beiden Varianten werden mit Hilfe der Annotation creation_mode unterschieden, die die Werte process bzw. instantiation annehmen kann.
2.6.1 classname
Voll qualifizierter Klassenname, der als Klassenname dem Befehl java (engl. Java
application launcher) übergeben wird oder zur Erzeugung eines Objekts der Klasse classname verwendet wird, abhängig von der Belegung der Annotation creation_mode
2.6.2 property
System-Properties, mit denen die Anwendung gestartet werden soll. Hierzu sind
mehrere Annotationen vom Typ property möglich. Die Properties werden unverändert durch Voranstellen des Strings -D an den Java Application Launcher übergeben. Diese Annotation ist nur für die Belegung creation_mode = process vorgesehen.
2.6.3 option
Der Wert der Annotation option wird als Standardoption an den Java Application
Launcher übergeben. Somit können Optionen wie -jar beim Anwendungsaufruf
gesetzt werden.
2
Standard-Option mit -D vorangestellt. Non-Standard-Options, die über -X gekennzeichnet werden, wie Xms128m für inital memory, können über die Annotation option übergeben werden.
(siehe http://java.sun.com/j2se/1.3/docs/tooldocs/solaris/java.html)
3
java.rmi.server.codebase
4
java.lang.SecurityManager
5
java.security.policy
6
2.6.4 creation_mode
Kann einen der Werte process oder instantiation annehmen, die für das Starten einer Anwendung oder für das Erzeugen eines Objekts innerhalb einer vorhandenen
Laufzeitumgebung stehen.
2.6.5 path
Die Annotation Pfad beschreibt den absoluten Pfad zur Anwendung. Diese Annotation ist nur für die Belegung creation_mode = process vorgesehen, dafür aber
obligatorisch.
2.6.6 classname
Spezifiziert den Klassennamen des zu erzeugenden Objekts oder der zu startenden
Java-Anwendung.
Übergabe von Parametern/Argumenten Die Parameter des Konstruktors werden je nach Belegung der Annotation creation_mode dem Klassenkonstruktor übergeben oder in der angegebenen Reihenfolge als Kommandozeilenargumente der
Anwendung übergeben. Fixe Werte werden über die Annotation attribute_in übergeben.
Beispiel:
INIT
|
|
|
|
|
classname = mp3converter.ChannelCreator
creation_mode = process
path=/usr/home/mp3converter
property java.security.policy=policy/policy.all
property java.lang.SecurityManager=java.lang.SecurityManager
string channelname, int init_size, string spacename
Resultiert in dem folgenden Aufruf:
java -Djava.security.policy=policy/policy.all
-Djava.lang.SecurityManager=java.lang.SecurityManager
mp3converter.ChannelCreator channelname init_size spacename
wobei die Argumente durch ihre aktuellen Werte der formalen Parameter ersetzt
werden.
2.7 IN-Event
Ein IN-Ereignis ist ein asynchrones Ereignis, dessen Umsetzung in JavaSpaces
dem Schreiben eines Entry-Objekts in einen vorgesehenen JavaSpace entspricht.
7
2.7.1 attribute_in
Durch die Annotation attribute_in werden vordefinierte Attributwerte der EntryObjekte gesetzt. Aufgrund der bei JavaSpaces-Operationen verwendeten Musteranpassung kann es nötig sein, bestimmte Attribute mit einem konstanten Wert vorzubelegen, der von der angesprochenen Komponente immer mit dieser Belegung
erwartet wird. Da dieser Wert immer konstant bleibt und sie ein Spezifikum der
Kommunikation auf JavaSpaces-Ebene und nicht auf AID-Ebene ist, soll dieses
Attribut für den späteren Benutzer der Komponente transparent sein.
Als Beispiel soll eine Klasse namens Index dienen, deren Inkarnationen zur
Verwaltung einer FIFO-Schlange dienen. Das type-Attribut der Klasse entscheidet
über die Verwendung des Index-Objekts als Kopf oder Ende der Schlange. Das
Ereignis
IN setTail
| attribute_in type=tail
| classname_in=queue.Index
string channel,
int position
wird realisiert, indem ein Objekt der Klasse queue.Index mit den Attributen channel, position und dem mit «tail» vorbelegten Attribut type im JavaSpace abgelegt
wird.
2.7.2 spacename_in
Die Annotation spacename_in beschreibt den JavaSpace, in den dieses Ereignis geschrieben werden soll. Ist für das übergeordnete Interface oder Component bereits
ein JavaSpace festgelegt, ist diese Annotation nicht obligatorisch, da der übergeordnete JavaSpace übernommen wird. Ist für das Ereignis ein JavaSpace annotiert,
so wird dieser benutzt.
2.7.3 classname_in
classname_in legt den voll qualifizierten Klassennamen des Entry-Objekts fest, das
das IN-Ereignis repräsentiert. Die Klasse muss das Interface org.jini.core.Entry implementieren, einen öffentlichen Standardkonstruktor besitzen sowie nur öffentliche, nicht-primitive Attribute besitzen. Näheres dazu in der JiniTM Entry Specification6 .
6
http://java.sun.com/products/jini/2.1/doc/specs/html/entry-spec.html
8
2.8 OUT-Event
Ein OUT-Ereignis ist ein asynchrones Ereignis, dessen Umsetzung in JavaSpaces
dem Lesen eines Entry-Objekts aus einen vorgesehenen JavaSpace entspricht. Im
Detail betrachtet, schreibt die Komponente ein Entry-Objekt in den JavaSpace. Der
Treiber entfernt dieses Tupel und leitet das Ereignis mitsamt Attributen an die Umgebung als Empfänger des Ereignisses weiter. Die Komponente erhält keine Rückantwort, daher ist die Kommunikation asynchron.
Da JavaSpaces die Operationen take und read beim Lesen von Tupeln unterscheidet, muss man diese beiden Varianten auch mit Hilfe von Annotationen
berücksichtigen. Ist die Annotation take_only für das OUT-Event gesetzt, wird das
Tupel aus dem Tupelraum nur gelesen und verbleibt im Tupelraum, im Standardfall
wird es aus dem Tupelraum entfernt.
Die für beide Fälle zu verwendenden Annotationen variieren nur geringfügig
in semantischen Details und sind deshalb gemeinsam aufgeführt.
2.8.1 attribute_out
Durch die Annotation attribute_out werden vordefinierte Attributwerte des zur Musteranpassung verwendeten Entry-Objekts gesetzt. Wie bei attribute_out kann es
aufgrund der bei JavaSpaces-Operationen verwendeten Musteranpassung notwendig sein, dass bestimmte Ereignisse durch fixe Belegung von Attributewerten charakterisiert sind. Will der Treiber ein derartiges Ereignis entgegennehmen, muss er
dieses Attribut mit diesem konstanten Wert vorzubelegen, um andere nicht gewollte Ereignisse auszuschließen.
Wir schließen an das Beispiel für die Annotation attribute_in für IN-Ereignisse
an. Um ein für das Ereignis getTailPosition passendes Entry-Objekt zu erhalten,
muss das Attribute type mit "tail"vorbelegt sein. Dadurch werden Objekte, die den
Kopf der Schlange beschreiben, von der Mustererkennung ausgeschlossen.
INOUT getTailPosition
string channel, | take
RETURNS
int position
|
attribute_in type="tail"
|
classname_out=mp3converter.Index
|
tupelspace=music.mp3ts
Entwurfsüberlegung Konzeptionell wäre auch vorstellbar, die Annotationen attribute_in und attribute_out nicht zu verwenden. Das Problem hierbei liegt jedoch darin, dass diese fixen Belegungen notwendig sind, um die Kommunikation
zwischen Treiber und Komponente zu ermöglichen. Im Fall des oben gezeigten
INOUT-Ereignisses müsste der Benutzer das Attribute type immer auf tail setzen, ansonsten würde der Kopf der Schlange ausgelesen, der jedoch in diesem Fall
9
ausschließlich von der Komponente benutzt wird. Diese zusätzliche Information
müsste in der Schnittstelle dokumentiert und bei der Verwendung der Komponente
beachtet werden.
Die Entscheidung für oder gegen die Verwendung vordefinierter Attribute als
Annotationen ist letztendlich eine Designentscheidung hinsichtlich der Frage, wie
viel Abstraktion die Schnittstelle zu einer JavaSpaces-Komponente bieten soll.
Denkbar wäre beispielsweise eine Komponente, deren Funktionsfähigkeit von der
Belegung eines Attributes mit einer magic number abhängt. Diese magic number hat immer die gleiche Belegung und wird bei einem Ereignis immer gesetzt.
Grundsätzlich ist hier auch ein manuelles Setzen dieses Attributs durch den Benutzer der Komponente denkbar, jedoch erscheint die Abstraktion davon mit Hilfe
von vordefinierten Attributen doch als die komfortablere Alternative.
Will man auf der anderen Seite dem Benutzer das Setzen dieses Attributs ermöglichen, so ist das durch eine entsprechende Modifizierung der AID-Schnittstelle
jederzeit möglich.
2.8.2 spacename_out
Bezeichnet den JavaSpace, in den die Komponente die Entry-Objekte für dieses
Ereignis schreibt. Ist für ein Ereignis ein kein separater spacename_out annotiert,
so wird der JavaSpace aus der jeweiligen Interface bzw. Component-Annotation
verwendet. Aus diesem JavaSpace werden die Entries gelesen, die den OUT-Teil
von OUT und INOUT und OUTIN-Ereignissen darstellen.
2.8.3 classname_out
classname_out legt den voll qualifizierten Klassennamen des Entry-Objekts fest,
das das OUT-Ereignis repräsentiert. Die Klassendefinition muss der JiniTM Entry
Specification entsprechen. Objekte dieser Klasse werden als Template verwendet,
um Entry-Objekte, die OUT-Ereignisse repräsentieren, aus dem Tupelraum zu entfernen. Die gelesenen/entnommenen Entry-Objekte besitzen ebenfalls diesen Typ
classname_out.
2.9 INOUT-Event
Es gibt zwei verschiedene Möglichkeiten, ein AID-INOUT-Ereignis auf JavaSpaces zu übertragen. Zur Unterscheidung dieser beiden Fälle dient die Annotation matching_only. Ist sie bei einem INOUT-Ereignis vorhanden, zeigt sie an, dass
lediglich ein Entry-Objekt mittels Musteranpassung aus dem Tupelraum entfernt
werden soll. Ist diese Annotation nicht gesetzt, wird ein Entry-Objekt im Tupelraum abgelegt und anschließend ein Antwort-Tupel entnommen.
10
2.9.1 Ledigliches Entfernen eines Entry-Objekts aus dem Tupelraum
Es wird lediglich ein Entry-Objekt aus dem Tupelraum entnommen. Dazu muss
ein Template-Objekt erzeugt werden, dessen Attribute gemäß der aktuellen Ereignisparameter gesetzt werden. Mit diesem Objekt als Template wird eine takeOperation ausgeführt. Die Untermenge an Attributen des als Rückgabewert erhaltenen Entry-Objekts, die in der RETURNS-Liste enthalten ist, wird im OUT-Ereignis
als Antwortereignis gesetzt.
Dieser Kommunikationsakt findet asynchron zwischen Umgebung und Komponente statt. Die Komponente sorgt lediglich dafür, dass ein passendes EntryObjekt im Tupelraum vorhanden ist, der Treiber liest dieses zeitlich entkoppelt aus
dem Tupelraum aus und leitet es an die Umgebung weiter.
2.9.2 Schreiben und anschließendes Lesen von Entry-Objekten
Zuerst wird ein Entry-Objekt im Tupelraum abgelegt, im Anschluss daran wird
ein Antwort-Tupel entnommen. Dazu wird erst ein Entry-Objekt von Typ classname_in erzeugt und seine Attribute mit denjenigen Parametern gesetzt, die die
Annotation write besitzen. Konstante Attribute werden durch die Annotation attribute_in erkannt und die entsprechenden Felder des Entry-Objekts gesetzt. Dieses
Objekt wird in den Tupelraum abgelegt.
Anschließend wird ein Template erzeugt, um ein Anwort-Tupel möglicherweise anderen Typs zu entnehmen. Für dieses Auslesen ist es unter Umständen notwendig, Attribute des Template-Objekts mit bestimmten Werten zu belegen. Hierzu werden mit write annotierte Parameter sowie konstante Attribute, die durch die
Annotation attribute_out zur Verfügung gestellt werden, benutzt.
Mit diesem Objekt als Template wird analog zum ersten Fall eine take-Operation
ausgeführt. Die Untermenge an Attributen des als Rückgabewert erhaltenen EntryObjekts, die in der RETURNS-Liste enthalten ist, wird im OUT-Ereignis als Antwortereignis gesetzt.
In diesem Fall sind also obligatorische take und write-Annotationen für
die Parameter der Parameterliste notwendig. Parameter können hier sowohl zur
Musteranpassung als auch als Belegungen der Attribute des Tupels, das in den Tupelraum abgelegt wird, benutzt werden. Näheres dazu unter Parameter.
Analog zu OUT-Ereignissen müssen auch für diese beiden Fälle von INOUTEreignissen die Operationen take und read beim Lesen von Tupeln unterschieden werden. Ist die Annotation take_only für das INOUT-Event gesetzt, wird beim
OUT-Teil des Ereignisses das Tupel aus dem Tupelraum nur gelesen und verbleibt
im Tupelraum, im Standardfall wird es aus dem Tupelraum entfernt.
2.9.3 attribute_out
Die für beide Fälle zu verwendenden Annotationen variieren nur geringfügig in
semantischen Details und sind deshalb gemeinsam aufgeführt.
11
2.9.4 attribute_in
Durch die Annotation attribute_in werden vordefinierte Attributwerte der EntryObjekte gesetzt. Die Verwendung geschieht analog zu IN-Ereignissen. Diese konstanten Attribute beziehen sich auf das Entry-Objekt, das zu Beginn in den Tupelraum geschrieben wird, findet also nur im zweiten Fall, also im Fall des Lesens
und Schreibens von Tupeln Verwendung.
2.9.5 spacename_in
Die Annotation spacename_in beschreibt den JavaSpace, in den das zuerst abzulegende Tupel geschrieben werden soll. Es wird analog zum gleichnamigen Attribut
bei IN-Ereibnissen verwendet. Dieses Attribut bezieht sich wie attribute_in auf das
Entry-Objekt, das zu Beginn in den Tupelraum geschrieben wird, es findet also
auch nur im zweiten Fall Verwendung.
2.9.6 classname_in
classname_in legt den voll qualifizierten Klassennamen des Entry-Objekts fest, das
das IN-Ereignis repräsentiert. Die Klasse muss das Interface org.jini.core.Entry implementieren, einen öffentlichen Standardkonstruktor besitzen sowie nur öffentliche, nicht-primitive Attribute besitzen. Näheres in der JiniTM Entry Specification
. Dieses Attribut bezieht sich ebenfalls nur auf das Entry-Objekt, das im zweiten
Fall zu Beginn in den Tupelraum geschrieben wird.
2.9.7 attribute_out
attribute_out wird analog zur gleichnamigen Annotation bei OUT-Ereignissen verwendet. Es werden dadurch beschriebene vordefinierte Attributwerte des zur Musteranpassung verwendeten Entry-Objekts gesetzt.
2.9.8 spacename_out
spacename_out wird ebenfalls analog zur entsprechenden Annotation bei OUTEreignissen verwandt. Die Annotation bezeichnet den JavaSpace, aus dem EntryObjekte gelesen werden, die die Komponente als OUT-Ereignis in diesen Tupelraum schreibt.
2.9.9 classname_out
classname_out wird ebenfalls analog zur gleichnamigen Annotation bei OUT-Ereignissen
verwendet. Objekte dieser Klasse werden als Template verwendet, um Entry-Objekte,
die OUT-Ereignisse repräsentieren, aus dem Tupelraum zu entfernen.
12
2.10 OUTIN-Event
OUTIN-Ereignisse stellen sich in JavaSpaces folgendermaßen dar: Die Komponente schreibt ein Entry-Objekt ein den Tupelraum. Der Treiber leitet dieses Ereignis
an die Umgebung weiter, welche im Anschluss ein Anwortereignis zurücksendet.
Der Treiber ist daraufhin veranlasst ein Anworttupel entsprechend dem Antwortereignis in den Tupelraum zurückzuschreiben.
Analog zu OUT-Ereignissen müssen auch hier die Operationen take und read
beim Lesen von Tupeln unterschieden werden. Ist die Annotation take_only für das
INOUT-Event gesetzt, wird beim OUT-Teil des Ereignisses das Tupel aus dem Tupelraum nur gelesen und verbleibt im Tupelraum, im Standardfall wird es aus dem
Tupelraum entfernt.
2.10.1 attribute_out
Die Parameter der Parameterliste müssen bei OUTIN-Ereignissen separat mit take
oder write-Annotationen versehen werden, abhänging davon, ob sie für das Entnehmen des Entry-Objekts das das OUT-Ereignis repräsentiert, vorgesehen sind
oder für das Entry-Objekt, das anschließend in den Tupelraum als Antwort zurückgeschrieben wird. Näheres dazu im Abschnitt Parameter.
Die Typen in der RETURNS-Liste müssen eine Untermenge der Attribute des
Entry-Objekts sein, das aus dem JavaSpace gelesen wird. Für diese Typen ist keine
Unterscheidung in take oder write notwendig.
2.10.2 attribute_in
Durch die Annotation attribute_in werden vordefinierte Attributwerte der EntryObjekte gesetzt. Die Verwendung geschieht analog zu IN-Ereignissen. Diese konstanten Attribute beziehen sich auf das Entry-Objekt, das als Antwort in den Tupelraum geschrieben wird.
2.10.3 spacename_in
Die Annotation spacename_in beschreibt den JavaSpace, in den das als Antwort
abzulegende Tupel geschrieben werden soll. Es wird analog zum gleichnamigen
Attribut bei IN-Ereibnissen verwendet. Dieses Attribut bezieht sich also wie attribute_in auf das Entry-Objekt, das von der Umgebung als Antwort in den Tupelraum geschrieben wird.
2.10.4 classname_in
classname_in wird analog zur gleichnamigen Annotation der IN-Ereignisse verwendet. Dieses Attribut bezieht sich ebenfalls nur auf das Entry-Objekt, das als
Antwort von der Umgebung in den Tupelraum geschrieben wird.
13
2.10.5 attribute_out
attribute_out wird analog zur gleichnamigen Annotation bei OUT-Ereignissen verwendet. Es werden dadurch beschriebene vordefinierte Attributwerte des zur Musteranpassung verwendeten Entry-Objekts gesetzt.
2.10.6 spacename_out
spacename_out wird ebenfalls analog zur entsprechenden Annotation bei OUTEreignissen verwandt. Die Annotation bezeichnet den JavaSpace, aus dem EntryObjekte gelesen werden, die die Komponente als OUT-Ereignis in diesen Tupelraum schreibt.
2.10.7 classname_out
classname_out wird ebenfalls analog zur gleichnamigen Annotation bei OUT-Ereignissen
verwendet. Objekte dieser Klasse werden als Template verwendet, um Entry-Objekte,
die OUT-Ereignisse repräsentieren, aus dem Tupelraum zu entfernen.
2.11 Parameter
Die AID-Parameter werden über Namensgleichheit den öffentlichen Attributen der
Entry-Objekte zugeordnet. Die Attribute der Entry-Klassen müssen dem Datentyp,
der durch die kanonische Zuordnung von AID-Datentypen und Java-Datentypen
vorgeschrieben ist.
Um die für die Ereignisse vom Typ INOUT und OUTIN nötige Unterscheidung
der Parameter zu realisieren, wurden für Parameter die Annotationen take und write
eingeführt.
2.11.1 take
Der mit take annotierte Parameter wird zur Belegung eines Attributes des als Template verwendeten Entry-Objekts benutzt.
2.11.2 write
Der mit write annotierte Parameter wird zur Belegung eines Attributes des EntryObjekts verwendet, das in den Tupelraum abgelegt wird.
2.11.3 matching_param
Semantisch ist die Annotation matching_param die Kombination aus den Annotationen take und write. Je nachdem, ob sie bei INOUT oder OUTIN-Ereignissen
verwendet wird, hat ihre Benutzung unterschiedliche Auswirkungen.
14
Benutzung von matching_param bei OUTIN-Events Hierbei bezeichnet matching_param ein benutzerdefiniertes Attribut, das zur Belegung eines Attributes
des Template-Objekts zum Auslesen des OUT-Ereignisses verwendet wird. Dasselbe, dem Parameter entsprechende Attribut wird auch beim anschließend im Tupelraum abgelegten Objekt gesetzt, das dem IN-Ereignis entspricht.
Benutzung von matching_param bei INOUT-Events Ein mit der Annotation
matching_param versehenes Attribut wird bei INOUT-Ereignissen als Attribut
des initiativen IN-Ereignisses gesetzt und anschließend bei der Mustererkennung
zur Entnahme des Antworttupels benutzt.
Die Annotation matching_param kann nur im zweiten Fall von INOUT-Ereignissen
verwendet werden, bei dem Tupel in den Tupelraum geschrieben und wieder entfernt werden. Der mit matching_param annotierte Parameter wird dann sowohl im
abzulegenden Objekt gesetzt als auch zur Musteranpassung beim Template-Objekt
zur Entnahme des Antworttupels.
Im Unterschied zur Annotation attribute_out wird der Parameter für jedes AIDEreignis vom Benutzer festgelegt und bezeichnet nicht ein konstantes Attribut.
Als Beispiel diene ein virtueller Marktplatz. Der Anwender hat die Wahl, Angebote auf Artikel abzugeben, die eine eindeutige Kennung besitzen. Vorstellbar ist eine Operation, um ein Gebot abzugeben, das Antworttupel beinhaltet die
Information, ob der Artikel bereits verkauft ist. Die beiden Entry-Klassen seien
Bid und SaleState. Bei der Beschreibung der Operation wird der Parameter
article_id verwendet, der mit der Annotation matching_param versehen ist.
Das Attribut article_id wird als Attribut des Bid-Objekts gesetzt, das zuerst in den
Tupelraum geschrieben wird. Anschließend wird ein Template-Objekt SaleState erzeugt, bei dem wiederum article_id entsprechend dem Parameterwert gesetzt wird,
um ausschließlich SaleState-Objekte auszulesen, die sich auf diesen Artikel beziehen.
Literatur
[1] S. Hupfer. Make Room for JavaSpaces, Part
(www.javaworld.com), Copyright IDG, October 2000.
15
IV.
JavaWorld