Java et Oracle 10g

L’environnement Java d’Oracle 10g

Oracle a développé sa propre machine virtuelle Java, compatible avec les spécifications de SUN Microsystems. Dans la version Oracle 10g, l’environnement Java est conforme aux spécifications Java 2. Par rapport aux machines virtuelles destinées aux postes client, la JVM d’Oracle 10g est capable de hautes performances dans le domaine transactionnel ; elle peut s’adapter automatiquement à un nombre grandissant d’utilisateurs et communiquer facilement avec la base de données Oracle, notamment avec le moteur PL/ SQL d’Oracle 10g. L’environnement Java d’Oracle 10g se caractérise par : • une machine virtuelle Java performante ; • une intégration étroite à la base de données. Les nombreuses applications développées en PL/SQL n’ont pas besoin d’être réécrites en Java. Grâce à l’intégration de la JVM dans la base de données, une véritable interopérabilité est possible entre le moteur PL/SQL, le moteur SQL et la JVM d’Oracle 10g. La base de données peut exécuter des déclencheurs (triggers), des fonctions, des procédures et des méthodes de type objet écrits en Java, tout comme elle peut exécuter du code PL/SQL. Évolutions d’Oracle 10g La machine virtuelle Java interne d’Oracle 10g est en version 1.4. Les technologies Java J2EE ne sont plus supportées dans la version Oracle 10g. Ces technologies regroupent : • le conteneur pour Enterprise Java Beans (EJB) ; • le moteur Java Server Pages (JSP) ; • le moteur Oracle Servlet Engine (OSE) ; • l’environnement CORBA intégré dans la base Oracle. Dans la gamme des produits Oracle, les standards J2EE sont désormais disponibles avec Oracle 10g Application Server (10g AS), le serveur d’application Oracle. Le module OC4J de 10g AS constitue le moteur de déploiement des applications J2EE. Nous venons de présenter l’environnement Java intégré dans Oracle 10g ; apprenons maintenant à l’exploiter. Configuration Java dans Oracle 10g Le fonctionnement de la JVM d’Oracle dans une instance Oracle 10g est déterminé par les paramètres de configuration suivants : • SHARED_POOL_SIZE; • JAVA_POOL_SIZE ; • JAVA_SOFT_SESSIONSPACE_LIMIT ; • JAVA_MAX_SESSIONSPACE_SIZE. Les paramètres SHARED_POOL_SIZE et JAVA_POOL_SIZE agissent directement sur les performances de la JVM d’Oracle 10g. Les deux autres paramètres fixent des seuils de consommation mémoire Java : le premier est un seuil d’avertissement, le second un seuil d’erreur. Ces quatre paramètres sont spécifiés dans le fichier d’initialisation de l’instance (local ou serveur). Paramètre SHARED_POOL_SIZE La zone mémoire dont la taille est spécifiée par le paramètre SHARED_POOL_SIZE sert, dans le cadre de la JVM, pour le chargement des classes Java par l’utilitaire loadjava par exemple. En effet le chargement d’objets Java dans la base de données  Outils et langages de programmation nécessite des traitements lourds en terme de ressource mémoire. Le mécanisme de chargement et de résolution des dépendances entre classes Java est décrit plus loin dans ce chapitre. La valeur minimum conseillée pour ce paramètre est environ 50 Mo. Il faut noter que la zone mémoire du pool partagé n’est pas dédiée uniquement à la JVM d’Oracle 10g. Paramètre JAVA_POOL_SIZE Le paramètre JAVA_POOL_SIZE spécifie la taille de la zone mémoire utilisée pour le stockage des objets Java pendant leur utilisation. La taille minimum conseillée est 20 Mo. Depuis la version Oracle 10g (release 1 et 2), le paramètre JAVA_POOL_SIZE est ajusté automatiquement par les processus de la base. Paramètre JAVA_SOFT_SESSIONSPACE_LIMIT Ce paramètre indique le seuil de mémoire Java consommée par une session Oracle au-delà duquel un message d’avertissement est enregistré dans un fichier de trace Oracle. Paramètre JAVA_SOFT_SESSIONSPACE_SIZE Ce paramètre indique la quantité de mémoire Java maximale que peut consommer une session Oracle. Si la mémoire Java utilisée par la session dépasse cette valeur, Oracle renvoie au programme appelant une erreur de dépassement de mémoire (« out of memory »). Par défaut, la valeur de ce paramètre est fixée à 4 Go. S’il existe un risque que la consommation mémoire des classes Java n’est pas maîtrisée, il est conseillé de fixer une valeur moins élevée à ce paramètre

