1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Thierry CAZENAVE www.cosmosbay-vectis.com Concepts dorigine et évolutions Le 24 Novembre.

Présentation au sujet: "1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Thierry CAZENAVE www.cosmosbay-vectis.com Concepts dorigine et évolutions Le 24 Novembre."— Transcription de la présentation:

1 1 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Thierry CAZENAVE www.cosmosbay-vectis.com Concepts dorigine et évolutions Le 24 Novembre 2003 S chéma D irecteur des E spaces numériques de T ravail Groupe de Travail Interopérabilité Les Web Services

2 2 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Agenda Concepts et enjeux des Web Services Web Services : le middleware objet de lère Internet Les Web Services comme technologie dintégration (EAI) Vers un nouveau modèle darchitecture à base de services logiciels (SOA) Lémergence des « Enterprise Services Bus » (ESB) Modèle dévaluation des offres de Web Services

3 3 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services sont un middleware Un middleware est un ensemble de moyens techniques mis en œuvre sur un réseau permettant de faire communiquer des systèmes informatiques entre eux. Quatre types de middlewares Orientés accès aux données Orientés messages ( MOM ) Orientés transaction ( TP ) Orientés objets distribués Peu de normalisation Middleware signifie presque toujours « produit » et parfois « standard » Ils sont souvent incompatibles entre eux Les Web Services sont une vision universelle du middleware

4 4 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Middlewares daccès aux données Dialoguer avec un système de gestion de base de données Requêtes select, insert, update, delete Deux couches distinctes La couche propre au SGBD ( SQLNet, TDS, … ) La couche de loutil de développement ( ODBC, ADO, JDBC, … ) BAS NIVEAU ! POINT A POINT Application Base de données Propriétaire Générique

5 5 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 J2EE Middlewares Orientés Message IBM MQSeries, Microsoft MSMQ, Tibco RendezVous… Passerelles entre les différents MOM Plateforme J2EE : JMS (Java Messaging Services) : standardisation de linterface des MOM Application J2EE Sujet JMS Application Subscribe Publish Application Queue JMS Application Send Receive Publish / Subscribe (One to many) Point to Point (One to One) Synchrone : receive() Asynchrone : onMessage() ASYNCHRONE ! BUS DE DONNEES

6 6 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Moniteurs Transactionnels ( TP ) Gestion de transactions distribuées Communication avec des « resources managers » hétérogènes Commit à deux phases Fonctionnement ACID Atomicité: toutes les opérations sont effectuées ou aucune Consistance: cohérence sémantique de lopération Isolation: une opération en cours na pas dincidence sur les autres Durabilité: une fois validées les opérations sont visibles de tous Des standards X/Open Distributed Transaction Processing (TX, XA, XA+, XAP-TP) OSI/TP, CORBA/OTS Les produits Inprise ITS, BEA M3, Tuxedo, Encina, Microsoft MTS… COMPLEXITE ! ARCH. DISTRIBUEE

7 7 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Middlewares dobjets distribués Gestion dapplications distribuées Une fonction est sur une machine et collabore au sein de lapplication avec une fonction sur une autre machine Des standards CORBA Des implémentations propriétaires DCOM, RMI Une vision très différente de linteropérabilité Parfois accessible par plusieurs langages Parfois accessible par plusieurs plateformes Parfois les deux Couplage fort ( technique, métier ) COUPLAGE FORT ! ARCH. DISTRIBUEE

8 8 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Pourquoi un nouveau modèle darchitecture ? Lhétérogénéité des systèmes dinformation est le point faible des architectures à base de composants (CORBA, DCOM, J2EE) : Nexpriment leur potentiel que dans un environnement technologique homogène Cette homogénéité est difficilement envisageable à léchelle dune entreprise Car son système dinformation est en constante évolution (elle est impossible à léchelle de la relation entre une entreprise et ses partenaires et clients) Pour intégrer et accepter cette hétérogénéité a été conçu le modèle darchitecture à base de « services » : SOA - Service Oriented Architecture Dans ce modèle les « services » offrent des fonctions métier de haut niveau, souvent existantes au sein des progiciels de lentreprise, qui assemblés entre eux, constituent les processus métier Les Web Services offrent une implémentation de ce modèle en utilisant judicieusement les technologies de lInternet et dXML Adhésion massive des éditeurs de logiciels dinfrastructure (middleware, EAI, serveurs dapplication…) et métier (ERP, CRM, SCM…) : offre la garantie dune véritable ouverture et réutilisation des services applicatifs de lentreprise

