Compatibilité avec toute application serveur conforme J2EE.

Développement sur base de composants (par ex. accès aux données Oracle via Entity Beans,…).

Design HTML accessible pour des profils "non-programmeur", étiquettes de données XML ajoutées par le développeur pour un comportement d'application interactive.

La gestion des droits d’accès des groupes peut être définie au niveau applicatif (modules, menus, pages, champs, tables, etc.) et/ou au niveau des données.

Antémémoire (Caching): les données du client et de l’application elle-même sont rangées dans une mémoire (cache) à l’exécution, ce qui améliore les performances et la réutilisabilité.

Traitement cohérent des exceptions pour faciliter la compréhension des problèmes et leur correction.

Centralisation de code JavaScript réutilisable pour des fonctions partagées.

Modèles pour les fonctionnalités de base (requête, navigation, liste de valeurs,…) en vue de faciliter le travail des designers / développeurs.

Mise en commun des connexions (Connection pooling) : les connexions à la base de données sont gardées en mémoire et recyclées pour être réutilisés plus tard, augmentant de la sorte les performances de la base de données.

Support du multilinguisme, au niveau applicatif et au niveau des données.

Support Thread pour les tâches parallèles.

Présentation des données de façon hiérarchique ("tree view") pour des structures de données récursives similaires à Windows Explorer, (ex: le service d’organisation, formulaires à questionnaires en arbre, etc.). Les arbres sont totalement configurables via des fichiers de configuration XML et peuvent prendre leurs données sources d’un « repository » ou d’une base de données.

Programmation de travaux pour les tâches de fond.

Authentification, droits d'accès, multilangue, navigation, gérés par un "central controller servlet".

Centralisation de l'historique d'accès des utilisateurs.

Limitation du nombre de pages JSP par application ou un outil pour maîtriser cela.

Déploiement de paramètres: facilement modifiable par l'administrateur système (DEV / TEST / PROD) à travers des fichiers de configuration ou une interface conviviale.

Téléchargement de fichiers (upload/download): Les fichiers de tous types peuvent être chargés dans la base de données, ou sur le système de fichiers du serveur, depuis les stations clients. Une zone du disque spécifique et personnelle est assignée par l’administrateur pour des raisons de sécurité.

Priorisation: permet de fixer les priorités entre les tâches de fond et les processus en ligne.

Unicode: permet la représentation de caractères et de langages spéciaux (arabe, cyrillique, etc).

Une architecture web stable et standardisée: toute nouvelle application ou module peut être intégré en douceur et avec un minimum d'effort. Cela permet d'obtenir le même look pour les écrans intranet et internet et de publier de nouveaux écrans sans aucun effort de développement.

Approche RAD (Rapid Application Development): les designers HTML peuvent rapidement produire une interface utilisateur avant de commencer à développer l'application proprement dite. Cela donne à l'utilisateur final une bonne idée du design en bout de course de l'application avant que l'analyse technique et le développement (phase d'analyse fonctionnelle) soient faits. Cela permet des changements plus faciles de l'application dans des business en constante évolution. Modules serveurs pré-existants: permettant à l'équipe de développement de se concentrer sur le développement relatif au business plutôt que sur les problèmes techniques. Réutilisation de modules côté serveur. Débogage facilité.

Réduction des coûts: pour l'infrastructure, la maintenance (impact des différents modules en relation avec la croissance du nombre d'utilisateurs).

Traitement parallèle / concurrentiel:

• Multithread: Coté serveur, chaque utilisateur obtient un environnement indépendant. La « servlet » est dupliquée et le traitement est séparé pour chaque utilisateur.
• Transactionnel : Permet (à travers un mécanisme de blocage, un traitement sans erreur ni suspension) aux utilisateurs de l’application de faire des modifications de type Ajout/Modification/Suppression sur les mêmes données en mêmes temps (blocage au niveau ligne, et non pas table).

Client léger: pas d'installation du côté client (navigateur), peu ou pas d'interaction avec une autre logiciel client.

Extensibilité: cette architecture permet de facilement modifier la taille de l'infrastructure  IT. En se préoccupant des besoins fonctionnels (business needs), cette architecture permet de changer la taille et d'aller d'un petit système vers un beaucoup plus grand, sans se faire ressentir sur l'application, la plateforme ou ses modules. 

Persistance: garder/journaliser/archiver les données importantes, par utilisateur et par session. 

