Developing a Distributed Dynamic Intelligent Agent Framework Based on the Jini Architecture

1. Developing a Distributed Dynamic Intelligent Agent Framework Based on the Jini Architecture Harry Chen Department of CSEE U. Of Maryland Baltimore County

2. Introduction • Developing a framework for dynamic distributed systems.. • Ronin Agent Framework • Introduces a hybrid approach based on the agent-oriented and service-oriented programming designs • deploys a dynamic distributed system with “intelligence”. • Ronin provides solutions for the problems raised by the existing agent frameworks.

3. Overview • Observations • The future computing trends. • Motivations for developing Ronin • The Jini architecture • Agent technology • The Ronin Agent Framework • Agents2Go & Ronin

4. The Future Trends • Computers & devices are connected in networks. • Wireless connection is gaining its popularity. • Distributed computing is the trend of the future. • PDAs and cellular phones are now capable of doing computation. • People are spending more time with computers. • Shopping, work, entertainment etc.

5. Observations • Networks are by nature dynamic. • “Things” come and go. • “Things” need to find each other. • “Things” are not homogeneous. • A laptop computer wants to talk to a web server as well as a cellular phone. • “Things” need to be smart! - People can’t spend all of their learning and telling these “things” what to do everyday!!

6. Observations • We need tools to develop flexible and robust distributed system with “intelligence”. • The Jini architecture seems to be a good framework for developing dynamic distributed systems. • Why is Jini good? • Is Jini the answer?

7. The Jini Architecture • A simple Java-based infrastructure for providing services in a network. • Each Jini system is built around Lookup Services (LS). • Service client finds services through the LS. • Each service implements a set of well-known service interfaces. • Service client knows how use a service because of the client knows how to use the interface!

8. A Typical Jini Service • The Printing Service • Bob needs to print 1000 copies of color brochures from his laptop. • Bob connects his computer to the network, specifies a set of lookup attributes for finding a printer. • The LS returns a matched print service. • The client application invokes one of the print service method, and the job is done!

9. A Closer Look at the Jini Architecture • There is a catch with the Printing Service scenario. • Finding a good service match Bob has to know about all of the lookup attributes. • A service might have hundreds of attributes. Bob might not understand all of the attributes. • Bob might not know his file must be printed on a PostScript printer.

10. A Closer Look at the Jini Architecture • How can we help Bob? • Give Bob a “smart” agent that can help Bob to make decision. • The agent finds an appropriate printer for Bob based on the properties of the print file and the user profile of the Bob. • No need for Bob to learn about the service detail • Reduce the chance of making human errors.

11. What Can We Say About Jini • Jini is good. • Jini provides flexible and robust infrastructure for deploying and finding services. • The service-oriented design provides an uniformed infrastructure for distributed entities to interact. • Developing a Jini service is easy.

12. What Else Can We Say About Jini • Jini alone is not the answer for everything. • Developing a “smart” Jini service is hard. • Why is it hard? • To be adaptive, it needs to learn from the environment and the past; it needs to cooperate with other services. • To be autonomous, it needs to know how to make plans and schedules; possibly it needs to know how to represent knowledge and reason. • And more …

13. Searching for Answers • Software agent model contains the properties that we are looking for: • Agents are autonomous. • Agents can learn from the past. • Agents can cooperate with other agents. • Agents can adapt and react to their environment. • If we can model a Jini service to have the same properties as a software agent, then we are done!

14. Software Agents • The key idea is that agents can act exactingly in order to accomplish tasks on the behalf of their users. • Software agents offer a new paradigm for very large scale distributed heterogeneous applications. • The paradigm focuses on the interactions of autonomous, cooperating processes which can adapt to humans and other agents.

15. Software Agents DO Communicate • Software agents communicate with each other using Agent Communication Language, ACL. • ACL is important for agent paradigm, just as the development of human language was the key to the development of human intelligence and societies.

