Middle-Tier Solutions

Middle- Tier Solutions

Most commonly, building a server that combines the advantages of SQL and XML involves a three-tier architecture. Such a strategy separates the process of delivering information into three different layers . Each is a distinct process. Each is created in different software ”and each might be running on a different machine.

The client tier is the software in direct contact with the human being. It is software dedicated to presentation of information and creation of an interactive experience. In our case, this tier typically consists of the browser, with its Flash player plugin and the ActionScript file we have written. This tier communicates with the server using XML as a data language.

The back-end tier incorporates the fundamental activity of the organization publishing the site. It could be almost any process; for example, at http://www.time.gov the back end is the Atomic Clock. But most sites are less exotic, and almost universally their back-end tier is a database management system that maintains the data that drives the site's activity, for example, the inventory of a bookstore or the schedules of an airline or the messages on a bulletin board. The DBMS (Database Management System) is specialized software that allows sites to manipulate enormous bodies of data with tremendous efficiency and reliability. The ability of many users to simultaneously interact with the data is an important standard feature.

The middle tier connects the other two. It is often called the application level. In theory, this level can be omitted. In fact two-tier (client/server) architecture was popular until recently, and even one-tier systems used to be common. (Our local library's card catalog is still available as a one-tier application). But placing an application level between the client and the database has several advantages. The most important is to focus the DBMS strictly on database activity, maximizing the efficiency of the most critical and expensive tier. Also important is the isolation of application code into a layer that understands the business logic of the site. It is far easier to tune the application code in such an environment, and the final system is much more responsive when it is shared among three specialized servers. In our case, the middle tier communicates with the DBMS using the SQL language and to the client using XML. So one of its most important functions is translating between XML and SQL, as well as translating between user interactions and database interactions.

First Steps

In this book we construct three-tier architectures ”but not all at once. Three-tier architecture involves creating six software interfaces: Flash must read and write XML; the middle tier must read and write XML to communicate with Flash and read and write SQL to communicate with the DBMS.

So far we have a Flash application that reads XML. In this chapter we write our first server code. All the application will do is create XML and pass it on to the Flash tier.

Application-Level Options

There is a wide variety of technologies to choose from when building a server-based application. The rapid growth of the Internet has forced new technologies forward but it was enabled by earlier generations of development. Older IT problems involved managing enormous databases and doing so with great speed. The web was born in a world where excellent solutions like Oracle or SQLServer were in place to manage data. The problems faced by early web site developers were not so much how to manage databases but how to expose existing databases to an enormous new audience ”and how to do so while competing with peers for the attention of an impatient public.

This problem is not computationally intensive. It is time-to-market intensive . Old technologies based on a lumbering cycle of code/compile/install/test are not well suited for this application level. To match the web's high demand for speed of development and modest demand for speed of execution, scripting languages have emerged. These scripting languages are forgiving coding environments with low barriers to entry. They favor easy access to useful functions over adherence to academic design.

Active Server Pages

A server-side scripter has many choices today. One of the most popular choices is ASP. ASP is pure Microsoft ”it is built on a Visual Basic sensibility. And it tends to run well only on a Microsoft server, like IIS. It is especially compatible with Microsoft's FrontPage web page builder, with InterDev, its development environment, and with Internet Explorer, the Microsoft browser. This tremendous integration into a proprietary world is the strength and the weakness of ASP. Although many organizations find comfort in being surrounded by wall-to-wall Microsoft certified developers, others feel anxiety when snared by the hegemony of Gates. Many programmers who are used to the conventions of C and its descendants never feel comfortable with the irregular syntax of Visual Basic.

Perl

If syntax is an issue, Perl also is problematic . Perl is the most venerable of server solutions. It has been around since the beginning of the Internet and must be credited greatly for the medium's early stunning growth. While the proliferation of content and simple web pages is due mostly to the flexible functionality of HTML, Perl enabled rapid advances in functionality and in the realization of bold ideas.

But in this era of convergent languages, Perl is an obscure and superannuated dialect . It has a tough learning curve, and because many people handle it clumsily, it is not usually a sound basis for collaboration. Further, each access often requires an individual execution of the Perl interpreter by the CGI mechanism, and it often lacks persistence between pages.

Java Server Pages

JSP is an attractive alternative. The Java scripting environment is fairly open and regular. Despite its association with Sun Microsystems, JSP is far less proprietary than ASP.

JSP is much more than a simple scripting language. It allows authors to write interpreted script command, but its real power is in linking pages with Java servlets. Servlets are application code written in Java and embedded into a page. They allow great power, and the JSP syntax is extremely well integrated with XML. Functionality is packaged well in this system; it is excellent for large development projects involving many developers and many organizations.

But for small teams engaged in rapid development, the ramp up to JSP constitutes a large overhead. As a platform for the examples in this book, it has the same costs.

PHP

Compared to corporate showdogs like ASP and JSP, it is easy to miss the charm of the mongrel language PHP. Next to the purebreds, it is homely. It lacks the formal discipline and the design integrity of its competitors . Their feature sets result from long committee meetings of programmers, architects , and marketers, all as picky as pedigreed breeders. By contrast, PHP has been bred by Darwinian forces. As a programmer feels a need, he creates a new feature. If the feature works, it is often contributed back to PHP's bubbling gene pool. The best features become part of the PHP standard.

PHP has grown like a weed, quickly and opportunistically. Its syntax is a "best-of" mixture, combining a general Java-like (C plus objects minus pointers) syntax with occasional lapses into Perl, like the arcane dot-operator.

PHP is a child of the open-source community. Its native land is Unix. With effort and luck it can operate on an NT server. On NT, it exists as a script interpreter, invoked by the server every time a PHP script (.php) script is served . On a Unix installation running the ubiquitous Apache server, the PHP engine is a part of the server itself. It is a module of Apache and it does not have to start up from scratch every time a script is encountered the way a stand-alone script interpreter or CGI program would.

PHP is easy to use, stable, free, and extremely capable. And it is very well documented. The formal documentation is published in 11 languages and distributed in 10 formats, and each format includes not only the official documentation but the comments ( elaborating or contradicting) of users ”including you, perhaps. In addition are dozens of tutorials, discussion groups, and code repositories all over the web.

That such resources can develop around a product for which no money changes hands is remarkable . PHP began as the Personal Home Page project of Rasmus Lerdorf. He built it as a tool to create an interactive r sum . He shared this tool with a few people who expressed interest. Two students at Technion Unversity (in Israel) formalized it into version 2. And it has grown since, with contributions from all over the planet. Those two students, Zeev Suraski and Andi Gutmans, are now devoted full time to PHP, along with a modest staff.

In particular, the serious ActionScript community has generally accepted PHP as its preferred server language. (Maybe this is true only of ActionScripters who share their code and knowledge ”but those who do not are hardly serious members of a community.)

So we begin to create server applications by addressing PHP.