Cours Architecture Des SI

Avril 2011 Architecture des SI - P. ANIORTE 1

Préambule

Présentation

Objectifs

Contenus


Objectifs

Savoir : Appréhender le problème de l’architecture des SI et les solutions disponibles

Savoir-faire : Mettre en œuvre les outils proposés dans les environnements CORBA & RMI


Contenus

Introduction à l’interopérabilité

Le modèle Client / Serveur

CORBA

RMI

Avril 2011 Architecture des SI - P. ANIORTE

4

Introduction à l’interopérabilité

Philippe ANIORTE

IUT Bayonne - LIUPPA

[email protected]


Plan du chapitre

1. Définition générale

2. Origines du problème

3. Types d’interopérabilité

4. Eléments de solution


1. Définition (1)

« Inter » : entre (entités)

« Opérer » : traiter

Permettre l’interaction (coopération) entre entités


1. Caractérisation des entités

Autonomie : conception / communication / exécution

Hétérogénéité : environnement

Distribution : réseau


1. Définition (2)

Capacité d’échange de données et de services entre systèmes en dépit de leurs différences (hétérogénéité)

L’interopérabilité traite la distribution, la compréhension et la communication mutuelles entre entités


2. Origines du problème

Niveau SI

Organisationnelles : externes / internes Intégration d’activités - Systèmes ouverts évolutifs

Techniques : modèles / logiciels / matériel


3. Types d’interopérabilité

Interopérabilité sémantique (conceptuelle) Focalise sur les données gérées dans des BD - niveau modèle

Interopérabilité technique (à l’exécution) Focalise sur les supports d’exécution (SGBD, Systèmes d’Exploitation, objets distribués)


4. Eléments de solution

Modèle de spécification commun : unification

Protocole d’interaction entre entités hétérogènes : transparence

Gestion de la distribution : transparence


12

Le modèle Client / Serveur

Philippe ANIORTE


[email protected]


Plan du chapitre

1. Principes du modèle

2. Aspects techniques

3. Eléments de mise en œuvre


1. Un modèle de communication entre entités distantes

Entités (clients & serveur) = processus

Les processus s’exécutent sur des machines différentes reliées par un réseau (distribution)

Protocole de communication (niveau application)


1. Le serveur

Fournit un service

Attend les sollicitations des clients

Répond à ces sollicitations en assurant le service


1. Les clients

Consomment le service

Demandent le service

Utilisent le service


2. TCP/IP

Protocole pour réseaux locaux le plus répandu

Transmission Control Protocol (couche ISO n° 4 - transport)

Internet Protocol (couche n° 3 - réseau)


2. Le Port

L’adresse IP d’une machine ne suffit pas

Il est nécessaire de préciser le processus concerné (service)

Tout service est associé à un port (n°)


2. La « socket »

« Prise » / « terminal de communication »

Dispositif permettant la communication de processus

Adresse IP / n° de port


3. La gestion de sockets (client & serveur)

Création socket

Envoi message

Réception message

Fermeture socket


3. La gestion de sockets (« côté client »)

Demande connexion

Création socket - Demande connexion - (Envoi message - Réception message) * - Fermeture socket


3. La gestion de sockets (« côté serveur »)

Rendre accessible la socket par des processus inconnus a priori (clients)

Ouverture service

Attente connexion


23

CORBA

Philippe ANIORTE


[email protected]


CORBA (Common Object Request Broker Architecture)

Applications industrielles de grande envergure

Atout majeur de développement

CORBA vs RMI, DCOM … Client / Serveur


Plan du chapitre

1. Présentation générale de CORBA

2. Etapes de développement d’une application CORBA

3. Services CORBA


1. Introduction

Pas un produit (outil ou ensemble d’outils)

Norme : spécifications et recommandations

Groupe de travail OMG


1. Architecture logicielle distribuée et objets (1/2)

Clients : requêtes à destination d’objets

