Design and development of corporate web applications

    Designing a corporate web application, like any other application, should start by defining the initial goals and areas of tasks. Create a register of stakeholders.

    The next step is to collect the requirements for the application that needs to be developed. Clarify the goals and scope of tasks and build a hierarchical structure of work.

    Let us consider separately the task of constructing a hierarchical structure of work. Each web application can be represented as follows:



    In other words, each web application sends http requests to the web server to obtain useful data. A program running a web server uses a particular model to store data. In the modern world, databases, SQL or NoSQL are most often used.

    Formally, each web application can be divided into 3 mutually independent parts.

1. A module that is executed by a web browser. This application can be written in any language that the browser supports. The most commonly used language is JavaScript, as the most supported and having great library support. This is very important, as it allows you to significantly save project budgets.
   
   
2. A module executed on the server side under the control of a web server. This application can be written in any language, the interpretation of which is supported by the web server of your choice. Recently, often, the Java language is chosen as the programming language. This language also has strong library support.
   
   
3. Database. There is also a fairly wide selection in this area. There are industrial databases, such as Oracle, DB2, PostgreSQL. There are lightweight databases such as MySQL. The database is selected based on the goals and areas of the tasks.

      Possible reference models for designing web applications.

    When building the architecture of a web application, it is necessary to minimize the dependence between structural units. In general, an application consists of three structural units.

1. A module that runs on a browser.
2. A module that runs on a web server.
3. Database.

These structural units give rise to two types of bonds.

1. The connection between the browser and the server side.
2. Communication between the server part and the database.

    To achieve the goal of maximum independence between structural units, it is necessary that each structural unit operates only with the data set it needs. Let's consider in more detail.

    A browser is an application software for viewing web pages.

    HTML is a standard document markup language. Most modern web browsers can interpret HTML.

    A web server is software that can receive HTTP requests from clients, process them and send a response in accordance with the protocol standard.

    A database is a collection of independent materials presented in an objective form, systematized in such a way that these materials can be found and processed using a computer. (Wiki)

                                    Minimizing Dependencies

    To minimize dependencies between the Browser and the Web server, it is necessary that the HTML markup language is used only in the browser, and the Web server provides an interface for obtaining the necessary data for the page.

    To solve this problem it is necessary:

• Define the goals and scope of the tasks to be solved within the framework of the created interface.
• Define the server side API.
• Choose the protocol of interaction between the server and client part. Creating a protocol is most conveniently chosen based on XML, since most modern browsers have built-in support for this language.
• Write a document in which the protocol will be set out.

    Our diagram can be converted into the following form:



    Next, the “Browser” is converted to a UML state diagram. These diagrams will show in which case one or another method is called.

This model is reachable in two ways.

1. The program executed by the “Browser” is written in JavaScript and communicates with the Web Server through AJAX, receiving answers in accordance with a specific protocol.
2. The "browser" only interprets HTML code, and the transformations occur through XSLT transformations on the side of the Web Server.

    In each of these cases, separation of the software part of the Web Server and the “Browser” is achieved. That is, using this model it is possible to make changes to the structural unit for the "Browser" and not cause indirect changes in the server part. This is very important because it reduces the cost of processing change requests. This is due to the fact that changes in one structural unit do not go beyond its framework.

                    Interaction of the Web Server and the Database The

    interaction of the database and the web server can be organized on the basis of two fundamentally different scenarios:

1. Business logic is in the database.
2. The business logic is in the web server code.

    In the first case, the database stores data and provides a data access interface:

1. Data sampling - is solved through representations.
2. Data modification - is solved through stored procedures.

    The program for the web server is a driver for accessing business logic. That is, it simply connects the Browser with the business logic that is implemented in the database.

    In the second case, the database stores data, and provides direct access to the data. Business logic is implemented in web server code. In this case, the database provides transactions for atomic operations.

    To minimize dependencies between the Web Server and the Database, it is necessary that the business logic be defined in only one place. That is, either in the code of the Web Server, or in the Database. This is very important because it reduces the cost of processing change requests. This is due to the fact that changes in one structural unit do not go beyond its framework.

                                Hierarchical structure of work

    Based on the above material, the hierarchical structure of the work will take the following form:

1. Module for the "Browser".
2. Module for Web Server.
3. Module for the Database.
4. The exchange protocol between the Browser module and the Web Server.
5. Interaction interface between the Browser module and the Web Server.
6. The interface between the Web Server and the Database.