DIAMOnDS: Distributed Agents for Mobile & Dynamic Services

1. Distributed Agents for Mobile & Dynamic Services DIAMOnDS

2. DIAMOnDS Team • Developers • NC Maria Riaz • PC Aamir Shafi • NC Umer Farooq • PC Anjum Shehzad • PC Saad Liaquat Kiani • Supervisors • Dr. Arshad Ali (NUST) • Dr Iosif C. Legrand (CalTech)

3. Sequence of Presentation • Part 1 • Introduction • Part 2 • Design & Architecture • Work Distribution • Part 3 • Modules Description • Important Features • Conclusion

4. Part 1: Introduction • Conventional communication mechanisms • Service Oriented Architecture • Why Jini • Why mobile agents • Why a new mobile agents platform • Hybrid Paradigm • SOA having support for mobile agents

5. Introduction • Problem:Deutsch's seven fallacies of distributed systems • The network is reliable • Latency is zero • Bandwidth is infinite • The network is secure • Topology doesn’t change • There is one administrator • The transport cost is zero These are the challenges that applications for distributed systems have to face and overcome to provide the best solution • Solution:Provide a secure distributed services infrastructure having features like • Management of distributed services • Flexible communications infrastructure • Reusability

6. Conventional Communication Mechanisms in Distributed Systems • Client Server • Peer to Peer • Hybrid (Client Server & P2P) • Mobile Code

7. Service Oriented Architecture • Service Provider • Responsible for publishing a description of the service to the service registry. • The service provider hosts the web service. • Service Registry • Is a repository that provides the capability of discovering services by the service requestors. • Service Requestor • Is responsible for discovering and invoking the service. • Binds to the service obtained from the service registry • Benefits of SOA • Loosely Coupled Services • Protocol Independence • Location Transparency • Time Independence

8. Why JINI?

9. Why Mobile Agents ? • Reduce network load and overcome latency • Execute asynchronously and autonomously. • Naturally heterogeneous, adapt dynamically • Are fault-tolerant and allow disconnected operations

10. Why a new Mobile Agent Framework? • Web-Based Toolkit • Only toolkit that allows agents to be started from the web • Open Source • Many toolkit are going closed source (IBM Aglets) • Truly Mobile Agents • A requirement to achieve robustness in WAN applications. (FIPA-OS moves agent by cloning) • Remote Monitoring • Only toolkit in which agents have remote GUI’s that can be downloaded on the client side • Integration of SOA • The notion of Agents acting as mobile services for end user

11. Hybrid Paradigm • DIAMOnDS is based on • Service Oriented Architecture having support for Mobile Agents • SOA having support for mobile code provides a highly flexible solution to Deutsch 7 fallacies • AIM :- To Develop an API for WAN applications developer based on hybrid paradigm

12. Part 2: Design & Architecture • Work Packages • Architecture • Work Distribution

13. Time div. according to Work Packages

14. Architecture Lookup Service Lookup Service Registration Service Client Agent Starter UI Agent Station Agent Station

15. Work Distribution • Aamir - Agent Starter • Maria - Agent Station, Database Agent • Anjum - Basic Agent, File Access Agent • Umer - Search Agent, Security • Saad - Test Agent, Client

16. Part 3 Modules Description

17. Modules • Agent Starter • Agent Station • Agents • Basic Service Agent • File Access Agent • Database Access Agent • Search / Information Retrieval Agent • Connectivity Test Agent • Client • Basic Client • File Access Client • Search Client

18. Agent Starter • The Agent Starter performs pre-functional initialization • Main Functions • Providing an interface for anyone interested to load their agents • Instantiation of Agents (Loading an agent from a jar file into the JVM) • Jini Client • To discover agent stations; and for this it needs Discovery Module • Hosting an HTTP server for providing code base for each type of agent

19. Instantiation of Agents • Loading of Agent into system requires • Path of jar file • The manifest of the jar file contains an attribute Main-Class which contains the main() method of the Agent • Jar files can be loaded from • Local File System • Remote HTTP/FTP server • Allows jar reuse • Redundancy

20. 1. Mobile Code executing at A Hosting HTTP server • Movement of Agent from an AgentStation/Starter to another Station • Requires an HTTP server to point to code base • Multiple code bases are also provided • What is codebase ? HTTP Server ??? B A

21. An interface for Agent Loading

22. Agent Station • Acts as a JINI Service • Establishes a peer relationship with all stations • Provides registration, notification and discovery mechanism for agents • Execution Environment for the agents • Agent Starter sub module • Security sub module • Trust Establishment with other services • Validating incoming agents

23. Execution Environment for the agents • Every agent needs an execution environment • It needs a controlling entity to start it • Execution engine sub module • Manages a thread pool • Allocates a separate thread for execution of each agent hosted on the station • Kills threads after an agent moves or is stopped by a user

24. Acts as a JINI Service • Registers with the Lookup Service with • Following attributes • Name – AgentStation@lxcms48.cern.ch • IP Address – 137.138.42.202 • Location – PK (Isb.) or CH (Geneva) • Proxy • The proxy needed by clients or other services to invoke methods on the station • Unique ServiceID • db466c4c-c336-4b21-b367-c3eb0c5cf2b3

25. Lookup DiscReg Agent Station Agent Station DiscReg Remote Notifications Registration DiscReg Agent Station Station-Station Agent Movement P2P relationship with all other stations

26. Services provided to the agents • Provides following services to the agents • Registration • Notification • Discovery • Execution environment • Access to Transaction Service • Access to Java Space Service

