PDF of this tutorialBusiness applications must implement security beyond the anonymous browse common for most Web sites. Security requires the cooperation of components at the top and middle tiers to authenticate the user and authorize application services. A common approach is the use of a dialog window through the browser to enter the user name and password. The middle tier authenticates the user and establishes a session. All messages between the browser and the Web server use a session identifier to maintain a logical connection between the tiers.
Once the session is established, the Web server has a mechanism to store the transaction state. The state of the transaction reflects the most recent data input by the user that has not been committed to the database. For instance, when creating a customer account, information is gathered about the customer and services, and perhaps an appointment is set to install the new service. As the user inputs these pieces of information, they are not usually committed to the database right away. Instead they are held in memory somewhere until the complete order is ready. Then the order can be validated for consistency and integrity before committing it to the database.
A critical factor in the performance and integrity of a system is where the transaction state is held. Opinions vary on this issue, but the software-engineering principles of the three-tier architecture apply to Intranet applications as well. With a thin-client approach, the state does not belong in the client because by definition the business logic is in the middle tier. It is also desirable to keep the accesses to the database stateless to allow for maximum flexibility and scalability. Keeping the state at the middle tier associated with the user's session helps minimize traffic between tiers, promotes good performance, and makes good use of the technology.
Figure 6. Web Server with Session State
The Web server can use various ways to access the business logic and place the results into a Web page. Some Web server vendors allow the developer to embed code directly in the Web page. This code, written in a programming language such as Java or Visual Basic, can directly access the business logic. Often this code either produces information that is embedded directly into the Web page before sending it to the browser or generates code that is used to populate a visual control, such as a data table, with the information when the browser loads the page. This method can lead to complex Web pages that contain, in addition to the normal text and HTML, code that the Web server executes in the middle tier and code that the Web browser executes in the top tier. It is important to develop and follow programming standards that address managing this complexity.
An early scheme used to couple business logic to Web pages is the common gateway interface (CGI). CGI involves the use of scripts or programs that Web pages call to process user inputs or build output data. This technique is generally being replaced by embedding programming languages such as Java in the Web page.
An important technology emerged during 1998 known as extensible markup language (XML). Although it is related to HTML, XML allows the developer to define new tags instead of the fixed set used by HTML. This simple but powerful extension enables a strong mechanism for data exchange between the Web server and browser. The Web server can use XML to provide data as a series of tag and value pairs, as shown in the following example.
<last-name>Doe</last-name>
<first-name>Sarah</first-name>
<phone>123-123-1234</phone>
</customer>
Using XML to provide the data in this way, in conjunction with some client-side script, means that the data is sent only once to the client, and the client can provide multiple views of the data using different sorting or filtering as required. Components for use on browsers are now being built with XML awareness, and they can parse and display the data directly.
Physically, multiple computers can be used at the middle tier. These computers are implemented as peers, each with an identical Web server. A user can establish a session with any of the computers and will stay with the computer for the duration of the session. Providing a central URL that redirects the initial session request to one of the peer Web servers to spread the load across the available systems can leverage the use of a single computer. This implementation provides some redundancy in case of a failure. Careful attention here can prevent the failure of any one of these computers from taking down the system. The user of a computer that fails can connect to one of the peers and would only lose the work for the current transaction. More elaborate schemes can be implemented to prevent even this loss.