16. ? e.g., ? Shared beliefs, plans, goals, and intentions Intentional Sharing e.g., KQML, FIPA, KIF, Aglets Shared facts, rules, constraints, procedures and knowledge Knowledge Sharing Object Sharing Shared objects, procedure calls and data structures e.g., CORBA, RPC, RMI Agent Communication Languages • Knowledge sharing approach • KQML, KIF, Ontologies • FIPA

17. Building Software Agents • Building smart agents we need sophisticated tools, for example. • Agent Communication Languages (ACL). • Rule-based programming. • Domain knowledge representation and reasoning. • Constraint problem solving. • Planners. • And more depends on the domain problem.

18. Problems Raised by the Existing Agent Frameworks • Lacking of sophisticated tools in Java. • Restricted ACL for agent communications. • Restricted network protocol. • Difficult to integrate heterogeneous agents systems. • Message representation are different. • Communication scheme are different.

19. Our Tasks • Task 1: Making sophisticated tools to be available for developing agents. • Task 2: Merge the agent architecture with the Jini architecture, taking advantage of the best parts of each.

20. Task 1: Making Tools Available • We can implement all of these sophisticated tools in Java. • Takes long time and it is not so trivial. • We can reuse the existing tools and create Java interface for agents to use. • Easy! Create Jini services for these sophisticated tools.

21. Making Prolog Available • Prolog engine is an excellent tool for building inference engine and knowledge base. • We have created a Jini service called Distributed Prolog KB (DPKB), to provide simple knowledge base operations for Jini enabled agents.

22. Prolog Engine • SICStus Prolog • Jasper Java package • PrologEngine • Wrapper class for SICStus prolog engine • SimplePrologKB • KB operations to PrologEngine

23. Jini Prolog KB Service - DPKB • Features. • Heavy-weighted Prolog Engine runs on the server side. Clients do not have to install native Prolog code. • Clients can have multiple KB through 1 DPKB service. • Each KB is identified by KB ID and KB password.

24. Client only sees this Runs on the server

25. Task 2: Merging agent with Jini • The Ronin Agent Framework is designed to aid in the development of dynamic distributed system with “intelligence”. • The Ronin Framework introduces a hybrid approach that is based on the composition of the agent-oriented and service-oriented programming design.

26. Ronin Design Goal • Promote generic agent attributes. • Making knowledge sharing possible. • Making basic communication negotiation possible. • Independent ACL and network protocol. • Making the integration between heterogeneous agents possible. • Simplicity.

27. Ronin Design • The Ronin Agent Framework defines an open framework that specifies the infrastructure requirements and interface guide line for the agent interaction and communication. • The standard interface and classes that are central (“core”) to the Ronin Agent Framework is called Core Ronin Agent Framework.

28. Core Ronin Components • Envelope • A meta container for ACL messages. • Effect. • Provides an uniformed structure for delivering messages. • No network protocol restriction is imposed.

29. Core Ronin Components • Common Agent Attributes. • Describes agent features to distinguish one agent from another in ways that are domain independent. • The attribute types and semantic meanings are defined by Ronin in the domain independent fashion. • Effect • Allows agents to find each other in a domain independent way, using the generic agent attributes.

30. Ronin Components • Domain Agent Attributes. • Describes agent features to distinguish one agent from another in ways that are domain dependent. • The framework does not define the types and semantic meanings of the Domain Agent Attributes. • Effect • Allows agents to find each other using the domain knowledge as an alternative to the common agent attributes.

31. Core Ronin Components • Ronin Agent. • A specialized version of a Jini service with the agent-oriented abstraction. • Provides services through agent communication. • Can be realized by either hardware or software. • Required to have at one Agent Deputy if it is intended to be contacted by other agents. • Required to have a set of Agent Attributes and Agent Domain Attributes.

