| By Thomas Myer Principal, Triple Dog Dare Media IN THIS CHAPTER Terminology Middleware Options Database Options What is a Web application? That's the question I'll try to answer in this chapter. Anyone who has spent any amount of time with Web applications might tell you that Web applications consist of many pieces; they can be implemented in Java, ASP, PHP, Perl/CGI, and they might be based on database tables, XML files, or other data sources. If you search on "Web application" at any search engine, you're likely to uncover hundreds (if not thousands) of white papers, case studies, and marketing hoopla over how great they are. Before we get into all that, though, I'd prefer to step back a little and take in the overall picture. Although Web applications seem like a very complex topic, they're actually very simple conceptually. A Web application is a Web site that contains dynamic pages instead of static ones. Dynamic pages contain instructions, sometimes by themselves, sometimes mixed in with HTML code and content, that get processed and executed by a Web server. In other words, an individual page's final content is not determined until a visitor views that page. An example of a dynamic page is a news feed that gets updated regularly. Instead of writing news headlines to a static HTML page, the news items are updated in a database, and instructions on the dynamic page extract the database information and display it for the viewer. Another example of a dynamic page is a search results page. Anytime a user enters a search term into a search engine and clicks Find or Search, a Web application, working in the background, searches through a list of files or database records and then returns results that match the entered search term. For the most part, Web applications are usually built to handle lots of data moving through a system, such as content published on a site, information captured from visitors, or personalization systems that display content according to a visitor's preferences. Although Web applications can do a variety of tasks in a variety of contexts, they're all very much the same under the covers. Learn to build one, and you can probably figure out how to build others. From an architectural standpoint, Web applications usually have three components, or layers: A presentation layer, or what you know as the user interface. This layer includes all HTML code, Flash components, and images. A business logic layer (also known as middleware), which contains processing instructions in such languages as JSP, PHP, or ASP. A data layer, which might contain database tables or flat files (such as XML) that are processed by the middleware and displayed on the user interface. This three-layer approach is known as a "three-tier architecture." Delivering a Web application in these three tiers allows parallel development the visual designers can lay down their design frameworks and page flows without impacting how the database design unfolds, and the middleware/business logic developers can create their code without having to worry about design issues. At some point, obviously, the three elements have to come together (the integration phase), but if everyone has followed the technical specifications, things shouldn't be too bad. NOTE You didn't think you could develop a complex application without a specification, right? A good specification includes use cases, an application workflow (detailing how the pages interact with each other), and a database diagram.
Many site owners find it very convenient to use Web applications in place of static pages. After they have a Web application installed, they can update content in a database and have those changes appear on their site. They can also separate the look and feel (design) of their site from their content, which makes it easier for them to update their sites without having to undergo painstaking manual changes. Furthermore, they can back up all their content using an automated database tool that can be set to run at a convenient time, like 2 a.m. Figure 16.1. Three-tiered architecture of a Web application.
Some of these concepts might be foreign to a design-centric view of the Web. After all, many Web applications remove the designer from having to make further updates to a site after it's live. This has been viewed as both a curse and a blessing a curse because it has seriously impacted designer's revenues (the owner of a Web application doesn't have to hire a designer to update site pages); a blessing because designers want to design, not update, content. Dreamweaver MX comes with added support to create, test, and deploy Web applications. Before we get much further along, though, I want to define some terms that you'll hear throughout this section of the book and cover options you have for middleware and databases. |
