Recherches et Développements autour des middlewaresmmorslaoui.free.fr/jalalMaster/09-01-slides-middleware.pdf · Recherche et développements autour du middleware - LMO'2001 Janvier

Recherche et développements autour du middleware - LMO'2001 Janvier 2001

Michel RIVEILL, Université de Nice 1

1

Recherches et Développementsautour des middlewares

Michel RIVEILL, Université de [email protected]

Projet RAINBOW, Laboratoire I3S (CNRS – UNSA)ESSI – 930 route des Colles - BP 145 – 06903 Sophia Antipolis CEDEX

http://www.essi.fr/~riveill

2

Middleware – bus logiciel : mode d'emploi

Logiciels d'application

Langagesméthodes et outils de développement

Logiciel de base(système, télécommucation, SGBD, etc.)

Dév

elop

pemen

t

Adm

inistr

ation

Bus logiciel - middleware(CORBA, J2EE, .Net, etc.)



3

Quelques problèmes « chauds »

Plan

q Méthodes et outils de développementu quels outils pour quels développeurs ?

q Logiciel de base : infrastructures pour applications répartiesu impact de l'Internet et du Webu informatique nomadique (mobile computing)u informatique individuelle omniprésente (ubiquitous computing )

q Comparaison (très rapide/partielle/partiale) de bus logiciels di sponibleset quelques travaux en cours

q Modes de développement des middlewaresu Quelle place pour le logiciel libre ?

4

Programmation : mode d'emploi

TempsAujourd'hui 2010

Nb. de personnes(échelle log.)

1M

10M

100 M

Programmeursoccasionnels

entreprisesutilisantl'informatique

entreprisesd'informatique

département d'informatique

Quel langage pour quel usage ?



5

langages de programmation : la querelle des anciens et des modernes

q Langages à objetu vertus et limitesu . . . des objets . . . aux composants

q Langages de scriptu Programmation occasionnelleu programmation à gros grain (« programming in the large »)

intégration de composants logiciels

q Quel langage pour quel usage ?u Occasionnel ou fréquentu Programmation de modulesu Assemblage de composants, description de configurationu Mise en œuvre d ’une application répartie à grande échelle

6

De la programmation usuelle…A la programmation par composition

« programming in the small »

q construire l ’application… mais tout est à la charge du programmeur

u construction des différents modulesu définition des instancesu interconnexions des modules

q structure de l’application peu visibleu ensemble des fichiers de codes nécessaire

q installation / évolution / modification difficile

u changement du mode de communicationu évolution, ajout, suppression de

fonctionnalitésu modification du placement

--> construction des briques de base

« programming in the large »

q réutiliser du logicielu intégration de modules logiciels existantsu construction de l'application par assemblage de

modules

q description de l'architecture de l'application

u spécification des briques de base :v interfaces, implémentationv attributs de spécialisation,v spécification comportementale

u description des interactions entre composants (connecteurs)

u description de variables d'environnement(placement, regroupement, sécurité, etc.)

u à l'aide d'un langage déclaratif ou d ’un langage de script

--> assemblage de briques existantes



7

Programmation orientée-objet

q Les "avantages" reconnusu encapsulation, typage fort, héritage, polymorphismeu avantages du typage "fort"

v détection des erreurs et optimisations à la compilationu réduction du temps de développement

v OO favorise la réutilisationu un seul langage pour : contrôle, accès aux données, IHM, communi cations, etc.

(exemple : Java)q Quelques limitations/interrogations

u l'héritage de classes pose des problèmes d'évolutionu le typage fort n'a pas que des avantagesu Le gain en temps de développement est-il réel (20-30% ?)

v quid de la réutilisation ?

u granularité des objets trop faible ?

8

