Handling Subscription in a Mobile Agent Based Service Environment for Internet Telephony: Swapping Agents

ABSTRACT

Internet telephony brings a host of opportunities. Cost can be reduced and new services can be engineered. Mobile agent based service architectures for Internet telephony, have emerged in the recent past. They stipulate the use of mobile agents that act as folders and carry the executables of services (or pointers to the executables). Carrying executables (or pointers to executables) in a mobile agent brings new challenges. Subscription handling is among them. This paper tackles the subscription problem. There are two possible approaches for upgrading a mobile agent that carries services, when the user subscribes to new service(s): agent swapping and on-the-fly updating. In the first approach, the agent that carries the services is swapped with a new agent that carries both the old and the new services. In the second approach, the new services are inserted in the agent on the fly. In this paper, we give an overview of our mobile agent based service architecture, state the subscription problem, derive requirements, and propose tentative solutions based on the swapping approach. The requirements include minimization of the duration of service interruption, scalability, and programming simplicity. The problem although related to software replacement, is significantly different. The two solutions proposed in the paper, smooth swapping and abrupt swapping, scale to a large extent, as shown by the prototyping results. There is no service interruption with the smooth swapping. Unfortunately, it requires that the old and the new agents co-exist on the user device or network node for a short while. It might therefore not be applicable to small footprint devices. The abrupt swapping does not require the co-existence of the old and the new agents and is therefore applicable to all types of devices. Service is however interrupted. Fortunately, the duration is insignificant as shown by the prototyping results. The bad news is that service programming is relatively complex in both cases.