Home

Search

COMMON INTRODUCTION

  • Overview
  • Application Areas
  • Related Work

    GYPSY

  • What's new?
  • Project Goals
  • Scenario
  • Mailing Lists
  • Team Members

    DOCUMENTATION

    DEVELOPMENT

    DISTRIBUTION

    Contact us


  • DSG Logo

    Gypsy Scenario



    This 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;

    Example figure
    To construct an agent in this case, the person chooses a FlightSearchTask from a task list and fills out the corresponding forms e.g. travel date, deadline (need the information the next day), reporting period (send status message every 5 hops), amount of money (micropayment) the user is authorizing the agent to spend, and query properties. These properties enable the agent to ask a place registry for URIs of useful places to visit. A list of properties would be, in this case, London, Heathrow, Gatewick. The agent also has, by default, a list of predefined properties such as flight, airline, travel agency which may also be edited by the user. Then the user adds a starting place, e.g. his favorite travel agency, to the route of the agent and launches it. If no starting URI is given, the agent will be launched to the home server to query the local place registry.

    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.

    Example figure
    The previous Figure shows the main concepts of Gypsy as described in this page. Servers are grouped into domains. A domain is a administrative unit which is administered using a remote administration tool. A log server in each domain records log messages received from servers in the domain.

    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 .