32. Core Ronin Components • Ronin Agent Deputy. • A specialized version of a Jini service proxy object. • Responsible for handling the communication and the interaction between its owner Ronin agent and other agents in the system.

33. Core Ronin Components (Agent Deputy Cont.) • Effect • Provides a local agent representation. • The mobile front-end of the agent. • Hides the actual agent implementation from other agents. • Making flexible and robust agent communication possible. • Using store-and-forward mechanism. • Mailbox mechanism and more …

34. Proxy Object An object diagram of a proxy structure at runtime. Print Server Client Proxy

35. Core Ronin Components • Ronin Agent & Agent Deputy • Ronin agent owns one or many Agent Deputies. • Agent Deputy will register with Lookup Service along with Agent’s attributes. • Agents communicate with other agents through their Agent Deputies. • Agent Deputy is responsible for choose the right communication scheme to delivery messages back to the owner agent.

36. Core Ronin & Ronin Implementations • Core Ronin only defines interfaces and classes that are needed to get things to run. • The idea is similar to net.jini.core • Ronin Implementation ~= com.sun.jini • Core Ronin has 3 packages • edu.umbc.ronin.attributes • edu.umbc.ronin.deputy • edu.umbc.ronin.language

37. Core Ronin

38. Agent Group Ronin Implementation • Feature. • Ronin Agent/Jini Service Shell (template). • Jini join & lookup specific information can specified in a Java Properties. • Dynamically initialize Agent Attributes and Domain Attributes based on Properties file. • Provides sufficient library for implementing agent-oriented Jini services. • Guarantees that deploying Ronin agents is not harder than deploying traditional Jini services.

39. Agent Group Ronin Implementation • 5 Packages • edu.umbc.agent.ronin.agent • Ronin Agent Shell and Message Dispatching utilities. • edu.umbc.agent.ronin.deputy AND edu.umbc.agent.ronin.deputy.transport • Out-of-box Agent Deputy implementation. • edu.umbc.agent.ronin.lookup • Customzied Lookup Tools for finding Ronin Agents. • edu.umbc.agent.ronin.util • Ronin Agent Shell Admin tools and misc. tools.

40. Receive Remote Envelope Out-of-box Agent Deputy

41. A Smart Jini System • We have developed a distributed system based on the Ronin framework and DPKB to demonstrate their feasibility. • The system is called Agents2Go.

42. Agents2Go • Components in the system: • An user with a PDA. • A Broker Agent. • Capable of making recommendations to users on local restaurants information. • A DPKB service. • A number of restaurant agents. • Provides dynamic information about the restaurant, e.G. Wait time etc.

43. Agents2Go • PDA finds the Broker Agent through Jini lookup service. • PDA submits recommendation request to the Broker with constraint and personal profile attached. • Broker preprocesses the request, constraints, and profile info, and then converts them into a number of queries in Prolog. It depends on the DPKB service for knowledge representation and reasoning.

44. Agents2Go • If the Broker KB does not have sufficient knowledge to make a recommendation, then the Broker will try to discover and lookup local restaurant agents through the Jini lookup service. • Broker negotiates with these agents using descriptive agent communication language, KQML. Message content is expressed in Prolog.

45. Agents2Go • After the Broker has received enough information, it restarts the recommendation inference process. • Broker replies the original request with the recommendation. The reply is expressed in the format that can be understood by the PDA.

46. Screenshots • Netform is a Palm application. • Netform allows a user to find his/her favorite restaurants.

47. Screenshots • User can specify various matching attributes. • We are looking for • Japanese cuisine • Has dinning in • Has reservation • Price range between $10 and $20.

48. Screenshots • Making connection to the network. • Connecting the proxy on the network. • The proxy is responsible for contacting agents in the system.

49. Screenshots • A matched result is send back from the proxy.

50. Future Works • Make the specifications and the source code of Ronin framework to be available to the community. • Use BeamML for constructing Agent Deputy dynamically. • Add support for Java Servlet.