Structure de tomcat

Il s'agit de quelques éléments de structure du serveur tomcat

Server
C'est l'ensemble du serveur catalina. Il peut contenir un ou plusieurs services.

Service
Un service est un groupe de connecteurs partageant un unique container, par un exemple
un connecteur http et un connecteur https partageant les mêmes servlets.

Container
Un container est un objet implémentant l'interface Container.Il est capable de traiter une requêtes en provenance d'un client et de fournir un réponse. Avant d'effectuer le traitement de la requete, il peut la faire transiter par un objet Pipeline qui est composé d'un ou plusieurs objets Valves.
Le Container, grâce à la méthode invoke, passe la requete à la première valve du pipeline. Cette méthode part du principe que la requete est de type Http. Son paramètre "request" implémente l'interface "HttpServletReques"

Pipeline
Gère une liste de valve. Si cette liste est vide une valve spéciale est appelée. Elle
est stockée dans le champ 'basic'. La liste des valves est stockée sous la forme d'une liste chainée.

Valve
Permet de faire des appels aux servlets. Gère aussi l'enchainement des valves.

Quelques correspondances entre interfaces et classes:
StandardServer -> Server
StandardPipeline -> Pipeline
ContainerBase -> Container
GenericServlet -> Servlet

Comprendre les programmes opensource

Le but de cet article n'est pas d'expliquer le mode de fonctionnement des licences des projets open-source, mais plutôt de donner quelques astuces pour comprendre comment fonctionne ces logiciels. Bien que les sources soient ouverts, il n'est pas toujours évident pour une personne qui débarque dans un projet d'en comprendre la structure. On peut trouver, bien sûr, quelques documents de structure, mais cela ne suffit pas toujours.

On peut penser que la première source de documentation, ce sont les développeurs eux-mêmes. A mon avis il n'est pas judicieux de les bombarder de questions, pour au moins deux raisons : d'abord ils n'ont peut-être pas que ça à faire, et ensuite il est sans doute plus instructif de se casser les dents sur le code pour bien le comprendre, quitte à le laisser tomber momentanément lorsque l'on est vraiment bloqué.

L'autre source d'information ce sont les ouvrages édités autour des applications.Leur seul défaut est que bien souvent on n'entre pas dans le vif du sujet à quelques rares exceptions prêt. Souvent les ouvrages traitant de tomcat ou eclipse aborde le développement, mais effleure la structure même de ces produits.

Autre source d'information, bien sur ce sont les sources. Et c'est bien l'avantage même de ces produit. Le meilleur moyen des les aborder est sans doute de répérer une fonctionnalitée, ou une caractéristique et de la rechercher dans le code.
Dans le cas de firebird, par exemple, je suis parti à la recherche des mots clés SQL et des procédures stockée.
Pour le noyau linux ma première exploration vient d'un source de "Hello World" écrit en assembleur. Ce source m'a permis de voir comment sont implémentés les appels systèmes et par ce biais aller plus loin dans les sources du noyau. Dans le même style, sachant que le noyau démarre le processus "init", j'ai cherché à savoir ce qu'il fait à ce moment là.
Pour tomcat, je suis partie de l'implémentation de HttpServlet. Comme il s'agit d'un programme très structuré, il m'a été facile de voir les principales structures de ce serveur.

La dernière source d'information est bien sur internet. On peut trouver toutes sortent d'informations sur les programmes open-source que l'on souhaite étudier. Cependant, si l'on ne veut pas se noyer dans les informations et dans le bruit issue des moteurs de recherche, il est important d'avoir une démarche de recherche structurée.

Toutes ces approches sont complémentaires. Avec un peu d'organisation on peut assez rapidement venir à bout de projets complexes. Je ne dis pas que l'on peut comprendre l'exhaustivité du code de projets importants, mais que l'on peut comprendre comment il s'organise.

Urbanisation

Le concept d'urbanisme est récent mais se répand rapidement. Derrière cette formulation qui peut paraitre pompeuse, il se cache une vrai nécessitée. II repose sur le constat qu'il est illusoire de vouloir reconstruire entièrement un système d'information en faisant table rase de l'existant, pour des raisons de coût et de risque (désorganisation, pertes de données...). Les principes soutenus par ce concept est que l'on peut gérer un système d'information comme on gère l'urbanisme d'une ville. Cela revient à cartographier le sytème, identifier les voies de circulation et le faire évoluer en suivant un projet d'entreprise qui dépasse le cadre du simple projet informatique. Cela implique d'avoir une réflection méthodologique en ce qui concerne la marche à suivre pour faire évoluer le système, morceaux par morceaux, sans pertuber l'existant, mais en apportant de nouvelles fonctionnalitées essentielles à l'entreprise.
Il s'agit aussi d'avoir une vision à long terme du système d'information, ce qui implique d'avoir une connaissance claire de la stratégie de l'entreprise.

Interfaces textes

Au risque de passer pour un vieux crouton, je me demande si parfois l'antique interface texte n'avait pas du bon. Je sais bien que les interfaces graphiques, qu'elles soient web ou non, sont très conviviales et faciles d'accès, mais je ne suis pas sur qu'elle soient très adaptées pour la saisie au kilomètre.
Je m'explique : je ne sais pas si vous l'avez remarqué, mais à chaque fois que l'on souhaite développer une interface de saisie sous windows ou sur le web, se pose invariablement la question des raccourcis clavier et de la lisibilité. C'est encore plus vrai dans un contexte industriel, où la présence d'une souris devient genante et où les terminaux peuvent avoir des contraintes de taille d'écran ou des claviers spéciaux. J'ai souvent entendu les utilisateurs regretter leur ancienne interface, qu'ils trouvaient bien plus rapide à utiliser.Dans certains cas ne vaut-il pas mieux utiliser un serveur telnet plutot qu'un serveur apache ?

Idéalement, la bonne solution est la bonne interface pour les bonnes fonctions. Le marketing et tout ce qui relève de la communication avec les interfaces graphique et la production à la chaine, manipulant des informations textuelles une interface texte. Un petit bémol, s'il s'agit d'une production "complexe", impliquant des schémas ou des graphiques, cela n'est pas possible, mais s'il s'agit de liste de codes à barres ou d'adresse d'expédition, cela peut se discuter.

Ceci devrait être possible à partir d'un serveur style dotnet ou j2ee. Surtout que ces systèmes intégre des notions de type MVC, ce qui permet d'avoir les mêmes notions métiers entre tous les terminaux. Bien sur la plupart de ces serveurs sont orientés HTTP, mais il est possible d'avoir une sorte de Telnet/HTTP. (oui, oui, l'inverse du WebToHost)