WebSphere Application Server : présentation et démarrage rapide
En savoir plus sur le modèle de programmation, comprendre le fonctionnement général du produit et démarrer rapidement.
- Spécifications Java™ et autres normes ouvertes pour le développement d'applications
- Extensions du modèle de programmation WebSphere pour améliorer la fonctionnalité des applications
- Conteneurs et services dans le serveur d'applications, utilisés par les applications déployées, et qui peuvent parfois être étendus
Le diagramme présente l'installation d'un seul serveur d'applications. Les parties concernant le modèle de programmation sont décrites ici. Les autres parties comprennent l'architecture du produit, indépendamment des différents types d'application décrits par le modèle de programmation. Voir Présentation du produit.
Composants d'application Java EE
- Applications Web exécutées dans le conteneur web
Le conteneur web est la partie du serveur d'applications dans laquelle s'exécutent les composants de l'application web. Une application Web se compose d'un ou plusieurs servlets associés, de la technologie JavaServer Pages (fichiers JSP) et de fichiers HTML (Hyper Text Markup Language) que vous pouvez gérer comme unité. Ils collaborent à l'exécution d'une fonction de logique applicative (ou "métier").
Le conteneur web traite les servlets, les fichiers JSP et les autres types d'inclusions SSI. Chaque exécution du serveur d'applications possède un conteneur web logique qui peut être modifié mais pas créé ou supprimé. Chaque conteneur web fournit les éléments suivants.- Chaînes de transport de conteneur Web
- Les demandes sont dirigées vers le conteneur web à l'aide de la chaîne de transport entrante du conteneur Web. La chaîne se compose d'un canal des communications entrantes TCP qui fournit la connexion au réseau, un canal de communications entrantes HTTP qui prend en charge les requêtes HTTP et un canal de conteneur web qui permet d'envoyer les requêtes concernant les servlets et les fichiers JSP au conteneur web afin qu'elles soient traitées.
- Traitement de servlet
- Lors de la gestion des servlets, le conteneur web crée un objet de requête et un objet de réponse, puis appelle la méthode de service de servlet. Le conteneur web
appelle la méthode de destruction de servlet le cas échéant et décharge le servlet pour qu'ensuite la machine JVM effectue la récupération de place.
Les servlets peuvent effectuer certaines tâches, notamment prendre en charge les contenus de pages web dynamiques, donner accès à des bases de données, servir simultanément plusieurs clients et filtrer des données.
Les fichiers JSP permettent de séparer le code HTML de la logique métier dans les pages Web. Les extensions IBM® de la spécification JSP permettent aux auteurs HTML d'ajouter facilement la puissance de la technologie Java aux pages web, sans être experts en programmation Java.
- Traitement HTML et autre contenu statique
- Les requêtes pour HTML et autre contenu statique adressées au conteneur web sont servies par la chaîne entrante de conteneur web. Cependant, il est généralement conseillé d'utiliser pour un environnement de production un serveur web externe et un module d'extension du serveur web en tant qu'interface frontale du conteneur web.
- Gestion de session
- La prise en charge est assurée pour l'interface javax.servlet.http.HttpSession de la façon décrite dans la spécification API du serveur.
Une session HTTPest une série de requêtes adressées à un servlet, provenant du même utilisateur et du même navigateur. Les sessions permettent aux applications s'exécutant dans un conteneur web de conserver la trace des différents utilisateurs. Par exemple, de nombreuses applications web permettent aux utilisateurs de collecter dynamiquement des données à mesure qu'ils naviguent sur le site, par une série de sélections effectuées sur les pages qu'ils consultent. L'endroit où se rend ensuite l'utilisateur ou ce qu'affiche ensuite le site peut dépendre du choix précédent de l'utilisateur sur le site. Pour gérer ces données, l'application les stocke dans une "session".
- Applications SIP et leur conteneur
Les applications SIP sont un programme Java qui utilise au moins un servlet SIP (Session Initiation Protocol). SIP permet d'établir et d'interrompre des sessions IP multimédias y compris la téléphonie sur IP, la présence et la messagerie instantanée.
- Collections de portlets et leur conteneur
Les collections de portlets sont des servlets Java réutilisables qui sont affichées sous forme de zones définies sur les pages du portail. Les portlets permettent d'accéder à de nombreux applications, services et contenus Web différents.
- Applications EJB exécutées dans le conteneur d'EJB
Le conteneur d'EJB fournit tous les services d'exécution requis pour déployer et gérer des beans enterprise. C'est un processus serveur qui traite les requêtes pour la session et les beans entity.
Les beans enterprise sont des composants Java qui implémentent généralement la logique métier des applications Java EE, ainsi que l'accès aux données. Les beans enterprise regroupés dans les modules EJB et installés dans un serveur d'applications ne communiquent pas directement avec le serveur. Ainsi, le conteneur d'EJB constitue une interface entre les composants EJB et le serveur d'applications. Ensemble, le conteneur et le serveur constituent l'environnement d'exécution du bean enterprise.
Le conteneur fournit plusieurs services de bas niveau, comme le support des transactions et des unités d'exécution. Sous l'angle administratif, le conteneur gère l'accès aux données pour les beans qu'il contient. Un seul conteneur peut héberger plusieurs fichiers JAR d'EJB.
Applications client et autres types de clients
- Applications client et leur conteneur
- Le conteneur client est installé à part sur la machine client et non sur le serveur d'applications.
Le client peut exécuter des applications dans un environnement Java EE compatible EJB. Le diagramme présente un client Java qui s'exécute dans le conteneur client.
Ce produit fournit un Outil launchClient pratique pour le démarrage du client d'application avec l'exécution du conteneur client.
En fonction de la provenance des informations techniques, les applications client peuvent être parfois appelées clients d'application. La présente documentation emploie indifféremment les deux termes.
- Clients Web, appelés également clients de navigateur Web
- Le diagramme présente un client de navigateur web, ou client Web, qui envoie une demande au conteneur web du serveur d'applications. Un client web ou client de navigateur web s'exécute dans un navigateur web et est généralement une application Web.
- Clients de services Web
- Les clients de services Web sont encore un autre type de clients que peut héberger votre environnement de traitement d'application. Le diagramme ne montre pas de client de services Web. Les informations de services web comprennent des informations sur ce type de client.
- Clients d'administration
- Le diagramme présente deux types de clients d'administration : un client de scriptage et la console d'administration qui est l'interface graphique (GUI) pour administrer ce produit. Ils accèdent tous deux à des parties de l'infrastructure d'administration des systèmes. Etant donné que les clients d'administration sont identiques quel que soit le type d'applications que vous déployez sur le serveur, ils font partie de l'architecture du produit. Cependant, étant donné que la plupart de ces clients sont des programmes que vous créez, ils sont abordés sous l'angle du modèle de programmation.
Services Web
- Services Web
- Les diagramme présente le moteur des services Web, élément du support des services
Web dans le contexte d'exécution du serveur d'applications. Les services Web sont des applications modulaires autonomes pouvant être décrites, publiées, recherchées et appelées sur un réseau. Ils implémentent une
architecture orientée services (SOA), qui prend en charge la connexion ou le partage de
ressources et de données d'une manière souple et normalisée. Les services sont décrits et
organisés de manière à permettre leur recherche et leur réutilisation dynamique et
automatisée.
Le produit se comporte à la fois comme un fournisseur de services web et comme un demandeur. En tant que fournisseur, il héberge des services web qui sont publiés pour être utilisés par les clients. En tant que demandeur, il héberge des applications qui appellent des services web depuis d'autres emplacements. Le diagramme présente le moteur des services web, contactant un fournisseur de services web ou une passerelle.
Accès aux données, messagerie et ressources Java EE
- ²Ressources d'accès aux données
- La gestion des connexions d'accès aux systèmes
d'information d'entreprise (EIS) du serveur
d'applications est fondée sur la spécification Java EE Connector Architecture (JCA). Le diagramme présente une application qui utilise les services JCA pour accéder à une base de données dans laquelle l'application récupère et conserve des données.
La connexion entre l'application enterprise et le système EIS s'effectue par le biais d'adaptateurs de ressources fournis par EIS et connectés au serveur d'applications. L'architecture détermine la gestion des connexions, la gestion des transactions et les contrats de sécurité établis entre le serveur d'applications et le système EIS.
Le gestionnaire de connexions du serveur d'applications (non indiqué) met en pool et gère les connexions. Il est capable de gérer les connexions obtenues via les adaptateurs de ressources définis par la spécification JCA, mais aussi celles qui sont obtenues via les sources de données définies par la spécification des extensions JDBC 2.0.
Les ressources JDBC (fournisseurs et sources de données JDBC) sont l'un des types de ressources Java EE qu'utilisent les applications pour accéder à des données. Même si l'accès aux données couvre bien d'autres notions que les ressources JDBC, cette documentation regroupe souvent les questions d'accès aux données avec les ressources Java EE pour plus de simplicité.
Les adaptateurs de ressources JCA sont un autre type de ressources Java EE utilisé par les applications. JCA définit l'architecture standard pour la connexion de la plateforme Java EE à des systèmes EIS. Prenons l'exemple d'une application ERP, d'un traitement de transaction principal, de systèmes de base de données et d'applications existantes non écrits en langage de programmation Java.
L'adaptateur de ressources JCA est un pilote logiciel au niveau système fourni par les vendeurs EIS ou d'autres vendeurs tiers. Il fournit la connectivité entre des serveurs ou des clients d'application Java EE et un EIS. Pour utiliser un adaptateur de ressources, installez le code d'adaptateur de ressources et créez des configurations qui utilisent cet adaptateur. Le produit fournit un adaptateur de ressources relationnel prédéfini.
- Ressources de messagerie et moteurs de messagerie
- Le support JMS permet aux applications d'échanger des messages en mode asynchrone
avec d'autres clients JMS en utilisant des destinations JMS (files d'attente ou
rubriques). Les applications peuvent utiliser des beans gérés par message afin d'extraire
automatiquement des messages à partir de destinations JMS et de noeuds finaux JCA sans
avoir à demander explicitement les messages.
Pour les demandes non JMS entrantes, les beans gérés par message utilisent un adaptateur de ressources JCA (Java EE Connector Architecture) 1.5 écrit à cette fin. Pour la fonction de messagerie JMS, les beans gérés par message peuvent utiliser un fournisseur de messagerie compatible JCA, tel que le fournisseur de messagerie par défaut intégré au produit.
Le moteur de messagerie prend en charge les types de fournisseurs de messagerie suivants.- Fournisseur de messagerie par défaut (bus d'intégration de services)
- Le fournisseur de messagerie par défaut utilise le bus d'intégration de services pour le transfert. Le fournisseur de messagerie par défaut fournit des fonctions point-à-point ainsi que des fonctions de publication et d'abonnement. Avec ce fournisseur, vous définissez des fabriques de connexion JMS et des destinations qui correspondent aux destinations de bus d'intégration de services.
- Fournisseur IBM MQ
- Vous pouvez utiliser IBM MQ en tant que fournisseur JMS externe. Le serveur d'applications fournit les classes client JMS et l'interface d'administration, tandis que IBM MQ fournit le système de messagerie basé sur une file d'attente.
- Fournisseur JMS générique
- Vous pouvez utiliser un autre fournisseur de messagerie à condition qu'il implémente le composant ASF de la spécification JMS 1.0.2. Les ressources JMS pour ce fournisseur ne peuvent pas être configurées à l'aide de la console d'administration.
transition : Dans la version 6, il n'existe plus le serveur JMS avec un moteur de messagerie intégré dans le serveur d'applications et qui proposait les différents types de fournisseurs mentionnés précédemment. Le fournisseur de messagerie de la version 5 est disponible pour la configuration de ressources devant être utilisées avec la messagerie intégrée de la version 5. Vous pouvez également utiliser le fournisseur de messagerie par défaut de la version 5 avec un bus d'intégration de services.EJB 2.1 introduit un ActivationSpec pour connecter les beans gérés par message vers les destinations. Pour assurer la compatibilité avec la version 5, vous pouvez configurer des beans gérés par message JMS (EJB 2.0) pour un port d'écoute. Pour ces beans gérés par message, le service d'écoute des messages fournit un gestionnaire de programmes d'écoute qui contrôle et surveille un ou plusieurs programmes d'écoute JMS, chacun de ces programmes surveillant une destination JMS pour le compte d'un bean géré par messages déployé.
- Bus d'intégration des services
Le bus d'intégration de services fournit une infrastructure de communication unifiée pour la messagerie et les applications orientées service. Le bus d'intégration de services est un fournisseur JMS qui assure le transfert fiable des messages et utilise la logique intermédiaire pour adapter intelligemment un flux de messages dans le réseau. Il prend en charge le rattachement des demandeurs et des fournisseurs des services web. Ses fonctions sont entièrement intégrées dans l'architecture du produit, y compris la sécurité, l'administration système, la surveillance et les sous-systèmes d'identification d'incident.
Le bus d'intégration de services est souvent désigné sous le terme de bus. Lorsqu'il est utilisé pour héberger des applications JMS, il est souvent désigné sous le terme de bus de messagerie. Il se compose des parties suivantes (non présentées en détails dans le diagramme).- Membres de bus
- Serveurs d'applications ajoutés au bus.
- Moteur de messagerie
- Il s'agit du composant qui gère les ressources de bus. Il fournit un point de connexion pour permettre aux clients d'envoyer ou de recevoir des messages.
- Destinations
- Il s'agit de l'emplacement du bus où les applications se connectent pour échanger des messages. Les destinations peuvent représenter des noeuds finaux de services Web, des files d'attente point-à-point de messagerie ou des rubriques de publication et d'abonnement de messagerie. Les destinations sont créées dans un bus et hébergées dans un moteur de messagerie.
- Emplacement de stockage des messages
- Chaque moteur de messagerie utilise une série de tables dans un magasin de données pris en charge (par ex. une base de données JDBC) afin de stocker des informations tels des messages, des informations d'abonnement et des états de transaction.
A l'aide de l'activation du SIBWS (service integration bus web services), vous pouvez :- Mettre un service interne déjà disponible à une destination de service, à disposition en tant que service web.
- Rendre un service externe web disponible à une destination de service.
- Utiliser la passerelle des Services web pour mapper un service existant (service interne ou service web externe) sur un nouveau service web qui semble être fourni par la passerelle.
- Accès concurrents, messagerie, adresses URL et autres ressources Java EE
- Les applications déployées sur un serveur d'applications compatible Java EE utilisent
les ressources J2EE suivantes :
- Ressources JDBC et autre technologie d'accès aux données (traité précédemment)
- Adaptateurs de ressources JCA (traité précédemment)
- Ressources JMS et autre système de messagerie (traité précédemment)
- Ressources concurrentes pour soumettre ou planifier l'exécution de tâches en parallèle, créer des unités d'exécution qui héritent du contexte Java EE et transférer un contexte Java EE pour appeler des interfaces, telles que des rappels asynchrones
- Prise en charge de JavaMail, pour que les applications puissent envoyer du courrier
Internet
LesAPI JavaMail fournissent une infrastructure indépendante de la plateforme et du protocole qui permet de créer des applications client de messagerie Java. Les API nécessitent des fournisseurs de services, appelés fournisseurs de protocole, pour agir en interaction avec les serveurs de messagerie qui s'exécutent sur des protocoles liés.
Un fournisseur de mail renferme plusieurs fournisseurs de protocole, comprenant Simple Mail Transfer Protocol (SMTP) pour envoyer du courrier, Post Office Protocol (POP) pour recevoir du courrier et Internet Message Access Protocol (IMAP) qui est une autre option pour recevoir du courrier. Pour utiliser un autre protocole, vous devez installer un fournisseur de services adapté au protocole.
Outre les fournisseurs de services, JavaMail doit disposer également de la structure JAF (JavaBeans Activation Framework), pour gérer des types de données complexes (et non du texte simple), comme le courrier de type MIME (Multipurpose Internet Mail Extensions), les pages URL et les fichiers joints.
- des URL, pour décrire des emplacements logiques ;
Les fournisseurs URL implémentent la fonctionnalité pour un protocole URL spécifique, comme HTTP, permettant la communication entre l'application et une ressource URL qui est prise en charge par un protocole spécifique. Un fournisseur URL par défaut est fourni pour l'utilisation par toute ressource URL dotée de protocoles basés sur la spécification Java SE (Java Platform, Standard Edition) prise en charge, par exemple HTTP, FTP ou File. Vous pouvez également intégrer vos propres fournisseurs URL qui implémentent des protocoles supplémentaires.
- Entrées d'environnement de ressources, pour mapper des noms logiques vers des noms physiques
L'environnement java:comp/env fournit un mécanisme simple permettant de consulter les objets d'espace de nom JNDI et les objets d'environnement d'application locaux. Par défaut, le produit fournit de nombreuses entrées d'environnement locales.
La spécification Java EE fournit également un mécanisme pour définir les entrées d'environnement client en définissant des entrées dans le descripteur de déploiement standard d'une application. La spécification Java EE utilise les méthodes suivantes pour séparer la définition d'une entrée d'environnement de ressource d'une application.- Demander au serveur d'applications de fournir un mécanisme pour définir des objets d'administration séparés qui encapsulent une entrée d'environnement de ressource. Les objets d'administration sont accessibles à l'aide de JNDI dans l'espace de nom local du serveur d'applications (java:comp/env).
- Indiquer le nom de recherche JNDI de l'objet d'administration et le type d'objet à renvoyer souhaité. Cette indication est effectuée dans l'entrée d'environnement de ressources mentionnée dans le descripteur de déploiement.
Le produit prend en charge l'utilisation des entrées d'environnement de ressources avec les concepts d'administration suivants.- Une entrée d'environnement de ressources définit la cible de liaison (nom JNDI), la classe de fabrique et renvoie le type d'objet (via le lien à un référençable) de l'entrée d'environnement de ressources.
- Un référençable définit le nom de classe de la fabrique qui renvoie les instances d'objet implémentant une interface Java.
- Un fournisseur d'environnement de ressources regroupe les référençables, les entrées d'environnement de ressources et toute caractéristiques personnalisées requises.
Sécurité
- Modèle de programmation de sécurité et infrastructure
- Le produit fournit des infrastructures
et des mécanismes de sécurité pour protéger les ressources Java EE confidentielles et les
ressources d'administration. Il répond ainsi à l'ensemble des besoins de sécurité des
entreprises pour l'authentification, le contrôle d'accès aux ressources, l'intégrité des
données, la confidentialité et l'interopérabilité sécurisée.
L'infrastructure et les mécanismes de sécurité protègent les ressources Java EE (Java Platform, Enterprise Edition) ainsi que les ressources d'administration en répondant aux exigences de sécurité de votre entreprise. L'infrastructure de sécurité de ce produit fonctionne avec l'infrastructure de sécurité existante de votre environnement informatique d'entreprise comportant plusieurs niveaux. Basé sur le concept d'architecture ouverte, le produit fournit de nombreux points de connexion permettant l'intégration aux composants logiciels d'entreprise en vue d'assurer une sécurité de bout en bout.
L'infrastructure de sécurité comprend un modèle de programmation et des éléments de l'architecture du produit qui sont indépendants du type d'application.
Services supplémentaires à l'usage des applications
- Service de nommage et d'annuaire
- Chaque serveur d'applications fournit un service d'affectation de nom qui fournit à son tour un espace de nom JNDI (Java Naming
and Directory Interface). Le service est utilisé pour enregistrer les ressources hébergées sur le serveur
d'applications. L'implémentation JNDI
est constituée à partir d'un service de nommage (CosNaming) CORBA
(Common Object Request Broker Architecture).
JNDI fournit l'accès au service de nommage côté client et présente le modèle de programmation utilisé par les développeurs d'applications. CosNaming fournit l'implémentation côté client. C'est aussi l'endroit où est stocké l'espace de nom. JNDI fournit essentiellement côté client une enveloppe de l'espace de nom stocké dans CosNaming et interagit avec le serveur CosNaming pour le compte du client.
Les clients du serveur d'applications utilisent l'architecture de nommage pour extraire des références à des objets liés à ces applications. Ces objets sont liés dans une structure essentiellement hiérarchique appelée espace de nom. Cet espace de nom est constitué d'une série de liaisons de nom, chacune composée d'un nom renvoyant à un contexte spécifique et à l'objet lié de ce nom. L'espace de nom peut être accédé et manipulé via un serveur de noms.
Ce produit fournit les caractéristiques de noms et d'annuaire suivantes.- Espace de nom réparti, pour une évolutivité supplémentaire
- Partitions transitoires et persistantes, pour des liaisons à divers niveaux
- Structure d'espace de nom fédéré sur plusieurs serveurs
- Liaisons configurées pour la définition de liaisons associées au système au démarrage du serveur
- Support des URL d'objet INS (Interoperable Naming Service) CORBA
Remarque : avec l'ajout du gestionnaire de membre virtuel dans le but de fournir une prise en charge de référentiel fédéré pour la sécurité du produit, celui-ci offre désormais des possibilités de gestion d'identité plus extensibles et plus élaborées qu'auparavant, surtout en association avec les autres produits WebSphere et Tivoli.
- Fonction ORB (Object Request Broker)
- Ce produit utilise un ORB pour gérer les interactions aussi bien entre les
applications du client et celles du serveur qu'entre les composants du produit. Un ORB utilise
IIOP pour prendre en charge les demandes client et les réponses
reçues des serveurs dans un environnement réseau réparti.
L'ORB fournit aux clients une structure qui leur permet de localiser des objets dans le réseau et d'appeler des opérations sur ces objets, comme s'ils étaient situés dans le même processus d'exécution que le client, ce qui déboucherait sur une certaine transparence au niveau des emplacements.
Bien que le diagramme ne le montre pas, l'ORB intervient lorsque le conteneur client contacte le conteneur d'EJB de la part d'un client Java.
- Transactions
- Le serveur d'applications intègre un service de transaction. Ce produit offre des
capacités transactionnelles avancées qui épargnent aux développeurs d'application
l'écriture de code personnalisé. Il fournit le support requis pour pallier bon nombre des
difficultés liées à l'intégration des ressources logicielles existantes à un
environnement Java EE.
Ces mesures incluent ActivitySessions.
Les applications IBM WebSphere Application Server peuvent utiliser des transactions pour coordonner plusieurs mises à jour de ressources sous forme d'une seule unité de travail afin que toutes les mises à jour ou aucune des mises à jour soient permanentes. Les transactions sont lancées et arrêtées par les applications ou le conteneur dans lequel les applications sont déployées.
Le serveur d'applications est un gestionnaire de transactions qui prend en charge la coordination des gestionnaires de ressources et participe à des transactions globales distribuées avec d'autres gestionnaires de transaction compatibles.
Le serveur peut également être configuré afin d'agir en interaction avec des bases de données, des files d'attente JMS et des connecteurs JCA grâce à la prise en charge des transactions locales, lorsque la prise en charge des transactions distribuées n'est pas nécessaire.
La manière dont les applications utilisent les transactions varie en fonction du type de composant d'application, par exemple :- Un bean session peut gérer ses transactions lui-même ou déléguer la gestion des transactions au conteneur.
- Les beans entity utilisent les transactions gérées par conteneur.
- Les composants Web, comme les servlets, utilisent des transactions gérées par bean.
Le produit traite les transactions avec les composants suivants.- Un gestionnaire de transactions prend en charge la liste des ressources XAResources et s'assure que ces ressources résultent en une issue cohérente à la fin de la transaction ou après un échec et un redémarrage du serveur d'applications.
- Un conteneur gère la liste des ressources XAResources pour le compte des application déployées lorsque celles-ci effectuent des mises à jour des gestionnaires de ressources de transaction (des bases de données, par exemple). Le conteneur peut également contrôler la démarcation des transactions pour les beans enterprise configurés pour les transactions gérées par le conteneur.
- Un API traite les beans enterprise gérés par beans et les servlets, permettant à ces composants d'application de contrôler la démarcation de leurs propres transactions.
Extensions WebSphere
Les extensions de modèle de programmation WebSphere sont l'apport au modèle de programmation dont vous bénéficiez lorsque vous achetez ce produit. A la pointe de la technologie, ces extensions permettent de programmer et de déployer plus facilement et de manière plus productive des applications plus performantes et plus efficaces.
De plus, vos applications peuvent utiliser une structure d'extension Eclipse. Vos applications sont extensibles dès que vous définissez un point d'extension et fournissent un code de traitement des extensions pour la zone extensible de l'application. Vous pouvez également connecter une application à une autre application extensible par la définition d'une extension répondant aux besoins du point d'extension cible. Le point d'extension peut rechercher dynamiquement l'extension nouvellement ajoutée, et la fonction est intégrée en toute transparence à l'application existante. Le système fonctionne sur la base de la compatibilité entre les modules Java Platform Enterprise Edition (Java EE). Le registre d'extension d'application utilise le format de descripteur de plug-in Eclipse et les API comme mécanisme d'extensibilité pour les applications WebSphere. Les développeurs qui créent les modules d'application WebSphere peuvent utiliser les extensions WebSphere Application Server pour implémenter des outils Eclipse et fournir des modules plug-in pour contribuer à des fonctionnalités comme des actions, des tâches, des éléments de menu et des liens vers des points d'extension prédéfinis dans l'application WebSphere. Pour plus d'informations sur cette fonction, voir Registre d'extensions d'applications.
Les extensions de modèle de programmation WebSphere et les services d'application correspondant qui les prennent en charge dans l'environnement d'exécution du serveur d'applications, se répartissent en trois groupes : extensions de modèle d'objet métier, les extensions de modèle d'objet de processus et les extensions qui génèrent des applications de génération future.
Extensions du groupe modèle d'objet métier
- Profilage d'applications
- Le profilage d'application est une extension WebSphere permettant de définir des
stratégies de contrôle dynamique des accès simultanés, de pré-extraction et de lecture
anticipée.
Le profilage d'application et la tentative d'accès permettent d'optimiser facilement les performances des applications des beans enterprise sans répercussion sur le code source. Différents beans enterprise, voire même différentes méthodes dans un bean enterprise, peuvent avoir leur propre tentative d'accès aux ressources. Profiler les composants d'après leur tentative d'accès accroît les performances dans l'environnement d'exécution du serveur d'applications.
- Service Dynamic query
- Dynamic Query est une extension de programmation WebSphere apportant aux applications
une souplesse sans précédent. Ce service vous permet de générer et de soumettre
dynamiquement des requêtes qui sélectionnent, trient, joignent et effectuent des calculs
sur des données d'application au moment de l'exécution. Le service Dynamic Query offre la
possibilité de transmettre et de traiter des requêtes EJB Query Language au moment de
l'exécution, ce qui supprime le besoin de définir des requêtes obligatoires dans le code
des descripteurs de déploiement lors du développement des applications.
Dynamic Query améliore les beans enterprise en permettant au client d'exécuter des requêtes personnalisées sur des composants EJB lors de l'exécution. Jusqu'à présent, les recherches EJB et les mappages de zones étaient mis en oeuvre en phase développement et leur modification nécessitait un nouveau développement ou réassemblage.
- Mémoire cache dynamique
- Le service de cache dynamique améliore les performances en mettant en cache mémoire
la sortie des servlets, des commandes et des fichiers JSP. Ce service intercepte les
appels aux objets pouvant être mis en cache et stocke la sortie de l'objet ou prend en
charge le contenu de l'objet à partir de la cache dynamique.
Les applications Java EE ayant un rapport de lecture-écriture élevé peuvent tolérer un petit temps de latence dans l'actualisation de leurs données, la cache dynamique permet d'améliorer sensiblement les temps de réponse du serveur, le débit et l'évolutivité.
Les fonctions disponibles sont la réplication entre clusters, le déchargement de disque de la cache dynamique, la mise en cache ESI (Edge Side Include) et la mise en cache externe (possibilité de contrôler les mises en cache hors du serveur d'applications, par exemple sur le serveur Web).
Extensions du groupe modèle de processus métier
- ActivitySessions
- Les ActivitySessions sont une extension WebSphere qui simplifient le traitement des
règles de validation et des limitations associées aux ressources de validation en une
phase.
Les ActivitySessions permettent d'étendre la portée de plusieurs transactions locales et de les regrouper. Elles peuvent ainsi être validées en fonction de critères de déploiement ou via une logique de programmation explicite.
- Services Web
- Les services Web sont des applications modulaires autonomes pouvant être décrites, publiées, recherchées et appelées sur un réseau. Ils implémentent une architecture orientée services (SOA), qui prend en charge la connexion ou le partage de ressources et de données d'une manière souple et normalisée. Les services sont décrits et organisés de manière à permettre leur recherche et leur réutilisation dynamique et automatisée.
Extensions pour la création de la génération suivante d'applications
- Beans asynchrones
- Les beans asynchrones sont obsolètes ; ils ont été remplacés par Concurrency Utilities for Java
EE.
Le beans asynchrones améliorent considérablement les performances des tâches consommatrices d'un grand nombre de ressources en permettant à des tâches isolées de s'exécuter comme des tâches multiples. Des options de planification asynchrone permettent de traiter des requêtes de traitement parallèle en "mode différé" à un moment choisi. Le produit prend intégralement en charge l'exécution et l'appel asynchrone d'unités d'exécution et de composants sur le serveur d'applications. Le serveur d'applications fournit un contexte d'exécution et de sécurité aux composants, en les intégrant totalement à l'application.
- Beans de lancement
- Des beans de démarrage permettent l'exécution automatique de la logique métier au démarrage et à l'arrêt du serveur d'applications. Ils peuvent, par exemple, être utilisés pour remplir des caches propres à l'application, initialiser des pools de connexions au niveau de l'application ou effectuer d'autres procédures d'interruption et d'initialisation propres à l'application.
- Pools d'objets
- Des pools d'objets constituent des moyens efficaces d'améliorer les performances au moment de l'exécution et autorisant la réutilisation de plusieurs instances d'objets. Cette réutilisation réduit la surcharge associée à l'instanciation, l'initialisation et la récupération de place des objets. La création d'un pool d'objets permet à une application d'obtenir une instance d'objet Java et de renvoyer l'instance au pool lorsqu'elle n'en a plus besoin.
- Internationalisation
- Le service d'internationalisation est une extension WebSphere visant à améliorer la productivité des développeurs . Il permet de reconnaître automatiquement le fuseau horaire et la localisation des informations du client appelant, de sorte que votre application réponde de manière adéquate. Avec cette technologie, l'utilisateur du monde entier obtient des informations de date et d'heure exactes, les langues et devises appropriées et les formats de date et décimaux corrects.
- Planificateur
- Le service de planification est une extension de programmation WebSphere chargée de déclencher des opérations à des heures ou intervalles donnés. Il permet de réduire les coûts informatiques et d'accroître la vitesse de traitement et de réponse des applications en optimisant l'utilisation des ressources informatiques existantes. Le service de planification offre la possibilité de traiter les charges de travail à l'aide de processus parallèles, d'attribuer une priorité élevée à des transactions spécifiques et de planifier l'exécution de tâches moins importantes à des heures de moindre trafic.
- Zones de travail
- Les zones de travail sont des extensions WebSphere permettant d'améliorer la
productivité des développeurs. Les zones de travail offrent une fonctionnalité comparable à celle des "variables globales". Elles offrent une solution pour la transmission et la propagation
d'informations contextuelles entre des composants d'application.
Les zones de travail permettent le partage réel des informations sur une application répartie. Par exemple, vous pouvez ajouter des informations de profil pour chaque client qui accède à votre application. Si vous placez ces informations dans une zone de travail, elles seront disponibles dans toute votre application, sans avoir à coder manuellement une solution ou à lire et écrire des informations dans une base de données.