Author: glandais Date: 2008-01-23 10:58:08 +0000 (Wed, 23 Jan 2008) New Revision: 427 Added: trunk/simexplorer-is/src/site/fr/rst/devel/architecture.txt trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.txt trunk/simexplorer-is/src/site/fr/rst/devel/migration.txt Removed: trunk/simexplorer-is/src/site/fr/rst/devel/architecture.rst trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.rst trunk/simexplorer-is/src/site/fr/rst/devel/migration.rst Log: Moved old rst to txt Deleted: trunk/simexplorer-is/src/site/fr/rst/devel/architecture.rst =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/architecture.rst 2008-01-23 10:54:50 UTC (rev 426) +++ trunk/simexplorer-is/src/site/fr/rst/devel/architecture.rst 2008-01-23 10:58:08 UTC (rev 427) @@ -1,390 +0,0 @@ -======================================= -SimExplorer SI - Dossier d'architecture -======================================= - -.. contents:: :depth: 3 -.. sectnum:: - -Introduction -============ - -Ce document détaille la solution proposée en réponse à la demande d'un outil d'exploration de simulation. - -Architecture conceptuelle -========================= - -Rappel des fonctions de l'application -------------------------------------- - -L'application permet l'utilisation d'outils de simulation dans un environnement multi-utilisateurs. Un mode client léger met à disposition la gestion des utilisateurs et la consultation des paramÚtres des simulations. Ce mode est accessible avec un simple navigateur. Avec un logiciel fourni (nommé aussi client lourd), l'utilisateur peut de même gérer les utilisateurs, mais aussi les simulations afin de les lancer. Une fonction de synchronisation met à jour les données locales par rapport aux données centralisées. - -Chaque fonction est limitée en fonction des droits de l'utilisateur connecté. Cet utilisateur, en fonction des groupes auxquels il appartient, obtient des droits sur les simulations et les utilisateurs (création, modification, suppression). - -Les modifications des paramÚtres des simulations sont sauvegardé afin de conserver un historique. Cet historique se synchronise avec les données centralisées et les données de l'utilisateur. - -Décomposition de l'application en modules ------------------------------------------ - -L'authentification s'appuie sur un module unique. Celui ci permet d'authentifier les utilisateurs se connectant via le client léger ou le client lourd. Un premier niveau impératif nécessite l'appartenance de l'utilisateur à un groupe destiné à contenir les accrédités à utiliser l'application. Ce module fourni aussi les groupes d'appartenance d'un utilisateur, afin de déterminer ses droits. Enfin, ce module permet l'édition des utilisateurs et des groupes par les utilisateurs avec pouvoir. - -Les autorisations sont gérées conjointement avec l'authentification. Une simulation a des droits associés en fonction de son propriétaire et son groupe d'appartenance. Ses droits sont décorélés des données métier, seul un identifiant technique permet aux services d'interroger le module d'autorisation afin de valider l'accÚs à une simulation. Le niveau de granularité des droits est similaire à la gestion des modes sur les fichiers. Les droits sur les actions création/modification/exécution sont alloués en fonction de l'utilisateur/groupe/autre. - -Le stockage est un module dupliqué à la fois sur le serveur gérant les données centralisées et sur chaque client lourd. Celui-ci a la charge de conserver les données dans une base, et de stocker les données volumineuses dans le systÚme de fichier. Il est capable de persister les objets utilisés par l'application. Un mécanisme de synchronisation permet de mettre à jour les données locales et les données centralisées en fonction de rÚgles de gestion de versionnement. - -La logique métier de l'application est contenue dans des services. Ceux ci peuvent être exécutés localement, lors de l'exécution d'une simulation sur le client lourd par exemple. Certains services sont présents uniquement sur le serveur, parce qu'ils nécessitent les modules d'autorisation et les données centralisées. Le client lourd fait alors appel à ces services dans un mode appel distant. - -Le module d'interface est composé de deux parties. CÃŽté serveur, l'utilisateur accÚde avec un navigateur Internet standard à l'application. Les pages sont servies par un serveur web utilisant un contrÃŽleur. Celui ci interagit avec les services afin de présenter les données à l'utilisateur. CÃŽté client, l'interface graphique s'appuie aussi sur un contrÃŽleur utilisant les services. - - -Exigences et contraintes ------------------------- - -Contraintes d'urbanisme -_______________________ - -Le client lourd doit s'intégrer dans SimExplorer RCP. - -Les services déployés sur le serveur et mis à disposition du client lourd doivent pouvoir être réutilisés par des applications tierces. - -Le serveur doit être en mesure de lancer des simulations et de récupérer les résultats. - -Exigences et contraintes liées à des fonctionnalités particuliÚres -__________________________________________________________________ - -Un serveur d'authentification.existant pourra être réutilisé dans la mesure où il est accessible via des protocoles standards. Une note précisant le fonctionnement de ce serveur devra être fourni afin de rendre possible son utilisation. ex : LDAP - -Les appels de lancement des simulations devra être formalisés dans une note. Ceux ci pourront alors être intégrés dans les services. - -L'authentification implique l'établissement d'une connexion sécurisée entre le client et le serveur, afin de ne pas faire passer en clair les mots de passe sur le réseau. Le serveur disposera d'un certificat afin de crypter les flux. - -Contraintes d'ergonomie -_______________________ - -L'application web se doit d'être compatible avec les navigateurs récents : Firefox2+ et IE6+. - -L'application client lourd est un application standard type bureautique, et doit être compatible avec le maximum de plateformes. Le lancement de l'application doit se faire simplement par un raccourci. - -Volumétrie -__________ - -Les données associées aux simulations sont parfois trÚs volumineuses (>100Mo). Ces données doivent être stockées en local mais aussi sur le serveur, avec des transferts entre le client et le serveur. - -Contraintes et exigences liées à l'exploitation -_______________________________________________ - -Lors de la mise à jour de l'application, la base de données doit être synchrone avec l'applicatif. De même, le client lourd doit être à jour par rapport à la version déployée sur le serveur. - -Les données doivent pouvoir être simplement sauvegardées et restaurées. - -Architecture logique -==================== - -Schéma d'architecture logique ------------------------------ - -.. image:: diagramme1.png - -Description des flux --------------------- - - #. Serveur web - - L'interface client léger passe par ce flux. L'authentification se fera en HTTPS, le reste de l'application pourra être au choix en HTTP ou en HTTPS. Le contenu sera constitué de pages XHTML compatibles avec les navigateurs récents. - - #. Interface client lourd - - C'est à travers ce canal que l'utilisateur interagit avec l'application. - - #. Serveur d'authentification - - Le framework d'authentification utilise un serveur externe afin d'authentifier les utilisateurs. Ce flux dépend du serveur. - - #. Autorisations - - Toutes les informations relatives à la protection des accÚs aux simulations sont retrouvées via ce lien vers une base de données. - - #. Persistance cÃŽté serveur - - Les objets sont stockés dans une base de donnée à travers ce flux. - - #. Persistance cÃŽté client - - De même, les objets sont stockés dans une base de données. Nous sommes ici en présence d'une base de données embarquée, afin de rendre le client lourd autonome. - - #. SystÚme de fichiers serveur - - Les données volumineuses sont stockées dans le systÚme de fichier plutÃŽt que dans la base. - - #. SystÚme de fichiers client - - De la même façon que sur le serveur, les données sont stockées sous forme de fichiers dans le systÚme de fichier de l'utilisateur. - - #. Services distants - - La communication entre le client lourd et le serveur passe par ce flux. Celui ci est crypté et intégré à haut niveau dans l'application. Les appels de service se font de façon transparente, de façon similaire à un appel local. - - -Initialisation des entrepÃŽts de données ---------------------------------------- - -Pour l'authentification, un groupe d'utilisateur doit être créé afin d'accueillir les personnes accréditées. De plus, un groupe d'administrateur avec un utilisateur doit exister afin de permettre l'administration des utilisateurs. Ces deux groupes seront à spécifier lors de l'installation. - -Si l'application doit utiliser un serveur d'authentification existant, le groupe des administrateurs doit avoir les droits de lister les utilisateurs amenés à être ajouté aux personnes accréditées. - -Les bases de données d'autorisation et de stockage peuvent être initialisés lors du lancement de l'application de façon automatique. Si les droits de création de table et de champs n'est pas autorisé pour l'application, un script doit être exécuté avant le déploiement d'une nouvelle version afin de mettre à jour la base et migrer les données. - -CÃŽté client, le problÚme ne se pose pas, la base de données est embarquée dans l'application. - -Les modules de l'application ----------------------------- - -Le module authentification -__________________________ - -La technologie JAAS (Java Authentication and Authorization Service) a été retenue. La partie autorisation est utilisée uniquement pour valider l'accÚs de l'utilisateur authentifié à l'application. - -Plusieurs méthodes d'authentification sont déjà implantées (login/mot de passe/groupes dans une base de données avec JDBC, LDAP, ...). - -Les modules services -____________________ - -Les services sont contenus dans des EJB (Entreprise Java Bean). Chaque service est un composant disposant d'outils facilitant la mise en oeuvre des transactions et la distribution. - -Ces services sont destinés à contenir toute la logique métier. - -Les services contiennent aussi le contexte d'authentification de l'appelant. - -Le module autorisation -______________________ - -Grâce au contexte d'authentification des EJB, les appels au module d'autorisation vont sécurisés les accÚs aux données. - -Le module stockage -__________________ - -Ce module repose en grande partie sur la technologie JPA (Java Persistence API). Elle permet un mapping entre les objets et la base de données de façon transparente et interropérable. Le choix de la base de données n'est alors plus vérouillé, de nombreux systÚmes étant compatibles. Afin de gérer les volumétries associées aux simulations, certaines propriétés seront stockées sur le disque dur. - -Lors de l'accÚs à une donnée, le module gérant les autorisations est appelé afin de vérifier les droits. De même, lorsque l'utilisateur crée une nouvelle entité, les droits lui sont associés via ce service. - -Le module interface -___________________ - -CÃŽté client léger, le site est réalisé avec Tapestry 5. Ce framework apporte le développement orienté objet au applications web. De nombreuses fonctionnalités sont incluses et facilitent le développement. - -CÃŽté client lourd, le framework JAXX est utilisé. Ce framework transforme des XML décrivant l'interface en classes Java. - -Développement de l'application ------------------------------- - -Lors de la construction de Simexplorer SI, nous utilisons le framework ToPIA ainsi que différents outils développés par Code Lutin. Ceux ci sont tous sous licence LGPL. - -A partir du modÚle conceptuel, le process de développement génÚre une partie de l'application, entre autre sous la forme d'interfaces à implémenter. Nous obtenons alors : - - les entités persistées - - les interfaces des services - - les interfaces des composants des pages web - - -Architecture physique -===================== - -Architecture logicielle ------------------------ - -L'ensemble de l'application est développée avec le langage Java. La version de référence lors du développement de l'application est JRE 6 Update 3. - -Serveur Web -___________ - -Le serveur web est constitué d'un Apache 2.2. Le module mod_proxy_ajp permet de ne pas lancer le serveur d'application en root et d'avoir accÚs au port HTTP et HTTPS. - -Serveur Applicatif -__________________ - -+------------------------+------------------------+------------------------+------------------------+------------------------+ -| |JBoss 4.2.2 GA |Geronimo JEE5 2.0.2 |JOnAS 5.0 M1 |GlassFish V2 | -+========================+========================+========================+========================+========================+ -|EJB3 | |ok| [#jba]_ | |ok| [#grc]_ | |ok| [#joa]_ | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- RemoteBinding | |ok| [#jbb]_ | |ok| [#grd]_ | |uok| | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- SSL | |ok| [#jbc]_ | |ok| [#gra]_ | |uok| | |ok| [#gfd]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- SecurityDomain | |ok| [#jbd]_ | |uok| | |ok| [#joc]_ | |ok| [#gfe]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- WebService | |ok| [#jbe]_ | |ok| [#gre]_ | |ok| [#job]_ | |ok| [#gfa]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -| * Sécurisé | |ok| [#jbe]_ | |uok| [#gre]_ | |uok| | |ok| [#gff]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -| * WebServiceContext | |ok| [#jbe]_ | |ok| [#gre]_ | |ok| [#job]_ | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- SessionContext | |uok| | |uok| | |uok| | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|JPA | |ok| [#jbf]_ | |ok| [#grf]_ | |ok| [#jof]_ | |ok| [#gfb]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- XML datasource | |ok| [#jbg]_ | |ok| [#grj]_ | |ok| [#joe]_ | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- persistence.xml | |ok| [#jbh]_ | |ok| [#grg]_ | |ok| [#jog]_ | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- orm.xml | |uok| | |ok| [#grh]_ | |ok| [#joh]_ | |ok| [#gfc]_ | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|Servlet | |ok| [#jbi]_ | |ok| [#gri]_ | |uok| | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|- JAAS | |ok| [#jbj]_ | |ok| [#grb]_ | |ok| [#jod]_ | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ -|Corba | |uok| | |uok| | |uok| | |uok| | -+------------------------+------------------------+------------------------+------------------------+------------------------+ - -.. |ok| image:: ok.png -.. |nok| image:: nok.png -.. |uok| image:: uok.png - -.. [#jba] http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/inde... -.. [#jbb] http://docs.jboss.org/ejb3/app-server/tutorial/jndibinding/jndi.html -.. [#jbc] http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/tran... -.. [#jbd] http://docs.jboss.org/ejb3/app-server/tutorial/security/security.html -.. [#jbe] http://labs.jboss.com/jbossws/docs/jaxws_userguide-2.0/index.html -.. [#jbf] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... -.. [#jbg] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... -.. [#jbh] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... -.. [#jbi] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Gett... -.. [#jbj] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... - -.. [#grc] http://openejb.apache.org/ -.. [#grd] http://openejb.apache.org/jndi-names.html -.. [#gra] http://www.ibm.com/developerworks/opensource/library/os-ag-corba1/ -.. [#gre] http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html -.. [#grf] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... -.. [#grj] http://cwiki.apache.org/GMOxDOC11/geronimo-connector-11xsd.html#geronimo-con... -.. [#grg] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... -.. [#grh] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... -.. [#gri] http://cwiki.apache.org/GMOxKB/jetty-or-tomcat.html -.. [#grb] http://www.ibm.com/developerworks/opensource/library/os-ag-security/ - -.. [#joa] http://www.easybeans.org/doc/userguide/en/chunk-integrated/ejb3_introduction... -.. [#joc] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... -.. [#job] http://wiki.easybeans.org/xwiki/bin/view/Main/JAXWS - -.. [#jof] http://www.jpox.org/docs/jpa/index.html -.. [#joe] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... -.. [#jog] http://www.jpox.org/docs/jpa/persistence_xml.html -.. [#joh] http://www.jpox.org/docs/jpa/orm_xml.html - -.. [#jod] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... - -.. [#gfd] http://blogs.sun.com/swchan/entry/enterprise_java_bean_over_ssl -.. [#gfe] http://java.sun.com/developer/technicalArticles/J2EE/security_annotation/ -.. [#gfa] http://wiki.glassfish.java.net/Wiki.jsp?page=WebServicesTechnologies -.. [#gff] https://glassfish.dev.java.net/javaee5/docs/AG/ablrk.html#ablry -.. [#gfb] https://glassfish.dev.java.net/javaee5/persistence/ -.. [#gfc] https://glassfish.dev.java.net/javaee5/persistence/persistence_faq.html#5 - - -SGBD -____ - -Pour la base sur le serveur, les performances et la stabilité de PostgreSQL ont été retenues. CÃŽté client lourd, la base de donnée embarquée H2 est utilisée. Un export XML sera réalisé pour l'interopérabilité. - - -Choix technologiques transverses -________________________________ - -Dans la perspective de réutilisation, les services publiés utiliseront des protocoles standardisés et inter opérables, afin de ne pas limiter le choix du langage. - -La technologie ... a été choisie pour son support de la sécurité et son utilisation courante dans différents langages et sur différents systÚmes d'exploitation. - -Solution aux contraintes d'ergonomie -____________________________________ - -L'application web respectera les standards W3C XHTML. - -L'application client lourd utilise le framework Swing, disponible sur un grand nombre de plateformes. Sur celles où Java Web Start est disponible, l'application pourra être installée par un simple clic sur le site du client léger. - -Dimensionnement -_______________ - -Une attention particuliÚre devra être faite à la taille des partitions lors de l'intégration en fonction de la volumétrie cible. De même, cÃŽté client, l'utilisateur doit être informé de l'espace utilisé par l'application par rapport à son espace disponible. La synchronisation doit vérifier au préalable la suffisance d'espace. - -En supposant que chaque simulation prend environ 100ko de paramÚtres, que 10 utilisateurs utilisent l'application en créant 5 simulations par jour, on obtient environ 10Go de paramÚtres de simulation sur 10 ans. - -Solution pour l'exploitation du systÚme -_______________________________________ - - -Lors de la mise à jour de l'application, plusieurs aspects doivent être gérés. Tout d'abord la base de données doit être synchrone avec l'applicatif. Ceci devra se faire automatiquement avec une migration des données executée lors du déploiement d'une nouvelle version. - -Dans un environnement client/serveur, il est nécessaire de garantir la compatibilité entre les deux applications. Ainsi, le serveur mettra à disposition dans la mesure du possible les services avec une compatibilité ascendante. Si la version du client est obsolÚte, l'utilisateur est notifié et il ne peut plus utiliser l'application en mode connecté. - - -ModÚle conceptuel ------------------ - -Entités des données -___________________ - -.. image:: ../../../../xmi/images/data.png - - -Entités des authorisations -__________________________ - -.. image:: ../../../../xmi/images/entities.png - - -Services de stockage -____________________ - -.. image:: ../../../../xmi/images/storage.png - - -Services d'authorisation -________________________ - -.. image:: ../../../../xmi/images/authorization.png - - -Application web -_______________ - -.. image:: ../../../../xmi/images/applications.png - - -Séquences d'utilisation ------------------------ - -Gestion des authorisations -__________________________ - -.. image:: ./authorization.jpg - -Écrans de l'application ------------------------ - -Liste des éléments -__________________ - -.. image:: ./screenshots/Screenshot.png - -Importer un élément -___________________ - -.. image:: ./screenshots/Screenshot-1.png - -Liste des utilisateurs -______________________ - -.. image:: ./screenshots/Screenshot-2.png - -Ajouter/éditer un utilisateur -_____________________________ - -.. image:: ./screenshots/Screenshot-3.png - -Liste des groupes -_________________ - -.. image:: ./screenshots/Screenshot-4.png - -Ajouter/éditer un groupe -________________________ - -.. image:: ./screenshots/Screenshot-5.png Added: trunk/simexplorer-is/src/site/fr/rst/devel/architecture.txt =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/architecture.txt (rev 0) +++ trunk/simexplorer-is/src/site/fr/rst/devel/architecture.txt 2008-01-23 10:58:08 UTC (rev 427) @@ -0,0 +1,390 @@ +======================================= +SimExplorer SI - Dossier d'architecture +======================================= + +.. contents:: :depth: 3 +.. sectnum:: + +Introduction +============ + +Ce document détaille la solution proposée en réponse à la demande d'un outil d'exploration de simulation. + +Architecture conceptuelle +========================= + +Rappel des fonctions de l'application +------------------------------------- + +L'application permet l'utilisation d'outils de simulation dans un environnement multi-utilisateurs. Un mode client léger met à disposition la gestion des utilisateurs et la consultation des paramÚtres des simulations. Ce mode est accessible avec un simple navigateur. Avec un logiciel fourni (nommé aussi client lourd), l'utilisateur peut de même gérer les utilisateurs, mais aussi les simulations afin de les lancer. Une fonction de synchronisation met à jour les données locales par rapport aux données centralisées. + +Chaque fonction est limitée en fonction des droits de l'utilisateur connecté. Cet utilisateur, en fonction des groupes auxquels il appartient, obtient des droits sur les simulations et les utilisateurs (création, modification, suppression). + +Les modifications des paramÚtres des simulations sont sauvegardé afin de conserver un historique. Cet historique se synchronise avec les données centralisées et les données de l'utilisateur. + +Décomposition de l'application en modules +----------------------------------------- + +L'authentification s'appuie sur un module unique. Celui ci permet d'authentifier les utilisateurs se connectant via le client léger ou le client lourd. Un premier niveau impératif nécessite l'appartenance de l'utilisateur à un groupe destiné à contenir les accrédités à utiliser l'application. Ce module fourni aussi les groupes d'appartenance d'un utilisateur, afin de déterminer ses droits. Enfin, ce module permet l'édition des utilisateurs et des groupes par les utilisateurs avec pouvoir. + +Les autorisations sont gérées conjointement avec l'authentification. Une simulation a des droits associés en fonction de son propriétaire et son groupe d'appartenance. Ses droits sont décorélés des données métier, seul un identifiant technique permet aux services d'interroger le module d'autorisation afin de valider l'accÚs à une simulation. Le niveau de granularité des droits est similaire à la gestion des modes sur les fichiers. Les droits sur les actions création/modification/exécution sont alloués en fonction de l'utilisateur/groupe/autre. + +Le stockage est un module dupliqué à la fois sur le serveur gérant les données centralisées et sur chaque client lourd. Celui-ci a la charge de conserver les données dans une base, et de stocker les données volumineuses dans le systÚme de fichier. Il est capable de persister les objets utilisés par l'application. Un mécanisme de synchronisation permet de mettre à jour les données locales et les données centralisées en fonction de rÚgles de gestion de versionnement. + +La logique métier de l'application est contenue dans des services. Ceux ci peuvent être exécutés localement, lors de l'exécution d'une simulation sur le client lourd par exemple. Certains services sont présents uniquement sur le serveur, parce qu'ils nécessitent les modules d'autorisation et les données centralisées. Le client lourd fait alors appel à ces services dans un mode appel distant. + +Le module d'interface est composé de deux parties. CÃŽté serveur, l'utilisateur accÚde avec un navigateur Internet standard à l'application. Les pages sont servies par un serveur web utilisant un contrÃŽleur. Celui ci interagit avec les services afin de présenter les données à l'utilisateur. CÃŽté client, l'interface graphique s'appuie aussi sur un contrÃŽleur utilisant les services. + + +Exigences et contraintes +------------------------ + +Contraintes d'urbanisme +_______________________ + +Le client lourd doit s'intégrer dans SimExplorer RCP. + +Les services déployés sur le serveur et mis à disposition du client lourd doivent pouvoir être réutilisés par des applications tierces. + +Le serveur doit être en mesure de lancer des simulations et de récupérer les résultats. + +Exigences et contraintes liées à des fonctionnalités particuliÚres +__________________________________________________________________ + +Un serveur d'authentification.existant pourra être réutilisé dans la mesure où il est accessible via des protocoles standards. Une note précisant le fonctionnement de ce serveur devra être fourni afin de rendre possible son utilisation. ex : LDAP + +Les appels de lancement des simulations devra être formalisés dans une note. Ceux ci pourront alors être intégrés dans les services. + +L'authentification implique l'établissement d'une connexion sécurisée entre le client et le serveur, afin de ne pas faire passer en clair les mots de passe sur le réseau. Le serveur disposera d'un certificat afin de crypter les flux. + +Contraintes d'ergonomie +_______________________ + +L'application web se doit d'être compatible avec les navigateurs récents : Firefox2+ et IE6+. + +L'application client lourd est un application standard type bureautique, et doit être compatible avec le maximum de plateformes. Le lancement de l'application doit se faire simplement par un raccourci. + +Volumétrie +__________ + +Les données associées aux simulations sont parfois trÚs volumineuses (>100Mo). Ces données doivent être stockées en local mais aussi sur le serveur, avec des transferts entre le client et le serveur. + +Contraintes et exigences liées à l'exploitation +_______________________________________________ + +Lors de la mise à jour de l'application, la base de données doit être synchrone avec l'applicatif. De même, le client lourd doit être à jour par rapport à la version déployée sur le serveur. + +Les données doivent pouvoir être simplement sauvegardées et restaurées. + +Architecture logique +==================== + +Schéma d'architecture logique +----------------------------- + +.. image:: diagramme1.png + +Description des flux +-------------------- + + #. Serveur web + + L'interface client léger passe par ce flux. L'authentification se fera en HTTPS, le reste de l'application pourra être au choix en HTTP ou en HTTPS. Le contenu sera constitué de pages XHTML compatibles avec les navigateurs récents. + + #. Interface client lourd + + C'est à travers ce canal que l'utilisateur interagit avec l'application. + + #. Serveur d'authentification + + Le framework d'authentification utilise un serveur externe afin d'authentifier les utilisateurs. Ce flux dépend du serveur. + + #. Autorisations + + Toutes les informations relatives à la protection des accÚs aux simulations sont retrouvées via ce lien vers une base de données. + + #. Persistance cÃŽté serveur + + Les objets sont stockés dans une base de donnée à travers ce flux. + + #. Persistance cÃŽté client + + De même, les objets sont stockés dans une base de données. Nous sommes ici en présence d'une base de données embarquée, afin de rendre le client lourd autonome. + + #. SystÚme de fichiers serveur + + Les données volumineuses sont stockées dans le systÚme de fichier plutÃŽt que dans la base. + + #. SystÚme de fichiers client + + De la même façon que sur le serveur, les données sont stockées sous forme de fichiers dans le systÚme de fichier de l'utilisateur. + + #. Services distants + + La communication entre le client lourd et le serveur passe par ce flux. Celui ci est crypté et intégré à haut niveau dans l'application. Les appels de service se font de façon transparente, de façon similaire à un appel local. + + +Initialisation des entrepÃŽts de données +--------------------------------------- + +Pour l'authentification, un groupe d'utilisateur doit être créé afin d'accueillir les personnes accréditées. De plus, un groupe d'administrateur avec un utilisateur doit exister afin de permettre l'administration des utilisateurs. Ces deux groupes seront à spécifier lors de l'installation. + +Si l'application doit utiliser un serveur d'authentification existant, le groupe des administrateurs doit avoir les droits de lister les utilisateurs amenés à être ajouté aux personnes accréditées. + +Les bases de données d'autorisation et de stockage peuvent être initialisés lors du lancement de l'application de façon automatique. Si les droits de création de table et de champs n'est pas autorisé pour l'application, un script doit être exécuté avant le déploiement d'une nouvelle version afin de mettre à jour la base et migrer les données. + +CÃŽté client, le problÚme ne se pose pas, la base de données est embarquée dans l'application. + +Les modules de l'application +---------------------------- + +Le module authentification +__________________________ + +La technologie JAAS (Java Authentication and Authorization Service) a été retenue. La partie autorisation est utilisée uniquement pour valider l'accÚs de l'utilisateur authentifié à l'application. + +Plusieurs méthodes d'authentification sont déjà implantées (login/mot de passe/groupes dans une base de données avec JDBC, LDAP, ...). + +Les modules services +____________________ + +Les services sont contenus dans des EJB (Entreprise Java Bean). Chaque service est un composant disposant d'outils facilitant la mise en oeuvre des transactions et la distribution. + +Ces services sont destinés à contenir toute la logique métier. + +Les services contiennent aussi le contexte d'authentification de l'appelant. + +Le module autorisation +______________________ + +Grâce au contexte d'authentification des EJB, les appels au module d'autorisation vont sécurisés les accÚs aux données. + +Le module stockage +__________________ + +Ce module repose en grande partie sur la technologie JPA (Java Persistence API). Elle permet un mapping entre les objets et la base de données de façon transparente et interropérable. Le choix de la base de données n'est alors plus vérouillé, de nombreux systÚmes étant compatibles. Afin de gérer les volumétries associées aux simulations, certaines propriétés seront stockées sur le disque dur. + +Lors de l'accÚs à une donnée, le module gérant les autorisations est appelé afin de vérifier les droits. De même, lorsque l'utilisateur crée une nouvelle entité, les droits lui sont associés via ce service. + +Le module interface +___________________ + +CÃŽté client léger, le site est réalisé avec Tapestry 5. Ce framework apporte le développement orienté objet au applications web. De nombreuses fonctionnalités sont incluses et facilitent le développement. + +CÃŽté client lourd, le framework JAXX est utilisé. Ce framework transforme des XML décrivant l'interface en classes Java. + +Développement de l'application +------------------------------ + +Lors de la construction de Simexplorer SI, nous utilisons le framework ToPIA ainsi que différents outils développés par Code Lutin. Ceux ci sont tous sous licence LGPL. + +A partir du modÚle conceptuel, le process de développement génÚre une partie de l'application, entre autre sous la forme d'interfaces à implémenter. Nous obtenons alors : + - les entités persistées + - les interfaces des services + - les interfaces des composants des pages web + + +Architecture physique +===================== + +Architecture logicielle +----------------------- + +L'ensemble de l'application est développée avec le langage Java. La version de référence lors du développement de l'application est JRE 6 Update 3. + +Serveur Web +___________ + +Le serveur web est constitué d'un Apache 2.2. Le module mod_proxy_ajp permet de ne pas lancer le serveur d'application en root et d'avoir accÚs au port HTTP et HTTPS. + +Serveur Applicatif +__________________ + ++------------------------+------------------------+------------------------+------------------------+------------------------+ +| |JBoss 4.2.2 GA |Geronimo JEE5 2.0.2 |JOnAS 5.0 M1 |GlassFish V2 | ++========================+========================+========================+========================+========================+ +|EJB3 | |ok| [#jba]_ | |ok| [#grc]_ | |ok| [#joa]_ | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- RemoteBinding | |ok| [#jbb]_ | |ok| [#grd]_ | |uok| | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- SSL | |ok| [#jbc]_ | |ok| [#gra]_ | |uok| | |ok| [#gfd]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- SecurityDomain | |ok| [#jbd]_ | |uok| | |ok| [#joc]_ | |ok| [#gfe]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- WebService | |ok| [#jbe]_ | |ok| [#gre]_ | |ok| [#job]_ | |ok| [#gfa]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +| * Sécurisé | |ok| [#jbe]_ | |uok| [#gre]_ | |uok| | |ok| [#gff]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +| * WebServiceContext | |ok| [#jbe]_ | |ok| [#gre]_ | |ok| [#job]_ | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- SessionContext | |uok| | |uok| | |uok| | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|JPA | |ok| [#jbf]_ | |ok| [#grf]_ | |ok| [#jof]_ | |ok| [#gfb]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- XML datasource | |ok| [#jbg]_ | |ok| [#grj]_ | |ok| [#joe]_ | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- persistence.xml | |ok| [#jbh]_ | |ok| [#grg]_ | |ok| [#jog]_ | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- orm.xml | |uok| | |ok| [#grh]_ | |ok| [#joh]_ | |ok| [#gfc]_ | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|Servlet | |ok| [#jbi]_ | |ok| [#gri]_ | |uok| | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|- JAAS | |ok| [#jbj]_ | |ok| [#grb]_ | |ok| [#jod]_ | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ +|Corba | |uok| | |uok| | |uok| | |uok| | ++------------------------+------------------------+------------------------+------------------------+------------------------+ + +.. |ok| image:: ok.png +.. |nok| image:: nok.png +.. |uok| image:: uok.png + +.. [#jba] http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/inde... +.. [#jbb] http://docs.jboss.org/ejb3/app-server/tutorial/jndibinding/jndi.html +.. [#jbc] http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/tran... +.. [#jbd] http://docs.jboss.org/ejb3/app-server/tutorial/security/security.html +.. [#jbe] http://labs.jboss.com/jbossws/docs/jaxws_userguide-2.0/index.html +.. [#jbf] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... +.. [#jbg] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... +.. [#jbh] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... +.. [#jbi] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Gett... +.. [#jbj] http://labs.jboss.com/file-access/default/members/jbossas/freezone/docs/Serv... + +.. [#grc] http://openejb.apache.org/ +.. [#grd] http://openejb.apache.org/jndi-names.html +.. [#gra] http://www.ibm.com/developerworks/opensource/library/os-ag-corba1/ +.. [#gre] http://cwiki.apache.org/GMOxPMGT/geronimo-20-web-services-support.html +.. [#grf] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... +.. [#grj] http://cwiki.apache.org/GMOxDOC11/geronimo-connector-11xsd.html#geronimo-con... +.. [#grg] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... +.. [#grh] http://openjpa.apache.org/builds/1.0.1/apache-openjpa-1.0.1/docs/manual/jpa_... +.. [#gri] http://cwiki.apache.org/GMOxKB/jetty-or-tomcat.html +.. [#grb] http://www.ibm.com/developerworks/opensource/library/os-ag-security/ + +.. [#joa] http://www.easybeans.org/doc/userguide/en/chunk-integrated/ejb3_introduction... +.. [#joc] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... +.. [#job] http://wiki.easybeans.org/xwiki/bin/view/Main/JAXWS + +.. [#jof] http://www.jpox.org/docs/jpa/index.html +.. [#joe] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... +.. [#jog] http://www.jpox.org/docs/jpa/persistence_xml.html +.. [#joh] http://www.jpox.org/docs/jpa/orm_xml.html + +.. [#jod] http://jonas.objectweb.org/current/doc/doc-en/integrated/configuration_guide... + +.. [#gfd] http://blogs.sun.com/swchan/entry/enterprise_java_bean_over_ssl +.. [#gfe] http://java.sun.com/developer/technicalArticles/J2EE/security_annotation/ +.. [#gfa] http://wiki.glassfish.java.net/Wiki.jsp?page=WebServicesTechnologies +.. [#gff] https://glassfish.dev.java.net/javaee5/docs/AG/ablrk.html#ablry +.. [#gfb] https://glassfish.dev.java.net/javaee5/persistence/ +.. [#gfc] https://glassfish.dev.java.net/javaee5/persistence/persistence_faq.html#5 + + +SGBD +____ + +Pour la base sur le serveur, les performances et la stabilité de PostgreSQL ont été retenues. CÃŽté client lourd, la base de donnée embarquée H2 est utilisée. Un export XML sera réalisé pour l'interopérabilité. + + +Choix technologiques transverses +________________________________ + +Dans la perspective de réutilisation, les services publiés utiliseront des protocoles standardisés et inter opérables, afin de ne pas limiter le choix du langage. + +La technologie ... a été choisie pour son support de la sécurité et son utilisation courante dans différents langages et sur différents systÚmes d'exploitation. + +Solution aux contraintes d'ergonomie +____________________________________ + +L'application web respectera les standards W3C XHTML. + +L'application client lourd utilise le framework Swing, disponible sur un grand nombre de plateformes. Sur celles où Java Web Start est disponible, l'application pourra être installée par un simple clic sur le site du client léger. + +Dimensionnement +_______________ + +Une attention particuliÚre devra être faite à la taille des partitions lors de l'intégration en fonction de la volumétrie cible. De même, cÃŽté client, l'utilisateur doit être informé de l'espace utilisé par l'application par rapport à son espace disponible. La synchronisation doit vérifier au préalable la suffisance d'espace. + +En supposant que chaque simulation prend environ 100ko de paramÚtres, que 10 utilisateurs utilisent l'application en créant 5 simulations par jour, on obtient environ 10Go de paramÚtres de simulation sur 10 ans. + +Solution pour l'exploitation du systÚme +_______________________________________ + + +Lors de la mise à jour de l'application, plusieurs aspects doivent être gérés. Tout d'abord la base de données doit être synchrone avec l'applicatif. Ceci devra se faire automatiquement avec une migration des données executée lors du déploiement d'une nouvelle version. + +Dans un environnement client/serveur, il est nécessaire de garantir la compatibilité entre les deux applications. Ainsi, le serveur mettra à disposition dans la mesure du possible les services avec une compatibilité ascendante. Si la version du client est obsolÚte, l'utilisateur est notifié et il ne peut plus utiliser l'application en mode connecté. + + +ModÚle conceptuel +----------------- + +Entités des données +___________________ + +.. image:: ../../../../xmi/images/data.png + + +Entités des authorisations +__________________________ + +.. image:: ../../../../xmi/images/entities.png + + +Services de stockage +____________________ + +.. image:: ../../../../xmi/images/storage.png + + +Services d'authorisation +________________________ + +.. image:: ../../../../xmi/images/authorization.png + + +Application web +_______________ + +.. image:: ../../../../xmi/images/applications.png + + +Séquences d'utilisation +----------------------- + +Gestion des authorisations +__________________________ + +.. image:: ./authorization.jpg + +Écrans de l'application +----------------------- + +Liste des éléments +__________________ + +.. image:: ./screenshots/Screenshot.png + +Importer un élément +___________________ + +.. image:: ./screenshots/Screenshot-1.png + +Liste des utilisateurs +______________________ + +.. image:: ./screenshots/Screenshot-2.png + +Ajouter/éditer un utilisateur +_____________________________ + +.. image:: ./screenshots/Screenshot-3.png + +Liste des groupes +_________________ + +.. image:: ./screenshots/Screenshot-4.png + +Ajouter/éditer un groupe +________________________ + +.. image:: ./screenshots/Screenshot-5.png Property changes on: trunk/simexplorer-is/src/site/fr/rst/devel/architecture.txt ___________________________________________________________________ Name: svn:executable + * Deleted: trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.rst =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.rst 2008-01-23 10:54:50 UTC (rev 426) +++ trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.rst 2008-01-23 10:58:08 UTC (rev 427) @@ -1,17 +0,0 @@ -GlassFish -========= - -**GlassFish** est un serveur d'applications compatible J2EE ; la licence est CDDL et GPLv2. - -Fonctions ---------- - -Au niveau des standards, GlassFish est une implémentation complète de la norme Java EE 5 qui recouvre: - - * EJB 3 (approche POJO, configuration par exception, injection de dépendance). L'occasion de se refaire une idée sur les EJB. - * JPA (Java Persistence API): standard implémenté par TopLink (par défaut dans GlassFish), Hibernate ou OpenJPA - * JAX-WS 2.x: nouvelle pile pour les services web - * JAXB 2.0: mise en corresponsance (mapping) XML/Java utilisée par JAX-WS 2.0 - * JSF (Java Server Faces) - Framework MVC dont Apache MyFaces et JSF RI sont des implémentations libres - * StAX - parseur de streaming XML - * JSP 2.1 & Servlet 2.5: pour faire de l'injection de dépendance dans le conteneur web Added: trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.txt =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.txt (rev 0) +++ trunk/simexplorer-is/src/site/fr/rst/devel/glassfish.txt 2008-01-23 10:58:08 UTC (rev 427) @@ -0,0 +1,17 @@ +GlassFish +========= + +**GlassFish** est un serveur d'applications compatible J2EE ; la licence est CDDL et GPLv2. + +Fonctions +--------- + +Au niveau des standards, GlassFish est une implémentation complète de la norme Java EE 5 qui recouvre: + + * EJB 3 (approche POJO, configuration par exception, injection de dépendance). L'occasion de se refaire une idée sur les EJB. + * JPA (Java Persistence API): standard implémenté par TopLink (par défaut dans GlassFish), Hibernate ou OpenJPA + * JAX-WS 2.x: nouvelle pile pour les services web + * JAXB 2.0: mise en corresponsance (mapping) XML/Java utilisée par JAX-WS 2.0 + * JSF (Java Server Faces) - Framework MVC dont Apache MyFaces et JSF RI sont des implémentations libres + * StAX - parseur de streaming XML + * JSP 2.1 & Servlet 2.5: pour faire de l'injection de dépendance dans le conteneur web Deleted: trunk/simexplorer-is/src/site/fr/rst/devel/migration.rst =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/migration.rst 2008-01-23 10:54:50 UTC (rev 426) +++ trunk/simexplorer-is/src/site/fr/rst/devel/migration.rst 2008-01-23 10:58:08 UTC (rev 427) @@ -1,190 +0,0 @@ -ToPIA Migration Service -======================= - -ToPIA Migration Service est un module ToPIA chargï¿œ d'effectuer la migration -d'une base de donnï¿œes existante sans perte de donnï¿œes. - -Configuration -------------- -Ce service doit disposer de quelques proprietï¿œs de configuration pour effectuer -la migration d'une base de donnï¿œes. - -Ces propriï¿œtï¿œs sont fournies au service via un TopiaContext et font donc partie -de la configuration de l'application. - - -Configuration de la base de donnï¿œes -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -:: - - hibernate.dialect=org.hibernate.dialect.H2Dialect - hibernate.connection.username=sa - hibernate.connection.password= - hibernate.connection.driver_class=org.h2.Driver - - topia.persistence.directories=directory1,directory2 - topia.persistence.classes=classImpl1,classImpl2 - topia.persistence.properties.file=??? - -Ces informations servent ï¿œ crï¿œer une configuration hibernate (qui contient les -informations de connexion et les mappings de l'application). - -Les lignes commencant par "hibernate" sont spï¿œcifiques ï¿œ hibernate et au type de -base de donnï¿œes utilisï¿œ. Les lignes suivantes sont spï¿œcifiques ï¿œ ToPIA mais -contiennent les mappings indispensable pour crï¿œer le schï¿œma de la base de -donnï¿œes aprï¿œs migration. - - -Configuration des mappings -~~~~~~~~~~~~~~~~~~~~~~~~~~ -La configuration doit contenir ces propriï¿œtï¿œs : - -:: - - topia.service.migration.mappingsdir=oldmappings - topia.service.migration.modelnames=model1,model2,model3 - -qui spï¿œcifie le rï¿œpertoire de recherche des anciens mappings pour les diffï¿œrents -modï¿œles. - -Ce dossier contient ensuite un sous-dossier par modï¿œle comportant chacun un -sous-dossier par version par version (nommï¿œ X, *X* ï¿œtant la version), avec pour -chaque dossier, l'ensemble des mappings hibernate de cette version. - -Exemple : - -:: - - oldmappings/ - model1/ - 1/ - Class1.hbm.xml - Class2.hbm.xml - Class3.hbm.xml - 2/ - Class1.hbm.xml - Class2New.hbm.xml - Class3.hbm.xml - 2.2/ - Class2.hbm.xml - Class3.hbm.xml - Class4New.hbm.xml - - -Configuration de la version -~~~~~~~~~~~~~~~~~~~~~~~~~~~ -La configuration doit contenir une propriï¿œtï¿œ : - -:: - - topia.service.migration.version=3.5.1 (exemple) - -Cette propriï¿œtï¿œs renseigne la version *courante* de l'application. - - -Configuration du callback -~~~~~~~~~~~~~~~~~~~~~~~~~ -Il est possible de dï¿œfinir une classe de type MigrationCallbackHandler, pour -interagir, par exemple, avec l'utilisateur et lui demander s'il faut migrer la -base de donnï¿œes. - -Ces //callback// doivent implï¿œmenter MigrationCallbackHandler et se trouver dans -la configuration: - -:: - - topia.service.migration.callbackhandlers=org.codelutin.test.SwingCallbackHandler - - -Configuration du service -~~~~~~~~~~~~~~~~~~~~~~~~ -Enfin pour utiliser le service, il faut l'activer. La configuration doit -contenir la propriï¿œtï¿œs suivante : - -:: - - topia.service.migration=org.codelutin.topia.security.TopiaSecurityServiceImpl - - -Utilisation ------------ -Ce module ï¿œtant un service ToPIA, il doit ï¿œtre activï¿œ pour pouvoir s'exï¿œcuter. - -Il commence par se connecter au SGBD, vï¿œrifie si les versions diffï¿œrent, et -effectue la migration si besoin. - -Classes de migration -~~~~~~~~~~~~~~~~~~~~ -Pour savoir comment migrer les donnï¿œes, le dï¿œveloppeur utilisant le module de -migration doit produire des classes Java de migration (une par classe -nï¿œcï¿œssitant une modification et par version). - -Ces classes doivent : - -- hï¿œriter de la classe ``AbstractMigration`` ou de l'interface ``Migration`` -- se trouver dans un sous package des classes d'implï¿œmentation rï¿œfï¿œrencï¿œes - par les mappings. Ce package doit se nommer VnVm oï¿œ: - - - *n* est la version de dï¿œpart de migration - - *m* la version d'arrivï¿œe - -- respecter une convention de nommage de la forme - MigrationClass oï¿œ: - - - *Class* est le nom de l'entitï¿œ devant ï¿œtre migrï¿œe - - Exemple, pour migrer une Personne d'une version 2 ï¿œ 2.1: - ``V2V2_1.MigratePersonne.java`` - - Note: les "." ï¿œtant interdits dans le nom de fichier, ils sont remplacï¿œs par - le caractï¿œre "_". - -Ensuite, chaque classe doit : - -- implï¿œmenter au moins la mï¿œthode ``migrate(MapAdapter, MapHelper)`` - cette mï¿œthode prend une MapAdapter en paramï¿œtre, pour modifier un tuple et un - MapHelper pouvant servir ï¿œ retrouver des informations sur le reste des tuples - de la base -- surcharger (si besoin) la mï¿œthode ``public ProxyClass migrateFrom()`` dans le - cas oï¿œ les tuples ï¿œ modifier proviennent d'une classe diffï¿œrente de la classe - courante. - -Exemple : - -Ici, la modification porte sur la transformation de l'attribut ``timestampNaissance`` -de la classe ``domaine.Personne`` en une nouvelle table ``domaine.Naissance``, effectï¿œe -dans le changement de la version 1 ï¿œ la version 2 : - -:: - - // migrateFrom() - public ProxyClass migrateFrom() { - return new SimpleProxyClass("domaine.Personne"); - } - - // migrate(MapAdapter, MapHelper) - public void migrate(MapAdapter map, MapHelper helper) { - - // map d'entree vide, conversion du timestamp - // en jour, mois, annee - try { - Long timestamp = (Long) map.getOldValue("timestampNaissance"); - Calendar c = Calendar.getInstance(); - c.setTimeInMillis(timestamp); - map.setValue("jour", c.get(Calendar.DAY_OF_MONTH)); - map.setValue("mois", c.get(Calendar.MONTH)); - map.setValue("annee", c.get(Calendar.YEAR)); - } catch (ExceptionAttributeUndefined e) { - e.printStackTrace(); - } - } - -Donc cette classe : - -- doit se nommer ``MigrateNaissance.java`` et se trouver dans le package - ``domaine.V1V2`` -- redï¿œfinit la methode migrateFrom() pour indiquer que les donnees proviennent de - ``domaine.Personne`` -- implï¿œmente ``migrate()`` pour produire des tuples de type ``domaine.Naissance`` - ï¿œ partir de tuples ``domaine.Personne`` Added: trunk/simexplorer-is/src/site/fr/rst/devel/migration.txt =================================================================== --- trunk/simexplorer-is/src/site/fr/rst/devel/migration.txt (rev 0) +++ trunk/simexplorer-is/src/site/fr/rst/devel/migration.txt 2008-01-23 10:58:08 UTC (rev 427) @@ -0,0 +1,190 @@ +ToPIA Migration Service +======================= + +ToPIA Migration Service est un module ToPIA chargï¿œ d'effectuer la migration +d'une base de donnï¿œes existante sans perte de donnï¿œes. + +Configuration +------------- +Ce service doit disposer de quelques proprietï¿œs de configuration pour effectuer +la migration d'une base de donnï¿œes. + +Ces propriï¿œtï¿œs sont fournies au service via un TopiaContext et font donc partie +de la configuration de l'application. + + +Configuration de la base de donnï¿œes +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:: + + hibernate.dialect=org.hibernate.dialect.H2Dialect + hibernate.connection.username=sa + hibernate.connection.password= + hibernate.connection.driver_class=org.h2.Driver + + topia.persistence.directories=directory1,directory2 + topia.persistence.classes=classImpl1,classImpl2 + topia.persistence.properties.file=??? + +Ces informations servent ï¿œ crï¿œer une configuration hibernate (qui contient les +informations de connexion et les mappings de l'application). + +Les lignes commencant par "hibernate" sont spï¿œcifiques ï¿œ hibernate et au type de +base de donnï¿œes utilisï¿œ. Les lignes suivantes sont spï¿œcifiques ï¿œ ToPIA mais +contiennent les mappings indispensable pour crï¿œer le schï¿œma de la base de +donnï¿œes aprï¿œs migration. + + +Configuration des mappings +~~~~~~~~~~~~~~~~~~~~~~~~~~ +La configuration doit contenir ces propriï¿œtï¿œs : + +:: + + topia.service.migration.mappingsdir=oldmappings + topia.service.migration.modelnames=model1,model2,model3 + +qui spï¿œcifie le rï¿œpertoire de recherche des anciens mappings pour les diffï¿œrents +modï¿œles. + +Ce dossier contient ensuite un sous-dossier par modï¿œle comportant chacun un +sous-dossier par version par version (nommï¿œ X, *X* ï¿œtant la version), avec pour +chaque dossier, l'ensemble des mappings hibernate de cette version. + +Exemple : + +:: + + oldmappings/ + model1/ + 1/ + Class1.hbm.xml + Class2.hbm.xml + Class3.hbm.xml + 2/ + Class1.hbm.xml + Class2New.hbm.xml + Class3.hbm.xml + 2.2/ + Class2.hbm.xml + Class3.hbm.xml + Class4New.hbm.xml + + +Configuration de la version +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +La configuration doit contenir une propriï¿œtï¿œ : + +:: + + topia.service.migration.version=3.5.1 (exemple) + +Cette propriï¿œtï¿œs renseigne la version *courante* de l'application. + + +Configuration du callback +~~~~~~~~~~~~~~~~~~~~~~~~~ +Il est possible de dï¿œfinir une classe de type MigrationCallbackHandler, pour +interagir, par exemple, avec l'utilisateur et lui demander s'il faut migrer la +base de donnï¿œes. + +Ces //callback// doivent implï¿œmenter MigrationCallbackHandler et se trouver dans +la configuration: + +:: + + topia.service.migration.callbackhandlers=org.codelutin.test.SwingCallbackHandler + + +Configuration du service +~~~~~~~~~~~~~~~~~~~~~~~~ +Enfin pour utiliser le service, il faut l'activer. La configuration doit +contenir la propriï¿œtï¿œs suivante : + +:: + + topia.service.migration=org.codelutin.topia.security.TopiaSecurityServiceImpl + + +Utilisation +----------- +Ce module ï¿œtant un service ToPIA, il doit ï¿œtre activï¿œ pour pouvoir s'exï¿œcuter. + +Il commence par se connecter au SGBD, vï¿œrifie si les versions diffï¿œrent, et +effectue la migration si besoin. + +Classes de migration +~~~~~~~~~~~~~~~~~~~~ +Pour savoir comment migrer les donnï¿œes, le dï¿œveloppeur utilisant le module de +migration doit produire des classes Java de migration (une par classe +nï¿œcï¿œssitant une modification et par version). + +Ces classes doivent : + +- hï¿œriter de la classe ``AbstractMigration`` ou de l'interface ``Migration`` +- se trouver dans un sous package des classes d'implï¿œmentation rï¿œfï¿œrencï¿œes + par les mappings. Ce package doit se nommer VnVm oï¿œ: + + - *n* est la version de dï¿œpart de migration + - *m* la version d'arrivï¿œe + +- respecter une convention de nommage de la forme + MigrationClass oï¿œ: + + - *Class* est le nom de l'entitï¿œ devant ï¿œtre migrï¿œe + + Exemple, pour migrer une Personne d'une version 2 ï¿œ 2.1: + ``V2V2_1.MigratePersonne.java`` + + Note: les "." ï¿œtant interdits dans le nom de fichier, ils sont remplacï¿œs par + le caractï¿œre "_". + +Ensuite, chaque classe doit : + +- implï¿œmenter au moins la mï¿œthode ``migrate(MapAdapter, MapHelper)`` + cette mï¿œthode prend une MapAdapter en paramï¿œtre, pour modifier un tuple et un + MapHelper pouvant servir ï¿œ retrouver des informations sur le reste des tuples + de la base +- surcharger (si besoin) la mï¿œthode ``public ProxyClass migrateFrom()`` dans le + cas oï¿œ les tuples ï¿œ modifier proviennent d'une classe diffï¿œrente de la classe + courante. + +Exemple : + +Ici, la modification porte sur la transformation de l'attribut ``timestampNaissance`` +de la classe ``domaine.Personne`` en une nouvelle table ``domaine.Naissance``, effectï¿œe +dans le changement de la version 1 ï¿œ la version 2 : + +:: + + // migrateFrom() + public ProxyClass migrateFrom() { + return new SimpleProxyClass("domaine.Personne"); + } + + // migrate(MapAdapter, MapHelper) + public void migrate(MapAdapter map, MapHelper helper) { + + // map d'entree vide, conversion du timestamp + // en jour, mois, annee + try { + Long timestamp = (Long) map.getOldValue("timestampNaissance"); + Calendar c = Calendar.getInstance(); + c.setTimeInMillis(timestamp); + map.setValue("jour", c.get(Calendar.DAY_OF_MONTH)); + map.setValue("mois", c.get(Calendar.MONTH)); + map.setValue("annee", c.get(Calendar.YEAR)); + } catch (ExceptionAttributeUndefined e) { + e.printStackTrace(); + } + } + +Donc cette classe : + +- doit se nommer ``MigrateNaissance.java`` et se trouver dans le package + ``domaine.V1V2`` +- redï¿œfinit la methode migrateFrom() pour indiquer que les donnees proviennent de + ``domaine.Personne`` +- implï¿œmente ``migrate()`` pour produire des tuples de type ``domaine.Naissance`` + ï¿œ partir de tuples ``domaine.Personne`` Property changes on: trunk/simexplorer-is/src/site/fr/rst/devel/migration.txt ___________________________________________________________________ Name: svn:executable + *