Écoledes Mines de Nancy – SI151- 2005-2006 1 Cours Middleware Introduction au m

Écoledes Mines de Nancy – SI151- 2005-2006 1 Cours Middleware Introduction au middleware ou intergiciel Écoledes Mines de Nancy – SI151- 2005-2006 2 Cours Middleware Introduction Corba J2EE/RMI Servlet/JSP Web Services Grid, temps -réel, surprise Écoledes Mines de Nancy – SI151- 2005-2006 3 Equipe pédagogique Bart Lamiroy Laurent Ciarletta Rémi Badonnel Vincent Cridlig … Prénom.Nom@loria.fr Écoledes Mines de Nancy – SI151- 2005-2006 4 Middleware : définitions (1) L'intergiciel (middleware en anglais) est un ensemble de logiciels ou de technologies informatiques qui servent d'intermédiaire entre les applications et le transport des données via le réseau. Ils offrent des services de haut niveau liés aux besoins de communication des applications (temps réel, sécurisation, sérialisation, transaction informatique, etc.). fr.wikipedia.org/wiki/Middleware Couche logicielle intermédiaire entre les applications et le réseau, permettant le dialogue entre des applications hétérogènes. Synonyme : Intergiciel. lexicom.free.fr/lexicommo.htm Écoledes Mines de Nancy – SI151- 2005-2006 5 Middleware : définitions (2) Logiciel standard qui permet à deux autres logiciels de communiquer en utilisant un protocole applicatif. Dans un Centre d'appels, prend en charge les communications entre les différents constituants : ACD, SVI, applicatif... www.digiway.fr/html/glossairejm.htm Un middleware permet la communication entre des clients et des serveurs ayant des structures et une implémentation différentes. Il permet l'échange d'informations dans tous les cas et pour toutes les architectures. Enfin, le middleware doit fournir un moyen aux clients de trouver leurs serveurs, aux serveurs de trouver leurs clients et en général de trouver n'importe quel objet atteignable. cynode.projet-enoch.net/resource/xml/doc/memoire/generated- html/ memoire_g1107.html Écoledes Mines de Nancy – SI151- 2005-2006 6 Middleware Middleware Système de communication Le Middleware Communication physique Machine O.S Machine O.S Applications Applications Écoledes Mines de Nancy – SI151- 2005-2006 7 Pour quoi faire? Interface de haut-niveau (API) pour le développement d’applications Cacher hétérogénéité du système sous -jacent (matériel et logiciel) Cacher les problèmes de la répartition au maximum Fournir des services répartis d’usage courant Faciliter la programmation répartie Écoledes Mines de Nancy – SI151- 2005-2006 8 Faciliter la programmation répartie Développement, évolution, réutilisation des applications Portabilité des applications Interopérabilité d’applications hétérogènes Écoledes Mines de Nancy – SI151- 2005-2006 9 Aspects importants Applications en constante évolution (besoins, architectures, ressources etc…) QoS Capacité d ’évolution Mobilité, dynamisme des environnements/utilisateurs Adaptation Découverte de service Reconfiguration Comportement Réutilisation, simplicité etc .. Composants Dynamique/adaptable Écoledes Mines de Nancy – SI151- 2005-2006 10 Applications réparties : Système et Application Système : gestion des ressource communes De l’infrastructure Lié au matériel et logiciels sous -jacents Système D’exploitation De communication Cacher la complexit é du matériel, des communications : fourniture de services d’un haut niveau Écoledes Mines de Nancy – SI151- 2005-2006 11 Applications réparties : Système et Application Application : Réponse à un problème spécifique Fournir des services à des utilisateurs (personnes, autres applications) Utilisant les services généraux offerts par le système Certaines applications travaillent directement sur le matériel (systèmes embarqués, réseaux de capteurs etc… Écoledes Mines de Nancy – SI151- 2005-2006 12 Panorama des architectures et technologies Écoledes Mines de Nancy – SI151- 2005-2006 13 Plan Contexte Vision OMG Vision .NET Vision Sun Les Services Web/Web Services Écoledes Mines de Nancy – SI151- 2005-2006 14 Contexte L’informatique d’entreprise est répartie Applications distribuées Objets répartis Divers moyens d’accès en mode « client-serveur » Mobile, Internet, Minitel, Téléphone Besoin d’architecture ouverte et adaptative Vers « l’entreprise étendue » Objet Client Objet Serveur Middleware Écoledes Mines de Nancy – SI151- 2005-2006 15 Contexte Passage du Web des utilisateurs/clients à un Web inter-système Client, B2C, B2B, EAI etc… Modèles qui évoluent : Client/serveur -> Grid, P2P Écoledes Mines de Nancy – SI151- 2005-2006 16 Architecture orientée service SOA (Service-Oriented Architecture) Pas nouveau Permet l’interopérabilité de systèmes hétérogènes Couplage « lâche » ou mou entre les composants logiciels Service = action exécutée par un « fournisseur » pour un « client » Différence avec l ’orienté objet : Découplage données – mode de traitement Ce n’est plus le « technique » qui dicte l ’architecture, mais le « métier » Écoledes Mines de Nancy – SI151- 2005-2006 17 3 principales approches Autour de Corba : informatique d’entreprise, intégration d’applications ‘legacy’ Autour de Java : Internet et Web Application et Web Serveurs COM+ , .NET : position forte de MS sur les postes de travail Écoledes Mines de Nancy – SI151- 2005-2006 18 CORBA Écoledes Mines de Nancy – SI151- 2005-2006 19 L’OMG Object Management Group Créé en 1989 But non lucratif Plus de 850 membres Création et maintenance de sp écifications: CORBA UML www.omg.org Écoledes Mines de Nancy – SI151- 2005-2006 20 Common Object Request Broker Architecture Eléments : Stub et skeleton g énérés automatiquement Object Adapter : enregistrement des objets, invocation, contr ôle BOA (Basic) POA (Portable) ORB : Object Request Broker (messages) IOP : Inter-ORB Protocol GIOP (General) IIOP (Internet) IDL : Interface Definition Language Objet (C++, Python …) Client Serveur ORB Objet (Java, Cobol …) Stub Skeleton ORB Object Adapter IDL (*) marshalling (**) unmarshalling IIOP (*) (**) Une architecture d’interopérabilité distribuée et orientée objet selon un modèle client-serveur ouvert Écoledes Mines de Nancy – SI151- 2005-2006 21 Objet Corba Serveur Objet CORBA Servant Implémentation (C++, Java, Cobol..) Interoperable Object Reference Interface IDL Écoledes Mines de Nancy – SI151- 2005-2006 22 CORBA : le mode dynamique Un « référentiel des interfaces » stocke sous forme d’objets les descriptions d’interfaces OMG-IDL. Une API (DII: Dynamic Invocation Interface) permet de construire des requêtes à l’exécution. Écoledes Mines de Nancy – SI151- 2005-2006 23 CORBA : les composantes du bus Bus de communication Interface d’invocation statique Interface d’invocation dynamique Interface du bus SII DII ORB SSI DSI OA Interface de squelettes statiques Interface de squelettes dynamiques Adaptateur d’objet IR Référentiel des interfaces ImplR Référentiel des implantations Écoledes Mines de Nancy – SI151- 2005-2006 24 OMA (Object Management Architecture) l’architecture globale Bus d’objets répartis Licences Transactions Persistance Propriétés Changements Events Nommage Vendeur Sécurité Relations Collections Temps Externalisation Interrogations Cycle de vie Concurrence Services objet communs Workflow DataWare IHM Administration Utilitaires communs Finance Télécoms Santé Interfaces de domaine Objets applicatifs Spécifiques Écoledes Mines de Nancy – SI151- 2005-2006 25 CCM (Corba Component Model) Extension logique des EJB (interopérabilité avec les EJB) Composant « emballés » Description XML du contenu Binaires (différentes plateformes) 4 catégories de composants Service Session Entity Process CIF ( Component Implementation Framework) Utilise CIDL (Component Implementation Description Language) pour générer le code complémentaire au code du composant Chaque composant est placé dans un « container » Écoledes Mines de Nancy – SI151- 2005-2006 26 Vers CORBA 3 CORBA 2.2 client/serveur orienté objet, les interfaces de base et le POA, les mécanismes dynamiques, GIOP, OMG-IDL et ses projections vers C, C++, SmallTalk, COBOL, ADA et Java. CORBA 3.0 interfaces multiples, passage par valeur, modèle de composant, langage de script, minimumCORBA, realtimeCORBA, CORBA/COM/DCE messaging, printing, fault tolerance, firewall Écoledes Mines de Nancy – SI151- 2005-2006 27 Implémentations BEA WebLogic IBM WebSphere IONA Orbix Borland Enterprise Edition MICO OmniORB ORBit Écoledes Mines de Nancy – SI151- 2005-2006 28 CORBA, UML, XML et MDA UML = standard OMG W3C DOM (Document Object Model) : Accéder à XML via des interfaces Se fonde sur l’IDL OMG Types Corba passés par valeurs mappés sur du XML CCM : encodage, configuration et déploiement décrits en XML Etc… Evolution vers le MDA (Model Driven Architecture) Spécifications écrites à 2 niveaux PIM (Pateform-Independent Model) PSM (Plateform- Specific Model) Mapping PIM vers PSM Processus business et entit és modelés au niveau PIM Génération automatique avec les mappings « englober CORBA, J2EE, XML, .NET et les autres technologies » Écoledes Mines de Nancy – SI151- 2005-2006 29 J2EE Écoledes Mines de Nancy – SI151- 2005-2006 30 Sun’s Java 2 Enterprise Edition Architecture générale Navigateur Web et Applet Client tier Clients évolués Composants d’application cliente Web Services Clients Serveur Web tier JSP Servlets Serveur d’applications tier Conteneurs EJB Entity Beans Stateful et stateless Beans Message Driven Beans Backend tier BD Applications « legacy » Nommage et répertoire (JNDI) Messaging (JMS) Écoledes Mines de Nancy – SI151- 2005-2006 31 Composants dans l’univers Java Applets (J2SE) JavaBeans (J2SE) Enterprise Java Beans (J2EE) Servlets/JSP (J2EE) Composants d’application cliente (J2EE) Écoledes Mines de Nancy – SI151- 2005-2006 32 Applets et JavaBeans Applets : Composants légers Téléchargeables pour les clients (navigateurs Web) Modèle de sécurit é fort JavaBeans : Programmation « connection-oriented » (« wiring ») Flux d’év ènements entre des sources et des « listeners » Clients (le plus souvent) et serveurs Support pour la conception visuelle d’applications Écoledes Mines de Nancy – SI151- 2005-2006 33 Servlets/JSP Servlet : Esprit des applets, côté serveur Composants légers instanci és par les serveurs Web Exécuté JSP : « code Java et HTML entrelacés » Pour la présentation Définition déclarative : génération automatique de pages Web (et des servlets correspondantes) Interprété Écoledes Mines de Nancy – SI151- 2005-2006 34 EJB Services intégrés dans des conteneurs d’EJB Beans Nécessité de déclarer leurs attributs Besoin de « descripteurs de déploiement » Différent des Java Beans ! : Composition « orientée objet » Création d’instances, appels de méthodes Pas très adapté au « wiring » Point fort : uploads/Ingenierie_Lourd/ cours1-middleware-poureleves.pdf

  • 18
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager