ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D · Echange de données entre applications 4D 2 ... effet, au sein du réseau local, 4D Server (en tant que serveur applicatif et de données)

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 1.0 7 avril 2009

4D v11 SQL Product Line

Echange de données entre applications 4D

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

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

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

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 2004. 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 2004. 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

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.

http://www.4d.fr/products/4dweb20pack-FL.html�


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.

http://www.4d.fr/products/Dev-comparative.html�

http://www.4d.fr/products/Dep-comparative.html�


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.

http://kb.4d.com/�


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

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

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 2003 4D 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 base64

1. 4D 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 http://www.4d.fr/products/Dep-comparative.html

http://www.4d.fr/products/Dep-comparative.html�


12

Annexes : fiches techniques des différentes solutions


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 11.3. 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:192.168.0.10" "4D_Nom_Publication" est le nom sous lequel est publié la base de données distante et "192.168.0.10" 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:192.168.0.10";"utilisateur";"motDePasse") SQL LOGIN ("IP:192.168.0.10: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:192.168.0.10";"utilisateur";"motDePasse";*) Debut SQL

SELECT * FROM CD Fin SQL


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:192.168.0.10";"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

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

Principales caractéristiques de SQL pass-through

Critère Description

Type de protocole Protocole orienté données

Mode Maintien de session

Securité (transport, authentification) Oui (optionnel avec SSL)

Securité (autorisations) Oui (privilèges d’accès contrôlés par schémas)

Possibilité de se connecter à 4D monoposte Oui (usage restreint selon la licence)

Compatible avec autres/anciennes versions de 4D Non

Protocole basé sur SQL Pass-trough


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 )

http://www.w3.org/TR/soap/

WSDL Web Services Description Language

Langage de description de Web services

http://www.w3.org/TR/wsdl

UDDI Universal Description, Discovery, and Integration

Spécifications pour les services d’annuaires (comme les “pages jaunes”) ou les Web services

http://uddi.xml.org/

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.

http://www.w3.org/TR/soap/�

http://www.w3.org/TR/wsdl�


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

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

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.


21

Inconvénients de SOAP

• Il peut arriver que SOAP soit lent (dans le transfert de l’information de l’enveloppe + le temps nécessaire à parser et analyser le XML). SOAP n’est pas optimisé pour la vitesse.

• SOAP utilise le serveur HTTP interne de 4D, qui fonctionne en mode mono-thread/coopératif Principales caractéristiques de SOAP


Type de protocole Protocole orienté service

Mode Pas de maintien de session

Securité (transport, authentification) Oui (optionnel avec SSL/HTTPS)

Securité (autorisations) Non (doit être implémentée et gérée au niveau de la méthode générant la réponse)

Possibilité de se connecter à 4D monoposte Oui

Compatible avec autres/anciennes versions de 4D Oui

Protocole basé sur SOAP


22

XML sur HTTP (avec 4D Web Server) Cette approche consiste à envoyer des paquets XML par HTTP. La structure des paquets XML, la façon dont ils sont remplis, et le mécanisme de gestion des erreurs, sont complètement laissés sous le contrôle et la responsabilité du développeur. Cette méthode est applicable si la même entité contrôle les deux extrémités du service : le client et le serveur. Si l’interopérabilité vous est nécessaire, il vaut mieux opter pour des Web services SOAP. Généralités sur le protocole HTTP

