Detta dokument beskriver utformningen och genomförandet av projektet Mobile Objects and Agents (MOA) vid Open Group Research Institute. MOA utformades för att stödja migration, kommunikation och kontroll av agenter. Det genomfördes på toppen av Java Virtual Machine, utan några ändringar av det. De ursprungliga projektmålen var att stödja kommunikation över agentmigration, som ett sätt att samarbeta; och att tillhandahålla omfattande resurskontroll, som ett grundläggande stöd för att motverka överbelastningsattacker. Under projektets gång lade vi till ytterligare två mål: överensstämmelse med komponentmodellen Java Beans som ger ytterligare konfigurerbarhet och anpassning av agentsystem och agentapplikationer; och driftskompatibilitet som möjliggör samarbete med andra agentsystem. I detta dokument analyseras MOA:s arkitektur, särskilt stödet för rörlighet, namngivning och lokalisering, kommunikation och resurshantering. Objekt och komponentmodeller av MOA diskuteras och några genomförande detaljer beskrivs. Vi sammanfattar de lärdomar som dragits när man utvecklar och genomför MOA och jämför det med relaterat arbete. Rörlighet har alltid lockat forskare inom datavetenskap. Detta intresse spänner från allmänna observationer, såsom "om det inte vore för rörlighet, skulle vi fortfarande vara träd" [10], och analogierna med den verkliga världen "migrerande fåglar och nomadstammar rör sig på grund av bristen på resurser", rent tekniska skäl, såsom att förbättra lokala referenser och skillnaden mellan lokala och avlägsna semantiker. En av de första inkarnationerna av programvarumobila enheter. är maskar [30], som kan spridas över noder och godtycklig klon. Obegränsade implementationer av maskar och virus har fått negativa konnotationer på grund av säkerhetsöverträdelser och överbelastningsattacker [13]. Nästa generation mobila enheter, så kallade processmigrering, genomfördes i driftssystemetDetta arbete stöddes delvis av byrån för avancerade forskningsprojekt och Romlaboratoriet vid flygvapnets Materielkommando. tem (OS) nivå. Det fanns många implementeringar av process och objekt migration [3, 12, 19, 31], men ingen har uppnått bred acceptans. På grund av den inneboende komplexiteten var det svårt att införa processmigration utan att påverka stabiliteten och robustheten hos det underliggande operativsystemet. Mobila föremål och agenter har fått stor uppmärksamhet på senare tid. Förutom mobil kod (t.ex. applets), agenter består av data och icke-övergående systemtillstånd som kan resa mellan noderna i ett distribuerat system (intranet eller Internet). Jämfört med mobila objekt representerar mobila agenter också någon; de kan utföra autonoma åtgärder för en användares eller en annan agents räkning. Detta dokument beskriver projektet Mobile Objects and Agents (MOA) vid Open Group Research Institute. Den uppenbara frågan är varför ännu ett mobilt agentsystem? Det fanns några skäl. Inget av de befintliga systemen vid tidpunkten för projektets start var tillräckligt moget för att användas som utgångspunkt för vårt arbete. Vi fann det lättare att utveckla ett annat system som skulle passa våra behov från början. Dessutom är vissa områden av vårt intresse, såsom kommunikation och resurskontroll, djupt involverade i utformningen av alla system, vilket gör det mycket svårt att lägga till dem som en eftertänksamhet. Slutligen var vi intresserade av interoperabilitet mellan systemen, och därför var det en bra idé att stödja ett annat genomförande. I början av projektet var vi intresserade av de två första av de fyra funktionerna som listas nedan, och under utvecklingen lade vi till de två sista: Samarbete. Ofta måste agenter samarbeta under utförandet antingen med andra agenter eller deras användare. För agentsamarbete är det nödvändigt att stödja namngivning, lokalisering och kommunikation mellan agenter. Förnekande av tjänsteangrepp. Agenter, såväl som värdar, är sårbara för ömsesidiga attacker, antingen via ett nätverk eller lokalt. För att förhindra överbelastning är det nödvändigt att upprätthålla resurskontroll av agenter och agentsystem, och att införa säkerhets- och resurspolicyer. Det blir allt svårare att konfigurera och anpassa programvara. När det gäller mobila agenter gäller detta både agenttillämpningar och agentsystem. Att vara kompatibel med en komponentmodell, såsom Java Beans, möjliggör ett standardiserat sätt att komma åt och ändra komponentegenskaper. Driftskompatibilitet. Agenter, såväl som agentsystem, måste samarbeta. När det gäller agentsystem leder driftskompatibiliteten till en större bas som agenterna kan besöka. Vi var aktiva i förslaget om en mobil agentanläggning för driftskompatibilitet för mobila agenter [26]. Mer information om hur dessa mål har uppnåtts finns i avsnitten 4.3, 4.6, 4.2 respektive 4.10. Resten av detta dokument är organiserat enligt följande. I Avsnitt 2 ger vi en bakgrund om mobila agenter och komponentbaserade datorer. Avsnitt 3 beskriver Javas lämplighet för mobila agenter och för komponentbaserad databehandling. I avsnitt 4 presenteras MOA:s utformning och genomförande. Avsnitt 5 diskuterar MOA nuvarande status. Avsnitt 6 beskriver vissa MOA-tillämpningar. I Avsnitt 7 presenterar vi lärdomar som dragits när man utformar och genomför MOA. MOA jämförs med relaterat arbete i avsnitt 8. Slutligen presenteras slutsatserna och det framtida arbetet i avsnitt 9. I detta avsnitt ger vi bakgrundsinformation om mobila agenter och komponentbaserade datorer. Bland fördelarna med mobila agenter skulle vi vilja understryka följande. En förbättring av referensorten uppnås genom att åtgärden flyttas mot datakällan eller andra slutpunkter för kommunikation, vilket leder till betydande resultatförbättringar. Överlevnad: liknande nomadstammar eller flyttfåglar, agenter kan överleva om de flyttas närmare resurser, eller bort från delvis misslyckade noder. Jämförbart med verkligheten hjälper vissa programmerare att bättre förstå programmeringsparadigm som uttrycks i termer av mobila agenter. Exempel är resande säljare, shoppare och arbetsflödeshanteringssystem. Anpassning av programvara kan uppnås med hjälp av mobila agenter, till exempel genom att justera sökningen enligt en användarspecifika kriterier, eller genom att utföra en åtgärd som är specifik för en avlägsen webbplats. Autonomi representerar agentens oberoende gentemot ägaren. En användare kan starta en agent för att agera för hans räkning och koppla bort. När användaren återansluter, returnerar agenten eller på annat sätt ger resultat. Agenter har olika utplaceringsområden. En är långsam och opålitlig länkar, såsom radiokommunikation, där lokalisering av referens förbättrar prestanda, och undviker potentiella förluster samtidigt överföra stora mängder data. Programdistributionen blir allt svårare. Mobil kod har gett ett revolutionerande genombrott, genom att tillåta nedladdning kod för heterogen miljö. Mobila agenter gör detta arbete ännu enklare, genom att associera åtgärder och ange med varje distribuerad version och kopia av en viss programvara. Nätverkshantering: agenter migrerar både kod och data, vilket gör dem användbara för att automatisera kontroll och konfiguration i storskaliga miljöer, såsom nätverk [15]. Elektronisk handel distribuerar mobila agenter genom att modellera resande säljare eller handlare som besöker butiker i ett elektroniskt köpcentrum. Data mining är en bekväm applikation för mobila agenter på grund av lokalisering av referens: agenter optimerar en sökning genom att vandra från plats till plats med stora mängder information. (Se [7] för ytterligare förmåner.) Icke desto mindre har mobila agenter fortfarande inte nått bred acceptans. Några av skälen är bland annat följande: Brist på tillämpningar: Mobila agenter har fått rykte om sig att "söka efter problemet". Många system har utvecklats men få tillämpningar finns. Säkerhet: de problem som orsakas av mobilkod rapporteras ofta. Mobila agenter trycker på säkerhetsproblemen ännu mer. Bristen på infrastruktur anpassad för mobila agenter, såsom namnservrar, meddelandesystem och hantering, är fortfarande inte allmänt utplacerad. Överlevnad är både en fördel och en utmaning för mobila agenter. Mobila agenter är till sin natur överlevnadsbara, men detta blir inte gratis; de måste utformas och genomföras för överlevnad. I synnerhet bör de minimera kvarvarande beroenden på tidigare besökta noder, eller servrar. Komponentbaserad programmering, inklusive OpenDoc, VBX och ActiveX, har varit ganska framgångsrik i att påskynda utvecklingen av GUI-program. Javabönor (komponenter skrivna i Java), är lovande för icke-GUI komponentprogrammering. Runtime beteende av en Java Bean definieras av en vanlig Java klass. Skillnaden mellan en böna och andra objekt är metadata som används för konfiguration. Det tillhandahålls av en tillhörande BeanInfo klass, eller det härrör från runtime klass. Komponentbaserad programmering förbättrar objektorienterade fördelar, såsom flexibilitet, och kodåteranvändning med två nya egenskaper: oberoende och konfiguration. Självständighet. Källkoden som definierar en komponent refererar inte direkt till någon annan komponent, utan i stället skapas samband mellan komponenter vid körtiden. Förhållandena kan fastställas av den behållare som håller komponenterna, eller till och med av själva komponenten. Detta har flera fördelar: • en "byggblock" metod: program är konstruerade från befintliga komponenter genom att definiera relationer • varje komponent kan testas individuellt • komponenter är lättare att återanvända; det finns ett minimum av ömsesidigt beroende mellan komponenter • ett program kan omstruktureras för nya krav utan att påverka logiken hos enskilda komponenter • uppdatera ett program med den senaste versionen av 3: e part komponenter förenklas Vi har valt Java eftersom det verkade vara den vanliga programmeringsspråket, men också på grund av de funktioner som gör det lämpligt för mobila agenter och komponenter. Java erbjuder fördelar för mobila agenter, samt vissa nackdelar. Fördelarna består av stöd för mobil kod, heterogenitet, språksäkerhet, objekt serialisering [28], reflektion, dynamisk klass lastning och multitrådning. Nackdelar består av otillräckligt stöd för resursförvaltning (t.ex. minne och diskgränser), inget stöd för att bevara trådutförande sammanhang, begränsat stöd för versionering, inget ägande av objekt och finkornigt skydd vid objekt granularitet [21]. Komponenter skrivna i Java är lätta och lite kod krävs för överensstämmelse med komponentmodellen. Java stöder ett antal nyckelfunktioner i komponentprogrammering: • En komponent kan ha flera gränssnitt. Java tillhandahåller implementation av flera gränssnitt, obegränsad gjutning, och en instans av operatör för att avgöra om en komponent stöder ett gränssnitt. • Flera komponenter kan sammanställas till en enda komponent. JDK 1.1-metoderna Beans.isInstanceOf och Beans.getInstanceOf kan användas i stället för exempel på operatör och gjutning, vilket möjliggör framtida användning av aggregation i JDK 1.2. • En komponents livslängd kan sträcka sig över mer än ett program. JDK:s bestämmelse om att serieisera komponenter gör det möjligt att omvandla ett objekt till ett formulär som kan skrivas till en diskfil eller skickas över ett nätverk. • En komponent konfigureras genom att ändra dess egenskaper identifieras genom att undersöka metoden signaturer av komponenten, t.ex. Klassen är erkänd som att ha egendom skivor, om metoderna fårSlices och setSlices finns. • Komponentens egenskaper nås med hjälp av klassen Introspector. MOA-arkitekturen presenteras i figur 1. Det finns tre typer av noder som kör MOA-system: front-end nod tillåter användare att styra och övervaka agenter; hem nod används som ett arkiv för agent data; och fjärr nod är där agenter normalt kör under hela sin livstid. namnserver spårar platsen för agenter och andra objekt, medan en bildskärm används för att kontrollera och övervaka objekt. Dessa och andra objekt i MOA-arkitekturen beskrivs mer i detalj i detta avsnitt. MOA-objekten på avlägsna noder kan klassificeras som agent-eller systemrelaterade (se figur 2). Agentrelaterade föremål är inringade; de har flytttillstånd. Agent och plats tillhör användarens trustdomän (se avsnitt 4.7 om mer information om säkerhet), medan andra komponenter tillhör MOA trustdomänen. En agent och plats är applikation utökade klasser. Agent är första klassens MOA-objekt. Det är en mall klass utvidgas av agent applikationer. Agenter namnges (se avsnitt 4. 4) och de kan kommunicera (se avsnitt 4. 3). En agent kan flytta till en agentmiljö (eller en plats inom den), det kan begära att träffa andra agenter på en viss plats eller agent miljö, öppna Channel till en annan agent, eller skicka meddelanden till den. En agent utför alltid inom en plats (se nedan). Det finns en en-till-en-kartläggning mellan en agent och en plats i ett agentsystem. Men en agent kan lämna platser bakom sig när den rör sig. Därför finns det en-till-många kartläggningar mellan en agent och platser på olika agentsystem. Plats är andra klassens MOA objekt. Den största skillnaden från agent är att platsen är ett stationärt objekt, och därför kan den inte röra sig eller mötas. Men platser kan kommunicera med andra platser och agenter; de kan vara aktiva, dvs.. De kan ha trådar på gång. Plats tjänar också container-proxy roll. De är proxies eftersom de kan förbli efter en agent lämnar och representera det där (vara proxy). De tjänar containerrollen för en agents säkerhet och resurser. Agent Control, Agent Properties, Family, LogService och Bucket är agent-relaterade klasser som tillhör MOA trust domänen. Agentkontroll är en intern klass som representerar ett gränssnitt mellan agentsystem och agent/plats. Den förvaltar agentsystemresurser (kommunikationskanaler, agentegenskaper osv.). Dessa objekt kan nås av en agent/plats, men de kan inte ändras. AgentProperties innehåller de egenskaper som kännetecknar agenter och överförs över noderna. Exempel är ägare, hemagent Miljö och lokaliseringStrategi. Familjen används för övervakning av agentaktiviteter. Varje agent har sitt eget familjeobjekt som den bär över migreringar. LogService hanterar lokala loggar. Bucket innehåller innehållet i en JAR-fil (JAva aRchive). Varje skopa implementerar en klasslastare för dynamisk laddning av burkfilen. En hashtable som finns i en hink gör det möjligt för klienten i en hink att effektivt indexera in i innehållet i en burkfil. Under övergången serialiseras komponenter som är inringade i figur 2 (med undantag för Place and Agent Control), placeras i skopan och skickas till destinationsnoden. Policy- och förhandlingsobjekt underhåller och hanterar information om resurser. Policy är en platshållare för fastigheter som beskriver policyn för en agent som anländer till en nod (agentPolicy), och en värd som tar emot agenten (hostPolicy), såsom agentens maximala livslängd, maximalt antal kanaler och maximala trådar. Förhandlaren för förhandlingar mellan agenten och den mottagande agentmiljön före agentens besök. Agentrörelsen är föremål för resursbehov och säkerhetsarrangemang mellan de två enheterna. Sandlåda och Agent Environment tillhandahåller grundläggande infrastruktur. Sandlådaklassen separerar agentapplikationen från agentsystemets tillstånd. Den växlar från agentens systemtråd till applikationstråd när det finns en annan skyddsdomän; den tjänar också till att byta från synkron till asynkron kommunikation när den går över nätverket. Resursanvändning och begränsningar spåras per sandlåda. AgentMiljö (AE) är behållaren för agenter och deras relaterade föremål vid ett agentsystem. Det finns en agentmiljö per Java Virtual Machine (JVM), men det kan finnas många per nod. Varje agent har sitt hem AE och alternativa hem AE om hemmet inte är tillgänglig. Messenger-skiktet använder Nets tjänster för att stödja en- och tvåvägsmeddelanden mellan komponenter. Komponenter adresseras med hjälp av destinationsagentsystemet och komponentnamnet. Namnserver spårar agentplatser. Namnserverklienterna kan (av)registrera och slå upp en agentplats. Namnserverklienter är användare (monitor) och agenter som letar upp platser för andra agenter för att kommunicera. Information om agentens plats (eller hur man hittar den) lagras i agentsystem som agenten besökte eller kommunicerade med. Namnserver spelar också rollen som Locator. Mover, Monitor och Logger tillhandahåller MOA-tjänster. Mover stöder agentrörelser. Den förhandlar om migration, fångar agentstaten och överför den. Monitor ger ett användargränssnitt för att styra och övervaka program (t.ex. agentens rörelse, kommunikation och resursanvändning). Logger loggar händelser i ett agentsystem till ihållande media. MoaApplet, BatchDriver och användarklasser stöder gränssnittet till MOA-systemet och dess applikationer. MoaApplet är ett applet-baserat gränssnitt som gör det möjligt för användare att interaktivt övervaka och felsöka agenter, att lansera dem, att ögonblicksbilda agentens tillstånd, och att fråga den loggade data. BatchDriver är ett skriptbaserat användargränssnitt för att tillhandahålla MoaApplets tjänster; vanligtvis används det för testningsändamål. Användarklass fungerar som ett gränssnitt mellan användaren applet och agenten. Den lanserar de förkonfigurerade agenterna, spårar agenterna och upprätthåller information av intresse för en användare. MOA-komponenter konfigureras med hjälp av MOAbatch-verktyget (se avsnitt 5). Komponentkonfigurationen definierar systemobjektträdet. MOA-systemet laddas genom att först ladda rotkomponenten. Varje komponent laddar sedan successivt komponenten under den i trädet. Komponenter är lokalt organiserade i ett märkt träd (se figur 3) som används för att dynamiskt etablera relationen mellan komponenterna, i motsats till statisk bindning, typisk för OO-programmering. Efter att komponenterna har laddats kan de lokalisera andra komponenter i agentsystemet med namn för att etablera dynamisk bindning. Icke-bladelement i objektträdet underklassar miljönBarnklass (se figur 4 ) som ger metoder för att lokalisera ett trädelement som ges ett relativt eller fullständigt sökvägnamn. Till exempel kan alla komponenter i figur 4 komma åt Mover-objektet genom att anropa metoden: getMiljö().getInstanceOf("/Mover",Mover.class) Koppling av komponenter i viss utsträckning negerar fördelarna med komponentprogrammering, och som sådan har den hållits till ett minimum. Till exempel görs nettokomponenten känd för andra komponenter, såsom de som underklass NetUser: AC, Messenger och godtyckliga program som använder Net. Vi har framgångsrikt använt komponenter för preconfiguring agent applikationer, liksom agentsystemet. För agentapplikationer kan vi enkelt konfigurera en agent resplan, policy, typer av loggning, felsökning, etc. Konfiguration av agentsystem anger vilka komponenter som kommer att integreras i trädet. Till exempel, homeService är inte närvarande på alla agentsystem, och agent miljö inte behövs i front-end och på hem noden. Felsökning kan anges som en del av agentsystemets konfiguration vid klassens granularitet. Tidsgränser för meddelanden kan konfigureras på komponentbasis. För Net-komponenten anger vi dess portnummer; för varje agent anger vi antalet servicetrådar för varje agent; Killer-komponentens egendom inkluderar tid när den kommer att ta ner systemet; för varje användare anger vi lösenord, inloggnings-ID och inloggningstid; för varje system anger vi värdpolicyn för förhandlingar med agenter. Komponenter kan också organiseras med hjälp av delkomponenter. Till exempel AC är ett aggregat som innehåller AcChannelMgr och AcMsgUser. Endast AC är konfigurerad i hela systemet. På så sätt förenklas konfigurationen med hjälp av en hierarkisk struktur. MOA-komponenterna i ett fjärrsystem och deras egenskaper presenteras i figur 5. MOA-kommunikationen är byggd ovanpå JVM-uttag. Det ger en högre grad av abstraktion, såsom kanaler och meddelanden mellan MOA objekt (agenter, platser och servrar). Kommunikationskanalerna stöder objektströmmar. Meddelanden ger möjlighet att skicka objekt av godtycklig typ som är specifika för programmet. Net-paketet stöder öppnande av kanaler med automatiserade försök. Destinationssystemet kan valfritt avvisa en begäran om kanalen med förbehåll för resursbegränsningar. Detta kan ske på agentsystemet, liksom på applikationsnivå. När en kanal öppnas för en agent behöver bara agentnamnet anges. Agentsystemet löser den faktiska agenten plats med hjälp av Locator objekt på ett distribuerat sätt. Brevpaketet kan passera programspecifika objekt genom att fördröja deserialisering tills destinationens namnrymd identifieras. Meddelanden kan vara synkrona (RPC-liknande) eller asynkrona (envägsmeddelanden). Messaging är byggt på toppen av Net-paketet, med hjälp av en gemensam pool av kanaler som är dedikerade till meddelande passerar. Meddelandets destination kan antingen vara en specifik plats (destinationsnamn, värddator och port) eller ett logiskt namn (t.ex. Agentnamn) om destinationen är ett flyttbart föremål. Detta återspeglas i genomförandet, där ett skiktat tillvägagångssätt tillämpas genom att bygga Locator ovanpå meddelandeskiktet som bygger på nätet (se figur 6 ). Locator hanterar transparent routing av meddelanden när en plats inte anges. Det gör det möjligt för agenterna att på ett öppet sätt kommunicera och samarbeta med varandra genom att använda agentens namn. Locator är beroende av de lokaliseringsstrategier som beskrivs i avsnitt 4.4 för att hitta en ny agentplats. När det gäller tvåvägsmeddelanden skickas svaren tillbaka till den ursprungliga tråden, som suspenderas i väntan på antingen ett svar eller en time out. Ett svar kan anlända från noden annat än den ursprungliga destinationen, om destinationsagenten flyttade. När agenten flyttar från en nod till en annan, märker han inte att dess kanaler har stängts och öppnats på fjärrnoden. När överföringen initieras utförs kanalens migreringsprocess först. Under denna process informerar agenten sina samarbetspartner om sin avsikt. Från och med denna punkt överförs inte de data som tas emot på kanalerna till programmet, utan lagras i en Vector of unread Objects. När du lär dig om flytten, agent kanal manager i andra änden av kanalen svarar tillbaka ett erkännande och stänger kanaluttaget utan att informera programmet. För den migrerande agenten, när bekräftelsen tas emot på en kanal, stoppas läsartråden för kanalen och uttaget stängs. Agenten transporterar sig själv till en ny plats, först när migrationsprocessen är klar för alla öppna kanaler. Under kanalmigreringen, även om uttaget är stängt, upprätthålls fortfarande informationen om de andra kommunikationsagenterna/platserna. När agenten flyttar, bär den ut informationen om kanalerna och använder den för att öppna kanalerna på den nya platsen. Innan kanaler öppnas igen skickar den först alla olästa objekt till Debug (Förteckning över komponenter som felsöks) AE (agentprogramkomponenter)
Till exempel stöder Mobile Objects and Agents (MOA) REF fyra system för lokalisering av agenter; dessa används vid behov för att leverera platsoberoende meddelanden.
Mobile Objects and Agents (MOA)
{'venue': 'IN PROC. OF THE FOURTH USENIX CONFERENCE ON OBJECT-ORIENTED TECHNOLOGIES AND SYSTEMS (COOTS ’98', 'journal': None, 'mag_field_of_study': ['Computer Science']}