» Forgot Password?
» Functional Modules
» Benefits
» Architecture
» Demo
» Manuals
» API Reference
» Case Studies
» Development Weblog
» SourceForge Tracker
» Commercial Support
» Downloads
» Find a Partner
Private Area» Authors
Architecture
| « Benefits |
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.
A series of requirements and priorities were set that the product had to strictly comply with.
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
- Simple conceptual model
- Easy access to all functionality
- Quick response time for all operations
- Availability of a complete range of operations
Functional Reach
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.
Our philosophy is to provide small and medium-size companies with practically all the functionality they require in each department and to provide a solid base to large companies so that they can later add on proprietary extensions.
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, Unix, Win32 and, depending on your setup, atomic calls to each of the operating systems to obtain 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.
Separating client-specific data
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.
Another factor is the rational use of the CPU and disk, which are considered scarce resources.
Standard Technology
Only the most market-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.
Simplicity
In spite of its wide technical and functional reach, the suite has been designed and coded for ease of use.
Languages, Components and Platforms
Java and Tomcat
All hipergate modules have been written in 100% Pure Java. This software can run on any version of the virtual machine from 1.3 to 1.5
hipergate as been tested on Tomcat 3.1.1a with Java 1.3, Tomcat 4.1.27 with Java 1.4 and Tomcat 5.5 with Java 1.5.
The web server workstation must be Linux, BSD, Solaris, AIX or Windows 2000.
Components Used under Open Source Licenses
- Jakarta Bean Scripting Framework 2.3
- Jakarta POI 2.5
- Jakarta ORO 2.0.8
- Xerces2 XML Java Parser 2.6.2
- Xalan XSLT Processor 2.6.2
- Pat Niemeyer BeanShell 2.0
- Enterprise DT Ltd Java FTP Library 1.2.2
- Jamie Jaworski DHTML Tabbed Panel
- DynAPI Cross-Browser DHTML Library 2.5
Components Used under Sun Microsystems, Inc. License
- JavaBeansTM Activation Framework 1.0.2
- JavaMailTM 1.3.2
- JavaTM Advanced Imaging 1.1.2
Other Components
- Infomentum AppletFile 3.0 (optional)
- DipuTree Java tree applet 3.0 (optional)
Supported Relational Database Management Systems
- PostgreSQL 7.3, 7.4
- Microsoft SQL Server 2000
- Oracle 9i, 10g
Internal Structure
Multilayer Design
hipergate code is made up of 5 layers:
 |
|
This division is intended to enhance scalability and extensibility of the application to:
- Validate and process a maximum number of on the client to reduce the traffic between the browser and web server.
- Differentiate the presentation layer from the iterations of objects.
- Provide an API for each of the application objects.
- Use the maximum amount of compiled and optimized code for the system core libraries.
- Externalize the business logic in server scripts that do not need to be compiled before being run.
- Reduce the number of calls to the database when these operations can be run atomically from the database manager.
State less Servers
hipergate does not use sessions or statuses maintained in the servers.
This measure ensures a reduced use of memory and enhances the scalability of the web server.
All information is maintained in session cookies stored on the client workstation.
These cookies contain a minimum of information:
- Security domain to which it is connected.
- Work area it is to which it is connected.
- Unique ID of the connected user.
- Access token of the encrypted session.
Since there are no sessions, there is no current session ID. Status information is transferred from one page to the next via GET or HTTP POST methods.
Caches
The system uses a distributed cache to locally store database information on the web server. This reduces the network traffic and load on the database.
Cache drivers ensure data consistency is maintained on sites with multiple web servers running concurrently on the same database.
Differentiating Departmental and Client Data
Many applications running in ASP mode do so by automatically duplicating data models for each of the client company running. The advantage is that it allows you to easily differentiate the data of each particular client. The disadvantage, nonetheless, is it leads to a proliferation of cloned databases that eventually becomes unmanageable after a certain number has been reached.
hipergate has chosen to follow a hybrid approach to tackle the challenge of differentiating data: one database can contain information on multiple client entities without any overlapping. Going one step further, the data and permission division can go down to the departmental level, thus enabling people in a specific group to have access to a set of data and applications that is different to that of another department.
Nonetheless, to maintain the separation of data based on client, the administrative tools contain subroutines that cut off and isolate certain client-specific information in the database as exclusive, even if this same information was previously stored in a shared database.
Domains
Conceptually, the hipergate domain is the highest unit level you can use for differentiating data. Typically, it represents a complete client entity, although it is sometimes used as a container for individual users that are not associated to any specific entity (for example, consultants who purchase a user account).
The main use of domains is to set the permission criteria for each administrator. That way, the administrator of one client entity may create new users or activate and deactivate certain applications within their domain, but he cannot view or modify the data of other client entities in different domains.
Work Areas
Each domain can contain one or more work areas. Work areas function as isolated information repositories.
Work areas usually represent functional departments within the client entity.
In any given moment, a user only view information of the work area to which he has been assigned a specific role.
For example, a salesman could be a user in the sales department and, at the same time, he could also be a guest in the technical support area. This salesperson could create new client records or generate business opportunities in the sales work area, but because of his privilege level in the support work area, he would only be able to see open incidents pending resolution and would not be able to modify any of them.
Security Model
hipergate provides a session-level, security model based on roles. This model handles the following concepts:
| Application |
The functional product as a set of interoperative applications. You can add or remove applications without affecting the rest of the system. In any given moment, a subset of these applications are available to the users, and they have a specific role in each of them, depending on the group of permissions they have been assigned. |
| User |
You can create an unlimited number of users and assign a set of roles and access IDs to them. |
| Role |
Four predefined roles are available in addition to a client entity-definable fifth one: administrator, superuser, user, guest and variable. Roles determine what the user can do in each application. So, a user can have the role of Administrator in the Personnel Directory module and the role of Guest in the Sales module. This would allow him to create new employee files, but not new client files. |
| Accounts |
An account is the same as a contract with the end client. There are 3 types of predefined accounts: the corporate account, the professional account and the system account. Corporate accounts permit an arbitrary number of users and are associated to their specific domain. Professional accounts represent individual users that cannot take advantage of the team work functionality available in the application. The system accounts are used by ISP providers that offer the service as a means of managing the domains purchased by their clients. |
| Domains |
A domain represents a set of users that independently manage themselves. Each domain has one or more administrator. |
| Work Areas |
Each domain contains one or more work areas. The work area is an entity that is used to determine what will or will not be displayed in the application. For example, suppose the client entity is a company with two branches, one in Madrid and another one in Barcelona. It is decided that the creation and management of users should be centralized through Barcelona and that the users should only be able to view the schedules and directories in their specific locations. In this case, one domain would be created for the company and a work area would be created for each of the branches. |
| Group |
Each user belongs to one or more groups. You can create an arbitrary number of groups. The groups themselves cannot assign roles to any user. You must assign a role to the group within the application and work area so that the users acquire the desired role. |
Graphical Illustration of the Security Model
| « Benefits |