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.

...

• Côté Orbeon Forms, SOAP est supporté par Orbeon Forms, l'appel à un WebService SOAP se fait simplement via un fichier XPL.

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.

...

• Il est possible d'ajouter/supprimer les masks de permissions et rôles disponibles dans l'application
• Une api permet de supprimer, ajouter vérifier un rôle ou une permission sur un objet de type OriAclObjectIdentity (cette api est notamment utilisée via les fonctions/conditions paramétrées dans les workflows OsWorkflow).

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.

• La plupart des beans ainsi que la plupart de leurs attributs sont persistants via Hibernate, ils servent aussi dans le même temps comme DTOs : en fait c'est eux qui sont chargés d'information tout au long des couches Dao et Service puis qui sont directement présentés voir modifiés depuis les contrôleurs webs (cf la section "Architecture par couches" plus bas).
• Certains beans/attributs sont persistants dans les configs Spring uniquement, ils permettent de paramétrer l'application.
• Enfin d'autres sont simplement transients.

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. * L'intérêt évident est que les différentes couches s'appuient ainsi sur les mêmes types de données, l'ensemble du code de l'application est ainsi très flexible et léger : l'ajout d'une donnée en tant qu'attribut de bean de la persistence à sa représentation côté web requiert par exemple des modifications très restreintes.

...