Caractéristiques de WebSphere Application Server

WebSphere Application Server est une plate-forme sur laquelle des applications d'entreprise Java de fonctionner. WebSphere Application Server est une implémentation de Java 2 Enterprise Edition (J2EE).

WebSphere Application Server fournit des services de base de données (connectivité, filetage, gestion de la charge, etc) qui peuvent être utilisés par les applications d'entreprise. L'élément principal est le serveur d'application, un processus java qui encapsule nombreux services, y compris les conteneurs, où la logique métier exécute. Si vous êtes familier avec J2EE, vous reconnaîtrez le conteneur Web et le conteneur EJB. Le conteneur Web exécute Servlets et JavaServer Pages (JSP), qui tous deux sont des classes Java qui génèrent des balises pour être vu par un navigateur Web. Le trafic entrant et sortant de la cartouche de bande se déplace à travers le serveur HTTP intégré. Bien servlets et les JSP peuvent agir de façon indépendante, ils ont le plus souvent faire des appels à Enterprise Java Beans (EJB) pour exécuter la logique métier ou accéder aux données. EJB, qui s'exécutent dans le conteneur d'EJB, sont facilement réutilisables classes java. Elles sont le plus souvent de communiquer avec une base de données relationnelle ou une autre source externe de données d'application, soit renvoyer ces données vers le conteneur Web ou apporter des modifications aux données pour le compte de la servlet ou JSP.

Le moteur de messagerie JMS est intégré dans le serveur d'applications. Il s'agit d'un moteur de pure java messagerie. Destinations JMS, connus sous le nom des files d'attente et les sujets de fournir des services de messagerie asynchrone pour le code s'exécutant à l'intérieur des conteneurs, JMS sera abordée plus en détail plus loin dans ce cours.

Comme vous le verrez plus en détail plus tard, le moteur de services Web permet aux composants de l'application d'être exposées en tant que services Web, qui peut être consulté en utilisant Simple Object Access Protocol (SOAP).

Plusieurs autres services s'exécutant dans le serveur d'application, y compris le cache dynamique, la réplication des données, la sécurité, et d'autres. Ceux-ci seront traités plus loin dans ce cours.

Il ya aussi quelques éléments importants en dehors du processus de serveur d'applications.
WebSphere Application Server fournit également un plug-in pour les serveurs HTTP qui détermine ce que le trafic HTTP est destiné à être manipulé par WebSphere, et achemine les requêtes vers le serveur approprié. Le plug-in est également un acteur essentiel dans la gestion de charge de requêtes HTTP, car elle peut répartir la charge au serveur d'applications multiples, ainsi que diriger le trafic loin de serveurs indisponibles. Elle aussi les routes de sa configuration à partir d'un fichier XML spécial.

Un des servervices fournis dans le serveur d'application est le service d'administration. Ce service permet de configurer le serveur d'application. Ces fichiers nécessaires à la configuration sont stockées en dehors du serveur d'application effective dans un ensemble de fichiers de configuration XML. Il est une application qui s'exécute dans l'application Web-la console d'administration.

WebSphere architecture d'administration

Il existe deux principaux outils utilisés pour administrer WebSphere Application Server: 1) la console d'administration, et 2) outil de ligne de commande wsadmin.

Configuration du serveur est stocké dans un ensemble de fichiers XML, souvent désigné comme le référentiel de configuration. Ces fichiers définissent le serveur lui-même, ainsi que des ressources et des services qu'il fournit. L'un des services offerts dans le serveur d'application est le service d'administration. Ce service permet de configurer le serveur d'application. Les fichiers nécessaires à la configuration sont stockées en dehors du serveur d'application effective dans un ensemble de fichiers de configuration XML. Il est une application qui s'exécute dans le conteneur Web qui fournit à l'utilisateur la possibilité d'administrer le serveur d'application via une application Web, la console d'administration. Ici vous pouvez voir la communication à partir du navigateur tout le chemin vers les fichiers de configuration XML. Wsadmin ne peut être utilisé pour administrer le serveur d'application de deux manières. 1) Via SOAP en communiquant avec le serveur HTTP intégré. 2) En utilisant RMI (par défaut) pour communiquer directement avec le service d'administration.

