Architecture soa (architecture orientée services)

3.4.2.2 Polling Fichier et Transformation

.../...

<service-assembly>

<identification>

<name>Polling_transformation</name>

<description>Represents the Service Assembly of Polling_transformation</description>

</identification>

<service-unit>

<identification>

<name>Polling_transformation-VQTIERS</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>VQTIERS.jar</artifacts-zip>

<component-name>sun-xslt-engine</component-name>

</target>

</service-unit>

<service-unit>

<identification>

<name>Polling_transformation-sun-file-binding</name>

<description>Represents this Service Unit</description>

</identification>

<target>

<artifacts-zip>sun-file-binding.jar</artifacts-zip>

<component-name>sun-file-binding</component-name>

</target>

</service-unit>

<connections>

<connection>

<consumer endpoint-name="to_grcPort" service-name="ns1:to_grcService"/>

<provider endpoint-name="to_grcPortTypeRole" service-name="ns1:to_grc"/>

</connection>

</connections>

.../...

La seconde activité du processus étudié est double, dans le sens où il s'agit d'un assemblage de services unitaires. Plus précisément, à cette étape, il va falloir solliciter un composant interne à l'ESB, chargé de scruter un répertoire spécifique (d'où le terme de polling), afin de déclencher un second service à bon escient, c'est-à-dire lorsqu'un certain type de fichier se présentera. Ce second service est dédié à la transformation d'un document XML dans un format cible spécifique (ici : le format des Tiers pour la GRC).

Illustration 132 : Assemblage de la transformation pour la JBI (Jbi.xml)

On retrouve dans ce fichier d'assemblage le nom de deux fichiers d'exécution (.jar). Le premier, VQTIERS.jar, est un programme Java obtenu suite à la construction du projet construit graphiquement (le terme de « build » est souvent utilisé). Il s'appuie sur un composant interne à l'ESB « sun-xslt-engine », chargé de transformer un document XML. Le second, sun-file-binding.jar, est un programme java construit de façon à déclencher le précédent composant. En effet, une transformation XSLT s'appuie sur une technologie de communication : message SOAP, File, FTP etc ... A chaque technologie de communication correspond un composant interne spécifique. La richesse d'un ESB, en termes de composants internes, est fonctionnellement importante, car elle constitue les limites de ce qui sera possible ou non d'implémenter. A titre d'exemple, l'ESB de SUN propose les composants suivants :

q File (utilisé dans la première réalisation),

q FTP (utilisé dans la première réalisation),

q HTTP Soap,

q JMS,

q Bpel (utilisé dans la première réalisation),

q Java EE,

q SQL,

q XSLT (utilisé dans la première réalisation).

La connexion entre ces deux services (EndPoint) est également précisée dans le JBI.xml. Elle peut également être concrètement visualisée via le framework.

Illustration 133 : Représentation graphique de la connexion des deux services unitaires, réalisé sous Netbeans

Le contrat de service entre le fournisseur et le consommateur se positionne sur une échelle à quatre niveaux^155(*). Le premier niveau concerne la vérification de la définition des types d'opérations et des paramètres. Le second niveau contrôle le comportement des opérations. Le troisième niveau s'intéresse aux contraintes de synchronisation des opérations. Et enfin le quatrième niveau, appelé Quality of Service « Qos », s'attache à définir le cadre de disponibilité, de sécurité et de performance du service. Le Qos est extérieur au service unitaire alors que les trois autres niveaux sont internes à l'interface. Ce volet fera l'objet d'un approfondissement dans le cadre de la seconde réalisation. Comme le montre la représentation graphique précédente, un WSDL indique la manière de communiquer pour utiliser le service « to_grcService ». Le WSDL se matérialise en un fichier XML, qu'il est possible d'afficher de façon graphique grâce à certains outils comme XmpSpy de l'éditeur ALTOVA).

Illustration 134 : Représentation graphique du WSDL, réalisé sous XmlSpy

Les paramètres du Port d'écoute sont également précisés dans le WSDL :

<service name="to_grcService">

<port name="to_grcPort" binding="tns:to_grcBinding">

<file:address fileDirectory="D:\Fichiers\out" lockName="filebc1.lck" workArea="filebc1_tmp" seqName="filebc1.seq"/>

</port>

</service>

Illustration 135 : Paramètre du service

Le message « input » respecte la structure du XML schéma VQTIERS et le message « output », après transformation, est structuré à partir du XML schéma Cpy, propre à la GRC de l'éditeur Selligent. Ces deux schémas sont associés au namespace « http://xml.netbeans.org/schema ». Les schémas ont été définis à partir de MagicDraw et ont été intégrés à la plate-forme Netbeans au moment de la définition des XML schéma. Quelques retouches ont été opérées après coup, directement dans Netbeans.

Le service de transformation « To_grc » est matérialisé lui aussi par un fichier de type XML : « to_grc.xsl ». Là aussi, existent des solutions pour représenter graphiquement le mapping entre le message input (source) et le message output (cible). La réalisation de cette transformation a également été prise en charge par Netbeans. Les règles de transformation peuvent y être intégrées de façon lisible. Par exemple, une balise CpyBlackList doit porter la valeur `1' lorsque la situation du partenaire est inactive (valeur = `X') ou lorsque le compte est fermé (valeur = `X').

Illustration 136 : Mapping de transformation XSLT entre le message Input et Output, réalisé sous Netbeans

La traduction XML de ce mapping est la suivante :

Illustration 137 : Traduction XML dans le fichier to_grc.xsl

* ¹⁵⁵ Cf. Source: « Making Components Contract Aware » [BEU-MCC].