11/02/02

SRM : Les serveurs d'applications en PHP

Interview de Derick Rethans, développeur principal du SRM. Le SRM apporte à PHP la persistance des applications (ressources, variables, connexions aux bases de données...) et propulse PHP dans la cours des serveurs d'applications.

Damien Seguy	:	*Qu'est ce que le SRM?*
Derick Rethans	:	SRM est un acronyme pour 'Script Running Magic' (script faisant de la magie), ou 'Script Running Machine'. Simplement, le SRM rend possible l'utilisation d'instances de classe distantes ; l'appel de fonctions distantes, qui sont déjà compilées, et le stockage de données entre plusieurs pages et plusieurs utilisateurs. Dans ce dernier cas, SRM fournit un système de variables d'applications. Mais le plus intéressant est l'appel d'objets distants aussi facilement que si c'était une instance locale. Ces objets, des bananes, comme nous les appelons, sont écrits en PHP, et sont conservés en mémoire entre deux requêtes de page. Toutes les fonctionnalités distantes sont écrites en PHP.

Damien	:	*Qu'est ce qui vous a poussé a créer le SRM.*
Derick	:	Uhm.. Et bien…Cela a commencé par une longue discussion houleuse, un flame, sur la liste de diffusion PHP-dev. Certains membres de la communauté (en particulierles méchants allemands) se chamaillaient à propos des serveurs d'applications. A cette époque, personne n'avait de définition bien précise pour cela, mais une des fonctions les plus importantes était les variables d'application. Alors, James Moore a eu l'idée de l'implémenter dans PHP lui-même, mais avec James et Mathieu Kooiman, nous avons décidé de réaliser certaines fonctionnalités, qui n'étaient pas limitées par PHP lui-même.

Damien	:	*A quand remonte le début de ce projet ?*
Derick		En Novembre / Décembre 2000. Nous (en particulier moi) avons commencé à programmer, sous la forme d'un projet de fin de scolarité. Nous voulions utiliser le SRM pour conserver des états d'authentification, et mettre en cache les résultats de requêtes.

Damien	:	*Un an après, est ce que le SRM ressemble au projet initial ? Est il mieux ? Qu'est ce qui a été abandonné ?*
Derick	:	SRM est très différent maintenant, et bien sur, il est mieux. Une des fonctionnalités qui reste est les variables persistantes. Mais c'est probablement la seule, à mon avis. Nous avons abandonné l'approche 'module' du SRM, et nous avons ajouté un système de cache de résultat. Nous ne souhaitions pas reprogrammer le SRM pour chaque type de fonctionnalité que PHP propose. Durant nos rencontres de développement à Arnhem, nous avons décidé d'utiliser PHP/Zend comme un module. Jani Taskinen démontra la possibilité de ce système, et Mathieu réécrit l'extension PHP pour qu'elle communique avec le SRM avec un langage Orienté Objet. J'ai alors étudié pas mal de programmes, et j'ai rendu possible l'exécution de fonctions distantes (écrites en PHP, et chargée dans le SRM sous forme de script compilé), et le support des bananes.

Damien	:	*Si je comprends bien, il y a des scripts PHP d'un coté, et un démon SRM de l'autre. C'est ça ?*
Derick	:	Oui. Le démon exécute les fonctions distantes, et conserve les objets. Les scripts PHP et les fonctions distantes sont écrites en PHP.

Damien	:	*Quels avantages y a t il a se dépendre d'un démon externe pour exécuter des scripts PHP ?*
Derick	:	Ce n'est pas 'dépendre' mais plutôt coopérer. En PHP, vous ne pouvez pas faire survivre de variable après la fin d'un script. Sans parler des ressources comme des connexions LDAP ou un pointeur de fichier. Un autre avantage du SRM est que de multiples utilisateurs peuvent exploiter le même objet, et communiquer entre eux facilement. De plus, le démon peut exécuter des scripts de lui même, comme par exemple, rafraîchir des données toutes les 5 minutes. C'est excellent pour monter un système de cache, en coopération avec les ADT de Sterling (Abstract Data Types).

Damien	:	*Aujourd'hui, qui peut profiter du SRM ?*
Derick	:	Ceux qui seront le plus intéressés seront ceux qui ont besoin d'un système de stockage persistant ; ceux qui ont besoin d'automatisation de leur site (rafraîchissement automatique des données) et ceux qui on besoin d'une 'application'. Je vais expliquer cela avec l'aide de 'Galactic Tales'. Galactic Tales est un jeu en ligne allemand, qui ressemble à civilization. Ici, ils ont besoin d''application' : les planètes et les stations spatiales gère des ressources qui leur sont propres, comme la recherche. C'est très difficile à faire avec des scripts PHP, car il n'y a alors pas de concept de 'temps'. Avec SRM, Galactic Tales disposaient de planètes automatiques, qui avaient une vie de leur coté, sans avoir réellement besoin de sollicitations de la part des utilisateurs. Seulement besoin d'informations de la part d'autres objets du jeu. Dernièrement, j'ai eu une discussion avec Ulf Wendel et Hartmut Holzgraefe à propos des caches des pages dynamiques. Un des plus grands problèmes est de savoir quand reconstruire la page. Laissons le SRM s'en occuper : Si quelque chose du coté de l'administration change, placez un booléen dans le SRM qui indique que la page a été mise à jour, ou bien que la requête a été modifiée. Dès que l'application résidente du SRM détecte ce changement (vérifications régulières), elle peut vérifier quelles sont les pages modifiées et les reconstruire. Les relations entre ces pages sont conservées en mémoire, dans le SRM, sous la forme d'un graphe supporté par ADT.

