Samir AMZANI's BLOG

Au cours de ces vingt dernières années, le développement des  applications a eu tendance à se faire en fonction des besoins des  entreprises. Une nouvelle application était créée à chaque fois qu'un  nouveau besoin émergeait. Il est souvent nécessaire de développer des  applications permettant de résoudre les problèmes à court terme afin des'adapter à la vitesse de croissance des entreprises. La plupart des  entreprises utilisent diverses applications fonctionnant sur des postes  de travail ou des serveurs. Les données des entreprises peuvent prendre  différentes formes : des tableurs aux bases de données en passant parles logiciels commerciaux spécifiques et de comptabilités.

Toutefois, le stockage d'informations à différents emplacements et dansplusieurs applications peut entraîner ultérieurement des problèmesd'architecture. Les données sont dispersées, entraînant ainsi desprocessus métiers inefficaces et une baisse globale de la productivité.

Le but de l'intégration des applications d'entreprise est donc de communiquer  ces applications et pour cela il existe plusieurs approches possibles:

1- L'approche manuelle :

L'approche manuelle représente l'approche la plus coûteuse et la plusprimitive pour l'intégration d'applications. Des rapports sontimprimés, puis saisis de nouveaux manuellement dans une autreapplication. Malgré son coût et son aspect fastidieux, cette approcheaujourd'hui est la plus répandue parmi les entreprises actuelles.

2- L'approche Import/Export

Avec cette approche, les données sont exportées par l'opérateur ouautomatiquement par le logiciel, transférées, puis importées dans uneautre application. L'un des inconvénients majeurs de cette approche estla nature statique des données. Les changements effectués après uneexportation n'apparaissent pas tant qu'une autre exportation n'a pasété réalisée. Par conséquent, la deuxième application disposeuniquement d'un statut approximatif des données. Cette approche neconvient pas pour des transferts en temps réel. Par ailleurs, leformatage des données exportées à partir d'une application vers uneautre application peut poser des problèmes. Il est souvent nécessairede développer plusieurs applications pour transformer les données en unformat lisible par la deuxième application, s'ajoutant aux problèmesdes autres applications à gérer.

3- L'approche ASDP (accès aux structures de données primitives)

Cette approche a été révolutionnaire car les éditeurs de bases dedonnées permettaient aux bases de données sous-jacentes d'accéder auxstructures des données. Cela permettait d'accéder en temps réel acelles-ci. Les standards tels que ODBC permettaient d'accéder auxdonnées à partir d'applications serveur ou bureautiques. Les donnéespouvaient être ainsi lues à tout moment et étaient précises. Toutefois,le partage d'applications n'existait pas et toutes les applicationssouhaitant accéder aux données devaient dupliquer les fonctionnalités.Toute modification apportée à la structure des données (par exemple,l'ajout d'un nouveau champ d'adresse) nécessitait la modification detoutes les applications accédant à la structure des données pourpouvoir bénéficier de ce changement. Etant donné que plusieursapplications renferment des règles d'intégrité strictes, telles que lesapplications de comptabilité, autoriser d'autres applications àmodifier les données au niveau le plus faible sans qu'elles soientvérifiées par l'application d'origine, pouvait entraîner de sérieuxproblèmes d'intégrité des données. L'un des principaux avantages del'accès aux structures de données primitives était la formulation derequêtes ad hoc par les utilisateurs à partir de produits tels queMicrosoft

Excel.Toutefois, les utilisateurs devaient apprendre comment les programmeursconcevaient les structures de données et suivre une nouvelle formationsi les structures étaient modifiées.

4- L' approche des API personnalisées

Comme nous l'avons décrit précédemment, vous risquez d'être confronté àdes problèmes d'intégrité si vous accédez aux données à un niveaufaible sans tenir compte des problèmes d'intégrité ou des règles del'entreprise. Pour résoudre ce problème, plusieurs éditeursd'applications tels que SAP® et PeopleSoft® ont créé leur propre APIpersonnalisée pour autoriser d'autres applications à partager lesfonctionnalités des applications et des données. Toutefois, chaque APIet chaque méthodes utilisées pour l'appeler étaient différentes. Etantdonné que ces API étaient étroitement couplées aux applicationsspécifiques, les autres éditeurs d'applications et d'outils dedéveloppement ont dû investir énormément pour prendre en charge les APIde chaque éditeur d'applications. Même si le concept semblaitprometteur, ces API ne furent jamais acceptées par les autres éditeurs.

5- L'approche actuelle : les SERVICES WEB

Les services Web se fondent sur l'approche des API personnalisées,bénéficiant ainsi de tous ces avantages tout en proposant d'autresservices. Les services Web utilisent des standards ouverts. Ils ne sontdonc pas étroitement couplés et ne sont donc pas liés à la technologied'un seul éditeur. Les services Web permettent également à uneapplication d'appeler une autre application grâce aux protocolesstandard tels que SOAP et XML. Cette approche garantit l'intégrité desdonnées car l'application appropriée est l'unique application quitraite les données. En cas de changement des fonctionnalités del'entreprise, seules les fonctionnalités de l'application appropriéedoivent être modifiées.

Etude de cas (Projet professionnelle universitaire 2005/2006)