Programmation par composantsq Composant : objet (ou groupe d'objets)

u qui exporte différents attributs, propriétés ou méthodes,u capable de s’auto-décrire,u qui peut être configuré et assemblé avec d'autres composantsu capable de réagir à des conditions de son environnement d'exécution

q Objectif u briques de base configurables et adaptables pour permettre la construction d’une

application par compositionu Différents points de vue

v Programmation d’un composant : langage à objets ?v Description de l’assemblage : A.D.L, langage de script, interactionv Mais aussi

u Configuration / adaptabilité des composants : A.O.P, méta-protocole, …

q Exemplesv COM / DCOM / COM+ / .Netv Java Beansv Enterprise Java Beansv Composants CORBA



9

q Comment (co-)opère un composant

u interface fonctionnelleu dépendancesu mode de communication des ports E/S

(synchrone, asynchrone, flots)u description du comportement

q Propriétés configurables du composant

u interface d'introspectionq Propriétés non-fonctionnelles

u cycle de vieu persistance, sécurité, transactionsu contraintes environnementalesu comportement (QoS, etc.)

Structure d'un composant

Code et propriétés non-fonctionnelles

Utilise

Propriétésconfigurables

Fournit a

sync

sync

Interfaced'introspection

Interfacesfonctionnelles

Interface d'administration

Code fonctionnel

Dépendances

flUx

async

sync

flUx

10

Plate-forme à composants

Système d'exploitation

Création/destructionpersistance, transactionsréplication, migration,

Bus logiciel A

Serveur decomposants

comportement

Systèmed'exploitation

comportement comportement

Serveur de composants

Bus logiciel B

Systèmed'exploitation

Serveur decomposants

Composant = unité de réutilisation

Assemblage de composants = unité d’administration



11

Vie (et mort) des applicationsq Pourquoi les applications ne fonctionnent pas correctement ?

u Développeurs ne tiennent pas compte du cycle de vie completu Équipes sont mal équipées pour gérer la complexitéu Incapacité de déployer en réparti, de manière simple, ce qui a été développé

v Le prototype fonctionne mais l’application échoue lors de la montée en chargev La fiabilité ou la performance requise n’est pas au Rendez-vous

q Nécessité d’administrer les applicationsu Loi de l’entropie

v Chaque système tend vers un état de désordre et requiert une certaine énergie pour le stopperu Appliquez-la à une société... À une manifestation lors du sommet de Nice

v Grand nombre d’ “objets” personnes

u Maintenant pensez à un réseau d’ordinateurs...q Le coût de gestion d’une application répartie dépasse très largement le coût

initial de son développement.u L’administration doit être pris en compte dès la conceptionu Afin de permettre l’évolution, la reconfiguration de l’applicati on

v Résistance aux pannes, évolution du nombre d’utilisateurs, évolution des besoins…

12

Modéliser la Complexité

MODELISEMODELISE

Décrire et comprendre la complexité de l’application distribuée



13

Surveiller pour Contrôler

MODELISEMODELISE

SURVEILLESURVEILLE

Garantir :- les niveaux de service en accord avec les utilisateurs- les besoins des composants- l’état du système

q Modéliser la Complexitédécrire l’architecture

14

Administrer pour Changer

MODELISEMODELISE

SURVEILLESURVEILLE

ADMINISTREADMINISTREAssurer que les services demandés sont maintenues alors que les applications évoluent (nouveaux utilisateurs, nouveaux besoins)

q Modéliser la Complexitéq Surveiller pour Contrôler



15

q Gestion et surveillance des applications objets distribuéesu Tolérance de panne et recouvrementu Surveillance des performancesu Définition des dépendances et ordre de démarrage des objetsu Démarrage et arrêt des objets individuels ou en groupe

q Intégration avec les environnements opérationnelsu Exécution d’actions basées sur des événementsu Mécanisme hiérarchique de filtres d’ événements

q Interface graphique intuitive, simple à utiliseru Possibilité de ligne de commande (langage de script)

q Connaître le fonctionnement de l’application - tunningu Statistiques détaillées - jusqu’au niveau méthodeu Statistiques combinables pour affichage optimumu Instrumentation à travers les intercepteurs

MODELISEMODELISE

SURVEILLESURVEILLE

ADMINISTREADMINISTRE

Bénéfices attendu d’un outils d’administration

16

Programmation par assemblage ADL

coll : collection [0..N] of Annuairecoll : collection [0..N] of Annuaire

Annuairepays = CH

Annuairepays = CHClientClient Recherche

(in string clé,out string email,in string pays)

Lance

AdminAdminInitialise(in CODE pays)

Recherche(in string clé, out string email)

Annuairepays = FR

Annuairepays = FR

Annuairepays = UK

Annuairepays = UK

LanceAnnuaire(in CODE pays)

coll : collection [0..N] of Annuaire;

admin.LanceAnnuaire(code) => coll.Init(code)using createInCollection();

client.Lookup(clé, email, pays) => coll.Lookup(clé, email)where pays == coll.paysusing randSyncCall;



17

Programmation par assemblage ADL

q Caractéristiquesu Peu, pas de « succes story »

v Qui connaît Darwin, OCL, Polilyth , …

u Bonne vision de l’architecture de l’applicationu Description des aspects essentiellement statique, régulier

v Description configurableu Peu servir de tableau de bord pour « visualiser » le fonctionnement de l’application

v Aide à l’observationv Outils pour la reconfiguration dynamique

q Usageu Description d’une version « d’installation » de l’applicationu Support pour faire de la validation, de la preuve

18

Langages de scripts

q Caractéristiquesu Exemples : shell Unix, Perl, Tcl, Python, . . . u langages non typés

v représentation des informations banalisée (ex. "string")v sémantique déterminée par l'usage

u expressivité à rapidité de développementu langages interprétés à perte d'efficacitéu intégration des concepts OO (Python, Perl 5.0)

q Usagesu utilisation moins efficace des machines mais plus efficace des programmeurs* intérêt pour :

la programmation occasionnelleles tâches d'intégration



19

Typage

CC++

Java / C#

Visual BasicTcl / Perl

assembleur

Nb.

d'in

stru

ctions

"mac

hine

s" /

inst

ruct

ion

du lan

gage

1000

100

10

1

Niveau de typageaucun fort

ADL

20

Différents outils pour différentes tâches

q Complémentarité u construction de composants avec les langages OOu assemblage de composants avec les langages de script

q Exemples :

q Quels critères de choixu Plate- forme, langage de programmation, langage d’assemblage, etc.

Plate-forme langage langageprogrammation de script

OS/360 BAL,PL/1 JCLUnix C, C++ sh, csh, Perl, TclPC C++ Visual BasicInternet Java / C# CorbaScript ?



21

Choisir un langage

q Siu Manipulation d'algorithmes et de structures de données complexesu manipulation de grands volumes de donnéesu applications "stabilisées

q Alors choisir un langage de programmation "classique"q Sinon Si

v manipulation de données de nature très différentev gestion d'interfaces homme-machinev manipulation de chaînes de caractèresv interconnexion de composants logicielsv application évolutive

u Alors choisir un langage de scriptu Sinon

v ??

22


Plan

q Méthodes et outils de développement

q Logiciel de base : infrastructures pour applications répartiesu impact de l'Internet et du Webu informatique nomadique (mobile computing)

u informatique individuelle omniprésente (ubiquitous computing )

q Comparaison (très rapide/partielle/partiale) de bus logiciels di sponibleset quelques travaux en cours

q Modes de développement du middlewareu Quelle place pour le logiciel libre ?



23

Infrastructures pour applications réparties "à grande échelle"

q L'Internet comme environnement d'exécution d'applications répartiesu le Web : un middleware à grande échelle

q L'Informatique nomade (mobile computing)

q L'Informatique personnelle omniprésente (ubiquitous computing)

Passage à l'échelle

nb. d'utilisateurs et de siteshétérogénéité des réseaux et des stations

hétérogénéité des systèmes Hétérogénéité des langages

24

WWW : un support pour l’accès à l’information (1)

q un protocole client-serveur (mis en œuvre sur TCP/IP) : HTTPq un système de désignation universelle : URLq une représentation de documents hypertextes : HTMLq des navigateurs (“browser”) évolués

browser Serveur HTTP

Station

documents HTML

requête HTTP

pages HTML

URL(id. documents)

environnement dedéveloppement dedocuments HTML

Client

Http

ServeurStation

pageHTML

Client

HTTP

URL(id. documents)

browser



25

WWW : un support pour l’accès à l’information (2)

q Accès à des serveurs “externes”u utilisation de l’interface CGI (Common Gateway Interface)

et/ou de "servlets" et/ou ASPv requêtes à un serveur de donnéesv transformation des résultats en pages HTML

Serveurde

donnéesServeur

HTTP

Station

pageHTML

requête HTTP

pages HTML(construites dynamiquement)

Client

HTTP

Serveur

URL

CGI

ASP / Servlets

browser

base de données

26

WWW : un support d’applications client –serveur (1)

q Utilisation du protocole HTTP pour le dialogue client-serveur

+ avantages :support universel de communication (http)simplicité de la mise en œuvremise en œuvre aisée depuis n’importe

quelle station cliente

Serveur HTTP

Station

requêtes HTTPClientHTTP

Serveur

CGI

Servlets / ASP

Applicationpartie -cliente(GET, POST)

Browserclient universel

- inconvénients :primitives élémentaires (GET, POST, . . .)serveur HTTP non adaptédifficulté de gérer des sessions

Données(html / autres formats)

Applicationpartie-serveur



27

WWW : un support d’applications client –serveur (2)q Utilisation du protocole SOAP (ou XML-RPC) pour le dialogue client-

serveuru SOAP = HTTP + XML

+ avantages :

+ support universel de communication

+ simplicité de la mise en œuvre

+ requêtes et réponses lisible

+ serveur + sophistiqué (état)

+ réponse adaptée selon le poste client

Serveur HTTP

Station

requêtes SOAP(XML)Client

HTTP

Serveur

ISAPI

CGIApplicationpartie -cliente

Browserclient universel

- inconvénients :

- peu efficace (par rapport à RPC)

Réponses SOAP(XML)

Applicationpartie-serveur

ASP

Servlets

28

WWW : des documents “actifs”

q Séquences exécutables ("applets", "contrôles") dans les pages HTML

Station

documents HTML "actifs"pageHTML

requête HTTP

pages HTML

URL(id. documents)

"applet”

interprète

* sécurité : contrôle des actions exécutées par le code importé

browser Serveur HTTP

Client

HTTP

Serveur

"applet"



29

Applications réparties sur l'Internet

q Le Web sémantiqueu Web : espace (illimité ?) d'informations structurées partagéesu bus logiciel : Http+ et URLu intégration par les données : XML, RDF, DOM, . . .

q L'Internet comme environnement d'exécution d'applications réparties

Deux visions architecturales opposées/complémentaires

30

Le Web sémantique

q Web : espace (illimité ?) d'informations structurées partagéesq bus logiciel : Http+ et URLq intégration par les données : XML, RDF, DOM, . . .

Serveurhttp

Application A

Serveurhttp

Application B

DocumentXML

Browserhtml/xml

Client http



31

L'Internet : environnement d'exécution d'applications réparties

q Le Web : système d'exploitation réparti (à objets)u une désignation uniforme via les URLsu des objets persistants via les démons HTTP et leurs systèmes de fichiers hôtesu un méta-protocole d’invocation via HTTP et les opérations de base (GET, POST, …) ou

SOAPu l’extensibilité via le protocole CGI, les servlets et le code mobile (applets)

q Deux approchesu Environnements Java sur le web

v un langage à objet ("pour tout faire")v une machine virtuelle universelle (JVM)v une désignation uniforme via les URLsv un protocole d'invocation via RMIv passerelles vers des environnements Corba et Com/Dcom/.Net

u Framework .Netv Tout composant peut être accéder par le Webv ASP : programmation de « servlet » dans différents langagesv ADO : accès aux donnéesv …

32

Informatique nomadique/mobilemobile computingq utilisateurs nomades et équipements portablesq réseaux sans fil* connectivité à l'Internet

Wireless WAN (GSM, CDPD, UMTS...)

Wired or Wireless LAN(WaveLAN, HiperLAN,..)

john@work

john@outside

Picocellular MAN

john@ home



33

Informatique personnelle omniprésenteUbiquitous computing

Fournisseur de serviceFournisseur d’infrastructure logicielle

34

Évolution de la capacité de calcul

1950

1960

1970

1980

1990

2000

2005

18

16

14

12

10

8

6

4

2

Ventespar an

Mainframe (N personnes, 1 calculateur)

PC (1 personne, 1 calculateur)

Ubiquitous computing(1 personne, N calculateurs)



35


Planq Méthodes et outils de développement

q Logiciel de base : infrastructures pour applications réparties

q Comparaison (très rapide/partielle/partiale) de bus logiciels disponibleset quelques travaux en cours

u EJB, CORBA, .Netu Adaptabilité, Interaction

q Modes de développement du middlewareu Quelle place pour le logiciel libre ?

36

Principaux apports du modèle EJBMise en évidence de plusieurs catégories de

« programmeurs »

Fournisseur d’EB

Assembleur d’application

L’installateur

Fournisseur de conteneur EJB

Fournisseur de serveur EJB

Développementde l’application

Enterprise Bean (EB)

Application

Conteneur

Serveur

Déploiement et exécution

ProduitUtilise

Développementdu serveur

EJB



37

Principaux apports du modèle EJB

q Fournir un modèle de développement uniforme pour les applications qui utilisent les composants EB

u Contrat coté clientv fournir une vue uniforme du bean

au client. En particulier cette vue est indépendante de la plate-forme de déploiement

u Contrat coté conteneurv permettre la portabilité des beans

sur différents serveurs EJBu Contrat coté “packaging” (ejb-jar

file)v fournir un format de fichier

standard pour “packager” les beans. Ce format doit être supporter par tous les outils liés aux EJB

clientEnterprise

Bean

EBJ conteneur

Contratconteneur

EJB serveur

Contratclient

Fichier ejb-jar

Contratparckaging

Préciser plusieurs niveaux d’interfaces

38


q Persistanceu JDBC u Call back : ejbCreate, ejbStore, ejbLoad, ejbFindu Bean managed ou container managed

q Transactionu Modèle XA (transactions plates) de l’X/OPENu Définition d’attributs dans le descripteur du bean :

v TX_NOT_SUPPORTED, TX_REQUIRED, TX_SUPPORTS,TX_REQUIRES_NEW, TX_MANDATORY, TX_BEAN_MANAGED

q Sécuritéu Basé sur l’API sécurité de Java (javax.security)u Délégué au conteneur (javax.ejb.EJBContextinterface)u Utilisation d’attributs de sécurité défini dans le descripteur du bean utilisé lors de la

phase de déploiementv runAsMode, RunAsIdentity

Spécifier les propriétés du composants de manière externe



39


Client

AccountHome

AccountBean

newInstance()

setEntityContext()

ejbCreate(...)

AccountEJB Object

Begin

setBalance()

commit

setBalance()

Base De

DonnéesRelationelles

Create(...)

Account Ref

JDBC / XA

Mise en place d’un mécanisme d’interposition…

40

Mécanisme d’interposition……Basé sur un descripteur de déploiement


Home interface AccountHome

Account

AccountBean

“AccountHome1”

TX_SUPPORTS

DataSource name...

Remote interface

Enterprise Bean

BeanHomeName

ControlDescriptors

Env. properties

AccountDeploymentDescriptor

ContainerManagedFields accno, customer,balance



41Plate-forme : J2EE

Principaux apports du modèle J2EEUne architecture complète pour « programmer » Web

Conteneur Web Conteneur EJB

Services

Java 2 SDK – édition standard

Sevlet JSP EJB

transactions messages mail connecteurs

RMI JDBC JNDI CORBA

42

Principaux apports du modèle J2EEUne architecture complète pour « programmer » Web

Serveur Web Conteneur EJB

J2EE plate-forme

EJB

EnterpriseInformation

System

EJB

EJB

Server-sideBusiness Logic

Server-sidePresentation

Client-sidePresentation

Navigateur

Station

Autres terminauxJ2EE plate-forme

JSP

JavaServlet

JSP

HTML

Javaapplet

Application Java

Client J2EE



43

Principaux apports du modèle J2EEUne multitude d’acteurs – réelle interopérabilité

ServeurWeb

Serveurmétier

Ressources

SGBD

Navigateur Connecteurs

NavigateurApplet JavaApplication JavaPDATéléphones WAP…

HTML statiqueHTML dynamiqueJSPServeur de scriptWML, XHTML, WML,Servlet…

BEA WeblogicIBM WebSphereSun iPlanetEJBsWorkflow Engine…

JDBCOBDCCICS GatewayJNDICorba…

Base de donnéesS.G.FE.R.P…

Fichier

Legacysystem

44

Principaux apports des composants CORBA

q Un modèle de composants interopérant avec EJBu On n’ignore pas/plus le passéu Modèle proche qui étend le modèle EJB

v La structure d’accueil et les conteneurs gèrent les composants et leurs propriétés non fonctionnelles

v Description des services fournis, mais aussi de ceux utilisés (synchrones, asynchrones, …)u Utilisation de différents langages, choix plus large de services

q Décrire le déploiement, la configuration et la compositionu Description d’un assemblage de composants (architecture logicielle)u Prise en charge IMPLICITE par description des propriétés non fonctionnellesu Les composants et assemblages sont déployés sur une architecture physiqueu Technologie de packaging pour déployer des binaires

v issus de différents langagesv de différents fournisseurs

u Propriétés recherchéesv interopérabilité entre les produitsv portabilité des composants

Une extension au modèle EJB



45

Distributeur de boisson

ComposantDistributeur

on/off

Dépanneur

Fournisseur

Client Prise de courant

Température

Référencede base

Plus de monnaie

Fac

ette

s

Puit d’événements

Imp

lantatio

n

FO

UR

NIT

UT

ILIS

E

Réceptable

Source d’événements

Attribut

Prise d’eau*

Vide *

46

Evaluation du modèle de composants

ù Capturer ce qui est fourni :ù propriétés configurables (attributs)

ù facettes (modularité)ù puits d’événements (asynchrone)

ù opérations (synchrone)

ù Capturer ce qui est utilisé :ù réceptacles simples ou multiples

(synchrone)ù sources d’événements (asynchrone)

ù Introspection

ù fonctionnelle (IFR)ù structurelle (API de navigation)

÷ Co-localisation de toutes les ports d’un composant

÷ facettes, puits, sources d’événements

÷ Pas d’agrégation÷ pas de « design pattern » contenant - contenu÷ un composant peut référencer des objets /

composants distants mais alors ils ne font pas parties du composant

÷ Faible expression de la cardinalité des ports

÷ plusieurs instances pour une facette (ex. 1 par client)

÷ réceptacles multiples => fixé à l’exécution

÷ Les ports sont décrits statiquement !÷ impossible d’en ajouter dynamiquement

÷ Sûrement d’autres critiques ?



47

Principaux apports du CCM

q Le langage OSD = Open Software Descriptionu introduit au W3C par Marimba et Microsoftu une DTD XML

q Étendu par l’OMG pour prendre en compte les besoins pour les composants CORBA

q Utilisé pour les descripteurs, 4 DTD XML pouru le Software Package Descriptoru le CORBA Component Descriptoru le Component Assembly Descriptoru le Property File Descriptor

q Un assemblage de composants est déployé par un outil de déploiement fourni par les vendeurs

q L’outil de déploiement interagit avec l’utilisateur pour choisir les machines et les processus

q L’application de déploiement interagit avec des structures d’accueil sur chacune des machines

u Installation, AssemblyFactory, Assembly,u ServerActivator, ComponentServer, Container

Déploiement

48

descripteur de package logiciel

q Décrit un package de manière globaleq Inclut des informations générales sur le composant et des spécifiques

sur les implantationsu <softpkg> avec name et version, <pkgtype>u général : <title>, <author>, <description>,

<license>u interface : <idl>u propriétés : <propertyfile>u dépendances : <dependency>u implantation : <implementation>, <os>,

<processor>, <compiler>, <code>, ...u informations spécifiques au composant <descriptor>



49

Le descripteur de composant

q En grande partie généré à partir du CIDLu informations techniques sur la structure de l’implantation

q Complété par l’utilisateur pour fixer :u <persistentstoreinfo>u <transaction>u <eventpolicy>u <threading>u <configurationcomplete>u <poapolicy>

50

Le descripteur d’assemblage

q Décrit la configuration initiale (mais virtuelle) des maisons, des instances de composants et des connexions

q Incluant des sections pour décrire :u la liste des archives de composantsu le partitionnement des instances de composantsu les connexions entre ces instances

v uses et providesv emits / publishes et consumes



51

Évaluation du modèle de déploiement

q Les points forts :u format de diffusion de packages logicielsu plusieurs implantations d’un même composantu description des connecteurs (architecture)u configuration des propriétés non fonctionnelles

q Les points faibles :u un assemblage ne peut pas être un composant !u pas de notion de connecteurs d’adaptation pour gérer l’impédance entre des composants

non compatiblesu peu d’API pour l’interopérabilité entre outils de déploiement et structures d’accueil

v le même fournisseur pour tous les outils ! -)

