SlideShare une entreprise Scribd logo
Théorie et Pratique du Système d’Information
Troisième Chapitre: Composants du SI
Janvier-Mars 2012
Ecole Polytechnique
Yves Caseau

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

1/26
Plan du Cours – Composants du SI
Première partie:
Le « Système Technique »
 Deuxième partie:
Infrastructure d’intégration
 Troisième partie:
Make/buy/rent : software ecosystem


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

2/26
Première Partie: le Système Technique

Sous-Systèmes du SI


Le SI est « fractal », ses composants sont des SI


Qualifiés de « macro-ST » à Bouygues Telecom

Une « brique » (sous-système) est un ensemble d’applicatifs
associés à un ensemble de ressources
 Schéma inspiré/extrait de « Architecture Logicielle » de J.
Printz


Système
applicatif
applicatio
n
exécutable

exécutable

bibliothèques

threads

process

scripts

DLLs, …

threads

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

3/26
Première Partie: le Système Technique

Système Technique
Chaque système technique dispose de ses ressources, allant du
PC à un ensemble de serveur spécialisés
 Les ressources peuvent être distribuées






Les ressources peuvent être mutualisées




Ex: GRID computing
Partage entre plusieurs systèmes applicatifs

Les ressources peuvent être virtualisées



Découpage logique d’une ressource en plusieurs « machines virtuelles »
Classique pour le stockage, tendance de fond pour les serveurs

Postes
de
travail

Postes
dePostes
de
travail
travail

Serveurs
Serveurs
Serveurs
de calcul

Ressource de
stockage
Ressource de
stockage

Back-up

Intfrastructure : réseau / servitudes

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

4/26
Première Partie: le Système Technique

Cycles de développement et Intégration


Le cycle classique de développement est souvent représenté
par un V
Expression Besoin

Mise en Service
Tests exploitabilité

Spécification

Spécifications
fonctionnelles

Intégration

Architecture système

Conception

Architecture
logicielle

Tests unitaires
Tests unitaires
techniques

code

Développement

Tests fonctionnels

Tests

Intégration logicielle

Zone spécifique
au métier / à
l’entreprise

On parle également de cycle en W pour représenter
l’intégration de plusieurs composants/projets dans un même SI
 Cf. Meinadier
Intégration
Ingénierie


système

système
Coordination

Réalisation des composants
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

5/26
Première Partie: le Système Technique

Composants


Principe d’un composant (Printz/Spyzerski)






Propriétés clés







Réutilisable
Scalable (sans état) => gestion du contexte en paramètre
Définition « unité de déploiement indépendante, utilisable via des
tiers via ses interfaces, dont l’état interne n’est pas observable »
Intégration tardive
Test modulaire (indépendants)
Standardisation (écosystème interne/externe)
Contrats

La notion de composant est transverse dans le SI (multi-échelle)





Composant logiciel
Serveur d’application – SOA local
Services métiers SOA global
Mais aussi: requêtes BD (services Tuxedo – moniteur transactionnel)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

6/26
Première Partie: le Système Technique

Architecture Client-Serveur


L’architecture client-serveur est le classique des années 80-90,
apparue avec l’informatique départementale





Mainframe : batch + terminal
PC + serveur

Une typologie qui évolue au cours des années (avec
balancier)





Client lourd
Client léger
Client riche (ex: Ajax)
Avantages/inconvénients: déploiement / performance / ergonomie

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

7/26
Première Partie: le Système Technique

Architecture en Couches


L’architecture en couche est aussi ancienne que la
programmation






Ex: Dijkstra, 1968
Base des architectures de protocole de communication
Exemple : 7 couches du modèle OSI

Outil de modularité




Correspond à une structure d’arbre orienté (hiérarchique)
Impacts en O(log N)
Cf. DSM
(dependency structure matrix
chapitres suivants)



Plusieurs « patterns » orientés




Vertical
 Par niveau d’abstraction (chaque couche ignore les détails de l’autre)
Horizontal
 Par étape de processus/ transformation (irréversibilité du temps)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

8/26
Première Partie: le Système Technique

Architecture 3-tiers


Evolution naturelle du modèle client-serveur:





Découplage traitement - données
Orientée-scalabilité : capacité à démultiplier les ressources de
traitement
Solution technique: Serveur d’application
IHM

Services Métiers

Présentation

Traitements

Visualisation IHM
Services
Présentation



Accès aux
données

Logique Métier

Services
élémentaires

Objet Métiers

Accès

S’étend naturellement au N-tiers en décomposant le traitement
selon une architecture en couche:



Serveurs d’applications Web (frontal de clients légers)
Serveurs d’intégration (entre traitement et données)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

9/26
Deuxième partie
Le « Système Technique »
 Infrastructure d’intégration
 Make/buy/rent : software ecosystem


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

10/26
Deuxième Partie:Infrastructure d’intégration

Web Services


“Web services are frequently just Web APIs that can be
accessed over a network, such as the Internet, and
executed on a remote system hosting the requested
services”.

SOAP / WSDL
 Styles


RPC (pattern principal)
remote procedural call
 SOA (message-based)
 REST (http emulation)




WS-* (from WS-I)


WS-security

WS-reliability
 WS-transaction




RPC: RMI (Java), Corba, DCOM (MS), XMP-RPC

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

11/26
Deuxième Partie:Infrastructure d’intégration

Bus d’intégration


Bus logiciel
pattern tiré du hardware
 Intermédiation, standardisation (interface) et
mutualisation du transport


comp
osant

Schéma iconique
de l’urbanisation

bus

Bus d’intégration = bus logiciel au niveau du SI
 Synchrone/ Asynchrone
 Exemples:


EAI (Enterprise Application Infrastructure)
architecture « Publish & Subscribe »
 ESB (Enterprise Service Bus)
 Corba


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

12/26
Deuxième Partie:Infrastructure d’intégration

Architecture SOA
événements
Applications
interactives
(ex: portail)

Processus

Batchs

Infrastructure (ex: ESB synchrone)

Annuaire
UDDI
service

service

Infrastructure (ex: ESB asynchrone)

Applicatio
ns

« Cloud »
(Internet)

Mash-ups

Propriété clés:
• Stateless
•Gestion explicite
du contexte
•Contrat de
service

