ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D Etude historique et comparative des techniques de transfert de données avec 4D v11 SQL

Transcription

1 Livre Blanc 4D ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D Etude historique et comparative des techniques de transfert de données avec 4D v11 SQL v avril D v11 SQL Product Line

2 2 Sommaire Echange de données entre applications 4D 4 Chapitre 1 : Historique des techniques de connectivité 5 4D Open for 4D 5 HTTP 5 XML et SOAP 5 SQL 6 Chapitre 2 : Inventaire des solutions actuelles 7 SQL Pass-through 7 Web Services avec SOAP 7 XML sur HTTP 7 Chapitre 3 : Quelques scénarios d utilisation 9 Synchronisation 9 Interopérabilité 9 Applications distribuées 9 Tableau comparatif des technologies d échange de données incluses dans 4D 11 Annexes : fiches techniques des différentes solutions 12 SQL pass-through 13 Généralités sur SQL pass-through 13 Comment établir la connexion 13 SQL pass-through et la sécurité 15 Bénéfices de SQL pass-through 15 Inconvénients de SQL pass-through 15 Principales caractéristiques de SQL pass-through 16 SOAP/Web Services 17 Généralités sur les Web Services 17 Description d une séquence requête/réponse SOAP 18 Contenu d un message SOAP 19 Optimisation de SOAP entre deux applications 4D 19 SOAP et la sécurité 20 Bénéfices de SOAP 20 Inconvénients de SOAP 21 Principales caractéristiques de SOAP 21

3 3 XML sur HTTP (avec 4D Web Server) 22 Généralités sur le protocole HTTP 22 Optimisation de la communication HTTP avec "Keep-Alive" 22 HTTP et la sécurité 23 Mise en œuvre d un service XML sur http 23 Bénéfices de XML sur HTTP 24 Inconvénients de XML sur HTTP 24 Principales caractéristiques de XML sur HTTP 25 Bibliographie 26

4 4 Echange de données entre applications 4D Très tôt dans l histoire de 4D, ses utilisateurs professionnels ont cherché à faire collaborer leur application avec d autres instances de bases de données 4D, que ce soit pour répliquer ou distribuer leur information. En effet, au sein du réseau local, 4D Server (en tant que serveur applicatif et de données) et 4D Backup (intégrant une solution de miroir prête-à-l emploi) couvraient généralement ces deux fonctions, mais pour ce qui est des réseaux étendus (WAN), et malgré quelques tentatives en ce sens (comme l ancien 4D Remote) la notion de client léger propriétaire (c est-à-dire sans avoir recours à des solutions de type TSE ou Citrix) ne pouvait être implémentée de façon aussi efficace que les autres briques de l architecture 4D. Le principal défi consistait à garantir un taux de transfert suffisamment rapide sur des tuyaux extrêmement fins, et ce malgré des connexions et déconnexions répétées, afin d offrir à l utilisateur une expérience acceptable. De son côté, le développeur se devait d être extrêmement sélectif dans ses choix, et faire en sorte de rendre le plus parcellaire possible l échange d information entre applications 4D distantes, afin de ne pas saturer bande passante, mémoire et buffers. Aujourd hui, alors que le besoin s'est accru (agences multi-sites, mobilité des intervenants), le contexte technologique a beaucoup changé, et 4D lui-même a beaucoup évolué. La notion de distance ne dépend plus de la géographie, et, l offre créant le besoin, les volumes mis en jeu ont explosé tout autant que les capacités physiques de transfert (disponibilité haut-débit, ADSL). Alors que, fait extrêmement rare dans l industrie du logiciel, il est courant de voir du code 4D de plus de quinze ans d âge continuer à tourner à l identique sur des applications professionnelles parfois critiques, 4D a procédé avec la version 4D v11 SQL, à sa plus grande mutation technologique depuis sa création. Il apparaît donc opportun de procéder à un état des lieux des solutions d échange de données entre bases 4D non connectées.

