Page History

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Détails de l'implémentation

ori-oai-workflow-spring

 

Interactions des différentes technos avec Spring

...

L'implémentation est relativement aisée : *

  • Côté Spring, XFire est utilisé, il permet d'exposer très simplement un Bean Spring (ses méthodes) en SOAP. Il permet d'utiliser un service Web tout aussi simplement : le service Web est accessible sous forme de Bean dans l'application.
  • Côté Orbeon Forms, SOAP est supporté par Orbeon Forms, l'appel à un WebService SOAP se fait simplement via un fichier XPL.

...

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 : *

  • Les données d'Acegi Security sont rendues persistantes via une implémentation Hibernate d'Acegi.
  • Nous avons implémenté le modèle RBAC, ainsi par rapport à l'implémentation de base de Acegi nous avons : ***
    • des rôles et des permissions définis sur les objets de type OriAclObjectIdentity, chaque objet étant associé (1/1) à un objet de type OriObjectAclAware (dont héritent WorkflowInstance et Entry)
      • un système d'héritage d'objets OriAclObjectIdentity permettant de faire hériter les rôles et permissions d'un parent à un fils
      • une possibilité de définir des permissions et rôles sur l'objet racine de l'arbre d'héritage des objets OriAclObjectIdentity, cela via un fichier de configuration Spring
      • un système de mask où un rôle est définie par sa cible (un objet OriAclObjectIdentity), un recipient (le nom d'un groupe ou d'un utilisateur) et un mask (un entier) alors qu'une permission est définie par sa cible (un objet OriAclObjectIdentity), un recipient (le mask d'un rôle) et un mask (un entier)

...

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.
  • Le fait cependant d'utiliser les mêmes beans au travers des différentes couches peut cependant, si on n'y prend garde, peut impliquer un certain nombre de contraintes/inconvénients.
    Cela implique par exemple que les attributs d'un même bean peuvent avoir des persistences différentes : persistence via Hibernate, OsWorkflow ou encore attribut transient ... ce qui peut perturber un dévelopeur découvrant le code.
    Les objets de type WorkflowInstance en sont un exemple parfait. Afin que le développeur s'y retrouve au mieux, il est donc important que les commentaires JavaDoc sur les attributs des beans soient le plus précis possible sur le mode de persistence utilisé.
    De même les beans doivent répondre à la fois aux contraintes données par leur utilisation dans JSF et dans Hibernate. Mais là encore, il est intéressant de constater que l'utilisation du même type de bean à la fois dans Hibernate et dans JSF permet par exemple une implémentation simple d'un Converter JSF (voir même d'un converter générique, comme cela a été fait pour ORI-OAI-Workflow).

...

La partie services se compose de plusieurs sous parties. *

  • La partie située dans le package org.ori.workflow.services.acls est spécifique à la sécurité de l'application. La majeure partie de ce package (qu'il faut mettre en relation avec le package org.ori.workflow.beans.acls) correspond à l'implémentation d'Acegi Security. AclWorkflowService est la classe instanciée pour correspondre au bean spring à mettre en relation avec le reste de l'application ori-oai-workflow.
  • WorkflowService appelle à la fois la partie DAO et OsWorkflow.
  • OriFunctions4OSWF ainsi que l'ensemble du package org.ori.workflow.services.oswfhelper correspondent aux beans appelés par OsWorkflow lors des fonctions et conditions paramétrés dans les workflows.

...