L'un des services offerts dans le serveur d'application est le service d'administration. Ce service permet de configurer le serveur d'application. Les fichiers nécessaires à la configuration sont stockées en dehors du serveur d'application effective dans un ensemble de fichiers de configuration XML. Il est une application qui s'exécute dans le conteneur Web qui offre aux utilisateurs la possibilité d'administrer le serveur d'application via une application Web, la console d'administration.

WebSphere profils aperçu

Les profils sont la voie que vous êtes autorisé à exécuter plus d'un serveur d'applications sur une seule installation de fichiers de produits WebSphere.

Les profils sont des ensembles de fichiers qui représentent une configuration de WebSphere Application Server. Fichiers WebSphere Application Server sont divisés en deux catégories. 1) Les fichiers de produit Set de partage en lecture seule des fichiers statiques ou binaires produits partagées par toutes les instances du produit WebSphere Application Server. Les fichiers de configuration 2) (profils) Ensemble de fichiers de données personnalisables par l'utilisateur. Les fichiers contiennent: WebSphere configuration, les applications installées, les adaptateurs de ressources, les propriétés, les fichiers journaux, etc. Chaque profil utilise les mêmes fichiers de produit, plus simple que de multiples installations de WebSphere, moins d'espace disque, simplifie l'application des mises à jour de produits.

Dans le répertoire d'installation de WebSphere il ya des sous-répertoires pour chaque profil. Dans l'exemple ci-dessus, il ya deux serveurs d'applications en cours d'exécution qui sont chacun configure les fichiers qui existent au sein de leur répertoire propre profil.

Flux réseau runtime déploiement

Le thème principal est le déploiement du réseau d'applications distribuées. Alors que le «flux» d'une application reste le même, il ya des ajouts importants à l'exécution d'une application. Notez le "équilibreur de charge" ce qui permet de multiples serveurs HTTP, les utilisateurs remarquer il ya des navigateurs pour l'équilibrage de charge et leur demande sera charge de travail est parvenu à un serveur HTTP. Une fois la demande frappe l'un de ces serveurs HTTP, le serveur HTTP plug-in charge de la demande entre les serveurs d'applications qu'il est configuré pour servir. Une fois que la demande arrive sur le serveur d'applications, le débit est identique à ce qu'il était en Express et Base. Les clients Java demandes à EJB peut également être géré la charge de travail afin que les demandes ne sont pas tous atteint un serveur d'application.

Débit réseau de l'Administration de déploiement.

Chaque processus de gestion, agent de noeud, gestionnaire de déploiement démarre avec son propre ensemble de fichiers de configuration. Gestionnaire de déploiement contient la configuration MASTER et fichiers d'application. Toutes les modifications apportées à l'agent de noeud ou du serveur sont locales et sera remplacée par la configuration MASTER à la prochaine synchronisation. La console d'administration et wsadmin sont encore les deux façons dont l'environnement est administré. Toutefois, prenez note que ces outils maintenant parler au gestionnaire de déploiement et NOT pour les serveurs d'applications directement. La communication de ces commandes émane des outils pour le gestionnaire de déploiement pour les agents de noeud, les serveurs d'applications. Cela permet à l'administration de plusieurs nœuds (chacun contenant éventuellement des serveurs d'applications multiples) à partir d'un point focal unique (le gestionnaire de déploiement).

Il est un référentiel principal pour les fichiers de configuration au sein d'une cellule, et ceux-ci sont associés avec le gestionnaire de déploiement. Toutes les mises à jour des fichiers de configuration doivent passer par le gestionnaire de déploiement. Vous verrez dans un instant comment ce processus fonctionne. Vous devriez être très prudent dans la connexion à un serveur d'application directement avec wsadmin ou la console d'administration que toutes les modifications qui sont apportées aux fichiers de configuration ne sont que temporaires, ils seront remplacés par les fichiers de configuration des fichiers maîtres.

Serveur Web personnalisé plugin-cfg.xml

