Christian Web Host, Java Programming - Cheap Web Hosting Blog

Part II: Developing Intranet Solutions Listing 4-1 (Continued) */ define( DBI_LOADED , TRUE); class DBI { var $VERSION = 1.0.0 ; function DBI($DB_URL) { $this->db_url = $DB_URL; $this->connect(); if ($this->connected == TRUE) { // set default mode for all resultset $this->dbh->setFetchMode(DB_FETCHMODE_OBJECT); } } function connect() { // connect to the database $status = $this->dbh = DB::connect($this->db_url); if (DB::isError($status)) { $this->connected = FALSE; $this->error = $status->getMessage(); } else { $this->connected = TRUE; } return $this->connected; } function isConnected()

Chapter 4: Architecture of an Intranet Application This framework is provided with the CD-ROM. You don t need to create it from scratch. Also note that the database abstraction uses DB.phpfrom the PEAR. Now let s create the classes needed to implement this application framework. Creating a Database Abstraction Class Accessing a database using its own API is common in the PHP world. For example, most PHP developers use PHP with MySQL and, therefore, they write code that is specific to the MySQL API found in PHP. There is nothing wrong with this approach if you know that your PHP applications will be used only for the MySQL database server. However, if there is a chance that your applications will be used with other databases such as Oracle, Postgres, and so forth, you need to avoid MySQL-specific API. A developer who has abstracted the database API in a level above the vendor-specific API can enjoy the speed of porting the application to different relational databases. Here, we will create a class called class.DBI.php that will implement a database abstraction layer for our application framework. Listing 4-1 shows class.DBI.php, which implements the database abstraction using PEAR DB. See http://pear.php.net/manual/en/core.db.phpfor details on PEAR DB, a unified API for accessing SQL-databases. Listing 4-1: class.DBI.php

Part II: Developing Intranet Solutions The application checks for valid user credentials in the authentication phase, which is already supplied by the framework s login application for valid users. The authorization step involves application-specific privilege management. Not all valid (authenticated) users are likely to have the same privilege based on the type of application. For example, an Employee Information System (EIS) application in an engineering firm can assign different privileges to executive management, department heads, team leaders, and engineers. This is why the authorization code is specific to the instance of the application and should be written by the application developer and should not be provided by the framework. When an application has gone through the authentication and authorization phases, it will run the application. This code will involve invoking application specific business objects and database interaction. The application will have database access via the database-independent abstraction and also will produce status messages and errors using the facilities provided by the framework. Figure 4-5 shows a real-world application framework that we will create in this chapter. DB.php (from PEAR) class.PHPApplication.php class.Debugger.php class.ErrorHandler.php class.DBI.php Your PHP Application Business Logic Figure 4-5: A real-world PHP Application Framework. The core of this framework is the class.PHPApplication.php. This class provides an abstract PHP application that you can extend to incorporate facilities provided by the error handler (class.ErrorHandler.php), the debugger (class.Debugger.php), and the database abstraction (class.DBI.php).

Chapter 4: Architecture of an Intranet Application . Override authorization support: Each application using the intranet application defines its own authorization method. . Debugging support: An application needs to be debugged many times during the development process. Because debugging is a core part of the development process, the framework includes a built-in debugger. The current implementation is very simple yet useful. . Internationalized error and status message handling support: Each application using the framework must use a central error message and status message repository. Both error and status messages can be internationalized. Business logic Each application has its own business-logic requirements. The business-logic objects will be given database connectivity from the application framework. This ensures that database abstraction is maintained. Relational database The relational database access is abstracted from the application using an abstraction layer, which is part of the application framework. This ensures that application database requirements can change without drastically affecting the application. For example, an application can be developed with this framework such that it works with the widely used, high-performance MySQL database and then deployed in an environment where the database is Oracle. Of course, the developers have to be careful not to use any vendor-specific features. Figure 4-4 shows a block diagram of an application that uses the previously mentioned application framework. Application Specific Error and Status Messages (Supports Internationalization) Database Independent Abstraction Authentication (Valid User Credentials) Authorization (Application Specific Authorization Requirements) Application Run() (Application Specific Driver Code) Business Logic Objects (Application Specific Code) Figure 4-4: A block diagram of an application using the PHP Application Framework.

Part II: Developing Intranet Solutions Relational Database Business Logic Your PHP Application PHP Application Framework Components HTML Template-based Presentation Layer INPUT OUTPUT Figure 4-3: High-level architecture diagram of an intranet application using our framework. Using an HTML template-based presentation layer All input and output to and from the application is handled via a template-driven HTML presentation layer. When the application needs input from the user, it presents an HTML page generated from an appropriate HTML template. Similarly, when the application needs to display output, it generates an HTML page by replacing special application-specific tags within the template. This ensures that cosmetic changes to the input or output interfaces can be done without requiring help from the application developer. For example, an application that uses the template-based presentation layer can have its interface modified by an HTML writer or graphics artist. Using PHP Application Framework components The components in the PHP Application Framework (PHPAF) layer implement the base application by providing the following services: . Database abstraction support: See the Relational database section later in this chapter for details. . Centralized authentication support: All applications defer the login and logout to the central authentication facility, as discussed earlier in this chapter.

Chapter 4: Architecture of an Intranet Application created that allows all applications to identify an authenticated user. When a user attempts to access an intranet application without logging in first, the application should automatically redirect the user to the login application. When the user is successfully authenticated via the login application, she should be automatically forwarded back to the application she had been attempting to access. The login process should be seamless. Similarly, a central, seamless logout facility should be provided to allow the users to log out from the intranet. . Application-specific authorization: Different types of users exist in an intranet and, therefore, intranet applications must discriminate when authorizing users. Employee access to an intranet application will vary. Because each application will have different requirements for authorizing the user, the task of authorization should be left to the application itself. . A shared database: Most intranet activity involves collaboration or group efforts. For example, users working in a team within a project might need to report the status of the project tasks individually, but the team leader or department head needs to access the information from the entire team to make technical or business decisions. A shared database is therefore the solution to store data. Based on these requirements, let s go ahead and build an intranet application framework. Building an Intranet Application Framework An intranet consists of many applications. It is a good idea to create an application framework that provides a set of commonly needed objects and services to implement applications. Typical intranet applications have user authentication requirements, database access requirements, user interfaces requirements, and business logic requirements. Each application s business logic, which is the work done by the application, is unique and must be implemented in the application code itself. However, each application can benefit from using a standard application framework consisting of objects that standardize authentication, database access, user interface, etc. The framework I will build here will do just that. Figure 4-3 shows the high-level design diagram for an intranet application that will use our application framework. Now let s discuss the components of this architecture.

Part II: Developing Intranet Solutions Marketing PC PC PC Engineering PC PCPC PC PC Sales MIS PC PCPC PC PC Intranet Server Firewall Database Server Administration PC PCPC PC PC Figure 4-1: A typical intranet-enabled company. Any Department Department Head Team Employee Project 1 Team Leader Team Employee Project (n) Team Leader Figure 4-2: User requirements for a typical intranet-enabled company. Each intranet application you develop must be able to authenticate and authorize different types of users. For example, an employee vacation management application has to incorporate the hierarchical chain of command that enables employee vacation requests to be reviewed and approved first by team leaders and then by the department head. So far, our intranet application framework has the following requirements: . Central authentication: Users need to be authenticated to access intranet applications. There are likely to be many intranet applications within an organization and therefore user authentication should be done such that a user logs in only once to access any application. A session should be

Chapter 4 Architecture of an Intranet Application INTRANET APPLICATIONS ARE PRIMARILY focused on automating an organization s daily business processes. A modern company has many intranet applications that are available to its employees to help them be more productive and efficient. For example, a group calendar system or task-tracking system can save a great deal of time and resources for most companies with more than five employees. This chapter focuses on the underlying architecture of intranet applications and discusses an open-source framework that enables you to develop intranet PHP applications in a rapid manner. Understanding Intranet Requirements To develop intranet applications, you need to understand how a typical intranet is deployed. A company with two employees can have an intranet, but the average intranet application is deployed in an organization with tens to hundreds of users. Figure 4-1 shows how an intranet connects employees in multiple departments of a company that uses an intranet application server to manage its daily internal business functions. A company generally uses its intranet server to automate interdepartment communication activities such as a shared calendar, shared contact database, document management, project/task tracking, and so forth. Before you develop the framework that will enable you to create intranet applications in PHP, you need to understand the intranet user requirements. Figure 4-2 shows how a single department within an organization appears from an intranet- requirements point of view. Users in organizations work in teams. A team usually has a team leader and a project assignment. The projects are managed by the department head. This type of hierarchical user base is very common in modern organizations.

Part II Developing Intranet Solutions CHAPTER 4 Architecture of an Intranet Application CHAPTER 5 Central Authentication System CHAPTER 6 Central User Management System CHAPTER 7 Intranet System CHAPTER 8 Intranet Simple Document Publisher CHAPTER 9 Intranet Contact Manager CHAPTER 10 Intranet Calendar Manager CHAPTER 11 Internet Resource Manager CHAPTER 12 Online Help System

Part I: Designing PHP Applications version with a single command. It is also the de-facto version control mechanism for many large-scale Open Source software. You can learn more about CVS at www.gnu.org/software/cvs or at http://www.cvshome.org. Summary In this chapter I have discussed various best practices for functions/methods, database, user interface, documentation, security, and version control. Getting used to these best practices is often very difficult since many programmers are often under great time pressure to produce workable applications. However, it is very important to get started with these practices as early in the development as possible so that they become second nature in future projects. This is particularly true for getting used to version control tools such as CVS. Many developers find version control as an additional task that does not relate directly to the deadline and simply wait till the very end to place code in version control. This type of practices often leads to big code maintenance problem in the long run. The key issue is early adoption of best practices so that you get used to it from the beginning.