|
Home
COMMON INTRODUCTION
GYPSY
|
Gypsy ScenarioThis page presents a scenario that we use as a driving use-case for Gypsy applications. This page will first give a user view of the problem and then the Gypsy system's view. The purpose of this page is to introduce Gypsy's terminology and components at a high level. A user wants to travel to London the next weekend and wants to find the lowest-cost flight available. Rather than doing the search himself, he launches his mobile agent to do the work for him and report the results when they are available. The agent is launched from the user's portable device (telephone, laptop, appliance, etc.) which runs the Gypsy user interface. The agent may be specialized by the user for this particular task or it may take on default values from the user's predefined profile. Once the agent is launched, the user may disconnect his portable device. The user has a permanent user place on a home server where his agents report to, and wait on their return. The user may at any time connect to his home server place and inquire about his various agents. Besides user places, Gypsy servers may house a number of other places specialized for particular services. For example, a flight reservation place provides flight reservation services. A place registry provides information on all available places; ![]() The agent arrives at the starting place and queries the local database for inexpensive flights. Then it queries the local place registry through the place interface for more new interesting places to visit. If the agent has reached its maximum reporting period, it sends a status message with its current results back to the owner by email or by a status messenger to the home server. When the agent has queried enough servers or the deadline has arrived the agent returns to the user place on the home server. This place receives the agent and, based on the notification strategy, it informs the user by email or SMS messages that the agent has returned. The user asks the home server to forward the waiting agents to his user interface. The returned agent is then given an embedded agent, called result writer, which formats, interprets and displays the result to the user based on the user's portable appliance. This scenario exemplifies the simplest use of Gypsy. There are other issues that Gypsy is able to handle. For example, what happens if the user wants to recall his agent before the deadline is passed? He could launch a new agent that follows exactly the same path that his agent has followed in order to catch up and find the agent. It is probably more efficient, however, if this new agent starts at the latest known location of the original agent. Another issue involves more complicated tasks that involve several simpler tasks. For example, what if the user wanted to make hotel and theater reservations in addition to the flight reservation? Gypsy supports supervisor agents that consist of worker agents, each of which is responsible for a particular tasks. The supervisor agent uses a constraint manager which is responsible for ensuring that the results of the tasks are compatible, e.g. that the flight arrival date is the starting date of the hotel reservation and the hotel checkout date is the same as the flight departure date. ![]() |
accesses to this page since January 1, 1999;
© 1997-2000 Distributed Systems Group , Technical University of Vienna .
Created and maintained by Wolfgang Lugmayr ( W.Lugmayr@infosys.tuwien.ac.at ).
Last update:
Tue Jan 4 15:49:19 CET 2000
.