1.1 – Modellering framework Basisfunctionaliteit Tele Atlas • Rondrijders verzenden afgewerkte update reports (UR) naar de server • Voor het binnenrijden van een nieuw gebied, ontvangen de werknemers een UR van het gebied • Rondrijders krijgen concrete opdrachten toegestuurd • Communicatie van en naar de server moet worden gecontroleerd
54
Embed
1.1 – Modellering framework Basisfunctionaliteit Tele Atlas Rondrijders verzenden afgewerkte update reports (UR) naar de server Voor het binnenrijden van.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1.1 – Modellering framework
Basisfunctionaliteit Tele Atlas
• Rondrijders verzenden afgewerkte update reports (UR) naar de server
• Voor het binnenrijden van een nieuw gebied, ontvangen de werknemers een UR van het gebied
Server (ev. DB server) Server (ev. synchro server) Mobiel toestelIN
TE
RF
AC
E A
G.
TA
SK A
GE
NT
SIN
FO
RM
AT
ION
AG
EN
TS
RECEIVING SLAVE AGENT
RECEIVING SLAVE AGENT
SENDING SLAVE AGENT
SENDING SLAVE AGENT
Houdt lijst met gegevens en prioriteit bij van aangevraagde transacties. Abstracte klasse waarvan enkel prioriteitsformule dient geïmplementeerd te worden. Indien de prioriteit een drempel overschrijdt, wordt de transactie uitgevoerd.
Policy agents volledig zelf te implementeren. Policies worden hier vertaald naar aanvragen bij synchro server. Voorbeelden: specifieke gegevens up-to-date houden, toestellen regelmatig verplichten te zenden, interface om commando’s van de buitenwereld uit te voeren, ….
Abstracte klasse moet worden overgeërfd
Abstracte klasse moet worden overgeërfd
(optioneel) Doel: synchro agent van de toestelbelasting op de hoogte houden.
(optioneel) Doel: synchro agent van de serverbelasting op de hoogte houden.
RSA’s en SSA’s worden pas gecreëerd wanneer een transactie plaatsvindt. (1 per transactie)
DCA en UCA zijn continu op toestel aanwezig. Kunnen elk slechts 1 transactie tegelijk aan.
De prioriteiten worden continu berekend op basis van factoren naar keuze: wachttijd, prioriteit opgegeven door aanvrager, toestelbelasting, serverbelasting, # actieve transacties, toestelID, richting, …
• AMobe implementeert ook de case-specifieke gedeelten voor Tele Atlas en IDEWE
• Voorlopig wordt de te zenden data als 1 geheel beschouwd indien het toestel wil zenden.
• Huidige principe van data opvragen:
– Request via String, return via File
• Later eventueel:
– Request via Object, return via Object
1.1 – Modellering framework
Bemerkingen bij het framework
• Probleem: minimale trafiek over de GPRS link gewenst (zie verder)
• Bepaalde beslissingen in het software-ontwerp kunnen later genomen worden voor agent-georiënteerde toepassingen dan voor klassieke object-georiënteerde toepassingen
1.2 - Modellering T&I
Functionaliteiten T&I
• Op de PC van de begeleider en op de mobiele toestellen (persoon met NAH en begeleider) worden dagschema’s en opvraagbare items gecreëerd en aangepast
• De persoon met NAH interageert met ontvangen memo’s; de begeleider krijgt informatie over deze interactie
• Analyserapporten
1.2 - Modellering T&I
De modellering toont veel gelijkenissen met het framework voor Tele Atlas/IDEWE:
• meerdere mobiele toestellen aanwezig
• uitwisseling dagschema’s en opvraagbare items zijn terug te brengen tot één van de vier scenario’s (toestel wil zenden/ontvangen, server wil zenden/ontvangen)
Server (ev. DB server) Server (ev. synchro server) Mobiel toestelIN
TE
RF
AC
E A
G.
TA
SK A
GE
NT
SIN
FO
RM
AT
ION
AG
EN
TS
RECEIVING SLAVE AGENT
RECEIVING SLAVE AGENT
SENDING SLAVE AGENT
SENDING SLAVE AGENT
Mobiele persoon NAHMobiele begeleider
Begeleider op PC
Interface om dagschema en opvraagbare items te bewerken Interface om dagschema en
opvraagbare items te bewerken
1.2 - Modellering T&I
Creatie memo-agent
• Een memo-agent kan door de Client DB agent gecreëerd worden om met de persoon met NAH te interageren.
• De memo-agent kan de reactie van de persoon met NAH op een memo registreren via de Client DB agent en die kan op zijn beurt de reactie doorsturen naar de server. Via een gelijkaardig mechanisme kan de reactie worden doorgestuurd naar het toestel van de begeleider. (creatie memo-agent)
Op beide platformen is er een DF en AMS aanwezig. MTP naar keuze of zelf te
implementeren.
2.3 - Aanspreken poort binnen KaHoSL LAN
• Agentserver in KaHoSL LAN en agentclient in Mobistar netwerk
• Probleem: firewall laat slechts communicatie van buitenaf toe via een beperkt aantal standaardpoorten (8080, 22, …)
• Oplossing 1: via een SSH tunnel, maken we van buitenaf connectie met een host, die zowel een lokaal als een extern IP-adres (IP-forw.) heeft
• Oplossing 2: we plaatsen een agentserver in de DMZ-zone
Internet
KaHoNet
AllServMondriaan
Fire-wall
MobistarNet
Scampi
10.0.0.20193.190.130.2
10.1.3.219
Opstelling 1
SSH
Internet
Fire-wall
Port forwarding:
L 1090 mondriaan:1099
Als we lokaal op Scampi poort 1090 aanspreken, is het alsof we poort 1099 aanspreken op Mondriaan
Opstelling 1 - Tunneling
MobistarNet
ScampiPuTTY
22
KaHoNet
AllServMondriaan
Fire-wall
Opstelling 1 – KaHoSL LAN
22
InternetFire
-wall
KaHoNet
Mondriaan
Scampi
DMZ
router
deus
Opstelling 2
MobistarNet
Internet
MobistarNet
Fire-
wall
KaHoNet
Mondriaan
Scampi
deus
remote monitoring
niet secure
Merk op: enkel op voorhand gekende poorten zijn aanspreekbaar
Opstelling 2
router
2.3 - Aanspreken poort binnen KaHoSL LAN
Vergelijking:
• SSH tunnelling geeft extra overhead, maar de communicatie is beveiligd. Flexibelere server-toewijzing. Agentenserver heeft enkel lokaal IP-adres.
• De “DMZ-oplossing” geeft minder overhead, maar de communicatie is niet beveiligd (maar kan ingebouwd worden). Remote monitoring. Agentenserver heeft extern IP-adres.
Random poorten probleem:
• Bij de “Remote Container” en vaak bij de “Remote Platform” opstelling worden er aan de server-zijde (random) poorten open gezet voor communicatie
• Bij “Split Container” gebeurt alle communicatie via één poort op de server
2.3 - Aanspreken poort binnen KaHoSL LAN
Remote Container
1099
26142615
2.3 - Aanspreken poort binnen KaHoSL LAN
7778
22602661
Remote Platform over HTTP
2.3 - Aanspreken poort binnen KaHoSL LAN
2.3 - Aanspreken poort binnen KaHoSL LAN
Besluit random poorten probleem:
• Beide opstellingen (tunneling, DMZ) vereisen dat op voorhand geweten is welke poorten gebruikt worden aan de serverzijde.
• De “remote container” mode maakt per definitie meerdere willekeurige poorten aan op de server. Deze mode is dus onbruikbaar.
• Voor de reeds bestaande MTP’s in de “remote platform” mode geldt hetzelfde. Een eigen implementatie zou kunnen helpen.
2.4 – Minimale trafiek
• GPRS wordt betaald per data-eenheid. Wat is de gemiddelde trafiek wanneer 2 agents communiceren of wanneer een remote agent bereikbaar wordt voor de server?
• Zijn er verschillen tussen “split container”, “remote container” en “remote platform”?
• Hoe kunnen we zelf overhead reduceren?
• Praktische metingen: gemeten over LAN, monitoring m.b.v. Ethereal en WinPcap, om algemeen beeld te krijgen
2.4 – Minimale trafiek
Aanloggen Starten agent Zenden
358 TCP324 RMI
554 TCP 174 RMI
585 TCP174 RMI
Split Container(cijfers steeds up+down, message steeds INFORM hallo)
2.4 – Minimale trafiek
Aanloggen
Starten agent
Zenden
1937 TCP2400 RMI
346 TCP410 RMI
1ste keer: 2471 TCPrm => s 1648 RMI
s => rm 680 TCP 406 RMI
rm => s 960 TCP 412 RMI
Remote Container
2.4 – Minimale trafiek
Aanloggen
Starten agent
Zenden
HTTP 1800 TCP6683 HTTP
0 526 TCP1881 HTTP
Remote Platform
2.4 – Minimale trafiek
• Split container is de beste keuze (ook wat betreft poorten) (of remote platform met een eigen MTP??)
• Vanwaar is de overhead net afkomstig? Kunnen we nog verder reduceren?
• Gelaagd model voor agentencommunicatie in Supporting Nomadic Agent-based Applications in the FIPA Agent Architecture (Heikki Helin)
2.4 – Minimale trafiek
syntax (ACLcodec) + semantiek
commun. Act + ontologies
2.4 – Minimale trafiek
• Heikki Helin: reduceer de overhead in elke laag
• Helin’s uitgangspunten: minimale trafiek, interoperability, encoderen in de lagen kan ACL performance tegenwerken
• Opmerking: dit model vertegenwoordigt enkel de agent-to-agent communicatie en houdt geen rekening met trafiek veroorzaakt door de architectuur van het platform!
2.4 – Minimale trafiekAC - Split
container
Not imple
m.RMI
TCP
FIPA-ACL
vrij
vrij
2.4 – Minimale trafiek
• Split container: 1. architecturale ingreep opdat er geen nodeloze container-platform communicatie plaatsvindt 2. onderste lagen niet vrij te kiezen DUS moeilijk verder te reduceren