Nächste Seite: 3.3 Kanal-Sicht
Aufwärts: 3. Risikoanalyse für MASA
Vorherige Seite: 3.1 Modell von MASA
  Inhalt
Unterabschnitte
3.2 Entitäten-Sicht
Für die in Kap. 2.5
geforderte Authentisierung ist es zunächst erforderlich, daß die
einzelnen Entitäten identifiziert werden können. Die nachfolgende
Tabelle 3.1 gibt eine Übersicht
darüber, ob und wie dies in der MASA-Implementierung möglich
ist.
Tabelle 3.1:
Übersicht über Möglichkeiten zu Identifizierung und
Authentisierung in MASA
|
Möglichkeit zur |
Entität |
Identifizierung |
Authentisierung |
Agentengattungen |
Java-Package & Name der Hauptklasse |
- |
Applets |
Java-Package & Name der Hauptklasse |
- |
Agenteninstanzen |
Datenstruktur CfMAF.Name |
- |
Agentensysteme |
Datenstruktur CfMAF.Name |
- |
Endsysteme |
indirekt über Agentensystem |
- |
Client-Systeme |
IP-Adresse |
- |
Benutzer von A.-Systemen |
- |
- |
Benutzer von A.-Instanzen |
- |
- |
Implementierer von A.-Gattungen |
- |
- |
|
Agentengattungen können über den hierarchisch aufgebauten Namensraum
der Java-Klassen eindeutig identifiziert werden. Nach Konvention wird
die Basis des Package-Namens einer Java-Klasse durch den
rückwärts geschriebenen DNS-Namen der erstellenden Organisation
gebildet, woran sich die weitere organisatorische und
implementierungstechnische Gliederung anschließt. Eine weitere und
MASA-spezifische Konvention besagt dann noch, daß der Name der
Hauptklasse eines Agenten aus der letzten Hierarchie-Ebene des
Package-Namens und dem Agententypen (MobileAgent oder
StationaryAgent) gebildet wird.
Beispielsweise trägt die Hauptklasse der Gattung des
FOO-Agenten den Namen
de.unimuenchen.informatik.mnm.FOO.FOOMobileAgent, gebildet
aus dem DNS-Namen informatik.uni-muenchen.de, der Bezeichnung
der Suborganisation ``MNM'', der Gattung ``FOO'' und dem Typen
``mobiler Agent''.
Äquivalent zu den Agentengattungen können Applets am Package-Namen
ihrer Hauptklasse identifiziert werden.
Da davon ausgegangen werden kann, daß jede Organisation, die Agenten
implementiert, im DNS-Namensraum vertreten ist und vom DNS-Namen
eindeutig auf die Organisation geschlossen werden kann, ist der
geschilderte Mechanismus zur Bildung von Gattungsnamen als ausreichend
für deren Identifizierung anzusehen.
Die für Agenteninstanzen und Agentensysteme in
[OMG 98-03-09], Kap. 1.2 und Kap. 3.5 definierten und
nach [Kemp 98], Kap. 4.5.1 in MASA verwendeten Datenstrukturen
erfüllen voll die für eine eindeutige Identifizierung notwendigen
Eigenschaften. Dabei bezieht sich die Eindeutigkeit nicht nur lokal
auf ein Agentensystem, sie ist prinzipiell vielmehr auch global über
die Grenzen der Agentensysteme hinweg im gesamten SmA gegeben.
Endsysteme können in MASA nach der in [Kemp 98], Kap. 4.5.1
definierten Konvention über den Identifikator des Agentensystems
eindeutig identifiziert werden. Diese besagt, daß in der
Datenstruktur CfMAF.Name das Strukturelement
Identity auf den Host-Namen des Endsystems zu setzen ist.
Konkret wird dabei der DNS-Name als Host-Name, und damit als
Identifikator des Endsystems, verwendet, womit ein Endsystem im
DNS-Namensraum eindeutig identifiziert werden kann (siehe
AgentSystem.createAgentSystemName(...)).
Client-Systeme können in MASA z. Zt. nur im Namensraum der
IP-Adressen identifiziert werden. Genau betrachtet ist es nur
dem Webserver-Agenten möglich eine solche Identifizierung
vorzunehmen, da dieser die HTTP-Verbindung zum Client-System
verwirklicht. Das Agentensystem selbst hat keine Kenntnis über die
Identität des Client-Systems.
Eine Identifizierung von Benutzern jeglichen Typs ist in MASA nicht
implementiert und auch nicht vorgesehen. Tatsächlich werden Benutzer
weder in [OMG 98-03-09] noch in [Kemp 98] betrachtet.
3.2.2 Schwächen der bisherigen Implementierung
Zwar wären einige Entitäten des Modells nach dem vorangegangenen
Abschnitt eindeutig identifizierbar, allerdings werden die
vorgestellten Identifikatoren in der vorliegenden MASA-Version noch
nicht konsequent und korrekt an allen Stellen eingesetzt.
So wird durchgängig für den Identifikator eines Agenten nur das
Identity Strukturelement betrachtet. Entsprechend wird in
der Hilfsklasse NameWrapper für die Bildung einer
String-Darstellung von CfMAF.Name in der Methode
toString() ausschließlich die Identity Komponente
benutzt. Folglich ist eine eindeutige Rückabbildung aus der
String-Darstellung zum CfMAF.Name nicht möglich.
Korrekt wäre, daß das gesamte 3-Tupel von CfMAF.Name als
Identifikator betrachtet wird und diese für die Abbildung auf eine
String-Darstellung herangezogen wird.
Daneben finden sich an verschiedenen Stellen auch noch individuelle
Abbildungen zur String-Darstellung, z.B. in der Klasse
AgentSystem wird das Attribut
agent_system_name deklariert. Es wird dann in
der main()-Methode mit einer String-Darstellung des
CfMAF.Name des Agentensystems belegt, ohne die Methode
toString() zu benutzen.
Als weiterer Kritikpunkt an MASA ist die nahezu
völlig fehlende Unterscheidung zwischen Agentengattungen und
Agenteninstanzen zu nennen. Diese konzeptionelle Schwäche hat
weitreichende Folgen, die sich über die gesamte Implementierung
erstrecken.
Am deutlichsten zeigt sich das Fehlen dieser Unterscheidung in der
Tatsache, daß es nicht möglich ist, auf einem Agentensystem von einer
Agentengattung mehrere Instanzen zu starten. Aber auch die
URL-Adressierung URL!Universal Resource Locator von
Applets einer Agenteninstanz in der Form
http://agentensystem:port/gattungsname
zeigt die Folgen. Um mehrere Agenteninstanzen der gleichen Gattung
unterscheiden zu können müßten die URL beispielsweise lauten:
http://agentensystem:port/cfmafName_string
Wie aus Tabelle 3.1
ersichtlich, wird eine Authentisierung momentan für keine der
Entitäten unterstützt, noch ist diese vorgesehen.
Nächste Seite: 3.3 Kanal-Sicht
Aufwärts: 3. Risikoanalyse für MASA
Vorherige Seite: 3.1 Modell von MASA
  Inhalt
harald@roelle.com