next up previous contents
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 - -


3.2.1 Identifizierung

3.2.1.1 Agentengattungen und Applets

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.

3.2.1.2 Agenteninstanzen und Agentensysteme

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.

3.2.1.3 Endsysteme

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

3.2.1.4 Client-Systeme

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.

3.2.1.5 Benutzer

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

3.2.3 Authentisierung

Wie aus Tabelle 3.1 ersichtlich, wird eine Authentisierung momentan für keine der Entitäten unterstützt, noch ist diese vorgesehen.


next up previous contents
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