CSE 134A Lecture Notes, November 7, 2001

CSE134A LECTURE NOTES

November 7, 2001

ANNOUNCEMENTS

There's no class next Monday, November 12, because of Veteran's Day. The final exam will be on Thursday December 6, from 3pm to 6pm, in this room.

USER INTERFACE

Let's talk about the current project, due Wednesday next week. Getting the user interface (UI) right is difficult. Bad visual interfaces are still usable, but bad voice interfaces are not. There are few established principles, but here are some guidelines.

(0) If you have the choice, provide 80% of the functionality with 20% of the complexity in the user interface, rather than 100% functionality with 100% complexity.
(1) Make the service sensitive to the context of the user. For example, let the user say "today" when a date is needed.
(2) Keep prompts short, but specific. For example, "say or type your four-digit PIN" not "enter your personal identification number."
(3) Get confirmation from the user, but unobtrusively. Make backing up easy.

A fundamental issue: User initiative versus system initiative versus mixed initiative.

FRONT-END SERVER DESIGN

Front-end servers have no long-term state, so they can be cloned. Each will have its own copy of the same content, i.e. HTML, PHP, etc.

Load-balancing software and/or hardware spreads requests across multiple front-end servers, and includes failure detection for frontend servers. Several different load-balancing techniques exist, with different levels of complexity: random, adaptive, stateful, adaptive and stateful.

Session management stores state information in clients and a backend server, not in the frontend servers. Client state can easily be distributed across multiple state servers. Typically session information is not highly confidential and may be stored inside the DMZ.

SSL sessions are segregated from regular HTTP sessions. SSL servers have hardware for encryption.

BACK-END SERVER DESIGN

Persistent content is divided across multiple back-end servers. Fault tolerance is expensive for servers that must maintain state. Failover clustering assumes that different servers can access the same or replicated disk drives. A group of servers that share storage is called a partition.

Allocating data to partitions is difficult. The objective is to avoid hot spots. We need tools to split and merge partitions. A large multiprocessor system can replace multiple partitions, but is usually more expensive.

The most complex sites use other applications, encapsulated as objects, e.g. Enterprise Java beans. Other applications include legacy databases, existing enterprise software e.g. for manufacturing planning, external ad servers.

APPLICATION SERVERS

Web servers have evolved into what are now called "application servers." These software platforms provide runtime environments for executing complex software in response to requests from clients.

There are two main types of app server: page-based and component-based. PHP is page-based, while EJB (Enterprise Java Beans) is the most common among component-based. For an overview see http://www.zdnet.com/filters/printerfriendly/0,6061,2713465-50,00.html

PAGE-BASED APP SERVERS

The main types are Microsoft ASP, ColdFusion, and Java server pages (JSP).

Code for generating displays is mixed with HTML output code. This reduces modularity and makes developing multiple alternative interfaces difficult. On the other hand prototyping is easy.

ColdFusion has fail-over and load-balancing between servers. PHP version 4 and ASP.NET have compilation to byte-code. Other performance features include caching. Early implementations had poor performance and scalability, but the latest versions can be very good.

Typically, page-based app servers do not provide script-level multithreading, or Java support. They typically do have the ability to invoke other servers, e.g. via CORBA (common object request broker architecture), Microsoft COM (common object model), SOAP (simple object access protocol), and HTTP.

COMPONENT-BASED

These typically use Java as their programming language, and a distributed object standard called Enterprise Java Beans (EJB), which is part of the general Java 2 Enterprise Edition (J2EE) standard along with a database API known as JDBC (supposedly not an acronym for Java Data Base Connectivity). Pricing is $795 to $35000 per CPU for IBM WebSphere. Microsoft products, while not cheap and not quite as high-end, are much cheaper. Despite using Java and the EJB so-called standard, you are typically locked in to one platform vendor due to incompatibilities.

The platforms provide

adaptive load-balancing
fail-over clustering
live deployment and updating of modules
remote monitoring
database connection pooling
two-phase commit
state management including session management

These last three features have historically been provided by so-called transaction monitors.

New modules of code can encapsulate existing databases and other servers. Different modules can provide different displays. EJBs have three main types: session beans, entity beans, and message-driven beans.

The importance of Java may decline because Sun and Microsoft both support SOAP and XML.

The scalability of component-based servers is not as good as suggested by the hype from vendors. One concrete case study reports 4000 users at 177 pages per second on six servers: two web, three application, one Oracle. Extreme scalability requires custom architecture and software, and traditional computer science design principles.