Développement

Le point sur l’interopérabilité J2EE, .NET et PHP

Frédéric Bon, publié le 3 mai 2004

Tags: pc, développement, java, windows/.net, php, entreprise, transactionnelle, gestion transactionnelle

Offrir davantage d’ouverture et de compatibilité entre systèmes informatiques est depuis longtemps un secteur en constante évolution. Concernant les technologies les plus répandues dans le développement des SI modernes, J2EE, .NET et PHP, les discussions sur ce domaine sont sujettes à polémique.

L'avènement des technologies internet n'a fait qu'étendre ce vieux concept à des applications distribuées au-delà d'un réseau d'entreprise. Le secteur économique des NTIC est bien évidemment à l'écoute de ce genre de problématique. En effet, fournir des services informatiques intégrables directement, et de manière transparente, au sein de SI existants intéresse nécessairement des acteurs, existants ou futurs, de ce marché.

D'ailleurs, les grands éditeurs tels que BEA, IBM ou encore Microsoft communiquent fortement sur la problématique de l'interopérabilité, et travaillent même de concert sur le sujet dans différents organismes de normalisation tels qu'OASIS. Cependant, au-delà du "buzzword", la signification réelle de l'interopérabilité reste floue. Concernant les technologies les plus répandues dans le développement des SI modernes, J2EE, .NET et PHP, les discussions sur ce domaine sont sujettes à polémique.

Interopérabilité: définition

Dans l'absolu, l'interopérabilité consiste à utiliser conjointement des fonctionnalités d'applications basées sur des technologies différentes (J2EE, .NET, PHP, C++, etc.). Une des motivations peut provenir de la volonté de consommer depuis ses applications des services métier gérés par des partenaires externes (vente d'assurances, suivi d'envois de colis, etc.).

Le véritable objectif est alors de permettre cette interopérabilité le plus simplement possible, en abstrayant à la fois aux utilisateurs finaux et aux développeurs la complexité et la diversité des environnements. L'administration technique du SI ne doit cependant pas s'en trouver complexifiée outre mesure. Il est important que les équipes responsables de cette administration puissent facilement prendre le contrôle et gérer ces solutions.

Prenons l'exemple d'une agence de voyage souhaitant déléguer le service de paiement d'un package voyage complet au SI de sa banque, et les services de réservation des billets d'avions et des chambres d'hôtel aux services respectifs de ses partenaires.

Au-delà de simples appels de fonctions sur des applications de ces différents SI, des besoins de sécurité (paiement par carte bancaire), de gestion transactionnelle (réservation, etc.) ainsi que de transmission de données "brutes"* (photos de la destination, plan d'accès, etc.) doivent être gérés. Et tout cela de la manière la plus transparente possible et avec la plus grande facilité d'administration!

Le couplage fort, ou l'intégration d'applications

Dans les technologies J2EE et .NET, le couplage fort est fondé sur l'utilisation de proxy. Des outils permettent la création de ces proxy, par exemple d'une classe Java dans l'environnement .NET. Cette classe est alors manipulable en toute transparence dans l'environnement .NET au travers du proxy généré. Ce couplage fort correspond donc à l'intégration des fonctionnalités de la classe Java considérée dans l'application .NET.

L'utilisation d'une telle classe est certes transparente pour le développeur, et permet très simplement de l'utiliser dans l'environnement .NET. En revanche, cette méthode pose des difficultés en terme d'évolutivité et d'agilité des applications concernées.

L'inconvénient majeur de ce type de couplage est la forte dépendance introduite entre l'application .NET et l'application Java. Une modification, même minime, sur le fonctionnement de l'application Java, dans notre exemple, peut provoquer le non fonctionnement de l'application .NET.

En effet:

1- Le développeur .NET utilisant la classe Java doit connaître le fonctionnement intrinsèque de cette dernière, se liant donc fortement à son utilisation "technique". Les contraintes induites sur le principe de fonctionnement de la classe Java sont difficilement évaluables.

2- Toute modification impactant directement (modification des méthodes, etc.) ou indirectement (par exemple, nécessité de configuration de la classe avant utilisation) la classe Java engendrera inévitablement des problèmes de fonctionnement dans l'application .NET.

Cette technique de mise en oeuvre permet toutefois de répondre facilement, dans une optique de développements "jetables", à des carences fonctionnelles déjà couvertes par d'autres applications. Elle ne permet par contre pas de faire appel à distance à des fonctionnalités mise en oeuvre dans d'autres SI, comme ceux de partenaires par exemple.

Pour tout autre type de besoins, les solutions à couplage lâche doivent donc être privilégiées.

* données binaires, images, documents de divers formats, etc. (suite...)

Page 1 | Page 2 | Page 3

Réagissez

#1 - par Azémar Pierre le 17/05/2004

Depuis trop longtemps la problématique de l'intéropérabilité est soulevée.Les constructeurs n'évoluent pas dans ce sens. Il faut en fait un language compatible universel,face à un éventail très large de matériels .Surtout au niveau de la micro-informatique .De plus conçernant window il y a un tel amalgame que, si un problème exciste il bloque tout et cela devient particulèrement navrant car à chaque fois il faut réinitialiser le tout . Donc pour l'instant à ce niveau tout est à revoir .

signaler au modérateur répondre