Damien	:	En résumé, le SRM renvoie les scripts PHP à la génération pure de pages HTML. Ils gèrent les pages web éphémères et assure la connexion avec l'internaute. Le SRM assure la survie de l'application, qui vit indépendamment.

Damien	:	Quelles sont les applications actuelles qui pourraient profiter du SRM ? PHPnuke, IMP, phorum, sont des exemples d'applications OpenSource majeures. Pourraient-elles être réécrites avec le SRM et améliorée ?
Derick	:	Prenons IMP. Comme vous le savez, IMP utilise IMAP pour ses fonctions MAIL. IMAP n'a pas de concept de liens persistants, et chaque page ouvre à nouveau une connexion au serveur. Il est possible de réécrire IMP sous forme de banane, pour qu'il s'exécute automatiquement, c'est à dire qu'il lise automatiquement le courrier lorsque nécessaire, recalcule les threads de messages, etc… Le script PHP (par opposition au SRM), ne s'occupe plus que de mise en page. L'authentification peut se faire sans un réel besoin de cookies ou d'autre chose, et les données d'identification ne doivent pas être stockées dans une session, car le SRM peut le gérer (il faudra toute fois un identifiant pour relier un utilisateur à ses données). PHPnuke devrait être banni de la terre, mais par exemple Phorum pourrait stocker des données dans une structure de données interne (un arbre de chez ADT, par exemple). Le script PHP n'aura plus jamais è recalculer les threads… Il n'est pas possible de tout écrire dans les bananes du SRM, mais vous pouvez séparer l'application de son affichage plutôt facilement. Un autre point avec phorum est que tous les messages sont partagés en mémoire par les utilisateurs, et presque aucune requête externe n'est nécessaire, en tous cas pas à chaque page, car le SRM garde tout en mémoire.

Damien	:	*Quel est le niveau de performance du SRM ?*
Derick	:	Nous ne l'avons pas encore testé, mais vous pouvez imaginer que garder des informations comme des forums hiérarchisés en mémoire accélère votre application, car aucune requête n'est nécessaire et qu'aucune calcul n'est demandé pour la mise en thread. Cela accélère notablement les performances. Utiliser des objets distants sur la même machine que le SRM (il communique via les sockets UNIX, sous Unix) est quasiment aussi rapide que d'utiliser un objet local. Une des raisons de ces performances est que le script dans le SRM est déjà analysé, et que l'objet existe déjà.

Damien	:	*Quels systèmes supporteront le SRM ?*
Derick	:	Pour le moment, il fonctionne sur Linux, Solaris et OpenBSD (le dernier n'a pas été testé dernièrement). Il y a aussi du monde qui souhaite le porter sur Windows. Le portage vers les autres systèmes Unix ne sera pas difficile. Dan Kalowsky travaille sur le portage MacOSX.

Damien	:	*Sous quelle licence sera placé le SRM ?*
Derick	:	La version Beta verra probablement le démon sous licence MPL, et les SAPI SRM et l'extension SRM seront sous licence PHP. Toutes les évolutions futures du démon seront sûrement sous licence Apache.

Damien	:	*Est ce que le SRM fera partie de la distribution PHP ?*
Derick	:	C'est difficile à dire. L'interface SAPI et l'extension seront ajoutées au CVS de PHP, mais le démon ne sera pas intégré dans PHP. Il y a toujours la possibilité que nous le fassions un jour ou l'autre.

Damien	:	*Quel sera le support disponible pour le SRM ?*
Derick	:	Du support sera fourni pour un usage commercial, sur une base commerciale, tout comme MySQL. Mais nous espérons qu'une communauté se formera, tout comme pour PHP. Le support des utilisateurs non-commerciaux (ce qui ne sera probablement pas beaucoup en nombre) se fera avec l'esprit de l'Open Source : si nous le voulons, nous le ferons. J'aime ce style.

Damien	:	*Enfin, quand sera t il publié officiellement ?*
Derick	:	Un projet comme celui ci n'est jamais fini, tout comme PHP, ou le noyau Linux. La version Beta est prévue pour bientôt, mais je ne peux pas prédire les dates de publications, car je n'en sais rien moi-même.
http://www.vl-srm.net
Damien Seguy

/ Retours d'expérience