Considérations de conception des applications
Cette rubrique décrit des suggestions architecturales pour la conception et l'optimisation des applications.
Les informations sur la conception des applications fournissent des suggestions relatives à l'architecture ainsi que l'implémentation des applications. Pour les applications existantes, ces recommandations peuvent nécessiter la modification des implémentations existantes. L'optimisation des paramètres des ressources et du serveur d'applications peut avoir un impact considérable sur les performances des applications bien conçues.
Utilisez les considérations de conception d'applications de cette rubrique qui contiennent des conseils pour concevoir des applications efficaces et optimisées. Ces considérations incluent des sites Web et d'autes suggestions pour rechercher les meilleures pratiques de conception d'applicationsWebSphere, notamment dans le domaine des extensions WebSphere dans la spécification Java™ Platform, Enterprise Edition (Java EE).
Les applications Java EE chargent, stockent, créent et suppriment des données des bases de données relationnelles, un processus couramment appelé persistance. La plupart des applications d'entreprise accèdent souvent à des bases de données. L'architecture et les performances de la couche de persistance est primordiale pour les performances d'une application. La persistance est donc un point très important à prendre en compte lors des choix en matière d'architecture qui peuvent avoir un impact négatif sur les performances. Ce guide préconise en premier lieu de se concentrer sur une solution présentant une architecture correcte. Cette dernière se caractérise par la cohérence des données, la sécurité, la maintenance, la portabilité et les performances de cette solution. Avec cette approche, vous n'obtiendrez peut-être pas les meilleures performances auxquelles vous pourriez prétendre en codant manuellement une solution qui ignore les qualités de service mentionnées, mais vous obtiendrez un équilibre approprié entre cohérence des données, possibilités de maintenance, portabilité, sécurité et performances.
Plusieurs options sont disponibles dans Java EE pour la persistance : les beans session utilisant des beans entity et notamment des beans CMP (persistance gérée par conteneur) ou BMP (persistance gérée par bean), les beans session utilisant JDBC (Java Database Connectivity) et les beans Java utilisant JDBC. Pour les raisons mentionnées plus haut, la persistance à l'aide des beans entity CMP est recommandée car elle offre la plus grande sécurité, maintenance et portabilité. CMP est également recommandé pour obtenir de bonnes performances. Reportez-vous à la section relative à l'optimisation du conteneur EJB dans la rubrique consacrée à l'optimisation des serveurs d'applications, pour plus d'informations sur l'optimisation des beans enterprise et plus spécifiquement, CMP.
Si une application requiert l'utilisation de beans enterprise, mais pas des entités EJB, le mécanisme de persistance implique généralement l'API JDBC. JDBC nécessitant un codage manuel (le code SQL exécuté sur une instance de base de données), il est important d'optimiser les instructions SQL utilisées dans l'application. En outre, configurez le serveur de base de données pour qu'il prenne en charge les performances optimales de ces instructions SQL. Enfin, l'utilisation d'API JDBC spécifiques doit être étudiée et notamment le traitement par lots et les instructions préparées.
Quel que soit le mécanisme de persistance pris en compte, utilisez des transactions gérées par conteneur lorsque le bean délègue la gestion des transactions au conteneur. Pour les applications qui utilisent JDBC, vous pouvez y parvenir facilement à l'aide du modèle de façade de session, qui encapsule toutes les fonctions JDBC avec un bean session sans état.
Enfin, vous trouverez des informations sur l'optimisation de la connexion sur laquelle les beans entity EJB ou JDBC communiquent, dans la section relative à l'optimisation des sources de données de la rubrique consacrée à l'optimisation des serveurs d'applications.
L'architecture MVC (Model-View-Controller) est l'une des architectures de programmation Java EE standard pour laquelle l'appel d'un servlet de contrôle peut inclure un ou plusieurs fichiers JSP (JavaServer Pages) enfant pour la construction de la vue. Le modèle MVC est recommandé pour l'architecture des applications. Ce modèle requiert une séparation distincte de la vue (fichiers JSP ou logique de présentation), du contrôleur (servlets) et du modèle (logique métier). L'utilisation du modèle MVC permet d'optimiser de manière distincte les performances et l'évolutivité de chaque couche.
Les implémentations qui évitent le stockage de l'état utilisateur du client sont les plus évolutives et obtiennent les meilleures performances. Concevez les implémentations de sorte qu'elles évitent de stocker l'état. Si le stockage de l'état est requis, vérifiez que les valeurs de la taille des données d'état et de la durée de stockage sont les plus faibles possible. En outre, si le stockage de l'état est requis, étudiez la possibilité de régénérer l'état en cas d'échec, au lieu de garantir la fonction de secours de l'état par l'intermédiaire de la réplication.
- Optimisation de la gestion des sessions
- Conseils pour l'optimisation des Enterprise JavaBeans
- Optimisation du cache dynamique avec le moniteur de cache
La plupart des charges de travail des applications Java EE comportent davantage d'opérations de lecture que d'opérations d'écriture. Les opérations de lecture requièrent la transmission d'une demande via plusieurs niveaux de la topologie comprenant un serveur Web frontal, le conteneur Web d'un serveur d'applications, le conteneur EJB d'un serveur d'applications et une base de données. WebSphere Application Server permet de mettre en mémoire cache les résultats à tous les niveaux de la topologie réseau et du modèle de programmation Java EE qui incluent des services Web.
Les concepteurs d'applications doivent songer à utiliser la mise en cache lors de la conception de l'architecture de l'application car cette fonction s'intègre à la plupart des niveaux du modèle de programmation. La mise en cache est un autre motif d'application du modèle MVC dans les applications. La combinaison de la mise en cache et de MVC peut offrir une fonction de mise en cache indépendante de la technologie de présentation et en cas d'absence de présentation aux clients de l'application.
Les concepteurs de réseaux doivent songer à utiliser la mise en cache lors de la planification du réseau car cette fonction s'intègre également à la plupart des niveaux de la topologie du réseau. Pour les applications disponibles sur Internet, les concepteurs de réseaux peuvent songer à utiliser une mise en mémoire cache ESI (Edge Side Include) lorsque la mise en mémoire cache de WebSphere Application Server s'étend à Internet. Les services de mises en mémoire cache réseau sont disponibles sur le serveur proxy pour WebSphere Application Server, WebSphere Edge Component Caching Proxy et le plug-in WebSphere.
Les charges de travail Java EE comprennent généralement deux types d'opération. Vous devez effectuer le premier type d'opération pour répondre à une demande système. Vous pouvez effectuer le second type d'opération de manière asynchrone une fois que la demande utilisateur à l'origine de l'opération est traitée.
C'est notamment le cas d'une application qui permet de soumettre un bon de commande, qui permet de continuer pendant que le système le valide, qui interroge les systèmes éloignés et qui par la suite vous indique le statut du bon de commande. Cet exemple peut être implémenté pendant que le client attend la réponse. L'implémentation synchrone requiert des ressources du serveur d'applications et vous devez attendre que toutes les opérations soient terminées. Si le processus vous permet de continuer, pendant la détermination asynchrone du résultat, le serveur d'applications peut planifier le traitement de manière optimale en fonction des autres demandes. Il peut vous notifier par courrier électronique ou par le biais d'une autre interface de l'application.
L'approche asynchrone prenant en charge une planification optimale des charges de travail et l'utilisation d'une quantité minimale de ressources, ne négligez pas les architectures asynchrones. WebSphere Application Server prend en charge la programmation asynchrone via le service Java EE Java Message Service (JMS) et les beans gérés par message (MDB), ainsi que le produit Concurrency Utilities for Java EE qui sont décrits dans les rubriques Optimisation de JMS (Java Message Service) et Optimisation de MDB.
Vérifiez que toutes les bibliothèques utilisées par les applications sont également conçues pour les performances côté serveur. Certaines bibliothèques sont conçues pour fonctionner correctement dans une application client, mais ignorent les problèmes de performances côté serveur, notamment en matière de mémoire utilisée, de synchronisation et de regroupement en pools. Il est recommandé que toutes les bibliothèques non développées dans le cadre d'une application fassent l'objet de test de performances avec les mêmes méthodologies de test que celles utilisées pour l'application.
Références supplémentaires :IBM® WebSphere Developer Technical Journal: The top 10 Java EE best practicesImprove performance in your XML applications, Part 2