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

Offrir davantage d’ouverture et de compatibilité entre systèmes informatiques est depuis longtemps un secteur en constante évolution.

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[OASIS : Organization for the Advancement of Structured Information Standards, voir [ ]].

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[[Données brutes : données binaires, images, documents de divers formats, etc.]] » (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 :
-# 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.
-# 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 œuvre 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 œuvre 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.

Mettre en œuvre des solutions inter opérables

La mise en œuvre de l’interopérabilité ne prend cependant pas en compte tous les paramètres évoqués précédemment. Effectivement, la plupart des solutions commerciales, ainsi que les solutions en production visent principalement le domaine de l’intégration.

La nuance entre intégration et interopérabilité est importante. En effet, l’intégration consiste plus à l’ « assimilation » d’un système par un autre qu’à un réel dialogue bilatéral entre systèmes.

Ces solutions, telles que Borland Janeva ou JNBridge, permettent principalement l’accès bas niveau à des objets Java en .NET, et réciproquement, donc proche du principe, déjà évoqué, de simples appels à des fonctions. Cette technique est appelée interopérabilité par « couplage fort », ou encore intégration applicative, comme nous l’avons vu précédemment.

Mais pour amener l’interopérabilité au niveau fonctionnel réellement attendu, et nécessaire dans le cadre des réels besoins des SI métier, les architectures logicielles doivent évoluer et être pensées en prévision de ce niveau fonctionnel.

En outre, pour garantir la transparence d’accès aux différents SI, et une indépendance technique maximale entre les applications devant interopérer, les « contrats » opérationnels entre les différents systèmes en jeu doivent être indépendants à la fois des infrastructures utilisées et des implémentations des différents services. Ces architectures, dites à « couplage lâche », se basent principalement sur la notion de SOA, Service Oriented Architecture, autre notion très à la mode ces derniers temps !

Le couplage lâche

L’objectif de cette technique est de s’éloigner de l’approche intégration pour privilégier une approche de dialogue applicatif.

Le dialogue applicatif, comme son nom l’indique, consiste à définir des langages d’échanges entre applications, indépendamment de la technologie utilisée ou du mode de fonctionnement particulier des fonctionnalités à partager.

Qui plus est, ces langages se rapprochent davantage du besoin métier réel que du procédé technique à utiliser pour répondre à une problématique donnée. Le dialogue métier une fois défini, c’est une couche logicielle particulière, liée à l’application à manipuler, qui est responsable de la « traduction » de la requête métier en enchaînement de tâches techniques. Réciproquement, cette même couche a la responsabilité de transformer le résultat produit dans le langage métier attendu par l’application appelante.

Dans ce cadre, une application offrant ses services définit un contrat explicite d’utilisation, résidant dans la définition du langage.

L’aspect uniquement métier du langage est purement théorique. Pour répondre aux problématiques techniques, telles que le protocole d’échange utilisé (http, smtp, ftp, etc.), les besoins de sécurité ou d’authentification des données échangées, un ensemble de standards ont été définis.

C’est sur ce point que le consortium OASIS, dont font partie des acteurs comme BEA, IBM et Microsoft, a publié des normes permettant de définir ces différents aspects. Toutes ses normes se basent sur les Web Services et sur le protocole SOAP pour leur mise en œuvre. Sans rentrer dans les détails, les normes suivantes sont définies :

• WS-S (Web Services – Security) pour les aspects sécurité
• WS-R (Web Services – Routing) pour le routage des messages
• WS-A (Web Services – Attachment) pour gérer les données brutes dans les messages

En revanche, l’utilisation de ces standards relève toujours davantage du prototypage que du réel développement applicatif. De plus, aucune norme n’est encore définie pour régler la gestion transactionnelle, facteur clé de l’interopérabilité pour de nombreux types de services.

Dans le monde .NET, un package nommé WSE (Web Services Extension) offre une première implémentation de ces standards. Réciproquement dans le monde Java, IBM fournit le package ETTK (Emerging Technologies ToolKit).

Cependant, leur objectif est plus d’offrir un « proof of concept » de l’interopérabilité par couplage lâche que de réelles briques structurantes à destination de projets réels.

L’alternative de la simplicité

Afin de garantir aujourd’hui une ouverture la plus large possible entre les applications, la technique la plus répandue consiste toujours à s’appuyer sur des échanges de type XML-RPC ou REST (Representational State Transfer, en savoir plus).

L’utilisation des capacités des infrastructures des couches basses permet de répondre aux problématiques de sécurité et de routage. Certes, cela nécessite une administration à la fois des canaux physiques utilisés ainsi que de l’application, mais cette approche pragmatique a fait ces preuves.

Ainsi, utiliser la configuration des firewalls pour assurer la sécurité d’accès à un service permet de gérer au niveau infrastructure les droits d’accès aux différents services. Ce type de sécurité est entre autre fondé sur la reconnaissance d’adresse IP de partenaires et sur la forme des URL appelées.

Cette démarche s’appuyant sur l’infrastructure, il est toujours possible d’utiliser des routeurs, proxy, etc. pour assurer le routage de services (en se basant sur les URLs par exemple).

La maîtrise de la qualité des services offerts peut là encore reposer sur tous les outils déjà existants sur les infrastructures. Les techniques existantes permettant d’assurer l’équilibrage de charge, la reprise sur incident, etc. sont applicables.

Concernant les aspects transactionnels, l’utilisation de cette démarche est plus restrictive. Cependant, ce besoin n’est pas le plus fondamental à l’heure actuelle, et il est toujours possible de « grossir » les échanges XML-RPC ou REST en encapsulant en leur sein les données à conserver lors de la « transaction ». L’idéal est toutefois d’utiliser des transactions se limitant à un seul appel distant.

Que faire aujourd’hui

Certes, dans les deux années à venir, l’ensemble des standards gravitant autour des Web Services et de SOAP devrait permettre une réelle abstraction de ces problématiques.

De plus, ces évolutions vont également permettre aux développeurs d’échapper à l’écriture longue et fastidieuse de code technique, et faciliter la gestion de l’infrastructure par les équipes d’administration.

Néanmoins aujourd’hui, la majeure partie des solutions ouvertes et inter opérables reposent sur des architectures de type XML-RPC ou REST. Ces architectures même si elles sont plus rudimentaires disposent aujourd’hui de deux avantages appréciables :
– l’enveloppe technique est éprouvée et maîtrisable facilement par des équipes de développement quelque soit la technologie qu’ils utilisent,
-on peut faire en sorte qu’aucune modification de l’environnement de production ne soit nécessaire.

Ces avantages sont bien souvent déterminants lorsqu’il est question de faire collaborer deux entités distinctes.