HTTP est un protocole de communication très populaire. C’est celui qui est le plus répandu sur Internet. Il a été originellement prévu pour diffuser des pages HTML. Combiné au langage HTML pour afficher du contenu sur un client (un navigateur Web), HTTP a été le vecteur du succès de la révolution Internet. HTTP est un protocole extrêmement bien conçu et par conséquent très flexible. Il peut être utilisé pour une grande variété d’applications (serveurs de fichiers comme WebDAV, applications Web 2.0 / Ajax avec XmlHttpRequest, flux multimédia, etc…) HTTP est un protocole de la couche application basé sur TCP. Il propose un mécanisme de requête/réponse standard entre un client (envoyant la requête) et un serveur (répondant à la requête par une réponse). HTTP structure le message de requête ou de réponse en deux parties : l’en-tête et le corps. L’en-tête contient les méta-données qui concernent le corps. Le corps contient les données (la charge utile). La section du corps peut-être identifiée en fonction du type de contenu MIME. HTTP fournit un jeu standard d’actions et méthodes à associer à la requête. La plus populaire est la méthode GET suivie de près par la méthode POST HTTP propose des codes d’états standardisés pour la gestion des erreurs. (Par exemple l’erreur 404, qui signifie "ressource non trouvée” est une erreur que la plupart des internautes ont déjà rencontrée). Optimisation de la communication HTTP avec "Keep-Alive"

Quand plusieurs cycles de requête/réponse sont effectués entre un même client et le serveur dans un délai court, il n’est pas efficace d’ouvrir et fermer en permanence la connexion TCP entre chaque cycle requête / réponse. En HTTP 1.0, "keep alive" était une option. Elle s’établissait (par requête) par le client, dans l’en-tête :

Connection: Keep-Alive En recevant ce paramètre dans l’en-tête HTTP, le serveur (à condition qu’il supporte cette fonction) devait répondre avec le même paramètre dans l’en-tête :

Connection: Keep-Alive Le serveur ne coupait pas la connexion après l’envoi de la réponse. La requête suivante du client était ainsi reçue dans la même connexion. En d’autres termes, avec HTTP 1.0, keep-alive n’était pas le mode par défaut, mais une option. En HTTP 1.1, keep-alive est implicite (activé par défaut). Par conséquent, dans une requête HTTP 1.1, le paramètre "Connection : keep alive" est inutile et ignoré. Cependant il est possible de désactiver le mode par défaut en spécifiant, dans la requête HTTP, le paramètre suivant :

Connection: close


23

Le serveur HTTP de 4D peut être configuré pour fonctionner en mode "keep-alive" (via le dialogue de préférences “Web /Options”). HTTP et la sécurité

L’authentification HTTP se contrôle dans la méthode base "Sur authentification web". Les modes "basique” et "digest" sont acceptés. Le mode "digest" est préférable car en mode basique, les mots de passe ne sont codés qu’en base64 au moment de la transmission et peuvent facilement être dérobés. HTTP peut également fonctionner avec SSL (HTTPS). La communication HTTP est ainsi protégée. L’authentification peut aussi être vérifiée avec SSL. Côté serveur, dans la méthode de base "Sur authentification web", la commande Connexion web securisee permet de détecter si la connexion s’est faite avec SSL. Les autorisations (c’est-à-dire le contrôle des accès aux objets et aux données pour chaque utilisateur) doivent être implémentées au niveau de la logique métier. Ceci est acceptable étant donné qu’il s’agit d’une solution "orientée service" dans tous les cas. L’accès aux méthodes, via HTTP, est contrôlé grâce à l’option "Disponible via 4D ACTION, 4DMETHOD et 4DSCRIPT" dans le dialogue "Propriétés de la méthode". Mise en œuvre d’un service XML sur http

Côté serveur, les requêtes entrantes seront traitées par le serveur Web. Une fois celui-ci correctement paramétré, vous avez le choix entre baser votre service sur des appels directs à vos méthodes 4D rendues publiques, ou effectuer une gestion manuelle grâce à la méthode de base “Sur connexion Web“. Le principe est le suivant : si la méthode existe et a été publiée pour HTTP (option “Disponible via 4DACTION, 4DMETHOD et 4DSCRIPT“ cochée dans les propriétés de la méthode), elle pourra être appelée directement par n’importe quel client HTTP. Si le client appelle une méthode qui n’existe pas ou qui n’a pas été publiée pour HTTP, alors vous pouvez intercepter la requête dans la méthode de base “Sur connexion web“ et exécuter votre propre code. Dans les deux cas vous devez d’abord analyser le flux de données entrantes. Si la méthode GET est utilisée, les paramètres sont envoyés dans l’URL en format URL-encoded. Il est alors possible de les récupérer avec la commande LIRE VARIABLES FORMULAIRE WEB (tabNoms; tabValeurs) Si la méthode POST est utilisée, les paramètres sont envoyés dans le corps de la requête, également en format URL-encoded, ou sous forme d’une structure XML. Dans ce cas vous devez utiliser LIRE CORPS HTTP (corps) puis analyser le corps grâce à la commande DOM Analyser variable XML. Une fois vos process métier achevés, vous renvoyez le résultat grâce à ENVOYER BLOB HTML($vx_blobXml;"application/xml") où $vx_blobXml est une variable BLOB contenant une structure XML. Si vous rencontrez des difficultés à appréhender les détails techniques ci-dessus, les livres de David Adams, The 4D Web Companion et The 4D Web Services Companion vous seront d’une grande aide (http://www.island-data.com/). Côté client, si vous pouvez vous limiter à l’emploi de la méthode GET, il vous suffit simplement d’utiliser la commande DOM Analyser source XML comme dans l’exemple suivant :

$xml_Struct_Ref:= DOM Analyser source XML ("http://host/myservice/ /currencyRateGet?cur=GBP&startDate=20090313&endDate=20090329")

Grâce à son client HTTP intégré, 4D réalise pour vous tout le travail technique et vous obtenez simplement dans la variable $xml_Struct_Ref la référence d’un arbre DOM contenant les données demandées !

http://www.island-data.com/�



24

Par contre, si vous souhaitez utiliser une requête POST, les choses deviennent plus complexes et vous devez utiliser 4D Internet Commands. Un exemple complet est fourni dans la base de démonstration qui accompagne le présent document. Bénéfices de XML sur HTTP

• 4D contient un serveur HTTP intégré, qui offre tous les avantages d’un protocole bien conçu et d’une implémentation parfaitement testée.

• HTTP est généralement laissé ouvert sur les firewalls (ou en tout cas son ouverture peut-être facilement négociée car il s’agit d’un “standard“ très connu)

• HTTP est également compatible avec les proxies • Il existe une multitude d’outils pour analyser et déboguer le trafic HTTP. • HTTP propose un mode sécurisé standardisé (HTTPS) qui est également supporté par 4D. • Un aiguillage des requêtes est possible grâce à la méthode de base “Sur connexion Web“. Ceci permet la

publication indirecte de noms de méthodes sur le réseau • Les commandes XML de 4D permettent d’analyser et construire facilement des structures XML. Inconvénients de XML sur HTTP

• HTTP est un protocole dépourvu de maintien de session, le concept de session n’étant d’ailleurs pas signifiant ici.

• Le serveur HTTP intégré dans 4D fonctionne en mode mono-thread/coopératif.

• Cette solution requiert une plus longue phase de conception et de programmation ainsi que des connaissances techniques spécifiques.


25

Principales caractéristiques de XML sur HTTP


Type de protocole Protocole orienté service

Mode Pas de maintien de session

Securité (transport, authentification) Oui (optionnel avec SSL/HTTPS)

Securité (autorisations) Non (doit être implémentée et gérée au niveau du protocole utilisé sur HTTP)

Possibilité de se connecter à 4D monoposte Oui

Compatible avec autres/anciennes versions de 4D Oui

Protocole basé sur HTTP


26

Bibliographie 4D v11 SQL Pass-Through sans ODBC: http://kb.4d.com/search/assetid=51682 Référence 4D v11 SQL: http://www.4d.fr/support/docs/4thdimensionmanuals.html Manuels et addenda 4D v11SQL : http://www.4d.fr/support/docs/4thdimensionmanuals.html Livres de David Adams : http://www.island-data.com/

http://kb.4d.com/search/assetid=51682�

http://www.4d.fr/support/docs/4thdimensionmanuals.html�

http://www.4d.fr/support/docs/4thdimensionmanuals.html�


4D SAS Siège mondial

60, rue d’Alsace - 92110 Clichy - France Tel: +33 1 40 87 92 84 - Fax : +33 1 40 87 92 01

[email protected] - www.4D.com

Copyright 4D SAS 2009 tous droits réservés. 4D et les logos associés sont des marques enregistrées au nom de 4D SAS.

Toutes les autres marques et tous les noms de produits cités sont des marques déposées et/ou enregistrées par leurs propriétaires respectifs.

4D SAS

France

+33 1 40 87 92 00

[email protected]

4D, Inc

USA & Canada

+1 800 785 3303

[email protected]

4D Deutschland GmbH

Germany & Austria

+49 8165 95 19 0

[email protected]

4D Japan

Japan

+81 3 5433 3461

[email protected]

4D UK Ltd

United Kingdom

+44 1625 536 178

4D Hispano

Spain, Portugal & Latin America

+34 91 414 92 90 [email protected] [email protected]

[email protected]

[email protected]

4D Sweden AB

Sweden & Denmark

+46 8 750 63 00

[email protected]

4D Australasia

Australia & New Zealand

+61 2 9499 9544

[email protected]

mailto:[email protected]�

http://www.4d.com/�

mailto::[email protected]�










Documents

ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D · Echange de données entre applications 4D 2 ... effet, au sein du réseau local, 4D Server (en tant que serveur applicatif et de données)