5 5 Chapitre 1 : Historique des techniques de connectivité Chronologiquement, quatre technologies sont successivement apparues pour répondre au besoin de d échange de données entre applications 4D. 4D Open for 4D 4D Open for 4D est un plug-in basé sur l API native de 4D (dénommée 4D Open) qui a vu le jour en 1994 pour répondre aux besoins de connexion distante depuis n importe quel type d application 4D vers 4D Server. Reconnue comme extrêmement efficace car économe en ressource, rapide et solide, cette solution avait pour seul inconvénient de nécessiter l écriture d une couche logique en plus du code 4D. En effet tout un jeu de commandes spécifiques à 4D Open for 4D, à implémenter côté client, permettait de découvrir la structure de données (fonction que n offrait pas le propre langage de 4D), puis de consulter et modifier des sélections d enregistrements, après avoir créé des liaisons fortes, ou binds, entre les tables, champs, variables ou tableaux des deux constituants de la connexion 4D Open. Avec l avènement de 4D v11 SQL, le format natif des données 4D a été profondément bouleversé occasionnant une conversion radicale de la structure comme des données des versions antérieures. Les interpréteurs des langages SQL et 4D ayant le même niveau d accès à la base de données, et 4D pouvant dialoguer nativement avec toute source ODBC, recréer ou convertir une API de communication est devenu inutile. Plutôt que s efforcer de maintenir artificiellement une surcouche obsolète, il a été fait le choix de continuer à privilégier l adoption des standards les plus répandus et d investir les efforts de développement vers des technologies innovantes. C est pourquoi 4D Open for 4D a officiellement cessé d être supporté. A noter cependant que sous Windows et Mac PPC, il est encore possible d utiliser le plug-in 4D Open for 4D 2004 dans un projet v11 SQL pour interroger une application tournant sous 4D Server Si cette annonce a pu inquiéter un certain nombre de développeurs, ce n est pas tant par nostalgie de la technologie 4D Open, que par interrogation sur les moyens à mettre en œuvre pour remplacer un code parfois existant de longue date (et, au passage, probablement largement rentabilisé) et ayant coûté un investissement en temps relativement important. Mise à jour après mise à jour, et particulièrement depuis 4D v11 SQL Release 3, il s avère que des solutions encore plus économes et flexibles existent pour remplir les mêmes fonctions, comme nous le verrons plus loin. HTTP Depuis 1995, 4D intègre un serveur HTTP performant permettant bien sûr la publication de pages Web dynamiques ou statiques. Mais, en tant que protocole parfaitement défini et largement accepté dans la plupart des entreprises, certaines d entre elles n ouvrant parfois que le port 80, et du fait qu aucune passerelle additionnelle ne filtre l accès aux enregistrements, HTTP est également une alternative intéressante pour le transport de données de type texte, et permet donc la mise en place d outils de dialogue entre deux applications 4D (à condition que l une d entre elles au moins possède une licence Web Server ou Web Services Server). Cette programmation de bas niveau, robuste et rapide n a que le défaut de ses qualités, elle s éloigne des paradigmes du développement rapide et requiert dont un certain investissement initial en temps que le développeur 4D n'a pas toujours la possibilité d'effectuer. XML et SOAP Défini en 1998, et désormais parfaitement mature, XML s est imposé comme un format standard d'échanges de données incontournable depuis plusieurs années. Puis, par la force de l usage, SOAP a émergé en tant que principal protocole d'exploitation de Services Web. 4D a su rester à la pointe de cette évolution avec une implémentation dès 4D 2003 des premières fonctions de manipulation XML et le support des Web Services, complété et renforcé en 4D Depuis, l usage d XML s est répandu jusque dans la gestion des préférences de 4D, de la sauvegarde, ou encore la manipulation des formulaires utilisateurs. Quant aux Web Services, ils sont disponibles en mode Serveur (avec licence dédiée) ou Client (en standard), avec des fonctions avancées telles que le support des modes RPC et DOC, la génération automatique de méthodes proxy ou la création

