Multi-Tier Application Programming with PHP

Practical Guide for Architects and Programmers

David Wall

• Publisher: Morgan Kaufmann
• Year: 2004
• Print ISBN: 9780127323503
• eBook ISBN: 9780080537153
• Topic: Ciencia de la computación
• Subtopic: Ciencias computacionales general

While many architects use PHP for projects, they are often not aware of the power of PHP in creating enterprise-level applications. This book covers the latest version of PHP – version 5 -- and focuses on its capabilities within a multi-tier application framework. It contains numerous coding samples and commentaries on them. A chapter discusses object orientation in PHP as it applies to the multi-tier architecture and other chapters discuss HTTP and SOAP, the two communication protocols most useful in tying together multiple layers. There is also coverage of database design and query construction as well as information about tricks you can use in generating user interfaces. - Covers PHP as it relates to developing software in a multi-tier environment—a crucial aspect of developing robust software with low cost and ease of use as design goals. - Makes extensive use of Simple Object Access Protocol (SOAP) and Web Services as implemented in PHP and NuSOAP. - Shows precisely how to make use of the InnoDB table type newly available in MySQL. InnoDB supports true referential integrity and row-level locking. - An application example (a multi-currency bookkeeping application) runs throughout the book, showing various PHP capabilities as well as the database interaction.

chapter 1

Introduction

Multi-tier software enables you to spread computing resources, which is to say, software components, across a network. By designing your software applications in such a way that their constituent parts exist on multiple machines, you can achieve greater reliability, better performance, easier management, and cost savings. In other words, multi-tier architecture gives you a head start in achieving what are usually the most important goals of software design.

This chapter explains the theory of multi-tier design and lays down a bit of background, conceptually and lexicographically. It also gets into the question of when you’d want to consider PHP and an open-source database server for implementing a multi-tier design, and when a commercial solution might prove superior.

1.1 Defining Multi-Tier Software Design

The basic idea of a multi-tier design is that all of the logical functions of the application are (or at least have the potential to be) separated on multiple computers interconnected by a network. Each logical function, usually referred to as a layer or tier, receives input from and provides output to other layers. The functional layers are:

Persistence. The database or other storage mechanism that keeps data in an organized way.

Accessor. The programs that pass queries to the persistence layer (in other words, the programs in which structured query language (SQL) statements are hard-coded). These programs expose “get” and “set” functions.

Logic. The programs that process user input and stored data and come up with a useful result.

Presentation. The programs that format the results of the logic layer as hypertext markup language (HTML), extensible markup language (XML), or whatever else the user requires.

Requester/consumer. The Web browser, XML parser, or other client that makes requests of the application and receives its output.

Elsewhere. The external Web services, HTML pages, and other resources to which applications make reference. The elsewhere layer may provide information of public interest, such as information on currency exchange rates or the weather. In other cases, the elsewhere layer may have to do with providing information that is external but still private, such as price lists from a vendor. The part of the elsewhere layer that actually provides the data is generally not under the direct control of the architect or programmer, but the software concerned with accessing it is.

This inventory of the tiers that make up a multi-tier application should be broadly familiar to anyone who has studied application architecture. This description, though, differs from standard in three respects:

1. It explicitly states that the persistence layer (the database and its database management system) and the accessor layer, which feeds SQL queries to the persistence layer, are separate.

2. It explicitly lists the requester/consumer layer as part of the application, even though the software running there is usually not under the control of the developer building the rest of the application (in the case of a browser, it’s from the Mozilla team or Microsoft or whomever).

3. It acknowledges that remote resources (the elsewhere layer) can be an integral part of a multi-tier application.

Overall, the design looks like what is shown in Figure 1.1.

Figure 1.1 Multi-tier software design under PHP makes it possible to spread computing resources across a network

1.2 Advantages of a Multi-Tier System

Multi-tier software applications earn their keep because they offer certain advantages over monolithic or simple client-server applications. Organizations thinking about implementing such a system should make sure that their requirements match with the strong points of multi-tier design, and that the weaknesses of the approach (discussed in the next section) do not overshadow the strengths.

