Cours chapitre3 2012

1,922 views

Published on

Cours sur le système d'information en 9 chapitres

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,922
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
168
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Ajouter de dessin classique pilotage support
  • Ajouter de dessin classique pilotage support
  • Ajouter de dessin classique pilotage support
  • Ajouter de dessin classique pilotage support
  • Ajouter de dessin classique pilotage support
  • 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
  • Ajouter de dessin classique pilotage support
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
    .
  • 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).
  • Cours chapitre3 2012

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

    ×