6 6 automatique de WSDL dynamique. Naturellement XML et SOAP sont d excellents candidats au transfert de données entre applications 4D. SQL SQL (Structured Query Language) est l un des derniers standards intégré au cœur de 4D. Non pas que 4D fût auparavant incapable de comprendre le SQL, mais son interprétation passait par des couches logicielles intermédiaires, en particulier l API 4D Open citée plus haut dans le cas d une requête ODBC entrante. La réécriture complète du noyau est le plus grand chantier réalisé depuis les origines de 4D. Le résultat est un environnement à la fois complètement standardisé, comparable aux bases de données du marché les plus réputées, et totalement compatible, après conversion, avec les anciennes applications. Ceci permet de continuer à travailler en langage 4D tout en insérant à tout moment des sections entières de commandes SQL. Rappelons que les deux langages sont traités de la même façon au niveau de la base de données et qu aucun des deux n a priorité sur l autre. Au bénéfice de SQL, la possibilité de tirer parti du traitement multithread préemptif de 4D v11 SQL, une meilleure expressivité des requêtes particulièrement sensible sur les recherches complexes et les jointures, enfin une popularité importante permettant de réutiliser du code source d un environnement à l autre et d être compréhensible par n importe quel développeur. Pour preuve de la richesse issue de l implémentation de SQL dans 4D, après seulement quelques mois, des supports aussi différents que le driver ODBC de 4D, les connexions SQL Pass-through (voir ci-dessous) ou la toute nouvelle librairie de connexion 4D for Flex ont pu voir le jour et reçoivent depuis lors de constantes améliorations. Ainsi tout en ayant mis en place un protocole SQL propriétaire, à l instar de ses concurrents, 4D a su le rendre ouvert et documenté. Dans cet esprit, 4D reste à l écoute pour toute sorte de collaboration visant à l implémentation de son protocole de communication entre son serveur SQL et d autres langages. Les prochaines versions de 4D offriront certainement d autres nouveautés dans ce domaine.

7 7 Chapitre 2 : Inventaire des solutions actuelles SQL Pass-through Le terme SQL Pass-through recouvre simplement la capacité qu a une base 4D d interroger une application tierce en langage SQL. La plupart des produits 4D ont cette faculté que ce soit pour des motifs de développement ou de déploiement (voir tableaux comparatifs sur le site 4D). Le code SQL s inscrit entre deux balises SQL Login et SQL Logout insérées dans une méthode 4D. Appliqué entre deux applications 4D, ce mode implique que l application recevant l appel contienne la fonction SQL Server activée. Depuis 4D 11.3, il n est plus nécessaire d installer un driver ODBC du côté de l application 4D appelante. La connexion devient très simple à mettre en œuvre et offre un rendement bien plus élevé qu avec ODBC. Au fond la logique correspond à celle de 4D Open for 4D, en établissant une connexion native privilégiée, à la différence près que cette fois le langage utilisé est le standard de référence. Le développeur 4D ne maîtrisant pas SQL n aura ainsi aucun mal à sous-traiter l écriture de ses requêtes complexes, mais en général, s agissant de remplacer 4D Open, celles-ci resteront pour la plupart très simples. De plus, les objets de l interface 4D facilitent l exploitation des résultats de la requête SQL dans l environnement 4D. Tout particulièrement, l objet listbox, qui se reformate automatiquement, en ajoutant, supprimant et redimensionnant les colonnes et les lignes nécessaires pour afficher les résultats, donne la mesure de la facilité de mise en œuvre de SQL Pass-through. Web Services avec SOAP L utilisation des Web Services entre deux applications 4D présente l énorme avantage de ne nécessiter aucune connaissance additionnelle concernant le protocole de transport des données ou la mise en œuvre d XML. Le développeur 4D conserve ainsi ses habitudes et ne manipule d un bout à l autre de la chaîne que des commandes 4D, certaines d ailleurs automatiquement écrites par l assistant de Web Services. Ainsi il peut se consacrer à la logique de service (le mot le plus important dans Web Services) qu il emploiera pour imaginer les requêtes et les réponses entre les deux applications. A sa disposition deux modes de communication : le mode simple RPC qui permet d obtenir rapidement une valeur, et le mode DOC qui permet d encapsuler toute une série de données variées. Dans les deux cas, depuis 4D v11.3, la communication entre les deux instances 4D peut tirer parti d une compression/décompression automatique (via un standard HTTP) qui diminue de façon très sensible les temps de réponse. SOAP étant un standard largement adopté dans l industrie, un service Web créé d abord pour 4D pourra ensuite être mis à disposition de toutes sortes de clients. Il est bien sûr aussi possible de consommer un service tiers. Attention cependant à bien surveiller la conformité à la norme qui n est pas toujours interprétée de la même manière, ce qui nécessite de bien tester les différents paramètres du Web Service, surtout s il a été généré dans un autre langage. XML sur HTTP Pour le dire simplement, faire de l XML sur HTTP consiste à recréer un Web Service personnalisé sans tout l enrobage de compatibilité universelle que contient le standard SOAP, donc de façon plus concise, précise et puissante. Grâce à la connaissance précise des objets à échanger, nul besoin de couvrir tous les cas de figure concernant tous les types d objets par exemple. Cependant, aucun assistant prêt-à-l emploi n existe dans ce cas précis. Ce sera au développeur de comprendre et implémenter les différentes étapes de la communication, depuis l interrogation du service, jusqu au transfert des données. Une bonne maîtrise du protocole HTTP et de la syntaxe XML sont donc requis. Mais le niveau de difficulté technique reste modéré. En récompense, le développeur 4D obtiendra un code totalement personnalisé, facile à optimiser grâce à ses retours d expérience, qui deviendra rapidement du code générique réutilisable.

