--- title: "Architecture des Systèmes d'Information" ... \newpage{} # CORBA ## Introduction CORBA pour Common Object Request Broker Architecture est une architecture logicielle pour développer des composants distribués. CORBA est : - Agnostic du langage, c'est a dire que des processus développés avec des langages de programations différents peuvent intéragir ensemble - Réparti ou distribué, c'est à dire qu'ils permet à des processus différents, éventuellement sur des machines différentes d'intéragir ensemble CORBA a été créé par l'OMG (Object Management Group) en 1992. ## Objectifs - Environnement ouvert - API portable - Environnement interopérable ## Architecture Les objets CORBA transitent sur un bus distribué appelé ORB (Object Request Broker) utilisant le protocole IIOP (Inter Internet ORB Protocole). Les objets transitent sur le bus ORB à l'aide d'un système d'amorce, des souches et des squelettes qui sont du code source généré. Le code source est généré à partir du code IDL (Interface Definition Langage) qui permet de définir de façon abstraite les objets et leurs méthodes. ![Architecture CORBA](img/orb.png) Pour résumer on a : - *stub* : partie cliente générée à partir de l'IDL - *skeleton* : partie serveur générée à partir de l'IDL - *Object Adapter* : Enregistrement (record) d'objet coté serveur, avec un identifiant attribué - *ORB* : Object Request Bus - *IIOP* : Internet Inter-ORB Protocol, qui utilise RPC (Remote Procedure Call) ## Langage IDL IDL permet de définir l'interface des composants distribués : ```java interface HelloWorld { string say_hello(); } ``` Il est ensuite compilé vers un langage de programmation cible pour générer : - Le *stub* - Le *skeleton* - L'interface - Les opération de l'interface ## Identité d'objet Les instances des objets CORBA ont chacunes une identité qui permet de les retrouver dans une sorte d'annuaire. ## Adapteur d'objets L'adapteur d'objet est le composant qui permet de serialiser les objets sur le bus ORB. Ses responsabilités sont les suivantes : - Faire l'interface entre objets CORBA et ORB - Enregistrer et recherche les instances d'objets - Générer les références d'objets - Instanciation des objets serveur - Activation des processus coté serveur - Aiguillage des invocation de méthode vers les objets Il existe deux types d'adapteurs : - BOA (Basic Object Adapter) - POA (Portable Object Adapter) ## Annuaire CORBA L'annuaire CORBA est le composant qui permet d'enregister les association de référence d'objet avec les instance correspondantes : - Le serveur enregistrer ses objets dans l'annuaire - Le client récupère l'accès à un objet en consultant l'annuaire ## Différentes Mises en oeuvre ### Héritage ![Héritage](img/heritage.png) ### Délégation ![Héritage](img/delegation.png) \newpage{} # Message Oriented Middlewares ## Introduction Un MOM : - Est un système client/serveur - Permet d'échanger des messages de façon asynchrone - Utilise une file de message - Possède un *message broker* - Fourni une API compatible avec plusieurs langages de programmation La création des MOMs vient des besoin suivants : - Pas de disponibilité simultannée : certains composants ne sont pas forcément toujours disponibles - Communication asynchrone / non bloquante - Couplage faible : interface standard ## Communication Les MOMs peuvent fonctionner de deux façon : - Synchrone / Bloquante : Emetteur bloqué jusqu'à récéption par le destinataire - Asynchrone / Non Bloquante : émetteur continue à s'exécuter après la soumission du message ## Persistance Deux façons de géré les données : - Persistante (*persistent*) : le message est conservé jusqu'à sa récéption par le destination, il n'est jamais perdu et il n'y a pas de dépendance temporelle ; l'émetteur et le destinataire n'ont pas besoin d'être en ligne en même temps - Transitoire (*transient*) : le message est conservé seulement pendant l'exécution simultanée de l'émetteur et du récépteur, il y a dépendance temporelle ; l'émetteur et le destinataire ont besoin d'être en ligne en même temps ## Diffusion - Unicast : message envoyé à un seul destinataire - Multicast : envoyé à plusieurs destinataires ## Consomation - Mode "push" : - L'émetteur envoie au récépteur - Pas de message → attente ou exception - Mode "pull" : - Le récepteur consulte le destinataire pour des nouveau message - Soit : - Périodiquement - En bloquant jusqu'à dispo d'un message ## Modèle de la file de messages - Les message sont stockés dans une *Queue* jusqu'à ce que le destinataire la lise - Chaque message est consommé une seule fois par un seul destinataire - Pas de dépendance temporelle - Le destinataire peut acquitter les message reçus ## Modèle du topic - Le *Topic* gère l'envoi de messages pour un ensembles de lecteurs abonnés - Les publishers et subscribers sont découplés, ils n'ont pas besoin de se connaitre - Il y a une dépendance temporelle : - Un client ne peut lire un message qu'après son abonnement au topic - Un client abonné à un topic doit être actif pour recevoir les message ## Topologies Différentes topologies sont possibles. ### Centralisée Serveur centrale de gestion des message. Avantages : - Découple les clients qui ne voient que le serveur Inconvénients : - Beaucoup de traffic - Goulot d'étranglement - Single point of Failure - Problème de scaling ### Décentralisée Une instance MOM par client, pas de serveur central. Avantages : - Distribution des fonctions du MOM entre les serveurs Inconvénients : - Problèmes potentiel d'interopérabilités entre les différentes instances - Clients plus lourds, fonction dupliquées ### Hybride Combinaison des deux architectures précédentes. ## Exemple d'implémentation d'un MOM : JMS JMS pour Java Messaging Service est le standard JakartaEE pour le développement MOM sur la plateforme. Il possède une intégration à EJB (les Message-Driven Beans). ### Réception des message JMS - Réception Synchrone, mode *pull* bloquant : - Le consommateur récupère explicitement le message depuis la destination en appelant la méthode `receive` - Cette méthode bloque le thread courant jusqu'à récéption d'un message - Réception Asynchrone, mode *push* avec dépendance temporelle : - Le consommateur enregister un gestionnaire de message auprès de la destination voulue - Lorsqu'un message arrive, le fournisseur JMS utilisé le gestionnaire pour gérer l'événement ### Destination JMS - File ou *Queue* : - Persistance des messages - Découplage temporel producteur/consommateur - Utilisé pour la communication point à point - Sujet ou *Topic* : - Non persistance des messages - Couplage temporel producteur/consommateur - Utilisé pour la communication pubsub JMS permet d'utiliser les deux destination avec les deux modes de récéption. ### Mise en place coté client - Usine de connexions : `ConnextionFactory` - Prend en charge la connexion avec le MOM - Encapsule les paramètre de connexion - `Session` : - Conexte mono-tâche - Utilisé pour la récéption et l'émission de messages - Gère plusieurs producteurs et consommateurs \newpage{} # Webservices Les services web fournissent une interface indépendantes du langage ou de la plateforme sur laquel ils reposent. Le web est utilisé pour la communication, car il est standard, c'est plus pratique que les protocoles hétérogènes que nous avons étudié (IIOP, RMI, DCOM). Les limitations de ces derniers sont les suivantes : - Pas de découvrabilité des services - Trop de contraintes sur le client : - Souches - Diffficile à construire dynamiquement - Compléxité - Péréniité - Prix en terme de plateforme et de compétences On passe donc à la WSOA : Web Services Oriented Architecture. Les problématiques sont l'interopérabilité des : - SI d'entreprise - Technologies eet plateformes ## Webservices SOAP Le protocole SOAP est basé sur un échange de donnée au format XML. Il se base sur un fichier de définition de services XML, appelé le WSDL. On dispose également d'un système dynamique de découverte des servicees ; UDDI. ### Message SOAP Un message SOAP est un document XML composé de : - Une déclaration XML optionnelle - Une enveloppe SOAP (élément `Evelope`), elle même composée de : - Un en-tête SOAP (élément `Header`) : pour l'authentification / gestion de session - Un corps SOAP (élément `Body`) : contient les données ```xml blabla ``` Exemple de requête pour un service d'addition de deux entiers : ```xml 5 12 ``` Exemple de réponse : ```xml 17 ``` SOAP opère bien sur HTTP : - Format requête/réponse adapté - Requête SOAP = requête HTTP POST avec l'enveloppe dans le Body de la requête et content-type text/xml - Utilisation du header HTTP¨`SOAPAction` ### WSDL WSDL pour Web Service Description Langage sert à décrire en XML de l'interface d'un service web. Le WSDL contient tout les informations concrètes et technique pour se connecter à un service web. #### Types WSDL utilise des types XML, primitif ou `complexType` pour définir les données. #### Messages Les messages sont échangés entre les clients et serveurs. Ils sont : - Type-safe - Peuvent avoir plusieurs parties, appelées `parts` Exemple : ```xml ``` #### Port Type Collection nommée d'opérations supportées par le service web. ```xml … … ``` #### Operations WSDL dispose de quatres types d'opérations : - One Way : une opération qui reçoit des messages mais n’en émet pas - Request-Response : une opération qui reçoit des messages puis renvoit des messages - Solicit-response : une opération qui envoie des messages puis en reçoit - Notification : une opération qui envoie des message sans en recevoir Une opération : - Envoie des message : `` - Reçoit des message : `` / `` La catégorie de l'opéation détermine l'ordre et la présence des input / output / fault. Exemples : ```xml ``` #### Binding Liaison d'un PortType à un protocole. Les opération peuvent avoir des Bindings différentes. Les protocoles disponibles sont : - SOAP - HTTP - MIME Un Binding a : - Un nom optionnel, attribut `name` - Un type, qui référence le PortType, attribut `type` #### Service Un service est accessible à un port, le point d'accès au service qui contient l'URL HTTP du service : ```xml ``` ### UDDI UDDI pour Universal Description, Discovery and Integration est un annuaire de services SOAP. Rôles : - Pages blanches : infos sur les fournisseurs de services - Pages Jaunes : critères et options sur les services - Pages vertes : WSDL L'initiative n'a pas marché, on utilise plutot des annuaires privés ### Mise en oeuvre avec JAX-WS JAX-WS est le standard de Jakarta EE pour l'implémentation de services SOAP qui se base sur JAXB (Java Architecture for XML Bindings) pour le mapping Java / XML. JAX-WS consiste à décorer un POJO/EJB avec des annotations #### Anooatations - `@WebService` : définit une classe comme contenant la définition d'un contrat de service SOAP - `@WebMethod` : Expose une méthode comme opération - `@WebParam` : Mappe un paramètre de la méthode à un paramètre de webservice - `@WebResult` : Map le retour de la méthode et le résultat de l'opération Exemple : ```java @WebService(name="Calculatrice",targetNamespace="http://org.lip6.fr/calcula trice") public interface CalculatriceServiceRemote { @WebMethod(action="urn:additionner",operationName="add") public @WebResult(name="Resultat") double additionner( @WebParam(name="Operande1") double operande1, @WebParam(name="Operande2") double operande2 ); @WebMethod(action="urn:multiplier",operationName="multiplier") public @WebResult(name="Resultat") double multiplier( @WebParam(name="Operande1") double operande1, @WebParam(name="Operande2") double operande2 ); } ``` #### Approches de développement - Code first : Ecrire le code Java et générer le WSDL avec `wsgen` - Contract first : Générer le code Java à partir du WSDL avec `wsimport` - Meet in the middle : on du Java et un WSDL, on va développer des adapteur pour les accomoder ## Webservices ReST ReST pour Representational State Transfer est un style d'achitecture pour les systèmes hypermédia distribués. Ce n'est pas un protocole ni un format mais bien un style d'architecture. Il fonctionne très bien sur le Web et HTTP mais n'y est pas exclusif. ### Concepts Clé - Ressources (noms) : identifiées par une URI - Méthodes (verbes) : manipules les ressources, onutilise les méthodes du protocole HTTP (POST, GET, PUT, DELETE) - Représentation : manière d'échanger l'état de la ressource, choisis par le client dans le Header `Accept` : - XML - HTML - JSON - Liens entre les données - La sécurité : tokens d'authentification, ex : JWT La communication avec ReST est Stateless : pas d'état coté serveur : - Le client est responsable de l'état de l'application - Le serveur est responsable de l'état de la ressource ### Exemples d'URIs : - http://example.com/customers/1234 : Le client num 1234 de la collection de clients - http://example.com/products/4554 : Le produit numéro 4554 - http://example.com/customers/1234/orders/12 : La commande num 12 du client num 1234 ### Méthodes HTTP - GET : Lecture d'une ressource, sans effet de bord - POST : créer une nouvelle information sans l'Id dans une collection - PUT : mise à jours (remplacement de la ressource) / création avec Id - DELETE : détruire une ressource ### Avantages Coté serveur : - Plus scalable - Reprise après panne (stateless) - Utilisation du cache - Couplage faible - Interface uniforme - Fonctionne avec les infrastructure actuelles Coté client : - Choix dans le format de données - Pas besoin de descripteur - Indépendant du langage ### Mise en oeuvre avec JAX-RS JAX-RS est la spécification JakartaEE pour les services ReST. Une ressource corrspond à une classe POJO annotée, chaque méthode correspond à une endpoint. Les annotations : - `@Path` : mappe une classe ressource ou une méthode endpoint à une URI - Annotation de méthode (`@POST`, `@GET`, `@PUT`, `@DELETE`) ; mappe une méthode endpoint à une méthode HTTP - `@Produces` : format produit par la méthode endpoint - `@Consumes` : format consoommé par la méthode endpoint Exemple : ```java @Path("/todos") public class NotificationsResource { private TodoRepository repository; @GET @Path("/{id}") public Response getTodo(@PathParam("id") int id) { return Response .ok() .entity(repository.find(id)) .build(); } @POST @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) public Response postNotification(Todo todo) { repository.save(todo); return Response .status(201) .entity(todo) .build(); } } ```