52

SOAPSOAPn N’importe quel client peut appeler le service (utilisation du protocole SOAP)

SOAPSOAPContract LanguageContract Language

n Chaque service est défini par son interface exprimée en XML

SOAPSOAPDiscoveryDiscovery

n Interrogation/Recherche des services Webdisponibles sur ce site

n Seul les protocoles de l’Internet sont utilisés

XML, XSDXML, XSDHTTP, SMTPHTTP, SMTP

Apport du dernier né… la plate-forme .Net

OpenInternet

Protocols

Web Web ServiceService

Rendre accessible depuis l’Internet tous les composants



53

Apport du petit dernier….Net

Base Class Library

Common Language Specification

Common Language Runtime

Data and XML

VB C++ C#

Visual S

tudio.NE

T

WebServices

JScript …

UserInterface

Programmer un composant avec plusieurs langages

è système de type commun è C#

Class Loader

IL to NativeCompilers

CodeManager

GarbageCollector

Security Engine Debug Engine

Type Checker Exception Manager

Thread Support COM Marshaler

Base Class Library Support

54

L’évolution (révolution)dans le “monde” Microsoft

Avec .Net, tous les composants sont construits sur le même substrat…

Il n’est pas nécessaire de leur ajouter quelque chose pour les rendre interopérable

