3 Troisième Volet :
Réalisation
La réalisation va être réalisée
autour d'un ESB acquis en 2007 et non encore déployé sur
deux plateformes NETBEANS puis WEBSphère afin d'illustrer
l'interopérabilité. Nous tenterons de respecter le cadre
modélisé dans le chapitre précédent et nous
appuierons sur l'architecture suivante :
q l'utilisation de langages universels et standards du
W3C : XML, XSLT, Xquery, SOAP,
q l'exposition des procédures stockées,
q un Repository,
q des Application découplées du modèle
de données,
q Un ESB, chef d'orchestre des échanges
inter-application.
Peu importe l'émetteur du document
?
OE
Document XML
Document Csv
Procédures
Repository
Application Semences
Datamart Céréales
GCR
_
Document XML
SOAP Request
(Web Service)
Legacy
Document XML
Document XML
Illustration 130 : Cycle de
vie d'un document XML Tiers
_
Les étapes de ce volet de réalisation vont
être de constituer le format Pivot Terrena, puis de rassembler tant, les
règles de transformations, que le vocabulaire commun.
Puis les composants modélisés
précédemment tel que les Web Service, les transformations, le
routage et les chargements seront réalisés et orchestrés
dans notre architecture choisie.
3.4 Étapes de la réalisation
La stratégie adoptée pour la constitution de
notre format pivot a consisté à convenir d'un format issu d'un
balisage normalisé, si possible du domaine public comme ceux de la Poste
ou de l'INSEE, de l'ISO etc ... et d'y greffer le balisage spécifique au
monde coopératif (Projet GIEA), tout en y intégrant des balises
« privées », propres à nos applicatifs
métiers.
Des services agissant comme des passerelles sur ce format
pivot pourront répondre à deux types de besoins : la
conversion du format pivot vers un format propriétaire, la conversion
d'un format propriétaire vers le format pivot.
Ces passerelles seront matérialisées par des
transformations de nature XSLT quand il s'agira de transformation de et vers
XML, et java quand il s'agira de transformations sur des formats source et
cible hétérogènes.
Le routage s'appuiera sur le référentiel afin
d'alimenter les applications Clientes qui consommeront les documents XML
transmis.
3.4.1
L'environnement Technique
La persistance des données est
assurée par un noyau Oracle 11g. Ce choix a
été fait en raison des atouts multiples de cette
version :
q Web Service natifs pour accéder à toute
procédure ou fonction de la base oracle. La version
précédente imposait l'utilisation d'un OC4J (Oracle Componant for
J2ee) pour les déployer.
q La gestion des données XML et des schémas XML
via le paquetage XML DB,
q L'indexation possible des documents Xml avec XMLIndex et
B-Tree,
q La gestion interne des schémas à partir du
type de donnée XMLType,
q Le développement possible en Xpath et
disponibilité de paquetages HTP.
L'ESB retenu est celui de SUN :
OpenESB mis à disposition depuis décembre 2008
au sein d'une nouvelle plateforme d'intégration SOA. Cette
dernière est constituée de l'assemblage des solutions
arrivées à maturité chez SUN : Glassfich Application
Server 2.1 R2, l'IDE Netbeans 6.5.1. et l'ESB OpenESB. Il est
ainsi possible de :
q Modéliser et exécuter des processus BPEL
d'orchestration de services,
q D'architecturer (Wsdl) et d'orchestrer
(Bpel),
q De développer en respectant les exigences
d'interopérabilité (XML, XSLT, XPATH ...),
q D'exécuter des applications composites dans le souci
de réutilisation des services (Service Assembly et Service Unit).
L'explorateur à partir duquel les web Services sont
invoqués est IE. Cependant il sera
vérifié que FireFox produit le même
résultat.
Deux réalisations distinctes seront
réalisées : une première, simple, afin de construire
et d'assembler les composants de base à notre architecture cible, une
seconde plus élaborée intégrant les notions de contrat de
service par exemple, ainsi que les récentes spécifications SOAml.
L'orchestration sera abordée dès la première
réalisation.
Afin d'illustrer l'interopérabilité, la seconde
réalisation sera réalisée sur une autre plate-forme
(WebSphère d'IBM). Les composants de la première
réalisation devront pouvoir être transposés dans la seconde
architecture (modélisation et technique).
| 