Les définitions de serveur Web sont créées pour permettre la cartographie des applications d'entreprise J2EE sur des serveurs Web spécifiques. Peut être fait par la console d'administration. Vous pouvez également utiliser le script généré lors de l'installation de la chauve-souris plug-in qui permet d'automatiser la cartographie de toutes les applications à la configuration du serveur Web. Dans le bac. La cartographie des applications vers des serveurs Web spécifiques provoquera la coutume plugin-cfg.xml fichiers uniquement pour les serveurs Web afin d'inclure les informations relatives à ces applications. Serveurs Web cible exécutant des applications spécifiques dans une cellule. Généré automatiquement par le gestionnaire de déploiement. Tout comme les modules d'une application les entreprises ont besoin d'être relié à un ou plusieurs serveurs d'applications, ils ont aussi besoin d'être relié à un ou plusieurs serveurs Web.

Emballage J2EE

Une application J2EE est emballé dans une archive Enterprise, un fichier avec l'extension a.EAR. L'application dispose d'un descripteur de déploiement, représenté ici sous forme de DD, ce qui permet la configuration de l'environnement d'un conteneur spécifique lorsqu'il est déployé. L'application peut comporter un ou plusieurs modules. Composants J2EE sont regroupées en modules, et chaque module dispose de son propre descripteur de déploiement. EJB EJB modules de groupe liés dans un seul module, et sont emballés dans Java Archive (JAR). Notez qu'il ya seulement descripteur de déploiement pour l'ensemble des EJB dans le module. Web Modules de regrouper les fichiers de classe servlet, JSP, les fichiers HTML et les images. Ils sont emballés dans Web Application Archive (WAR) des fichiers. Modules client d'application sont emballés dans Java Archive (JAR). Adaptateurs de ressources peuvent être emballés pour le serveur d'application ou dans un dossier de candidature. EAR.

Assemblage une application d'entreprise