En ligne/arrière-plan: permet aux utilisateurs et administrateurs de travailler en mode "en ligne" avec une réponse immédiate du système, ou de lancer des tâches et laisser le système traiter les données en arrière-plan pendant que l’utilisateur peut travailler sur d’autres tâches.

Performance: Le système assure la prise en charge des requêtes des utilisateurs, même en période de forte audience (beaucoup d’utilisateurs en parallèle, beaucoup de tâches à effectuer, une grande quantité de données dans la base de données).

Portabilité et connectivité: la plateforme permet d'être le plus portable possible d'un système informatique à un autre, permettant des changements futurs techniques d'infrastructure (système d'exploitation, serveur physique, gestionnaire applicatif serveur, etc.) sans impacter sur l'application logicielle. Cela permet également de se connecter à d'autres systèmes IT hétérogènes.

Disponibilité: : L’application développée à l’aide de cette plateforme va supporter un niveau de disponibilité très élevé, à travers les requêtes des utilisateurs durant les heures de bureau, mais également durant les autres périodes, tels que les weekends, soirées tardives ou aux aurores.

Standardisation et évolutions: Suivant la philosophie « code source libre » (open source), l’architecture permettra d’ajouter facilement des ensembles de fonctionnalités ou modules, en prenant compte les spécifications des besoins fonctionnels (business needs). Cette manière de travailler permet de penser à d’éventuelles évolutions, tout en préservant les investissements courants.

Base de données relationnelles JDBC: GID peut se connecter à toutes les bases de données relationnelles JDBC, y compris Access pour extraire des données.

Middleware: GID peut agir en tant que middleware, permettant facilement la connexion à d'autres outils, par divers moyens: fichiers csv ou XML via le système de fichiers, connexion TCP/IP, etc. La technique est la même que celle utilisée pour l'affichage des pages HTML à partir d'informations de la base de données: au lieu de consulter la base de données, il lit un fichier; au lieu d'afficher une page HTML au client, il délivre l'information à une autre application ou un autre module de GID.

Evolution: grâce à son architecture JSP, GID permet d'ajouter facilement des nouveaux "beans" ou autres modules, spécifiques au business. 

Fonctionnalités préexistantes: groupes d'utilisateurs, LDAP API, sécurité web + dossiers file system protégés, système de messages d'erreur dynamiques, système de paramétreges prédéfini permettant de régler le fonctionnement de l'application par les paramètres d'administration, etc.

Basic components
Oracle Business Components (BC4J) = java layer abstracting the access to the database, implementing the structure of the database in entities and object views, using a caching system for performance reasons. The GID developers needs to create, with Oracle Jdeveloper tool, the Business Components specific to their client database (entities for tables, object views for joined tables, etc)

Server File System = server side file system, with protected directories for security, with possible sub-directories allowed for each user (for iUpl/iDownl)


Hidden components
The following technical components of GID are used to implement some of the flows (these components are only used by GID kernel and are not manageable by GID developers):

iError_Handler (iERR) = component implemented in java classes instantiated by iCTRL and/or iCALL whan an error occurs.

Database_Connection_Pooler (iPOOL) = singleton started by iCTRL that manage the connection to the database. Each bean or java class that needs to connect to the database asks a connection to iPOOL that offer it. When a component releases a connection, iPOOL recuperate it to use it for another component requesting a connection. In the configuration file of the application server some environment parameters define to which schema (in Oracle terminology) to connect.

ISEQUENCER (iSEQ) = singleton started at initialization of iCTRL that generates sequences and counters at request.

ClassLoader (iCLASS) = java component allowing GID to be “JVM-tolerant”: GID loads its own libraries in the JVM independently from whatever other application present in the JVM, avoiding interference between different versions of the same library loaded by GID and another application.

The following main components of GID are highlighted in the diagram. These components are available to the GID developers:

IRAD_WIZARD (iRAD) = the wizard tool, implemented also in iREPO, that allow developing applications on GID platform

iREPOSITORY (iREPO) = the repository database, containing all applications developed on GID platform (html pages and their content, javascript, the java beans, etc). See the TEC-PLS-GID-iREPO document for more explanations on the iREPO structure and functioning.

iCONTROLLER (iCTRL) = the servlet of GID, receiving requests from the users browsers and forwarding the request to the concerned component (usually iCALL); this servlet checks the authorization and the access rights of the requestor.