Le middleware Oracle Net

In document Version Description Date (Page 41-46)

III.5.1. Rappel sur l’architecture Client/Serveur III.5.1.1. Définition

Le clients/serveur est une architecture mettant en œuvre deux types d’entités qui sont le client et le serveur. Le serveur héberge les ressources (applications notamment) et le client sont des interfaces pour accéder à au serveur à travers des requêtes qui peuvent être acceptées ou pas par le serveur.

Les caractéristiques d'un serveur :

 Il est initialement passif (ou esclave, en attente d'une requête) ;

 Il est à l'écoute, prêt à répondre aux requêtes envoyées par des clients ;

 Dès qu'une requête lui parvient, il la traite et envoie une réponse.

Les caractéristiques d'un client :

 Il est actif le premier (ou maître) ;

 Il envoie des requêtes au serveur ;

 Il attend et reçoit les réponses du serveur.

Le client et le serveur doivent bien sûr utiliser le même protocole de communication.

Un serveur est généralement capable de servir plusieurs clients simultanément.

III.5.1.2. Fonctionnement d'un système client/serveur

Un système client/serveur fonctionne selon le schéma suivant (expliqué en détails plus haut) :

Requête Réponse

Requête Réponse

Figure : Fonctionnement du modèle clients/Serveur

Le client émet une requête vers le serveur grâce à son adresse IP et son port d’écoute.

Le serveur reçoit la demande et répond à l'aide de l'adresse de la machine cliente et son port.

III.5.1.3. Avantages de l'architecture client/serveur

Le modèle client/serveur est particulièrement recommandé pour des réseaux nécessitant un grand niveau de fiabilité, ses principaux atouts sont :

Des ressources centralisées : étant donné que le serveur est au centre du réseau, il peut gérer des ressources communes à tous les utilisateurs, comme par exemple une base de données centralisée, afin d'éviter les problèmes de redondance et de contradiction ;

Une meilleure sécurité : car le nombre de points d'entrée permettant l'accès aux données est moins important ;

Une administration au niveau serveur : les clients ayant peu d'importance dans ce modèle, ils ont moins besoin d'être administrés ;

Un réseau évolutif : grâce à cette architecture il est possible de supprimer ou rajouter des clients sans perturber le fonctionnement du réseau et sans modification majeure.

III.5.1.4. Inconvénients du modèle client/serveur

L'architecture client/serveur a tout de même quelques lacunes parmi lesquelles :

Un coût élevé dû à la technicité du serveur ;

un maillon faible : le serveur est le seul maillon faible du réseau client/serveur, étant donné que tout le réseau est architecturé autour de lui. Heureusement, le serveur a une grande tolérance aux pannes (notamment grâce au système RAID et à la duplication des données).

III.5.2. Le middleware ou médiateur III.5.2.1. Définition

Supposons deux personnes : l’un vivant en RD Congo et un autre aux Etats unis font connaissance sur facebook, les deux personnes sont quotidiennement en communication interactif et arrivent tout de même à se comprendre même si le congolais n’est pas anglophones et l’américain non francophone. Au cours d’une réunion de présentation des nouvelles technologies Oracle, les deux personne se rencontrent physiquement et là la communication n’est plus aussi facile qu’avant, s’ils se comprenaient un peu à l’écrit, la compréhension devient impossible à l’orale. Ainsi donc ils auront besoin d’une personne

intermédiaire qui maitrise les deux langues afin de jouer l’interprète : Moi. Dans ce cas, je joue le rôle de l’interprète, heu … je voulais dire du middleware comme le montre la figure suivante.

Congolais francophone Américain anglophone

Danny : billingue

Figure : le rôle d’un interprète (middleware) dans le processus de communication Un middleware est donc un ensemble des services logiciels construisent au-dessus d’un protocole de transport afin de permettre l’échange des requêtes et des réponses associées entre client/serveur de manière transparente.

Le middleware (intergiciel) est la couche logicielle située entre les couches basses (systèmes d'exploitation, protocoles de communication) et les couches hautes (applications) dans un système informatique. Son but est de faciliter le développement des applications, en masquant l'hétérogénéité des systèmes sous-jacents et les détails de leurs mécanismes, et en

fournissant des interfaces normalisées de haut niveau.

Le middleware est un domaine en plein développement et plusieurs systèmes industriels sont disponibles : EJB, Corba, Oracle Net, .Net etc.

III.5.2.2. Les Objectifs d’un Middleware

L’objectif d’un médiateur est donc d’assurer une liaison transparente, c’est-à-dire de cacher l’hétérogénéité des composants mis en jeu. Il s’agit d’assurer la transparence aux réseaux, aux SGBD, et dans une certaine mesure aux langages d’accès. Mais les médiateurs peuvent assurer de multiples fonctions telles l’homogénéisation des formats des requêtes et de données, l’optimisation des accès, la gestion de services distribués.

III.5.2.3. Rôle d’Oracle Net

Oracle permet à des produits Oracle situés sur des machines différentes de communiquer. Les fonctions essentielles d’Oracle Net sont d’établir des sessions de communication réseau entre deux machines et de transférer les données entre les deux machines.

Oracle Net a pour objectif de rendre le réseau « transparent » pour les applications : les applications n’ont pas besoin de savoir où se trouve le serveur, quel est le protocole à utiliser pour s’y connecter, etc. les applications ont simplement besoin de connaitre un nom de service réseau qui leur permettra d’établir une connexion avec la base de données souhaitée.

Oracle Net doit être installé coté client et coté serveur ; cette installation est réalisée par défaut par Oracle Universal Installer (OUI). Après installation, la couche Oracle Net doit être configurée, là encore, coté client et coté serveur.

III.5.2.4. Principe de fonctionnement

Le schéma suivant illustre le fonctionnement d’Oracle Net : Oracle Net doit être configuré au niveau des deux entités : client et serveur. Comme nous allons le voir plus bas, la configuration au niveau client peut se résumer à copier un fichier (tnsname.ora) au niveau de la machine client puis installer le logiciel client.

Serveur Client

Application

Oracle Net

Réseau TCP/IP

Oracle Net

Figure : Fonctionnement d’Oracle NET

Lorsqu’une application cliente utilise un nom de service réseau pour se connecter, ce nom de service réseau est résolu par Oracle Net en un descripteur de connexion comportant l’adresse du service : protocole à utiliser, adresse du serveur, port de communication (dans le cas de protocole TCP) et nom de service (instance dans le cas qui nous intéresse).

Coté serveur, un processus d’écoute est chargé de recevoir les demandes de connexion et de les transmettre à la base concernée. Ce processus d’écoute se matérialise par un service sur plate forme Windows et un processus sur plate forme Unix ; il est configuré par le fichier listener.ora.

Il y a plusieurs méthodes pour effectuer la résolution de nom. Dans le cadre de ce séminaire, nous allons utiliser le nommage local (local naming) où un fichier de configuration (tnsnames.ora), situé sur le poste de l’utilisateur, se charge de la résolution, c’est la méthode la plus utilisée.

III.5.2.5. Les responsabilités réseau pour les administrateurs de base de données

Vu qu’Oracle fonctionne dans un environnement réseau, il est de la responsabilité de l’administrateur des bases de données d’assumer certaines tâches réseau. En quelques points, les responsabilités de l’administrateur se présentent comme suit :

 Comprendre la configuration réseau de l’organisation et être informé de toutes modifications de cette architecture;

 Travailler étroitement avec l’administrateur réseau afin de l’orienter à ne pas prendre des décisions qui pourraient aller en contre performance du serveur Oracle ;

 Comprendre les outils de configuration et d’administration du réseau ;

 Savoir résoudre les pannes liées à la connectivité réseau au niveau client, serveur et middleware.

III.5.2.6. Configuration d’Oracle Net a. Configuration côté serveur

La configuration côté serveur consiste à configurer le processus d’écoute Listener (expliqué juste dans les lignes qui suivent), c'est-à-dire à indiquer comment et pour quelles bases de données il doit écouter.

Cette configuration peut s’effectuer directement dans le fichier listener.ora (ce fichier se trouve par défaut dans le répertoire $ORACLE_HOME/network/admin) mais cela nécessite de bien connaître la structure de ce fichier (nous allons l’explorer pendant les séances pratiques). Pour l’instant on peut le faire en graphique en utilisant Oracle Net Manager (voir plus loin) :

Ci-dessous, une partie de mon listerner.ora

# listener.ora Network Configuration File:

C:\Oracle\product\11.1.0\db_2\NETWORK\ADMIN\listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST = (DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = Serveur)(PORT = 1521)) )

(DESCRIPTION =

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) )

)

Vous pouvez avoir une idée des paramètres qui s’y trouve. Pour le reste, nous en parlerons en large durant nos ateliers pratique.

b. Configuration côté client Pour configurer le client, il faut :

 Sélectionner les méthodes de résolution de noms utilisables par le client ;

 Configurer les méthodes de résolution de noms sélectionnées.

Les méthodes de résolutions de noms utilisables par le client sont stockées dans le fichier sqlnet.ora. Si la méthode de résolution de nom locale est utilisée, il faut en plus définir un ou plusieurs noms de service réseau dans le fichier tnsnames.ora.

Les deux fichiers se trouvent par défaut dans le répertoire

$ORACLE_HOME/network/admin.

Les fichiers sqlnet.ora et tnsnames.ora peuvent être édités directement mais cela nécessite de bien comprendre leur structure et de bien connaître la syntaxe et le rôle des différents paramètres.

Le plus simple consiste à utiliser Oracle Net Manager comme suit : voir TP 

III.6. Le processus d’écoute ou Listener Oracle

In document Version Description Date (Page 41-46)

Related documents