Catégorie : Informatique

Les service web sont par définition indépendants d’une technologie et interopérables, c’est à dire compatible entre différentes technologies (comprendre système d’exploitation ou langages). Il y a donc différentes façon de construire des services web, au moins une par technologie et surement des bonnes pratiques pour assurer cette interopérabilité.

J’ai listé ici les différents frameworks de Web Services (SAOP, WDSL & cie) pour quelques technologies.

Commençons par celui ce que je connais le mieux…

Frameworks pour Java

La spécification JAX-WS (Java Api for Xml Web Services) définit les API et les outils pour implémenter SOAP 1.1 et WSDL 1.1 en java.
JAX-WS est disponible d’office dans l’environnement virtuel client Java SE (Standard Edition) depuis la version 1.6.

Suite à la création de cette spécification, il y a un vaste choix de frameworks de Web Services pour java. En voici quelques uns, détaillés par la suite :

• Apache Axis2
• Glassfish Metro
• Apache CXF
• JbossWS
• Oracle Weblogic Application Server
• IBM WebSphere Application Server

Apache Axis 2

Apache Axis2 n’implémente que SOAP et WSDL mais possède une architecture modulaire autorisant le rajout de modules qui apportent de nouvelles fonctionnalités.
Par exemple le module Apache Rampart est une implémentation des normes WS-Security 1.0/1.1, WS-SecureConversation, WS-SecurityPolicy 1.1/1.2, WS-Trust, etc.
Il existe d’autres modules pour les normes WS-Addressing, MTOM ou XML-RPC. Et d’autres modules pour fournir de nouveau moyen de transports de messages SOAP : via TCP, UDP, email, SMS, XMPP (protocole de tchat), file JMS, etc.

Apache Axis2 est une réécriture de Apache Axis, framework pionner dans l’implémentation des Web Services en java, c’est probablement pour cette raison qu’il n’est pas conforme à
JAX-WS.

Glassfish Metro

Il s’agit de l’implémentation de référence de JAX-WS coté serveur, ce framework propose des librairies java rigoureusement conforme à la spécification, sans fonctionnalités supplémentaires.
C’est un module du serveur d’applications J2EE (Java 2 Entreprise Edition, la version serveur de l’environnement virtuel java) Glassfish de Sun/Oracle.

Apache CXF

Apache CXF est l’implémentation standard de JAX-WS faite par la fondation Apache en plus d’Axis2.
Ce framework est compatible avec les normes WS-Addressing, WS-Policy, WS-ReliableMessaging, WS-Trust (partiellement), MTOM et WS-Security.
Ce framework est indépendant d’un serveur d’application J2EE et est conçu pour être utilisable avec le framework Spring IoC (Inversion of Control) d’assemblage de composants logiciel java avec XML.

JBossWS

JBossWS est l’implémentation standard de JAX-WS pour le serveur d’application JBoss. Cette implémentation s’appuie sur divers frameworks java libre et depuis la version  4 du serveur d’application JBoss, JBossWS est une intégration de Apache CXF dans le serveur d’application grâce à Spring.

Oracle Weblogic Application Server

Le serveur d’application J2EE Weblogic d’Oracle (historiquement le serveur a été créé par la société BEA Systems) est compatible avec JAX-RPC (Java API for Xml based RPC) au lieu de JAX-WS.
Ce serveur est bien sur, comme Axis2, compatible avec SOAP 1.1 et WSDL 1.1. Il est également compatible UDDI 2.0, et propose des solutions propriétaires pour la gestion des problématiques de sécurité et de communications asynchrones.

IBM WebSphere Application Server

Le serveur d’application J2EE WebSphere 7 d’IBM est compatible avec JAX-WS,WS­SecureConversation, WS­Trust, WS­SecurityPolicy, WS­Policy, WS­Addressing,WS­MetadataExchange, WS-ReliableMessaging, WS-Trust, MTOM, d’autres normes de WebServices du W3C et d’autres normes définies par l’OASIS (Organization for the Advancement of Structured Information Standards), un consortium d’entreprise de l’informatique dont l’objet est de promouvoir l’adoption de standards informatiques.

C’est apparemment la solution la plus riche en termes de normes de Web Services implémentées, pour java et pour tous les langages et tous les systèmes d’exploitation confondus.

Frameworks pour .Net

