|Lesson 8||Executing components of applications |
| Objective || Describe the architectural considerations when developing Web sites and applications. |
Applications Architecture for Websites
Executing components of applications
The following are basic guidelines for you to use when choosing between executing client-side and server-side components:
- Components of the application that are shared among clients persist, or carry over from session to session, from session to session should be on the server side.
- Components that are not shared among clients and that do not persist from session to session must reside on the client side.
- Components that relate directly to client resources must have a client component. Examples include audio clips, video clips, and animations. Some of these, such as streamed video and audio, may also have server components.
- Certain components, such as those identifying the connection between the client and server, may be on both the client side and the server side.
You should also consider these additional factors that are involved in deciding where processing should be performed:
- Server location
- Response time
- Client and server processing capacity
- Reuse of components
You will learn more about these additional considerations in the following table:
||For security reasons, a server located at an ISP is restricted in terms of the scripts that are allowed. If a site uses many CGI and other scripts and applications, consider server-side processing and co-locating the server.
||If extremely rapid feedback is required, consider processing the component on the client.
||If a component is intended to run on an extremely thin client lacking in processing power, consider processing the component on the server.
||If the server is lacking in resources (i.e., disk space, processor power) for handling the expected demands, consider offloading some of the overhead to the client in the form of Serverless computing
|Resuse of Components
CGI and SSI
CGI is a simple mechanism for implementing portable server-side applications. It has been employed throughout the Web. However, there are a number of problems associated with CGI processing. Its main deficiency is performance. Processing a request that invokes a CGI script requires the spawning of a child process to execute that script (plus another process if the script is written in an interpreted language such as Perl). Furthermore, any initialization and other processing that might be common to all requests must be repeated for every single request. SSI has similar deficiencies when its command processing employs CGI under the hood. It adds the additional performance penalty by requiring servers to parse SSI pages. Most importantly, SSI may represent a serious security risk, especially when not configured correctly by the server administrator. The SSI mechanism is not scalable, and provides only limited opportunities for reuse. With this in mind, a number of other approaches to dynamic content processing arose in the Web server environment.
ISAPI and NSAPI
Efficiency concerns may be addressed by using native server APIs. A native API is simply a mechanism providing direct "hooks" into the Web server's application programming interface. Use of a native API implies the use of compiled code that is optimized for use within the context of a specific Web server environment. From a historical perspeective, NSAPI and ISAPI were two approaches employed by Netscape's Web server software and Microsoft’s IIS, respectively. The problem is that there is no commonality or consistency amongst these native APIs. They are different from each other, and code written for one environment cannot be reused in another. This makes it impossible to implement portable applications.
In the next lesson, you will learn which elements of Web sites and applications should be tested.