Sécurité Java dans Oracle 10g

Oracle 10g a des fonctionnalités de gestion de la sécurité pour tous les objets de la base de données. Elle gère la sécurité sur les objets des schémas par type d’accès (lecture, exécution, modification, suppression, etc.). La sécurité de l’environnement Java 2 repose initialement sur l’octroi de permissions sur les ressources système. Dans ce livre, nous n’expliquerons pas en détail les permissions Java 2. Cette section décrit l’implémentation et la gestion de la sécurité Java 2 dans Oracle 10g. =Briard.Livre Page 478 Mardi, 21. février 2006 1:46 13 Java et Oracle 10g CHAPITRE 20 479 Gérer la sécurité Java 2 dans Oracle 10g Dans les JVM externes, les règles de sécurité Java 2 sont décrites dans un fichier (Security policy file). Dans Oracle 10g, les règles de sécurité Java 2 sont enregistrées dans une table (Java policy table). La consultation de la table des permissions Java 2 se fait à travers des vues du dictionnaire Oracle 10g. Ces vues décrivent la configuration des permissions Java 2 paramétrées dans la base de données : • DBA_JAVA_POLICY ; • USER_JAVA_POLICY. Dans ces vues on trouve les informations suivantes : Comme pour les privilèges standard Oracle (système et objets), les permissions Java 2 peuvent être accordées, soit à des schémas, soit à des rôles. Sécurité Oracle 10g préconfigurée Dans Oracle 10g, l’octroi de permissions Java 2 est facilité par l’existence de rôles Oracle standard déjà configurés à la création de la base de données : • JAVA_ADMIN ; • JAVA_DEPLOY ; • JAVASYSPRIV ; • JAVAUSERPRIV ; Colonne Information Kind GRANT ou RESTRICT (octroi ou restriction) Grantee schéma ou rôle auquel la permission est accordée Type_schema schéma propriétaire de la classe de la permission Type_name nom de la classe de la permission Name nom de la permission Action actions associées à la permission (read, write par exemple) Enabled permission active ou inactive Seq clé identifiant la permission Un enregistrement dans la table des permissions Java 2 ne signifie pas forcément un octroi de privilèges. Le type de la permission est GRANT ou RESTRICT. Un enregistrement de la table peut donc indiquer une interdiction.  • JAVADEBUGPRIV. Le rôle JAVA_ADMIN accorde des droits privilégiés sur la gestion de la sécurité Java (PolicyTablePermission). Par défaut, il est accordé au rôle DBA. Le rôle JAVA_DEPLOY accorde des droits pour le déploiement des librairies de classes Java compilées nativement. Le rôle JAVASYSPRIV accorde des droits privilégiés comme : • l’administration des classes de la JVM d’Oracle 10g ; • l’utilisation de sockets (client et serveur) ; • l’accès complet aux fichiers du système d’exploitation. Le schéma PUBLIC reçoit par défaut les droits de chargement et d’exécution des classes. Il ne peut en revanche pas modifier les classes des packages Java système telles que oracle.aurora, java et jdbc. Le rôle JAVAUSERPRIV accorde des droits d’exécution supplémentaires (par rapport à PUBLIC), comme : • l’utilisation de sockets (client) ; • l’accès aux fichiers en lecture seule ; • la gestion des threads. Le rôle JAVADEBUGPRIV accorde des droits pour utiliser les fonctions de débogage de la JVM d’Oracle 10g. Gérer les permissions Java 2 dans Oracle 10g La gestion des permissions Java 2 est effectuée via une API PL/SQL ou Java. Le package PL/SQL s’appelle DBMS_JAVA. Il comprend les méthodes pour accorder ou supprimer des privilèges Java 2 dans la JVM Oracle 10g. Types de permissions Aux types de permissions Java 2 communs, Oracle 10g ajoute deux types propres à la JVM interne de la base de données : • oracle.aurora.rdbms.security.PolicyTablePermission; • oracle.aurora.security.JserverPermission. Le premier permet d’accorder les droits sur la table des permissions Java 2.