Valoriser le patrimoine numérique scientifique, pédagogique et documentaire des universités et le partager par un réseau de portails communicants en OAI

Vous pouvez retrouver des paragraphes sur nos choix techniques ici pour
le module ori-oai-workflow :
http://sourcesup.cru.fr/ori-workflow/specification.html#1
Je peux compléter si nécessaire, mais à ma connaissance, les 2 grands
choix possibles dans un cadre J2EE à ce moment là était JBPM et
OsWorkflow. Par rapport aux technologies utilisées OsWorkflow convenait
tout à fait à nos besoins (intégration dans spring [spring modules],
hibernate, dépendant de très peu d'autres API, etc. cf la documentation
donc).

Concernant la version utilisée, pour être très précis, c'est la version
cvs de la branche 3.0 récupérée le 12/08/06.
Nous l'avons patchée pour contournée un bug dans celle-ci (présent aussi
dans la 2.8.0) : http://jira.opensymphony.com/browse/WF-427
Cette version correspond en fait à peu de choses près à une 2.8.0, mais
avec quelques issues de fixées en plus. Notamment la possibilité
d'étendre plus facilement le AbstractWorkflow ... (cf les issues
d'osworkflow sur opensymphony)
On était aussi passé à cette version en espérant que d'ici la fin de nos
développements, osworkflow aurait fait une release, en fait il n'en est
rien (et d'ailleurs notre patch n'a pas été intégré ... et nous n'avons
pas pris le temps de le retravailler comme demandé, et c'est un tort
...). A priori effectivement depuis la 2.8.0 peu de choses ont changé.
On n'a eu aucun problème avec la version que l'on a et que l'on a ainsi
considéré comme stable.

Pourquoi osworkflow ne bouge plus vraiment ? Ici, je ne pense pas qu'on
puisse dire que le projet est "mort" dans le sens où a priori (on
pourrait vérifier) il y a un certain nombre d'utilisateurs OsWorkflow
(de librairie qui l'utilisent etc.). Je dirai que le projet est
suffisamment mature et répond suffisamment bien à la problématique des
projets qui l'utilisent si bien que personne n'a envie de consacrer du
temps à le faire évoluer plus que cela ...

Maintenant pour les applications graphiques permettant de configurer ce
genre de choses qui restent très techniques, voici mon avis personnel
(pas forcément partagés par tous, je ne sais pas). En premier lieu j'ai
clairement toujours quelques doutes sur les outils d'administration de
type clickodrome (qui je le reconnais peuvent parfois sembler séduisants
...) pour un certain nombre de raisons ... c'est peut-être un tort ...
mais le débat serait long et fastidieux !
En tout cas développer puis maintenir une telle application me parait
trop lourd notamment par rapport au peu d'intérêt que l'on peut à mon
avis en retirer au final (et notamment dans ori-oai) : l'édition du XML
d'OsWorkflow n'est pas ce qu'il y a de plus compliqué en soit. De plus
même si la configuration de workflows osworkflow constitue la
configuration centrale et première dans ori-oai-workflow, techniquement
c'est un fichier XML à configurer parmi d'autres.

Le plus complexe est certainement de savoir ce que l'on veut faire dans
son établissement, comment on s'organise etc.
Pour ce faire, schématiser l'ensemble avec un outil comme dia est par
exemple une bonne solution. Exemple ici :
http://sourcesup.cru.fr/ori-workflow/media/workflow_model_1.dia.png
En plus du workflow, il faut également formaliser l'ensemble des besoins
: qui fait quoi : qui est dans quel groupe, quel groupe à quel rôle,
quel rôle voit quoi, etc.

Une fois le besoin bien formalisé, c'est effectivement à un
informaticien d'implémenter la chose sous la forme des fichiers de
configurations disponibles dans oir-oai-workflow : fichier de
configuration osworkflow mais aussi les configurations Spring Acegi, les
mappings des groupes avec le ldap, etc.

Il en va de même pour chaque module (notamment donc l'interface de
recherche) : on formalise les besoins (en n'oubliant pas d'inclure le
technique dans le groupe de travail) puis on demande au technique
d'implémenter au mieux la chose (sous le contrôle du fonctionnel) ... et
je ne suis pas sûr donc qu'un outil graphique élaboré (et donc forcément
[très] complexe - difficile à documenter, à débuguer, etc.) qui
masquerait les fichiers de configurations XML auraient un apport si
conséquent.

[pour finir l'application graphique pour OsWorkflow n'a je crois jamais
été recommandée, celle-ci restait expérimentale (présentée clairement
comme telle) et était plus selon moi destinée à démontrer les capacités
d'OsWorkflow en lui-même ... et c'est vrai que c'est assez sympa à
manipuler ... je cromprends que cela fasse rêver ! ;-) ]

En espérant avoir répondu au mieux,
Cordialement,
Vincent Bonamy.

francoise.schortin@u-psud.fr wrote:

--
Ce message a