Ressources

Référentiels
(données)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

13/26
Deuxième Partie:Infrastructure d’intégration

Orchestration BPM


Moteur d’orchestration
Workflow
 Processflow

BPEL

Moteur
Processus





Standardisation


BPEL4WS / XW-BPEL et les autres




Cf chapitre 6

Intégration avec serveur d’applications
– WebSphere (IBM), WebLogic (Bea/Oracle),
…



Questions à se poser/ réponse possible
Performance / distribution
 Flexibilité / moteur de règles
 Intégrité (Transactions)


Cf. chapitre 6


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

14/26
Deuxième Partie:Infrastructure d’intégration

ETL (Extract / Transform / Load)


Exemple d’architecture en couche (cf. Printz)
Application

ETL
Extract

Transform

DWH
Load

Référe
nciels



Datamarts
Application

Infrastructure d’intégration des SI décisionnels
Orienté traitement de masse
 Intégration d’outils XML volumiques (filtrages,
transformation)




Evolution vers une solution complète
EII : Enterprise Information Integration
 Intégration d’un processflow / interfaces SOA


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

Vraie
compétence
technique

15/26
Compatibilité ascendante et versions


XML est auto-décrit et extensible …




La gestion des versions est indispensable pour gérer la
complexité





Cela n’assure pas la compatibilité ascendante dans la lecture des
messages