COM / DCOM .Net



55

Simplifier le déploiement et l’administration


q Assemblagesu Unité de déploiement, de gestion de version et de sécuritéu Proche d’une DLLs, mais auto-descriptible (manifeste)

q Installation sans « effet de bord »u Applications et composants peuvent être partagés ou privés

q Exécution Side-by-sideu Plusieurs versions du même composants peuvent co-exister, éventuellement dans le

même processus

56


ASP+ Application


app.aspx<HTML><script>… <<langage<< au<< choix

</script>…</HTML>

Windows

Web Controls

HTTP

DBMS

ADO+

IIS

ASP+ Applications : Accès depuis un navigateurWeb Control = formulaires / ASP = servlet / ADO = base de données



57


Windows

SOAP

ASP+ Applicationapp.asmx

class X {[WebMethod]public int Method1() { … }

}ADO+

IIS

DBMS

ASP+ Applications : utilisation d’un service Web


58

DBMS

q Une interface pour accéder aux services de persistancesu Implémentation fournie par Microsoft ou par les fournisseurs de base de données

q Classes de base dans ADO+u Connection, Command, DataSet

ADO+


.NET Application Managed Provider

Apport du petit dernier….NetADO+ : accès aux systèmes d’information



59

Un point de vue personnel…q Chaque plate-forme apporte son lot « d’innovation » en particulier sur

