AXOPEN

Présentation de l’offre SOA Progress

L’offre logicielle SOA Progress propose une couverture complète des fonctions d’un ESB à travers les produits Sonic ESB et DXSI.

Sonic ESB est la plate forme d’exécution des flux de médiation. Les flux de médiation déployés sur l’ESB sont modélisés grâce à l’environnement de développement Sonic workbench basé sur Eclipse.

DXSI est un outil puissant de gestion des formats de données de l’entreprise. DXSI permet de modéliser les objets pivots et les formats spécifiques afin de construire toutes les transformations. La construction des règles de transformation est graphique et l’outil génère du code à la volée (java) qui est ensuite exécuté dans le flux de médiation comme n’importe quelle étape de transformation. Les librairies de transformation DXSI sont automatiquement importées dans l’ESB.

L’environnement de modélisation des formats pivots et des transformations nommé Designer DXSI est lui aussi basé sur Eclipse.

1   L’architecture de Sonic ESB

1.1     Infrastructure de communication

Sonic ESB repose sur le moteur JMS Sonic MQ qui a fait la réputation de la société Progress dans le mode des TELCO. Un bus JMS permet de publier des messages asynchrones entre applications ou composants. Le bus Sonic MQ est très largement répandu dans le monde des télécoms et le secteur financier grâce à sa tenue en charge et sa fiabilité.

Sonic ESB expose des services web sur les couches de transport http et jms. L’éditeur s’est engagé sur le support de l’ensemble de normes regroupées dans le Basic Profile 1.1 et promulguées par le WS-I.

Rest est un style d’architecture (Representational State Transfer) utilisé pour déployer construire des services SUR le web (à ne pas confondre donc avec les services web). Les principes de REST sont très simples et s’appuient essentiellement sur la couche de transport http et les documents XML. Il  n’existe pas aujourd’hui de standardisation ni de normes associées à ce style d’architecture. L’exécution de services REST dans Sonic ESB nécessite une part importante de développement spécifique (Article Progress).

1.2     Connecteurs

Afin de ne pas laisser les applications propriétaires isolées, Sonic ESB embarque aussi des connecteurs logiciels permettant de communiquer en utilisant d’autres protocoles de communication. Ces connecteurs traitent les fichiers, les bases de données, les serveurs FTP mais aussi une connectique plus progicielles avec des connecteurs dédiés à des progiciels spécifiques comme SAP ou Oracle Application.

NB : Les connecteurs progiciels font souvent l’objet d’une facturation à part.

Les connecteurs fichiers sont les plus largement utilisés. Le connecteur Sonic Adapter for flat file supporte les formats XML, à délimiteurs et les fichiers à taille fixe. Il est à même d’accéder aux fichiers locaux, mais aussi à des fichiers distants par l’utilisation du FTP.

Les connecteurs JDBC sont utilisés pour accéder aux données persistantes. La norme JDBC permet d’assurer un mécanisme transactionnel avec le support de transaction XA.

1.3     Transformations

Les composants de transformation sont utilisés pour assurer l’adaptation du format des messages échangés sur le bus. En fonction de la complexité ou de la nature de la transformation, Sonic ESB  offre des outils différents comme DXSI ou les transformations  XSL.

1.3.1       DXSI

DataXtend SI est un atelier de conception permettant de modéliser et transformer les formats de données de l’entreprise. DXSI génère à l’exécution tout le code d’implémentation correspondant au besoin modélisé par le concepteur. Cet outil assure à la fois une bonne productivité avec un environnement graphique et de bonnes performances grâce à la génération de code java à la volée.

1.3.1.2    Format Pivot

Un des très gros points forts de DXSI est qu’il oblige le concepteur à travailler ses transformations à partir d’un modèle pivot (ou canonique). Il doit concevoir un format de données génériques pour chacun des objets métiers de l’entreprise (une commande, un client, une facture etc). Toutes les transformations s’appuient ensuite sur ce format afin de passer d’un format spécifique à une application vers le format pivot (ou parle alors de demi flux entrant), ou bien du format pivot vers un format spécifique (demi flux sortant). Cette utilisation de format pivot facilite la réutilisation de demi-flux applicatifs existants  et limite la création d’interfaces point à point. L’utilisation du format pivot simplifie et rationalise les échanges de données au prix d’un effort raisonnable de conception. Dans le cas d’une architecture de services, DXSI permet d’exposer sur le bus des services génériques (données pivot, granularité correcte) qui s’appuient sur des services techniques (basse granularité, format de donnée propriétaire) localisés sur les applications.

1.3.1.3    Exposition de services

Une transformation DXSI est vue comme un service à l’intérieur d’un flux de médiation.  Il suffit de glisser/déposer la transformation dans le flux de médiation pour qu’à l’exécution la transformation soit appelée.

1.3.1.4    Capacité de transformation

Le designer DXSI génère du code java qui implémente les transformations modélisées dans l’environnement de développement. Ce code java est ensuite déployé sur les serveurs Sonic ESB. Il n’existe donc pas à proprement parler de conteneur DXSI. Au runtime, les transformations DXSI sont exécutées par le conteneur ESB.

1.3.2       XSL

Sonic ESB propose aussi un outil de transformation XSL (transformation XML vers XML). Bien que beaucoup moins puissante que DXSI, cette solution ne doit pas être négligée et correspondant à un certain nombre de cas d’utilisation. Les règles d’utilisation de DXSI et du XSL sont détaillées dans le guide de développement.

2   Architecture logique Sonic ESB

2.1     Vue d’ensemble

Figure : Architecture logique Sonic ESB

2.2     Services DXSI

Les services DXSI sont embarqués dans le conteneur ESB et sont exécutés par des librairies JAVA.

2.3     Gestion des références croisées

Les références croisées assurent le passage de données sémantiquement équivalentes mais syntaxiquement différentes. Ainsi, un code pays est souvent identifié par les trois lettres FRA mais peut ainsi s’écrire avec le code FR. Pour passer de l’un à l’autre, les références croisées utilisent des tables de référence qui enregistrent ces valeurs. Les références croisées sont utilisées dans DXSI et doivent être stockées dans un tiers de persistance comme une base de données.