Exécution dans des processus serveurs

Réponses aux clients


1. Architecture logicielle distribuée et objets (2/2)

Client et Serveur : 2 parties du développement

Serveur : met à disposition des objets CORBA

Client : utilise ces objets


1. Du Client / Serveur de base à l’architecture distribuée

Limites du Client / Serveur : performances (nombre de connexions, réseau), déploiement, évolution

Interopérabilité !


1. Seconde génération : Client / Serveur à 3 niveaux (tiers) (1/2)

Intermédiaire entre le client et le serveur : serveur d’application

Déplacement de la logique de l’application vers le serveur d’application


1. Seconde génération : Client / Serveur à 3 niveaux (tiers) (2/2)

Avantages : centralisation des traitements (maintenance, évolution), partage des traitements

Inconvénients : communication standardisée à un bas niveau, concept objet non pris en compte, manque d’outils de développement


1. Architecture logicielle distribuée CORBA

Indépendance géographique (transparence de la distribution)

Middleware (intergiciel) : gestion de la communication entre éléments distribués hétérogènes (applet Java, DB2, Excel, Oracle, COBOL, C++ …)

Orientation « objet » (Java …)


1. Avantages de CORBA (1/2)

Solutions non propriétaires : bus logiciel - ORB (Object Request Broker)

Interopérabilité : protocole IIOP (Internet Inter-ORB Protocol)

Intégration de l’existant (« wrapping », passerelles)


1. Avantages de CORBA (2/2)Abstraction : définition / implantation partie

visible par les clients = interface (contrat qui définit les méthodes supportées par l’objet)

Transparence d’utilisation (y compris dans le temps : évolution)

Java (orientation objet, interopérabilité …)


1. Architecture CORBA (1/3)ORB

Issue des travaux de l’OMG visant à définir les bases d’une architecture distribuée universelle (OMA - Object Management Architecture)

ORB : cœur de l’architecture Communication transparente entre les objets mis à disposition par le serveur et les clients qui s’y connectent


1. Architecture CORBA (2/3)Objets applicatifs & Services CORBA

Objets applicatifs (Application Interfaces) : constituent l’application à développer

Services CORBA (CORBAServices ou services objets) : outils généraux de développement s’adressant aux objets (sécurité …)


1. Architecture CORBA (3/3)Spécialisations

CORBAFacilities : spécialisation horizontale S’adressent aux applications - utilitaires communs (impression …)

Domain Interfaces : spécialisation verticale (métiers) - utilitaires destinés à un secteur d’activité (gestion de cartes bancaires …)


1. Les éléments essentielsde la norme CORBA : IDL (1/7)

IDL (Interface Definition Language) : langage de définition de l’interface des objets CORBA accessibles par les clients

Concerne la partie externe de l’objet définie de façon publique (méthodes …)

Indépendance avec l’implantation de l’objet « mapping » (transformation)


1. Les éléments essentiels de la norme CORBA : Stub & Skeleton(2/7)

Stub (souche) : fragment de code pour la communication client / serveur côté client

Skeleton (squelette) : communication côté serveur

Outils de génération automatique de code (Java, C++, …) à partir de la définition de l’interface (IDL)


1. Les éléments essentiels de la norme CORBA : Adapter (3/7)

Object adapter (adaptateur d’objet) : Gestion des objets à l’intérieur de l’application serveur (activation des objets en fonction des demandes …)

2 types : BOA (Basic Object Adapter) & POA (Portable Object Adapter)


1. Les éléments essentiels de la norme CORBA : POA (4/7)

Parfaitement décrit dans la norme Compatibilité entre tous les ORB

Servant : implantation de l’objet (côté serveur)

Object reference : côté client


1. Les éléments essentiels de la norme CORBA : IOR (5/7)

Connexion entre un client et un serveur (binding)

Retourne au stub la référence à l’objet auquel on veut accéder : IOR (Interoperable Object Reference)

