3.4.3 Seconde
réalisation : Polling fichier / Transformation / Transfert FTP
Cette réalisation doit répondre aux exigences
suivantes :
q Mettre l'accent sur l'interopérabilité des
architectures SOA,
q Mise en place d'une politique de contrat de service,
q Prise en compte des spécificités SOAml.
Pour ce faire, la seconde réalisation doit être
réalisée sur la base d'un autre outil de modélisation et
une plate forme technique différente. Le modeleur Magicdraw sera
remplacé par un autre ou complété d'un pluging
intégrant le profil SOAml et Websphere sera préféré
à Netbeans. L'idée est de vérifier les possibilités
d'échange à la fois entre les deux modeleurs supportant une
interface XMI et la portabilité du code généré sur
une nouvelle plateforme technique.
Pour ce qui est du contrat de service, ce sera l'occasion
d'introduire le langage OCL dans la modélisation et d'observer son
impact sur le déploiement.
L'objectif de ce chapitre est de
répondre à la question posée par le sujet de ce
mémoire, ou autrement exprimé, de définir la valeur d'une
mise en place d'une architecture SOA, pour le Groupe Terrena.
3.4.4 Résultats obtenus
3.4.4.1 Première réalisation
La première réalisation n'a pas posé de
problème dans le sens où les contraintes étaient
faibles :
q Le processus était élémentaire, sans
introduction de contrat de service complexe,
q Les composants de l'offre SUN sont à la fois riches,
stables et bien documentés,
q La modélisation a permis d'obtenir une ossature de
code,
q On peut saluer une réelle prise en compte du monde
XML par Oracle (même s'il ne faut pas se laisser tenter par un
cloisonnement Oracle ...).
Cependant, cette expérimentation ne doit pas cacher
une réalité plus complexe :
q Le processus expérimenté, même s'il
répondait à un besoin métier, était principalement
constitué de briques techniques,
q Le code a dû faire l'objet de compléments et
d'adaptations avant d'être opérationnel, car comme le dit un
proverbe chinois « les modèles font d'excellents serviteurs
mais de bien mauvais maîtres ». L'état actuel du BPMN
n'enchaîne pas les différents modèles UML permettant de
générer le code attendu pour une architecture SOA appuyée
d'un ESB,
q La modélisation a cruellement manqué du
nouveau profil SOAml spécifié début 2009, mais apparu dans
les modeleur MagicDraw et Objecteering que courant mars,
q L'ESB devient un point névralgique. En cas de panne
de ce dernier, le système d'information tout entier est paralysé.
Des recherches complémentaires sont réalisées afin de
s'assurer de la disponibilité de notre architecture en cas de panne des
communications avec le serveur d'hébergement de l'ESB.
Isoler la valeur d'une telle mise en place, n'est pas chose
simple et bien que les outils ne constituent pas à eux seuls une
architecture SOA, ils sont néanmoins nécessaires dans la phase
d'industrialisation.
Avant tout chiffrage, il y a des avancées qu'il n'est
pas facile d'évaluer, mais que l'on peut lister :
q la définition d'un référentiel et
d'une sémantique d'entreprise,
q la construction de modèles avec les métiers,
permettant à ces derniers de devenir de réels acteurs et
propriétaires des processus les concernant.
Une fois ce premier niveau de maturité atteint,
d'autres sources de valeur, toutes aussi délicates à valoriser,
peuvent être dégagées, telles que l'optimisation des
processus grâce à la mise en place d'indicateurs.
Mais la démarche est au moins aussi importante que
l'architecture SOA. Les nouvelles spécifications SOAml en sont un
exemple. Une fois la phase d'étude achevée, le
développement doit impérativement être en lien direct avec
la modélisation qui reste, une fois couplée à la couche
métier (BPMN), l'interface visible et compréhensible par l'acteur
Métier.
| 
