Détails de l'implémentation

ori-oai-workflow-spring

 

Interactions des différentes technos avec Spring


JSF


JSF allié à Spring permet de faire tourner l'application aussi bien en mode servlet (dans un conteneur de servlets) qu'en mode portlet (dans un conteneur de portlets et donc dans un environnement Esup par exemple). JSF fournit les éléments pour récupérer les paramètres liés au contexte de l'exécution de l'application (la requête, la session, les paramètres init, et donc l'utilisateur connecté, etc...).

SOAP


Cf précédemment. On utilise ici un protocole maison en Soap (Web Service) pour faire interagir Spring et Orbeon Forms.

On utilise également SOAP pour interagir avec les autres modules de ORI.

L'implémentation est relativement aisée :

SpringOsWorkflow


Cf précédemment. Permet d'appeler une instance d'OsWorkflow depuis Spring. OsWorkflow a l'énorme avantage de pouvoir iutégrer l'appel à des méthodes de Bean Spring en tant que conditions et fonctions d'un workflow.

Hibernate


Les données de l'application Spring sont stockées dans une BD SQL via Hibernate, Hibernate qui s'intègre parfaitement dans une applciation Spring. A noter que la configuration Hibernate Spring est utilisée également par OsWorkflow pour gérer la persistance.

Compass/Lucène


Permet d'indexer, rechercher et naviguer plus rapidement dans les fiches. On utilise Compass via Spring en le synchronisant directement sur les transactions Hibernate.

SpringLdap


Ldap sert à l'application de base de données utilisateurs/groupes. De même que pour les autres technos, Spring fournit des beans permettant d'interagir avec Ldap. Ils sont utilisés au travers d'Acegi.

Acegi Security


Acegi Security permet de gérer tout l'aspect security de l'application.

Acegi Security communique avec les sources de données utilisateurs/groupes pour l'authentification ainsi que comme base utilisateurs pour l'implémentation de RBAC (Role Based Access Control).

Acegi Security propose de base une implémentation d'une politique de sécurité de l'application. L'implémentation qui en a été faite en est ici tout autre :

Beans/Pojos Ori-Oai-Workflow-Spring


Le diagramme ci-dessous donne le diagramme de classes des beans/pojos utilisés dans Ori-Oai-Workflow-Spring. Il ne donne pas les beans/pojos issus de OsWorkflow.

Architecture par couches


Comme dit plus haut, les beans (package org.ori.workflow.beans, qui sont en fait des pojos) sont transversaux aux couches de l'application. Ils représentent à la fois les données persistantes, les données récoltées via la couche service et les données visualisées voir éditées au niveau de la couche Web.

Tout comme le préconise Esup-Commons, tous les beans springs (on ne parle plus ici des beans pojos mais bien des beans springs) sont configurés via les fichiers de configuration spring. Cela permet d'uniformiser la déclaration des différents beans spring et de tirer partie au mieux de Spring IDE (dans Eclipse).

Au niveau de la couche de présentation dirigée par JSF, on associe à chaque page jsf un controller. Ce controller permet de récupérer et sauver les beans/pojos de l'application. Le choix a été pris de configurer les controllers JSF comme des beans spring de scope request. Un contexte applicatif est cependant maintenu en sauvant les états des beans/pojos d'une requête à une autre via la balise t:savestate de MyFaces Tomahawk. De même le bean/pojo UserContext par exemple est de scope session (mais tous les controllers sont bien quant à eux de scope request).

La partie services se compose de plusieurs sous parties.

La partie DAO utilise hibernate pour la persistence de données. A noter que la session hibernate est gérée (ouverture/fermeture) par Esup Commons : on utilise en effet l'implémentation de Servlet/Portlet fournie par Esup Commons.