ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D

Transcription

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
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.
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
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
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.
2.
3.
SQL pass-through
XML sur HTTP
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.
2.
3.
Web Service SOAP
SQL Pass-through
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.
2.
3.
SQL Pass-through
Web Service SOAP
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
√
√
Protocole standard
√
√
Port standard
√
√
√
√
√
√
Code requis côté serveur
Couplage fort à la BDD
√
√
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é
√
√
√
√
√
Modélisation des
données
Via schéma
Via schéma XML
Interception des paquets
√
√
Coopératifs
Coopératifs
Compilé
Gestion d'erreurs
Threads
√ (v11.3+)
Préemptifs
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.
2.
3.
4D Server offre deux modes de connexion SQL : à la connexion ou illimité
Licence Web Services Server
Licence Web Server
Voir descriptif complet des licences sur 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.
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;
HTTP;
HTTP;
HTTP;
-1)
1)
5)
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
Critère
Description
Type de protocole
Protocole orienté service
Mode
Pas de maintien de session
Oui (optionnel avec SSL/HTTPS)
Non (doit être implémentée et gérée au niveau de la
méthode générant la réponse)
Oui
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.islanddata.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 !
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
Critère
Description
Type de protocole
Protocole orienté service
Mode
Pas de maintien de session
Oui (optionnel avec SSL/HTTPS)
Non (doit être implémentée et gérée au niveau du
protocole utilisé sur HTTP)
Oui
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/
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
4D SAS
4D, Inc
4D Deutschland GmbH
4D Japan
France
USA & Canada
Germany & Austria
Japan
+33 1 40 87 92 00
+1 800 785 3303
+49 8165 95 19 0
+81 3 5433 3461
[email protected]
[email protected]
[email protected]
[email protected]
4D UK Ltd
4D Hispano
4D Sweden AB
4D Australasia
United Kingdom
Sweden & Denmark
Australia & New Zealand
+44 1625 536 178
Spain, Portugal & Latin
America
+46 8 750 63 00
+61 2 9499 9544
[email protected]
+34 91 414 92 90
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
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.

ECHANGE DE DONNÉES ENTRE APPLICATIONS 4D

Transcription

Documents pareils

[Jérémy ROCH] Curriculum Vitæ

File - Ronan Le Prioux Administrateur système, réseaux

Télécharger mon CV

Tom Germain

Numéros de ports de SQL Server - Vulgarisation

cv-detaille-pgauwin- 29mars2010 - Patrick GAUWIN

ROUBEYRIE Olivier

Mon CV au format PDF

Wiem LAHBIB . Née: 06-01-1988 Nationalité: Tunisienne