9 9 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Principes des Architectures Orientées Services (SOA) La notion de service logiciel nest pas liée à une technologie ou à un outil en particulier mais plutôt à un modèle de conception des applications Un service logiciel est un module logiciel utilisable par programmation : Destiné aux applications, pas aux utilisateurs Implémente les règles des architectures multi-niveaux : séparation traitements / présentation Utilisable de manière distribuée, indépendamment de sa localisation physique Un service logiciel est autonome, complet et cohérent : Fournit plusieurs fonctions liées au même objet métier, par exemple la création, la modification et la consultation dun client Se différencie du composant logiciel qui fournit une granularité beaucoup plus fine (des méthodes sur des objets) et impose une manipulation plus complexe Gère la notion détat (session dutilisation) et la notion dutilisateur (identification) Un service logiciel est auto-descriptif et permet un couplage faible : Fournit une description des fonctions proposées de manière à nimposer aucun pré requis à leur utilisation (format de description normalisé et complet) Permet un couplage faible en nimposant aucune autre condition technique que le format de description Il est indépendant des plates-formes et outils de développement

10 10 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Enjeux Permettre à une organisation de simplifier l'utilisation de services applicatifs à distance via le réseau Internet ou via un réseau privé Les Services Web : Répondent à une problématique dinvocation de composants applicatifs dans une architecture distribuée, au même titre que son illustre prédécesseur CORBA Répondent à une problématique dintégration dapplications au même titre que les offres dEAI Ils bénéficient de louverture et de linteropérabilité apportées par XML et les protocoles de lInternet Les premières implémentations en entreprises sont liées à leur cœur de métier

11 11 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Mettre en œuvre conjointement trois standards : SOAP, WSDL UDDI SOAP : Simple Object Access Protocol Protocole de type RPC utilisant XML pour la structuration de ses messages Apporte une structure denveloppe pour le transport dinformations XML sur les protocoles de lInternet WSDL : Web Service Description Language WSDL est une spécification de description des Services Web Permet une définition normalisée de linterface offerte par les services du système de réservation Utilise une description des données métier sappuyant sur les XML Schema UDDI : Universal Description, Discovery and Integration Annuaire des Services Web mis à disposition par les entreprises, permet la découverte, la sélection et la mise à disposition des descriptions de services Permet la constitution dun annuaire des services offerts par le système de réservation aux partenaires du Club Méditerranée Lidée de base des Web Services

12 12 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Modèle SOA mis en œuvre par les Web Services Catalogue des Services (UDDI) Société A ( Fournisseur ) Société A ( Fournisseur ) Service A Société B ( Consommateur ) Société B ( Consommateur ) Application B Publication (WSDL) Service A Le lien entre ces acteurs repose sur trois fonctionnalités : La publication du service (publish), La recherche du service (find), Lappel au service (bind) Une Architecture Orientée Services est une infrastructure logicielle qui englobe des modules applicatifs autonomes Les met à disposition au travers du réseau en les répertoriant dans un annuaire Permet leur utilisation au travers dun modèle de communication indépendant des technologies Utilisation au travers du réseau (SOAP) Recherche (WSDL) 1 2 3

13 13 SDET – Groupe de travail interopérabilité – 24 Novembre 2003 Les Web Services Les Web Services font lobjet dun consensus indéniable entre les éditeurs de solutions logicielles et les organismes de normalisation tels que le W3C, lOASIS, lIETF… Le seul « standard » ayant fait une unanimité comparable au cours des dernières années est XML (eXtensible Markup Language) Les voies tracées par ces deux technologies sont parallèles et complémentaires : Parallèles car XML comme les Web Services sont les dignes héritiers de technologies éprouvées : SGML (1986) pour XML et CORBA (1991) pour les Web Services Complémentaires car les Web Services sont fondés sur XML et servent le même objectif de recherche dinteropérabilité OASIS : Organization for the Advancement of Structured Information Standards IETF : Internet Engineering Task Force

14 14 SDET – Groupe de travail interopérabilité – 24 Novembre 2003...