8 8 Note sur TCP/IP De longue date, grâce au plug-in 4D Internet Commands, inclus dans tous les produits 4D, il est possible d implémenter des solutions de connectivité entre deux applications 4D via TCP/IP. Le principe consiste a construire un émetteur et un récepteur s échangeant des données à travers un port dédié, le cas échéant en mode binaire. Cette programmation de bas niveau n est pas couverte dans le présent livre blanc car sa mise en œuvre n est pas aussi aisée que les solutions présentées ci-dessus, plus conformes à la philosophie de 4D, car simples et rapides à implémenter tout en offrant des performances élevées. Les lecteurs intéressés par le TCP/IP peuvent se reporter aux différentes notes techniques sur le sujet dans la base de connaissances 4D.

9 9 Chapitre 3 : Quelques scénarios d utilisation Les trois solutions décrites ci-dessus sont équivalentes fonctionnellement dans le cadre d une mission d échange de données entre bases 4D. Chacun peut avoir ses préférences ou ses habitudes, mais le lecteur appréciera certainement d être guidé pour s orienter sur l une ou l autre de ces technologies en fonction de ses besoins et du contexte d utilisation. Synchronisation Réplication de base (maître/esclave) : il peut s agir d une réplication pour motifs de robustesse (mirroring), ou bien d une répartition des tâches d édition de données globales depuis un site unique vers différents sites de consultation ou d exploitation locaux. Objectif recherché : vitesse, fiabilité, facilité de maintenance. Réseau en étoile : plusieurs sites de même niveau doivent répliquer leurs données, de façon à obtenir le même jeu final (cas différent de l application distribuée ci-après). Des règles logiques de synchronisation doivent être établies, ainsi qu une définition des priorités par table ou par champ en cas de conflit logique. Objectif recherché : sécurité, gestion des erreurs performante. Préconisation : 1. SQL pass-through 2. XML sur HTTP 3. Web Service SOAP Interopérabilité Architecture provisoire, ou soumise à des changements fréquents. Nécessité de garantir une évolution de scalabilité, en passant de 4D à une autre application distante. Réusabilité du code dans de multiples configurations dans lesquelles 4D n est pas assuré d être toujours présent. Nécessité d utiliser un port standard. Couplage faible entre les différentes applications 4D. Objectifs : flexibilité, rapidité de mise en œuvre. Préconisation : 1. Web Service SOAP 2. SQL Pass-through 3. XML sur HTTP Applications distribuées Répartition des données sur plusieurs sites à consulter en temps réel. Objectifs : temps de réponse faible. Consolidation des données issues de divers sites, et regroupées au sein d une interface unique sur un site consommateur du service. Objectif : rapidité d affichage, flexibilité (capacité à faire évoluer la structure des écrans de consolidation très rapidement) Préconisation : 1. SQL Pass-through 2. Web Service SOAP 3. XML sur HTTP