Simply put, multi-tier systems, in comparison with monolithic or client-server systems, offer greater return on investment over time because of their greater adaptability and ease of maintenance (at least from a programmer’s perspective). Depending on specific conditions, multi-tier applications may or may not offer advantages in terms of absolute performance as well.

This section provides a run down of the chief selling points, from a commercial point of view, of multi-tier software systems. It shows you why multi-tier software architecture under PHP will help your organization become more efficient and profitable.

1.2.1 Software Modularity

The functional elements of a multi-tier software application are broken up into autonomous units. Those units may be classes or procedural programs; it does not matter. The important thing is that a given element expects a certain input, provides a certain output, and does so via known protocols (like straight hypertext transport protocol [HTTP], or simple object access protocol [SOAP] over HTTP, or SOAP over simple mail transport protocol [SMTP]). As long as these characteristics are documented, it’s possible for sets of modules to interact in different ways, so as to adapt better to various business requirements.

Modularity and abstraction breed adaptability, and they also allow additional flexibility. Though all software modules in this book’s illustrative software systems are implemented in PHP (mostly as procedural programs), it would be easy to migrate them to an object-oriented implementation gradually, testing throughout. It would also be possible to fit classes or programs written in languages other than PHP into the software designs described in this book. If we were software design consultants, and we had a customer with a set of SOAP-aware accessor-layer classes implemented in Java, would we implement redundant software in PHP in order to provide a new service to a user? We would not. A new PHP-based layer of software on the business logic layer would speak to the Java classes.

1.2.2 Reliability

With modularity also comes reliability. It’s a basic tenet of software engineering that incremental development is generally good. You get the basic framework going, then add and test one feature at a time. You test recursively to verify that newly added features haven’t broken old ones. A multi-tier software system in which separate programs on each layer handle specific tasks is inherently compliant with this principle. When you add a class, you can (and should) test it, to make sure that it doesn’t break what was working before.

1.2.3 Division of Responsibility and Ease of Management

When software is broken into functionally distinct layers, it’s easier to divide human responsibility for the layers among multiple teams. You might choose to make one group of programmers responsible for designing and maintaining the accessor layer, for example, telling them only what functions would need to be exposed and what values should be returned. Let them figure out the most efficient way to meet those requirements without worrying about other aspects of the system. The scaling limitations that usually impinge upon a project of intellectual creation (which is what a software project is—these limitations of scaling are described by Frederick P. Brooks in The Mythical Man-Month [Addison-Wesley, Boston, 1995]) don’t apply as strongly because the lines of delineation between layers are so distinct.

1.2.4 Ease of Documentation

To an extent, multi-tier software applications are self-documenting, in that it should be clear that a program on the presentation layer (which will certainly be denoted by a unique directory, if not a unique server or two) has to do with delivering information in a form that’s meaningful to some client (whether that client is a person using a Web browser or a remote software application consuming XML, or something else). Programmers can easily give their programs descriptive filenames and comments. Required support files, Web services description language (WSDL) files, for example, provide further documentation. There’s quite a lot of information available in a multi-tier software system even before the first line of human-language documentation is written.

1.2.5 Security

Multi-tier software, by its very design, incorporates what could be called encapsulation or compartmentalization. This advantage is particularly evident with respect to the schema of t...

Table of contents

• Cover image
• Title page
• Table of Contents
• The Morgan Kaufmann Practical Guides Series
• Copyright
• Dedication
• Preface
• Chapter 1: Introduction
• Chapter 2: Principles of Object Orientation in PHP
• Chapter 3: HTTP in PHP
• Chapter 4: Simple Object Access Protocol Under PHP
• Chapter 5: Designing and Implementing a Multi-Tier Application in PHP: A Succinct Example
• Chapter 6: The Persistence Layer
• Chapter 7: The Accessor Layer
• Chapter 8: Business Logic
• Chapter 9: The Presentation Layer
• Chapter 10: The Elsewhere Layer
• Afterword
• Index
• The Morgan Kaufmann Practical Guides