Lorsque vous travaillez avec un espace de travail remis par le développement, aucun assemblage requis (fait automatiquement par l'outil). Si vos développeurs utilisent des outils IBM vous pouvez recevoir un existant, un dossier de travail espace de travail pour la configuration et le déploiement finale. Dans ce cas, les fichiers individuels WAR et JAR ne sont pas nécessaires car ils existent déjà dans le cadre de l'espace de travail. Lorsque vous travaillez avec des espaces de travail tout ce que vous devez faire lors du démarrage AST, est le point dans le répertoire racine de l'espace de travail. Si vous recevez la GUERRE individu et les fichiers JAR, qui sont les modules de l'application, vous devrez pointer AST à un espace de travail vide qui tiendra espace de travail de l'application Enterprise. Vous ne le faire la première fois, par la suite, que vous venez de pointer vers ce répertoire AST espace de travail nouvellement créé. Dans ce dernier scénario, le montage est tout simplement l'action d'importer les fichiers contenant les modules et les associer à l'application d'entreprise. Le résultat final est un fichier EAR, qui contient tous les modules et leurs descripteurs de déploiement. Le fichier EAR peut alors être installé (ou déployée) pour un serveur d'application.

Création d'une source de données

Les applications installées qui doivent interagir avec des bases de données relationnelles utilisent les fournisseurs JDBC pour accéder aux données. Ensemble, les objets JDBC sources de fournisseurs et les données sont fonctionnellement équivalent à l'architecture J2EE Connector (JCA) fabrique de connexions (qui donne accès à des bases de données non relationnelles). Applications installées utilisent une source de données pour accéder aux données de la base de données. Une source de données est associée à un fournisseur JDBC qui fournit la classe spécifique JDBC mise en oeuvre du conducteur. La source de données représente l'J2EE Connector Architecture (JCA) fabrique de connexion de l'adaptateur relationnelle. Utiliser des composants d'application de la source de données pour accéder à des instances de connexion à une base de données spécifique, un pool de connexion est associé à chaque source de données. Vous pouvez créer plusieurs sources de données avec des paramètres différents, et de les associer avec le même fournisseur JDBC. (Une raison pour ce faire est de donner accès aux différentes bases de données.) Fournisseurs JDBC pris en charge par WebSphere Application Server sont nécessaires pour mettre en œuvre l'une ou l'autre des interfaces sources de données suivants, qui sont définis par Sun Microsystems. Les interfaces permettent l'application de s'exécuter dans un réseau monophasé ou protocole de transaction en deux phases.

Journaux WebSphere Application Server

La machine virtuelle Java (JVM) des journaux

Les journaux JVM sont créés par la réorientation des flux System.out et System.err de la JVM pour les fichiers journaux indépendants. WebSphere Application Server écrit des messages formatés pour le flux System.out. En outre, les applications et d'autres codes peuvent écrire sur ces flux en utilisant la print () et Printin () méthodes définies par les cours d'eau. Dans le cas d'une configuration de WebSphere Application Server Network Deployment, journaux JVM sont également créés pour le gestionnaire de déploiement et chaque agent de noeud, car ils représentent aussi les machines virtuelles.

Journaux processus

Processus WebSphere Application Server contient deux flux de sortie qui sont accessibles en code natif s'exécute dans le processus. Ces cours d'eau sont les stdout et stderr flux. Le code natif, y compris les machines virtuelles Java (JVM), peut écrire des données sur ces flux de processus. En outre, la JVM fournie flux System.out et System.err peut être configuré pour écrire leurs données à ces cours d'eau aussi. Comme avec JVM de sciage, il existe un ensemble de logs de processus pour chaque serveur d'application, étant donné que chaque machine virtuelle est un processus du système d'exploitation, et dans le cas d'une configuration de WebSphere Application Server Network Deployment, un ensemble de billes de processus pour le gestionnaire de déploiement et chaque agent de noeud.

IBM Service Logs

Le journal du service d'IBM contient à la fois les messages WebSphere Application Server qui sont écrites dans le flux System.out et des messages spéciaux contenant des informations de service étendu qui n'est normalement pas d'intérêt, mais peut être important lors de l'analyse des problèmes. Il ya un journal de service pour toutes les machines virtuelles Java WebSphere Application Server sur un nœud, y compris tous les serveurs d'applications. Le journal du service d'IBM est maintenu dans un format binaire et nécessite un outil spécial pour la voir. Ce spectateur, l'analyseur AST Log and Trace, fournit d'autres possibilités de diagnostic. En outre, le format binaire fournit des fonctionnalités qui sont utilisés par des organisations de support IBM. Le serveur HTTP plug-in log sera décrit plus tard dans cette présentation.

Présentation wsadmin

Wsadmin offre des capacités de script et de ligne de commande d'administration. Les tâches courantes d'exploitation et la configuration peut être effectuée à partir de scripts et de la ligne de commande plutôt que par la console d'administration. WebSphere Application Server outil wsadmin offre la possibilité d'exécuter des scripts. Vous pouvez utiliser l'outil wsadmin pour gérer un serveur WebSphere Application Server V6.1 installation. Cet outil utilise le Bean Scripting Framework (BSF), qui prend en charge une variété de langages de script pour configurer et contrôler votre installation de WebSphere Application Server. Le lanceur wsadmin rend les objets administratifs disponibles via des interfaces spécifiques du langage. Scripts utiliser ces objets pour la gestion des applications, la configuration, le contrôle opérationnel et pour la communication avec les MBeans s'exécutant dans WebSphere Process Server. Wsadmin agit comme une interface avec les objets Java pour l'accès par des scripts. Wsadmin utilise la même interface (par JMX) que la console d'administration pour modifier la configuration et les serveurs de contrôle

Là, un nombreux niveaux qui sont involed dans un environnement de sécurité. WebSphere fournit qu'une partie de la sécurité totale qui doit être appliquée. Des choses comme la sécurité du système de fichiers doivent encore être pris en compte pour protéger des choses comme vos fichiers de configuration et porte-clés. Sécurité Système d'exploitation - L'infrastructure de sécurité du système d'exploitation sous-jacent fournit des services certaine sécurité à la sécurité des applications WebSphere. Cela inclut le soutien à la sécurité du système de fichiers pour sécuriser les fichiers sensibles dans l'installation du produit WebSphere. L'administrateur système WebSphere pouvez configurer le produit pour obtenir des informations d'authentification directement à partir du registre d'utilisateurs du système d'exploitation, par exemple le gestionnaire de NT Security Access....