Memoire Online - SOA : Définition, Utilisation dans le monde de la banque et méthodologie de test

L'architecture SOA est de plus en plus utilisée dans les entreprises. Cette Architecture Orientée Service apporte beaucoup de nouveautés au monde des systèmes d'information et à l'informatique en général. D'ici fin 2008, 60 % des entreprises opéreront leurs applications métiers par le biais d'une architecture SOA et le marché mondial des Web Services (une implémentation de SOA) est passé de 950 millions de dollars en 2004 à 6,2 milliards en 2008.

J'ai d'ailleurs réalisé mon stage de quatrième année à Thales sur un sujet impliquant les SOA : il s'agissait d'une étude sur les SOA et ainsi voir comment les utiliser dans le contexte de Thales. Depuis des années, de multiples études de ce type ont été menées dans toutes les entreprises. En effet, cette architecture permet une refonte complète tout en gardant des briques existantes mais peut très bien être instaurée de manière incrémentale. Les entreprises, dont les banques, qui n'ont, bien sûr, pas envie de repartir de zéro avec leur systèmes d'information, peuvent ainsi progressivement utiliser une architecture SOA de plus en plus complète.

Effectuant mon stage cette année dans une banque, je me suis intéressé au monde SOA dans la banque où la notion de qualité de service est très importante. Les banques s'y intéressent particulièrement : comment vont-elles passer d'infrastructures créées il y a des dizaines d'années à une architecture SOA ? Ce qui va surtout m'intéresser dans ce document concerne la qualité SOA et la méthodologie pour tester une architecture SOA. Pendant l'adoption incrémentale, il va falloir utiliser une stratégie particulière qui diffère des phases de tests habituelles. Nous verrons pourquoi c'est si important et comment il est possible de réaliser cette tâche, en général, et plus particulièrement dans le monde de la banque.

En concevant une architecture SOA, l'année dernière, il n'a jamais été question de qualité SOA ou de méthodologie de test et c'est ce qui manque à mon expérience sur ces architectures.

Je vais ainsi présenter SOA avec mes acquis du stage de quatrième année puis voir les systèmes d'information existants dans le monde de la banque et comment planifier ces tests dans une architecture SOA.

QU'EST-CE QUE SOA ?

LA THEORIE SOA

Depuis le début, le terme SOA est évoqué mais la traduction de cet acronyme « Service-Oriented Architecture » par Architecture Orientée Service ne permet pas de comprendre exactement ce qu'il signifie. Une définition simple pourrait être la notion d'intégrer et de manipuler les différents composants d'un système informatique en tant qu'ensembles fonctionnels appelés services.

Cette architecture à la mode répond aux problèmes de réutilisation d'outils (ou produits) des entreprises. Pour mieux comprendre sa définition, il faut voir cette architecture comme une philosophie. C'est une approche permettant de réutiliser et d'organiser des ressources existantes, dans une solution autorisant une interopérabilité entre plateformes et environnements, une évolutivité des modules applicatifs et une flexibilité autorisant l'utilisation dynamique d'applications. Cette solution permet donc d'intégrer divers systèmes : chaque ressource peut être accessible en tant que service possédant une interface. L'implémentation du fournisseur de service est donc libre de changer sans qu'il y ait un impact sur son utilisation. On peut voir ce service comme une boîte noire : on sait qu'elle va rendre le service voulu sans savoir comment est faite la boite noire. On peut choisir de la remplacer par un autre service implémenté différemment mais répondant aussi à la même fonctionnalité.

Un exemple concret est le service qui a été créé par la SNCF : réserver une place de train. Une architecture SOA a été implémentée et l'un des services offre la possibilité de réserver une place de train : que l'on y accède de leur site internet ou d'un guichet, le service est le même. La personne qui fait la réservation utilise un client pour se connecter : un consommateur de service.

Cependant, l'interaction entre consommateur et fournisseur n'est pas directe mais faite par le biais d'un médiateur responsable de la mise en relation des composants.

Un consommateur de Service X (resp. Y) passe par un médiateur pour accéder au bon fournisseur de Service X (resp. Y).

Pour mieux voir comment fonctionne une architecture SOA, il est important de savoir ce qu'est un service. Il assure une fonction bien définie et est autonome, ne dépendant d'aucun contexte ou service externe. On retrouve dans un service les caractéristiques suivantes :

· Couplage faible : les services sont exposés via des standards qui assurent la réduction des dépendances. Le terme « loosely-coupled » est souvent utilisé.

· Grande Maille : les opérations proposées par un service encapsulent plusieurs fonctions et opèrent sur un périmètre de données large. Un service contient des objets, des composants qu'il utilise pour répondre à sa fonction. Le terme récurrent est « coarse-grained ».

· Synchrone ou asynchrone : attente de réponse après l'utilisation d'un service ou non.

Une architecture orientée service consiste donc en une collection de services, indépendants les uns des autres, qui interagissent et communiquent entre eux.

Il est intéressant de comparer l'architecture SOA à une autre architecture qui met en avant des différences importantes. Cette architecture est l'architecture orientée objet. Dans cette architecture, les données manipulées sont directement associées au mode de traitement qui leur est appliqué. La programmation orientée objet (POO) implique deux choses : liaison forte à un modèle spécifique et un nombre d'appels important entre les deux couches de présentation et métier (contenant les objets métiers).

Au contraire, l'architecture SOA permet à la couche de présentation de passer par des services pour manipuler les objets métier sans avoir besoin de les connaître explicitement. Les services agissent ainsi en tant que boites noires faisant abstraction de la complexité du modèle objet.

Pour mettre en pratique cette théorie, une implémentation s'est vite imposée : les Web Services. Même si ce n'est pas l'unique choix d'implémentation, elle est souvent associée à SOA.

LES WEB SERVICES

Les Web Services représentent l'implémentation la plus utilisée pour appliquer l'architecture SOA. Le concept de Web Service regroupe un ensemble de technologies basées sur XML, permettant de créer des composants logiciels distribués, de décrire leurs interfaces et de les utiliser en mettant en oeuvre des standards tels que SOAP, XSD, WSDL et UDDI. Les Web Services respectent donc des protocoles et des normes informatiques utilisés pour échanger des données entre les applications : ils ont été définis, pour la plus grande part, par le W3C (World Wide Web Consortium), qui a été fondé pour promouvoir la compatibilité des technologies du Web et émet des recommandations à valeur de standards industriels.