Pour les langages gérés par le framework .Net (C#, VB.Net, etc.), le choix se pose entre WSE est WCF (Windows Communication Framework, le remplaçant plustôt qu’une alternative en fait). Les différences les plus notables sont :

• WCF est la dernière implémentation SOAP de Microsoft pour .Net 3.0 ;
• les performances de WCF sont augmentées de 200 à 400% par rapport à WSE ;
• WCF implémente un plus grand nombre de normes WS-*.

Donc pour faire du WebService sur .Net il faut utiliser WCF et .Net 3.0 minimum

Frameworks pour C++

Pour C++, les frameworks les plus connus sont Axis for C++ de la fondation Apache, et gSOAP, les différences les plus notables sont les suivantes :

• Axis for C++ :
  • fonctionne sous Windows et Linux ;
  • fonctionne comme un serveur HTTP indépendant ou en module pour le logiciel de serveur web Apache Httpd ;
  • dispose d’une IHM WEB pour le déploiement des Web Services à chaud
  • ne supporte que les normes SOAP et WSDL, et contrairement à Axis2 pour java, il ne dispose pas d’une architecture modulaire le rendant extensible.
• gSOAP :
  • fonctionne sous Windows, MacOS, Linux, Unix et OpenVMS
  • supporte les normes SOAP, WSDL et UDDI.
  • support des normes WS-* suivantes :
    • WS-Policy 1.2/1.5 et WS-SecurityPolicy 1.2
    • WS-Security (2004/01),
    • WS-Addressing (2003/03, 2004/03, 2004/08, 2005/03)
    • WS-ReliableMessaging
    • WS-Discovery (partiellement)
  • Compatible XML-RPC
  • Permet de faire des appels SOAP sur UDP
  • Fonctionne en mode serveur HTTP autonome ou en module pour les logiciels de serveur web IIS et Apache Httpd ;

gSOAP paraît être le framework préférable pour une application en C++ utilisant les Web Services, sous Windows ou sous un autre système d’exploitation.

Frameworks pour d’autres langages

Pour perl, le seul framework disponible semble être SOAP::lite, une collection de modules perl pour le logiciel de serveur web Apache Httpd, ce framework ne gère que SOAP et WSDL.
Pour PHP, il est possible d’utiliser NuSOAP, un ensemble de classes PHP à utiliser coté serveur fournisseur de Web Services, compatible avec SOAP 1.1 et WSDL 1.1 uniquement.
Pour python, il est possible d’utiliser Zolera SOAP Infrastructure (ZSI), un paquetage Python compatible là encore avec SOAP 1.1 et WSDL 1.1 uniquement.

Conclusions

Pour assurer l’interopérabilité entre les technologies je ne m’aventurerais pas au-delà de SOAP1.1 et WSDL1.1

WS-* à toujours été une notion assez vague pour moi, je me suis donc penché sur la question.

Connaître l’historique des services web permet de mieux comprendre ce que sont les Web Services et d’où viennent les normes WS-*.

Le schéma ci-dessous présente chronologiquement de gauche à droite les différentes normes concernant les services web et leurs origines.

Lorsque les premiers programmes appelables par d’autres programmes ont été créés, ils s‘appuyaient sur un concept nommé RPC (Remote Procedure Call) qui donne les principes d’appel de procédure ou de fonction entre deux logiciels. RPC date de 1976 soit entre la mise en place d’ARPANET (1971), l’ancêtre d’Internet et d’Internet (1982).

La programmation orienté objet à fait évoluer le concept de RPC et impulsé l’initiative CORBA par l’OMG (Object Management Group, un consortium de plusieurs entreprises leader en informatique tels que Hewlett-Packard, IBM, Sun Microsystems, Apple Computer).

CORBA une spécification de protocole de communication orienté objet qui parviendra à une interopérabilité effective avec la version 2.4 (2000) suffisamment exhaustive et claire pour que les éditeurs de cadriciel (ou framework) CORBA puissent garantir des communications entre applications CORBA réalisées avec des cadriciels, langages et systèmes d’exploitation différents.

A partir de CORBA émergeront plusieurs technologies d’informatique distribuée, d’abord conçues pour fonctionner dans un réseau local ou privé plutôt qu’Internet : il s’agit par exemple des EJB (monde Java) ou de DCOM (monde Microsoft).

Le Web est la partie visible d’Internet, ce sont d’abord les sites web consultables par les internautes. Ces sites web sont composés de pages web le plus souvent au format HTML, qui sont transférés aux navigateurs web via le protocole HTTP. Le protocole HTTP est né en 1991 près de 10 ans après la création d’Internet. Les serveurs web et les navigateurs web communiquent ensemble via ce protocole.

En 1993, la norme CGI (Common Gateway Interface) à permit de rendre les serveurs web plus intelligent. De simple serveur de fichier HTML contenant des informations statiques (i.e. qui n’évoluent pas automatiquement en fonction du temps ou des demandes des navigateurs), un serveurs web à pu générer des pages HTML avec du contenu issu de traitement tels que des calculs ou des consultations de bases de données.

CGI a rendu possible les services  sur internet, ces services étant d’abord utilisables par des internautes humains, pas des logiciels.

XML-RPC est une spécification de protocole reconnue comme un sous-ensemble de la première version de SOAP que Microsoft a refusé de rendre public. XML-RPC souffrira comme pour CORBA, de quelques manques ou imprécisions et de l’ombre de SOAP 1.1, le protocole promu par le W3C, le consortium international qui définit les standards du World Wide Web.

En 2000 le terme de Web Service est apparu pour définir un services web décris en WSDL, utilisable via le protocole SOAP 1.1 et éventuellement inscrit dans un annuaire UDDI. Il s’agit des normes socles des Web Services.

A ce jour XML-RPC est toujours utilisé,  car il est plus simple : il n’a pas de notion  orienté objet, et un mécanisme de sécurité simpliste. Il est donc plus facile à mettre en œuvre que SOAP, tout en étant souvent suffisamment complet pour répondre aux exigences techniques de beaucoup de solutions logicielles sur Internet.

Note :  les annuaires UDDI sont peu utilisés sur Internet, ils ont moins de succès que des annuaires de web services informels qui disposent d’une IHM tels que ServiceRepository ou ProgrammableWeb .

Les normes socles des Web Services (SOAP, WSDL) évoluèrent pour plus de maturité et de nouvelles normes ont été créées pour traiter de différentes problématiques non couvertes : ebXML, WS-Policy, WS-Discovery, WS-Inspection, WS-Eventing, WS-Addressing, WS-Routing, WS-Referral, MTOM, WS-Enumeration, WS-Transfer…

Ces nouvelles normes, dédiées à une problématique particulière, sont regroupées sous le terme WS-*. Nous n’allons pas ici présenter toutes les normes WS-*, mais il faut noter que l’apparition de ces normes paraît quelque peu désorganisée : la norme WS-Policy, dont l’objectif est de couvrir les problèmes de sécurité et de confidentialité qui sont devenues essentielles sur Internet, est complétée de plus de cinq autres normes relatives à la sécurité ; les normes WS-Routing et WS-Referral ont rapidement été remplacées par WS-Addressing.