DEVELOPING WITH AN N-TIERED ARCHITECTURE

Rather than cramming all your application's code into a single interdependent mass, an n-tiered architecture mandates that you divide it up into sections or tiers which talk to each other through a (hopefully) simple, well-defined protocol or API (application programming interface). In a relatively simple web application, your topmost tier might be responsible for generating dynamic HTML content and processing requests from clients (usually browsers). The tier below that might validate that data, and the bottommost tier is generally responsible for data persistence (usually using a database).

Let's say, for example, in the process of creating an account for an e-commerce application, you enter a login name and a password (see Figure 9.1). The top tier hands your registration data to the middle tier, which determines that the login name you chose is not unique, so the top tier is told to rerender the registration form with a message asking you to choose a different login name. The second time the form is submitted, the middle tier confirms that the name is unique this time, so the data is handed to the bottommost tier where it is stored in a database and used for authentication purposes each time you log in to your account.

Figure 9.1. The n-tier structure.

There are three primary advantages to an n-tiered architecture:

1. If each layer of code is insulated well enough from the layers around it (in objectoriented programming, this is usually referred to as "encapsulation"), then changes in one layer should have little or no effect on other layers.

2. By having distinct boundaries between layers of code, it is easier to allocate developers and designers, allowing teams to specialize in their respective areas.

3. With a well-understood protocol between layers of code, it becomes possible to implement different tiers with completely different technologies.

This chapter is primarily concerned with the third advantage of n-tiered application development because it allows us to combine the strengths of two very different technologies Flash and Java to arrive at a single, fully functional application.

Note that if your expertise lies primarily in the realm of Flash rather Java, there is still plenty to be gained from this chapter. Not only will you find Java remarkably similar to Flash 5 ActionScript, but the higher-level architectural concepts presented here apply to software development in general, whether you are using Java, C++, or Flash by itself.