L’IOR est ensuite utilisé par le client pour accéder à l’objet correspondant


1. Les éléments essentiels de la norme CORBA : Référentiels (6/7)

Interface Repository : référentiel qui contient des informations sur les objets utilisés (IDL …)

Implementation Repository : contient des informations qui permettent à l’ORB de localiser et d’activer les objets référencés dans l’Interface Repository


1. Les éléments essentiels : Interfaçage dynamique (7/7)

Accès dynamique aux objets (lors de l’exécution) : évolution des interfaces

DII (Dynamic Invocation Interface) : construction dynamique de requêtes vers des objets CORBA sans stub

DSI (Dynamic Skeleton Interface) : interception de requêtes sans skeleton


1. Evolution de CORBA1991 : version 1.0 - pas de protocole

commun à tous les ORB

1994 - 1999 : version 2.0 à 2.3 - IIOP ... RMI sur IIOP

version 3.0 : CCM (CORBA Component Model)


1. Implantations de CORBA

Inprise : VisibrokerIONA : OrbixIBM : SOMObjectsObject Oriented Concepts : ORBacusAT&T : omniORB2


1. CORBA et ses concurrents (1/2)

Sockets ...

RPC (Remote Procedure Call) standardisé par l’Open Software Foundation sous la dénomination DCE (Distributed Computing Environment) - RPC/DCE basé fonctions


1. CORBA et ses concurrents (2/2)

DCOM (Distributed Common Object Model) / COM+ - Microsoft : Windows

RMI (Remote Method Invocation) - Java EJB (Enterprise JavaBeans)


2. Développement d’une application CORBA : Vue générale

Définition des fonctionnalités de l’objet

Implantation de ces fonctionnalités et codage des applications client et serveur

Compilation de l’ensemble pour générer les applications exécutables


2. Les 7 étapes de développement d’une application CORBA (1/3)

1. Ecriture de l’interface de l’objet en IDL

2. Compilation de l’IDL : génération des modules stub et skeleton (ligne de commande ou environnement de développement)

3. Implantation de l’objet (code)



4. Ecriture ou génération du code de l’application serveur (pour le lancement de l’objet)

5. Compilation du serveur (génération de l’exécutable de l’application serveur - liaison à l’ORB)



6. Ecriture de l’application cliente (pour se connecter à l’objet distant afin d’exécuter des méthodes)

7. Compilation du client (liaison à l’ORB)


2.1. Ecriture de l’interface en IDLIndépendance avec le langage utilisé

pour l’implantation de l’objet

Eléments de syntaxe : mots réservés - définition de méthodes

Editeur de texte (général ou intégré) : format ASCII standard - <module>.idl


2.2. Compilation de l ’IDL - Génération stub et skeleton (1/2)

Compilateur IDL fourni avec l’ORB

Stub : objet « virtuel » (proxy ou objet subrogé) - relai vers l’objet distant

Skeleton : classe de base de l’objet distribué à dériver (cf. étape 3)


2.2. Compilation de l ’IDL - Génération stub et skeleton (2/2)

Code généré : C++, Java ...

Selon des règles de projection (mapping) définies par l’OMG (C, C++, Java, COBOL, Ada et Smalltalk)

Ligne de commande ou environnement de développement


2.3. Création du servant - Implantation de l’objet

Création de la classe de l’objet mis à disposition des clients

Par dérivation, à partir du skeleton généré à l’étape 2

Editeur de texte / générateur de code


2.4. Réalisation du serveur (1/4)

Mettre à disposition des applications clientes l’objet obtenu à l’étape 3

Création d’une application hôte (serveur) qui contiendra l’objet

Programme résident (servlet, contrôle ActiveX, DLL ISAPI …)



Initialiser l’ORB : disposer d ’un accès à un objet correspondant à l’ORB

Obtenir une référence sur le rootPOA : accéder aux fonctionnalités du POA

