Contrôlez directement la programmation de votre application Web.
Cet article démontre quelques techniques simples de programmation PHP pour offrir une interface Web à une classique application de saisie de commandes. Vous apprendrez à déployer des scripts PHP non orientés objet traditionnels qui interagissent avec les procédures stockées RPG de l’application de saisie de commandes Acme servant d’exemple.
Je ne manifeste aucune préférence de code envers un produit PHP ou un framework PHP particulier.
Le simple apprentissage progressif de PHP vous mettra rapidement aux commandes de la programmation de votre application Web PHP. Imaginez d’écrire un code PHP simple au lieu d’apprendre, personnaliser et déployer d’encombrants frameworks OO pour de simples applications sur le Web. Si vous recherchez un langage d’interface Web facile à apprendre sur i5/OS, ceci devrait vous intéresser.
L’idée principale de la programmation Web avec Apache/PHP est de permettre à plusieurs applications de type navigateur d’utiliser un petit pool de jobs serveurs prédémarrés (jobs Apache worker), en donnant à chaque client navigateur l’impression d’être le seul détenteur de la machine tout en modérant l’usage des ressources machine.
La programmation d’applications PHP basée sur Apache est par conséquent stateless ; après que chaque client navigateur subseconde utilise le job Apache/PHP, tous les attributs de programmation (variables RPG, variables PHP, fichiers ouverts) sont libérés pour permettre au prochain client navigateur d’utiliser le même job pour une toute autre chose.
Le petit pool de jobs Apache worker est généralement attribué à chaque requête client Web subseconde (clic du navigateur) selon un mode « qui n’est pas occupé ? » aléatoire.
Par conséquent, il n’est pas certain que notre application reviendra au même job Apache/PHP à chaque transition d’écran. C’est pourquoi nous ne devrions pas laisser des données et les ressources machine traîner dans le job Apache/PHP, au risque d’affecter négativement la prochaine application, sans aucun rapport avec la présente, réutilisant le job.
En revanche, dans une application interactive (5250) RPG traditionnelle, toute la session utilisateur est l’otage d’un job unique/client unique, gardant ainsi son état complet (variables RPG, fichiers ouverts) pendant que l’utilisateur travaille dans l’application. Les applications GUI traditionnelles sur Windows, Linux, AIX et Java autonome sont aussi des modèles « otages » full state, client/job/thread unique comme des sessions 5250.
Dans le réseau, la plupart des applications client/serveur déploient aussi un modèle « otage » client/job/thread unique, insérant simplement des transferts de protocole de communication (socket) de données entre l’écran et le serveur de logique de gestion. La programmation Web est différente.
Mais alors comment utiliser Apache/PHP comme interface Web avec une application de saisie de commandes RPG existante ? PHP a un certain nombre d’extensions i5/OS bien connues, dont ibm_db2 et i5/OS Toolkit, pour appeler la logique de gestion en arrière-plan RPG. L’application de saisie de commandes Acme fournissait des procédures stockées stateless à appeler à partir de notre frontal PHP, donc ibm_db2 est un bon choix pour cette démonstration.
Astuce : Concevoir une interface Web comme un frontal GUI « copie conforme » de votre application interactive est une raison fréquente d’échec d’un projet Web pour développeurs débutants. L’application de saisie de commandes Acme fournit un bon exemple d’interface de procédures stockées stateless dont vous pouvez vous inspirer pour votre application Web.
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