Un Web Service peut, dans un exemple simple, laisser un client communiquer avec lui en utilisant des messages XML qui répondent au standard SOAP (Simple Object ou Service Oriented Architecture Protocol). Il représente donc le format d'échange de données dont les protocoles primaires sont HTTP et HTTPS. On y trouve un en-tête et un corps. Dans l'en-tête, on peut faire référence à un fichier XSD (XML Schema Definition), permettant de définir les types des différentes données échangées. Dans le corps, les données indiquant la méthode utilisée et les bons paramètres sont présents. Prenons un Web service donnant, pour un identifiant client particulier et un identifiant produit, le prix du produit désiré. Un message SOAP contenant les bonnes informations et un champ prix vide pourra être envoyé au service. En retour, sera renvoyé le message avec le prix du produit renseigné.

Un fichier WSDL (Web Services Description Language) décrit un web service : c'est la fameuse interface évoquée précédemment dans la description d'un service. Pour faire un rapprochement, on peut voir ce fichier comme une interface en langage JAVA : on connaît les méthodes mais par leur implémentation. Elle contient aussi d'autres informations comme le fichier XSD (si jamais il y a des types complexes) mais surtout les informations permettant d'accéder au service (protocole, port et "EndPoint" - l'endroit où se trouve le service).

Un registre UDDI Universal Decription Discovery and Integration) est un annuaire basé sur XML qui permet de publier des services et facilite leur découverte par d'autres services en définissant comment ils interagissent. Un scénario d'utilisation possible est donc la publication d'un fournisseur de service (donc de son WSDL) auprès d'un registre en créant tout d'abord une entreprise et une catégorie de service. Un client demande ensuite à un registre UDDI la localisation d'un service qui correspond au service venant d'être ajouté à l'annuaire. Le WSDL du service demandé est alors reçu par le client qui peut communiquer avec le fournisseur de services en SOAP.

Schéma volontairement simplifié au niveau du middleware qui, ici, offre la possibilité d'accéder à un registre UDDI..

Derrière l'acronyme BPEL (Business Process Execution Language), se cache la notion d'orchestration qui est de plus en plus utilisée et qui, comme son nom l'indique, fait jouer les web services comme un chef d'orchestre. Cette couche, permettant de gérer le lien entre plusieurs services, pourrait offrir, par exemple, de mélanger un service d'envoi de SMS, un service donnant la température et un service donnant des conseils pour s'habiller selon la température. BPEL appelle un premier service pour connaître la température cet après-midi, utilise ce résultat pour interroger le service indiquant comment s'habiller et envoie la réponse avec le service envoyant des SMS. Un client, faisant appel à un BPEL, pourrait savoir qu'il doit emporter un pull car il va faire froid en fin de journée.

Derrière cet exemple très simple, on comprend que BPEL est lui-même un web service : il possède son propre WSDL. Mais son WSDL est particulier car il contient des informations supplémentaires : entre autres, les WSDL des services qu'il va invoquer pendant son exécution.

SOA est une théorie et on ne doit pas oublier que l'on peut faire une architecture SOA sans Web Services et inversement car, réaliser des web services, ne veut pas dire mettre en place une architecture SOA. « Une façon de concevoir et d'implémenter les applications de l'entreprise qui possèdent un couplage faible, sont à grandes mailles et sont des services réutilisables, accessibles par des interfaces bien définies et indépendantes de toute plateforme. »

Cette définition n'inclut donc pas de protocole de communication obligatoire et il n'y a aucune restriction évoquée : pas d'obligation d'envoyer des messages SOAP en HTTP. SOA est beaucoup plus que seulement des Web Services et sa vraie force intervient réellement quand il n'y a plus ces restrictions et autorise les services à être invoqués par une multitude de protocoles. L'ESB permet justement de mettre en oeuvre un environnement ne se limitant pas aux limites évoquées.

LES ESB (ENTERPRISE SERVICE BUS)

La définition de l'ESB permet de se rendre compte que c'est l'environnement parfait pour appliquer SOA. L'ESB est le médiateur : c'est une technologie informatique intergicielle permettant à des applications hétérogènes d'interagir au travers de services standards qu'elles mettent à disposition. Les principes sont la découverte dynamique (notre annuaire de services), la chorégraphie et l'orchestration de services (pas de coordinateur central dans la chorégraphie, chaque service connaît les services qu'il doit appeler) et la communication par messages. Les standards sont ceux des services web (SOAP, WSDL, ...) mais aussi la norme JBI (ESB est une implémentation de cette norme qui permet à des composants de communiquer via des messages), les messages JMS (Java Message Services) que je vais décrire plus tard, ... L'ESB permet de surveiller le trafic (« monitoring », console d'administration, fichiers de log, ...), d'imposer une qualité de service (gestion des transactions, assure la réception, permet de mettre en place des sécurités).

L'ESB se place en médiateur entre les fournisseurs et les consommateurs de service.

Il existe beaucoup de patterns d'intégration - le terme français patron est peu utilisé - pour un ESB, qui modifient un peu le schéma ci-dessus et le complètent. J'ai détaillé ces patterns en annexe. Ils m'ont alors permis d'identifier, pour chaque projet dont on m'a donné la documentation, le pattern utilisé. J'ai d'ailleurs pu me rendre compte qu'un des projets ne faisait pas non plus vraiment du SOA mais plutôt des Web Services sans respecter l'architecture. Chaque pattern s'applique dans des conditions particulières et tout est possible si l'architecture SOA est respectée. Il est même possible, même si ce n'est pas recommandé, d'avoir plusieurs ESBs sous certaines conditions.

Les ESBs sont devenus très importants dans l'architecture SOA, ils offrent des possibilités qui deviennent indispensables à toute architecture. Parmi ces possibilités, il est possible de compléter SOA avec EDA (Event-Driven Architecture) qui est l'architecture dirigée par les évènements.

EDA (EVENT-DRIVEN ARCHITECTURE)

Un ESB permet aussi de faire de l'EDA qui est parfois vu comme un mode d'implémentation asynchrone de SOA ou juste une extension permettant de compléter l'architecture. Le fonctionnement est ici un peu différent : nous avons été habitués au « Request and Reply » (envoi d'une requête et réception de la réponse) alors qu'ici le principe est « Publish and Subscribe » (les informations sont publiées et si on veut les recevoir, on s'y abonne).

