Upload
ngodien
View
220
Download
0
Embed Size (px)
Citation preview
Le middleware ou intergicielGénéralités
Urbanisation et architecture des systèmes d’information
DAVID [email protected]
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 2
Plan
DéfinitionsProblèmes liés à la répartitionservices attendusMiddleware propriétaireMiddleware client/serveurMiddleware objetÉvolutions du middleware
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 3
Définitions
Définition du middleware ou intergiciell’ensemble des services logiciels construits au dessus d’un protocole de transport qui permettent l’échange entre client et serveur de manière transparente.
Application A client
Application B serveur
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 4
DéfinitionsObjectif du middleware
Permettre l’accès à n’importe quels services à partir n’importe quels outils
Middleware
Protocolesde
communicationInterfacesserveurs
Bureautique
AGL
Progiciel
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 5
Middleware
Représentation
Niveau 6
Niveau 3
Niveau 4
Niveau 5
Niveau 2
Niveau 1
Niveau 3
Niveau 2 Niveau 2
Niveau 1
Niveau 6
Niveau 3
Niveau 4
Niveau 5
Niveau 2
Réseaux
Application A client
Application B serveur
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 6
Problèmes de répartition
Problème 1 : Indépendance vis-à-vis du réseau
Client Serveur
X.25SNA ATMEthernet
Réseau 1
Réseau 2
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 7
Problèmes de répartition
Problème 2 : Indépendance vis-à-vis de la représentation des données et des protocoles d’échange
Client Serveur
00110111 01110011
ASCII ASN.1HEXA
EBCDIC LSBHSB
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 8
Problèmes de répartition
Problème 3 : Indépendance vis-à-vis des systèmes d’exploitation
Client Serveur
DOS MAC OS
WIN 3.11
WIN 95LINUX
NT
HP UX VMS
SUN OS
AIX NT
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 9
Problèmes de répartition
Problème 4 : Indépendance vis-à-vis des langages de programmation
Client Serveur
LG4 JAVA
C++
Visual Basic
LG4 JAVA
C++
Visual Basic
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 10
Services attendus
Service 1 : Localisation des services
Client
Serveur 1
Serveur 2
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 11
Services attendus
Service 2 : Sécurité
Client Serveur
Disponibilité
Intégrité
Confidentialité
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 12
Services attendus
Service 3 : Transactionnel
ClientServeur
AtomicitéCohérenceIsolationDurabilité
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 13
Services attendus
Service 4 : Temps de réponse/Performances
Client Serveur
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 14
Services attendus
Service 5 : Administration
Client Serveur
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 15
Services attendus
Autres services : Distribution de l’heure, gestion des licences, etc...
Client Serveur
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 16
Objectifs du middleware
La transparence:à l’hétérogénéité : l’illusion que tous les serveurs du réseau font partie du même système. à la localisation physique des ressources : l’utilisation d’annuaire (X500 ou LDAP) permet de s’affranchir de la localisation.à l ’espace de désignation (arborescence des serveurs de noms) : Toutes les ressources peuvent être atteinte de la même manière.au déplacement des ressources sur les serveurs : Les mises àjours des annuaires doivent être transparentes.à l’authentification : mot de passe unique (SSO).à la réplication : La distribution des données doit être inconnue de l’utilisateur (ex: Lotus Notes).
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 17
Objectifs du middleware
La transparence:à l’accès distribué (annuaires) : Toutes les ressources sont accessibles comme si elles étaient disponibles sur la machine locale.à l’heure : Toutes les horloges doivent être synchronisées.aux pannes : Des mécanismes de reprises à chaud et des redondances doivent permettre de garantir une sûreté de fonctionnementà l’administration : L’ensemble des ressources doit être administrable via une interface unique.
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 18
Intergiciel
Définitions
Application
OS
Service
OS
Communication
API
API « OS »
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 19
Fonctions de l’intergiciel
L’intergiciel a quatre fonctions principalesFournir une interface ou API (Applications Programming Interface) de haut niveau aux applicationsMasquer l’hétérogénéité des systèmes matériels et logiciels sous jacentsRendre la répartition aussi invisible (“transparente”) que possibleFournir des services répartis d’usage courant
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 20
Objectifs
L’intergiciel vise à faciliter la programmation répartie
Développement, évolution, réutilisation des applicationsPortabilité des applications entre plates-formesInteropérabilité d’applications hétérogènes
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 21
typologie de l’intergiciel
Appel de procédure à distance: RPC, DCE, SOAPBases de données: ODBC, ADO, ADO.NET, JDBCObjets répartis: Java RMI, CORBA, DCOMComposants répartis: Enterprise Java Beans (EJB), CCM, .NETMessage-Oriented Middleware (MOM)
Message Queues, Publish-Subscribe (évènements)Intégration d’applications: Web Servicescode mobile: Applet, ActiveX
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 22
Exigences de conception
Pour que deux logiciels coopèrent en utilisant un middleware ils doivent être d’accord sur:
Les données qu’ils échangeront; l’accord doit porter sur la sémantique de ces données. C’est là la partie statique de l’accord, partie qui ne dépend pas des opérations sur ces données.
Les opérations effectuées par l’un pour le compte de l’autre, au moins dans leur spécification: appels de fonctions par exemple. C’est la partie dynamique de l’accord.
Les moyens de communication qu’ils utiliseront pour échanger données et opérations: protocole applicatif et infrastructure réseau.
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 23
Exigences de conception
Principe directeur : séparation des préoccupationsIsoler les aspects indépendants (ou faiblement corrélés) et les traiter séparémentExaminer un problème à la foisÉliminer les interférencesPermettre aux aspects d’évoluer indépendamment
Mise en œuvreEncapsulation : séparer interface et réalisation (contrat commun)Abstraction : décomposition en niveaux, cacher les détails non pertinents à un niveau donnéIsolation et expression indépendante des aspects hors interface
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 24
Services et interfaces
DéfinitionUn système est un ensemble de composants (au sens non technique du terme) qui interagissentUn service est “un comportement défini par contrat, qui peut être implémenté et fourni par un composant pour être utilisépar un autre composant, sur la base exclusive du contrat” (*)
Mise en œuvreUn service est accessible via une ou plusieurs interfacesUne interface décrit l’interaction entre client et fournisseur du servicePoint de vue opérationnel : définition des opérations et structures de données qui concourent à la réalisation du servicePoint de vue contractuel : définition du contrat entre client et fournisseur
(*) Bieber and Carpenter, Introduction to Service-Oriented Programming, http://www.openwings.org
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 25
Définitions d’interfaces (1)
La fourniture d’un service met en jeu deux interfacesInterface requise (côté client)Interface fournie (côté fournisseur )
Le contrat spécifie la compatibilité (conformité) entre ces interfacesAu delà de l’interface, chaque partie est une “boîte noire” pour l’autre (principe d’encapsulation)Conséquence : client ou fournisseur peuvent être remplacés du moment que le composant remplaçant respecte le contrat (est conforme)
Client Fournisseur
Interface fournieInterface requise
Contrat
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 26
Définitions d’interfaces (2)
Partie “opérationnelle”Interface Definition Language (IDL)Pas de standard, mais s’appuie sur un langage existant⌧IDL CORBA sur C++⌧Java et C# définissent leur propre IDL
Partie “contractuelle”Plusieurs niveaux de contratsSur la forme : spécification de types -> conformité syntaxiqueSur le comportement (1 méthode) : assertions -> conformitésémantiqueSur les interactions entre méthodes : synchronisationSur les aspects non fonctionnels (performances, etc.) : contratsde QoS
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 27
Schémas d’interaction
Schémas asynchrones Évènements réactionMessages asynchronesLes évènements ou les messages peuvent être mémorisés ou non
=>Couplage faibleSchémas synchrones
Appel synchroneLe client est bloqué jusqu’au retour
=> Couplage fort
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 28
Accès à un service
1: Création
2: Enregistrement
3: Recherche
4: Liaison
5: Accès
Annuaire
Client Serveur
ServiceApplication
Description
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 29
Middleware et modèle OSI
Le middleware client/serveur se compose au minimum :
D’une interface de programmation API:⌧nommé Application Program Interface, elle travaille en
relation avec l ’application et permet de faire appel aux services accessibles sur le serveur.
D’un protocole de communication FAP: ⌧nommé Format And Protocol, il assure l’interface avec le
réseau.Il s’appuie sur un protocole de transport:⌧ex.: TCP-IP, X25, NetBios, 802.11
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 30
Middleware et modèle OSI
Physique
Liaison
Réseau
Transport
Session
Présentation
Application7
6
5
4
3
2
1
Interface de programmation (API)
Protocole de communication (FAP)
Ex : TCP
Ex : Ethernet
Ex : Coaxial, 10baseT
Ex : IP
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 31
Middleware et modèle OSI
Piles de communication
Physique
Liaison
Réseau
Transport
Session
Présentation
Application
Fibre optique
Ethernet
Netbeui
Netbios
XDR
Mom
coaxial Paire torsadée
Token Ring
TCP/IP IPX/SPX LU6.2/APPN
Sockets TLICPI-CAPPC
NDR
ORBRPC
SUN DCEPoste à
poste
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 32
Les grandes familles du middleware
Niveau 6
Niveau 3
Niveau 4
Niveau 5
Niveau 2
Niveau 1
Niveau 3
Niveau 2 Niveau 2
Niveau 1
Systèmes d ’exploitation/ Mécanismes de base
Niveau 6
Niveau 3
Niveau 4
Niveau 5
Niveau 2
Niveau 7 Niveau 7
Client SGBDR
Client Messagerie
Client Gestion rés.
Client Groupware
Serveur SGBDR
Client Messagerie
Serveur Gestion rés.
ServeurGroupware
Systèmes d ’exploitation/ Mécanismes de base
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 33
Middleware propriétaire
Mainframe
Terminaux passifs
Informatique centralisée
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 34
Middleware propriétaire
Interface de commande Traitements
Interface de commande Traitements
Données
Données
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 35
Middleware propriétaire
Interface de commande Traitements Données
Le middleware est propriétaire car le constructeur fournit le matériel, le système d’exploitation et les logiciels applicatifs associés.
Ex: CPI-C, APPC sur le protocole de transport SNA d’IBM
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 36
Middleware client/serveur
Serveur
IBM PS/2
Informatique client/serveur
Mac
Compatible PC
Terminaux intelligents
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 37
Middleware client/serveur
Interface de commande
Interface de commande
Traitements
Données
Traitements
Applications clientes
Serveurs
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 38
Middleware client/serveur
Serveurs de données
Apparition des interfaces graphiques DOS/WINDOWS,
MAC OS, X-WINDOWS/MOTIF
Baisse des coûts des terminaux (IBM PC)
Applications clientes
Intelligence dans les postes clients
Editeurs de logiciels serveurs
Première structuration de l’offre informatique
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 39
Middleware client/serveur
Toute l’industrie informatique est touchée
MTA
Bases de données
Messagerie
Groupware
Supervision de réseau
UA
Client SGBDR
Serveur NotesClient Notes
SQL
X.400
MIBAgent
Notes
SNMP
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 40
Middleware Objet
Architectures Multi niveaux (architecture à objets répartis)
Mac
PC
UNIX Mini
Mini
PCPC
PC
Internet
Internet Objet
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 41
Middleware objet
ClientComposant
Objet
Implémentation
Interface
Le code que le client utilise pour accéder aux propriétés et aux méthodes de l’objet ne dépend pas de l’implémentation de l’objet
OS
Programmation objets
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 42
Middleware objet
Client Composant Objet
Répartition des objets
Bus logiciel
Réseau
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 43
Middleware composants
Interface de commande
Interface de commande
DonnéesTraitements
Architecture Multi niveaux (architecture à composants
logiciels)
Serveurs d’applications
Serveurs de donnéesClients légers
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 44
Middleware Internet
Web services .NET
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 45
Middleware Internet
Web services J2EE
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 46
Middleware Internet
Utilisation des technologies et standards d’Internet pour créer des services actifs et coopératifs
Publication / Recherche : UDDIService d’interactions: SOAP over HTTP/SMTPDescription des interfaces : WSDL (issu de XML)Format universel: XMLCommunications: Internet (encapsulation HTTP)
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 47
Évolutions du middleware
Les enjeux des nouvelles architectures
Client légerClient léger
Structuration de l’industrie
informatique
Structuration de l’industrie
informatique
Bataille pour le cœur des systèmes
informatiques
Bataille pour le cœur des systèmes
informatiques
Éditeurs de composants objets
métier
Intégrateurs de composants objets
métier
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 48
Middleware : vers plus de simplicité ?
Sockets,Paquets
1980 1990
RPC,Souches,
SquelettesIDL,XDR,
Messages
ORB,CORBA,
RMI,DCOM,.NET,
IIOP, SOAP,MOM,
WWW, XML,
2000
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 49
Abstraction des processeurs
Pentium Sparc . . . . . .
Machine Virtuelle Java
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 50
Abstraction des IHM
Windows Motif Mac . . .
Swing
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 51
Abstraction des bases de données
Oracle MS Access MySQL . . .
MS ODBC, ADOJava Data Base Connectivity
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 52
Abstraction des langages de programmation (1/2)
Java C++ Ada . . .
OMG Interface Definition Language (IDL)
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 53
Abstraction des langages de programmation (2/2)
Java C++ Eiffel . . .
Common Language Runtime (CLR) de .NET
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 54
Abstraction des communications
TCP/IP ATM mémoirepartagée . . .
CORBA , MOM
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 55
Abstraction des fonctions systèmes
communication sécurité transaction persistance
Framework DotNetEntreprise Java Beans (EJB),
CORBA Component Model (CCM)
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 56
Quid abstraction des middlewares ?
CORBA EJB .NET . . .
Enjeu majeur !
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 57
Exemple de choix…
Communication asynchroneroutage et filtrage de messages. . .
De nombreuses technologies Message Oriented Middleware (MOM) !
IBM MQ SeriesJava Messaging Service (JMS)EJB et Message BeansOMG Notification ServiceCORBA Component Model (CCM) et ports asynchrones
Quelle est la technologie la mieux adaptée ?Sera-t-elle toujours la meilleure dans quelques années ?
2006/2007 Cnam – NFE 107 - © Eudeline/Benhaddou 58
Solution?
Privilégier les démarches d’urbanisationUtiliser des modèles pour remonter le niveau d’abstractionUne piste: MDA (Model DrivenArchitecture) => Séparation des préoccupations