10 10 Vous trouverez dans la base exemple jointe à ce livre blanc une illustration concrète de la mise en œuvre de chacune des trois solutions. Cette base de données simule le transfert de données d archives concernant le taux de change de diverses monnaies par rapport à l Euro, grâce à une interface très simple. Vous pouvez comparer la vitesse de transfert entre les différentes méthodes de connexion en fonction du volume de données échangées. Le code source pourra être réutilisé et modifié pour vos propres besoins. Prenez soin de lire attentivement les instructions d installation du fichier Lisez-moi fourni avec la base de démo. Consultez également le tableau comparatif et les annexes ci-dessous pour toutes vos questions techniques.

11 11 Tableau comparatif des technologies d échange de données incluses dans 4D SQL Pass-through SOAP XML/HTTP Code requis côté serveur Couplage fort à la BDD Protocole standard Port standard SSL Programmation Langage 4D Licence spécifique (1) (2) (3) Interopérabilité Native ou ODBC Appel de méthode Possible Requis Possible Version minimum 4D v11 SQL 4D D 2003 Possible entre versions différentes de 4D Mode connecté Compilé Gestion d'erreurs (v11.3+) Modélisation des données Via schéma Via schéma XML Interception des paquets Threads Préemptifs Coopératifs Coopératifs Assistant de génération de code Compression des paquets (v11.3+) Securité Schémas Droits d'accès aux méthodes Code ou Droits d'accès aux méthodes Type de paquet Texte + Binaire Texte Texte Données binaires Oui (BLOBs) Encodage base64 Encodage base D Server offre deux modes de connexion SQL : à la connexion ou illimité 2. Licence Web Services Server 3. Licence Web Server Voir descriptif complet des licences sur

12 12 Annexes : fiches techniques des différentes solutions

13 13 SQL pass-through Généralités sur SQL pass-through SQL pass-through permet d utiliser les commandes SQL pour interroger un serveur distant 4D v11 SQL Server. Alors que dans les versions précédentes, un pilote ODBC devait être installé pour permettre à deux applications 4D de communiquer entre elles, ce pilote n est plus nécessaire à partir de la version En plus d être plus simple, la connexion bénéficie d une rapidité d exécution accrue. Comment établir la connexion Pour se connecter au 4D Server distant on utilise la commande SQL LOGIN. Par la suite tous les ordres SQL EXECUTER seront redirigés sur le serveur 4D distant jusqu à ce qu un appel à SQL LOGOUT ferme la session. Exemple : SQL LOGIN ("4D:4D_Source_Donnees";"utilisateur";"motDePasse") Dans ce cas le premier paramètre pourra être : "4D:4D_Nom_Publication" ou "IP: " "4D_Nom_Publication" est le nom sous lequel est publié la base de données distante et " " est son adresse IP (Si la base 4D distante n utilise pas le port par défaut, le numéro de port doit être ajouté après l adresse IP sous la forme ":NumeroPort"). Quelques exemples : SQL LOGIN ("4D:4D_Nom_Publication";"utilisateur";"motDePasse") SQL LOGIN ("IP: ";"utilisateur";"motDePasse") SQL LOGIN ("IP: :19832";"utilisateur";"motDePasse") Deux options supplémentaires sont disponibles pour le premier paramètre : 1. La constante SQL_INTERNAL renvoie toutes les requêtes SQL suivantes sur le propre moteur de la base de données appelante (dans ce cas les deux paramètres utilisateur et motdepasse sont requis mais peuvent être laissés vides). 2. Une chaîne vide ("") ouvre un dialogue de connexion standard permettant de se connecter manuellement à la source de données. Si vous souhaitez inclure le code SQL entre deux balises Debut SQL et Fin SQL, vous devrez ajouter un quatrième paramètre * à la commande SQL LOGIN. SQL LOGIN ("IP: ";"utilisateur";"motDePasse";*) Debut SQL SELECT * FROM CD Fin SQL

14 14 Notes : Seules certaines licences dans la gamme de produits 4D ont la possibilité d établir une connexion directe avec une autre application 4D, ou de répondre à une requête en tant que serveur SQL. Consultez la table comparative des licences sur le site Web de 4D. Une seule connexion est autorisée par process. Si vous désirez établir plusieurs connexions simultanées, vous devez créer autant de process que nécessaire. Vous devez démarrer la fonction Serveur SQL du côté serveur. Vous pouvez le faire par la fenêtre d Administration de 4D Server, onglet Serveur SQL : "Démarrer le serveur SQL" ou bien dans les Préférences : "Préférences/SQL/Publication du serveur SQL/Lancer le serveur SQL au démarrage". Pour changer le nom de publication de la base, allez dans "Préférences/Client-Serveur/Réseau/Nom de publication:". Vous pouvez augmenter le niveau de sécurité en cochant l option "Activer SSL" dans la page "Préférences/SQL". N oubliez pas de copier les fichiers key.pem et cert.pem à l endroit suivant : MaBaseDeDonnees/Preferences/SQL/ ("MaBaseDeDonnees" représentant le dossier ou package de la base 4D). SQL pass-through peut aussi servir à appeler des méthodes ou des fonctions : Exemple : TABLEAU TEXTE(monTableau;0) SQL LOGIN("IP: ";"utilisateur";"motDePasse";*) Si (OK=1) Debut SQL SELECT {FN getinfo(id_cd) AS VARCHAR} FROM CD INTO :montableau; Fin SQL Fin de si SQL LOGOUT La méthode getinfo est appelée pour chaque enregistrement présent dans la sélection construite par la requête SELECT. Le tableau texte montableau est rempli par des chaînes concaténées à partir d informations extraites de l enregistrement CD. Notez comment une variable 4D est référencée dans du code SQL grâce à la syntaxe ':' (ou aussi <<montableau>>). Voici le code de la méthode getinfo (dont l option "Disponible via SQL" a été activée dans la fenêtre de propriétés de la méthode) : C_ENTIER LONG($1) CHERCHER([CD];[CD]ID_CD=$1) $0:=[CD]Titre+" "+[CD]Interprete+" "+[CD]Description Veuillez noter qu il n existe aucun contexte ni aucun enregistrement courant dans la méthode appelée. Si vous souhaitez gérer "l enregistrement courant correspondant au contexte de la requête SQL du côté de 4D, il vous appartient de charger celui-ci en passant son numéro d identifiant comme paramètre à la méthode appelée comme dans l exemple ci-dessus. Si vous souhaitez n exécuter la méthode qu une fois, il vous suffit d utiliser la clause LIMIT dans la requête : Debut SQL SELECT {FN getinfo(id_cd) AS VARCHAR} FROM CD LIMIT 1 INTO :montableau; Fin SQL

15 15 SQL pass-through et la sécurité SQL pass-through est compatible avec SSL. La communication via SQL pass-through peut donc être protégée. Côté serveur, la méthode base "Sur authentification SQL, si elle a été définie, est appelée lors de l ouverture de la connexion. De plus, les schémas, fonctionnalité apparue en version 11.3, autorisent le contrôle d accès de façon standard à un jeu de tables. Une table ne peut être assignée qu à un (et un seul) schéma. Cette opération est réalisée en mode Développement ou par une commande SQL. Les utilisateurs et les groupes 4D reçoivent des privilèges d accès à chaque schéma (lecture-seule, lecture-écriture, ou tous droits). Ces droits sont attribués ou modifiés par des commandes SQL. Enfin seules les méthodes 4D dont la propriété "Disponible via SQL a été cochée peuvent être invoquées. Bénéfices de SQL pass-through SQL pass-through est rapide. SQL pass-through se connecte directement en mode multithread préemptif au moteur de base de données. SQL Pass-through est une solution connectée/avec maintien de session SQL pass-through accepte l utilisation de transactions dans la base de données SQL pass-through supporte les types 4D natifs (pas de transtypage). Un mode sécurisé est disponible pour les connexions SQL pass-through (grâce à l usage de certificats SSL). Inconvénients de SQL pass-through SQL pass-through est une solution puissante, mais elle nécessite un effort initial pour maîtriser le langage SQL. Tout comme avec ODBC, le "client" doit savoir à priori comment accéder à la structure interne de la base de données du "serveur". Ceci implique que vous devez exposer votre modèle de données. Il n y a pas de possibilité d abstraction des données. Un couplage fort est imposé. La version 11.3 améliore cet état de fait en proposant l utilisation de schémas, qui permettent de masquer certaines parties du modèle en fonction des droits de l utilisateur. SQL pass-through n utilise pas de port standard.