[Définir la stratégie du POA : persistance]



[Créer le POA]

Créer le servant

Activer le servant dans le POA : rendre l’objet accessible aux applications clientes



Activer le POA Manager : pour écouter les demandes

Mise en attente du serveur : mettre l’application serveur en position d’attente


2.5. Compilation du serveur

Génération de l’exécutable (ligne de commande / environnement de développement)

Fichiers à inclure : [interface], stub, skeleton, code programme serveur, ORB


2.6. Réalisation du client

Initialiser l’ORB (idem serveur)

Connexion à l’objet : méthode propriétaire (bind) non normalisée par l’OMG !

Utilisation de l’objet : appels de méthodes (« classique »)


2.7. Compilation du client

Génération de l’exécutable : ligne de commande / environnement de développement (idem serveur - étape 5)

Fichiers à inclure : interface utilisateur du client, stub, ORB


3. Services CORBA - Vue générale (1/7)

Naming : permet le « nommage » symbolique des objets CORBA sous des noms simples et explicites qui seront ensuite utilisés par les clients

Event : produit des événements asynchrones au niveau des serveurs accessibles par un canal spécifique (pull / push)



LifeCycle : offre un ensemble d’outils pour la gestion du cycle de vie des objets

Persistent Object : prend en charge la persistance des objets (stockage / restauration) - liens avec Externationalization (stockage sur support persistant)



Relationship : gère les relations inter-objets (cardinalités 1-1 1-n n-n, intégrité)

Externationalization : gère des flux d’objets sortants (externationalisation) et entrants (internationalisation) pouvant impliquer des ORB différents - interopérabilité



Transaction : garantit l’intégrité des objets quels que soient les problèmes survenant lors du traitement - concept de transaction

Concurrency Control : gère les problèmes d’accès concurrents aux ressources partagées



Licensing : gestion des licences - contrôle de l’accès aux objets pour facturation

Query : permet l’introspection sur les objets

Object Collection : permet de parcourir des collections d’objets (de même type) - itérateurs - liés à Query



Property : permettre l’ajout dynamique de propriétés à un objet CORBA - en marge de la définition - besoin temporaire

Security : garantir la sécurité de l’application (authentification des clients, cryptage des données transitant sur le réseau …)



Time : fournit un point de synchronisation entre clients et serveurs - déclenchement simultané d’actions communes

Trading Object : service de localisation d’objets - trouver l’objet approprié répondant à des critères de recherche précis.


Conclusion

Langage IDL

Programmation Serveur

Programmation Client


72

Java-RMI

Philippe ANIORTE


[email protected]


Positonnement

RMI : Remote Method Invocation (RPC orienté objet intégré à Java)

Interopérabilité autour de Java

Objet Java : Stub (Proxy) / Skeleton


Architecture

2 parties : JVM Client & JVM Serveur (JVM=Java Virtual Machine)

JVM Client : Client - Stub - Naming

JVM Serveur : Serveur - Skeleton - Naming


Naming (nommage)

Dispositif central : rmiregistry (serveur de noms)

Le serveur y enregistre le service

Le client y recherche le service


Démarche de développement

Codage

Compilation

Lancement


Codage - Vue générale

Interface du service

Serveur (implantation de l’objet distribué offrant le service)

Client (utilisation de l’objet via l’interface)


Codage de l’interface (interface Java « classique »)

Interface « publique »

Extension de l’interface java.rmi.Remote

Exception java.rmi.RemoteException


Compilation des sources

Fichiers .java (interface, serveur & client)

Compilateur Java : javac

Génération de 3 classes .class (interface, serveur & client)


Génération des stub et skeleton

Outil rmic

Génération de classes ( _Stub.class & _Skeleton.class)


Lancement

Serveur de noms (rmiregistry)

Serveur

Client

Cours Architecture Des SI

Documents

Transcript of Cours Architecture Des SI