l’interopérabilitéu E.J.B : mono-langage – multi-p late- forme – MVu CCM : multi - langage – multi -plate- forme – intégration au niveau IDLu .Net : multi- langage – (mono)-plate- forme – intégration par un système de type commun + MV

pour ce système de typeu Mais c’est plus une évolution qu’une véritable révolution

q On aura du mal à concurrencer les grosses machinesu On == les équipes de recherche universitaires

v Impossibilité d’évaluer en permanence des plates-formes qui évoluentv nécessité d’un véritable partenariat avec des industriels

u Pour comprendre les problèmes et les enjeuxu Trouver les fondements et préparer nos enseignements

v Difficulté de retrouver le « signal » à l’intérieur du « bruit »v Difficulté de surfer sur la vague

q Mais il reste de très nombreuses nichesu Comment étendre le middleware et les composants qui s’exécutent ?u Comment faire interagir des composants ?u Comment décrire le comportement d’un composant, d’un assemblage, …

u … on peut en trouver de nombreux autres … mais celles -ci concernent les activités de RAINBOW…

Je suis à la bourre

60

Objectifs

Construire simplement des Applications Réparties

q dans de nombreux domaines d'application de l'informatique répartie, on constate une évolution de plus en plus rapide des besoins et des conditions d'utilisation.

