Comprendre les applications distribuées

Agenda
Breve historique
Applications client – serveur
Architectures distribuees
Technologies distribuees
L’abstraction “Objets distribues”
Avantages lies au developpement d’applications distribuees
Les defis du developpement d’applications n – tiers distribuees
Relever le defis a l’aide du .Net Remoting

Le developpement d’applications client serveur a constamment evolue au fil du temps pour satisfaire les contraintes d’entreprise de plus en plus importantes
Parmi les technologies initiales permettant de l’implanter on retrouve:
DCOM
Java
RMI
CORBA
Actuellement on exige des technologies de developpement d’applications client serveur d’etre
Efficientes
Extensibles
Dotees du support des transactions
Interoperable avec differentes tehnologies
Hautement configurables
Accessibles par Internet, ou intranet
….


Constats
---------

Rares sont les applications don’t le perimetre est suffisament large pour supporter l’ensemble des exigences mentionnees precedemment
Par consequent afin de prendre en compte les applications plus modestes la technologie client serveur
Doit fournir des comportement par defaut commun
Doit etre simple a configurer
Etre facile d’utilisation
Il est quasiment impossible de satisfaire a toutes les exigences mentionnees a l’aide d’une technologie unique
Par consequent les technologies modernes client – serveur commencent par implementer une liste d’exigences plus modestes, puis remplissent les autres exigences au fil des evolutions.
C’est l’approche adoptee par Microsoft .Net Remoting

Microsoft .Net Remoting

------------------------

Microsoft .Net Remoting a ete concu selon un model objet coherant et extensible offrant en outre la possibilite de developper des solutions logicielles client serveur similaires a celles qui se faisaient avec des technologies telles que DCOM
Elle exploite judicieusement les nombeuses technologies sous – jacentes offertes par la plate forme .Net Framework telles que
L’acces aux donnees a l’aide de Microsoft ADO .NET
La conception, le developpement, le deploiement et l’exploitation des services Web XML
L’utilisation des technologies d’acces distants tels que le Marshalling
L’utilisation des standards technologiques tels que XML, HTTP, SOAP
…
Microsoft .Net Remoting est le choix par excellence pour le developpement d’applications client serveur n – tiers ciblant la plate forme Microsoft .Net Framework

Interoperabilite du .Net remoting

----------------------------------

Lorsqu’on dispose d’objets COM/DCOM a reutiliser l’interoperabilite est assuree par une couche d’interoperabilitee integree en natif dans .Net Remoting possedant les caracteristiques suivantes :
Completude (richesse fonctionnelle)
Facilite d’utilisation
Offre des possibilites de migration progressive des objets des anciennes technologies vers .Net Remoting
Lorsqu’on dispose d’objets a reutiliser provenant d’une technologie non – Microsoft telle que Java Remote Method Invocation (RMI) ou Common Object Request Broker Architecture (CORBA), Microsoft .Net Remoting
Offre un support des technologies standardisees:
XML, SOAP (Simple Object Acces Protocol)
Qui permettent la communication entre notre application et toute plate forme supportant ces memes technologies

Architectures distribuees

-------------------------

On entend par application distribuee une application pour laquelle les traitements sont repartis entre deux ou plusieurs machines. Cette repartition des traitement impliquant notamment que les donnees concernees sont egalement distribuees.
Plusieurs architectures distribuees ont prevalu avant l’apparition du .Net Remoting, elle ont ete le fondement sur lequel Microsft apres avoir tire des lecons a developpe le .Net Remoting. Il s’agit notamment
De la programmation modulaire
Des applications client / serveur de base
Des applications client / serveur N – tiers
Du Peer – to – peer

Programmation modulaire

--------------------------

Principe : organiser le code en unites fonctionnelles coherantes
Les lignes de code en procedures
Les procedures en classes
Les classes en composants
Les composants en des sous – systemes plus vastes lies les uns aux autres
La modularite est tres utile pour la distribution du code sur differentes machines
Les architectures distribuees different essentiellement entre elles par les responsabilites attribuees a chaque module ainsi que leurs interactions

Client / serveur de base

------------------------

Represente l’architecture fondamentale ou primaire des applications distribuees
Definie par un processus client simple qui requiert des services de la part d’un processus serveur
De facon typique le processus client est responsible de la couche presentation interfaces utilisateur) ce qui inclut
La validation des entrees utilisateur
Le dispatchage des appels vers le serveur
L’execution potentielle de regles metiers
Le processus serveur quand a lui est responsible
De satisfaire les requetes du client en executant la logique metier et en interoperant avec des ressources telles que bases de donnees et fichiers
Il est classique d’avoir plusieurs client pour un seul processus serveur (exemple des applications Web)
D’un point de vue fonctionnel il est possible de faire cohabiter le client et le serveur sur la meme machine

Client / serveur N - tiers

--------------------------

Le client / serveur de base est appele “application 2 tiers” , car le client interagit directement avec le serveur.
Les applications 2 – tiers sont faciles a implementer mais ont une extensibilite limitee
Le cas d’utilisation suivant a conduit au besoin d’applications n – tiers
Une application s’execute sur une machine unique
Pour une raison quelconque on decide d’en faire une application distribuee
On souhaite par exemple donner acces a plus d’un client a la fois
Acceder a des ressources
Utiliser la puissance de traitement d’une machine aux configuration haut de gamme
Au fur et a mesure qu’on donne acces a des clients les processus de traitement ralentissent
A un certain moment les delais d’attente deviennent tellement importants que l’application est consideree indisponible
Pour resoudre le probleme on etend la configuration materielle: ce qui constitue une solution potentielle mais forcement temporaire
Une solution possible : l’usage d’une architecture n – tiers (3 tiers au moins)

On procedera donc a l’adjonction d’une couche intermediaire permettant la realisation de differentes taches
Y inserer la logique metier
La couche intermediaire dans ce cas s’assure de verifier la consistence des donnees fournies par le client et les utilise suivant les exigences du metier.
Peut impliquer une collaboration avec une couche donnees ou effectuer uniquement des traitement en memoire.
En cas de succes la couche intermediare transmet les donnees traiteees a la couche donnees pour stockage ou renvoie les resultats au client.
La force de cette conception : la distribution granulaire des responsabilites de traitement
Il est possible que plus d’une couche de cette architecture (2 par exemple) soient hebergees sur une meme machine
Dans ce cas aussi une separation logique des fonctions du systeme est avantageuse
Les developpeurs et les administrateurs peuvent maintenir les couches separement
Les changer, les deplacer simultanement
Les migrer vers des machines separees afin d’ameliorer l’extensibilite de la solution
Avantage indeniable pour extensibilite, et flexibilite de la maintenance et du deploiement

Architecture peer – to - peer

-----------------------------

Dans les architectures precedentes les roles sont distincts, on peut identifier un couple maitre/esclave entre client et serveur.
Les couches du modele n – tiers s’identifient souvent a des roles tels que couche presentation, couche metier ou couche donnees
Ceci n’est pas forcement indispensable
Certains models sont beaucoup plus collaboratif et il y est difficile de discerner la frontiere entre le client et le serveur
Les scenarios des groupes de travail sont bases sur ces modeles car leur objectifs est essentiellement le partage d’informations et de traitement
Le modele peer – to – peer est concu comme plusieurs noeuds individuels sans serveur centralise.
Ceci implique la necessite d’un mecanisme permettant aux differents noeuds de se reperer les uns les autres
Ceci est realise via des techniques de broadcasting ou des paramtres de configuration

Technologies distribuees

-------------------------

Plusieurs technologies ont servi au fil des annees a l’implantation des architectures presentees plus haut. Les meilleures ameliorations ont ete plus au niveau technologique qu’au niveau architectural, bien que des progres remarquables ont ete faits a ce niveau. Parmi celles – ci on a principalement
Les sockets
RPC (Remote Procedure Call )
Les Stubs
Le Marshalling
Les IDL (Interface Definition Languages)

Sockets

--------

L’une des abstractions fondamentales des applications reseau modernes
Barricadent les programmeurs de l’acces aux details de communication reseau de bas – niveau en la rendant similaire a des mecanismes I/O (Input Output)
Necessitent cependant beaucoup de travail pour developper une riche ou complexe application distribuee, bien que fonctionnellement parlant ils permettent un controle total de la communiquation
Les sockets demandent de creer des fonctions de transfert et reception de messages systemes ainsi que d’interpretation des flux de donnees
Les developpeurs ont besoin d’abstractions de haut niveau donnant l’illusion d’effectuer des appels de fonctions ou de procedures locales

Remote Procedure Call (RPC)

-------------------------------

La specification RPC a ete definie par la DCE (Distributed Computing Environment) et la Open Group (communement Open Software Foundation ). RPC permet
D’utiliser une semantique similaire a celle utilisee lors de la realisation d’appel local de procedure
Necessite cependant une configuration precise et implique des contraintes de type de donnees precis.
Les concepts fondamentaux introduits par RPC ont servi de fondement aux technologies de distributions telles que DCOM, CORBA, RMI et … Microsoft . Net Remoting, il s’agit principalement
Des stubs
Du Marshaling
Des IDL (Interface Defintion Language )
RPC constitue un bon important dans la tentative de rendre familieres les technologies de communication distantes par rapport aux Sockets. Mais vu les progres et la predominance de la P.O.O (Programmation Orientee Objet) le concept d’ “objets distribues” s’est impose

Stubs

----------

Bouts de code s’executant sur le serveur et le client et sont responsables de l’illusion que l’appel de la procedure distante est local.
Par exemple le code client appelle des procedures au sein du stub qui sont parfaitement ressemblantes a celles implementees sur le serveur
Le stub transfert ensuite l’appel a la procedure distante