**6. Code-on-demand paradigm**

Typically, code on demand is used for any technology that sends executable code from a server host to a client host on the request of the client's application. Code on demand is a specific use of mobile code under the field of code mobility. In the code-on-demand style, as delineated in **Figure 10**, a client component has an access to a set of resources, but not the know-how on how to process them. It sends a request to a remote server for the code representing that know-how, receives that code, and executes it locally. So as per the code-ondemand paradigm, knowing the know-how is necessary when in need [17].

**6.1. Working and architecture of applets**

in above **Figure 11**.

**6.2. Life cycle of an applet**

off to other pages.

**Figure 12.** Life cycle of applet.

and client may be requesting from a Linux-based system.

Atop these five methods, depicted in **Figure 12**, an applet is been created:

called after the param tags inside the applet tag have been processed.

applet sits. It can, therefore, be called repeatedly in the same applet.

behind after a user leaves the page that contains the applet.

The internet is a combination of various kinds of systems or platforms that are often required to communicate with each other. The client that makes a request may be from a completely different platform for instance the application may be hosted on the windows based server

Evolution and Paradigm Shift in Distributed System Architecture

http://dx.doi.org/10.5772/intechopen.80644

17

Java introduced a new technology that would allow any client from any network platform to host and execute applications over the internet. This new technology was called as applets [18]. The word applet stands for an "application scriplets". This can be defined as a piece of java code residing on a server machine requested via a browser downloaded over the internet and executed on the client machine via the browser. In order to execute the applet on a client machine, the browser must be java enabled i.e. JRE must be enabled. An applet is typically embedded inside a web page and runs in the context of a browser. The browser's Java Plug-in software manages the lifecycle of an applet. The architecture of applet is shown

**a.** Init(): This method is intended for whatever initialization is needed for your applet. It is

**b.** Start(): This method is automatically called after the browser calls the init method. It is also called whenever the user returns to the page containing the applet after having gone

**c.** Stop(): This method is automatically called when the user moves off the page on which the

**d.** Destroy(): This method is only called when the browser shuts down normally. Because applets are meant to live on an HTML page, you should not normally leave resources

**e.** Paint(): Invoked immediately after the start() method, and also any time the applet needs to repaint itself in the browser. The paint() method is actually inherited from the java.awt.

Say for example, one host (A) initially is unable to execute its task due to a lack of code (know-how). And another host (B) in the network provides the needed code. Once the code is received by A, the computation is carried out on A's machine. Host A holds the processor capability as well as the local resources. Unlike in the client–server paradigm, A does not need knowledge about the remote host, since all the necessary code will be downloaded.

Java applets are excellent practical examples of this paradigm. Applets get downloaded in Web browsers and execute locally.

**Figure 10.** Code-on-demand.

**Figure 11.** Architecture of applet.