27. Sub Modules in Station • Agent Starter sub module • For loading agents • HTTP server • FTP server • Local File System • Security sub module • Validating incoming agents • Verifying the user who starts the station

29. Security Features • User Controlled Certificate Exchange • Verification of agents using certificates • Validation of agents code using digital signature • Open and Restricted Agent Services

30. Terminology • Entity • An entity is a person, organization, program, computer, business, bank, or something else you are trusting to some degree. • Public Keys • Are numbers associated with a particular entity • Use: Are intended to be known to everyone who needs to have trusted interactions with that entity • Are used to verify signatures. • Signature • A signature is computed over some data using the private key of an entity • The signer in case of a certificate is also known as the issuer.

31. Terminology • Digitally Signed • If some data is digitally signed it has been stored with the ”identity” of an entity, and a signature that proves that entity knows about the data. The data is rendered un-forgeable by signing with the entity’s private key. • Public &Private Keys • These are numbers, each of which is supposed to be known only to the particular entity whose private key it is (that is, it’s supposed to be kept secret). • Private and public keys exist in pairs in all public key cryptography systems (also referred to as ”public key crypto systems”). • In a typical public key crypto system, such as DSA, a private key corresponds to exactly one public key. • Private keys are used to compute signatures.

32. Terminology • Certificate • (also known as a public-key certificate) is a digitally signed statement from one entity (the issuer), saying that • The public key (and some other information) of another entity (the subject) is credible • Correct and • Belongs to the subject entity. • Keystore • A password protected database of keys (public & private) and certificates. • Truststore • A keystore containing certificates of trusted entities.

33. Certificate Exchange • Agent stations have an open interface using which any owner of an agent can send his certificate to a station. • The receiving station has the authority to accept or reject an arriving certificate. • If accepted, the certificate is stored in the station’s truststore.

34. Verification of Agents using Certificates • All agents are provided in the form of signed jar files. • An agent can’t load/execute on a station until its signer’s certificate is in the agent station’s truststore.

35. Code Validation Using Digital Signature Start • A malevolent entity can replace the code in a file after the original user has signed the agent. • Such an agent is prevented from loading by verification of its signature using its creator’s certificate. The owner signs an agents embedding its certificate in jar Owner moves agent to a station Receiving station checks the agents signature Signature is validated Agent is accepted Agent is denied End

36. Open & Restricted Agent Services • Agents can be specified as open/restricted while compiling. • GUI of an open agent can be downloaded by any requesting client. • GUI of a closed agent is provided only to the owner of that agent. • The mechanism of authenticating the requestor involves a signature based handshake.

37. Security of a Restricted Agent • Downloading GUI of an agent involves a handshake between the agent and the requestor.

38. What are Mobile Agents ? • Normally the agent refers to humans • “one that acts or has the power or authority to act… or represent another.” • In computer world, • a software program that acts on a user’s behalf • Intelligent Agents are characterized along 3 dimensions • Agency: the degree of independence • Intelligence: the degree of learning • Mobility: degree of movement • Types of mobile agents • Mobile agent toolkits • Multi-agent toolkits • General purpose agent toolkits • Internet agent toolkits

39. Issues related to Mobile Agents • Class Loading • Mechanism for dynamically loading software components into the JVM e.g. applet • Lazy loading: loading on demand • Type-safe linkage: does not violate type safety • User-definable class loading policy: Specifying • Remote location • appropriate security attributes • Multiple namespaces: class loaded through different loaders have distinct name space

40. Weak Mobility – performing same job on every machine

41. Basic Agent • Mobile • Can migrate between Agent Stations by • Name • IP • Random move • Predefined path • Mobility mechanism • Light HTTP server • Marshalling / Unmarshalling • Weak Mobility

42. … Basic Agent • Transaction • ACID properties • Either agent moves successfully to destined station or remains on the same station • Service • Acts as an entity providing functionality to the users • Registers with the Registration authority • By providing Specific attributes • Can be discovered by other services using attributes • Provides remote GUI for administration and/or its specific operations

43. Application Agents • All application agents exhibit properties of • Mobility • Transaction • Service • We have provided a toolkit and by using it other agents can be created. • Reusability • Four specific implementations of our toolkit are • File Access Agent • Database Agent • Search Agent or Information retrieval Agent • Test Agent

44. File System Station ClientGUI Client File Access Agent • Remote File Access Functionality • Exports file system of the host station to the client/user • File transfer over TCP sockets • Remote File edit/view • Secure Access to file system • Based on public/private key pairs

45. Snapshot (Agent’s view on Client)

46. Connectivity Test Agent • A hopping agent that moves between all the stations that are online • It keeps a record of all its moves in the form of a log file with itself • Not on persistent storage • Shows station presence on a world map • Proof of Fault Tolerance Implemented • Scenario • This agent is about to move to a station that has just crashed • Conventional Applications might fail in such a scenario • No notification of the dynamic network • No intelligence • Conn. Test Agent’s behavior in this scenario • The agent will recognize this network change and will select a different station to move to. • Such fault tolerance measures are a must for WAN Applications

48. Client UI Agent Station Agent Station Database Access Agent • Access to remote databases • Agent Station registers databases with itself, making the DBs accessible to hosted agents • Database can be queried/updated remotely through the agent GUI at client • RMI-JDBC • mySQL • Microsoft Access

49. Remote DB being viewed at Client through DB Agent GUI

50. Search Agent / Information Retrieval Agent • Visit different Agent Stations searching for given information • Word/Phrase to look for in files • User can select the locations to search • Steps • Moves to a site • Analyzes the stored documents • Records results (saves state) • Moves to the next site.