Improve Foundations

Guide d'architecture
5.0.1

IMPROVE S.A. 124 rue de Verdun - 92800 PUTEAUX - Tel 01.41.97.83.20 Fax 01.41.97.83.23 Capital de 110.075 RCS NANTERRE B 380 903 229 NAF 721Z TVA FR 35 380 903 229

Improve Foundations
Guide d'architecture
Copyright 2008-2009 IMPROVE

Historique des versions

Version 0.1 03/04/2007 D. Duquenne

Cration partir du prcdent document d'architecture Version 0.2 Relecture et adaptations mineures Version 1.0 23/05/2007 F. Esnault 19/04/2007 F. Esnault

Rorganisation par rapport aux autres guides, complments Version 1.1 11/07/2007 F. Esnault

Complments avec les nouveauts de la version 4.1 du socle Version 1.2 08/08/2007 F. Esnault

Prcisions sur les nouveauts de la version 4.1 Version 1.3 Complments sur la version 4.2 d'IF Version 2.0 Modifications pour la version 5.0 d'IF Version 5.0 29/08/2008 F. Esnault 17/04/2008 F. Esnault 08/02/2008 F. Esnault

Rorganisation du document, externalisation de la partie technique dtaille Version 5.0.1 Complments pour distribution IF 5.0.1 04/03/2009 F. Esnault

Improve Foundations - Guide d'architecture - 5.0.1

ii

Guide d'architecture

1. Introduction ........................................................................................................................ 1 1.1. Prsentation du document ........................................................................................ 1 1.2. Primtre ................................................................................................................... 1 1.3. A qui sadresse ce document ? ................................................................................ 1 1.4. Pr-requis .................................................................................................................. 1 1.5. Pour aller plus loin .................................................................................................... 1 2. Objectifs .............................................................................................................................. 3 2.1. Une architecture clef-en-main ............................................................................. 3 2.2. Des principes gnraux ............................................................................................ 4 3. Architecture applicative .................................................................................................... 5 3.1. Concepts ................................................................................................................... 5 3.1.1. Caractristiques d'un service ......................................................................... 5 3.1.2. Dfinition de l'architecture oriente service .................................................... 5 3.2. Le modle multicouche ............................................................................................. 6 3.2.1. Introduction ..................................................................................................... 6 3.2.2. Les donnes physiques .................................................................................. 7 3.2.3. Le mapping et les connecteurs ...................................................................... 7 3.2.4. La couche Entreprise ..................................................................................... 8 3.2.5. La couche Application .................................................................................... 8 3.2.6. La couche Client ............................................................................................ 8 3.2.7. Exemple dutilisation du modle multicouche ................................................. 9 3.2.8. Avantages du modle multicouche ............................................................... 10 3.2.9. Inconvnients du modle multicouche ......................................................... 10 3.3. Architectures multi-tiers ........................................................................................... 11 3.3.1. Architecture Client Lger .............................................................................. 11 3.3.2. Architecture Client Riche .............................................................................. 13 3.3.3. Architecture mixte : client lger + riche ........................................................ 16 4. Implmentation Improve Foundations Core ............................................................... 19 4.1. Architecture Oriente Services ................................................................................ 19 4.1.1. Contraintes lies au concept dArchitecture Oriente Service (SOA) ........... 19 4.1.2. Principes gnraux ....................................................................................... 20 4.2. Architecture gnrale du socle ............................................................................... 20 4.2.1. Intgration de Spring .................................................................................... 21 4.2.2. Noyau et moteur bas sur Spring Core ....................................................... 22 4.2.3. Articulation entre les applications, le socle et les frameworks open source 22 ... 4.3. Compatibilits et dpendances ............................................................................... 23 4.4. Conteneur de composants ...................................................................................... 24 4.4.1. Identification des composants ..................................................................... 24 4.4.1.1. Cas des services ............................................................................... 24 4.5. Architecture logicielle, notion de couche (Layer) ..................................................... 25 4.6. Configuration ........................................................................................................... 25 4.6.1. Fichiers de configuration d'une application ................................................... 25 4.6.2. Systme de configuration centralis ............................................................. 25

Improve Foundations - Guide d'architecture - 5.0.1

iii

Guide d'architecture

Improve Foundations

4.7. Services et valves ................................................................................................... 27 4.8. Injection ................................................................................................................... 27 4.9. Gestion des vnements ........................................................................................ 27 4.9.1. Quest-ce quun vnement ? ...................................................................... 27 4.9.2. Introduire de nouveaux vnements ............................................................ 28 4.10. Gestion des connexions et des transactions ......................................................... 28 4.10.1. Connexions ................................................................................................. 28 4.10.2. Transactions ............................................................................................... 29 4.10.3. Services connects ................................................................................... 30 4.11. Contextes .............................................................................................................. 30 4.11.1. ThreadContext ............................................................................................ 30 4.11.2. ApplicationContext ...................................................................................... 30 5. Extensions ........................................................................................................................ 31 5.1. IFE-Web .................................................................................................................. 31 5.2. IFE-Errors ................................................................................................................ 31 5.3. IFE-Struts ................................................................................................................ 31 5.4. IFE-StrutsHelp ......................................................................................................... 32 5.5. IFE-StrutsLayout ...................................................................................................... 32 5.6. IFE-MultiProcess ..................................................................................................... 32 5.7. IFE-EasyWeb .......................................................................................................... 32 5.8. IFE-PortletBridge ..................................................................................................... 33 5.9. IFE-Authentication ................................................................................................... 33 5.10. IFE-Authorization ................................................................................................... 33 5.11. IFE-Hibernate ........................................................................................................ 34 5.12. IFE-JDBC .............................................................................................................. 34 5.13. IFE-FTP ................................................................................................................. 34 5.14. IFE-Mail ................................................................................................................. 34 5.15. IFE-JMS ................................................................................................................. 34 5.16. IFE-PDF ................................................................................................................. 34 5.17. IFE-JasperReports ................................................................................................. 35 5.18. IFE-RTFTemplate .................................................................................................. 35 5.19. IFE-Converter ........................................................................................................ 35 5.20. IFE-GWT ............................................................................................................... 36 5.21. IFE-RialtoGWT ...................................................................................................... 36 5.22. IFE-Flex ................................................................................................................. 36 5.23. IFE-Audit ................................................................................................................ 36 5.24. IFE-MessAdmin ..................................................................................................... 36

Improve Foundations - Guide d'architecture - 5.0.1

iv

Guide d'architecture

1. Introduction
1.1. Prsentation du document
La ralisation dun projet ncessite souvent une bonne adquation entre larchitecture applicative dune part et larchitecture technique dautre part. Mais le succs dun tel projet ncessite surtout la matrise de la complexit technologique. Il est en effet de plus en plus rare que les fondations dun projet informatique reposent sur un seul et unique produit. Elles sont, au contraire, constitues dune collection de technologies provenant de sources diverses. Cette diversit impacte de fait le niveau de comptences requis pour la ralisation de tels projets. Il est alors conseill de grer cette complexit en intgrant toutes ces technologies au sein dun socle technique : sorte de bote outils proposant une architecture, des services techniques et une mthodologie de dveloppement prts lemploi. Ce document prsente larchitecture gnrale et les services proposs par le socle technique Improve Foundations.