Une application publie des évènements dans un topic. Toutes les applications peuvent s'abonner à ce topic pour recevoir les évènements quand ils sont publiés.

La publication est dynamique : si jamais il y a de l'information à transmettre, elle est publiée et tout le monde peut souscrire à ce service à n'importe quel moment.

Les messages sont envoyés par une application dans une queue. Une autre application peut lire un message dans cette queue : elle le consomme. (Point à Point)

Le format des messages échangés pour utiliser cette fonctionnalité est, par exemple, JMS (Java Message Services). JMS permet deux modes de fonctionnement : le « Publish and Subscribe » - cela s'appelle un Topic -, et le « Send and Receive » - la Queue, envoi et récupération de messages -.

Les queues et les topics sont hébergés sur l'ESB. Un message JMS peut contenir un objet java ou du texte (donc du XML ou même des messages SOAP). Ce même message contient un en-tête permettant d'ajouter des informations (durée de vie, queue ou topic de retour de réponse, ...)

Pour comparer avec les Web Services appelés avec des messages SOAP sur HTTP, on a, d'un côté les Web Services avec des fichiers générés des 2 côtés pour faire le lien entre les messages échangés, et de l'autre une queue ou un topic faisant le lien :

En expliquant cette possibilité, on comprend que ce qui est important est la conception du service. L'idéal serait de proposer plusieurs moyens pour accéder au service selon la situation. On peut imaginer un objet natif qui gère les achats et utilise des applications de l'entreprise pour propager l'information. Cet objet peut avoir des méthodes pour acheter, ajouter des produits au panier, donner les informations de l'acheteur, etc. Appeler ces méthodes à un niveau local ne pose pas de problème mais, comme évoqué dans la définition des services, ce n'est pas une solution.

La solution est de fournir une méthode unique pour ajouter un ordre d'achat contenant toutes les données nécessaires. Cette méthode peut être décrite par le biais d'une interface et accessible par diverses technologies. Le service ne change pas, seulement le protocole de communication et le format des données échangées. Au consommateur du service de choisir le meilleur moyen d'accéder au service.

SOA DANS LE MONDE DE LA BANQUE

LA BANQUE

De nos jours, plus de 90 % des transactions du secteur financier se basent sur des systèmes statiques constitués d'infrastructures informatiques développées il y a de nombreuses années. Les institutions bancaires vont devoir adapter et repenser sans cesse leurs stratégies et leurs objectifs pour effectuer les meilleurs choix. Les architectures SOA sont une des clés pour répondre à ces besoins à condition de bien comprendre les projets et les objectifs de l'entreprise. Ainsi, de nombreux établissements exploitent des systèmes technologiques qui ne leur permettent pas de répondre de manière efficace aux changements de stratégies imposés par de nouvelles orientations. Ces infrastructures sont performantes mais elles doivent évoluer avec l'entreprise pour répondre aux besoins existants et aux développements futurs. Les architectures orientées services proposent une alternative efficace à ces exigences fortes. De nombreuses situations vont nécessiter cette évolution de l'infrastructure informatique avec les changements réglementaires imposés aux banques. Les banques doivent faire face à de nouvelles normes réglementaires comme le projet d'espace unique de paiement en euros (SEPA) ou les accords BALE II, qui constituent un dispositif prudentiel destiné à mieux appréhender les risques bancaires et principalement le risque de crédit ou de contrepartie et les exigences en fonds propres, ou encore à des projets de rapprochement entre deux institutions bancaires.

Microsoft, SAP et 15 autres sociétés acteurs du monde bancaire ont créé en 2008 l'association BIAN (Banking Industry Architecture Network) pour partager leurs expertises techniques et méthodologies pour faciliter l'évolution des systèmes informatiques des banques vers ces architectures SOA. Les architectures SOA permettent d'éviter de repartir de zéro et, au contraire, elles sont assez souples pour reconstruire un nouveau système informatique sur l'existant et les faire évoluer à la demande du service informatique. Mais, il y a aussi de nombreux projets qui ont été des échecs car les processus de l'informatique d'une banque sont étroitement liés aux processus de l'entreprise. Un projet SOA ne peut être réussi que si le projet est modélisé à partir des besoins de l'entreprise. Comme les banques comportent une grande part de développements spécifiques et que ces derniers constituent une entrave gênante avec la globalisation des marchés financiers, BIAN encourage le développement de services standardisés, vers lesquels les banques pourraient évoluer par étape.

IBM, COBOL, CICS

Le monde informatique bancaire a toujours été un très grand utilisateur de tous les systèmes IBM. Ces systèmes hôtes représentent un grand investissement qui est intégré au niveau des processus et des sources de données. Le challenge des projets SOA est donc aussi d'intégrer l'ensemble des applications développées sur les systèmes IBM, qui sont appelés application Mainframes ou System i. Les Web Services vont permettre de publier les processus métiers bancaires offerts par le système informatique existant et de les mettre à disposition de façon standard, peu importe le langage de développement utilisé.

L'histoire du Mainframe dans les banques est vieille de 50 ans et est liée au Cobol. C'est un langage de programmation de troisième génération créé en 1959 et est l'acronyme de Common Business Oriented Language dont le but est d'être un langage commun pour la programmation d'applications de gestion. Ce langage était le plus employé des années 1960 à 1980 et reste donc très utilisé dans les institutions financières. En effet, l'immense majorité des plus grandes entreprises du secteur financier ont encore des Mainframe et leur confient leurs applications et leurs données les plus critiques. Les révolutions architecturales ont entre temps eu lieu mais n'ont pas remplacé les Mainframe : elles se sont superposées à l'existant, les complexifiant et nuisant à toute évolutivité.

