WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Architecture SOA (Architecture Orientée Services ). Quelle source de valeur pour le Groupe Terrena?

( Télécharger le fichier original )
par Virginie ELIAS
Conservatoire des arts et métiers de Nantes - Pays de la Loire - Ingénieur CNAM en informatique 2009
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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).

précédent sommaire suivant