16 16 Principales caractéristiques de SQL pass-through Critère Type de protocole Mode Securité (transport, authentification) Securité (autorisations) Possibilité de se connecter à 4D monoposte Compatible avec autres/anciennes versions de 4D Description Protocole orienté données Maintien de session Oui (optionnel avec SSL) Oui (privilèges d accès contrôlés par schémas) Oui (usage restreint selon la licence) Non Protocole basé sur SQL Pass-trough

17 17 SOAP/Web Services Généralités sur les Web Services Acronyme Nom complet Description Lien SOAP Simple Object Access Protocol (1 ) Protocole d échange d informations à base de messages WSDL Web Services Description Language Langage de description de Web services UDDI Universal Description, Discovery, and Integration Spécifications pour les services d annuaires (comme les pages jaunes ) ou les Web services Dans le cadre du présent document, nous resterons centrés sur SOAP, qui peut être utilisé sans les deux autres technologies, même si WSDL est le plus souvent associé à la fonction de découverte. SOAP est un protocole basé sur XML, qui s utilise généralement sur HTTP ou HTTPS. Dans l implémentation au sein de 4D, SOAP est exclusivement utilisable sur HTTP et HTTPS. L objet de ce protocole est d échanger des messages de données structurées tout en décrivant la propre structure des messages et des erreurs SOAP. La structure basique d un message SOAP est l enveloppe : A l intérieur de l enveloppe, un élément "Corps" contient l information décrivant la procédure distante qui est invoquée ainsi que les paramètres qui seront envoyés ou reçus. SOAP propose des types de données standardisés. Les tableaux de données sont supportés. Une requête SOAP est envoyée dans une requête http POST. Il existe deux types de messages SOAP : RPC et DOC. Le style RPC est le plus simple à implémenter entre deux applications 4D car il est basé sur des paramètres typés. A l inverse, le style DOC est utilisé pour l échange de documents XML structurés. Cette distinction n affecte absolument pas le type de données échangées mais simplement la façon dont elles sont encapsulées dans le message. 1 A l origine SOAP signifiait "Simple Object Access Protocol", puis il a été traduit par "Service Oriented Architecture Protocol", mais ces acronymes ont été abandonnés depuis la version 1.2 de SOAP car ils étaient considérés comme source de confusion. Depuis la version 1.2, SOAP n est plus un acronyme.

18 18 Description d une séquence requête/réponse SOAP Il est important de comprendre ce qui se produit lorsqu est appelée la commande APPELER WEB SERVICE. Voici la description de ce processus :

19 19 Contenu d un message SOAP La taille de l enveloppe est fixe mais celle du corps dépend grandement de la complexité (et de la quantité) des données transférées. L en-tête XML (dont la fonction est de formater les données du corps d une façon standard) peut, dans certains cas, générer un fort ratio signal/bruit (par comparaison avec un simple protocole brut ou binaire). Ceci est particulièrement vrai par exemple pour transférer des tableaux. Par exemple, un tableau d entiers de 66 lignes sera transféré comme suit : <SOAP-ENC:Array id="ref-1" SOAP-ENC:arrayType="xsd:int[66]"> <item1>1</item1> <item2>2</item2>... <item65>65</item65> <item66>66</item66> </SOAP-ENC:Array> Heureusement, le XML se compresse très facilement (voir ci-après). La compression permet d accélérer le temps de transfert, mais pas d améliorer le temps de traitement de la génération ou du parsing du corps du message. Optimisation de SOAP entre deux applications 4D 4D v11.3 offre une nouvelle fonctionnalité qui peut être activée pour comprimer les données en utilisant l algorithme standard Deflate. Cette option permet d accélérer le transfert d informations SOAP entre deux applications 4D. Elle s active à partir du client SOAP, grâce à la commande FIXER OPTION WEB SERVICE : FIXER OPTION WEB SERVICE (Web Service Compression HTTP; Web Service Compression Deflate) APPELER WEB SERVICE (...) Cette option doit être activée pour chaque utilisation de la commande APPELER WEB SERVICE (et avant ladite commande). Elle est remise à la valeur par défaut (pas de compression) après chaque appel. Ceci permet d activer l option selon les besoins précis. Par exemple, elle sera activée pour un service dont la bande passante et limitée (Internet ou WAN) et désactivée si la bande passante n est pas limitée (réseau de type LAN). Par défaut, aucune compression HTTP n est effectuée. La compression se sera possible que si les deux applications 4D sont compatibles avec cette fonctionnalité (c est-à-dire égale ou supérieure à 11.3) La compression peut être optimisée pour vos besoins en utilisant deux nouveaux paramètres de la base de données (depuis 4D v 11.3). Ces paramètres peuvent s ajuster sur le serveur et/ou le client (avec des valeurs différentes). Ils s appliquent à toutes les requêtes et les réponses SOAP. Le premier paramètre est le taux de compression : -1 : automatique (meilleur compromis) 1 : plus rapide (moins exigeant en CPU/plus rapide, moins de compression/volume de données plus grand) 9 : plus compressé (plus exigeant en CPU/moins rapide, plus de compression/volume de données plus faible) Le niveau de compression par défaut est 1 (plus rapide) FIXER PARAMETRE BASE (Niveau de compression HTTP; -1) FIXER PARAMETRE BASE (Niveau de compression HTTP; 1) FIXER PARAMETRE BASE (Niveau de compression HTTP; 5) FIXER PARAMETRE BASE (Niveau de compression HTTP; 9)

