Cours chapitre3 2012

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

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

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

Cours chapitre3 2012

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

Cours chapitre3 2012

Plus De Contenu Connexe

Les utilisateurs ont également aimé (20)

Similaire à Cours chapitre3 2012 (20)

Plus par Yves Caseau (20)

Plus récents (20)

Cours chapitre3 2012

Notes de l'éditeur