Contents

• • • 1 Introductie
      • 1.1 Technologie
      • 1.2 Doel
      • 1.3 Reisgids
      • 1.4 Dankbetuiging
    • 2 Agents
      • 2.1 Hoog niveau aspecten van agents
      • 2.2 Definitie van een agent
      • 2.3 Gebruik van mobiele agents
      • 2.4 Mobiliteit
      • 2.5 Security en persistentie
      • 2.6 Location control
      • 2.7 Proxy agents
      • 2.8 Communicatie
      • 2.9 Conclusie
    • 3 Java
      • 3.1 De virtuele machine
      • 3.2 De taal Java
      • 3.3 Conclusie
    • 4 Aglets
      • 4.1 Overzicht
      • 4.2 Een Aglet
      • 4.3 Proxy agents
      • 4.4 Naming
      • 4.5 Security
      • 4.6 Conclusie
    • 5 Mole
      • 5.1 Overzicht
      • 5.2 Een Mole
      • 5.3 Communicatie
      • 5.4 Proxies
      • 5.5 Meta level
      • 5.6 Conclusie
    • 6 Infosphere
      • 6.1 Overzicht
      • 6.2 Een Djinn
      • 6.3 Mobiliteit
      • 6.4 Communicatie
      • 6.5 Persistentie
      • 6.6 Proxies
      • 6.7 Naming & meta data
      • 6.8 Conclusie
    • 7 Conclusie
    • 8 Location control
      • 8.1 Naming
      • 8.2 Routing
      • 8.3 Correctheid
      • 8.4 Referenties
      • 8.5 Conclusie
    • 9 Communicatie
      • 9.1 Interface
      • 9.2 Implementatie
    • 10 Levensloop van een Agent
      • 10.1 Creëren van agents
      • 10.2 Wijzigen van ``self''
      • 10.3 Processen
      • 10.4 Verplaatsen van agents
      • 10.5 Proxy-agent
      • 10.6 Garbage collection
      • 10.7 Conclusie
    • 11 Conclusie
      • 11.1 Resultaat
      • 11.2 Gebreken
      • 11.3 Voortzetting van deze thesis
  
  
• Bibliography
• Index

1 Introductie

Het is opvallend hoe vandaag binnen computer netwerken de grens tussen client en server gaandeweg vervaagt om plaats te maken voor een nieuwe vorm van gedistribueerde programma's. Door de enorme toename in performantie van de modale PC is de zogenaamde client immers reeds in staat om zuivere netwerk programma's zoals FTP- en WWW-servers te ondersteunen. Anderzijds blijven er natuurlijk een hele reeks diensten over die niet lokaal kunnen aangeboden worden en die toch een hoge graad van interactiviteit langs de client-kant vereisen. Een voorbeeld hiervan zijn de talrijke search engines op het internet: door hun omvang en algemeenheid leveren ze minder relevante informatie op zodat een intelligente interactie met de eindgebruiker onontbeerlijk wordt. Denken we hierbij aan een adaptieve filter die tijdelijk lokaal wordt geïnstalleerd om relevante informatie te herkennen en die nauw samenwerkt met de eigenlijke search engine. Een ander voorbeeld zijn web crawlers: aangezien deze vanuit een lokale machine het internet doorlopen geeft dit aanleiding tot een spectaculaire verspilling van de beschikbare bandbreedte. Eigenlijk moet men dus stellen dat de enorme toename in stabiliteit en performantie van de hardware een drastische terugloop in de verhouding aantal clients/aantal servers met zich meebrengt.

Op het gebied van de software architectuur treffen we in dit kader de grootste afwijkingen van het traditionele client/server beeld; Java applets die delen van de programmatuur van een traditionele server exporteren naar de client zijn het best gekende voorbeeld. Nochtans zijn er reeds verschillende resultaten in de zoektocht naar een meer symmetrische structuur in gedistribueerde systemen: SUN en IBM ontwikkelen respectievelijk zogenaamde servlets [20] en aglets [17]. De visie die hierbij ontstaat is er een van ver doorgedreven uniformiteit: alle processen binnen een dergelijk netwerk zijn in hetzelfde medium uitgedrukt. Daarom nemen wij ons hier voor toekomstige gedistribueerde systemen te beschouwen als dynamische omgevingen waarbinnen mobiele software agents met elkaar en met menselijke gebruikers kunnen communiceren. ¹