C'est cette situation figée que les entreprises veulent faire évoluer en s'affranchissant de la dépendance aux développeurs Cobol et de la complexité à appréhender le patrimoine applicatif. Le but de l'utilisation de SOA est donc de rénover les pratiques du développement sur Mainframe. La solution logicielle que préféreront les banques est la solution IBM Rational Software du fait de ce lien particulier avec IBM. La modernisation des architectures est un point essentiel car il y a un trop fort couplage entre les composants, empêchant la flexibilité des solutions et la réutilisation du code. Les solutions comme Rational (d'autres existent sur le marché) vont permettre de transformer les applications « green screen » (un écran vert servant de client) en interfaces ou en Web Services, de pouvoir développer des Web Services à partir de langages comme Cobol ou Java ou à partir d'application CICS avec le Service Flow Modeler. Le système CICS (Customer Information Control System) est un système qui permet d'effectuer des opérations transactionnelles, comme la consultation ou la mise à jour de bases de données ou de fichiers, avec une très grande économie de moyens. Service Flow Modeler est l'outil permettant de construire un flow de services en se basant sur des Commarea (fichiers Cobol de définition de données) et applications Terminal CICS (voir annexes).

On peut ainsi exposer des flows de données en tant que service avec des logiciels rendant possible l'utilisation des technologies CICS dans une architecture SOA.

On expose ainsi le service CICS par le biais d'une interface WSDL générée. En détail, on obtient le schéma suivant où un service consommateur (requester) envoie une requête au service fournisseur (provider).

Toute une gamme de logiciels existe pour accompagner la vie d'un projet SOA et IBM fonctionne beaucoup avec ces entreprises travaillant dans le monde bancaire. Des logiciels existent et suivent une méthodologie particulière pour surveiller la qualité et les tests : cette méthodologie sera évoquée dans la deuxième partie de ce document. Cet aspect est important car les tests fonctionnels non intégrés et les tests de performances différents entre îlots et des processus de fabrication inconsistants contribuent à fragiliser le processus de développement et en augmenter les coûts.

Les possibilités de modernisation des Systèmes d'Information traditionnels sont :

- L'analyse du patrimoine : détection de l'ensemble des interactions d'une application Cobol/CICS avec le reste du parc applicatif

- La transformation de ce module de traitement écrit en cobol, en web service invocable au sein d'une architecture SOA, sans impact sur le fonctionnement du système d'information.

