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

 > 

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

( Télécharger le fichier original )
par Cédric MORA
IFIPS - Maison de l'ingénieur - Spécialité informatique 2008
  

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

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.

précédent sommaire suivant