introductionwebserhfghhdfhsdvices (1).pptx
- 1. Urbanisation et Web Services Cours 3 Intégration de Systèmes d'Informations
- 2. Agenda • Urbanisation des systèmes d'information • Couplages faibles et forts entre systèmes • Web services 2
- 3. Urbanisation 3 intégration de systèmes par les services
- 4. Note sémantique sur le terme « Système d’Information » 4 • En Anglais le plus souvent: – On parle des systèmes d’information d’une organisation, chacun étant construit le plus souvent autour d’une application informatique gérant un ensemble d’infos persistantes (documents, données de gestion, etc.), pour servir une fonction de gestion spécifique. – Un ERP, un datawarehouse, une GED (gestion électronique de documents), un portail intranet, une application CRM, etc. sont autant de « information systems » • En Français le plus souvent: – On parle du système d’information d’une entreprise, qui recouvre l’ensemble des applications, réseaux, outils, pratiques, compétences, etc. – Lorsqu’on en parle avec un regard « ingénierie » et technique, alors on emploie aussi parfois le terme « système d’information » avec le même sens qu’en anglais (1 S.I. = 1 système informatique isolé). • Urbanisation en français: – Activité consistant à organiser de manière performante et efficiente LE système d’information d’une organisation (voire de plusieurs organisations coopérantes), • En anglais ce terme n’est presque pas utilisé (-> 2006): – Le plus souvent remplacé par Information Systems Integration
- 5. Systèmes d'information: flux et reflux… PGI / ERP opérationnel / back-office Décisionnel / DataWarehouse s Chaînes logistiques SCM Electronic Front Office Business to Customer Electronic Front Office Business to Business We b marché s électronique s EDI partenaire s commerciau x DW we b dat a ... [email protected] - HEC Lausanne 5
- 6. d'intégration ressemblent un peu à cela: [email protected] - HEC Lausanne 6
- 7. Systèmes d'information: flux et reflux… • Besoin fort d'organisation de tous ces échanges d'information entre systèmes • Choix d'une architecture commune • Gestion des flux d'information => Urbanisation Thibault.Estier@unil. c h - HEC Lausanne 7
- 8. Architecture Systèmes d’Information versus Architecture Logicielle Thibault.Estier@unil. c h - HEC Lausanne 8 2 notions séparées: • Architecture S.I. : – ensemble des décisions, plans & schémas, normes et recommandations, définissant l’interopérabilité des applications informatiques d’une plateforme (ou d’un « système d’information » au sens français du terme…) – interopérabilité: • les flux d’information entre applications • les services offerts par les applications pour produire/consommer ces flux, • les processus (business process) supportés par ces flux. • Architecture logicielle : – ensemble des décisions, schémas, normes et recommandations, environnements de développement (langages, méthodes, …) impliqués dans la construction d’une application informatique à l’aide de composants logiciels, – les composants (packages, classes, etc.) structurés en frameworks facilitent une certaine réutilisation d’une application dans l’autre.
- 9. 9 [email protected] - HEC Lausanne Arch. SI vs Arch logicielle: ressemblances • intention d’organiser un ensemble de composantes en un système où: – les composantes sont identifiées et leur propriétés connues – les relations statiques et dynamiques (échanges d’information) sont connues • notion d’interface – (sous-)ensemble des propriétés nécessaires aux échanges d’information – une composante équipée d’une interface connue s’appelle un module • objectifs de la modularisation / organisation en composants: – factorisation de l’effort de conception/gestion de ces propriétés – limiter la redondance et les surcoûts associés – réduire les coûts de maintenance/adaptation – flexibilité : faciliter évolution par parties
- 10. Arch. SI vs Arch logicielle: différences Thibault.Estier@unil. c h - HEC Lausanne • la nature et la taille des composantes – architecture SI: modules = des applications entières, des progiciels, peu d’homogénéité des technologies mises en œuvre, applications « anciennes » patrimoine (legacy systems), – architecture Logicielle: modules = classes, fonctions, scripts, regroupés en packages, assemblés pour constituer une application, les packages sont regroupés en frameworks lorsqu’ils sont réutilisables/réutilisés, souvent alignés sur une même technologie
- 11. Arch. SI vs Arch logicielle: différences Thibault.Estier@unil. c h - HEC Lausanne • les objets-métier (business objects) ne sont pas directement des objets du logiciel (souvent pas implémentés tels quels) • la notion de processus pour coordonner les composantes : – n’existe que rarement dans les architectures logicielles, – est très importante dans les architectures de SI • pour définir les objectifs/motivations/règles des flux d’information entre applications • pour contrôler/piloter l’alignement de la plateforme SI avec les besoins des « Business Processes » • pour organiser/gérer l’hétérogénéité des technologies utilisées: utilisations de systèmes médiateurs Business Process Management Systems.
- 12. 12 [email protected] - HEC Lausanne Trois approches pour l’urbanisation - l’intégration de systèmes d’information • l'approche orientée données • l'approche orientée services (SOAservices ) • l'approche orientée événements et processus (SOAprocess) En pratique: les trois approches sont souvent à l’œuvre sur le terrain en même temps.
- 13. Trois approches pour l’urbanisation - l’intégration de systèmes d’information • l'approche orientée données – on raisonne sur les schémas de données gérées par les différentes applications, – intégration de schémas, correspondances (mappings) de données, – référentiels terminologiques, ontologies de domaines, => Modèle de Données d’Entreprise – approches ETL (Extract, Transform and Load), très efficaces pour les grands volumes de données, – gestion des copies / replications, versions, etc. exemple: alimentation d’un entrepôt de données (Datawarehouse) à des fins d’analyse/reporting Thibault.Estier@unil. c h - HEC Lausanne 13
- 14. Trois approches pour l’urbanisation - l’intégration de systèmes d’information [email protected] - HEC Lausanne • l'approche orientée services (SOAservices ) – chaque application/système impliqué publie les informations ou transformations d’informations sous forme de services disponibles pour d’autres applications, – accent sur les interactions synchrones entre applications (call / return) – forêt de systèmes invoquant respectivement leurs différents services
- 15. Trois approches pour l’urbanisation - l’intégration de systèmes d’information [email protected] - HEC Lausanne • l'approche orientée événements et processus (SOAprocess) – domaine des outils EAI (enterprise application integration), – accent sur les interactions asynchrones entre applications (messages/files d’attente) – analyse des séquences d’interactions entre systèmes processus – orchestration des processus et des échanges de messages par des systèmes intermédiaires
- 16. Architecture Orientée Service (SOA) – principes (Singh & Huns) • Couplage le plus faible possible • Neutralité de l'implémentation – Plusieurs technologies possibles – "The interface is what matters" ! • Configuration flexible – pouvoir changer la configuration des relations entre composants dynamiquement • Cycles de vie des composants longs – instances durent plus longtemps que chaque exécution d'application – composants existent et sont disponibles avant leur usage, sont "découvrables", peuvent acquérir de nouvelles relations en cours de vie • Granularité plutôt importante – les composants de l'architecture sont assez "gros" pour rendre un service métier facile à identifier/comprendre dans l'organisation (pas de micro- computation) – réduire l'overhead de communication, peu de messages • Coopération des composants comme un "travail d'équipe" – des parties autonomes, ouvertes, qui coopèrent pour produire un effet d'ensemble.
- 17. Couplages faibles ou forts modes de coopération entre services 17
- 18. Nature des couplages entre applications d’une architecture SI • échanges synchrones de données : couplage fort – call servicei::operationk() -- return(result_parameters) – unité de temps émission/réception des informations, – les 2 systèmes sont disponibles pour l’échange au même instant – A suspend l’opération en cours en attendant la réponse de B A B
- 19. Nature des couplages entre applications d’une architecture SI • échanges asynchrones de données : couplage faible – envoi d’un message pour un service d’information, réponse revient également par message – émission/réception des informations éventuellement à des instants différents, – A envoie le message et poursuit l’opération en cours, B produit la réponse dès la disponibilité du message A B
- 20. Nature des couplages entre applications d’une architecture SI • échanges asynchrones de données (2) : Evénements – idée: séparer la production de l’événement de sa propagation, – avantage: distribuer le même événement (et infos associés) à plusieurs consommateurs , – mécanisme « publish / subscribe » • A publie son intention d’émettre des événements de type e1 • B, B’, B’’, … souscrivent à e1 et sont tous notifiés lors d’une survenance de e1 A B e1 productio n e1 B’ distributio n
- 21. Nature des couplages entre applications d’une architecture SI • échanges asynchrones de données (3) : Gestion par un intermédiaire le broker – un système spécialisé concentre toutes les files d’attentes de messages et gère les productions/ distributions d’événements, – avantages: • un point d’organisation et de contrôle des processus d’échanges, • validation de règles d’intégrité inter systèmes, • adaptations de formats de messages/données, • découplage entre systèmes A, B, B’ : on peut modifier la configuration globale sans modifier/avertir A A B Broke r B’ distribution e1_in e1_out_B e1_out_B’
- 22. Web services 22
- 23. Web Servi ces [email protected] - HEC Lausanne • Références: – Les Web Services, Hubert Kadima, Valérie Monfort, Dunod, Paris, 2003, 411 pages, ISBN=2-10-006558-0 – Web Services Essentials,Distributed Appliications with XML-RPC, SOAP, UDDI & WSDL, Ethan Cerami, O'Reilly & Associates, USA, 2002, 290 pages, ISBN=0-596-00224-6 – Programming Web Services with SOAP, James Snell, Doug Tidwell, Pavel Kuchlenko, O'Reilly & Associates, USA, 2002, ISBN=0-596-00095-2 – http://www.w3.org/2002/ws/ : Site d'activité du groupe "Web Services" du W3C, standards, protocoles, spécifications de références – http://www.w3.org/2000/xp/Group/: Références spécifiques à SOAP/XML-Protocol
- 24. Web Services: Définition • Un service web (WS) est une application autodescriptive dont l'interface utilise l'infrastructure, les normes et les protocoles du web pour mettre à disposition des données ou des services. – échange de données en format XML, – données disponibles par des protocoles HTTP, SMTP, (plus rarement FTP, ou Web-DAV) – indépendant de tout langage de programmation, indépendant de tout système d'exploitation – conçu pour interconnecter des applications sur le Web (≠ browsing) – répertorié dans un annuaire ou référencé par d'autres services (découvrable).
- 25. Motivation des Web Services • du web "human centric" au web "application centric" HTTP GET: "Où en est ma commande ?" HTTP Response (page HTML): "Elle sera livrée demain matin." XML Request: "Où en est cette commande ?" Applicatio n "inventaire " XML Response: "Elle sera livrée demain matin." vers d'autres applications ou serveurs...
- 26. Architecture des Web Services: rôles des applications • Service provider: implémente le service et le rend disponible sur internet/intranet • Service requestor: n'importe quelle application accédant au service en envoyant une requête XML au fournisseur • Service registry: un répertoire ou annuaire contenant la description du service registry provide r requesto r publication service description recherche de service invocation du service
- 27. Annuaire UDDI, Flux WSDL et SOAP dans l’implémentation de services
- 28. Architecture des Web Services: rôles des protocoles et standards • Discovery: découverte/recherche de services, publication de services – UDDI - Universal Description, Discovery and Integration • Description: description des propriétés d'un service – WSDL - Web Service Description Language • Messaging and Packaging XML: formattage et encodage – XML-RPC - remote procedure call en XML – SOAP - double fonction: rpc et échange de (petits) messages/documents • Transport: protocoles d'échanges de données – HTTP - Hypertext transfer protocol – SMTP - Simple mail transfer protocol – FTP - File transfer protocol
- 29. O A P • définit un environnement d'échanges de messages XML. • messages SOAP échangés par HTTP, SMTP, FTP, RMI/IIOP,... • dérivé en deux variantes: – SOAP RPC: les messages sont des invocations de méthodes sur un objet distant, – SOAP messaging: un message est un document décrivant un object complexe (une commande client, une demande de crédit, etc.) • SOAP est un double acronyme: – Service Oriented Architecture Protocol – Simple Object Access Protocol