1.2. Primtre
Le prsent document concerne Improve Foundations version 5 et ne s'applique donc pas aux versions prcdentes. Notons toutefois que pour l'essentiel, cette version partage les principes de la version 4. Pour savoir prcisment ce qui distingue ces versions, il est recommand de consulter le guide de migration.

1.3. A qui sadresse ce document ?

Ce document constitue une bonne introduction technique Improve Foundations et sadresse aux personnes qui veulent comprendre l'organisation et les principes de fonctionnement sans entrer dans les dtails de mise en oeuvre.

1.4. Pr-requis
Afin de comprendre ce document, des comptences en architecture, en XML, en programmation oriente objet et en Java sont ncessaires.

1.5. Pour aller plus loin

Ce document fait un tour d'horizon de l'architecture et des mcanismes gnraux du socle technique. Sa lecture pourra tre complte par celle :

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

1. Introduction

de la documentation technique d'IF-Core, qui apporte les dtails concrets permettant de mettre en oeuvre les fonctions du noyau, de la documentation technique de chacune des extensions, qui en prsente les apports et l'utilisation, du guide de conception, pour approfondir la dmarche de conception d'applications avec Improve Foundations, du guide de dveloppement, qui prsente des bonnes pratiques concernant l'utilisation du socle par un dveloppeur,

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

2. Objectifs
2.1. Une architecture clef-en-main
Larchitecture applicative propose par Improve Foundations, pour le dveloppement des applications de gestion, a pour objectifs de: diffrencier les composants fonctionnels des services techniques, assurer un couplage lche entre les composants fonctionnels, garantir que la phase de dveloppement naura pas dimpact sur les modles UML produits lors de la phase de conception, garantir un bon niveau de rutilisabilit des composants fonctionnels et des services techniques, garantir un bon niveau dvolutivit des composants fonctionnels et des services techniques, garantir une bonne maintenabilit des composants fonctionnels et des services techniques, garantir la scurit, le code dun composant fonctionnels ne devant pas altrer la scurit de lapplication, garantir labsence de code consommateur de ressources CPU ou mmoire, faciliter le dveloppement des applications en saffranchissant des concepts volus de la programmation oriente objets, faciliter lintgration dans lapplication de nouveaux services fonctionnels, faciliter lintgration dans lapplication de nouveaux services techniques, faciliter le dveloppement des applications en se concentrant sur les aspects fonctionnels, permettre le dveloppement itratif des applications, garantir lacidit des traitements (Atomicity, Consistency, Isolation, Durability), prendre en compte le cycle de mise en production dune application : dveloppement, intgration, recette, pr-production, production, prendre en compte les principes dintgration continue, prendre en compte le dveloppement dapplications orient tests unitaires, centraliser les aspects configuration de lapplication.

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

2. Objectifs

2.2. Des principes gnraux

Les principes gnraux suivants ont ts retenus: Les dveloppements fonctionnels sont raliss en Java. Une application sera hberge dans une application Web (WebApp). Larchitecture technique nimpose pas de couche graphique, celle-ci pourra tre de type client lger ou client riche. Le socle technique ne laisse la charge des dveloppeurs que les parties purement fonctionnelles. Il fournit les outils et services permettant aux dveloppeurs de se concentrer sur les parties spcifiques au mtier. Les contrles de surface sont raliss ct client et ct serveur. Les contrles de rgles mtier plus complexes (inter-champs) sont raliss ct serveur. Les applications peuvent tre dcoupes en un nombre variable de couches. Les applications suivent les concepts dArchitecture Oriente Services (SOA = Service Oriented Architecture). Utilisation systmatique des Interfaces pour les composants de type service c'est dire d'APIs de service clairement dfinies. Une application peut tre dcrite par la liste des services fournis (Nom du service, Interface, Implmentation, Couche) Gestion des transactions Une interaction utilisateur ne doit pas verrouiller de ressources au-del de la requte HTTP ou au del de tout autre type de demandes. Pour cela, le socle Improve Foundations intgre un mcanisme de gestion des transactions. Gestion des contextes Le socle technique fournit un ensemble de services permettant la gestion des diffrents contextes.

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative
3.1. Concepts
Improve Foundations adopte une architecture oriente services. Le concept d'architecture oriente services, comme son nom l'indique, s'appuie sur la notion de service.

3.1.1. Caractristiques d'un service

Un service est un traitement rutilisable. Il est compos dune interface dappel clairement dfinie et dune implmentation.

Figure 3.1. Interface et implmentation d'un service

Linterface dfinit le nom du service avec les donnes en entre et les donnes en sortie sous la forme d'une Interface Java Le composant dsigne l'implmentation concrte du service sous la forme d'une classe Java.

3.1.2. Dfinition de l'architecture oriente service

L'architecture oriente service est une infrastructure qui permet de mettre en uvre des services. Les apports de l'utilisation d'une telle architecture sont: Une facilit rutiliser des traitements au sein d'une mme application ou entre plusieurs applications. Une meilleure interoprabilit entre les diffrents constituants (composants, services, connecteurs...) des applications qu'ils soient techniques ou fonctionnels, et quelles que soient les technologies mises en oeuvre. Une meilleure description des applications (cartographie fonctionnelle aise).

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative

Figure 3.2. Schmatisation d'un socle technique

3.2. Le modle multicouche

3.2.1. Introduction
Afin d'assurer sa productivit, sa rutilisation et sa maintenabilit, une application base sur les technologies objet requiert la dfinition dune architecture logique. Cette architecture organise les interactions entre objets et dfinit la rpartition des diffrents composants dans lapplication. On a l'habitude de regrouper les objets en classes, les classes en domaines, et les domaines en couches. Les couches permettent de prsenter l'architecture applicative de l'application. Les quipes de ralisation s'attribuent des responsabilits sur le dveloppement de chaque couche. Aussi, si modliser est indispensable, la construction dune architecture couches est un critre de qualit dans le cadre d'un dveloppement objet. Le modle multicouche propose une architecture en cinq couches qui isole les aspects transactionnels dun systme dinformation des aspects fonctionnels dune application et des contraintes lies la technologie cliente. Ce modle ne sapplique pas toutes les situations, en particulier pour les applications non prennes ou ponctuelles, mais il permet de qualifier une application en terme de rutilisation, de maintenabilit et dvolution. Le modle propos est compos de cinq couches : les donnes physiques, le mapping des donnes et les connecteurs, les composants entreprise, lapplication et le client. La figure suivante prsente les interactions possibles entre les diffrentes couches :

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative

Figure 3.3. Architecture en couche

3.2.2. Les donnes physiques

De manire gnrale la couche de donnes physiques correspond la prsentation physique des donnes (SGBD, annuaire LDAP,). Elle est issue, dans le cas de stockage des donnes dans une base relationnelle, dun script SQL de cration de base. Dans le cas des systmes centraux, elle peut tre reprsente par des messages MQ, des transactions Tuxedo ou tout autre connecteur ad-hoc.

3.2.3. Le mapping et les connecteurs

Cette couche provient le plus souvent dun outil et est gnre automatiquement par celui-ci. Dans le cas dune base relationnelle, elle permet de faire le mapping relationnel/objet. Des outils comme Hibernate, iBatis SQLMaps, TopLink ou XIC de XCalia permettent de gnrer cette couche. Afin dviter tout problme lors de la rgnration de cette couche par loutil de mapping, les objets gnrs qui composent cette couche ne doivent en aucun cas tre modifis.

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative

3.2.4. La couche Entreprise

La couche entreprise propose des services d'accs aux donnes du systme dinformation au travers de mthodes de cration, de recherche, de modification et de suppression. Ces mthodes contiennent les rgles de gestion associes aux diffrentes oprations. La couche entreprise est constitue de services Entreprise qui exposent les traitements quelle peut raliser sur les donnes du systme dinformation et de composants Entreprise qui reprsentent limplmentation de ces services. Les composants de la couche entreprise accdent aux donnes via la couche mapping/connecteurs, si elle existe. Les composants entreprise garantissent lintgrit des donnes du systme dinformation. Si des donnes non-intgres sont trouves dans le systme dinformation, la responsabilit incombe cette couche. La couche entreprise effectue donc un ensemble de vrifications, et ne permet pas la transmission de donnes non-cohrentes. Les donnes transmises la couche entreprise par la couche application doivent tre intgres. Si elles ne le sont pas, la couche application nest pas conforme et doit tre corrige.

3.2.5. La couche Application

La couche application regroupe la logique fonctionnelle d'une application (rgles mtier), telle qu'elle est dfinie dans les spcifications fonctionnelles dtailles. La couche application utilise les services de la couche entreprise pour raliser le fonctionnel spcifi, et prsente ce fonctionnel sous la forme de services. La couche application est constitue de services Application qui exposent les traitements fonctionnels quelle peut raliser et de composants Application qui reprsentent limplmentation de ces services.

3.2.6. La couche Client

La couche client reprsente l'interface utilise par lutilisateur pour accder lapplication. Parce que la couche application regroupe les rgles fonctionnelles, il est possible de faire voluer les IHM moindre cot. Le client peut aussi tre un partenaire de type entreprise (B2B) naccdant pas lapplication par son IHM mais par dautres protocoles. La couche client comporte en gnral deux aspects : la prsentation et la navigation.

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative

3.2.7. Exemple dutilisation du modle multicouche

Figure 3.4. Architecture en couche

