Urbanisation et architecture des systèmes...

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


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


DéfinitionsObjectif du middleware

Permettre l’accès à n’importe quels services à partir n’importe quels outils

Middleware

Protocolesde

communicationInterfacesserveurs

Bureautique

AGL

Progiciel


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


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



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



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



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


Services attendus

Service 1 : Localisation des services

Client

Serveur 1

Serveur 2

Réseau


Services attendus

Service 2 : Sécurité

Client Serveur

Disponibilité

Intégrité

Confidentialité

Réseau


Services attendus

Service 3 : Transactionnel

ClientServeur

AtomicitéCohérenceIsolationDurabilité

Réseau


Services attendus

Service 4 : Temps de réponse/Performances

Client Serveur

Réseau


Services attendus

Service 5 : Administration

Client Serveur

Réseau


Services attendus

Autres services : Distribution de l’heure, gestion des licences, etc...

Client Serveur

Réseau


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).


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.


Intergiciel

Définitions

Application

OS

Service

OS

Communication

API

API « OS »

Réseau


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


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


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


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.


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


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


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


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


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


Accès à un service

1: Création

2: Enregistrement

3: Recherche

4: Liaison

5: Accès

Annuaire

Client Serveur

ServiceApplication

Description


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



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



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


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


Middleware propriétaire

Mainframe

Terminaux passifs

Informatique centralisée



Interface de commande Traitements

Interface de commande Traitements

Données

Données



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


Middleware client/serveur

Serveur

IBM PS/2

Informatique client/serveur

Mac

Compatible PC

Terminaux intelligents

Réseau



Interface de commande


Traitements

Données

Traitements

Applications clientes

Serveurs



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



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


Middleware Objet

Architectures Multi niveaux (architecture à objets répartis)

Mac

PC

UNIX Mini

Mini

PCPC

PC

Internet

Internet Objet


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


Middleware objet

Client Composant Objet

Répartition des objets

Bus logiciel

Réseau


Middleware composants



DonnéesTraitements

Architecture Multi niveaux (architecture à composants

logiciels)

Serveurs d’applications

Serveurs de donnéesClients légers


Middleware Internet

Web services .NET


Middleware Internet

Web services J2EE


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)


É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


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


Abstraction des processeurs

Pentium Sparc . . . . . .

Machine Virtuelle Java


Abstraction des IHM

Windows Motif Mac . . .

Swing


Abstraction des bases de données

Oracle MS Access MySQL . . .

MS ODBC, ADOJava Data Base Connectivity


Abstraction des langages de programmation (1/2)

Java C++ Ada . . .

OMG Interface Definition Language (IDL)


Abstraction des langages de programmation (2/2)

Java C++ Eiffel . . .

Common Language Runtime (CLR) de .NET


Abstraction des communications

TCP/IP ATM mémoirepartagée . . .

CORBA , MOM


Abstraction des fonctions systèmes

communication sécurité transaction persistance

Framework DotNetEntreprise Java Beans (EJB),

CORBA Component Model (CCM)


Quid abstraction des middlewares ?

CORBA EJB .NET . . .

Enjeu majeur !


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 ?


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

Urbanisation et architecture des systèmes...

Documents

Transcript of Urbanisation et architecture des systèmes...