This section presents an example of a framework
for mobile code that was implemented by a graduate student at Carleton.
A number of elements are necessary for code mobility. The critical centerpiece of the infrastructure is the mechanism for code migration. The Mobile Code Daemon (MCD) runs as a daemon (thread) inside a Java Virtual Machine on every Network Element (NE). It is our assumption that every NE is Java-enabled; that is, it runs its own JVM or has a proxy that runs a JVM. The MCD listens on well-known ports for TCP or UDP messages that carry compressed Java bytecodes of the migrating software agent. Java bytecode is an intermediate code that can be interpreted by a JVM on the underlying platform. It is the basis of the mobility of Java programs. The Migration Facility (MF) is the part of the MCD responsible for actual shipment of the code. Each networked device has a number of potential targets and the MF implements a default selection of the target. Alternatively, the agent that is being migrated can provide a selection algorithm.
There are other parts of the infrastructure that are not directly involved in transferring code. For example, the Virtual Networked Element (VNE) provides an interface to Element Resources (DR) on a networked device. The Communication Facility (CF) allows for direct (thread to thread) or indirect (for example through a blackboard) communication between agents. The Security Facility (SF) ensures the security and integrity of the migrating code, the device and the network.
In general, mobile code technology can be divided
into the pop technology, push technology and autonomous
migration. A similar taxonomy (code-on-demand, remote evaluation
and autonomous mobile agents) has been proposed. The pop technology
refers to cases where a missing part of an application is downloaded from
a remote location, so it can be executed locally as a part of this application.
The push technology implies uploading software to a remote location and
executing it remotely, but under the control of a local agent. Autonomous
migration involves software agents that move autonomously between various
locations and execute locally on each of them.
A different classification is far better suited
for applications of mobile code. We started our project with a term agent
referring to all instances of mobile code only to find out very soon that
such a terminology was very confusing. Even more so, if we take into accounts
that the same term is heavily used in the network management context. It
became apparent that to communicate clearly and efficiently a more accurate,
application-based taxonomy of mobile code was necessary. We decided to
follow the naming conventions started with applet as mobile code
that implements an application that is downloaded for a local execution.
Originally, the execution was to happen inside a Web browser. In general,
it is not a necessity, because a Java Virtual Machine capable of running
applets can be embedded in any application and deployed on any device.
By a servlet we describe an agent that is uploaded to a remote location
where it is activated as a server (or a part thereof) for subsequent requests.
An extlet is a similar entity, which is uploaded to a remote location
to extend the capabilities of the recipient, but not necessarily as a server.
An agent may cede the authority over a certain task to a deglet. A deglet
stays alive for as long as required to perform the task. It may move to
multiple locations if necessary. A netlet is similar, except that
the task that it carries out is permanent; i.e., by design a netlet does
not terminate. Netlets can be considered an integral part of the underlying
network. They may perform management functions as well as play the role
of middle-ware by providing various services to overlying applications.
Piglet is defined as maliciously altered mobile code that constitutes a security risk to the network.
In the following sections, we will illustrate the taxonomy of mobile code through describing several uses of each of these types. We start with an applet.
Most of the users of computers have encountered
Java applets while browsing the Internet. Applets started as small Java
programs that could be executed within the Web browser. They were considered
enhancements to Web pages that make the content more attractive and accessible
to the visitors. With time, the capabilities of applets and the execution
environment within browsers were extended to meet increasingly sophisticated
needs. An idea of a network computer was born. A network computer is a
device that obtains its applications from remote location and executes
them locally. They do not need to be installed on the computer; instead,
they are located somewhere in the network. A Web browser evolves into the
operating system of a network computer.
We show an advanced version of a similar system that composes its applications online depending on the needs and profile of the user. In this case, not simple applets, but parts of bigger applications are downloaded to the users workstation. There might be a number of servers where the software components are stored. The user activates an application or just a certain function of an application that is already running. The required component is found on one of the servers and brought to the network computer for execution. Owing to Java features, any component might be exchanged for another one; for example, if the user’s abilities change with experience. The components that are not needed can be removed from the system by the garbage collector. In that way, the system is dynamically configured for the specific user and for specific function.
Resolving technical issues is all what it takes to setup and run such a dynamic system on a corporate intranet or extranet. Extending the same model to the Internet is a challenge, because other issues such as security and billing must be resolved. Nevertheless, the direction is clear: in the future, applications will be composed out of components available on the Internet. The user will be billed on-fly by an accounting system.
The next example comes from Network Management. A network device, a PC, includes a special downloadable data presentation applet. The applet is a part of the vendor designed and implemented interface (we call them Virtual Managed Component or VMC) to the device that may reside on the network device or on a proxy as described earlier. The VMC is delivered to the user as an integral part of the device. When the device is connected to the network, the knowledge about the available facilities is shared with the interested parties residing in the network. For example, a device browser may discover the device and request a list of supported services. Alternatively, a provisioning agent may be another part of the VMC. We will see examples of these later. A user browsing a list of devices may need to examine a particular device. If the device is registered as one that provides its own facility to examine its state, then the applet is fetched from the selected item and executed locally on the manager's workstation. It may execute inside a Web browser or as a standalone application. The applet implements the data presentation function in the way that the vendor of the device considers as the most suitable for this particular device. For example, it may be a simple textual list or a sophisticated graphical representation of the hardware and/or services. If a device does not provide presentation applet, then the device browser may implement a default data presentation facility. That is a solution widely used in today's network management systems. It requires that each device implement the communication protocol of the manager. The solution with downloadable applets does not have such constraints.
An additional flavor to the approach is added by maintaining a repository of applets on a server; e.g., on the vendor's Web page. The VMC shipped with a network device would include only a reference pointer to the remote applet, which would be brought from the server when needed. An obvious advantage is that the vendor can maintain its repository up to date and structure it conveniently; for example, with the use of various software components.
One of the features that make the JVM so sophisticated
in comparison to a protocol handler is a capability to extend its functionality
by loading new Java classes at runtime. With this capability, it is possible
that two entities can communicate without the need of having á
priori arrangements for a communication protocol. The initiator of
the communication may provide the targeted party with a complete protocol
handler. In our jargon, the installation of the handler is achieved by
the means of a servlet by sending it to the target's JVM, which installs
and activates the necessary classes. After that, the parties can communicate
using the language implemented by the servlet, although initially only
the originator of the conversation knew it. There is an example of such
a scenario involving a soft protocol shown in the illustration.
Host1
attempts to initiate a communication session with host2 using the
myTelnet protocol. The protocol handler is sent as a servlet to
host2. From now on, the servlet is ready to respond to the messages
coming from host1 in the way defined by myTelnet.
The use of the adjective soft is justified by the fact that a servlet does not necessarily implement a complete handler. Several servlets might be installed as required. Neither does the handler need to implement the ultimate version of the protocol. Certain parts of the handler can be exchanged by re-loading its parts; for example, to extend or upgrade to a new version of the protocol.
It is worth noting that applets could be used instead of servlets to implement protocol softness. For example, host2 could catch protocol exceptions and download applets that implement failing parts. The applets can be obtained either from the other party or from another, for example, third party's, repository such as a Web server. In the latter case, neither host1 nor host2 need to have complete protocol handlers. The only information that is needed is the type of the protocol for the intended session. All required bits and pieces can be downloaded from the repositories as needed. The information about the repositories might be publicly available or negotiated between the communicating parties.
This idea will be taken even further with the use of deglets. Simply, each message will be accompanied by a set of controllers that handle the message in a manner appropriate for the receiver equipment. We will discuss it a bit later. Now, let us move to another categ0ry of mobile code, extlet.
The primary example of the use of extlets is
to install and upgrade software in a networking environment. The bare skeleton
of a network is just interconnected hardware. Below the application layer,
there are plenty of services implemented as firmware or middleware. Either
the services are provided as integral parts of the underlying infrastructure,
or they have to be provisioned one way or another. Automatic distribution
of software is not new, but the use of a portable platform makes the ideas
far more powerful and flexible.
Let us imagine that we have a network consisting of Java enabled devices. Virtually every piece of software that is required to run and use the network can be installed as an extlet. That can be done manually, by a knowledgeable network manager, or automatically, by provisioning agents. A repository containing a repertoire of installable services must be available in any case.
For example, consider the manager of a network consisting of a number of workstations and servers. He has to decide what applications are available to the users of the workstations and what kind of services will be available from a particular server. Very often, some of the workstations are also servers at the same time. That kind of diversification can be achieved dynamically by sending selected extlets to appropriate targets. In the further operation, any of the applications or services can be extended or upgraded as the users knowledge of the tools improves, their needs and sophistication grow and new generation of software are being released. For example, the workstation of a software developer will require different set of applications than a workstation of a technical writer. While developers may need a wordprocessor, very rarely a technical writer will need a compiler or a debugger. On the other hand, a technical writer will generally use a complex desktop publishing system rather than a plain vanilla wordprocessor.
Note that the applications and services provisioned by the means of installable extlets do not necessarily reside completely on the local workstation or server. The extlet might implement only a request resolution system that will download appropriate applets from a repository on the per need basis as explained before.
Delegating an agent in the area of electronic commerce is probably
the best example of the use of deglets. A client wishing to purchase certain
goods activates a deglet that will act on the user’s behalf in the purchasing
process. The activation process involves an interview that can be performed
by the deglet or by another agent (called an interface agent). The goal
of the interview is to acquire the details of the purchase. The details
are then fed into the deglet, which starts to visit points of sale on the
electronic marketplace. At each point, the deglet negotiates with the sale
agent the availability of the goods and conditions of a potential purchase.
The deglet can employ an intelligent algorithm to determine whether the
constraints set by its owner are satisfied. An expert system can be used
to make such a judgement. JESS, a Java implementation of CLIPS, is an example
of such a system. The size of compressed JESS is relatively small, but
if transmission of tens of kilobytes were a problem, then an alternate
route would be to consult the owner or a local intelligent agent. Java’s
Remote Method Invocation (RMI) or other similar technologies (for example,
CORBA) can be used to perform such an action. The deglet does not have
to terminate after the first match has been found. It can continue to explore
the marketplace in an attempt to find the best possible deal.
Certain special types of purchases require that the deglet stay alive permanently. For example, a client investing in a stock market may want to be notified whenever favorable conditions arise. In this case, the delegated task is permanent and is assigned to a netlet.
We already mentioned that deglets could be used to enhance communication
protocols. One or more deglets are associated with a message that the sender
directs to one or many receivers. Each deglet can handle the message in
a way that is determined on fly by examining the profile of the receiver
and the receiving device. After determining what is the right presentation
for the particular user and device, the deglet organizes downloading of
a proper handling applet from the presentation server. There might be many
presentation servers accessible from the local device. We call such an
application a universal message server.
We illustrate a case in which a message is sent to two receivers. One of them uses a telephone, while the other accesses the message with a computer. The deglet that arrives to the telephone (Java enabled) downloads a handler that will present a message in a form of a voice memo. If the message arrives to the computer, then either a textual or a more advanced presentation that involves such advanced technologies as virtual reality can be requested. Note that the same scenario would apply if the same user accessed the message using various devices at his convenience.
Mobile code is a convenient vehicle to perform discovery tasks. While the basic network discovery might not be a convincing justification for the use of mobile code, its more sophisticated varieties certainly do benefit from the new capabilities. Nevertheless, the basic discovery of network devices is an excellent vehicle to illustrate the approach.
One of the commonly used discovery techniques is sending ping messages to IP addresses in a certain domain. The discovering process builds its view of the network from the received responses. Instead, a deglet can be created with a sole task of sending the identifier of a visited node to the creator. The deglet is then injected into the network and travels by the means of the implemented migration patterns. There are several of similar issues to resolve as in the ping algorithm (e.g., the scope of the search), but the method is more flexible. For example, it does not require that the interlocutor had the knowledge about the network. The termination of the task can be determined heuristically inside the deglet; for example, by counting the hops or an average number of visits of a particular node.
By implementing constraints on the type of the devices in the discovery deglet implements, we can create partial models consisting only of devices of a certain type. If the constraint is on the status, like node utilization, then we may discover over-utilization problems.
If the delegated task has a permanent nature, then a netlet can
be used instead of a deglet. We already mentioned the need for netlets
that act as persistent buying agents in the context of electronic commerce.
In the case of network discovery, if netlets are used in place of deglets,
then the discovery process becomes continuous. Therefore, the netlet can
discover the changes to the network topology. A number of netlets might
be assigned to perform the task. The speed with which the changes are detected
can be controlled by the degree of the density of netlets. The more netlets
are in the networks, the shortest the detection process is. Of course,
there are certain constraints that define the upper bound on the number
of netlets; e.g., the throughput. Netlets can use the default migration
policies implemented by the migration facilities. Alternatively, they may
implement their own migration patterns. For example, a netlet may define
the scope of the coverage, so it never leaves a particular sub-network.
In the same way as a deglet, a netlet may implement a set of constraints on which the reports are based. Owing to their permanent nature, netlets with constraints constructed as functions of device states become problem detectors. The constraints do not have to be confined to a single network device. They may encode arbitrarily complex fault detection and correlation algorithms. The only limitation is the size of the netlet with a direct impact on the efficiency with which it can migrate and on the network throughput. That issue can be alleviated by a smart programmer taking advantage of the expressiveness of Java.
Netlets that comply with certain security provisions might be allowed to perform actions on network devices. Such active netlets can be used to address problems autonomously leading to an immediate recovery if such is possible. The network manager will either be informed about the event or will be alerted if an automatic recovery is not possible or requires an authorization. A number of such specialized network doctors might provide a high degree of network immunity to a range of problems.
In the context of deglets, tasks are delegated as needed by an interface agent interacting with the delegating entity. In contrast, netlets can be assigned their tasks á priori by their designers and start automatically as an integral part of the networking infrastructure. A number of mechanisms can be used to control the texture and density distribution of netlet societies.