cours chapitre3 2012

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


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


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


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


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


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


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


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


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


Deuxième partie

Le « Système Technique » Infrastructure d’intégrationMake/buy/rent : software ecosystem


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


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


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


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


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


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é


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


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


Troisième partie

Le « Système Technique » Infrastructure d’intégrationMake/buy/rent : « software ecosystem »


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


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


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


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


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


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


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 !

cours chapitre3 2012

Education