La couche physique reprsente la base de donnes. Cette couche est ici reprsente par une classe (mme si dans des cas concrets, il n'y a pas forcment de code Java correspondant, il s'agit typiquement d'une table en base de donnes). La couche Entreprise reprsente la vision Java de la base de donnes. Cette couche comporte deux classes. Une classe encapsulant le service et une classe encapsulant les donnes d'un contrat. On peut noter que l'ensemble des informations remontes de la base de donnes est rendu visible par la couche entreprise. Deux applications accdent au service entreprise, l'application de facturation qui va donner une vue sur le contrat correspondant son besoin fonctionnel. Mme chose pour l'application de gestion des sinistres. Les couches clients ne sont pas reprsentes sur le diagramme. La couche client de l'application de facturation ne peut accder qu'aux informations fournies par la couche application correspondante. Il en est de mme pour la couche de gestion des sinistres.

Improve Foundations - Guide d'architecture - 5.0.1

Guide d'architecture

3. Architecture applicative

3.2.8. Avantages du modle multicouche

L'architecture 5 couches prsente prcdemment permet de dcomposer le systme en sous-systmes. Chacun de ces sous-systmes peut tre modlis de faon indpendante, et il est possible d'affecter des responsabilits aux intervenants du projet sur telle ou telle couche (analyse / implmentation). Chaque couche est dveloppe et teste de faon individuelle. Le modle multicouche propose un cadre de conception systmatique, qui vise l'industrialisation de la production de logiciels. Dans ce modle d'architecture, la couche Application est non seulement indpendante de la couche Client, mais elle repose aussi sur une couche Entreprise normalise. Les aspects transactionnels et interactifs sont compltement dtachs du fonctionnel, au bnfice de la maintenabilit et de l'volutivit. Le modle multicouche propose un cadre de conception systmatique, garantissant des hauts niveaux : d'volutivit, en dissociant le fonctionnel du transactionnel, de maintenabilit, en attribuant des responsabilits par couche, et de rutilisabilit, en assurant un faible couplage entre les couches. L'architecture 5 couches permet de reporter les spcificits lies telle ou telle technologie au niveau de l'implmentation des services des couches "Application" et "Entreprise". Cette gnricit permet au modle multicouche d'adresser des dveloppements Client / Serveur aussi bien que J2EE (EJB et servlets / JSP). L'architecture 5 couches est une architecture oriente service (SOA, Service Oriented Architecture).

3.2.9. Inconvnients du modle multicouche

Les dtracteurs du modle multicouche lui reprochent dengendrer un surcot de documentation, de ralisation, de performances, et de produits : Surcot documentaire : chaque couche est indpendante, et demande donc une documentation qui dfinit ses interfaces avec les autres couches. Surcot de ralisation : pour un service ou une fonctionnalit, il faut impacter plusieurs couches, et coder plusieurs lments (ventuellement par des personnes diffrentes). Surcot de performances : avant de pouvoir tre traite, une requte utilisateur doit traverser plusieurs couches, ceci peut amener un surcot de performances. Dans certains cas il est prfrable de simplifier cette architecture pour plus defficacit en prvoyant par exemple des

Improve Foundations - Guide d'architecture - 5.0.1

10

Guide d'architecture

3. Architecture applicative

services entreprise ddis une application. Toutefois, dans la grande majorit des cas, ce surcot apparatra ngligeable par rapport aux temps d'excution globaux. Surcot des outils : un outil utilis pour la ralisation d'une couche propose un ensemble de services qui ne seront pas utiliss, du fait de l'architecture multicouche. Par exemple, un SGBD comme Oracle permet de mettre en place des triggers, des procdures stockes, des rollbacks, des conditions sur l'attribution des indexations. Ses services sont inutiles dans une architecture multicouche, car ils sont assurs par la couche entreprise.

3.3. Architectures multi-tiers

Voici diffrentes propositions darchitecture pour les applications : Architecture Client Lger Architecture Client Riche Architecture Client Mixte

3.3.1. Architecture Client Lger

Figure 3.5. Architecture physique client lger

Client lger: poste disposant dun navigateur Web. La partie graphique de lapplication est envoye vers le poste client par la couche cliente situe sur le serveur dapplications (en gnral du HTML). Serveur dapplications: plate-forme dexcution J2EE

Improve Foundations - Guide d'architecture - 5.0.1

11

Guide d'architecture

3. Architecture applicative

Figure 3.6. Architecture logicielle/applicative

Dans ce cadre, la couche cliente peut typiquement reposer sur les frameworks Struts et Struts-Layout. Des alternatives sont possibles, bases sur les technologies Servlet/JSP de J2EE. Toutes les couches sont situes au niveau du serveur dapplications. Avantages: Le poste client de lutilisateur ncessite seulement un navigateur Internet de type Internet Explorer ou Mozilla Firefox. Seul le serveur dapplications (et ventuellement la base de donnes) seront impacts par des mises jour des applications. Tout est centralis sur le serveur. Le poste client ne fera pas lobjet de modifications. Larchitecture sappuie sur J2EE (Java 2 Enterprise Edition) de Sun Microsystems. Cest le standard du monde Java. Les comptences J2EE sont largement rpandues sur le march. Les applications seront facilement supervisables car elles sont rassembles au mme endroit, sur le serveur dapplications. De plus grce une architecture en couche, il est simple didentifier un problme :
Improve Foundations - Guide d'architecture - 5.0.1 12

Guide d'architecture

3. Architecture applicative

problme daffichage => couche cliente problme fonctionnel => couche application donnes incohrentes dans la base de donnes : couche entreprise Inconvnients: Le serveur est charg d'excuter la totalit des traitements, prparation de l'affichage compris (exception faite de quelques traitements de surface raliss en javascript). Les clients lgers nintgrent pas de composants de type diteur comme Word ou de tableur de type Excel. La plupart des actions de l'utilisateur sont traites par un aller-retour entre le poste client et le serveur (temps de latence) et l'ensemble de la page doit tre rendu chaque fois. Le flux HTML consomme de la bande passante : HTML, images, javascript, AJAX La technologie appele AJAX tente de pallier ces inconvnients en proposant une IHM plus volue et en abandonnant la ncessit de recharger toute la page chaque interaction. On s'approche alors d'une solution dite de client riche bien que l'application s'excute toujours dans un navigateur Web.

3.3.2. Architecture Client Riche

Figure 3.7. Architecture physique

Improve Foundations - Guide d'architecture - 5.0.1

13

Guide d'architecture

3. Architecture applicative

Figure 3.8. Architecture logicielle/applicative

L'IHM des applications est totalement prise en charge par le poste de l'utilisateur selon une ergonomie dite riche, proche de celle des outils de bureautique. Dans le monde Java, il existe trois familles majeures de composants pour construire linterface graphique : AWT (Abstract Window Toolkit, http://java.sun.com/products/jdk/awt) : premire bibliothque disponible dans le monde Java, fournie en standard. Elle contient seulement des composants graphiques de base : bouton, champs de texte, liste, menu, table Bien sr il est possible de personnaliser ou crer des composants mais dans une certaine limite. Swing ou JFC (Java Foundation Classes, http://java.sun.com/products/jfc) : bibliothque de deuxime gnration galement fournie en standard. Elle contient des composants volus en plus des composants de base : arbre, onglet, bote de dialogue prdfini, systme de multi fentrage, Tous les composants sont hautement personnalisables, le modle sous-jacent tant complexe cela peut demander beaucoup de temps. SWT (Standard Widget Toolkit, http://www.eclipse.org [http://www.eclipse.org/]) : bibliothque issue du projet Open Source Eclipse, sert de base la plate-forme Eclipse RCP. Proche des fonctionnalits de Swing, elle est rpute plus rapide mais comporte certaines limitations. Avantages:

Improve Foundations - Guide d'architecture - 5.0.1

14

Guide d'architecture

3. Architecture applicative

Sur la couche client dun client riche ou lourd, AWT et Swing sont aussi des standard de J2SE (Java 2 Standard Edition). Tous les crans peuvent tre envisags grce aux bibliothques de composants (AWT/SWT/Swing). Seuls les changes de donnes circulent sur le rseau. La supervision du fonctionnement des applications reste aise car le serveur dapplications centralise les traitements fonctionnels significatifs (services). Cest un bon compromis entre le client lourd et le client lger, cest la tendance du march. Inconvnients: Le poste client nest pas banalis pour les applications client riche. Il faudra installer une machine virtuelle java. Celle-ci est consommatrice de mmoire, lutilisateur devra se limiter quelques applications simultanment. Lors de mise jour de lapplication, cela ncessite de dployer lapplication sur chaque poste client. Le monde Java nintgre pas des composants de type diteur comme Word ou de tableur de type Excel. Pour la partie riche, quel que soit la bibliothque de composants choisie, il faut investir du temps afin den matriser totalement tous les aspects. Les comptences sur ces bibliothques se sont pas rpandues sur le march.

Improve Foundations - Guide d'architecture - 5.0.1

15

Guide d'architecture

3. Architecture applicative

3.3.3. Architecture mixte : client lger + riche

Figure 3.9. Architecture physique

Client riche: sur le poste client se trouve toute la couche cliente. Elle accde la partie fonctionnelle en communiquant avec le serveur dapplications via des messages.

Improve Foundations - Guide d'architecture - 5.0.1

16

Guide d'architecture

3. Architecture applicative

Figure 3.10. Architecture logicielle/applicative

La couche cliente peut tre scinde en deux parties : pour une ergonomie simple, un client lger est utilis. pour une ergonomie complexe, une couche cliente est dploye sur le poste de lutilisateur Avantages: Larchitecture sappuie sur J2EE (Java 2 Enterprise Edition) de Sun Microsystem. Tous les crans peuvent tre envisags grce aux bibliothques de composants (AWT/SWT/Swing) et pour les crans simples le client lger peut tre choisi. La supervision du fonctionnement des applications est aise car le serveur dapplications centralise tout. Voir aussi les avantages de la partie client lger de la premire architecture. Inconvnients: Le poste client nest pas banalis pour les applications client riche. Il faudra installer une machine virtuelle java. Celle-ci est consommatrice de mmoire, lutilisateur devra se limiter quelques applications simultanment.

Improve Foundations - Guide d'architecture - 5.0.1

17

Guide d'architecture

3. Architecture applicative

Pour la partie riche, quelle que soit la bibliothque de composants choisie, il faut investir du temps afin den matriser tous les aspects. Les comptences sur ces bibliothques ne sont pas rpandues sur le march. Avec un mixte de ces deux types de clients, lhomognit de lergonomie des applications ne sera pas assure. Le monde Java nintgre pas (par dfaut) des composants de type diteur comme Word ou de tableur de type Excel. Voir les inconvnients pour la partie client lger de la premire architecture.

Improve Foundations - Guide d'architecture - 5.0.1

18

Guide d'architecture

4. Implmentation Improve Foundations Core

4.1. Architecture Oriente Services
4.1.1. Contraintes lies au concept dArchitecture Oriente Service (SOA)
Improve Foundations Core est un cadre de dveloppement qui permet des dveloppeurs qui ne sont pas des experts de dvelopper rapidement, maintenir et faire voluer des applications J2EE complexes en se concentrant sur les aspects fonctionnels du dveloppement. De mme, les architectes techniques sont capables de faire voluer ou d'enrichir l'architecture mise en place sans impact sur le fonctionnement des applications. Selon les principes prsents prcdemment, Improve Foundations Core s'appuie sur une architecture dcouplant les diffrentes couches d'une application J2EE : la couche de prsentation/navigation, la couche de logique applicative, la couche de persistance et propose une couche verticale de services techniques. Les capacits d'volution du Foundations Core sont obtenues en associant des patrons de conception reconnus dans le monde du logiciel (GOF mais aussi Contexte de Thread, Pipeline, Valve, Moteur vnementiel) un mcanisme central de configuration. Enfin, Foundations Core structure et homognise les applications produites en dfinissant des mthodes systmatiques de conception et de dveloppement.

Improve Foundations - Guide d'architecture - 5.0.1

19

Guide d'architecture

4. Implmentation Improve Foundations Core

4.1.2. Principes gnraux

Figure 4.1. Architecture gnrale d'une application base sur le socle (vue densemble) - En gris : le socle - En jaune : les extensions du socle - En blanc : les dveloppements fonctionnels

4.2. Architecture gnrale du socle

Le socle se compose d'un noyau, Improve Foundations Core et d'extensions dont le nom est prfix par IFE . Il n'y a pas de mcanisme particulier qui gre la relation entre le noyau et les extensions. Il s'agit simplement d'un dcoupage logique du code et des bibliothques correspondantes. Cela signifie que la prsence et l'activation d'une extension n'est pas particulirement connue du noyau. L'ajout d'une extension se fait seulement en intgrant au classpath le jar correspondant et par configuration au cas par cas des lments apports par celle-ci (valves, listeners, services...).

Improve Foundations - Guide d'architecture - 5.0.1

20

Guide d'architecture

4. Implmentation Improve Foundations Core

4.2.1. Intgration de Spring

La version 5.0 d'Improve Foundations (IF) est le fruit d'une refonte du socle technique sur les possibilits offertes par le framework Spring. Ce choix permet de s'appuyer sur un certain nombre de mcanismes prouvs de Spring et d'augmenter le potentiel du socle en bnficiant de la puissance de ce framework et des apports de sa communaut. Ce changement tant fondamental, il a t l'occasion de revoir certains aspects du fonctionnement du socle, en particulier au niveau de son noyau.

Globalement, les grandes fonctions proposes par Improve Foundations v5 restent les mmes que celles des versions 4.x. L'utilisation de la version 5 du socle ne s'avre pas trs diffrente pour un dveloppeur par rapport celle de la version 4, afin de minimiser l'effort de formation sur cette nouvelle version et de faciliter la migration d'applications dj produites avec IF v4. A cet effet, Improve Foundations version 5.0 : continue exposer son API et son systme de configuration propre, permet de reprendre facilement les extensions de la version 4 (mme si une migration est ncessaire) masque l'utilisation sous-jacente de Spring, sans pour autant interdire son utilisation directe par l'application. Cette version est le rsultat d'une premire tape d'une dmarche plus long terme qui vise autant intgrer un plus grand nombre de possibilits de Spring Framework (notamment sous forme de nouvelles extensions) qu' envisager la possibilit de faire reposer le noyau de IF sur diffrentes solutions alternatives dont Spring Core ne serait qu'un choix parmi d'autres (en particulier d'autres conteneurs IoC pourraient venir le remplacer si un tel composant devient un standard JSR). Dans cette optique, l'articulation entre Improve Foundations et Spring Framework a t particulirement soigne mme si la possibilit d'utiliser une alternative Spring Core ne fait pas partie des possibilits prtes l'emploi dans la version 5.

Improve Foundations - Guide d'architecture - 5.0.1

21

Guide d'architecture

4. Implmentation Improve Foundations Core

4.2.2. Noyau et moteur bas sur Spring Core

Dans la version 5, le noyau IF-Core considre donc Spring Core comme une couche de bas niveau sur laquelle s'appuyer. IF-Core demeure le noyau de IF vu des usages extrieurs mais Spring Core devient son moteur. IF-Core se compose donc concrtement de 2 parties : le noyau principal (IFC) et le moteur. Dans la version 5, l'implmentation du moteur disponible est IFC-Spring. Il faut noter qu'IFC n'a aucune dpendance vis--vis de Spring. Ce dcoupage permet d'envisager d'autres implmentations du moteur mais dans son tat actuel, le noyau ne propose pas la fonctionnalit complte qui permettrait de s'affranchir de Spring. Une application reposant sur Improve Foundations doit donc intgrer son classpath les modules IFC et IFC-Spring.

4.2.3. Articulation entre les applications, le socle et les frameworks open source
Le schma suivant rcapitule les articulations entre les applications, Improve Foundations version 5 et Spring :

Improve Foundations - Guide d'architecture - 5.0.1

22

Guide d'architecture

4. Implmentation Improve Foundations Core

1. Les applications reposent sur IF-Core 2. IF-Core utilise Spring Core comme moteur 3. Les applications utilisent des extensions Improve Foundations 4. Une extension Improve Foundations repose sur IF-Core 5. Une extension Improve Foundations implmente ses fonctionnalits sur un ou plusieurs frameworks et/ou des fonctionnalits de modules Spring 6. Les applications peuvent utiliser nativement les modules de Spring ou tout autre framework (techniquement possible mais hors du primtre de support d'IF)

4.3. Compatibilits et dpendances

La version 5.0 d'Improve Foundations est compatible et supporte avec : le JDK 1.4 et J2EE 1.4 le JDK 1.5 et JEE 5 Elle peut fonctionner avec d'autres JDK et versions de J2EE, mais ces configurations ne sont pas supportes contractuellement par Improve. Les versions les plus rcentes des bibliothques open source ont t intgres dans la mesure o elles restaient compatibles avec l'ensemble des exigences et des contraintes techniques (c.f. la documentation des extensions) Pour ce qui concerne Spring Framework, c'est la version 2.5 qui est utilise.

Improve Foundations - Guide d'architecture - 5.0.1

23

Guide d'architecture

4. Implmentation Improve Foundations Core

4.4. Conteneur de composants

Improve Foundations Core est un conteneur de composants. Le terme composant , dsigne ici un lment logiciel typ constitutif d'une ou plusieurs applications. Diffrents types de composants sont reconnus par IF-Core. Dans cette catgorie, on peut distinguer des composants purement techniques et d'autres qui ont une orientation fonctionnelle. Voici les principaux : layer : reprsentation d'une couche service : composant qui peut tre invoqu depuis une autre couche pour raliser un traitement significatif (fonctionnel ou technique) valve : composant qui ajoute un comportement avant et/ou aprs les appels de service sans tre invoqu explicitement listener : composant qui ragit des vnements initializer : composant qui ralise un travail au dmarrage du socle bean : simple JavaBean, surtout utilis pour factoriser une configuration connection factory : fournisseur de connexions pour les accs aux donnes Le premier rle d'IF-Core est de contrler le cycle de vie et en particulier l'instanciation et le rfrencement de ces composants. L'instanciation des autres lments du systme n'est pas de la responsabilit d'IF-Core (par exemple, des objets correspondant des entits mtier ne sont pas jusqu' prsent considrs comme des composants bien qu'ils pourraient l'tre et leur instanciation est la charge du dveloppeur ou d'une solution de mapping objet-relationnel). Depuis la version 4.1 d'Improve Foundations, la notion de bean est venue s'ajouter la liste des composants grs par le noyau. Ceci a ouvert la voie l'injection de dpendance pour des usages ouverts.

4.4.1. Identification des composants

L'identification des composants au sein d'un conteneur est base sur la notion de nom . Ainsi tout composant accepte un attribut name dans sa configuration en XML, ce qui permet de prciser un identifiant sous forme de chane de caractres quelconque, pour peu qu'elle soit unique au sein de la couche. L'usage de l'attribut name n'est pas rendu obligatoire afin de rester compatible avec le format des versions prcdentes du socle. Si celui-ci n'est pas renseign dans la configuration, le nom du composant sera cr implicitement.

4.4.1.1. Cas des services

Pour un service, le nom utilis par dfaut est celui de l'interface d'abstraction (lorsque name n'est pas renseign) , comportement des versions antrieures d'Improve Foundations. L'API

Improve Foundations - Guide d'architecture - 5.0.1

24

Guide d'architecture

4. Implmentation Improve Foundations Core

Java propose ainsi 2 signatures de la mthode getService(), l'une acceptant l'interface Java en paramtre (Class), l'autre attendant le nom de type String. Notons que le support de l'attribut name apporte ici une souplesse qui n'est utile que sur des cas spcifiques. Comme cet attribut apporte aussi une complexit et un risque d'erreur supplmentaires, son usage n'est pas la prconisation par dfaut. On prfrera notamment continuer identifier les services par leur interface d'abstraction, ce qui est plus simple et plus sr dans la plupart des cas.

4.5. Architecture logicielle, notion de couche (Layer)

Conformment aux choix prsents prcdemment, Improve Foundations Core apporte la notion de couche (Layer). Une couche correspond un ensemble de composants regroups en tant que brique d'architecture logicielle. Tout composant au sens du socle appartient donc une couche et une seule. Parmi les couches, la couche appele Foundation rassemble les composants techniques utilisables de manire transverse. Cette couche est initialise la premire et est considre comme parente des autres. Le socle considre que l'architecture d'une application est par dfaut constitue des couches enterprise , application et client (en plus de Foundation ). Il est nanmoins possible de constituer autant de couches que souhait et leur nom peut aussi tre choisi librement.

4.6. Configuration
4.6.1. Fichiers de configuration d'une application
Une application base sur le socle Improve Foundations est configure par des fichiers XML qui interviennent diffrents niveaux : foundation.xml : dclaration des services techniques (qui peuvent tre transversaux aux couches fonctionnelles) clientLayer.xml, applicationLayer.xml, enterpriseLayer.xml : dclaration des services fonctionnels et valves spcifiques chacune des couches respectives environment.xml : fichier de centralisation des paramtres les plus variables (variables d'environnement) D'autres fichiers de configuration peuvent aussi intervenir selon l'architecture et les extensions choisies (web.xml, struts-config.xml, hibernate.cfg.xml).

4.6.2. Systme de configuration centralis

Le systme central de configuration mis en place dans le socle permet de dclarer lensemble des composants du systme et de dfinir leurs paramtres de fonctionnement en sappuyant

Improve Foundations - Guide d'architecture - 5.0.1

25

Guide d'architecture

4. Implmentation Improve Foundations Core

sur le fichier denvironnement contenant les paramtres les plus variants du systme (noms de serveur, logins, passwords, emplacement des logs...). Ce systme s'appuie sur un moteur de transformation XSLT qui permet dintgrer les valeurs des variables d'environnement dans tous les fichiers XML concerns. Ce choix d'implmentation offre une grande souplesse qui permet d'envisager de vritables transformations de la configuration en fonction de l'environnement. En consquence, les fichiers de configuration sont en ralit des fichiers XSL mme si la connaissance de ce format par le dveloppeur n'est gnralement pas utile.

Figure 4.2. Les fichiers de configuration de lapplication sont construits en sappuyant sur une dfinition de lenvironnement.

D'une manire gnrale, les composants dcrits dans les fichiers de configuration du socle (services, valves, listeners...) sont instancis par le noyau partir de la configuration en XML. Un paramtrage en XML peut tre ajout la dclaration d'un composant. Celui-ci peut tre exploit de diffrentes manires : par injection, les paramtres en XML tant implicitement mapps vers des proprits Java sur le composant, par initialisation explicite si le composant implmente linterface Initializable. L'injection est applique par dfaut sur les composants. Pour qu'elle fonctionne, certaines rgles doivent toutefois tre respectes. Dans le second cas, l'injection est dsactive, ce qui offre plus

Improve Foundations - Guide d'architecture - 5.0.1

26

Guide d'architecture

4. Implmentation Improve Foundations Core

de souplesse mais oblige le dveloppeur dcrire explicitement la rcupration et l'exploitation de la configuration.

4.7. Services et valves

Les services constituent le coeur fonctionnel des applications puisqu'ils portent les traitements. Ils sont systmatiquement dfinis sous forme d'interfaces pour lesquelles on apporte des implmentations. L'ensemble doit tre dclar en XML au niveau de la configuration de la couche concerne. Les valves, qui s'appuient sur des mcanismes d'AOP, viennent apporter des traitements "priphriques" l'excution des services. Une valve peut en effet raliser un travail avant et/ou aprs l'excution d'un service sans que le code du service lui-mme ni le code d'invocation de celui-ci en soient impacts. Le dclenchement de ces valves se fait par configuration. Ce mcanisme est notamment utile pour mettre en place des traitements "transversaux" caractre plutt technique comme par exemple les traces ou les vrifications relatives la scurit. Il faut noter que par dfaut, une valve est active sur tous les services d'une couche mais il est possible de dfinir des filtres pour prciser l'activation sur un sous-ensemble de services

4.8. Injection
L'injection est un mcanisme activ par dfaut sur les composants. Il permet ceux-ci de recevoir implicitement un paramtrage partir de la configuration en XML. Il est ainsi possible d'injecter de valeurs simples ou des rfrences vers d'autres composants comme de simples beans ou des services (injection de dpendance). Le systme supporte ce niveau les valeurs multiples (tableaux ou listes) et les beans imbriqus (nested beans). Il faut noter que contrairement des frameworks comme Spring qui gnralisent l'injection de dpendance, Improve Foundations propose cette possibilit sans volont d'en faire une rgle incontournable. L'IoC outrance peut en effet apporter une complexit qui est contre-productive et risque d'erreurs.

4.9. Gestion des vnements

4.9.1. Quest-ce quun vnement ?
Vous tes en train de quitter votre appartement pour partir au travail. Le tlphone se met sonner . Ceci est un vnement. Un vnement est une circonstance qui ncessite linterruption du travail qui est en train dtre ralis. Cette problmatique existe dans la vie courante elle se rencontre aussi dans les

Improve Foundations - Guide d'architecture - 5.0.1

27

Guide d'architecture

4. Implmentation Improve Foundations Core

applications java. IMPROVE Foundations intgre un gestionnaire dvnements qui permet un objet (Event Source) de dclencher un vnement et dautres objets (Listener) de les couter.

Figure 4.3. Dclenchement dun vnement

Exemple dvnements qui peuvent tre dclenchs : cration dune session utilisateur, destruction dune session utilisateur, lexcution dun service technique ou fonctionnel vient dtre demande, lexcution dun service fonctionnel chou, lexcution dun batch vient de se terminer

4.9.2. Introduire de nouveaux vnements

Le socle permet dintroduire de nouveaux vnements ainsi que des listeners spcialiss. Dans la pratique, les valves sont frquemment la source des vnements techniques mais des vnements fonctionnels peuvent aussi tre introduits. Il est ainsi possible : de crer un nouveau type d'vnements de dclencher ce type d'vnements sur une couche, tout endroit du code de crer une interface de listener associ de proposer des implmentations de ce listener et de les activer au niveau de la couche Une couche peut ainsi jouer le rle de "moteur vnementiel" en diffusant les vnements survenus ses listeners. C'est avec la valve un autre moyen de dclencher des traitements implicitement en dehors des services.

4.10. Gestion des connexions et des transactions

Le socle Improve Foundations apporte une API de gestion des connexions et des transactions qui se veut indpendante de la solution technique sous-jacente. Il peut toutefois tre important de savoir que la solution repose sur la norme JTA, ce qui permet d'envisager le mode 2-phase commit sur les transactions.

4.10.1. Connexions
Le ConnectionManager gre des instances de ConnectionFactory. Chacune est ddie un accs vers une base de donnes. Il existe plusieurs implmentations de ConnectionFactory

Improve Foundations - Guide d'architecture - 5.0.1

28

Guide d'architecture

4. Implmentation Improve Foundations Core

apportes par les extensions qui vont les mettre en uvre selon diverses solutions techniques (JDBC, Hibernate...). A cause de la mise en oeuvre de JTA, les drivers JDBC et datasources associes doivent tre compatibles XA. A partir de l, l'obtention d'une connexion dans du code Java se fait toujours de la mme manire, en s'adressant au ConnectionManager. En gnral, la connexion obtenue devra tre caste pour travailler avec l'API d'accs au donnes apporte par la ConnectionFactory correspondante (JDBCConnection, HibernateConnection ou autre).

4.10.2. Transactions
Le TransactionManager est ddi la gestion des transactions. Il masque lui aussiles technologies sous-jacentes pour proposer une API standardise. Rappelons que, selon le dcoupage en couches de l'architecture, les transactions sont gres au niveau de la couche application alors que la solution d'accs au donnes intervient dans une couche plus basse. Cette raison suffit motiver l'emploi d'une API indpendante. TransactionManager apporte une API classique de gestion des transactions avec les mthodes begin(), commit(), rollback(). Toutefois, pour viter de laisser le dveloppeur se charger de son utilisation, ce qui pose un risque d'erreurs (commit() ou rollback() non appels dans les cas qui le ncessitent), TransactionManager propose une alternative qui passe par la mthode run() d'une classe anonyme qui va s'excuter dans un contexte transactionnel : Une autre alternative consiste utiliser TransactionValve, une valve qui met en uvre la gestion des transactions. Son traitement consiste faire appel au TransactionManager pour ouvrir une transaction avant un appel de service et la fermer aprs l'excution de celui-ci (commit() ou rollback() en cas d'erreur). Ainsi le code du service lui-mme n'est pas pollu par la notion de transaction. Le code est plus court, plus lisible. En contrepartie, il faut activer la valve et dfinir les services sur lesquels doivent s'appliquer une transaction. Le mcanisme de filtrage des valves va permettre de prciser les cas d'application d'un contexte transactionnel. Le mcanisme de gestion des transactions exploite : Le TransactionManager de Spring Le standard JTA en se basant sur l'implmentation Java Open Transaction Manager (http://jotm.objectweb.org) Les transactions supportent ainsi le mcanisme de 2-phase commit . L'utilisation de JOTM permet de mettre en uvre JTA sans ncessiter un serveur d'applications implmentant un

Improve Foundations - Guide d'architecture - 5.0.1

29

Guide d'architecture

4. Implmentation Improve Foundations Core

conteneur JTA. Cela rend les applications autonomes de ce point de vue par rapport aux serveurs d'applications cibles. Ceci reste transparent pour le dveloppeur mais ncessite la configuration de datasources XA pour les accs aux donnes. La plupart des drivers JDBC proposent leur implmentation d'XADataSource.

4.10.3. Services connects

L'API sur les connections apporte par le socle standardise la manire de les rcuprer lors de l'criture des services. La notion de service connect apparat en complment pour : faciliter un peu plus encore l'usage des connexions de manire allger le code produire sur chaque service, permettre une configuration externe de la connexion utilise par le service. En fin de compte, un "service connect" est le cadre pour la mise en oeuvre du pattern DAO (Data Access Object).

4.11. Contextes
4.11.1. ThreadContext
Improve Foundations permet de grer un contexte rattach au Thread. Ce contexte permet de conserver des rfrences vers des objets que l'on souhaite transmettre travers les couches de l'architecture sans les faire apparatre dans les signatures de mthodes des services. Le ThreadContext est gnralement rattach au cycle de vie d'une requte HTTP dans le cas d'une application Web (cf. ThreadContextFilter dans IFE-Web).

4.11.2. ApplicationContext
Un contexte partag par toute l'application est galement disponible. Comme le ThreadContext, celui-ci permet de stocker des objets relativement une cl.

Improve Foundations - Guide d'architecture - 5.0.1

30

Guide d'architecture

5. Extensions
Toute application repose sur un ensemble de services techniques. Improve Foundations permet de les mettre en uvre en apportant des extensions autour du noyau prcdemment dcrit. Ce document se contente de donner un aperu des extensions disponibles et de leurs apports. Le dtail de leur utilisation est dcrit dans la documentation respective de ces extensions.

5.1. IFE-Web
IFE-Web est une extension qui inclut les fonctionnalits Web essentielles, comme un complment au noyau. Elle apporte en particulier : WebClientLayer : reprsentation d'une couche Client de type Web. WebSession : reprsentation d'une session utilisateur une session utilisateur qui peut-tre sous-classe pour apporter un comportement spcifique. ThreadContextFilter : filtre de servlet qui assure que le ThreadContext est vid la fin de chaque requte HTTP.

5.2. IFE-Errors
Cette extension apporte un ensemble de classes permettant aux dveloppeurs fonctionnels de grer les erreurs : une notion de message internationalisable et li une cl (gnralisation du principe des messages Struts) des exceptions pour distinguer les erreurs fonctionnelles des erreurs techniques. En particulier, BusinessRulesException permet de faire remonter de la couche application un ensemble d'erreurs fonctionnelles de manire les exploiter dans la couche cliente.

5.3. IFE-Struts
IFE-Struts est une extension qui inclut des fonctionnalits complmentaires au noyau pour les applications utilisant Struts 1. Elle apporte : StrutsClientLayer : reprsentation d'une couche Client de type Web Struts (hrite de WebClientLayer).

Improve Foundations - Guide d'architecture - 5.0.1

31

Guide d'architecture

5. Extensions

La notion de valve Struts : le fonctionnement dune valve Struts est sensiblement le mme que celui dune valve de layer puisqu'elle apporte un tratiement avant et/ou aprs l'excution d'une action Struts. ImproveFoundationsPlugin : permet d'initialiser le noyau du socle au moment du dmarrage de la servlet Struts. WebSessionValve : valve qui facilite la configuration d'une session (WebSession).

5.4. IFE-StrutsHelp
L'extension IFE-Struts-Help permet la mise en place dune aide contextuelle avec Struts. Lassociation entre un cran de lapplication et lcran daide se fait par un fichier de configuration. Les dveloppements ne sont pas du tout impacts par la mise en place du systme daide contextuelle. Ce systme peut donc tre activ ou dsactiv tout moment. L'extension apporte une taglib avec un tag qui va gnrer dynamiquement l'URL de la page d'aide associe l'cran en cours de visualisation.

5.5. IFE-StrutsLayout
Cette extension permet de travailler avec le framework Open Source Struts-Layout, complment Struts. Elle propose un contrleur (RequestProcessor) permettant la cohabitation de Struts, Struts-Layout et Tiles avec Improve Foundations (valves Struts en particulier).

5.6. IFE-MultiProcess
Lobjectif de cette extension est de permettre une sauvegarde dun contexte utilisateur. Ceci permettant a un utilisateur de pouvoir travailler sur plusieurs dossiers en parallle sans ouvrir plusieurs navigateurs. LAPI propose permet de sauvegarder des contextes utilisateurs et de les restaurer. Une implmentation par dfaut est fournie par le socle. Il est possible de dvelopper sa propre implmentation afin de proposer une implmentation plus complte ou rpondant des besoins spcifiques.

5.7. IFE-EasyWeb
IFE-EasyWeb apporte une simplification de l'implmentation de la couche navigation d'une application Struts. Elle cache l'API servlet/jsp et dans une certaine mesure celle de Struts.

Improve Foundations - Guide d'architecture - 5.0.1

32

Guide d'architecture

5. Extensions

On crit les actions en tendant AbstractWebAction ou AbstractWebDispatchAction. Les mthodes y reoivent un StrutsWebContext au lieu des traditionnels requte, rponse, mapping et formulaire. Par dfaut ce contexte est persistant entre 2 requtes HTTP qui utilisent la mme action. On peut rendre le contexte commun 2 actions distinctes en leur faisant implmenter une mthode qui retourne un id. L'extension apporte aussi un mcanisme permettant de rafficher facilement la page prcdente et une valve qui permet de conserver l'historique de la navigation. Des actions struts et une taglib sont fournis pour naviguer dans cet historique.

5.8. IFE-PortletBridge
L'extension IFE-PortletBridge apporte les moyens pour intgrer des portails des applications bases sur Struts et Improve Foundations.

5.9. IFE-Authentication
L'objectif est de garantir quun utilisateur de l'application a t identifi. Cette extension permet de crer la session utilisateur. IFE-Authentication apporte des valves qui : filtrent les accs pour identifier l'utilisateur en cas de besoin (2 mthodes proposes : HTTP, JSP) dlguent l'identification de l'utilisateur un module externe : il faut implmenter AuthenticationService

5.10. IFE-Authorization
Cette extension propose un mcanisme de gestion des habilitations d'un utilisateur. Elle apporte : un service d'habilitation AuthorizationService dont l'application doit fournir une implmentation (l'utilisateur tant vhicul par le ThreadContext), des valves pour filtrer les appels des actions Struts et/ou des services, un modle d'habilitation pour stockage dans une base de donnes avec les services d'accs (implmentation reposant sur Hibernate). L'usage du modle d'habilitation est facultatif. Il est possible que des besoins fonctionnels particuliers obligent crer une implmentation diffrente.

Improve Foundations - Guide d'architecture - 5.0.1

33

Guide d'architecture

5. Extensions

5.11. IFE-Hibernate
Cette extension simplifie l'intgration de Hibernate, framework Open Source de mapping Objet/Relationnel. La manipulation des connexions et des transactions repose sur l'API standardise du socle. Elle apporte une ConnectionFactory ddie pour configurer et rcuprer une HibernateConnection qui expose une API simplifie pour excuter les actions les plus courantes. On peut toutefois accder la Session pour exploiter toutes les possibilits du framework.

5.12. IFE-JDBC
L'extension IFE-JDBC permet la manipulation de bases de donnes travers JDBC. Elle propose une simplification de l'utilisation de JDBC et les implmentations de ConnectionFactory et TransactionManager appropries. L'extension apporte en effet une ConnectionFactory (JdbcConnectionFactory) qui permet d'obtenir des JdbcConnection qui encapsulent une connexion JDBC et fournisse une API simplifie pour excuter des requtes. On peut aussi obtenir des JdbcSqlConnection qui donnent accs toute l'API JDBC. D'autre part, la classe ObjectMapper permet d'exploiter simplement un Result Set.

5.13. IFE-FTP
Cette extension propose un service technique de transmission de fichiers par FTP (FtpService).

5.14. IFE-Mail
Cette extension propose un service technique denvoi de mail (MailService). Elle ncessite la dclaration dun serveur SMTP.

5.15. IFE-JMS
IFE-JMS fournit un service d'changes de messages avec les brokers JMS. Cette extension propose une API plus simple et plus directe que JMS pour les cas d'utilisation les plus courants.

5.16. IFE-PDF
Lobjectif de lextension PDF est de permettre la gnration de documents formats au format PDF pour toutes les applications bases sur le socle. Deux possibilits sont offertes : Impression sur le poste client, les documents sont alors gnrs travers le flux dune servlet,

Improve Foundations - Guide d'architecture - 5.0.1

34

Guide d'architecture

5. Extensions

Impression par batch, les documents imprimer peuvent alors tre dpos sur un serveur FTP. Cette extension permet de gnrer des documents PDF partir dentits mtier. les entits sont srialise sous forme de flux XML sur la base dune transformation XSL le flux XML est transform en template XSL-FO le PDF est gnr partir du template Xsl-FO avec FOP Le dveloppeur applicatif doit fournir : le flux XML qui reprsente les entits, le mapping est ralis manuellement par le dveloppeur ou en utilisant un mcanisme de mapping tierce, et le template XSL-FO qui dfinit limpression.

5.17. IFE-JasperReports
Le but de l'extension IFE-Jasper est de permettre une utilisation simple du moteur de JasperReport. L'extension apporte un service abstrait AbstractJasperService et des implmentations par dfaut : XMLJasperService : cette implmentation permet l'utilisation de Bean Java comme source de donnes. BeanJasperService : cette implmentation permet l'utilisation de fichier XML comme source de donnes. JasperStoredProcedureService : cette implmentation permet d'aller rcuprer les donnes en base l'aide de procdures stockes.

5.18. IFE-RTFTemplate
IFE-RTFTemplate simplifie la gnration de documents de fusion au format RTF. L'extension est base sur l'utilitaire RTFTemplate (http://rtftemplate.sourceforge.net/fr/index.html) et Velocity. Elle permet de fusionner des donnes sous forme d'objets Java avec des modles (templates) de document RTF ditables avec un traitement de texte classique.

5.19. IFE-Converter
Cette extension propose un service de conversion de documents entre plusieurs formats bureautique usuels.

Improve Foundations - Guide d'architecture - 5.0.1

35

Guide d'architecture

5. Extensions

Elle est base sur les possibilits de l'utilitaire JODConverter [http://www.artofsolving.com/opensource/jodconverter] qui s'appuie lui-mme sur OpenOffice [http://www.openoffice.org] 2.0.3 ou suprieur.

5.20. IFE-GWT
Cette extension apporte des facilits pour utiliser le framework GWT (http://code.google.com/webtoolkit/) en apportant notamment une servlet spcifique qui permet de dclencher le dmarrage du noyau Improve Foundation et facilite les appels de services GWT en jouant le rle de contrleur unique.

5.21. IFE-RialtoGWT
Cette extension complmentaire IFE-GWT propose l'intgration du framework Rialto-GWT pour la ralisation d'applications Web 2.0 (http://rialto.improve-technologies.com/wiki/rialtogwt).

5.22. IFE-Flex
Cette extension propose un pont permettant l'appel de services de la couche Application depuis un client Flex.

5.23. IFE-Audit
IFE-Audit apporte des valves qui permettent de tracer les appels vers des actions struts et des services. La trace est dirige vers un fichier de log qui va enregistrer les appels, la dure d'excution des services, les erreurs rencontres. Ce fichier de log peut ensuite tre exploit par une application d'audit pour visualiser les informations sous forme de tableau de bord statistique.

5.24. IFE-MessAdmin
Cette extension intgre l'outil MessAdmin qui permet de superviser les sessions en cours d'une application. On peut ainsi connatre ces sessions et obtenir des informations les concernant (en termes d'utilisation mmoire notamment). Il est possible en outre de notifier un utilisateur ou tous les utilisateurs en envoyant un message qui sera affich dans une popup ds la prochaine requte.

Improve Foundations - Guide d'architecture - 5.0.1

36