Jusqu'ici je n'ai dit que des choses positives sur Tomcat et WebSphere. Etesvous prêt à entendre des choses plus désagréables ? Commençons par Tomcat.
Le plus gros problème avec Tomcat est le manque d'assistance. Personne n'attend à côté d'un téléphone d'assistance technique pour aider à résoudre vos problèmes. De plus,
Tomcat ne
prend en charge qu’un seul serveur : il
ne gère pas le clustering. Avec
WebSphere, le clustering et le failover
sont assurés (ainsi que l’assistance
technique).
Tomcat a aussi la réputation d’être
moins évolutif que WebSphere. Tomcat
ne supporte pas les EJB – pas plus
d’ailleurs que les autres API J2EE. De
plus, Tomcat n’offre pas un environnement
intégré avec une GUI sophistiquée
pleine de wizards et d’aide en
ligne.
En tant que partisan de Tomcat, je
puis réfuter les critiques dont il fait
l’objet.
Prise en charge de J2EE. Bien que
Tomcat ne supporte pas directement
toutes les API J2EE que WebSphere
supporte (comme JDBC, JNDI,
JavaMail, RMI, JMS, XML et EJB), toutes
ces API, à l’exception notable d’EJB,
sont disponibles moyennant l’inclusion
de fichiers JAR (Java Archive) disponibles.
Assistance technique. Le Jakarta
Project n’a peut-être pas un service
d’assistance technique, mais une multitude
de newsgroups et de forums
sont prêts à recevoir des questions.
Souvent, on reçoit des réponses plus
rapides de la part d’un forum opensource
qu’un fournisseur. Avec, il est
vrai, un gros bémol : les newsgroups
sont irresponsables et la qualité des
renseignements n’est absolument pas
garantie.
Dans un environnement cyber en constante mutation, le phishing évolue vers des attaques toujours plus sophistiquées combinant IA, automatisation et industrialisation. Une réalité complexe qui exige des mesures de sécurité avancées et repensées au-delà de l’authentification multifacteur. Découvrez les réponses technologiques préconisées par les experts Eviden et les perspectives associées à leur mise en œuvre.