La gestion de version introduit un « découplage temporel »
En l’absence de versions, le système doit évoluer par bloc (malgré
l’EAI

Règles pour obtenir une compatibilité ascendante (classique)





Marquer les composant des messages avec des numéros de version
Format ouvert permettant d’accepter des informations non
interprétées (le minimum … rarement implémenté)
Pilotage dynamique (quelle version de X utilise quelle version de Y)
 Déploiement facilité

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

16/26
Deuxième Partie:Infrastructure d’intégration

Intégration par le « front office » - Portail applicatif


L’intégration applicative peut aussi venir du front-office




Vision unifiée des applications
Scripts de partage d’information/ automatisation de saisie
Méthode légère d’urbanisation qui peut évoluer vers SOA

Une méthode légère et efficace d’intégration
 Architecture Web qui s’appuie de multiples outils




Une part importante d’open-source
Portail applicatif

Serveur Web
Services
Présentation
Services
métiers
Automatisation
Workflow

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

Progiciel moderne
Interface
Services

Web
Interface

Legacy

17/26
Deuxième Partie:Infrastructure d’intégration

Quel est le retour sur investissement ?
Le ROI de l’infrastructure d’intégration n’est pas simple :






L’infrastructure coûte cher
La conception est difficile -> alourdit les spécifications + essais/erreurs
Les adaptateurs sont coûteux (de 20 à 40% du développement)
Tests complexes
Exploitation et mise au point difficiles

Facteurs clés:



Age moyen (taux de refonte) -> nettoyage
Taux de renouvellement -> évolutions

Le ROI se juge avec du recul



Cycle complet de vie
Quelle est la valeur de l’agilité (cf. chapitre 5) ?
 Analyse de scénarios (avec et sans)

I.2 : Urbanisation - Questions

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

18/26
Troisième partie
Le « Système Technique »
 Infrastructure d’intégration
 Make/buy/rent : « software ecosystem »


Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

19/26
Troisième Partie: Ecosystème Logiciel

Progiciels et Logiciels Métiers


Il existe plusieurs types de « mode de fabrication » pour des
applications logicielles


Spécifique



Framework
Progiciel





Critères dimensionnants


nombres de clients

taux de couverture (générique / spécifique pour intégration)
 généricité du besoin (intersection / union)
 Taux d’évolution fonctionnel
 Contraintes de performance




Jeu à « deux acteurs »



client : make/buy (avec intégration)
Vendeur: maximiser rentabilité (pas revenu)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

20/26
Troisième Partie: Ecosystème Logiciel

Comprendre les coûts de fabrication


Coûts sont fonction du volume du logiciel (cf. Chapitre 5)



O(n 1.2) construction
O(n x m 0.5) incrément

Le volume est un compromis entre « intersection » et
«union » des besoins
 Le fournisseur gère différentes versions techniques
 Le fournisseur optimise nb_clients * (prix – cout unitaire)


Progiciel

Coût unitaire

coût
Nombre de clients

Coût total

Différentiation (l’inverse de la généricité)
Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

« le mieux est
l’ennemi du bien »
Trop de fonctions
coûte: intégration,
ressources,
complexité
21/26
Troisième Partie: Ecosystème Logiciel

Comprendre les coûts de maintenance


Cycle de vie des coûts de maintenance




Le logiciel est un produit « vivant » -> génération successive de
versions fonctionnelles
Chaque version génère un coût de maintenance





technique
correction des anomalies

Réduire les coûts


Le coût de maintenance dépend de:





Conduit à la notion de cycle: garantie/maintenance/maintenance
étendue/maintenance spécifique (sur demande)




Nombre de versions en activité
Nombre de clients (taux de découverte des anomalies)

Pression sur les clients pour faire « migrer » de façon ascendante

La maintenance est une composante du prix qui est moins bien
comprise par les clients


d’où l’idée de « louer le logiciel » en tant que service

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

22/26
Troisième Partie: Ecosystème Logiciel

ASP et SaaS


ASP (Application Service Provider)





Hébergement applicatif
Le service correspond à la « location par appartement » d’une
plateforme
 Ex: CRM, SFA (Salesforce)

SaaS (Software as a Service) : nouveau nom / concept marqué
par le « cloud computing »


Multiplicité des fournisseurs

coût

Capacité
à
évoluer

Effet complexité
Synchroniser les besoins

Nombre de clients
spécifique

framework

framework
ASP

spécifique

COTS

COTS
ASP

Différentiation (l’inverse de la généricité)

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

Complexité du besoin

23/26
Troisième Partie: Ecosystème Logiciel

Open Source


Qu’est-ce l’open-source  ?






Avantages





Coûts  (même avec les coûts cachés)
Réactivité

Contraintes d’utilisation





Développement et maintenance confiée à une communauté d’intérêt
bénévole (même si des services rémunérés existent – cf. UNIX)
QoS : fonction de la taille de la communauté (généricité du logiciel) et de
l’implication (généricité de la demande)

Culturel: les développeurs parlent aux développeurs
Généricité : la QoS dépend de la mutualisation du besoin

Critères de JP Rangaswami (
http://confusedofcalcutta.com/2008/07/19/thinking-about-opensource
)




Général => open source
Industrie => progiciel
Entreprise-spécifique (différenciant) => développement

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

24/26
Troisième Partie: Ecosystème Logiciel

Grid Computing and Cloud Computing


Grid: utiliser une « ferme » d’ordinateurs en tant que superordinateur parallèle

Cloud Computing: Outsourcing du Grid (Amazon, Google,
etc.)
 Trois avantages majeurs:


Fault-tolerance à travers la redondance implicite.
 Très haute performance à travers le parallélisme massif







TCO réduit par l’utilisation de « Commodity computing »
(PC) – Ex: coût hébergement email de Google






Ex: data mining, traitement d’événements en temps réel
Cf. architecture « MapReduce » de Google

+ Économie d’échelle implicite

(1 & 2) suppose une architecture logicielle adaptée !

Le SaaS se prête très bien (souvent, architecture
moderne) au Cloud Computing

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

25/26
Limites du Cloud Computing
Le « cloud computing » est dans une phase naissance =>
beaucoup de « hype »
 Trois limites:


1.
2.

3.

Maitrise des données et de la « privacy ».
Temps de latence: Un aller-retour n’est pas gratuit (10 ms pour
3000km) => les applications transactionnelles à fort de gré
d’interaction ne sont indiquées
Surcoût d’une approche SOA externalisée
1.
Les services sont forcément à faible granularité, (s’ils était
spécialisés et complexes il n’y aurait pas la taille critique de
marché)
2.
Un RPC à travers un WS a un surcoût important
3.
On ne peut pas transformer (aujourd’hui) toutes les appels
fonctionnels en invocation de WS
–
–

« SOA is not scale-free »
C’est même vrai à l’intérieur de l’entreprise !

Copyright © Yves Caseau 2012 – Cours Polytechnique (III)

26/26

Contenu connexe

En vedette

6sigma ibtissam el hassani-chapitre 4
6sigma ibtissam el hassani-chapitre 46sigma ibtissam el hassani-chapitre 4
6sigma ibtissam el hassani-chapitre 4
ibtissam el hassani
 
Management des risques 6 : HAZOP, HAZard and OPerability
Management des risques 6 :  HAZOP, HAZard and OPerabilityManagement des risques 6 :  HAZOP, HAZard and OPerability
Management des risques 6 : HAZOP, HAZard and OPerability
ibtissam el hassani
 
Management des risque etude de cas 1 - MOSAR/MADS
Management des risque   etude de cas 1 - MOSAR/MADSManagement des risque   etude de cas 1 - MOSAR/MADS
Management des risque etude de cas 1 - MOSAR/MADS
ibtissam el hassani
 
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
ibtissam el hassani
 
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de PapillonManagement des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
ibtissam el hassani
 
Management des Risques ibtissam el hassani-chapitre 5
Management des Risques ibtissam el hassani-chapitre 5Management des Risques ibtissam el hassani-chapitre 5
Management des Risques ibtissam el hassani-chapitre 5
ibtissam el hassani
 
Management des risques ibtissam el hassani-chapitre3 : MADS/MOSAR
Management des risques   ibtissam el hassani-chapitre3 : MADS/MOSARManagement des risques   ibtissam el hassani-chapitre3 : MADS/MOSAR
Management des risques ibtissam el hassani-chapitre3 : MADS/MOSAR
ibtissam el hassani
 
Management des risques ibtissam el hassani-chapitre1-2
Management des risques   ibtissam el hassani-chapitre1-2Management des risques   ibtissam el hassani-chapitre1-2
Management des risques ibtissam el hassani-chapitre1-2
ibtissam el hassani
 
Management des risques 10 : Aspect Réglementaire et Normatif
Management des risques 10 : Aspect Réglementaire et Normatif Management des risques 10 : Aspect Réglementaire et Normatif
Management des risques 10 : Aspect Réglementaire et Normatif
ibtissam el hassani
 
Management des risques - Support de cours - ibtissam el hassani-2015-2016
Management des risques - Support de cours -  ibtissam el hassani-2015-2016Management des risques - Support de cours -  ibtissam el hassani-2015-2016
Management des risques - Support de cours - ibtissam el hassani-2015-2016
ibtissam el hassani
 
Management des risques 9 : Risques d’Entreprise et Cartographie
Management des risques 9 : Risques d’Entreprise et CartographieManagement des risques 9 : Risques d’Entreprise et Cartographie
Management des risques 9 : Risques d’Entreprise et Cartographie
ibtissam el hassani
 
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du coursLean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
ibtissam el hassani
 
Etude de cas - Ubisoft
Etude de cas - UbisoftEtude de cas - Ubisoft
Etude de cas - Ubisoft
Jean-Patrick Ascenci
 
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
Paianet - Connecting Healthcare
 
Noticias
NoticiasNoticias
Un musée sans musée?
Un musée sans musée?Un musée sans musée?
Un musée sans musée?Aurelie Henry
 
LucesDeBohemia
LucesDeBohemiaLucesDeBohemia
LucesDeBohemia
Refuerzo
 
Me divorcié
Me divorciéMe divorcié
Me divorcié
SALUD Y VIDA INTEGRAL
 
Gerencia estrategica
Gerencia estrategicaGerencia estrategica
Gerencia estrategica
andortizco
 
RESOLUCIÓN BENI
RESOLUCIÓN BENIRESOLUCIÓN BENI
RESOLUCIÓN BENI
Alejandra Prado
 

En vedette (20)

6sigma ibtissam el hassani-chapitre 4
6sigma ibtissam el hassani-chapitre 46sigma ibtissam el hassani-chapitre 4
6sigma ibtissam el hassani-chapitre 4
 
Management des risques 6 : HAZOP, HAZard and OPerability
Management des risques 6 :  HAZOP, HAZard and OPerabilityManagement des risques 6 :  HAZOP, HAZard and OPerability
Management des risques 6 : HAZOP, HAZard and OPerability
 
Management des risque etude de cas 1 - MOSAR/MADS
Management des risque   etude de cas 1 - MOSAR/MADSManagement des risque   etude de cas 1 - MOSAR/MADS
Management des risque etude de cas 1 - MOSAR/MADS
 
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
Management des risques 7 : Outils de Sûreté de Fonctionnement pour l’Analyse ...
 
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de PapillonManagement des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
Management des risques 8 : Arbre de défaillances/ d’Evénements; Nœud de Papillon
 
Management des Risques ibtissam el hassani-chapitre 5
Management des Risques ibtissam el hassani-chapitre 5Management des Risques ibtissam el hassani-chapitre 5
Management des Risques ibtissam el hassani-chapitre 5
 
Management des risques ibtissam el hassani-chapitre3 : MADS/MOSAR
Management des risques   ibtissam el hassani-chapitre3 : MADS/MOSARManagement des risques   ibtissam el hassani-chapitre3 : MADS/MOSAR
Management des risques ibtissam el hassani-chapitre3 : MADS/MOSAR
 
Management des risques ibtissam el hassani-chapitre1-2
Management des risques   ibtissam el hassani-chapitre1-2Management des risques   ibtissam el hassani-chapitre1-2
Management des risques ibtissam el hassani-chapitre1-2
 
Management des risques 10 : Aspect Réglementaire et Normatif
Management des risques 10 : Aspect Réglementaire et Normatif Management des risques 10 : Aspect Réglementaire et Normatif
Management des risques 10 : Aspect Réglementaire et Normatif
 
Management des risques - Support de cours - ibtissam el hassani-2015-2016
Management des risques - Support de cours -  ibtissam el hassani-2015-2016Management des risques - Support de cours -  ibtissam el hassani-2015-2016
Management des risques - Support de cours - ibtissam el hassani-2015-2016
 
Management des risques 9 : Risques d’Entreprise et Cartographie
Management des risques 9 : Risques d’Entreprise et CartographieManagement des risques 9 : Risques d’Entreprise et Cartographie
Management des risques 9 : Risques d’Entreprise et Cartographie
 
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du coursLean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
Lean Manufacturing _ Ibtissam EL HASSANI _ Complément du cours
 
Etude de cas - Ubisoft
Etude de cas - UbisoftEtude de cas - Ubisoft
Etude de cas - Ubisoft
 
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
L'hôpital face au défi du vieillissement et de la chronicité- Eliane Deschamp...
 
Noticias
NoticiasNoticias
Noticias
 
Un musée sans musée?
Un musée sans musée?Un musée sans musée?
Un musée sans musée?
 
LucesDeBohemia
LucesDeBohemiaLucesDeBohemia
LucesDeBohemia
 
Me divorcié
Me divorciéMe divorcié
Me divorcié
 
Gerencia estrategica
Gerencia estrategicaGerencia estrategica
Gerencia estrategica
 
RESOLUCIÓN BENI
RESOLUCIÓN BENIRESOLUCIÓN BENI
RESOLUCIÓN BENI
 

Similaire à Cours chapitre3 2012

Cours architecture
Cours architectureCours architecture
Cours architecture
Abdelaziz Elbaze
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdf
BabacarDIOP48
 
Architectures bigdata
Architectures bigdataArchitectures bigdata
Architectures bigdata
khouloud Hwerbi
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
Klee Group
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
amine17157
 
informatique_logiquarchitecture_applicative
informatique_logiquarchitecture_applicativeinformatique_logiquarchitecture_applicative
informatique_logiquarchitecture_applicative
Narjes Weslati
 
Informatique en nuage et continuité des affaires
Informatique en nuage et continuité des affairesInformatique en nuage et continuité des affaires
Informatique en nuage et continuité des affaires
Georges Cowan
 
Cloud computing
Cloud computing Cloud computing
Cloud computing
Abdelghani Akil
 
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
Nabil Bouzerna
 
Architecture .net
Architecture  .netArchitecture  .net
Transhumance pres anr_25-septembre synthese v10
Transhumance pres anr_25-septembre synthese v10Transhumance pres anr_25-septembre synthese v10
Transhumance pres anr_25-septembre synthese v10François Huguet
 
ch1-cours2016.ppt
ch1-cours2016.pptch1-cours2016.ppt
ch1-cours2016.ppt
Manellansari
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
SamirAwad14
 
client_serveur_introductionnnnnnnnnnn.PPT
client_serveur_introductionnnnnnnnnnn.PPTclient_serveur_introductionnnnnnnnnnn.PPT
client_serveur_introductionnnnnnnnnnn.PPT
radjadjouambi
 
Les Clouds: Buzzword ou révolution technologique
Les Clouds: Buzzword ou révolution technologiqueLes Clouds: Buzzword ou révolution technologique
Les Clouds: Buzzword ou révolution technologique
Frederic Desprez
 
education
educationeducation
education
guestb6689d
 
TelCar : Solution de lecture des informations de bord de véhicule
TelCar : Solution de lecture des informations de bord de véhiculeTelCar : Solution de lecture des informations de bord de véhicule
TelCar : Solution de lecture des informations de bord de véhicule
Ghassen Chaieb
 

Similaire à Cours chapitre3 2012 (20)

Cours architecture
Cours architectureCours architecture
Cours architecture
 
Les vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdfLes vrais enjeux de l'IA.pdf
Les vrais enjeux de l'IA.pdf
 
Architectures bigdata
Architectures bigdataArchitectures bigdata
Architectures bigdata
 
Architecture orientée service (SOA)
Architecture orientée service (SOA)Architecture orientée service (SOA)
Architecture orientée service (SOA)
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
 
informatique_logiquarchitecture_applicative
informatique_logiquarchitecture_applicativeinformatique_logiquarchitecture_applicative
informatique_logiquarchitecture_applicative
 
Informatique en nuage et continuité des affaires
Informatique en nuage et continuité des affairesInformatique en nuage et continuité des affaires
Informatique en nuage et continuité des affaires
 
PFE PPT2
PFE PPT2PFE PPT2
PFE PPT2
 
Temoignages clients
Temoignages clientsTemoignages clients
Temoignages clients
 
Cloud computing
Cloud computing Cloud computing
Cloud computing
 
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
La plateforme CHESS un outil pour l’analyse comparative des technologies de c...
 
Architecture .net
Architecture  .netArchitecture  .net
Architecture .net
 
Transhumance pres anr_25-septembre synthese v10
Transhumance pres anr_25-septembre synthese v10Transhumance pres anr_25-septembre synthese v10
Transhumance pres anr_25-septembre synthese v10
 
Transhumance pres
Transhumance presTranshumance pres
Transhumance pres
 
ch1-cours2016.ppt
ch1-cours2016.pptch1-cours2016.ppt
ch1-cours2016.ppt
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
 
client_serveur_introductionnnnnnnnnnn.PPT
client_serveur_introductionnnnnnnnnnn.PPTclient_serveur_introductionnnnnnnnnnn.PPT
client_serveur_introductionnnnnnnnnnn.PPT
 
Les Clouds: Buzzword ou révolution technologique
Les Clouds: Buzzword ou révolution technologiqueLes Clouds: Buzzword ou révolution technologique
Les Clouds: Buzzword ou révolution technologique
 
education
educationeducation
education
 
TelCar : Solution de lecture des informations de bord de véhicule
TelCar : Solution de lecture des informations de bord de véhiculeTelCar : Solution de lecture des informations de bord de véhicule
TelCar : Solution de lecture des informations de bord de véhicule
 

Plus de Yves Caseau

CCEM2023.pptx
CCEM2023.pptxCCEM2023.pptx
CCEM2023.pptx
Yves Caseau
 
DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022
Yves Caseau
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3
Yves Caseau
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-Tracking
Yves Caseau
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital Transformation
Yves Caseau
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the guts
Yves Caseau
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018
Yves Caseau
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018
Yves Caseau
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIA
Yves Caseau
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT Architecture
Yves Caseau
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015
Yves Caseau
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013
Yves Caseau
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012
Yves Caseau
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08
Yves Caseau
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance
Yves Caseau
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013
Yves Caseau
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015
Yves Caseau
 
GTES UTC 2014
GTES  UTC 2014GTES  UTC 2014
GTES UTC 2014
Yves Caseau
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014
Yves Caseau
 
Disic mars2014
Disic mars2014Disic mars2014
Disic mars2014
Yves Caseau
 

Plus de Yves Caseau (20)

CCEM2023.pptx
CCEM2023.pptxCCEM2023.pptx
CCEM2023.pptx
 
DataAquitaine February 2022
DataAquitaine February 2022DataAquitaine February 2022
DataAquitaine February 2022
 
Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3Global warming dynamic gamesv0.3
Global warming dynamic gamesv0.3
 
Machine Learning for Self-Tracking
Machine Learning for Self-TrackingMachine Learning for Self-Tracking
Machine Learning for Self-Tracking
 
Information Systems for Digital Transformation
Information Systems for Digital TransformationInformation Systems for Digital Transformation
Information Systems for Digital Transformation
 
Lean from the guts
Lean from the gutsLean from the guts
Lean from the guts
 
Taking advantageofai july2018
Taking advantageofai july2018Taking advantageofai july2018
Taking advantageofai july2018
 
Software Pitch 2018
Software Pitch 2018Software Pitch 2018
Software Pitch 2018
 
Intelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIAIntelligence Artificielle - Journée MEDEF & AFIA
Intelligence Artificielle - Journée MEDEF & AFIA
 
Big data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT ArchitectureBig data, Behavioral Change and IOT Architecture
Big data, Behavioral Change and IOT Architecture
 
XEBICON Public November 2015
XEBICON Public November 2015XEBICON Public November 2015
XEBICON Public November 2015
 
Smart selfnovember2013
Smart selfnovember2013Smart selfnovember2013
Smart selfnovember2013
 
Management socialnetworksfeb2012
Management socialnetworksfeb2012Management socialnetworksfeb2012
Management socialnetworksfeb2012
 
Google socialnetworksmarch08
Google socialnetworksmarch08Google socialnetworksmarch08
Google socialnetworksmarch08
 
Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance Managing Business Processes Communication and Performance
Managing Business Processes Communication and Performance
 
Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013Smart homeamsterdamoctober2013
Smart homeamsterdamoctober2013
 
Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015Entreprise troispointzeropublicjan2015
Entreprise troispointzeropublicjan2015
 
GTES UTC 2014
GTES  UTC 2014GTES  UTC 2014
GTES UTC 2014
 
The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014The European CIO Conference - November 27th, 2014
The European CIO Conference - November 27th, 2014
 
Disic mars2014
Disic mars2014Disic mars2014
Disic mars2014
 

Dernier

Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
cristionobedi
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
mrelmejri
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
Txaruka
 
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
IES Turina/Rodrigo/Itaca/Palomeras
 
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
SYLLABUS DU COURS  MARKETING DTS 1-2.pdfSYLLABUS DU COURS  MARKETING DTS 1-2.pdf
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
Moukagni Evrard
 
Mémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et auditMémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et audit
MelDjobo
 
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Oscar Smith
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
WarlockeTamagafk
 
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
M2i Formation
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
Friends of African Village Libraries
 
Iris et les hommes.pptx
Iris      et         les      hommes.pptxIris      et         les      hommes.pptx
Iris et les hommes.pptx
Txaruka
 
Système de gestion des fichiers de amine
Système de gestion des fichiers de amineSystème de gestion des fichiers de amine
Système de gestion des fichiers de amine
sewawillis
 
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupeCours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Yuma91
 

Dernier (13)

Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
 
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
Evaluación docentes "Un cielo, dos países: El camino de los descubrimientos"
 
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
SYLLABUS DU COURS  MARKETING DTS 1-2.pdfSYLLABUS DU COURS  MARKETING DTS 1-2.pdf
SYLLABUS DU COURS MARKETING DTS 1-2.pdf
 
Mémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et auditMémoire de licence en finance comptabilité et audit
Mémoire de licence en finance comptabilité et audit
 
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
 
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
M2i Webinar - « Participation Financière Obligatoire » et CPF : une opportuni...
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
 
Iris et les hommes.pptx
Iris      et         les      hommes.pptxIris      et         les      hommes.pptx
Iris et les hommes.pptx
 
Système de gestion des fichiers de amine
Système de gestion des fichiers de amineSystème de gestion des fichiers de amine
Système de gestion des fichiers de amine
 
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupeCours de conjugaison des verbes du premier, deuxième et troisième groupe
Cours de conjugaison des verbes du premier, deuxième et troisième groupe
 

Cours chapitre3 2012

  • 1. Théorie et Pratique du Système d’Information Troisième Chapitre: Composants du SI Janvier-Mars 2012 Ecole Polytechnique Yves Caseau Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 1/26
  • 2. Plan du Cours – Composants du SI Première partie: Le « Système Technique »  Deuxième partie: Infrastructure d’intégration  Troisième partie: Make/buy/rent : software ecosystem  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 2/26
  • 3. Première Partie: le Système Technique Sous-Systèmes du SI  Le SI est « fractal », ses composants sont des SI  Qualifiés de « macro-ST » à Bouygues Telecom Une « brique » (sous-système) est un ensemble d’applicatifs associés à un ensemble de ressources  Schéma inspiré/extrait de « Architecture Logicielle » de J. Printz  Système applicatif applicatio n exécutable exécutable bibliothèques threads process scripts DLLs, … threads Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 3/26
  • 4. Première Partie: le Système Technique Système Technique Chaque système technique dispose de ses ressources, allant du PC à un ensemble de serveur spécialisés  Les ressources peuvent être distribuées    Les ressources peuvent être mutualisées   Ex: GRID computing Partage entre plusieurs systèmes applicatifs Les ressources peuvent être virtualisées   Découpage logique d’une ressource en plusieurs « machines virtuelles » Classique pour le stockage, tendance de fond pour les serveurs Postes de travail Postes dePostes de travail travail Serveurs Serveurs Serveurs de calcul Ressource de stockage Ressource de stockage Back-up Intfrastructure : réseau / servitudes Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 4/26
  • 5. Première Partie: le Système Technique Cycles de développement et Intégration  Le cycle classique de développement est souvent représenté par un V Expression Besoin Mise en Service Tests exploitabilité Spécification Spécifications fonctionnelles Intégration Architecture système Conception Architecture logicielle Tests unitaires Tests unitaires techniques code Développement Tests fonctionnels Tests Intégration logicielle Zone spécifique au métier / à l’entreprise On parle également de cycle en W pour représenter l’intégration de plusieurs composants/projets dans un même SI  Cf. Meinadier Intégration Ingénierie  système système Coordination Réalisation des composants Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 5/26
  • 6. Première Partie: le Système Technique Composants  Principe d’un composant (Printz/Spyzerski)     Propriétés clés      Réutilisable Scalable (sans état) => gestion du contexte en paramètre Définition « unité de déploiement indépendante, utilisable via des tiers via ses interfaces, dont l’état interne n’est pas observable » Intégration tardive Test modulaire (indépendants) Standardisation (écosystème interne/externe) Contrats La notion de composant est transverse dans le SI (multi-échelle)     Composant logiciel Serveur d’application – SOA local Services métiers SOA global Mais aussi: requêtes BD (services Tuxedo – moniteur transactionnel) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 6/26
  • 7. Première Partie: le Système Technique Architecture Client-Serveur  L’architecture client-serveur est le classique des années 80-90, apparue avec l’informatique départementale    Mainframe : batch + terminal PC + serveur Une typologie qui évolue au cours des années (avec balancier)     Client lourd Client léger Client riche (ex: Ajax) Avantages/inconvénients: déploiement / performance / ergonomie Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 7/26
  • 8. Première Partie: le Système Technique Architecture en Couches  L’architecture en couche est aussi ancienne que la programmation     Ex: Dijkstra, 1968 Base des architectures de protocole de communication Exemple : 7 couches du modèle OSI Outil de modularité    Correspond à une structure d’arbre orienté (hiérarchique) Impacts en O(log N) Cf. DSM (dependency structure matrix chapitres suivants)  Plusieurs « patterns » orientés   Vertical  Par niveau d’abstraction (chaque couche ignore les détails de l’autre) Horizontal  Par étape de processus/ transformation (irréversibilité du temps) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 8/26
  • 9. Première Partie: le Système Technique Architecture 3-tiers  Evolution naturelle du modèle client-serveur:    Découplage traitement - données Orientée-scalabilité : capacité à démultiplier les ressources de traitement Solution technique: Serveur d’application IHM Services Métiers Présentation Traitements Visualisation IHM Services Présentation  Accès aux données Logique Métier Services élémentaires Objet Métiers Accès S’étend naturellement au N-tiers en décomposant le traitement selon une architecture en couche:   Serveurs d’applications Web (frontal de clients légers) Serveurs d’intégration (entre traitement et données) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 9/26
  • 10. Deuxième partie Le « Système Technique »  Infrastructure d’intégration  Make/buy/rent : software ecosystem  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 10/26
  • 11. Deuxième Partie:Infrastructure d’intégration Web Services  “Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services”. SOAP / WSDL  Styles  RPC (pattern principal) remote procedural call  SOA (message-based)  REST (http emulation)   WS-* (from WS-I)  WS-security WS-reliability  WS-transaction   RPC: RMI (Java), Corba, DCOM (MS), XMP-RPC Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 11/26
  • 12. Deuxième Partie:Infrastructure d’intégration Bus d’intégration  Bus logiciel pattern tiré du hardware  Intermédiation, standardisation (interface) et mutualisation du transport  comp osant Schéma iconique de l’urbanisation bus Bus d’intégration = bus logiciel au niveau du SI  Synchrone/ Asynchrone  Exemples:  EAI (Enterprise Application Infrastructure) architecture « Publish & Subscribe »  ESB (Enterprise Service Bus)  Corba  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 12/26
  • 13. Deuxième Partie:Infrastructure d’intégration Architecture SOA événements Applications interactives (ex: portail) Processus Batchs Infrastructure (ex: ESB synchrone) Annuaire UDDI service service Infrastructure (ex: ESB asynchrone) Applicatio ns « Cloud » (Internet) Mash-ups Propriété clés: • Stateless •Gestion explicite du contexte •Contrat de service Ressources Référentiels (données) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 13/26
  • 14. Deuxième Partie:Infrastructure d’intégration Orchestration BPM  Moteur d’orchestration Workflow  Processflow BPEL Moteur Processus   Standardisation  BPEL4WS / XW-BPEL et les autres   Cf chapitre 6 Intégration avec serveur d’applications – WebSphere (IBM), WebLogic (Bea/Oracle), …  Questions à se poser/ réponse possible Performance / distribution  Flexibilité / moteur de règles  Intégrité (Transactions)  Cf. chapitre 6  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 14/26
  • 15. Deuxième Partie:Infrastructure d’intégration ETL (Extract / Transform / Load)  Exemple d’architecture en couche (cf. Printz) Application ETL Extract Transform DWH Load Référe nciels  Datamarts Application Infrastructure d’intégration des SI décisionnels Orienté traitement de masse  Intégration d’outils XML volumiques (filtrages, transformation)   Evolution vers une solution complète EII : Enterprise Information Integration  Intégration d’un processflow / interfaces SOA  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) Vraie compétence technique 15/26
  • 16. Compatibilité ascendante et versions  XML est auto-décrit et extensible …   La gestion des versions est indispensable pour gérer la complexité    Cela n’assure pas la compatibilité ascendante dans la lecture des messages La gestion de version introduit un « découplage temporel » En l’absence de versions, le système doit évoluer par bloc (malgré l’EAI Règles pour obtenir une compatibilité ascendante (classique)    Marquer les composant des messages avec des numéros de version Format ouvert permettant d’accepter des informations non interprétées (le minimum … rarement implémenté) Pilotage dynamique (quelle version de X utilise quelle version de Y)  Déploiement facilité Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 16/26
  • 17. Deuxième Partie:Infrastructure d’intégration Intégration par le « front office » - Portail applicatif  L’intégration applicative peut aussi venir du front-office    Vision unifiée des applications Scripts de partage d’information/ automatisation de saisie Méthode légère d’urbanisation qui peut évoluer vers SOA Une méthode légère et efficace d’intégration  Architecture Web qui s’appuie de multiples outils   Une part importante d’open-source Portail applicatif Serveur Web Services Présentation Services métiers Automatisation Workflow Copyright © Yves Caseau 2012 – Cours Polytechnique (III) Progiciel moderne Interface Services Web Interface Legacy 17/26
  • 18. Deuxième Partie:Infrastructure d’intégration Quel est le retour sur investissement ? Le ROI de l’infrastructure d’intégration n’est pas simple :      L’infrastructure coûte cher La conception est difficile -> alourdit les spécifications + essais/erreurs Les adaptateurs sont coûteux (de 20 à 40% du développement) Tests complexes Exploitation et mise au point difficiles Facteurs clés:   Age moyen (taux de refonte) -> nettoyage Taux de renouvellement -> évolutions Le ROI se juge avec du recul   Cycle complet de vie Quelle est la valeur de l’agilité (cf. chapitre 5) ?  Analyse de scénarios (avec et sans) I.2 : Urbanisation - Questions Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 18/26
  • 19. Troisième partie Le « Système Technique »  Infrastructure d’intégration  Make/buy/rent : « software ecosystem »  Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 19/26
  • 20. Troisième Partie: Ecosystème Logiciel Progiciels et Logiciels Métiers  Il existe plusieurs types de « mode de fabrication » pour des applications logicielles  Spécifique  Framework Progiciel   Critères dimensionnants  nombres de clients taux de couverture (générique / spécifique pour intégration)  généricité du besoin (intersection / union)  Taux d’évolution fonctionnel  Contraintes de performance   Jeu à « deux acteurs »   client : make/buy (avec intégration) Vendeur: maximiser rentabilité (pas revenu) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 20/26
  • 21. Troisième Partie: Ecosystème Logiciel Comprendre les coûts de fabrication  Coûts sont fonction du volume du logiciel (cf. Chapitre 5)   O(n 1.2) construction O(n x m 0.5) incrément Le volume est un compromis entre « intersection » et «union » des besoins  Le fournisseur gère différentes versions techniques  Le fournisseur optimise nb_clients * (prix – cout unitaire)  Progiciel Coût unitaire coût Nombre de clients Coût total Différentiation (l’inverse de la généricité) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) « le mieux est l’ennemi du bien » Trop de fonctions coûte: intégration, ressources, complexité 21/26
  • 22. Troisième Partie: Ecosystème Logiciel Comprendre les coûts de maintenance  Cycle de vie des coûts de maintenance   Le logiciel est un produit « vivant » -> génération successive de versions fonctionnelles Chaque version génère un coût de maintenance    technique correction des anomalies Réduire les coûts  Le coût de maintenance dépend de:    Conduit à la notion de cycle: garantie/maintenance/maintenance étendue/maintenance spécifique (sur demande)   Nombre de versions en activité Nombre de clients (taux de découverte des anomalies) Pression sur les clients pour faire « migrer » de façon ascendante La maintenance est une composante du prix qui est moins bien comprise par les clients  d’où l’idée de « louer le logiciel » en tant que service Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 22/26
  • 23. Troisième Partie: Ecosystème Logiciel ASP et SaaS  ASP (Application Service Provider)    Hébergement applicatif Le service correspond à la « location par appartement » d’une plateforme  Ex: CRM, SFA (Salesforce) SaaS (Software as a Service) : nouveau nom / concept marqué par le « cloud computing »  Multiplicité des fournisseurs coût Capacité à évoluer Effet complexité Synchroniser les besoins Nombre de clients spécifique framework framework ASP spécifique COTS COTS ASP Différentiation (l’inverse de la généricité) Copyright © Yves Caseau 2012 – Cours Polytechnique (III) Complexité du besoin 23/26
  • 24. Troisième Partie: Ecosystème Logiciel Open Source  Qu’est-ce l’open-source  ?    Avantages    Coûts  (même avec les coûts cachés) Réactivité Contraintes d’utilisation    Développement et maintenance confiée à une communauté d’intérêt bénévole (même si des services rémunérés existent – cf. UNIX) QoS : fonction de la taille de la communauté (généricité du logiciel) et de l’implication (généricité de la demande) Culturel: les développeurs parlent aux développeurs Généricité : la QoS dépend de la mutualisation du besoin Critères de JP Rangaswami ( http://confusedofcalcutta.com/2008/07/19/thinking-about-opensource )    Général => open source Industrie => progiciel Entreprise-spécifique (différenciant) => développement Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 24/26
  • 25. Troisième Partie: Ecosystème Logiciel Grid Computing and Cloud Computing  Grid: utiliser une « ferme » d’ordinateurs en tant que superordinateur parallèle Cloud Computing: Outsourcing du Grid (Amazon, Google, etc.)  Trois avantages majeurs:  Fault-tolerance à travers la redondance implicite.  Très haute performance à travers le parallélisme massif     TCO réduit par l’utilisation de « Commodity computing » (PC) – Ex: coût hébergement email de Google    Ex: data mining, traitement d’événements en temps réel Cf. architecture « MapReduce » de Google + Économie d’échelle implicite (1 & 2) suppose une architecture logicielle adaptée ! Le SaaS se prête très bien (souvent, architecture moderne) au Cloud Computing Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 25/26
  • 26. Limites du Cloud Computing Le « cloud computing » est dans une phase naissance => beaucoup de « hype »  Trois limites:  1. 2. 3. Maitrise des données et de la « privacy ». Temps de latence: Un aller-retour n’est pas gratuit (10 ms pour 3000km) => les applications transactionnelles à fort de gré d’interaction ne sont indiquées Surcoût d’une approche SOA externalisée 1. Les services sont forcément à faible granularité, (s’ils était spécialisés et complexes il n’y aurait pas la taille critique de marché) 2. Un RPC à travers un WS a un surcoût important 3. On ne peut pas transformer (aujourd’hui) toutes les appels fonctionnels en invocation de WS – – « SOA is not scale-free » C’est même vrai à l’intérieur de l’entreprise ! Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 26/26

Notes de l'éditeur

  1. Ajouter de dessin classique pilotage support
  2. Ajouter de dessin classique pilotage support
  3. Ajouter de dessin classique pilotage support
  4. Ajouter de dessin classique pilotage support
  5. Ajouter de dessin classique pilotage support
  6. La caractérisation donnée ici est tirée du chapitre 7 de ISO 7498-1. La description originelle donne en plus pour chaque couche les fonctions de manipulation de commandes ou de données significatives parmi celles décrites plus bas. La couche « physique » est chargée de la transmission effective des signaux entre les interlocuteurs. Son service est typiquement limité à l'émission et la réception d'un bit ou d'un train de bit continu (notamment pour les supports synchrones). La couche « liaison de données » gère les communications entre 2 machines adjacentes, directement reliées entre elles par un support physique. La couche « réseau » gère les communications de proche en proche, généralement entre machines : routage et adressage des paquets.(cf. note ci-dessous). La couche « transport » gère les communications de bout en bout entre processus (programmes en cours d'exécution). La couche « session » gère la synchronisation des échanges et les «transactions», permet l'ouverture et la fermeture de session. La couche « présentation » est chargée du codage des données applicatives, précisément de la conversion entre données manipulées au niveau applicatif et chaînes d'octets effectivement transmises. La couche « application » est le point d'accès aux services réseaux, elle n'a pas de service propre spécifique et entrant dans la portée de la norme
  7. Ajouter de dessin classique pilotage support
  8. Remote procedure calls Architectural elements involved in the XML-RPC. RPC Web services present a distributed function (or method) call interface that is familiar to many developers. Typically, the basic unit of RPC Web services is the WSDL operation. The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticised for not being loosely coupled, because it was often implemented by mapping services directly to language-specific functions or method calls. Many vendors felt this approach to be a dead end, and pushed for RPC to be disallowed in the WS-I Basic Profile. [edit]Service-oriented architecture Web services can also be used to implement an architecture according to Service-oriented architecture (SOA) concepts, where the basic unit of communication is a message, rather than an operation. This is often referred to as "message-oriented" services. SOA Web services are supported by most major software vendors and industry analysts. Unlike RPC Web services, loose coupling is more likely, because the focus is on the "contract" that WSDL provides, rather than the underlying implementation details. [edit]Representational state transfer Finally, RESTful Web services attempt to emulate HTTP and similar protocols by constraining the interface to a set of well-known, standard operations (e.g., GET, PUT, DELETE). Here, the focus is on interacting with stateful resources, rather than messages or operations. RESTful Web services can use WSDL to describe SOAP messaging over HTTP, which defines the operations, or can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer).
  9. Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
  10. Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
  11. Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
  12. Complex Systems is a new approach to science that studies how relationships between parts give rise to the collective behaviors of a system and how the system interacts and forms relationships with its environment.
  13. Fault-tolerance through the implicit redundancy. This is, however, an architectural issue. It is not enough to rent your computing infrastructure from Amazon, Google or Microsoft to get this benefit. You also need to implement your information system with an architectural paradigm which takes advantage from the availability of multiple servers. Super-computing performance through parallelization. The same remark applies: it is true that new techniques for data mining or real-time event processing (two examples) may be tried successfully on the cloud through a MapReduce approach; it also requires a significant amount of work if you start from your legacy application. Reduced costs of operation (TCO) through the use of standardized and mass-produced units. Look at the price of the TPMC according to the type of hardware and you will get the idea. I won't dwell on this, this is explained everywhere in the newspaper articles I was mentioning. .
  14. The risk of loosing privacy and control (cf. R. Stallman's reaction). There are many aspects, including legal and societal, to this issue. This is the part that is reasonably well covered in the papers (such as The Economist). It is clearly a valid point, but technology and service segmentation might alleviate this issue in the future. There may exist private clouds, secure clouds, encrypted clouds (where the encryption is managed by a third-party), etc.  Latency : accessing the cloud is not instantaneous. Even if the protocols were truly optimal (and they are not, web service invocation carries a significant overload), it takes some time to access to a distant data center (the light takes 10 ms to travel 3000km, and 10ms is significant for many high-performance computations or transactions). This is why MMORPGs rely on a RCA (rich client architecture – a significant part of the work is done locally).  Computational overhead: making each service invocation a web service invocation is not practical for high performance computing. There is a proper level of granularity for encapsulating a piece of computation/transaction into a cloud service. This is actually something for which there exists a significant amount of history: when companies try to develop a SOA architecture, they have to get the service granularity right. Otherwise, they "discover" that application servers cannot carry an infinite load and that they exhibit a performance overhead when compared with more traditional approaches (a RPC – remote procedure call- is more expensive than a procedure call, and a WS call is not the cheapest RPC).