Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2 Update 2 est un serveur compatible avec la plate-forme J2EE 1.4 permettant de développer et de déployer des applications J2EE et des services Web basés sur la technologie Java dans des environnements de production à grande échelle.
Cette section aborde les sujets suivants :
serveur d'application Environment Enterprise 8.1 2005Q2 Update 2 propose les améliorations suivantes :
Amélioration de l'administration : serveur d'application prend en charge la gestion sécurisée distante des déploiements d'entreprise multimachines complexes via une console installée sur un navigateur ou une interface de ligne de commande pouvant contenir des scripts. Il fournit également une interface API JMX complète permettant un accès par programme distant et sécurisé aux fonctions de contrôle et d’administration.
Courtier de messages : serveur d'application est fourni avec un courtier de messages de classe d'entreprise intégré, composant un système de messagerie haute disponibilité, performant, fiable et évolutif.
Prise en charge d'une plate-forme étendue : de nouveaux systèmes d'exploitation, environnements localisés et composants matériels, ainsi que de nouvelles bases de données sont pris en charge.
Sun Java Enterprise System : serveur d'application, considéré comme composant clé de Sun Java Enterprise System, est étroitement intégré aux services d'identités réseau et de portail.
Outils de migration et de mise à niveau : ces outils vous permettent de vérifier la portabilité et le respect des standards des applications J2EE, facilitent la migration à partir d'autres serveurs d'applications J2EE (JBoss, WebLogic, WebSphere) et contribuent à la mise à niveau à partir des versions précédentes de Sun ONE Application Server/iPlanet Application Server.
Prise en charge de Java 2 Standard Edition 5.0 : serveur d'application prend en charge Java 2 Standard Edition 5.0 qui comprend des fonctions de contrôle et de gestion améliorées ainsi que plusieurs améliorations en termes de performances et d'évolutivité.
Prise en charge des plug-in Java Web Services Developer Pack 1.6 (JWDSP) : tous les plug-in JWSDP sont désormais pris en charge. JWSDP 1.6 peut être téléchargé gratuitement à l'adresse http://java.sun.com/webservices/downloads/1.6/index.html.
Pilotes JDBC : serveur d'application est doté des pilotes Sun JDBC.
Sécurité des services Web : ces mécanismes de sécurité des messages du conteneur implémentent un système d'authentification au niveau des messages (par exemple, le chiffrement ou la signature numérique XML) des appels de services Web SOAP. Pour cela, des profils nom utilisateur/mot de passe X509 de la norme OASIS WS-Security sont utilisés.
WS-I Basic Profile 1.1 : comme indiqué dans la spécification J2EE 1.4, cette version implémente Web Services Interoperability (WS-I) Basic Profile 1.1 afin d'autoriser une intéroperabilité des applications de services Web.
Connectivité d'arrière-plan avec des adaptateurs iWay : désormais, Sun Microsystems revend et prend en charge vingt-deux adaptateurs iWay pour la connexion des systèmes centraux (SAP, Siebel, Oracle, CICS et IBM MQ Series) afin que vous puissiez tirer parti des applications informatiques existantes depuis l'environnement serveur d'application. Ces adaptateurs prennent en charge la spécification J2EE Connector Architecture 1.5 et les normes de services Web (SOAP). Ils incluent par ailleurs des outils de développement permettant de réduire le temps de connexion aux applications d'arrière-plan.
Dernière version du système de gestion HADB : les plates-formes UNIXTM intègrent le nouveau système de gestion de base de données haute disponibilité (HADB version 4.4.3). Ce système se compose d'un serveur de base de données, d'un pilote ODBC 2.5, d'un pilote JDBC 3.0 de type 4, du programme clusql (programme interactif permettant de saisir et d'exécuter des instructions SQL) et d'un système de gestion. Cette version permet d'éliminer la dépendance SSH/RSH, mais requiert une configuration réseau pour multidiffusion UDP. Reportez-vous au manuel Sun Java System Application Server Enterprise Edition 8.1 2005Q2 High Availability Administration Guide pour plus d'informations sur la configuration minimale requise et les restrictions de HADB.
Prise en charge des zones Solaris 10 : serveur d'application peut être installé dans une zone globale ou non globale sous Solaris 10. Reportez-vous à la page Solaris Zones pour plus d'informations sur les zones Solaris.
Cette section présente la configuration système requise pour installer Sun Java System serveur d'application Environment Enterprise 8.1.
Le tableau ci-dessous répertorie les systèmes d'exploitation pris en charge par Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2. En outre, il indique la mémoire minimale requise et la mémoire recommandée pour l'installation et l'exécution d'serveur d'application.
Tableau 2–1 Configuration requise par la plate-forme Sun Java System serveur d'application 8.1 2005Q2
Système d'exploitation |
Mémoire minimum |
Mémoire recommandée |
Espace disque minimum |
Espace disque recommandé |
JVM |
---|---|---|---|---|---|
Sun Solaris 8, 9, 10 (SPARC) Solaris 9, 10 (x86) |
512 Mo |
1 Go |
250 Mo disponibles |
500 Mo disponibles |
J2SE 1.4.2_06, J2SE 5.0 |
Red Hat Enterprise Linux2.1 Update 2, 3.0 Update 1 |
512 Mo |
1 Go |
220Mo disponibles |
300Mo disponibles |
J2SE 1.4.2_06, J2SE 5.0 |
Windows Server 2000 SP4+ Windows 2000 Advanced Server SP4+ Windows Server 2003 Windows XP Pro SP1+ |
1 Go |
2 Go |
500 Mo disponibles |
1 Go disponible |
J2SE 1.4.2_06, J2SE 5.0 |
Sous UNIX, vous pouvez vérifier la version du système d'exploitation en utilisant la commande uname et l'espace disque en utilisant la commande df.
Pour obtenir la liste actuelle des patchs requis pour Sun Java System serveur d'application Environment Enterprise 8.1, accédez au site http://sunsolve.sun.com et faites une recherche sur app server 8.1 patch.Suivez les liens de Sun Java System serveur d'application Environment Enterprise 8.1. Au fur et à mesure de la modification des exigences relatives aux patchs de système d'exploitation et de la mise à disposition de patchs pour les composants Java Enterprise System, des mises à jour sont disponibles sur le site SunSolve, initialement sous la forme de blocs de patchs recommandés.
Sun conseille aux utilisateurs de Solaris 9, 10 (x86, SPARC) d'installer le groupe de patchs recommandés. Ce dernier est disponible dans la section des patchs sécurisés et recommandés du site SunSolve.
Pour exécuter des composants natifs de ce produit, y compris le programme d'installation, le package suivant (qui ne fait pas partie de la distribution RedHat Enterprise Linux 3.0 standard) doit être installé : compat-libstdc++-7.3-2.96.118.i386.rpm
Le package peut être téléchargé à l'adresse http://rpm.pbone.net/index.php3/stat/4/idpl/843376/com/compat-libstdc++-7.3-2.96.118.i386.rpm.html.
Sun Java System serveur d'application a été conçu pour prendre en charge la connectivité des SGBD avec les pilotes JDBC correspondants. Pour obtenir la liste des composants testés par Sun et jugés compatibles pour la création de configurations de bases de données conformes J2EE, reportez-vous au tableau suivant :
Tableau 2–2 Pilotes JDBC compatibles J2EE
Fournisseur JDBC |
Type de pilote JDBC |
Serveur de base de données pris en charge |
---|---|---|
Logiciel inet |
Type 4 |
Oracle (R)8.1.7, 9i, 9.2.0.3 Sybase ASE12.5.2 Microsoft SQL Server 20004.0 Service Pack1 |
IBM |
Type 2 |
IBM DB28.1 Service Pack3+ |
PointBase |
Type 4 |
PointBase Network Server4.8 |
DataDirect |
Type 4 |
Oracle (R)8.1.7, 9i, 9.2.0.3 Sybase ASE12.5.2 Microsoft SQL Server IBM DB28.1 Service Pack3+ |
Pilote JDBC Sun Java System pour Oracle |
Type 4 |
Oracle (R)9.2.0.3, 10G |
Pilote JDBC Sun Java System pour DB2 |
Type 4 |
IBM DB28.1 Service Pack3+ |
Pilote JDBC Sun Java System pour Sybase |
Type 4 |
Sybase ASE12.5.2 |
Pilote JDBC Sun Java System pour Microsoft SQL Server |
Type 4 |
Microsoft SQL Server 20004.0 Service Pack1 |
Oracle |
Type4, type2 |
Oracle (R)9.2.0.3, 10G |
Pour obtenir plus d'informations sur le logiciel i-net, consultez le site http://www.inetsoftware.de/.
Pour obtenir plus d'informations sur DataDirect Technologies, consultez le site http://www.datadirect.com/.
Les pilotes JDBC Oracle doivent être correctement configurés pour être compatibles avec J2EE 1.4. Pour ce faire, utilisez la configuration suivante avec les pilotes de types 2 et 4 :
Utilisez le pilote JDBC version 9.2.0.3 ou version ultérieure.
Le fichier de paramètres (init.ora) de la base de données Oracle doit contenir le paramètre compatible=9.0.0.0.0 ou supérieur.
Utilisez le fichier ojdbc14.jar.
Configurez serveur d'application de façon à définir la propriété JVM suivante :
-Doracle.jdbc.J2EE13Compliant=true |
En outre, pour les pilotes de type 2, les variables ORACLE_HOME et LD_LIBRARY_PATH (qui doivent inclure $ORACLE_HOME/lib) doivent toutes les deux être définies dans un environnement dans lequel serveur d'application est exécuté. Vous pouvez, par exemple, les ajouter au fichier asenv.conf et vous assurer qu'elles sont bien exportées.
Un grand nombre d'applications utilisent le serveur de base de données PointBase fourni avec serveur d'application. Si vous utilisez serveur d'application Enterprise Edition, vous devez au préalable configurer le serveur de base de données PointBase.
Vous pouvez configurer PointBase de deux manières:
À l'aide de la commande correspondant à votre système d'exploitation et à votre shell, définissez la variable d'environnement JAVA_HOME dans le répertoire dans lequel J2SE est installé. Par exemple : % setenv JAVA_HOME "/opt/SUNWappserver/jdk"
Modifiez le fichier de configuration PointBase d'Application Server comme suit :
Sous les systèmes Solaris et Linux, modifiez le fichier de configuration install_dir/pointbase/tools/serveroption/pbenv.conf, en remplaçant la ligne :
PB_JAVA=%%%PB_JAVA%%%
par
PB_JAVA=J2SE_location
Sous les systèmes Windows, modifiez le fichier de configuration install_dir\pointbase\tools\serveroption\pbenv.bat en remplaçant la ligne :
PB_JAVA=%%%PB_JAVA%%%
par
PB_JAVA=J2SE_location
où J2SE_location correspond au répertoire dans lequel J2SE est installé. Si vous avez installé J2SE avec Application Server, il est installé par défaut sous install_dir/jdk.
Une fois la modification effectuée, lancez PointBase à l'aide du script startserver.
Cette section répertorie les serveurs Web pris en charge par Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2.
Tableau 2–3 Serveurs Web pris en charge
Web Server |
Version |
Système d'exploitation |
---|---|---|
Sun Java System Web Server |
6.1+ |
Solaris SPARC8, 9, 10 Solaris x86 9, 10 Red Hat Enterprise Linux2.1 Update 2, 3.0 Update 1 |
Serveur Web Apache |
1.3+, 1.4, 2.0 |
Solaris SPARC 9, 10 Solaris x86 10 Red Hat Enterprise Linux2.1 Update 2, 3.0 Update 1 Windows Server 2003 Windows 2000 Advanced Server SP4+ Windows Server 2000 SP4+ Windows XP Pro SP1+ |
Microsoft IISTM |
5.0+ |
Windows Server 2003 Windows 2000 Advanced Server SP4+ Windows Server 2000 SP4+ Windows XP Pro SP1+ |
Cette section répertorie les navigateurs pris en charge par Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2.
Tableau 2–4 Navigateurs Web pris en charge
Navigateur |
Version |
---|---|
Mozilla |
1.4, 1.5, 1.6, 1.7.x |
Netscape Navigator |
4.79, 6.2, 7.0 |
Internet Explorer |
5.5 Service Pack2, 6.0 |
Outre la configuration indiquée dans la section Configurations matérielle et logicielle requises, vous devez vérifier que le système est conforme aux exigences ci-dessous pour pouvoir exécuter HADB.
Configuration requise au niveau de l'hôte pour le serveur HADB
Configuration requise au niveau de l'hôte pour la gestion HADB
Configuration requise au niveau de l'hôte pour le client HADB
Les composants Java du système ont été créés avec JDK 1.4.2_02 et testés sur JDK 1.5.
Solaris (SPARC) – Solaris 8 MU7, Solaris 9 MU7, Solaris 10 RR.
Solaris (x86) – Solaris 9 MU7, Solaris 10 RR.
RedHat Enterprise Linux - 2.1 U5 (seul le système de fichiers ext2 est pris en charge, non ext3), 3.0 U4 (ext2 et ext3 sont pris en charge. Les mises à jour antérieures à U4 ne sont pas recommandées en raison d'un swapping excessif). Notez que HADB est testé sur ces versions de système d'exploitation en mode 32 bits uniquement. Par ailleurs, HADB ne prend pas en charge la version RedHat Enterprise Linux 3.0 exécutée en mode 64 bits, en raison d'un bogue au niveau du système d'exploitation (voir le problème connu 6249685 dans la section Haute disponibilité pour obtenir plus de détails sur l'incidence de ce bogue sur HADB).
Microsoft Windows – Microsoft Windows 2000 Advanced Server Service Pack 4 et Microsoft Windows 2003 Enterprise Edition. Notez que HADB ne prend en charge aucune des versions ultérieures de Microsoft Windows en mode 64 bits.
Mémoire minimum : 320 Mo par nœud.
Espace minimum disponible sur le disque : 70 Mo par hôte pour les binaires HADB. En outre, un espace disque doit être dédié aux périphériques de données, à savoir 512 Mo par nœud pour une installation test.
Mémoire recommandée : 512 Mo par nœud.
Espace disque recommandé : 70 Mo par hôte pour les binaires HADB. En outre, un espace disque doit être dédié aux périphériques de données, à savoir 1200 Mo par nœud pour une installation test.
Vérifiez que l'écriture en cache est désactivée sur les périphériques sur lesquels des données HADB et des fichiers journaux sont stockés. L'écriture en cache est activée par défaut sur certaines plates-formes Solaris, Solaris x86 par exemple.
Mémoire minimum : 128 Mo
Espace disque minimum : 70 Mo par nœud pour les binaires HADB.
Mémoire minimum : 120 Mo
Espace disque minimum : 20 Mo
La mise à niveau sur place à partir d'une version antérieure d'Application Server n'est pas prise en charge. Reportez-vous au manuel serveur d'application Environment Enterprise Upgrade and Migration Guide pour obtenir des instructions complètes sur la mise à niveau à partir d'une version précédente d'serveur d'application vers la version actuelle.
Si vous souhaitez utiliser PointBase avec serveur d'application, téléchargez J2SE 1.4.2 et utilisez-le à la place de la version J2SE 5.0 JVM fournie. Pour ce faire, suivez la procédure ci-dessous :
Téléchargez le kit SDK J2SE 1.4.2 (et non JRE) et installez-le sur votre système si ce n'est pas déjà fait.
Le kit SDK J2SE 1.4.2 est disponible à l'adresse http://java.sun.com/j2se/1.4.2/.
Arrêtez serveur d'application.
À partir de la ligne de commande :
install_dir/bin/asadmin stop-domain |
À partir de la console d'administration :
Modifiez le fichier install_dir/config/asenv.conf (asenv.bat sous Windows), en remplaçant la valeur AS_JAVA de sorte qu'elle désigne le répertoire de base de J2SE 1.4.2.
Modifiez le fichier as-install/samples/common.properties, en remplaçant la ligne commençant par com.sun.aas.javaRoot... de sorte qu'elle désigne le répertoire de base de J2SE 1.4.2.
Redémarrez serveur d'application.
À partir de la ligne de commande :
install_dir/bin/asadmin start-domain |
À partir de la console d'administration :
Avant d'installer le logiciel Sun Java System serveur d'application, vous devez également veiller à ce que les autres exigences ci-dessous soient satisfaites.
Espace libre : le répertoire temporaire doit disposer d'au moins 35 Mo d'espace libre pour l'installation de Sun Java System serveur d'application et 250 Mo pour l'installation du kit SDK.
Utilisation du programme de désinstallation : si vous devez supprimer serveur d'application du système, veillez à utiliser le programme de désinstallation fourni avec le logiciel. Si vous utilisez une autre méthode, des problèmes peuvent de se produire lors de la réinstallation de cette version ou de l'installation d'une nouvelle version.
Ports disponibles : vous devez disposer de sept ports non utilisés et disponibles.
Le programme d'installation détecte automatiquement les ports utilisés et propose des ports non utilisés comme paramètres par défaut. Par défaut, il s'agit des ports 8080 pour HTTP, 8181 pour HTTPS et 4849 pour Administration Server.
Le programme d'installation détecte les ports utilisés et vous en attribue deux autres : Sun Java System Message Queue (par défaut, 7676) et IIOP (par défaut, 3700 pour IIOP et 1060 et 1061 pour IIOP/SSL). Si ces numéros de ports par défaut sont déjà utilisés, le programme d'installation attribue un numéro de port aléatoire à partir de la plage de ports dynamiques (notez qu'il se peut que ce ne soit pas le prochain numéro de port disponible).
Démarrage de serveurs déjà installés (UNIX) : à moins que vous ne remplaciez le serveur précédemment installé, vous devez le démarrer avant d'entamer la procédure d'installation de Sun Java System serveur d'application 8.1. Le programme d'installation sera ainsi en mesure de détecter les ports utilisés et évitera de les affecter à d'autres utilisations.
Remplacement de serveurs déjà installés (UNIX) : si vous souhaitez remplacer une ancienne version de Sun Java System serveur d'application par cette version d'serveur d'application, vous devez l'arrêter avant de procéder à l'installation du nouveau serveur. Utilisez l'assistant de mise à niveau du programme d'installation pour mettre le serveur à niveau.
Arrêt du pare-feu (Microsoft Windows) : vous devez arrêter votre pare-feu avant d'installer le logiciel Sun Java System serveur d'application. À défaut, tous les ports par défaut risquent d'être désactivés. Le programme d'installation doit être capable de déterminer, avec précision, les ports qui sont disponibles.
Pour de plus amples informations de compatibilité, reportez-vous au manuel Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Upgrade and Migration Guide .
Cette section répertorie les problèmes soulevés par les utilisateurs et résolus dans la version Environment Enterprise 8.1 de Sun Java System serveur d'application.
Numéro de bogue |
Description |
---|---|
4887079 |
API de programmation pour le déploiement/l'annulation du déploiement et la recherche des applications déployées. |
4911462 |
Message incorrect lorsque le port dépasse la plage disponible. |
4918535 |
sun-appserv-deploy() ne prend pas en charge createAndDropTables() |
4939749 |
xml:()la valeur lang() ne doit pas être insérée automatiquement dans l'outil de déploiement. |
4946914 |
Prise en charge du déploiement pour le cluster. |
4979136 |
Lorsque le déploiement est effectué à partir du répertoire, l'application est copiée dans un répertoire de sauvegarde. |
4987274 |
Le déploiement échoue si l'interface distante pour le bean est appelée Util(). |
4988818 |
Échec des tests d'exécution de persistance transparente lors de l'utilisation de J2SE 1.5. |
4992295 |
Déploiement réussi d'un composant système sur l'interface de la ligne de commande, mais une erreur est consignée dans le fichier journal du serveur. |
4994790 |
Les pages JSP déployées avec le paramètre precompilejsp=true n'utilisent pas les indicateurs du compilateur de sun-web.xml. |
4996876 |
Comparaison entre le vérificateur et le déploiement avec le paramètre verify=true ; rapports générés différents. |
5003356 |
Les mises à jour récentes du fichier server.policy ne sont pas prises en compte par l'outil de mise à niveau. |
5006854 |
Échec du déploiement de asadmin deploy --virtualservers |
5007309 |
La valeur par défaut des threads de l'accepteur du listener HTTP est inappropriée. |
5008941 |
Échec de l'opération de démarrage de JSR88 lorsqu'une application dont le déploiement a été annulé fait l'objet d'un redéploiement. |
5016848 |
Sous Windows, la mise en cache du fichier JAR du JDK et la présence de fichiers non fermés empêchent certains redéploiements. |
5017956 |
La commande list -m au niveau du module JAR ne répertorie pas les EJB. |
5030425 |
La commande deploydir ignore les modifications security-role-mapping. |
5041343 |
Vérification non effectuée du renvoi à la ligne marqué par une barre oblique (/) de servlet-mapping url-pattern- -directory. |
5046120 |
GRAVES messages de journaux lors du déploiement d'applications volumineuses. |
6041268 |
Aucun mécanisme pour désactiver HTTP TRACE. |
6062410 |
L'outil de mise à niveau se lance en anglais sur un ordinateur fonctionnant sous un autre environnement linguistique. |
6067341 |
Échec de la commande deploydir sur une application Web avec ejb-refs sur les interfaces distantes rmic. |
6152752 |
Exception outofbound consignée lors de l'exécution d'une série de tests SPEC J2004. |
6154949 |
La validation de la connexion ne fonctionne pas. |
6157310 |
L'exécution recharge le champ Collection lors de la gestion des relations. |
6165491 |
Échec du démarrage d'un domaine si ce dernier a été créé avec un autre chemin que celui du domaine par défaut. |
6171667 |
Les éléments des propriétés de modules du cycle de vie ne sont pas créés dans domain.xml. |
6171729 |
Les propriétés RA ActivationSpec de type autre que chaîne provoquent une exception IllegalArgumentException lors du déploiement d'un MDB. |
6172178 |
Échec de l'obtention par OSS/J TT TCK de la fabrique de connexion JMS à partir d'un serveur d'application distant. |
6172589 |
Optimisation des appels au gestionnaire de sécurité. |
6183492 |
[DataDirect] DB2 : Échec de certains tests de serveurs d'applications de persistance transparente avec l'exception générée lors de l'invocation EJB. |
6184864 |
La requête EJB QL n'a renvoyé aucun résultat avec l'opérateur OU et l'expression contient des CMR à une seule valeur nulle. |
6197393 |
En règle générale, l'outil de déploiement ne parvient pas à créer l'élément de destination du message dans le descripteur de déploiement. |
6198796 |
Les commandes asadmin des exemples EE doivent inclure l'option availabilityenabled=true () lors du déploiement de l'application. |
6198981 |
Du fait de l'absence du fichier xalan.jar dans le classpath, les listes déroulantes sont vides et l'assistant de service Web ne fonctionne pas. |
6199076 |
Impossible d'exécuter le test de basculement avec le script asant pour l'exemple de la librairie Duke. |
6202363 |
L'exemple d'application mq-failover possède un nom de cluster codé en dur dans une cible ant. |
6202606 |
Impossible d'utiliser la configuration de service JMS pour SSL JMS entre JMS et Message Queue. |
6206176 |
Application Server 8.1 requiert des commandes startserv/stopserv qu'elles disposent des autorisations 755. |
6207297 |
Échec de l'accès à Application Server si le numéro de port SSL par défaut (443) n'est pas défini. |
6207862 |
La commande asadmin create-domain --help génère des données incorrectes. |
Cette section répertorie les problèmes rencontrés par des utilisateurs et résolus dans Sun Java System serveur d'applicationEnvironment Enterprise 8.12005Q2Update 2.
Numéro de bogue |
Description |
---|---|
4842830 |
L'exception “ComStream is closed” est envoyée au client JDBC. |
4847716 |
Il est conseillé de ne pas utiliser la commande execute/executeUpdate pour définir le mode de validation, car cela risquerait d'entraîner un comportement non souhaité. Utilisez la commande JDBC standard setAutocommit(). |
4861326 |
Le pool d'instructions ne reconnaît pas l'instruction CREATE SCHEMA comme une instruction SET SCHEMA implicite. |
4891060 |
Les listeners ignorent la directive d'adresse lors de l'écoute des sockets. |
5042351 |
Les nouvelles tables créées après l'ajout de nouveaux nœuds ne sont pas distribuées dans ces derniers. |
5061316 |
Les requêtes effectuées dans une table faisant l'objet d'une refragmentation risquent d'échouer avec HADB-E-01792 : Les répliques ont été supprimées. La requête doit être renouvelée. |
5063175 |
La commande hadbm create doit générer une erreur lors de l'utilisation d'un hôte avec un/plusieurs réseaux. |
5079029 |
L'annulation de l'enregistrement d'un package sur un seul hôte risque d'échouer avec l'erreur "The software package is in use by a database instance and can not be removed". |
5094611 |
Les opérations de gestion nécessitant l'ouverture d'une transaction d'écriture dans le référentiel d'administration peuvent, à de rares occasions, attendre indéfiniment l'ouverture de ladite transaction. |
5103186 |
Impossible de démarrer NSUP lorsqu'un réseau ne fonctionne plus sous Windows 2003. |
6225613 | |
6271063 |
L'installation ou la suppression du package HADB c (Solaris : SUNWhadbc, Linux : sun-hadb-c) version symlink /opt/SUNWhadb/ génère une erreur. |
6174781 |
La commande hadbm status – nodes risque d'indiquer que tous les nœuds sont dotés du statut nodestate inconnu pendant une courte période après le redémarrage des agents de gestion. |
6175436 |
Si la commande hadbm addnodes ou hadbm refragment échoue avec l'erreur HADB-E-11747 : "Nodegroup all_nodes exists already", exécutez de nouveau la commande hadbm refragment. |
61746766179084 |
Impossible d'exécuter la commande configure-ha-cluster. |
6178228 6179010 |
Échec de la commande configure-ha-cluster |
6181845 |
Impossible de créer un périphérique de données d'un volume supérieur à 2 Go sous Windows. |
6189189 |
La commande export-http-lb-config ne crée pas le nom de fichier loadbalancer.xml lorsque le chemin absolu est indiqué. |
6198225 |
Le guide de démarrage rapide (QuickStart Guide) comporte une erreur (phrase répétée). |
6195779 |
Les valeurs des options de certaines listes déroulantes du filtre ne sont pas traduites. |
6196741 |
La mise à niveau à partir d'un composant J2SE fourni ne fonctionne pas correctement lorsqu'il s'agit de J2SE 1.4.x. |
6207616 |
Si un hôte est défaillant, une commande hadbm risque de rester bloquée plusieurs minutes si elle doit se connecter à l'agent de gestion. |
6212791 |
Aucun élément ne s'affiche dans le volet droit lors de la sélection d'un nœud de l'arborescence. |
6216096 |
Un blocage risque d'entraîner une défaillance au niveau du nœud, car la mémoire tampon du journal risque d'être pleine et un grand nombre de transactions annulées. |
6225613 |
Taille de l'objet LOB incorrecte dans executeUpdate() |
6227502 |
Les erreurs d'initialisation du service du minuteur EJB ne devraient pas être classées comme graves. |
6228789 |
Échec de la commande hadbm delete. |
6230415 |
HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
6230792 |
hadbm :erreur 22009 : The command issued had no progress in the last 300 seconds. |
6232347 |
La commande dropandcreatetables n'est pas correcte pour la commande asdamin deploy --help. |
6232838 |
Des appels de journal non nécessaires nuisent aux capacités d'extensibilité du serveur d'application. |
6232974 |
Le programme d'installation n'a pas pu créer un agent de nœud lors de la mise à niveau de la version 8.0 Platform Edition vers 8.1 Enterprise Edition. |
6233142 |
L'installation ou la désinstallation de HADB doit toujours préserver le lien symbolique /opt/SUNWhadb/4, mais cela n'a pas toujours été le cas. |
6233276 |
L'autorisation de formulaire ne fonctionne pas pour URL-pattern -*.jsp. |
6233469 |
Texte d'aide incorrect pour la commande asadmin help. |
6233476 |
Texte d'aide incorrect pour la commande update-file-user et les commandes similaires. |
6237567 |
Clé adminObjectStep2PageHelp manquante dans la fenêtre de la ressource d'objet de création d'administration. |
6238477 |
Impossible de résoudre les références EJB au service de nom Corba dans une même instance du serveur d'application. |
6239630 |
Impossible de mapper correctement un bean entité particulier. |
6239837 |
Unité et valeur par défaut incorrectes pour l'intervalle de reconnexion dans le nœud server-config JMS. |
6240661 |
Certains messages apparaissent en anglais dans la version localisée. |
6241311 |
La note relative au champ Délai d'inactivité du pool est incorrecte. |
6241368 |
L'écran de connexion de la console d'administration et l'aide en ligne ne font jamais référence à l'anglais comme langue du navigateur. |
6243395 |
La récupération de transaction ne fonctionne pas avec des ressources JMS et JDBC. |
6245922 |
Application Server tombe régulièrement en panne. |
6246426 |
L'extension des fichiers JAR dans le répertoire WEB-INF/lib fait apparaître un contenu qui devrait être masqué. |
6249637 |
La modification des propriétés du pool de connexion JDBC requiert un redémarrage. |
6249662 |
Le format de la commande Proxy-auth-cert est incorrect. |
6250989 |
Élément SOAP.La commande addChildElement ajoute un élément incomplet sans marque. |
6252187 |
La connexion unique du système de haute disponibilité propage les Principals entre différents domaines. |
6252810 |
La commande configure-ha-persistence n'est pas à jour dans les pages de manuel. |
6253735 |
QuickStart ne comprend pas les informations de haute disponibilité. |
6254393 |
La version QuickStart intégrée renvoie vers des notes de version anciennes. |
6254462 |
Une exception NPE a été levée par le code de validation de la connexion après le redémarrage de la base de données. |
6255253 |
Le lien Comment acheter figurant dans la documentation renvoie à une URL incorrecte. |
6255440 |
Amélioration des performances en vue de la synchronisation. |
6255458 |
Erreur de typographie dans la commande delete-virtual-server. |
6255524 |
La tâche ANT UpdateTask ne fonctionne pas avec ANT 1.6.2. |
6255564 |
Échec du démarrage du domaine mis à niveau en raison de l'échec d'authentification de l'administrateur après la mise à niveau de la version Platform Edition vers Enterprise Edition. |
6258844 |
La connexion utilisateur du domaine de fichiers ne fonctionne plus après la mise à niveau vers 8.1 Update 1. |
6258997 |
Description correcte de l'option --secure dans les pages de manuel de l'interface de ligne de commande. |
6259125 |
La documentation relative à la commande asadmin get est inadéquate et confuse. |
6262564 |
La classe PrivateKeyProcessor ne prend pas en charge l'utilisation de la méthode Get pour l'objet keyIdentifier. |
6262824 |
Solaris10 : L'arrêt d'un agent de gestion par le biais du script ma-initd dans une zone globale provoque également l'arrêt de l'agent de gestion dans la zone locale. |
6263684 |
Le script de génération du patch pour Linux RPM requiert des modifications manuelles dans le fichier README. |
6263686 |
La génération de patch pour svr4 entraîne l'insertion d'entrées incorrectes dans le fichier README. |
Le script package-appclient est endommagé. |
|
6264969 |
Échec de la configuration de tous les exemples d'Application Server utilisant PointBase : Impossible de mettre à niveau la base de données vers la version 5.1. |
6265687 |
L'image graphique du programme d'installation présente une version de produit incorrecte. |
6266183 |
Échec du test de la fonction de haute disponibilité : Le nom de domaine après redémarrage contient une valeur nulle. |
6267410 |
Une exception se produit avec session.invalidate() si le niveau du journal est paramétré sur FIN. |
Cette section présente d'autres informations importantes sur l'implémentation du système HADB dans serveur d'application 8.1.
Une nouvelle commande de gestion, hadbm setadminpassword, a été ajoutée afin de permettre la modification du mot de passe utilisé pour l'administration de la base de données. La commande comporte des options indiquant l'agent de gestion à utiliser ainsi que les ancien et nouveau mots de passe. Pour plus d'informations, reportez-vous à la page de manuel hadbm setadminpassword.
La commande de gestion hadbm listpackages a été modifiée. Avant, la commande ne prenait en charge aucun opérande et répertoriait tous les packages dans le domaine de gestion approprié. À présent, la commande dispose d'un opérande de nom de package optionnel et répertorie uniquement les packages dotés de ce nom. Si l'opérande n'est pas indiqué, tous les packages sont répertoriés. Pour plus d'informations, reportez-vous à la page de manuel hadbm listpackages.
La commande de gestion hadbm createdomain a été modifiée. L'opérande hostlist est étendu de manière à préciser également le numéro de port de l'agent de gestion. Ainsi, le domaine peut être entièrement spécifié en utilisant uniquement l'opérande hostlist. L'ancien comportement est toujours pris en charge dans le cadre de la compatibilité ascendante. Pour plus d'informations, reportez-vous à la page de manuel relative à la commande hadbm createdomain.
Certains des messages d'erreur du système de gestion ont été modifiés. Ces modifications ont été apportées pour améliorer la compréhension, la cohérence et la précision de ces messages. Les modifications effectuées ne sont pas répertoriées dans ces notes de version.
Les procédures d'installation et de désinstallation ont été légèrement modifiées. Normalement, le lien symbolique /opt/SUNWhadb/4 devrait être préservé lors de l'installation ou de la désinstallation de HADB, mais ce n'est pas toujours le cas :
Il n'est plus possible de saisir des mots de passe sur la ligne de commande sous la forme d'options de commande. Cette modification concerne toutes les commandes hadbm prenant en charge la saisie de mots de passe comme options de ligne de commande. Dans les commandes hadbm, il était jusqu'alors possible d'entrer un mot de passe via :
un fichier de mot de passe ;
une option de ligne de commande ;
une entrée interactive.
La deuxième méthode (l'option de ligne de commande), considérée comme dangereuse en termes de sécurité, n'est plus autorisée. Un message d'avertissement apparaît si un mot de passe est saisi de cette manière. Il est recommandé d'utiliser la première ou la troisième méthode. L'utilisation d'un mot de passe sur la ligne de commande deviendra impossible dans la prochaine version. Notez que cette modification s'applique à toutes les commandes hadbm prenant en charge l'option de mot de passe.
Le système HADB a été mis à niveau de manière à prendre en charge JGroups version 2.2. Son code source est distribué avec HADB. Pour prendre en charge les mises à niveau à partir d'une version antérieure de HADB, les deux versions JGroups 2.1 et 2.2 sont fournies avec HADB. Pour JGroups 2.1, seul le code octet est fourni.
Plusieurs considérations importantes doivent être prises en compte si vous souhaitez configurer HADB de manière à utiliser l'un des systèmes de fichiers suivants :
ext2 et ext3 : HADB prend en charge les systèmes de fichiers ext2 et ext3 sous Red Hat Application Server 3.0. Sous Red Hat Application Server 2.1, seul le système ext2 est pris en charge.
Veritas : lorsque le système de fichiers Veritas est utilisé sur la plate-forme Solaris, le message “WRN: Direct disk I/O mapping failed“ est consigné dans les fichiers de l'historique. Ce message indique que le système HADB ne parvient pas à activer la fonction d'E/S directe pour les unités de données et de journaux. La fonction d'E/S directe permet de réduire le traitement nécessaire à l'écriture des pages de disque et, par voie de conséquence, d'améliorer les performances du processeur. En outre, elle réduit le temps système consacré à la gestion des pages de données corrompues dans le système d'exploitation.
Pour utiliser la fonction d'E/S directe avec le système de fichiers Veritas, procédez de l'une des manières suivantes:
Créez des unités de données et de journaux sur un système de fichiers monté avec l'option mincache=direct. Cette option s'applique à l'ensemble des fichiers créés sur le système de fichiers. Reportez-vous à la commande mount_vxfs(1M) pour obtenir plus de détails.
Utilisez la fonction Quick I/O de Veritas pour effectuer une E/S brute sur les fichiers du système de fichiers. Reportez-vous au Guide d'administration de VERITAS File System 4.0 pour Solaris pour obtenir plus de détails.
Notez que ces configurations n'ont pas été testées avec serveur d'application 8.1 2005Q2 Update 2.
Reportez-vous au Guide d'administration de la haute disponibilité d'serveur d'application Environment Enterprise pour obtenir des informations sur l'installation et la configuration de HADB avec le logiciel serveur d'application.
Migration de données et tâches antérieures à la mise à niveau
Informations spéciales relatives au déploiement et à la mise à niveau
Les utilisateurs doivent conserver les fichiers de l'historique HADB, les fichiers de configuration de l'agent de gestion, les fichiers journaux et le référentiel, ainsi que toutes les unités de données en dehors du chemin d'installation. Si cela n'a pas déjà été fait, il est nécessaire d'y remédier avant de procéder à la mise à niveau. Pour déplacer le référentiel de gestion et les fichiers de configuration :
Arrêtez tous les anciens agents de gestion et maintenez les nœuds HADB en cours d'exécution.
Sur chaque hôte, déplacez le référentiel vers le nouvel emplacement.
Sur chaque hôte, copiez le répertoire dbconfig au nouvel emplacement.
Sur chaque hôte, mettez à jour le fichier mgt.cfg et définissez le chemin approprié pour dbconfig et le référentiel.
Lancez les agents de gestion via le fichier mgt.cfg mis à jour.
Pour effectuer la mise à niveau de HADB version 4.4.x vers 4.4.2-7, suivez la procédure ci-dessous :
Si nécessaire, effectuez les tâches antérieures à la mise à niveau mentionnées ci-dessus.
Installez HADB version 4.4.2-7 sur tous les hôtes HADB (sous un autre chemin que celui utilisé pour la version 4.4.x, par exemple sous /opt/SUNWhadb/4.4.2-7).
Installez HADB 4.4.2-7 sur les hôtes client de hadbm, s'ils diffèrent des hôtes HADB.
Arrêtez tous les agents de gestion exécutés sur tous les hôtes HADB.
Démarrez les processus d'agent de gestion à l'aide de la nouvelle version du logiciel, mais en utilisant les anciens fichiers de configuration. Pour les étapes suivantes, utilisez la commande hadbm disponible à partir du répertoire bin de la nouvelle version.
Enregistrez le package dans le domaine de gestion (étant donné que le nom de package par défaut devient V4.4, vous devrez probablement fournir un autre nom pour éviter des conflits avec des packages existants dotés du même nom) :
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7 |
Exécutez la commande hadbm listpackages, puis vérifiez que le nouveau package est enregistré dans le domaine.
Redémarrez la base de données avec la nouvelle version hadbm 4.4.2-7. S'il est nécessaire de déplacer les unités et les fichiers d'historique, exécutez la mise à niveau en ligne tout en définissant de nouveaux chemins pour ces unités et fichiers d'historique, en une seule opération :
hadbm set packagename=V4.4.2-7,devicepath=new_devpath, historypath=new_histpath |
Si les unités et les fichiers de l'historique sont déjà situés en dehors du répertoire d'installation, exécutez la commande ci-dessous, de manière à effectuer uniquement un redémarrage progressif des nœuds :
hadbm set packagename=V4.4.2-7 database name |
Vérifiez que la base de données est en cours d'exécution (à l'aide de la commande hadbm status) et qu'elle fonctionne normalement, en servant les transactions du client.
Si tout fonctionne correctement, vous pourrez supprimer l'ancienne installation ultérieurement. Avant d'annuler l'enregistrement de l'ancien package, supprimez toutes les références à l'ancien package dans le référentiel ma. À défaut, la commande hadbm unregisterpackage échouera, en indiquant le message “package en cours d'utilisation.”Une opération de reconfiguration fictive, par exemple hadbm set connectiontrace=same as previous value, supprimera toutes les références à l'ancien package. Maintenant, annulez l'enregistrement de l'ancien package :
hadbm unregisterpackage [--hosts=host-list] old pacakge name |
Supprimez l'ancienne installation du système de fichiers.
Sous Solaris, testez la mise à niveau en vérifiant qu'elle a été correctement effectuée :
Vérifiez que les processus en cours d'exécution utilisent les nouveaux binaires. À tous les nœuds HADB, vérifiez les éléments ci-dessous :
new path/bin/ma -v new path/bin/hadbm -v |
Vérifiez si la base de données est en cours d'exécution. La commande ci-dessous doit indiquer que tous les nœuds HADB présentent un statut “en cours”.
new path/bin/hadbm status -n |
Vérifiez que les pointeurs des produits utilisant HADB ont été modifiés de manière à renvoyer vers le nouveau chemin HADB.
Vous pouvez exécuter les tests de mise à niveau des produits utilisant HADB pour vérifier le bon fonctionnement de la mise à niveau de HADB.
Après une mise à niveau en ligne, si la nouvelle version ne fonctionne pas correctement, revenez à l'ancienne version de HADB. Toutefois, si le référentiel de l'agent de gestion a été modifié, vous pouvez rétablir la base de données HADB à un niveau inférieur, mais le nouvel agent de gestion doit rester en cours d'exécution.
Cette section présente des informations supplémentaires sur le déploiement et la mise à niveau de HADB.
Stockez l'unité, le journal et les fichiers de l'historique sur des disques locaux uniquement. N'utilisez pas de fichiers système montés à distance.
Si plusieurs nœuds sont placés sur un hôte, il est recommandé de placer les périphériques appartenant à chaque nœud sur des disques différents. À défaut, les éventuels conflits de disque réduiront les performances. Les signes de ce problème sont indiqués dans les fichiers de l'historique par des messages comme BEWARE - last flush/fputs took too long. Lorsqu'un seul nœud comporte plusieurs fichiers de périphérique de données, il est recommandé d'utiliser des disques séparés.
Utilisez des disques locaux (de préférence des disques distincts de celui utilisé pour les périphériques de données) pour installer les binaires HADB sur les hôtes HADB. Des retards NFS ou un conflit de disque peuvent entraîner le redémarrage du nœud avec l'avertissement : "Processus bloqué pournnn, durée de blocage max. de nnn" dans les fichiers de l'historique.
Ne placez pas les périphériques HADB, les fichiers de l'historique, les répertoires et les fichiers de configuration de l'agent de gestion sous le chemin d'accès au package HADB. À défaut, vous rencontrerez des problèmes lors de mises à niveau vers des versions plus récentes et lors de la suppression de l'ancien chemin du package.
La version de HADB est officiellement prise en charge pour un maximum de 28 nœuds (24 actifs et 4 disponibles).
Nous vous recommandons d'utiliser la même version pour le pilote JDBC et le serveur HADB.
Le protocole IPv6 n'est pas pris en charge, seul IPv4 l'est.
La longueur des lignes de commande est limitée à 2048 octets sous Windows.
Le réseau doit être configuré pour une multidiffusion UDP.
En raison d'un swapping excessif observé dans RedHat Enterprise Linux 3.0, updates 1 à 3, nous ne le recommandons pas comme plate-forme de déploiement. Le problème est résolu dans la version RedHat Enterprise Linux 3.0 update 4.
Possibilité d'exécution du superviseur de nœud NSUP avec la priorité au temps réel :
Les processus du superviseur de nœud (NSUP), clu_nsup_srv, garantissent la haute disponibilité de la base de données HADB par le biais de messages de “pulsation” échangés en temps voulu. Les délais sont affectés lorsqu'un NSUP est hébergé au même emplacement que d'autres processus, générant ainsi des insuffisances de ressource. Il en résulte des partitions de réseau erronées et des redémarrages de nœud (précédés de l'avertissement “Processus bloqué pendant n secondes” dans les fichiers de l'historique) entraînant des abandons de transactions et autres exceptions.
Pour résoudre ce problème, le superviseur de nœud clu_nsup_srv (trouvé sous installpath/lib/server) doit comporter le bit suid et le fichier doit appartenir à l'utilisateur root. Pour ce faire, procédez manuellement à l'aide des commandes :
# chown root clu_nsup_srv # chmod u+s clu_nsup_srv |
Le processus clu_nsup_srv est alors exécuté en tant qu'utilisateur root lors de son démarrage, ce qui lui permet d'obtenir automatiquement la priorité en temps réel après le démarrage. Pour éviter toute incidence sur la sécurité lors de l'utilisation de setuid, la priorité en temps réel est définie au tout début du processus et ce dernier reprend l'ID utilisateur réel une fois la priorité modifiée. D'autres processus HADB réduisent leur priorité au niveau de partage du temps.
Si le superviseur NSUP n'a pas pu définir la priorité de temps réel, il émet un avertissement, “Impossible de définir la priorité de temps réel” (unix: errno will be set to EPERM), consigné dans le fichier ma.log et se poursuit sans la priorité de temps réel.
Dans certains cas, il est impossible de définir des priorités de temps réel, notamment :
lors d'une installation dans des zones non globales de Solaris 10 ;
lors de la révocation des privilèges PRIV_PROC_LOCK_MEMORY (autoriser un processus à verrouiller des pages dans la mémoire physique) et/ou PRIV_PROC_PRIOCNTL sous Solaris 10 ;
lorsque les utilisateurs désactivent l'autorisation setuid ;
lorsque les utilisateurs installent le logiciel en tant que fichiers .tar (option d'installation non root pour App.server).
Le processus clu_nsup_srv n'utilise pas beaucoup de ressources processeur, son empreinte est petite et son exécution avec une priorité de temps réel n'a aucune incidence sur les performances.
Configuration du multiacheminement sur réseau IP (IPMP) pour HADB pour Solaris (testé sur Solaris 9 uniquement) :
Sun recommande de configurer le multiacheminement sur réseau IP sur les systèmes Solaris hébergeant des bases de données HADB, afin de garantir une disponibilité maximale du réseau. La procédure est expliquée en détail dans le Guide d'administration du multiacheminement sur réseau IP. Si vous décidez d'utiliser le multiacheminement avec HADB, reportez-vous à la section relative à l'administration du multiacheminement sur réseau du Guide d'administration du multiacheminement sur réseau IP afin de procéder à la configuration du multiacheminement, étape requise pour ensuite adapter cette configuration à HADB comme décrit ci-dessous. Le Guide d'administration du multiacheminement sur réseau IP fait partie de la documentation concernant l'administrateur système de Solaris 9. Vous pouvez la télécharger à partir de l'adresse http://docs.sun.com.
Définition du délai de détection des défaillances de l'interface réseau
Afin que HADB puisse correctement prendre en charge les défaillances relatives au multiacheminement, le délai de détection des défaillances de l'interface réseau ne doit pas dépasser les 1000 millisecondes comme indiqué dans le paramètre FAILURE_DETECTION_TIME sous /etc/default/mpathd. Modifiez le fichier et remplacez la valeur de ce paramètre par 1000si la valeur initiale est supérieure :
FAILURE_DETECTION_TIME=1000 |
Pour que la modification soit prise en compte, exécutez la commande ci-dessous :
pkill -HUP in.mpathd |
Adresses IP à utiliser avec HADB
Comme décrit dans le Guide d'administration du multiacheminement sur réseau IP Solaris, le multiacheminement implique le rassemblement d'interfaces réseau physiques en groupes d'interfaces multivoies. Chacune des interfaces physiques d'un groupe est associée à deux adresses IP : une adresse d'interface physique et une adresse test. Seule l'adresse d'interface physique peut être utilisée pour la transmission des données. L'adresse de test, quant à elle, est destinée uniquement à un usage interne à Solaris. Lors de l'exécution de la commande hadbm create --hosts, chaque hôte doit être spécifié avec une seule des adresses d'interface physique du groupe de multiacheminement.
Exemple
Supposons que les Hôte 1 et Hôte 2 disposent chacun de deux interfaces réseau physiques. Sur chaque hôte, ces deux interfaces sont configurées en tant que groupe de multiacheminement. L'exécution de la commande ifconfig -a génère le résultat suivant :
Hôte 1
bge0: flags=1000843<mtu 1500 index 5 inet 129.159.115.10 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 5 inet 129.159.115.11 netmask ffffff00 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 6 inet 129.159.115.12 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 6 inet 129.159.115.13 netmask ff000000 broadcast 129.159.115.255 |
Hôte 2
bge0: flags=1000843<mtu 1500 index 3 inet 129.159.115.20 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge0:1: flags=9040843<mtu 1500 index 3 inet 129.159.115.21 netmask ff000000 broadcast 129.159.115.255 bge1: flags=1000843<mtu 1500 index 4 inet 129.159.115.22 netmask ffffff00 broadcast 129.159.115.255 groupname mp0 bge1:1: flags=9040843<mtu 1500 index 4 inet 129.159.115.23 netmask ff000000 broadcast 129.159.115.255 |
Dans ce cas, les interfaces réseau physiques sur les deux hôtes sont celles répertoriées en tant que bge0 et bge1. Celles référencées par bge0:1 et bge1:1 sont des interfaces de test de multiacheminement (elles sont signalées comme étant désapprouvées dans ifconfig). Pour plus de détails, reportez-vous au Guide d'administration du multiacheminement sur réseau IP.
Pour configurer HADB dans cet environnement, sélectionnez une adresse d'interface physique au niveau de chaque hôte. Dans cet exemple, nous choisissons 129.159.115.10 sur l'hôte 1 et 129.159.115.20 sur l'hôte 2. Pour créer une base de données avec un nœud par hôte, utilisez l'argument suivant pour hadbm create :
--host 129.159.115.10,129.159.115.20 |
Pour créer une base de données avec deux nœuds de base de données sur chaque hôte, utilisez l'argument :
--host 129.159.115.10,129.159.115.20,129.159.115.10,129.159.115.20 |
Dans les deux cas, la variable ma.server.mainternal.interfaces doit être paramétrée sur 129.159.115.0/24 sur les deux hôtes.
Il est impossible d'effectuer une mise à niveau de 4.2 ou 4.3 vers 4.4 en ligne. En revanche, la version 4.4 prend en charge les mises à niveau en ligne vers les versions ultérieures. Pour effectuer une mise à niveau de 4.4.1 vers 4.4.2, suivez la procédure ci-dessous :
Installez 4.4.2 sur tous les hôtes HADB (sous un autre chemin que celui utilisé pour 4.4.1, par exemple sous /opt/SUNWhadb/4.4.2-6).
Installez la nouvelle version sur les hôtes hadbm client.
Arrêtez tous les agents de gestion exécutés sur les hôtes HADB.
Démarrez les processus d'agent de gestion à l'aide de la nouvelle version du logiciel, mais en utilisant les anciens fichiers de configuration. Pour les étapes suivantes, utilisez la commande hadbm disponible à partir du répertoire bin de la nouvelle version.
Enregistrez le package dans le domaine de gestion (étant donné que le nom de package par défaut devient V4.4, vous devrez probablement fournir un autre nom pour éviter des conflits avec des packages existants dotés du même nom) :
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-6 V4.4.2 |
Redémarrez la base de données avec la nouvelle version (la commande suivante lance un redémarrage progressif des nœuds) :
hadbm set packagename=V4.4.2 nom_base_de_données |
Vérifiez que la base de données est en cours d'exécution (à l'aide de la commande hadbm status) et qu'elle fonctionne normalement, en servant les transactions du client.
Si tout fonctionne correctement, vous pourrez supprimer l'ancienne installation ultérieurement.
Avant d'annuler l'enregistrement de l'ancien package, supprimez toutes les références à l'ancien package dans le référentiel ma. À défaut, la commande hadbm unregisterpackage échouera et affichera le message “package en cours d'utilisation”.Une opération de reconfiguration fictive, par exemple hadbm set connectiontrace=< same_as_previous_value>, supprimera toutes les références à l'ancien package. Maintenant, annulez l'enregistrement de l'ancien package :
hadbm unregisterpackage [--hosts=<liste_hôtes>] <nom_ancien_package> |
Supprimez l'ancienne installation du système de fichiers, en suivant les instructions d'installation de HADB à l'adresse .
Il est impossible de créer un index secondaire UNIQUE sur une table.
L'expression (DISTINCT column) n'est pas autorisée dans une expression d'agrégation , à moins qu'elle ne soit la seule expression sélectionnée.
Toutes les tables doivent être créées avec une clé primaire (les tables sans clé primaire ne sont pas prises en charge).
FULL OUTER JOIN n'est pas pris en charge.
Les sous-requêtes IN qui sont des sous-requêtes de table ne sont pas prises en charge ; par exemple :
SELECT SNAME FROM S WHERE (S1#,S2#) IN (SELECT S1#,S2# FROM SP WHERE P#='P2') |
Les contraintes autres que NOT NULL et PRIMARY KEY ne sont pas prises en charge.
Il est possible d'affecter un nouveau propriétaire à la ressource. Dans ce cas, cependant, les privilèges octroyés au propriétaire actuel ne sont pas accordés au nouveau propriétaire.
Deux sous-requêtes NOT EXISTS imbriquées où chaque sous-requête n'est pas (directement) corrélée au niveau externe des requêtes ne sont pas prises en charge.
Les privilèges de colonne ne sont pas pris en charge.
Les constructeurs de valeur de ligne sont autorisés uniquement dans une clause VALUES.
Les sous-requêtes ne sont pas acceptées comme expressions de valeur dans les constructeurs de valeur de ligne.
Les types de données ci-dessous ne peuvent pas être utilisés lors de la création de clés primaires :
REAL
FLOAT
DOUBLE PRECISION
DECIMAL
NUMERIC
Application Server inclut l'équilibrage de charge pour les clients HTTP, IIOP et JMS, la prise en charge du basculement de la session HTTP, la prise en charge du basculement et du clustering EJB, les services d'horloge EJB haute disponibilité, la récupération des transactions distribuées, la prise en charge des mises à niveau d'applications progressives, ainsi qu'une base de données haute disponibilité pour le stockage de l'état transitoire des applications J2EE.
La disponibilité assure le basculement des instances d'Application Server mises en cluster. Lorsqu'une panne est détectée, la session que supervisait le serveur non disponible est réaffectée à une autre instance d'Application Server. Les informations relatives à la session sont stockées dans la base de données HADB. Le système HADB prend en charge la persistance des sessions HTTP, des beans de session avec état et des références liées à la connexion unique.
Le produit serveur d'application est distribué sous diverses formes. Le tableau ci-dessous identifie les différentes versions du produit et les manières de se les procurer.
Version du produit Application Server |
Méthode de distribution |
---|---|
Composant serveur d'application Environment Enterprise de Sun Java Enterprise System. |
Distribution basée sur des fichiers Installation de patch requise via Sunsolve |
Produit autonome serveur d'applicationStandard et Environment Enterprise |
Distribution par fichiers et package |
Dans la prochaine version de Sun Java System serveur d'application Environment Enterprise , les incompatibilités suivantes seront introduites :
Bien que le service HTTP continue d'utiliser un cache DNS pour une meilleure performance, le contrôle du cache DNS n'est pas disponible.
La prise en charge de mise en cache de fichier HTTP sera remodelée, entraînant ainsi des changements de configuration et de contrôle.
Le format du suffixe de rotation du journal d'accès sera remplacé par le format pris en charge par les objets de date et d'heure, tel que spécifié à l'adresse http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html. La valeur par défaut de cette version, â%YYYY;%MM;%DD;-%hh;h%mm;m%ss;s ,â sera encore prise en charge mais d'autres variations également.
Les éléments, attributs et propriétés domain.xml, qui ne seront plus pris en charge seront signalés par des avertissements dans le journal du serveur et dans le fichier journal de mise à niveau comme n'étant plus autorisés.
Le nœud server.http-service.dns ne sera plus disponible dans la vue de contrôle.
Certains attributs du nœud server.http-service.file-cache peuvent être supprimés. Par conséquent, toute commande de contrôle asadmin visant à accéder à des attributs supprimés de ces nœuds échouera.
L'outil de déploiement ne sera plus disponible. La fonction équivalente est disponible dans l'IDE NetBeans. Pour plus d'informations et pour planifier une migration, consultez le didacticiel J2EE 1.4 pour NetBeans 4.1 à l'adresse http://www.netbeans.org/kb/41/j2ee-tut/index.html.
Le mode GUI du vérificateur (invoqué via verifier -u) ne sera plus disponible. La fonction équivalente sera disponible dans l'IDE NetBeans.
Le mode par défaut pour la vérification de l'application avec le vérificateur âVérifier des règles J2EEâ sera remplacé par âVérifier des règles J2EE et des règles de configuration de Sun Application Server.âEn d'autres termes, le vérificateur par défaut testera si une application répond aux règles J2EE et si elle est configurée pour être exécutée sur Sun Application Server. La commande du vérificateur comprendra un commutateur de ligne de commande afin de tester une application pour les règles J2EE uniquement.
Dans la version actuelle, les entrées JAR et de répertoire ajoutées aux attributs classpath-prefix, server-classpath et classpath-suffix du fichier domain.xml (fichier de configuration d'Application Server) sont disponibles dans le chemin de classe du système JVM. Une application dépendante de ce comportement peut utiliser les méthodes suivantes de la classe java.lang.ClassLoader pour accéder à des classes ou d'autres ressources à partir du chemin de classe du système JVM :
getSystemClassLoader()
getSystemResource()
getSystemResourceAsStream()
getSystemResources
Dans la prochaine version importante, les entrées JAR et de répertoire ajoutées aux attributs classpath-prefix, cserver-classpath et classpath-suffix ne seront plus disponibles dans le chemin de classe du système JVM. Si une application utilise l'une des méthodes indiquées ci-dessus, Sun recommande fortement d'utiliser une méthode équivalente n'impliquant pas la disponibilité des ressources dans le chemin de classe du système. Les méthodes équivalentes ne portant pas sur le chemin de classe du système JVM sont disponibles dans java.lang.ClassLoader et doivent être utilisées dans la mesure du possible. Par exemple :
java.net.URL url = ClassLoader.getSystemResource ("com/acme/tools/tools.properties");
java.net.URL url = this.getClass().getClassLoader().getResource ("com/acme/tools/tools.properties");
S'il n'est pas possible de modifier le code, vous pouvez alors choisir d'utiliser une nouvelle option de configuration qui sera ajoutée dans la version suivante afin de définir le chemin de classe du système JVM.
La sécurité de services Web peut être configurée à l'aide des fichiers wss-client-config.xml et wss-server-config.xml. Notez que le contenu et le nom de ces fichiers de configuration peut varier. La fonction équivalente sera toujours disponible.
Sun Java System serveur d'application Environment Enterprise 8.1 2005Q2 prend en charge la plate-forme J2EE 1.4. Le tableau ci-dessous présente une description des API disponibles sur la plate-forme J2EE 1.4 :
Tableau 2–5 API disponibles sur la plate-forme J2EE 1.4
API |
Description |
Composants |
|
Application et client d'application |
Implémentation des descripteurs de déploiement standard à l'aide de schémas XML |
Enterprise JavaBeans (EJB)2.1 |
Service d'horloge et extrémité du service Web EJB |
Java Servlet2.4 |
Filtre de l'extrémité du service Web |
Architecture de JavaServer Pages (JSP)2.0 |
Langue d'expression et bibliothèque de balises |
J2EE Connector Architecture1.5 |
Caractère enfichable de Java Message Service (JMS) et de l'adaptateur de ressource entrant |
Services Web |
|
Java Web Services Developer Pack1.5 |
Boîte à outils intégrée pour la conception, le test et le déploiement d'applications XML, d'applications et de services Web |
Java API for XML-based Remote Procedure Calls (JAX-RPC)1.1 |
Mappage pour le langage WSDL et la technologie Java et prise en charge du développement des extrémités et des clients de service Web |
WS-I Basic Profile1.0 |
Élément d'activation pour l'interopérabilité via le langage WSDL et le protocole SOAP |
SOAP with attachment API for Java (SAAJ)1.2 |
API pour système de messagerie SOAP. Favorise la création de messages SOAP avec des pièces jointes. |
Java APIs for XML Registries (JAXR)1.0 |
API standard uniforme permettant d'accéder aux registres XML, notamment les annuaires UDDI et ebXML |
Autre |
|
J2EE Deployment1.1 |
API standard permettant le déploiement d'applications et de composants J2EE |
J2EE Management1.0 |
Définitions du modèle d'informations pour la gestion de la plateforme J2EE |
Java Management Extensions (JMX)1.2 |
API de gestion standard |
Java Authorization Contract for Containers (JACC)1.0 |
Définition des contrats de sécurité entre un serveur Application Server J2EE et un fournisseur de stratégie d'autorisation |
Java API for XML Processing (JAXP)1.2 |
API utilisée par des applications pour analyser et convertir des documents XML ainsi que pour gérer le traitement de schémas XML |
JMS1.1 |
Norme de messagerie qui permet aux composants d'application J2EE de créer, envoyer, recevoir et lire des messages ; permet également de prendre en charge les API uniformes pour files d'attente et rubriques. |
JavaMail1.3 |
Ensemble de classes abstraites permettant de structurer un système de messagerie ; comporte également des mises à jour mineures pour les API. |
Application Server inclut des services Web, des conteneurs Web et EJB de hautes performances et prend en charge la livraison simultanée des messages avec le logiciel Sun Java System Message Queue.
Application Server prend en charge l'évolutivité horizontale par le biais du clustering des instances de serveur et l'équilibrage de charge des requêtes. Il permet également une évolutivité verticale de premier ordre, prenant en charge les grandes machines multiprocesseurs. Il vous est possible de clusteriser le courtier de messages intégré afin d'obtenir une meilleure évolutivité et une meilleure disponibilité. En outre, les clusters d'Application Server vous offrent la possibilité d'équilibrer la charge de l'accès aux clients, notamment les clients HTTP, les applications client enrichi RMI/IIOP, les clients de services Web et les clients JRM.
Sun Java System serveur d'application Environment Enterprise 8.1 prend en charge la technologie JavaServer 1.1. Cette technologie s'appuie sur un ensemble d'interfaces API côté serveur représentant les composants de l'interface utilisateur qui gèrent leur état, leur événement, leur gestion et la validation des entrées. De plus, les API définissent la navigation entre les pages et prennent en charge l'internationalisation et l'accessibilité. Vous pouvez ajouter des composants personnalisés de l'interface utilisateur à l'aide d'une bibliothèque de balises personnalisées JSP.
Au cours de la phase de développement, la technologie JavaServer Faces permet à chaque membre d'une équipe de développement de se consacrer à une partie spécifique du processus. Un modèle de programmation simple relie ensuite les différentes parties, facilitant et améliorant ainsi le cycle de développement.