Architecture and Technology

Design Requirements and Priorities

hipergate was designed from the very onset as a suite geared towards providing high quality service to the most demanding clients.

Ergonomics and Usability

The first priority is that the product had to provide excellent user experience. This is achieved via:
• Homogeneous information architecture throughout all the modules.
• Easy to understand conceptual model.
• Intuitive access to all functionalities.
• Quick response time for all operations.
• Availability of a complete set of features.

Functional Richness

The suite has been designed to cover 80% of the typical requirements of each functional module. Our mission is to concentrate on the horizontal expansion of the product rather than developing a few very highly specialized and complex applications.

Stability

Our suite is intended for availability 24 hours a day, 7 days a week. Each module has been thoroughly tested in several code walkthroughs, black box testing, and stress testing in critical conditions.

Scalability

During the entire development cycle, performance has never played a secondary role in relation to transportability and expansion of product functionality. The code is optimized to take advantage of specific functionality of each of the databases and platforms it runs on.

One part of the process logic uses procedures stored in PL/SQL, PL/pgSQL or Transact-SQL, which has been rewritten to take full advantage of the most advanced options available in each RDBSM.

Java code is available in 3 run modes: 100% Pure Java, Linux or Win64 and, depending on your setup, for optimum performance.

The application has three layers: web server, application server and database server. The design emphasizes on its capacity of creating farms and distributing the load over several servers.

To reduce memory consumption and enhance the service capacity of each web server, the application runs without the sessions and statuses maintained on the server side.

The suite includes a sophisticated, cache-distributed, proprietary system, whose mission it is to maintain local information on the web servers and reduce the overloading of database nodes.

Fault Tolerance

You can set up the system to cluster run on both the database and web servers.

Maintainability

The coding has been designed to enhance easy maintainability and expansion by programmer without an advanced knowledge of the system. The object model, which isolates the physical database from the business logic, provides a natural framework for adding on extensions with a very short learning curve. Many of the routine coding tasks: form generation, lookup tables, data validation, date management, etc. are already resolved in a standardized fashion in reusable components.

Multitenancy

hipergate shares information of several clients in the same database to prevent databases from growing unmanageably. Nonetheless, as a pre-requisite for providing ASP services, you must be able to retrieve clean client-specific information from the shared database at any time in order to make a backup copy for the client or for installing a dedicated instance of the database.

Cost Effectiveness

The application can run 100% on open source software to completely avoid license fees.

Standard Technology

Only standard technology and components are used. In addition, we advocate exclusive use of platforms only when explicit consent of it is given from the large enterprises in the sector.

In spite of its wide technical and functional reach, the suite has been designed and coded to be ease of use.

Internal Structure

hipergate code is made up of 5 layers:

Layer 1: JavaScript code run by the client's browser. Layer 2: JSP pages served by the servlet runner. Layer 3: Java POJO business logic model. Layer 4: Java BeanShell Scripts. Layer 5: RDBMS stored procedures.

This division is intended to enhance scalability and extensibility of the application to:

1. Reduce bandwith traffic between the browser and web server.
2. Implement a Model-View-Controller paradigm.
3. Provide an API for each of the application objects.
4. Use the maximum amount of compiled and optimized code for the system core libraries.
5. Externalize the business logic in server scripts that do not need to be compiled before being run.
6. Reduce the number of calls to the database when these operations can be run atomically from the database manager.