Discussion :

[darkendorf]

Bonjour,

Je tente de développer un web service en delphi (avec Delphi 2007) : je génère une dll que je met dans un répertoire virtuel de IIS 5, ma DLL est configuré dans les Filtres ISAPI de IIS. Tests sous XP SP3 actuellement, pas de problèmes, mon service répond bien, mon fichier .ini est bien chargé, jusque là je m'en suis plutôt bien sortit ^^

par contre, je dois faire accès à des tables paradox, et là il y a comme un os... mon objet session refuse de pointer ver le répertoire NetFileDir (et oui je ne suis pas le seul avec mon webservice à accéder à ces tables...)

Si je supprime mon objet TSession pour utiliser les paramètres par défaut, j'obtiens cette erreur logique :
C:\WINDOWS\SYSTEM32\PDOXUSRS.LCK
Permission refusée.
Impossible d'accéder au répertoire.

Donc quand je configure correctement mon objet session, il pointe vers un dossier de la machine, mais il semblerait que IIS me l'interdise...

Y a-t-il des droits particuliers à configurer sous IIS ou des paramètres spécifiques dans Delphi ?

[Franck SORIANO]

Déjà il va falloir faire attention à plusieurs choses.

Avec un filtre ISAPI, c'est IIS qui exécute le code, c'est à dire un service windows et non pas l'utilisateur connecté.
Donc si ton appli doit écrire dans System32, il faut que le compte Windows utilisé pour exécuter le service IIS (ou le pool d'application selon ton paramétrage) possède les droits suffisant pour accéder à System32.
Par défaut, IIS doit être configuré avec un compte assez restreint (question de sécurité).

Deuxièmement IIS en ISAPI est multi-threadée. Et le BDE n'est pas thread-safe ! Avec le BDE, il faut que chaque thread travaillent avec une session différente !
Concrêtement, lors de chaque appel à ton Webservice, il faut bien te dire que c'est peut-être un thread différent qui exécute ta requête. Et que ton WebService peut être appelé simultanément par deux threads différents.
Autrement dit, pour le BDE, il vaut mieux que tu ouvres une session différente par invocation du Webservice.

[darkendorf]

Wow merci de ta réponse !!

effectivement, j'avais trouvé l'option multi threadé intéressante, mais quand je charge en même temps deux appli, j'ai deux blocages BDE...

j'ai résolu mon problème de session, en le mettant dans un dossier ou IIS user a des droits.

Donc en gros, il vaudrait mieux que je ne fasse pas une dll mais un exécutable indépendant ? ou il existe un moyen de laisser ma dll dans IIS avec une configuration particulière ? ou peut-être remplacer ou enlever CoInitFlags := COINIT_MULTITHREADED; dans le source de mon projet ?

j'avoue que je touche à quelque chose qui m'est obscur, et j'avance à tatons ^^

[darkendorf]

[edit : ménage]

J'allais dire une c...

Bref il y a un concept dans le web service que je ne comprend pas... j'ai un web service, qui contient des objets permettant de se connecter à une base, executer des requêtes (...) dans un data module.

Est-ce que chaque client instancie le service intégralement ? ou est-ce que, par exemple, le WebModuleCreate n'est lancé que par le premier utilisateur et c'est l'interface de cette instance du service qui est appelée par tous les clients ? parce que dans ce dernier cas, dès qu'une instruction utilise un objet, une instruction d'un autre utilisateur peut être en train de l'utiliser...

Si la solution et d'instancier le web service intégralement pour chaque client et que ça peut être géré de manière tranparente pas IIS, ça me va, il ne me reste qu'à gérer la session bde dans un répertoire différent pour chaque utilisteur ( c'est toujours moins lourd que de configurer un web service par client potentiel !!!!!!!!! ).

help inside needed ^^

[Franck SORIANO]

Bref il y a un concept dans le web service que je ne comprend pas...

Effectivement. Un WebService est avant tout une application Serveur qui dialogue avec les clients en mode Web (echange HTTP via SOAP ou REST).

Le service est instancié/démarré lorsque IIS charge la DLL. C'est tout l'intérêt de l'ISAPI, le serveur est chargé une fois, reste en mémoire, et est interrogé en multi-threading par différents clients.
La question est de savoir quand est-ce que tu instancies ton datamodule. Si c'est au démarrage de l'application, via une variable globale, il n'y a qu'un seul datamodule partagé entre tous les clients.
Si c'est au début du traitement de la méthode appellée par le client, dans une variable locale à cette dernière, tu as une instance par client (et même par invocation).

Si la solution et d'instancier le web service intégralement pour chaque client et que ça peut être géré de manière tranparente pas IIS, ça me va, il ne me reste qu'à gérer la session bde dans un répertoire différent pour chaque utilisteur ( c'est toujours moins lourd que de configurer un web service par client potentiel !!!!!!!!! ).

Si tu veux que ton web service soit lancé à chaque appel client, fait une application CGI au lieu de l'ISAPI.
Ca veut dire qu'à chaque appel, IIS lancera une nouvelle instance de l'exe qui sera détruite à la fin de la requête du client. Dans ce mode, il n'est plus question de multi-threading. Une requête = Une instance de l'application CGI.
C'est beaucoup plus simple à coder. Par contre c'est aussi beaucoup moins performant. Surtout si tu as un temps de connexion du BDE important.

[ShaiLeTroll]

En Delphi 2007, tu as DevExpress avec les drivers MySQL fourni avec non ?
Tu devrais plutôt investir dans une technologique plus robuste que Paradox (obselète depuis Delphi 5 ~ 2000) , mieux vaudrait du BlackFish, InterBase ou FireBird, cela reste très proche de Borland\CodeGear, et surtout c'est maintenu !

DevExpress est pénible pour une utilisation avec des grilles, mais dans un WS, tu n'as pas besoin de curseur bi-directionnel, c'est probablement la couche d'accès aux données la plus rapide avec celle de CoreLab\Devart ... couplé à MySQL par exemple

Pas de question à se poser sur le multi-thread (du moins pas trop) et pas de
problème de droits, la DLL WS et le process DB sont indépendants !

[darkendorf]

Oui la connexion à bde n'est pas ce que l'on peut appeler instantanée... j'instancie manuellement mon unité UDataModule dans l'événement OnCreate du WebModule : DMmonService := TDMmonService.Create(Self);
Et dans le OnCreate du DM je paramètre mes objets bde (répertoire de démarrage - privateDir -, répertoire de partage de la connexion bde - NetFileDir - ...).

Si c'est au début du traitement de la méthode appelée par le client, dans une variable locale à cette dernière, tu as une instance par client (et même par invocation).

c'est ce qu'il me faut ^^

donc il me suffirait d'instancier mon DataModule dans l'implémentation de l'interface...

par contre, les fichiers fichiers bde LCK doivent du coup se trouver dans un répertoire différent à chaque fois, sinon c'est bde qui va refuser de s'ouvrir quand une connexion est en cours...

suis-je sur la bonne voie ?

PS : une requête n'a besoin d'être effectuée qu'au chargement de la DLL, je peux donc imaginer enregistrer son résultat dans une variable de mon WM pour qu'il la partage avec les autres instances, c'est bien ce qu'il faut comprendre ?

[darkendorf]

Merci Shai !!

je travail sur de l'existant, en évolution, donc mon Dm doit se connecter à la fois à du BDE et à du FireBird, et effectivement la facilité d'utilisation et la rapidité d'exécution sont incomparables ^^

la moitié de la structure des données et transféré à ce jour sur FB et chez nos clients, la base FB fait entre 300 et 900 Mo avec une efficacité égale ! un bonheur dont j'aimerais jouir entièrement... mais le programme existant fait quelques centaines de milliers de lignes avec quelques 500 fenêtres et l'implémentation de BDE et très... profonde.

[ShaiLeTroll]

Sinon, j'ai déjà utilisé Paradox en multi-thread dans un exe normal, je n'ai jamais eu de soucis, bon en général, les threads ne se marchaient pas sur les pieds, l'un faisait insert et update, un autre update, et le dernier update puis delete ... le tout dans un processus bien défini (lié à une machine)

Selon mes tests, faut éviter que plusieurs thread puissent modifier en même temps un même enregistrement, la ça fout la merde !

avec GetCurrentThreadId tu peux constituer un tableau de TDataModule, un par thread, c'est une autre technique que j'ai utilisé pour lancer le même activeX dans une application avec plusieurs pour avoir des données partagées entre les threads et d'autre bien isolé, bon je parle de cela en Delphi3 depuis avec ThreadingModel, on peut s'en sortir plus simplement

Je n'ai jamais eu besoin de créer plusieurs objets sessions !

[darkendorf]

avec GetCurrentThreadId tu peux constituer un tableau de TDataModule, un par thread,

... se concentrer... donc je continue d'instancier dans mon WebModule, mais en enregistrant l'instance dans un tableau en fonction du thread Id ? mais BDE va refuser d'utiliser les même paramètres dans l'objet Session... il va me falloir de toutes manières un répertoire différent par instance...

[ShaiLeTroll]

Tu pourrais avec ta DLL, en créant un Thread supplémentaire (appelon le Perpetuel), au démarrage de la DLL,

à chaque appel de ta DLL par ISAPI, tu envoie un PostThreadMessage à ton Thread Perpetuel (utilise WParam pour un pointeur sur un record ou un objet, et LParam pour le Handle du Thread ISAPI) puis avec une simple boucle sur WaitMessage et GetMessage tu attends que l'item soit traités

Pendant ce temps, ton Thread Perpetuel boucle que WaitMessage, dès qu'il en reçoit un, tu appele GetMessage, tu traite le contenu de WParam et tu renvoie un PostThreadMessage au Thread ISAPI identifié LPARAM ... ainsi un seul thread (Perpetuel), une seule file d'attente, le BDE sera tranquille dans un thread, une seule session, un seul .LCK, ...

Pour Thread Perpetuel, tu peux utiliser un ThreadList ça sera encore plus pratique que WaitMessage (et surtout plus de confiance pour l'accumulation de traitement en attente), pour le retour PostThreadMessage fait bien son office

[darkendorf]

Encore merci pour ton intérêt

houlà les messages ^^ oui j'ai déjà vu ça...

mais ce n'est pas plus simple en faisant le même genre de chose en restant dans mon thread principal WM qui instancie le DM puis qui traite séquentiellement les requêtes...

ou alors c'est ce que tu viens de dire ^^ -> je ne peux pas communiquer directement avec le thread principal et il me faut utiliser les Messages pour faire ainsi...

Peux tu me donner plus de détails ? notamment sur cette phrase :

en créant un Thread supplémentaire (appelon le Perpetuel), au démarrage de la DLL

[ShaiLeTroll]

dans Initialization, tu créés un objet Thread, normalement, il est global à tous les threads, tu pourrais l'utiliser pour obtenir son handle ... à toi de voir si tu préfère une ThreadList ou PostThreadMessage pour gérer la file d'attente
pensez à killer le thread dans Finalization

je ne peux pas communiquer directement avec le thread principal

Perso, je n'ai jamais fait de DLL ISAPI, j'ai une peu bidouillé sur XMLRad mais pour IIS, j'ai juste utiliser une architecture avec COM+ auquel, je n'ai pas compris grand chose, j'ignore son comportement en terme de thread, c'est que j'ai compris des propos de Franck SORIANO, que tu n'as pas un seul thread mais plusieurs qui ne sont pas de ton ressort mais celui de ISAPI

Le service est instancié/démarré lorsque IIS charge la DLL. C'est tout l'intérêt de l'ISAPI, le serveur est chargé une fois, reste en mémoire, et est interrogé en multi-threading par différents clients.

[darkendorf]

c'est que j'ai compris des propos de Franck SORIANO, que tu n'as pas un seul thread mais plusieurs qui ne sont pas de ton ressort mais celui de ISAPI

Le service est instancié/démarré lorsque IIS charge la DLL. C'est tout l'intérêt de l'ISAPI, le serveur est chargé une fois, reste en mémoire, et est interrogé en multi-threading par différents clients.

... c'est dans le détail que ça m'intéresse; concrètement, j'ai un WebModule.pas, une Interface.pas définissant les procédure exposées, et une implémentation.pas contenant mon code opérationnel. En plus un DataModule à instancier... quelque part.

si j'ai bien compris, le webmodule est généré une seule fois et reste en mémoire tant que IIS n'est pas coupé (par exemple). A chaque connexion client, mon implémentation est activée dans un thread (mais communique directement - apparemment - avec mon webmodule sans besoins de Messages Windows en appelant ses procédures comme une fiche le ferait avec une autre dans une application classique).

Donc dans un contexte "paradox", il me suffirait de générer un tableau d'objets TSession en fonction par exemple de l'adresse MAC du client avec un répertoire privateDir propre à ce client, et tout le monde pourrait se connecter par le même DataModule... ou alors instancier le DataModule dans l'implémentation.pas avec toujours un privateDir propre à chaque client.

Je vais tester ça pour voir si j'ai pas de problèmes de communications et je reviens pour vous en faire part ^^

[Franck SORIANO]

En Delphi 2007, tu as DevExpress avec les drivers MySQL fourni avec non ?

Tu veux dire dbExpress j'imagine

...c'est probablement la couche d'accès aux données la plus rapide avec celle de CoreLab\Devart ...

Pas vraiment. Fait le test avec OleDb, tu verras la différence...

PS : une requête n'a besoin d'être effectuée qu'au chargement de la DLL, je peux donc imaginer enregistrer son résultat dans une variable de mon WM pour qu'il la partage avec les autres instances, c'est bien ce qu'il faut comprendre ?

Tu es en train de dire que tu n'as besoin de l'accès à la base Paradox que pour charger des données fixes (genre config, paramétrage...), que tu pourrais tout monter en mémoire au départ, et ensuite te servir des résultats pour répondre aux clients ?
Si c'est bien ça, ne te prend pas la tête. C'est exactement ce qu'il faut faire, et c'est l'intérêt de l'ISAPI !!! Tu peux garder des données en caches entre chaque invocation du WS.

Perso, je n'ai jamais fait de DLL ISAPI, j'ai une peu bidouillé sur XMLRad mais pour IIS, j'ai juste utiliser une architecture avec COM+ auquel, je n'ai pas compris grand chose, j'ignore son comportement en terme de thread, c'est que j'ai compris des propos de Franck SORIANO, que tu n'as pas un seul thread mais plusieurs qui ne sont pas de ton ressort mais celui de ISAPI

En fait, c'est l'architecture de IIS qui fonctionne comme ça : Le serveur Web reçoit les requêtes HTTP des clients. Il les met en attente dans une file.
Il dispose d'un pool de WorkerThread (par défaut, 5 thread par CPU) qui vont aller piocher dans la file pour traiter les requêtes en attentes.

Donc chaque thread traite une requête d'un client. Soit la requête HTTP porte sur un élément qu'IIS sait traiter, soit il délègue son traitement à l'extension ISAPI. Comme l'extension ISAPI n'est rien d'autre qu'une DLL, elle est chargée lors du premier appel (il est alors possible d'exécuter du code d'initialisation), puis déchargée lorsque IIS estime qu'il n'en a plus besoin (dans la pratique, lors de l'arrêt du pool applicatif).

Au final, le filtre ISAPI peut être appelé par plusieurs Worker thread en même temps. C'est pour ça que la DLL doit être thread-safe !

Sinon, j'ai déjà utilisé Paradox en multi-thread dans un exe normal, je n'ai jamais eu de soucis

Moi j'écris des programmes de reprise de données où je lis des tables Paradox pour injecter les données dans des tables SQL Server. Je multi-thread le traitement pour traiter plusieurs tables en parallèle et accélérer le chargement.
Je peux te dire que si tu ne fais pas gaffe, le BDE ne résiste pas longtemps à ce traitement...

[darkendorf]

non non j'ai une requête spécifique un peu lourde (pas lourde à exécuter, mais qui récupère beaucoup de données) qui n'est exécutée qu'une seule fois au démarrage, mais après chaque client accède aux tables Paradox en fonction de leur activité... du coup j'imaginais charger le DataModule dans mon interface en spécifiant un répertoire différent par utilisateur pour les lock de BDE, et le premier utilistauer qui provoque le chargement de la DLL s'occupe de mettre en mémoire la grosse requête dont tous les utilisateurs auront besoin.

[darkendorf]

Me revoilou,

après quelques déboires paradoxaux, et une refonte de l'application, et encore quelques reparamétrages avec de multiples aller-retours 'nom de session automatique' puis 'manuel', etc. paratruc s'est décidé à accepter mes connexions... j'ai développé mes services, multiplié mes types de clients (app delphi et client javascript) et ça tourne assez bien ^^ à par tun petit soucis lors de la première connexion ou deux requêtes s'enchainent trop vite et paradox il et pas trop d'accord... bref.

Mon problème aujourd'hui et de m'affranchir de IIS... donc transformer mon ISAPI en application autonome (serveur web donc).

J'ai été orienté vers IdHttpServer, mais c'est la procédure de transformation de mon ISAPI qui m'inquiète : par quoi commencer ?? dois-je créer une nouvelle application et recopier le code, ou simplement coller le code source du WebModule dans une form et importer les autres modules (datamodule, interface du service, implémentation du service)

Par la suite, connaissez-vous un bon tuto de WebService en Delphi sous forme d'application indépendante avec le composant IdHttpServer ? à moins que poser le compo avec deux trois paramètres suffise...

je rêve trop peut-être ?

[Franck SORIANO]

Personnellement, je ne chercherais pas à convertir l'ISAPI.
Je garderais l'extension ISAPI tel quelle. Par contre, je développerais le serveur Web (avec idHttpServer) en implémentant la partie serveur des spécifications ISAPI de telle sorte qu'il soit capable d'utiliser la DLL !

De cette façon, on peut garder le WebService sous forme d'une extension ISAPI et le faire tourner avec n'importe quel serveur Web : Appli maison, IIS, Apache...

http://msdn.microsoft.com/en-us/libr...81(VS.90).aspx

Grosso modo, une extension ISAPI, c'est une DLL avec trois fonctions.
Donc lorsque tu reçois une requête HTTP depuis le composant idHttpServer, tu appelles la fonction HttpExtensionProc de la DLL pour lui déléguer le traitement de la requête, et tu renvoies la réponse au client.
Tu n'as même pas besoin de savoir ce que fait la DLL.

Bon dans la pratique, c'est un peu plus compliqué mais à peine...

[darkendorf]

heu... oui effectivement c'est parfait ça, mais justement c'est dans la pratique que ça m'intéresse ta proposition !!

Garder ma dll qui est fonctionnelle et développer un 'serveur' qui la charge, c'est tout simple apparemment, mais lui faire passer les requêtes et renvoyer les réponses... je vais chercher des exemples s'il en existe, mais dans le cas contraire... j'étais dans l'à peu près en faisant la dll, là je suis carrément dans l'obscure.