q Les applications et le système qui supportent son exécution doivent être adaptable :

u Par rapport aux besoins exprimés par les différents acteurs (concepteurs, intégrateurs, utilisateurs finals, administrateurs), tant en ce qui concerne les fonctions de l'applications que ses propriétés non-fonctionnelles (sécurité, disponibilité, qualité de service, persistance des données, etc.).

u Par rapport à l'environnement de l'application (disponibilité de ressources, qualité des connexions et des transmissions, etc.).

q L'adaptation peut prendre différentes formes (changement de structure, de contenu, de localisation des programmes ou des données, etc.), et peut être statique ou dynamique.

u L’adaptation peut concerner : les composants, les interactions, le middleware, …u Des exigences de réactivité imposent souvent une adaptation dynamique.



61

Observations...q Ecrire efficacement des applications réparties est difficile

u Le « contour » de l ’application est mal définiu Un domaine particulier nécessite un environnement approprié (OS+langage)u La plupart des OS sont rigides et évoluent difficilement

q Evolution des besoins applicatifs…u Les environnements d'exécution existants sont peu appropriés aux applications

modernes :v travail coopératif, multimédia, mondes virtuelsv systèmes embarqués, cartes à puce, téléphonie mobilev réseaux actifsv etc…

u Caractéristiques de ces applications : répartition géographique des utilisateurs et des ressources, nombres et localisations non connus a priori - non stables

