Ce paragraphe définit les choix techniques pris après réflexions, tests, etc. Ces choix ont été fonction des technos, de leur efficacité par rapport aux besoins, de leur souplesse mais aussi de leur robustesse, de l'expérience de chacun, des habitudes et technos usités dans la communauté ESUP Portail, etc.
OsWorkflow
OSWorkflow est un produit OpenSource d'OpenSymphony.
OSWorkflow est une bonne solution de Workflow dans le monde de l'OpenSource. On constate qu'il est utilisé dans différents produits et qu'il est choisi par des projets +/- similaires à ORI.
Une de ses principales spécificités est de fonctionner de manière autonome. La servlet d'exemple fournie par défaut et qui tourne sans aucune configuration le montre bien, OSWorkflow peut fonctionner seul. Il est aisé de pluguer OSWorkflow à une application déjà existante. OSWorkflow peut ainsi être vu comme un composant réellement indépendant dans ORI-OAI-Workflow. La possibilité qu'il offre de le commander via de simples appels WEBService (SOAP) le prouve également.
OSWorkflow gère de manière autonome tout ce qui concerne le Workflow. Les Workflows (diagrammes états-transitions) se configurent via un fichier XML. Une Application Graphique Java peut permettre de créer/modifier des Workflows (attention : cela reste cependant avant tout expérimental). Les Workflows peuvent être relativement complexes. Ils permettent d'appeller des scripts Java BeanShells lors d'une transition (ou mieux encore des méthodes définies dans des "beans spring", et c'est ce qui nous intéresse ici), de faire des splits/joins, de mettre des conditions de tous types sur des transitions (par exemple des conditions sur l'appartenance d'un utilisateur à un rôle), de définir des permissions en fonction des états, etc.
Indépendant, OSWorkflow peut s'utiliser avec sa propre base de données (en tout cas, il gère ses propres tables). L'édition des workflows se fait de manière indépendante du reste de l'application, en éditant le fichier XML OSWorkflow avec un simple éditeur texte. L'indépendance de OsWorkflow ne gêne pas son intégration complète dans le module ORI-OAI-Workflow : on utilise OsWorkflow conjointement à spring, ce qui permet d'utiliser des méthodes spécifiques au module ORI-OAI-Workflow en tant que fonctions et conditions dans des workflows OsWorkflow. Aussi les possibilités du module ORI-OAI-Workflow en matière de conditions ou de fonctions à appeler lors de transitions sont facilement extensibles et cela fait partie des gros points forts de ce module.
Esup-Commons
Esup-Commons permet de mettre en place (et de façon standard par rapport aux développements Esup) une architecture basée sur Spring-Hibernate-JSF (le framework général de l'application étant Spring : conteneur léger), packagée au mieux, pensée pour les mises à jours futures, pouvant tourner à la fois (avec le même code) en mode portlet et en mode standalone.
Esup Commons est, au vue d'une application comme Ori-Oai-Workflow, une proposition d'architecture représentant des facilités de développement et déploiement. Nous utilisons dans Ori-Oai-Workflow certaines fonctionnalités de Esup Commons.Ainsi la gestion des exceptions et l'utilisation de Hibernate sont gérées via Esup Commons, tout comme les envois de message via SMTP. Par contre l'authentification est par exemple gérée par Acegy Security et non Esup Commons.
http://www.esup-portail.org/display/PROJCOMMONS
JSF
Bien que l'accent concernant l'ergonomie et l'IHM soit d'abord mis sur les formulaires d'édition, on souhaite avoir une IHM efficace tout le long de l'application. JSF se couple parfaitement avec Spring.
L'implémentation choisi de JSF est MyFaces qui semble être l'implémentation OpenSource de référence. On utilise cependant d'autres librairies JSF comme Jenia par exemple.L'utilisation de JSF via Esup Commons nous permet d'avoir un code unique pour les 2 versions d''Ori-Oai-Workflow : mode portlet et mode standalone.
http://java.sun.com/javaee/javaserverfaces/
http://myfaces.apache.org/
http://www.jenia.org/
Base de données SQL
Le choix a été fait d'utiliser une Base de Données SQL transactionnelle unique pour l'ensemble de l'application. Pour manipuler la base de données depuis l'application, le choix s'est porté sur Hibernate qui s'intègre bien dans Spring. Il est simple à configurer et à utiliser notamment lorsqu'il n'y a pas de BD pré-existante (c'est à dire lorsque la structuration de la base de données est conçue pour les besoins de l'application développée, comme c'est le cas ici).
Hibernate
Framework de mapping objet-relationnel (MySql)
http://www.hibernate.org/
http://www-fr.mysql.com/
Acegi Security
Acegi Security est la solution en terme de sécurité intégrée dans une application Spring.
Acegi Security est un produit complexe qui couvre un grand nombre d'aspects autour de la sécurité : "authentication " + "authorisation". Il permet surtout de sécuriser en fonction des rôles de l'utilisateur les appels à des méthodes, les urls.
ORI-OAI-Workflow utilise Acegi Security pour :
- la gestion de l'authentification.,
- la gestion de RBAC (Role Based Access Control) qui est le Design Pattern décrivant le fait que l'on assigne les permissions à des rôles et non directement aux "Principals" (~ Groupes et Utilisateurs), cf la
- et donc la gestion des autorisations.
Ainsi Acegi a été utilisé comme base pour implémenter une solution de RBAC.
http://www.acegisecurity.org/
XFire
Pour la communication entre Spring et Orbeon OPS, ainsi que la communication inter-modules
http://xfire.codehaus.org
Conteneur - uPortal
ORI-OAI-Workflow peut fonctionner dans un ESUP-Portail. Il est décliné sous forme de JSR168. ORI-OAI-Workflow peut également fonctionner sans ESUP, il fonctionne alors de manière "standalone" en tant que servlet.
Ldap - CAS - Shibboleth
Dans ORI-OAI-Workflow, la gestion d'utilisateurs/groupes peut se faire via un ldap (et donc via un openldap/phpldapadmin local par exemple si le système d'information dans lequel ORI-OAI-Workflow se déploie n'a pas de système de gestion de son ldap) ou via shibboleth.
La récupération des utilisateurs et des groupes par ORI-OAI-Workflow sur le ldap ou via shibboleth est à configurer dans des fichiers de configuration. Il est à noter que ORI-OAI-Workflow est capable de définir des nouveaux groupes "virtuels" via des filtres Ldap configurées dans le module ORI-OAI-Workflow (ce qui peut s'avérer pratique).
L'authentification peut se faire via LDAP, CAS ou Shibboleth.
Compass
Technologies communes
Ainsi que toutes les technologies communes à tous les modules.
ORI-OAI-Workflow est géré par le framework Spring et répond en JSR168 (Portlet) ou mode standalone (Servlet). Il contient toute la logique applicative. Il fait appel à OSWorkflow pour afficher les informations relatives aux états dans lesquels se trouvent les workflows et pour procéder à des actions sur les états (transitions). Il propose ainsi à l'utilisateur certaines actions sur les entrées de MétaDonnées qu'il liste : faire une transition sur le workflow correspondant à l'entrée, éditer la fiche XML de l'entrée (et donc appeler un formulaire Orbeon Forms), etc. Il intègre également complètement OSWorkflow.
OSWorkflow gère tout ce qui est relatif au Workflow a proprement parlé. il contient et propose les informations relatives aux états des workflows, les transitions possibles, les permissions que l'utilisateur courant a par rapport au rôle dans lequel il est, etc. Il appelle la partie principale lors des conditions et fonctions paramétrées dans les workflow.