C'est bien sûr compliqué de réorganiser les composants applicatifs, de les récrire, ou de les mutualiser dans des architectures SOA. Des outils permettent de détecter des interdépendances applicatives pour pouvoir mettre en évidence la structure complète du programme : quelles sont les transactions CICS, quels sont les programmes COBOL, ... Cette étape est importante dans l'optique d'un passage à SOA pour repérer les programmes les plus utilisés et ainsi récolter des informations stockées dans un référentiel utilisé par les outils de cartographie et d'analyse d'impact. Un des objectifs est donc, bien entendu, d'améliorer les taux de réutilisation des composants. en se servant des analyses précédemment effectuées. Les outils existants (comme Rational Developer for System Z d'IBM) permettent ensuite la suppression de la partie cobol de l'application et la création d'un service web utilisant la partie métier écrite en Cobol/CICS. Les possibilités sont énormes et permettent la visualisation transparente des programmes quelque soit leur origine et leur structure dans une présentation type station de travail, avec une unité de navigation et d'outils d'analyse et de débogage pour toutes les sources. Toutes les combinaisons sont possibles : création depuis le début d'un service, transformation d'un module métier en cobol en nouveau service, ...

STRATÉGIE DE L'ENTREPRISE

Les processus initiaux pour la mise en place d'un projet d'architecture SOA sont l'identification d'une activité, la segmentation des processus métiers liés à cette activité, puis les regrouper au sein de services web. Ce sont des processus compliqués et la difficulté principale dans le cadre des projets SOA reste la définition sémantique des services. C'est justement ce sujet qui intéressait l'entreprise SAP pour le secteur bancaire lorsqu'elle a créé en 2005 le regroupement IVN (Industry Value Network) for Banks qui rassemble 37 éditeurs et institutions financières.

Les architectures SOA possèdent une grande richesse qu'il faut maîtriser en ne tombant pas non plus dans la multiplication des services à outrance : le projet peut être un échec avec une architecture manquant de toute cohérence fonctionnelle. La modification d'un processus métier a une incidence sur l'ensemble des processus de l'entreprise dessinant un lien essentiel entre la direction de l'entreprise et l'entité informatique. Une stratégie doit être mise en place pour la réussite d'un projet SOA : partir de la mission de l'entreprise et collaborer entre la direction et l'entité informatique est primordial. La direction stratégique de n'importe quelle entreprise est amenée à évoluer et à faire naître de nouvelles stratégies de gestion.

Une gouvernance SOA efficace apporte toutes les réponses aux questions métier fondamentales concernant :

- Le droit décisionnel : le modèle de service à utiliser pour un nouveau processus, les responsables du financement et des mises à niveau pour les services partagés, l'incitation à la réutilisation d'un service, les droits et fréquence d'utilisation d'un service.

- Les services métiers appropriés : les services métiers communs dont une banque a besoin, des applications potentielles qui vont réutiliser les services, des règles communes ou uniques, l'existence de services existant déjà et pouvant être réutilisés.

- Le cycle de vie des ressources de service : l'autorisation de modification d'un service utilisé par d'autres, les utilisateurs concernés par un service modifié, éviter la prolifération inutile de services

- La mesure de l'efficacité : la mesure de l'utilisation et des coûts du service, la mesure de l'avantage pour l'entreprise.

La nature de SOA se prête bien à une adoption incrémentale reposant sur la planification, l'élaboration, l'évolution et le dimensionnement des processus métiers. Chaque phase du processus est indépendante, ce qui permet aux institutions bancaires d'optimiser leurs déploiements de SOA en fonction des premiers besoins. Cette approche itérative et interactive oblige à avoir des phases de tests importantes que je vais décrire dans la suite de ce document.

COMMENT TESTER SOA ?

POURQUOI EST-CE SI PARTICULIER DE TESTER SOA ?

Tester l'intergiciel d'une entreprise (middleware - sert d'intermédiaire de communication entre plusieurs applications) qui utilise une architecture orientée services est compliqué. L'architecture SOA fait évoluer le système d'information où les applications étaient au centre vers un monde où ce sont les processus qui sont au centre. Comme évoqué précédemment, l'intégration des mécanismes de SOA permet une intégration avec un couplage faible et on peut ainsi changer les applications sans impacter les autres applications.

SOA, pouvant être implémenté de multiples façons, sera donc testé de façon particulière : il existe peu de méthodologies conçues spécifiquement pour les applications SOA et des nouvelles approches et méthodologies ont dû être créées pour vérifier et valider de telles applications. On peut se poser la question : Pourquoi est-ce si différent de tester SOA ? La réponse est complexe mais elle peut se résumer à « agilité » et « flexibilité ». Ce qui fait tout l'intérêt d'une architecture SOA est aussi ce qui demande une approche différente au niveau des tests. Il faut ainsi tester les interfaces et les services qui peuvent rapprocher différents systèmes et plateformes mais aussi s'intéresser aux dimensions de sécurité et de performance. Un autre point important de la méthodologie de test pour SOA est la disponibilité de l'environnement. Derrière cette notion, est présent l'essence même de SOA où interviennent les différents services ou applications dans l'environnement : la disponibilité de ces services internes autonomes, qui composent les Business Process (BPEL - Orchestration de Services), est très importante pendant les différentes phases de tests d'intégration. Il faut ainsi pouvoir tester ces processus d'orchestration comme un tout complet mais aussi tester chacune des parties qui le composent.

Les applications intergicielles basées sur SOA sont donc plus complexes que les applications que l'on rencontre habituellement qui sont liées à l'interface graphique (GUI). Ici, l'interface machine n'est pas intuitive pour une personne humaine qui voudrait interagir avec : les messages qui sont échangés, par exemple, sont conçus conformément aux données de l'entreprise mais ne sont pas forcément compréhensibles humainement. Il faut bien sûr des outils pour pouvoir déchiffrer des messages mais aussi des outils de génération de tests qui ne peuvent pas tous être écrits spécifiquement pour chaque cas, ...

De plus, en ajoutant plus de complexité pour atteindre un état flexible et réutilisable, l'architecture SOA devient d'autant plus stratégique pour l'entreprise. Le retour sur investissement d'une telle architecture peut être important si cette architecture est bien testée. Une architecture SOA non testée peut se transformer en échec et faire perdre de l'argent.

LES BASES DE LA MÉTHODOLOGIE DE TEST

On peut identifier certains points importants lorsque l'on teste un service d'une architecture SOA : la distribution, les données, le comportement, l'intégrité, la conception et le niveau de performance des services. Les services sont distribués au sein de l'entreprise dans des environnements hétérogènes et peuvent être découverts en cours d'exécution. Une architecture SOA n'est pas figée et la découverte dynamique de service implique une phase de tests couvrant cette possibilité. Le test des données est critique car il faut contrôler les données utilisées par le service et vérifier la cohérence entre les données entrantes et sortantes. Les messages qui circulent contiennent beaucoup de champs (les services sont appelés de façon indépendante et n'ont pas d'état prédéfini donc pas de contexte) et les possibilités de permutations des champs sont importantes. Le comportement d'un service est bien sûr ce qu'il y a de plus important : est-ce qu'il répond correctement à ce pour quoi il a été créé ? Et si le service a plusieurs fonctionnalités, il faut le surveiller pendant tous les traitements. L'intégrité permet de savoir jusqu'à quel point un service est capable de continuer à jouer son rôle pendant une longue période. Ces tests doivent bien sûr refléter des cas d'utilisations possibles en production. Tester la conception d'un service permet de savoir si pour un service particulier et sa fonctionnalité intrinsèque, le bon patron de conception (design pattern) est utilisé. Cette phase demande une attention particulière car elle demande une interaction entre les architectes, les designers et les développeurs. Enfin, le dernier point correspond au niveau de performance spécifique que peut fournir un service et mesurer ce niveau en condition réelle pour voir s'il respecte bien le niveau prévu. Un mauvais niveau de performance d'un service peut faire baisser la performance globale de l'architecture SOA : un processus d'orchestration qui utiliserait un service avec un faible niveau de performance aurait, lui, un mauvais niveau de performance, ...

De plus, les données échangées dans une requête et dans une réponse sont figées : les services sont accessibles par des interfaces connues (WSDL). Ceci implique donc une prédictibilité entre les services qui interagissent. Les données et les fonctionnalités évoluent constamment ce qui implique une évolution permanente de l'application et ces évolutions amènent donc de plus en plus d'interactions entre les différents systèmes. Aussi, les services sont souvent pensés synchrones mais il existe aussi des services qui fonctionnent de manière asynchrone et on peut donc voir des interfaces qui ne correspondent pas au traditionnel questions/réponses avec les standards SOAP des web services. Chaque protocole (qui utilise par exemple des queues de message Java Message Services) ajoute de la complexité aux tests. Il est impossible de réellement tester l'architecture SOA comme une boite noire classique (vérification que l'implémentation fournit bien le résultat attendu par la spécification sans savoir comment cela a été réalisé ; à différencier la boite blanche où on a accès à la structure du code et où on peut donc faire des tests au plus bas niveau possible). En effet, les données pouvant être modifiées dans différents systèmes, il est nécessaire de vérifier que les systèmes impactés ont bien pris en compte cette évolution au niveau données (il n'y a que très rarement des impacts sur la fonctionnalité du service).

Enfin, SOA étant une architecture, il est important de tester l'architecture de manière holistique : considérée comme un tout et non comme une composition d'éléments (services, processus, ...). On peut ainsi voir si l'architecture dans sa globalité réussit à atteindre les objectifs de réutilisation et flexibilité et étudier les composants principaux de l'architecture comme la persistance de l'information (qui correspond aux données qui sont sauvegardées une fois une opération terminée).

On peut donc voir différents problèmes outre ceux de l'application elle-même : l'environnement et les besoins logiciels que l'on va avoir. L'environnement est complexe car on peut intégrer différentes technologies et il faut pouvoir gérer ces technologies comme points d'intégration : plus les technologies sont différentes, plus la complexité des tests sera grande. Ce qui fait la force de SOA alourdit ainsi la complexité de la phase de tests. Les outils dont a besoin doivent répondre ainsi aux problèmes soulevés :

Problèmes	Besoins
L'application n'a pas d'interface graphique.	Les testeurs ont besoin d'une interface de test facile à utiliser et permettant de générer des requêtes à partir d'un fichier WSDL.
Messages contenant beaucoup de données.	Outil permettant l'automatisation de la permutation des données.
L'application a des interfaces précises (WSDL).	Outil permettant de vérifier que la réponse correspond au service.
L'application évolue rapidement et constamment.	Outil permettant de générer des types de tests modulaires et de les exécuter rapidement.
L'application peut supporter différents protocoles.	Outil gérant les divers protocoles existants (Ex : HTTP/HTTPS, MQ, JMS, ...)
Impossible de tester en tant que boîte noire classique.	Outil pour automatiser la validation des fichiers et des bases de données, et permettant d'automatiser des scénarios de tests qui soient paramétrables.
Les dépendances de l'environnement ne peuvent être contrôlées.	Outil pour gérer les données sur différents systèmes.
La maintenance des données est coûteuse.	Outil permettant de réutiliser les données sur les différents cas de test.

MÉTHODOLOGIE DE TEST

Pour créer un plan de test SOA, il est donc nécessaire de comprendre le fonctionnement de l'architecture à un méta-niveau puis de voir comment découper cette architecture en différents composants pouvant être testés individuellement. Ces parties doivent aussi pouvoir être testées en tant que composants liés entre eux. Enfin, l'architecture doit être testée de manière holistique. Il est donc nécessaire de créer des standards et des procédures qui permettent de tester jusqu'au niveau des projets.

SOA n'est qu'une théorie et il existe beaucoup d'implémentations différentes de cette théorie : les architectures ne sont pas toutes identiques et les solutions sont propres à chaque problème. En créant son propre plan de tests SOA, il faut comprendre cela car cela veut dire qu'il y aura des besoins spécifiques pour chaque architecture.

SOA assure une réduction des dépendances mais il existe une interdépendance entre les différents composants. On peut voir, dans le schéma suivant, comment ils sont reliés et nous allons comprendre comment ils fonctionnent indépendamment et collectivement.

On distingue ainsi plusieurs patrons de conceptions (design patterns) en fonction du type d'architecture. Les architectures de transactions sont celles où les services de transactions sont très utilisés : on peut prendre le cas des applications où il y a beaucoup de services de transactions en ligne et qui sont invoqués plus que les autres. Les architectures de données sont celles où les services les plus utilisés sont les services de données ou les services qui distribuent de l'information. Les architectures de processus sont celles où le coeur de l'architecture se trouve au niveau des processus : ce sont des architectures qui évoluent souvent et où les services principaux peuvent être changés facilement. Selon les besoins, on identifiera donc un certain type d'architecture et on testera différemment.

Pour pouvoir tester une architecture, on peut voir le problème de trois façons :

- « Bottom Up » (« de bas en haut ») : cette approche permet de tester l'architecture en commençant par les caractéristiques les plus simples puis de tester les plus sophistiquées. Si on regarde le schéma précédent, cela correspond à tester des données aux processus, puis la couche de données (services de données, abstraction de données), des couches de services de transaction vers les couches de processus et enfin les couches de contrôle et de gestion des évènements. Pour simplifier, cela revient à tester chaque composant en déplaçant des couches du bas vers les couches du haut.

- « Top Down » (« de haut en bas ») : cette approche inverse l'ordre des tests de l'approche « Bottom Up ». On teste chaque composant des couches les plus hautes vers les couches les plus basses.

- Système : l'approche Système permet de tester comme un tout. Ainsi, on regarde l'architecture comme une unité fonctionnelle en testant toutes les interfaces de toutes les couches en regardant ce qui rentre et ce qui sort en observant les différents comportements.

Ces trois approches sont distinctes et se complètent. Même si on peut n'utiliser qu'une des trois approches, les projets de tests SOA les plus réussis sont ceux qui utiliseront les trois approches. Le choix dépend bien sûr des besoins de l'architecture.

Pour créer un plan de tests, il ne faut pas oublier le domaine fonctionnel de l'architecture. Ainsi, il faut comprendre le domaine du problème avant de savoir comment le tester : au niveau sémantique, au niveau des services et au niveau des processus. L'approche va donc se décider au moment de la création de l'architecture.

Toutes les activités comme la conception, l'analyse, la planification et l'exécution doivent être testées tout au long de la vie du projet. Le fameux « modèle en V » est ainsi une bonne méthodologie qui permet de mettre en place une bonne discipline de tests durant toute la vie du projet. Le projet commence ainsi par une définition des besoins (« User Requirements ») puis les critères d'acceptation des tests (« Prepare User Acceptance Testing ») avant de commencer la phase de conception technique. De même, avant la phase suivante de design technique, le modèle en V demande de définir le niveau d'exigence technique et ainsi de suite. Ce modèle en V permet donc aux équipes projet de déterminer continuellement ce qu'il faut pour bien tester une application.

Ce modèle en V permet d'abord une approche « Top Down » en respectant la définition des exigences des processus, la conception technique fonctionnelle, ... Il encourage ensuite une approche « Bottom Up » en testant les fonctions à l'intérieur d'un service, puis les services eux-mêmes, les orchestrations de services et finalement le test du système complet. Le modèle en V incite donc à tester tout au long du développement de l'architecture. Nous reviendrons sur cette idée de tests continus, et non pas exclusivement à la fin du développement, par la suite.

Pour tester à un moment donné une application SOA, on distingue ainsi les catégories suivantes : test de gouvernance (Governance), test des données (Link Testing), test au niveau des composants du service (Component Testing), test des services (Service Testing), test d'intégration (Integration Testing), test au niveau des processus comme l'orchestration (Workflow Testing), test du système (System Testing) et test de sécurité (Security). On peut ainsi identifier à partir du schéma présenté précédemment, les couches impactées par ces catégories de test.

Le test de gouvernance. La gouvernance SOA correspond à l'assurance que les services existants (et les futurs services créés) soient conformes aux standards politiques et objectifs de l'entreprise. Elle permet par exemple de maintenir une qualité de service ou une flexibilité des processus car elle fournit une structure, un engagement et un support pour le développement, l'implémentation et la gestion de l'architecture SOA. Il s'agit donc ici de vérifier que les engagements soient respectés : la qualité de services en terme de performance ou transaction, les évènements qui doivent être notés et pendant combien de temps, ou les politiques sur l'infrastructure (droits d'accès, sauvegardes, plantages, ...). Ces tests interviennent à tout niveau.

Le test des données. Ces tests s'intéressent aux données liées aux services. Les données peuvent provenir des bases de données mais aussi de tous les systèmes utilisant des données. Il faut tester les données qui sont utilisées à l'intérieur des services : pas seulement la valeur de l'information mais son utilisation.

Le test au niveau des composants du service. Ces tests sont généralement exécutés par les développeurs pour vérifier le code compile, et que le fonctionnement de base des composants ainsi que les fonctions internes d'un service respectent les spécifications. Il est ainsi possible de tester ces petites parties de l'application en les isolant et voir si elles fonctionnent avant de les intégrer dans un ou plusieurs services.

Le test des services. Ce test est le plus important car beaucoup d'entreprises font, par exemple, des web services et il faut donc faire particulièrement attention aux tests unitaires. Ces tests doivent non seulement répondre aux engagements prévus pour le service mais aussi aux engagements des processus qui vont l'utiliser. Les services ne sont pas des applications ou des systèmes complets et ne doivent pas être traités de cette façon. Ils font partie de différentes applications et doivent être testés de façon indépendante : ils peuvent fonctionner seuls ou à l'intérieur d'un processus. La meilleure approche pour tester des services est de lister les cas d'utilisation pour chaque service. Toutes les configurations doivent être considérées : un service utilisé seul, un service qui est appelé par un autre qui est lui-même appelé par un autre service, ou des services appelés à distance par des systèmes non contrôlés. Les services doivent avoir un couplage cohérent avec leur utilisation pour maximiser les performances. Ainsi, un service avec un couplage trop faible va avoir tendance à baisser les performances car le nombre de communications va être trop important avec la multiplication de services.

Les tests d'intégration. Ces tests s'intéressent aux différentes interfaces des services et si elles respectent bien les spécifications. Tous les services livrés par une équipe de développement doivent bien correspondre à la définition des services en termes de standard, format et données. De plus, les tests se portent aussi sur les scénarios incluant les différentes couches de communication et les protocoles réseau. Les services externes à l'entreprise sont aussi testés. Les services doivent atteindre l'interopérabilité, qui permet à un système de travailler facilement avec d'autres, en respectant scrupuleusement les interfaces ou en utilisant des services capables de convertir les données d'une interface de service à la volée. Il faut donc avoir une interopérabilité au moment de la conception mais aussi en cours d'exécution pour pouvoir intégrer des éléments indépendamment des protocoles, du système d'exploitation ou langage de programmation. Le test de rétrocompatibilité permet aussi de savoir comment sont affectés les consommateurs d'un service dont on change l'interface. Si ces consommateurs sont affectés par ce changement, ce n'est pas rétrocompatible et il faudra donc mettre en place une stratégie, gérer l'impact de tels changements. Une interface de service évoluera forcément un jour et un tel changement doit être analysé.

Le test des processus. Ces tests permettent de s'assurer que les processus intégrant plusieurs services fonctionnent selon les spécifications. Cette phase de tests concerne donc la logique des processus, l'ordre d'utilisation des services, la gestion des erreurs et la réutilisation des processus. Les services sont orchestrés, assemblés pour former une solution cohérente et donc on peut ajouter, changer et enlever des services à volonté. Les processus peuvent évoluer rapidement et il faut donc vérifier que la conception permet ceci. Il y a beaucoup d'approches et de standards différents pour séquencer et manager des collections de services. Outre l'orchestration, on peut voir ainsi une chorégraphie de services (les services connaissent les autres services dont ils ont besoin contrairement à l'orchestration) ou encore les processus propriétaires : il faudra donc tester ces processus de manière adéquate.

Le test du système. Cette phase permet de vérifier que la solution technique de l'architecture SOA correspond bien aux engagements et satisfait les critères d'acceptation. Les tests ciblent les scénarios clés de la solution et interviennent après les tests précédents.

Le test de sécurité. Plus l'architecture SOA deviendra grande au sein de l'entreprise, plus ces tests seront importants. Il faut donc planifier dès la création de l'architecture et ne pas attendre la fin du développement de l'architecture. En effet, il faut se demander si les données qui parcourent ce réseau interne et externe sont protégées. Si jamais les tests de sécurité sont exécutés seulement à la fin, il y a un risque de trouver des problèmes de sécurité sévères mais, plus important, de voir que le système n'a pas eu une conception adéquate pour une architecture sécurisée.

Nous avons pu voir que tous ces tests ne doivent pas être effectués seulement à la fin du développement si l'on ne veut pas avoir de surprise concernant les performances ou la sécurité. Tester tôt dans la réalisation de l'architecture peut sembler compliqué mais c'est nécessaire si l'on veut éviter les échecs. Tester un service rapidement permet de se rendre compte de ses erreurs plus rapidement et donc de réagir plus vite et éviter une perte de temps et d'argent. Il faut donc tester dès le début et en continu. Un service qu'on ne pensait pas stratégique peut devenir important dans le futur. Et la qualité et les performances des services peuvent être altérées par les configurations de l'ESB, les règles de transformations ou la politique de sécurité. Tester en continu permet à l'architecture SOA de changer facilement - l'empêchant de devenir statique et rigide. Les bénéfices sont importants : on peut tester et valider quotidiennement tôt dans le cycle de développement quand c'est facile (et donc moins cher) de réparer les problèmes.

Une des conséquences de la correction d'un défaut est la possibilité d'introduire des nouvelles erreurs. En introduisant de nouveaux éléments, on ne peut être certains que tous les tests qui ont été passés correctement se passeront bien à nouveau. La stratégie de régression permet de ne tester à nouveau qu'une sélection de services tout en s'assurant qu'aucun autre service précédemment testé ne sera compromis par les changements effectués. Cette stratégie ne s'intéresse pas à tester la correction du défaut mais plutôt que le système et les services qui le composent n'aient pas été affectés. Ces tests ne peuvent rendus possibles que par l'utilisation d'outils automatisant la vérification des tests : nous allons voir les produits pouvant être utilisés.

Beaucoup d'entreprises adoptent l'approche de tests basée sur les risques : les cas et scripts de tests exécutés selon un ordre justifié par les implications financières des tests qui ne passeraient pas et sur la possibilité d'échec de ces tests.

L'analyse de tous ces tests nous permet de comprendre la complexité de l'architecture SOA. Cela se complique lorsque l'on multiplie les différentes technologies, applications protocoles, processus, les systèmes hétérogènes et distribués. On peut comprendre qu'il est difficile de trouver un outil miracle permettant de réaliser tous ces tests. Le but n'était pas ici de décrire toutes les solutions mais bien de définir une méthodologie de tests et de bonnes pratiques et amenant à une réflexion continue lorsque l'on développe une architecture SOA. On peut tout de même identifier plusieurs produits offrant une palette d'outils : les outils de la société Green Hat qui sont parmi les plus utilisés ou ceux de la société IBM (Rational), peut-être moins complets mais offrant plus de maintenance, ou encore les produits « Open Source » mais plus simplistes comme SOAP UI.

DANS LE MONDE DE LA BANQUE

Beaucoup d'institutions comme les institutions bancaires se tournent vers les architectures SOA. L'environnement que l'on teste est souvent hors de contrôle de l'entreprise de tests. L'environnement n'est habituellement pas dédié aux tests de l'application mais est souvent partagé par beaucoup d'applications. Les sous-systèmes qui contiennent les données dont les tests dépendent sont aussi hors de contrôle.

Dans les environnements bancaires, il est impossible d'arrêter les processus de sous-systèmes dépendants : par exemple, les comptes avec un solde de zéro vont être analysés et fermés chaque mois. Cette violation de données rend l'automatisation de tests difficile car il faut une grande compréhension des applications de la part des personnes de ces sous-systèmes dont l'application dépend. La configuration initiale des données dans ces sous-systèmes dépendants est difficile à mettre en place et il est ainsi nécessaire de payer un autre groupe pour configurer les données ou former des membres de l'entreprise sur chaque sous-système dépendant.

Comme nous l'avons vu, l'environnement est complexe dans les SOA et on retrouve cette complexité dans les banques. Les technologies peuvent aller des web services et autres applications intergicielles aux applications CICS. Les tests sont alors d'autant plus complexes mais le bénéfice est important. La vitesse de développement de nouveaux produits et services est accélérée et cela permet aux banques d'apporter des nouvelles offres plus rapidement sur le marché.

Les tests peuvent être mis en place par tous les standards offerts par l'architecture SOA (échange de données et interopérabilité) et ainsi réfléchir à une politique commune de tests multi environnements.

Les banques, qui avaient déjà utilisé l'architecture SOA sur des petits projets, vont pouvoir étendre leur expérience maintenant que la technologie qui accompagne la théorie est plus mature, qu'ont eu lieu les premiers retours d'expérience et que les offres de framework SOA (conception, réalisation et tests) sont plus complètes et faciles à mettre en oeuvre.

CONCLUSION

Ce document permet de comprendre les principes d'une architecture SOA et de mettre en évidence les points qui en font sa particularité : tous les avantages apportés par cette architecture en termes de souplesse et de facilité d'évolution complexifient la méthodologie de test. On comprend alors qu'on ne peut pas aborder les tests de la même manière qu'une application classique. Pour créer un plan de tests, il faut donc avoir en tête tous les problèmes évoqués précédemment mais aussi comprendre ce qu'il y a d'unique dans l'architecture. Ainsi, s'ajoutent en plus les spécificités du monde de la banque : multiplateforme, multi environnement, multi technologie, ...

Le point important est bien sûr de d'impliquer les équipes de tests dès la phase de conception de l'architecture SOA : prévoir l'approche de tests lors de la définition des besoins et ne pas avoir des surprises à la fin au niveau performance ou sécurité. Il y a beaucoup d'éléments dans l'architecture SOA et il n'est pas forcément possible de tout tester : il faut ainsi savoir ce qui y est important et ainsi satisfaire tous les engagements pris lors de la conception de l'entreprise.

Les applications basées sur SOA évoluent constamment et il est nécessaire de pouvoir passer rapidement des scripts de tests permettant de tester toutes les fonctionnalités. Il est bien sûr important d'utiliser des outils, avec une interface Homme Machine facilement utilisable, qui permettent de tester les aspects uniques des applications SOA qui sont sans interfaces graphiques et où il y beaucoup d'échanges de messages. Aucun outil ne peut satisfaire toutes les applications, environnements et tests possibles : il faut donc se construire une solution adaptée en n'hésitant pas à utiliser différents logiciels.

Si la qualité est au coeur de l'architecture SOA, toutes les possibilités offertes pourront être utilisées.

ANNEXES

CICS - DÉTAILS

COBOL - EXEMPLE DE RÉUTILISATION EN TANT QUE WEB SERVICE AVEC LES LOGICIELS ACUCORP

Il est possible de transformer le programme Cobol en service web. Ici, un exemple avec les logiciels de l'entreprise Acucorp (fournit un moyen d'invoquer un programme Cobol, génération d'un fichier WSDL à partir des spécifications, génération d'une interface permettant d'appeler le service, outils donnant des informations statistiques pendant l'exécution, ...).

LE MODÈLE DE TEST « ONSITE - OFFSHORE »

Le modèle de test « Onsite - Offshore », qui permet d'externaliser les procédures de tests, est très utilisé. Le client est donc « Onsite » (à gauche) et l'entreprise ou service dédié aux tests est « Offshore » (à droite).

On peut imaginer qu'une petite équipe travaillerait chez le client alors qu'une plus grande serait à l'extérieur. L'équipe chez le client fournit alors une interface avec le client et coordonne le travail externe, et l'équipe externe peut exécuter tous les cas de tests et rapporter tous les défauts.

BIBLIOGRAPHIE

SITES INTERNET

Greenhat, integrated product suite for supporting your SOA project - www.greenhat.com

DOCUMENTS ELECTRONIQUES (PDF)

Communication par événements et bus à messages - Sacha Krakowiak - Université Joseph Fourier

Automating what you can't see - Testing Middleware for enterprise - Jon Howarth, Robert Ryan

Tests - Lionel Seinturier - Université des Sciences et Technologies de Lille

SOA : Définition, Utilisation dans le monde de la banque et méthodologie de test

INTRODUCTION