20 20 Le deuxième nouveau paramètre est le seuil de compression. Il permet d éviter de comprimer de trop petits paquets. La notion de «petitesse» est définie grâce au seuil. En-dessous du seuil, le paquet ne sera pas compressé. Au-dessus du seuil, les paquets seront compressés. Le seuil par défaut est de 1024 octets. FIXER PARAMETRE BASE (Seuil de compression HTTP; 2048) Toujours en ce qui concerne l optimisation, SOAP, travaillant sur la couche http, bénéficie de toutes les améliorations propres au serveur HTTP interne. C est le cas par exemple pour la fonctionnalité Keep-alive comme nous le verrons plus bas. SOAP et la sécurité L authentification peut être contrôlée par la méthode de base "Sur authentification Web". Depuis 4D v11.2 le mode "digest" est admis pour l authentification SOAP. Dans les versions précédentes, seul le mode "basique" était supporté. Le mode Digest offre un plus haut niveau de sécurité étant donné que l authentification est réalisée par un procédé à sens unique appelé "hachage", qui rend le contenu impossible à déchiffrer. Cependant l authentification Digest est une fonction HTTP 1.1 et n est pas compatible avec tous les navigateurs. Depuis 4D v11.3 il est possible d effectuer une authentification SOAP sur un Web Service situé derrière un proxy. Ceci illustre la volonté de 4D de continuer à améliorer l implémentation de SOAP dans ses versions successives. SOAP peut être utilisé sur HTTPS. La communication SOAP est dans ce cas totalement protégée. L authentification peut être vérifiée avec SSL. Sur le serveur, dans la méthode de base "Sur authentification Web", la fonction Connexion Web securisee peut servir à détecter si la connexion a été effectuée en SSL. L autorisation (le contrôle des accès à tels objets ou telles données pour un utilisateur donné) doit être implémentée dans la logique métier du serveur. Ceci est acceptable étant donné que la solution est "orientée service" de toutes façons. L accès aux méthodes, via SOAP, est contrôlé par l option "Offerte comme Web Service" (dans la fenêtre "Propriétés de la méthode"). La publication automatique de la WSDL peut également être activée/désactivée dans le même dialogue. Bénéfices de SOAP SOAP est un standard de l industrie ouvert. Il est possible (et sûr) d utiliser SOAP pour échanger des données entre différentes versions de 4D. SOAP est un protocole intelligible et intuitif (basé sur XML) et donc facile à déboguer. Des outils tels que des sniffers HTTP peuvent vous aider à tester vos services. SOAP est très simple à mettre en œuvre (grâce à l "Assistant de Web Services" qui génère automatiquement le code requis pour appeler le Web Service). Il ne faut que quelques minutes pour mettre en place un Web Service parfaitement fonctionnel entre deux applications 4D, sans aucun besoin de gérer les détails internes du protocole.