cours chapitre3 2012
Post on 18-Dec-2014
421 Views
Preview:
DESCRIPTION
TRANSCRIPT
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 1/26
Théorie et Pratique du Système Théorie et Pratique du Système d’Informationd’InformationTroisième Chapitre: Composants du SITroisième Chapitre: Composants du SI
Janvier-Mars 2012Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 2/26
Plan du Cours – Composants du SIPlan 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) 3/26
Sous-Systèmes du SISous-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
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Système applicatif
application
exécutable
scripts
bibliothèques
threads
threads
DLLs, …
exécutable
process
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 4/26
Système TechniqueSystè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 Ex: GRID computing
Les ressources peuvent être mutualisées 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
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Ressource de stockage
ServeursPostes de travail
Intfrastructure : réseau / servitudes
Back-up
Ressource de stockage
Serveurs
Serveurs de calcul
Postes de travail
Postes de travail
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 5/26
Cycles de développement et IntégrationCycles de développement et Intégration Le cycle classique de développement est souvent représenté par un V
On parle également de cycle en W pour représenter l’intégration de plusieurs composants/projets dans un même SI Cf. Meinadier
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Intégration système
Ingénieriesystème
Réalisation des composants
Coordination
Expression Besoin
Spécifications fonctionnelles
code
Architecture logicielle
Tests unitaires techniques
Mise en ServiceTests exploitabilité
Tests fonctionnels
Intégration
Tests unitaires Conception
Spécification
Développement Intégration logicielle
Architecture système
Tests
Zone spécifiqueau métier / à l’entreprise
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 6/26
ComposantsComposants
Principe d’un composant (Printz/Spyzerski) 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 »
Propriétés clés 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)
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 7/26
Architecture Client-ServeurArchitecture 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
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 8/26
Architecture en CouchesArchitecture 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)
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 9/26
Architecture 3-tiersArchitecture 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
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)
Pre
miè
re P
art
ie:
le S
ystè
me T
ech
niq
ue
IHM
Présentation
Services Métiers
TraitementsAccès aux données
Visualisation IHM
ServicesPrésentation
Logique Métier
Objet Métiers
Services élémentaires
Accès
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 10/26
Deuxième partie
Le « Système Technique » Infrastructure d’intégrationMake/buy/rent : software ecosystem
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 11/26
Web ServicesWeb 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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 12/26
Bus d’intégrationBus d’intégration
Bus logiciel pattern tiré du hardware Intermédiation, standardisation (interface) et
mutualisation du transport
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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
bus
composant
Schéma iconique de l’urbanisation
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 13/26
Architecture SOAArchitecture SOAD
eu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
Applications interactives(ex: portail)
Processus
événements
Batchs
service
Propriété clés:• Stateless•Gestion explicite du contexte•Contrat de service
Annuaire UDDI
Référentiels(données)
« Cloud »(Internet)
Applications
Ressources
Infrastructure (ex: ESB asynchrone)
Infrastructure (ex: ESB synchrone)
service
Mash-ups
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 14/26
Orchestration BPMOrchestration BPM
Moteur d’orchestration Workflow Processflow
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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
Moteur Processus
BPEL
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 15/26
ETL (Extract / Transform / Load)ETL (Extract / Transform / Load)
Exemple d’architecture en couche (cf. Printz)
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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
ETL DWH
Data-marts
Extract Transform Load
Appli-cation
Appli-cation
Référenciels
Vraie compétence technique
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 16/26
Compatibilité ascendante et versionsCompatibilité ascendante et versions
XML est auto-décrit et extensible … Cela n’assure pas la compatibilité ascendante dans la lecture des
messages La gestion des versions est indispensable pour gérer la
complexité 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) 17/26
Intégration par le « front office » - Portail applicatifInté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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
Portail applicatif Serveur Web Progiciel moderne
LegacyWebInter-face
Services Présentation
Services métiers
AutomatisationWorkflow
InterfaceServices
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 18/26
Quel est le retour sur investissement ?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
Deu
xiè
me P
art
ie:I
nfr
astr
uctu
re d
’in
tég
rati
on
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 19/26
Troisième partie
Le « Système Technique » Infrastructure d’intégrationMake/buy/rent : « software ecosystem »
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 20/26
Progiciels et Logiciels MétiersProgiciels 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)
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 21/26
Comprendre les coûts de fabricationComprendre 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)
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Différentiation (l’inverse de la généricité)
coût
Nombre de clients Coût total
Progiciel
« le mieux est l’ennemi du bien »Trop de fonctions coûte: intégration, ressources, complexité
Coût unitaire
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 22/26
Comprendre les coûts de maintenanceComprendre 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:
Nombre de versions en activité Nombre de clients (taux de découverte des anomalies)
Conduit à la notion de cycle: garantie/maintenance/maintenance étendue/maintenance spécifique (sur demande)
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
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 23/26
ASP et SaaSASP 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
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Différentiation (l’inverse de la généricité)
coût
ASP COTSframework
spécifique
Complexité du besoin
Capacitéà évoluer
Synchroniser les besoinsEffet complexité
ASP
COTS
frameworkspécifique
Nombre de clients
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 24/26
Open SourceOpen Source
Qu’est-ce l’open-source ? 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) Avantages
Coûts (même avec les coûts cachés) Réactivité
Contraintes d’utilisation 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-and-vrm/ )
Général => open source Industrie => progiciel Entreprise-spécifique (différenciant) => développement
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 25/26
Grid Computing and Cloud ComputingGrid Computing and Cloud Computing
Grid: utiliser une « ferme » d’ordinateurs en tant que super-ordinateur 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
Ex: data mining, traitement d’événements en temps réel Cf. architecture « MapReduce » de Google
TCO réduit par l’utilisation de « Commodity computing » (PC) – Ex: coût hébergement email 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
Tro
isiè
me P
art
ie:
Ecosystè
me L
og
icie
l
Copyright © Yves Caseau 2012 – Cours Polytechnique (III) 26/26
Limites du Cloud ComputingLimites du Cloud Computing
Le « cloud computing » est dans une phase naissance => beaucoup de « hype »
Trois limites:1. Maitrise des données et de la « privacy ».
2. 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
3. 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 !
top related