De voornaamste reden om de notie van mobiele software in overweging te nemen is de reductie van nodeloze communicatie binnen een groot netwerk. In een systeem zoals het internet, waarbij een immens groot aantal machines op een niet reguliere manier met elkaar verbonden zijn kan het reactievermogen van agents, dat wil zeggen persistente en autonome software componenten, verhoogd worden door ze ook mobiel te maken. Zo kan bijvoorbeeld de mobiliteit van een menselijke gebruiker weerspiegeld worden in de mobiliteit van een persoonlijke agent die hem of haar op het internet vertegenwoordigt.

1.1 Technologie

Enerzijds is er dus het probleem van distributie, maar anderzijds is er ook de push die de huidige technologie geeft. Krachtige computers en netwerken laten toe het performantieverlies van virtuele machine (VM) technologie te accepteren om de voordelen ervan te kunnen uitbuiten.

In zijn thesis `Language support for Mobile Agents' [9] beschrijft Frederick Colville wat een programmeertaal nodig heeft en welke voorzieningen aangaande taalconstructies en taalimplementatie aangenaam zijn als we zelf een agent framework willen programmeren. Laat ons hierover even uit wijden.

• Uit ervaring weten we dat geheugenbeheer op één machine met één processor de programmeur vaak onnodige kopzorgen baart en vaak tot onnodige fouten leidt. In deze context biedt als technologie met zijn simulatie van een oneindig geheugen de uitkomst. In een gedistribueerde omgeving daarentegen waar men naar een object kan refereren van buiten uit de virtuele machine wordt dit een nog groter probleem. Stel dat 2 agents naar hetzelfde object refereren en de eerste agent verplaatst zich uit de machine. Op een gegeven moment houdt de tweede agent op te bestaan. Hoe kan de virtuele machine weten dat naar dit object nog wel degelijk gerefereerd wordt ? Omdat dit probleem te complex wordt hebben we nood aan automatisch geheugenbeheer.
• In gedistribueerde omgevingen en bijbehorende architecturen komt het maar al te vaak voor dat we een en hebben. De transportlaag zorgt over het algemeen voor het verplaatsen van een byte stream van de ene machine naar de andere. De communicatielaag vormt de link tussen intern gerepresenteerde objecten naar netwerk gerepresenteerde objecten. Als we bijvoorbeeld communicatie beschouwen tussen een 386-architectuur en een SPARC workstation zullen we de convertie van big endian² naar little endian in acht moeten nemen. Deze convertie verwacht dat de programmeur semantiek op zijn byte streams plakt en zegt wat een entiteit vormt. 4 bytes zijn niet noodzakelijk een integer. Dit vraagt altijd de nodige interactie tussen het systeem en de communicatielaag. Meestal moet de programmeur aan elke klasse of structuur methoden writeToStream en readFromStream toevoegen. Het zou aangenaam zijn mocht de programmeertaal dit proces zo goed mogelijk automatiseren.
• Niet alleen op niveau van hardware wat betreft little endian en big endian treffen we problemen aan, maar ook wat betreft het operating system en aanwezige API's ontdekken we afwijkingen. We zouden bijvoorbeeld graag een agent verhuizen van een Unix workstation naar een NT-client. We hebben dus een taal nodig die in staat is deze heterogeniteit te virtualiseren.
• Eens dit allemaal opgelost is moeten we natuurlijk ook de code kunnen verplaatsen van machine $x$ naar machine $y$. Dit kan gaan van de verplaatsing van agent beschrijvingen tot het verplaatsen van gecompileerde agents. Net zoals we opgemerkt hebben bij de transportlaag willen we dit zo doorzichtig mogelijk aanbieden.
• Het is duidelijk dat elke machine meerdere agents moet kunnen herbergen omdat we niet willen dat de aanwezigheid van een agent op een machine een andere agent belet te bestaan. Dit wil zeggen dat deze agents parallel moeten kunnen uitvoeren zonder in elkaars vaarwater te zitten. Ze zullen dus uitgevoerd moeten worden in hun eigen thread zonder dat coöperatie verwacht wordt van de agent.
• Stel dat we toch coöperatie verwachten van de agent, dan kan deze agent het hele systeem blokkeren en op oneerlijke wijze resources benutten die voor andere agents bestemd waren. Dit veiligheidsaspect van agents is er een dat opgenomen moet worden in de taal en zijn structuur, des te meer ook andere agents beschermd moeten worden tegen aanvallen van buiten uit. Interpreters vormen in deze context een onverwacht bruikbare oplossing. Door de virtualisering van de hardware en expliciete uitvoering van instructies houden we de executie van een agent totaal in de hand zoals opgemerkt in [8].

Het blijkt nu dat de Java bytecode interpreter aan veel van deze eisen voldoet en ons vandaag de mogelijkheid geeft snel een compacte implementatie te bouwen waarbinnen nagedacht en geëxperimenteerd kan worden over high-level communicatie tussen agents om zo tot beter onderhoudbare, abstractere modellen van interprocescommunicatie te komen. Het agent systeem wordt bijgevolg geprogrammeerd in Java, net zoals de agents zelf.

1.2 Doel

In deze thesis willen we testen hoe goed we in staat zijn dergelijk mobiele agents te implementeren met behulp van Java. Hiertoe zullen we dus de voor- en nadelen van bestaande agent systemen moeten onderzoeken. Aangezien dit nog een jonge technologie is die nog niet op punt gebracht is, is er ongetwijfeld plaats voor verbetering. We zullen trachten een aantal problemen zoals location transparency en communicatie te behandelen door het bouwen van een eigen agent systeem.

Het programmeren van agents in dit framework zou moeten overeenkomen met het expliciteren van de objecten die we ontdekken in een . De gemakkelijkste wijze om hierover te redeneren is te denken aan diensten die iemand nodig heeft, aan diensten die iemand aanbied. Beschouw een agent als een representatie van de wensen van een gebruiker.

1.3 Reisgids

In het eerste deel onderzoeken we een aantal agent systemen die in Java geprogrammeerd zijn. Hierbij trachten we de voordelen en nadelen van elk systeem grondig af te wegen. Om dit te kunnen doen diepen we eerst allerhande aspecten van agents uit en creëren we het nodige referentiekader. Naderhand bespreken we in hoeverre de Java virtuele machine en zijn bijhorende taal voorzieningen bieden voor de ontwikkelingen van een dergelijk systeem.

Na de literatuurstudie zullen we in het tweede deel een eigen framework ontwikkelen dat de voordelen van de bekeken systemen tracht te integreren. Speciale aandacht zal hierbij worden geschonken aan location transparency en persistentie.

Om de leesbaarheid te verhogen zullen we, als we code in de tekst voegen, enkel het essentiële overhouden. Constructors die onmiddellijk hun super aanroepen, try-catch clauses en dergelijke worden niet vermeld. URL's en gelijkaardige namen worden sans serif gezet. Bijvoorbeeld http://ketchup.rave.org/~werner Klassenamen en methodenamen worden altijd in typewriter mode geprint. We nemen de conventie van Java en SmallTalk over en laten elke klassenaam met een hoofdletter beginnen; methodenamen laten we van start gaan met een kleine letter. Bijvoorbeeld: object myDictionary is een instantie van de klasse MyDictionary.

Deze thesis is niet in perfect algemeen Nederlands geschreven omdat sommige termen onvertaalbaar zijn zonder een onverstaanbare tekst over te houden. Waar we konden hebben we Nederlands op een consistente wijze gehanteerd. Vaktermen en code hebben we in hun standaardtaal, het Engels, gelaten. Zo nu en dan wordt zowel het Nederlands als het Engels voor een bepaald woord gebruikt, bijvoorbeeld `message' of `bericht'. Dit komt omdat we langzaam van een vakterm zoals `message passing' overgaan naar `het sturen van berichten'

1.4 Dankbetuiging

Eerst en vooral zou ik Wolfgang De Meuter (Wolf) willen bedanken voor de uren die hij samen met mij gespendeerd heeft om mij van `char*' tot `String' te promoveren. Professor Theo D'Hondt is zo gul geweest mij de vrijheid te geven allerhande onderzoeksdomeinen af te schuimen vooraleer ik dit onderwerp ter hand heb genomen. Patrick Steyaert heeft de tekst nagelezen en een aantal sublieme meta-meta-hints gegeven aangaande het nut van agents. Niels Boyen, de distributie expert van het 10e, heeft mij een hoop papers in verband met data distributie aan de hand gedaan. Geert Lathouwers heeft mijn werk geregeld geminimaliseerd door telkens weer opnieuw een paper op te diepen die net hetgene uitlegt dat ik bedacht had. Technische ondersteuning heb ik gekregen van Joe Kiniry (de schrijver van de Infosphere) en Joachimm Baum (één van de ontwikkelaars van het Mole systeem). Carinne Lucas, Tom Lenaerts en Thomas Unger hebben de finale versie opgepoetst. Zeker wat betreft de L^ATEXcode moet ik Thomas dankbaar zijn.