v forte contrainte de sécurité (données sensibles, copyright, droits d'accès),v modèles de données complexesv configurations dynamiques de partenaires hétérogènes

q Evolution du « support matériel »...u Les performances augmentent, les prix et la taille diminuentu et les OS "classiques" n'ont pas le temps de suivre

62

Construction d'applications réparties

q Middleware extensibleu Extensible

v pour le spécialiser par domaine d ’applications, par type de matériels (stations, portables, PDA, téléphones, …)

v parce qu ’il est impossible de prévoir à l'avance tous les usages et les évolutions technologiques

u ex : utilisation du téléphone cellulaire pour surfer sur la toile, passer des commandes

u Extensible à la voléev il est parfois impossible d ’arrêter un système pour le modifier :

u application de télécommunication, applications embarquées (satellites)u Interopérabilité entre divers domaines/applications

v pour la réutilisation des logiciels existantsv pour l'échange de données entre applicationsv pour permettre la mobilité (code et/ou donnée)

u sécurité, efficacité, panneu Même ensemble d ’outils et de services

v au-dessus de systèmes existants ou pouvant existerv sur des machines nues



63

Construction d'applications réparties

q Adaptabilité de l'applicationu aux besoins des utilisateurs

v personnalisation d'une applicationu réutilisation et configuration

v changement de la structure d'une applicationu reconfiguration statique ou dynamiqueu installation « au fil de l ’eau » : ex. connexion à un service depuis une borne

interactiveu aux conditions de l'environnement d'exécution

v adapter le fonctionnement de l ’application aux disponibilités de ressources de l ’environnement : processus, mémoires, bande passante, …

v adapter le fonctionnement de l ’application aux services réellement disponibles

q l ’adaptabilité peut prendre différentes formesu changement de structure, de contenu, de localisation du code ou des

donnéesu changement dynamique ou statique

64

PLUM

q Plate-forme Logicielle pour Usagers Mobiles ayant accès à un service distant (application mobile de type « VHE » Virtual Home Environment)

u soutien aux élèves hospitalisés alternant séjours à l ’hôpital et à domicileu critères de flexibilité, d ’adaptation et d ’extensibilité

q mise en œuvre effective d’une grande application répartie à partir des technologies composants (« adaptables »)

u Application baghera

Based ’exerciceset de cours

Démonstrateur

médiateur

tuteur

assistant

compagnon



65

L’application Baghera (1/3)

Ecole

Base d’exercices

Boites aux lettres

Cartables

Interface élèves

Interface professeurs

Interface administrateurs

66

L’application Baghera (2/3)interface Mailbox extends JavaPodInterface {Vector getMails ();void addMail (Mail mail); void removeMail (int index);void removeMails (); void addListener (MailListener listener);

}

interface ElectronicCase extends Mailbox {

Vector getExerciseList ();void addExercise (String exercise);void removeExercise (String exercise);

Solution getSolution (String exercise);

void proposeSolution (String exercise, AnnotatedFigure solution);void confirmSolution (String exercise);

void proposeCorrection (String exercise, AnnotatedFigure correction);void confirmCorrection (String exercise);

}



67

L’application Baghera (3/3)

interface VirtualSchool extends JavaPodInterface {

Vector getStudents ();void addStudent (String name, String professor);void removeStudent (String name);

String getProfessor (String student);ElectronicCase getElectronicCase (String student);

Vector getProfessors ();void addProfessor (String name);void removeProfessor (String name);

Vector getStudents (String professor);Mailbox getMailbox (String professor);

void transferStudent (String student, String professor);

ExerciseRepository getExerciseRepository ();}

68

Propriétés non-fonctionnelles

q Persistance :u pour les cartables, les boîtes aux lettres...u Mais possibilité de choisir le support et la mise en œuvre

v Fichier, BD, …

q Protection :u un élève ne doit pas avoir accès aux cartables des autres élèves, aux

solutions des exercices...u Mais possibilité de déconnecté le mécanisme

v Par exemple sur mon poste de travail je ne dois avoir que « mes » objets… et donc ne pas payer le coût des mécanisme liés à la protection

q Mode déconnecté :u travail sur une copie partielle des composants persistants, puis

réconciliationu Le protocole dépend du type de données utilisée

v Documentsv Agendav Annuairev …



69

Architecture de la plate-formeq Objectifs = trouver une architecture de plate-forme middleware

permettant :u d’associer des propriétés non fonctionnelles (persistance, mobilité, protection…) aux

applications, de façon « orthogonale »u de programmer séparément chaque propriétéu de composer plusieurs propriétésu d’ajouter de nouvelles propriétés (composables avec l’existant) au fur et à mesure :

plate-forme extensible

Serveur

ConteneurTalon

SqueletteS

C2

C1

Connecteur

70

eJavaq Qu ’est-ce que c ’est ?

u Un sur-ensemble de Javav nouvelles catégories d ’objets : objets extensibles et extensions

u class C extends ExtensibleObjectsu class D extends Extensionu C o = new C() ; o.addExtension (new D())

v même syntaxe que Java, sémantique étendueu Mise en œuvre par compilation

v modification d ’un compilateur Javau Sert de base au noyau extensible JavaPod

v Permet d’utiliser réception, émission de message comme point de jonction pour insérer le code technologique et pour assembler les propriétés

v peut être utilisé indépendamment

q C’est un outils, autres approchesu Reflexivité, méta-programmation, …

Un outils

Classe C

Objet o

Instance de Classe D

Objet O

Instance de

Classe C

hérite de

Modification dynamiquede l ’héritage



71

S

C2

C1

Implémentation : persistance

invoke : sérialiser après chaque appel en écritureinvoke : sérialiser après chaque appel en écriture

table {méthode → mode (R ou W)}table {méthode → mode (R ou W)}

getComponent : charger depuis le disque si besoingetComponent : charger depuis le disque si besoin

72

S

C2

C1

Implémentation : protection

invoke : vérifier les droits avant chaque appelinvoke : vérifier les droits avant chaque appel

table {méthode → droits d’accès}table {méthode → droits d’accès}



73

Mécanismes d’interaction

q Travaux de Rainbowu Comment étendre le middleware et les composants qui s’exécutent ?u Comment faire interagir des composants ?u Comment décrire le comportement d’un composant, d’un assemblage, …

q Interaction = possibilité d’assembler à la demande des « services existants »

Je suis à la bourre

74

bankClient account1 account2

credit()

debit()

Transfert d’un compte sur un autre.

© 2000Laurent Bussard

Rainbow Project (I3S)

Comment utiliser des services Corba?

Les interactions : principe



75

q D’après l’OMG, ”Les services sont aussi compliqués que nécessaire« .

q Dans la pratique,u leur utilisation peut être complexe

v Il faut modifier le code originalpour insérer les appels au service

u Leur utilisation n’est généralement pas décritev Il faudrait publier leur fonctionnement



BankClient

transfert()Begin transactiondebit()credit()Commit / Rollback

Transac-tion

begin()rollback()commit()

Begin transCommitRollback

Get service

Begin transCommitRollback

Utilisation des services Corba

Account

debit()credit()rollback()

Account

debit()credit()rollback()

76

BankClient Account

Classes:bankClient ' account1' account2'

credit()

debit()

Transaction Service

begin trans

commit / rollback trans

save()

save()



New behaviour:

BankClient' Account' . . .

Transaction

Targets

recoverable class Account {

transactional * credit()transactional * debit()

}

class BankClient{

transactionalAction * makeTransfer()}



Service de Transactions

q Utilisation habituelleu Par construction d’une sous classe



77

Une approche possibleq Utilisation d’un service d’interaction

u pour décrire de manière externe, le nouveau comportementq Utilisation d’un mécanisme d’extension

u pour ajouter si nécessaire le comportement de l’objet mémoire

q Solution « partielle »Interaction object2memoire (…)

ObjectRecoverable.* èMemoire.saveState(ObjectRecoverable);ObjectRecoverable.*

ObjectRecoverable.commit() èMemoire.validateState(ObjectRecoverable)

ObjectRecoverable.rollBack() èMemoire.restoreState(ObjectRecoverable)

78

q Et on recommence…u Nouvelles classes par héritage

q Ou nouvelle interactionInteractionInteraction producteur2Channel(…)producteur2Channel(…)Producteur.* Producteur.* èè Producteur.* ; Channel.Producteur.* ; Channel.pushpush(new (new EventEvent())())

Account

Classes:bankClient account1' account2'

credit()

debit()

EventChannel

send event

send event

New behaviour:

Account' . . .

Event

Targets

eventSender class Account {

sender * credit(..)sender * debit(..)

}



Service des Événements



79


credit()

debit()

Transaction

begin trans


save()

save()



EventChannel

send event

send event


credit()

debit()

Transaction

begin trans


save()

save()



EventChannel

send event

send event



Et si l’on veut composer les services

q Abstraction de la composition:v Au cours de la transaction à Enregistrer les événements. v Réussite de la transaction à Émettre les événements enregistrés.v Échec de la transaction à Supprimer les événements enregistrés.

q Construction d’une nouvelle interaction (qui sera réutilisable)InteractionInteraction freezefreeze(x,c)(x,c)x.* x.* --> if this.> if this.currentMessagecurrentMessage..inTransactioninTransaction()()

thenthen c.c.freezefreeze() end if; x.*,() end if; x.*,x.commit() x.commit() --> x.commit() // c.> x.commit() // c.emitemit()()

80

Quelques résultats… partielsq associer des propriétés non fonctionnelles aux applications,

de façon « orthogonale » :u Persistance, transaction, protection, évènement…u mode déconnecté : séparation incomplète du code fonctionnel

q programmer séparément chaque propriété :u Il peut rester des dépendances implicites (adresse pour appel di stant…)

q composer plusieurs propriétés :u On peut composer à la main…

v Composition interneu On peut proposer des modèles d’« interactions » (réutilisation)

v Composition externeu Pbs : construire des modèles de modèles

v Choix et ordonnancement automatique des extensions, en fonction d’une description de haut niveau (descripteur de déploiement)

q plate-forme extensible :u On peut faire beaucoup de chose - Optimisations pour le cas « statique »u On ne sait pas tout faire

v ex : ajouter un GC serait difficile



81


Planq Méthodes et outils de développement

q Logiciel de base : infrastructures pour applications réparties

q Comparaison (très rapide/partielle/partiale) de bus logiciels disponibleset quelques travaux en cours

q Modes de développement des middlewaresu Quelle place pour le logiciel libre ?

82

Modes de développement du logicielq Objectifs

u maîtrise de la complexité u réduction des coûts de développement et de maintenance

q Approchesu consensus : normes (protocoles et/ou interfaces) pour

v Portabilité, interopérabilitéu développement coopératif

v mutualisation des efforts de développement

q Des points de vue contradictoiresu le point de vue du vendeur : systèmes ouverts

v normalisation d'un protocole et/ou d'une interfacev mutualisation de l'effort de spécificationv mise en œuvre propriétairev exemples : IETF, OMG, W3C, . . .

u le point de vue du développeur : logiciels libres ("open source")v développement (et debug) coopératif

* mutualisation de l'effort (et des coûts) de développement* maîtrise des évolutions

u le point de vue de l'utilisateur :v oui aux logiciels libres . . . mais à condition qu'il y ait un support de qualité industrielle



83

Logiciel libreq Des success stories

u logiciels : GNU, X11… - systèmes : FreeBSD, Linux… - serveur Http : Apache - langages : Tcl /TK, Perl… – système Linux : Red Hat, Caldera et de nombreuses PME en France…

. . . Mais aussi quelques ratés :u Netscape : Mozilla ?????

q Un nouveau modèle de développement de logicielu "la cathédrale et le bazar" (Eric Raymond)

v taille du bazarv méthode de travail au sein du bazar

u consensus (modèle Apache) : collège d'architectesu autocratique (modèle Linux )

q Quel modèle économique pour les logiciels libres ?u "free software needs profit" (John Ousterhout)

u support, maintenance, services, solutions "clés en main"*modèle :

v partage des coûts de développementv maîtrise et pérennité d'une technologiev "business" non pas sur la technologie mais sur son exploitation

84

ObjectWeb

qContexteuanalyse des besoins

v plate-forme Corba complète (ORB + services)v plate-forme RMI v serveur d'application EJBv portabilité et extensibilitév Utilisation simultanée de différents modèles

uanalyse de l'offrev de multiples offres Corba - aucune complète v technologie Java-RMI contrôlée par Sunv effort de développement important - coût exhorbitantv Peu de passage d’un modèle à l’autre

qObjectifufournir une plate-forme d'applications réparties à objets

v générique : env. Corba, env. RMI, env. EJB, . . .v extensible : ajout de fonctionnalitésv open source : effort de développement et coûts mutualisés



85

ObjectWeb (2)

q Initiative de France Telecom R&D + Inria (Sirac) + Bull (EJB)+ Lutris (Enhydra)

u développement d'une plate-forme d'applications réparties à objets extensible et libre

Micro-ORB Jonathan

JVM

Jeremie(personnalité RMI)

David(personnalité Corba)

Jonas(personnalité EJB)

Applications réparties(objets/composants)

??(nouvelle personnalité)

86

ObjectWeb (3)

q Projet RNRT Parol (99)u mise en place d'une communauté de développement

pilotée par : Cnet, Inria (Sirac), Afnoru soutien financier du ministère (matériel, ingénieurs, . . .)u projet de 18 mois

v consolidation base de codev comité d'architectesv outils de développementv diffusion

q Projet RNTL ARCAD (00)u systèmes extensiblesu applications adaptables

v évolution des besoinsv prise en compte des changements de l'environnement d'exécution

q Projet RNTL IMPACT (01 ?)u Enrichir la plate-forme avec ce qui existe dans les équipes de recherche



87

. . . et pour finir . . .

88

Quelques pointeurs

q Programmation par composantshttp://www.omg.orghttp://www.sun.comhttp://msdn.microsoft.com/net

http://corbaweb.lifl.fr (les rois de corba)

q Informatique mobilehttp://www.symbian.comhttp://www.palm. com

http://www.inrialpes.fr/planetehttp://www.inria.fr/rodeo

q Systèmes ouvertsOMG http://www.omg.orgWeb Consortium http://www.w3C.orgOpen Group http://www.opengroup.org

q Logiciels libresAFUL http://www.aful.orgpage Open Source http://www.opensource.orgFree Software Foundation (GNU) http://www.fsf.orgApache (serveur Web) http://www.apache.orgRedhat (Linux) http://www.redhat.comCygnus (GNU) http://www.cygnus.comEx-Office (objet, Java)) http://www.exoffice.comOpen Care (tous logiciels libres) http://www.ocare.com

ObjectWeb http://www. objectweb.orgEnhydra (XML/Java) http://www.enhydra.org

RNTL ARCAD http://arcad.essi.fr



89

C’est fini

http://www.essi.fr/~rainbow