LAMP (Software Architecture)

The acronym LAMP refers to a solution stack of software, usually free and open source software, used to run dynamic Web sites or servers. The original expansion is as follows:

  • Linux, referring to the operating system
  • Apache, the Web server
  • My SQL, the database management system (or database server)
  • P (one of several scripting languages: Perl, PHP or Python. )

The combination of these technologies is used primarily to define a web server infrastructure, define a programming paradigm of developing software, and establish a software distribution package.

Though the originators of these open source programs did not design them all to work specifically with each other, the combination has become popular because of its low acquisition cost and because of the ubiquity of its components (which come bundled with most current Linux distributions). When used in combination they represent a solution stack of technologies that support application servers.

  • Very low cost compared to other technologies
  • GNU public licensing
  • LAMP available as free software
  • Best for Web applications
  • LAMP has been proven faster, more flexible, and easier than any alternative

How does LAMP Work?

LAMP is singularly focused towards Web applications. The architecture is very straightforward, as illustrated in diagram below. Linux forwards HTTP connections to Apache, which serves static content directly from the Linux kernel. Dynamic pages are forwarded by Apache to PHP, which runs the PHP code to design the page. Database queries are sent to MySQL through PHP. Administration is commonly handled through phpMyAdmin, and every major enterprise management system can manage Apache and Linux.

LAMP Architecture

http connections

Model – View – Controller (MVC Architecture)

Model-View-Controller (MVC) architecture is widely used in interactive web-based applications. This architecture divides functionality among objects involved in maintaining and presenting data to minimize the degree of coupling between them.


A security component is shown with the standard MVC architecture because it is an important component of the system that provides the ability to assert role-based access control in all modules.

  • ModelThe Model is perhaps the most important component of the system. It contains the business logic that is executed for each action defined in the controller. This logic is defined using a scripting language that allows for rapid creation of sophisticated processing schemes. It leverages an extensible library of methods that are useful in the processing of input data, accessing various data sources and assembling Business Documents or Objects from multiple data sources.
  • ViewThe View component renders the output of the model and forwards user input to the controller. For output to a web application, this means creating an HTML web page (or other type of display page format such as WAP/WML). The preferred technique for generating the output pages is Java Server Pages (JSP).
  • Controller The controller acts as the “traffic cop” in the architecture. It directs the flow of the information between the View and Model components and selects the Model activities to execute and the View pages to generate. On input, the controller interprets the data in the input request and renders it into an object that is processed by the Model. An optional data validation process is used to determine if the data conforms to pre-defined rules and reports errors if any are found. On output, the controller makes data objects (including error messages) generated by the Model available to the View segment.
    This makes it very easy to define (and change) the flow of an application. An important aspect of the architecture of the controller is that it allows an application to be broken down into modules. Each module can be developed independently and then merged together. This is an important development scalability feature of the system.
  • SecurityUser authentication and role-based access are important aspects of many web-based applications. For example, each activity implemented in the Model can optionally require that the user be logged in and possess a particular authorization level (a role) before it can be executed. In addition, access to data sources can be controlled on a function-by-function basis so a ‘creator’ can be given access to change certain tables in a database, while a ‘user’ is given access to only read these tables.
    Another component of the security system provides a single-login capability. Users may need to access data sources, such as legacy applications, that require a user ID and password that is different for different systems and likely different from the login required for the web application. Info*Integrator maintains this single-login information in a table (passwords are encrypted) and uses it when accessing an underlying application. The single-login information can be maintained in an LDAP enabled data source or a database.