Services communs CORBA

Les services communs CORBA Service de recherche d’objets : pour retrouver un objet Nommage (Naming) : par un nom : service de « pages blanches » Vendeur (Trader) : par des propriétés: service de « pages jaunes Services concernant la vie des objets : Life Cycle, Property, Relationship, Externalization, Persistent Object, Query, Collection, Versionning, Time, Licencing Services de sûreté de fonctionnement : Security, Transactions, Concurrence Services de communications asynchrones: Events, Notification, Messaging Vendeur : les objets peuvent être recherchés en fonction de leurs caractéristiques.

Les services communs CORBA : historique 1er RFP : 1993 - 1994 Nommage, Cycle de vie, Notification d'événements, Persistance. 2ème RFP : 1994 - 1995 Transactions, Concurrence d ’accès, Externalisation, Relations. 3ème RFP : 1995 - 1996 Sécurité, Serveur de temps. 4ème RFP :1995 - 1996 Propriétés, License, Serveur de requêtes. 5ème RFP :1996 --- Annuaire par fonctionnalités, Collection, Gestionnaire de versions. Request For Proposalrequete dont le résulat c’est des réponses des membres basées sur des otils existants ou en développement des preuves de faisabilité sont alors demandées. RFP sont alors merger .. 12 à 16 mois pour sortir un standard. Actuellement le travail est plus tourné vers les CORBA et JavaBeans, Corba Domains et Business Objects. Et il y a la préparation de Corba 3.0

Les services de recherche d’objets CORBA Bus d’objets répartis CORBA sur Internet (IIOP) Serveur C++ Client Java Repertoire Traitement Service de recherche d’objets IOR IOR équivalent des pages blanches : objets désignés par un nom symbolique . annuaire matérialisé par un graphe de répertoire de désignation. Services Nommage et/ou Vendeur

Le service Vendeur Le service vendeur ou Trader service permet : d ’enregistrer des objets auprès de ce service en les caractérisant par un ensemble de propriétés. de retrouver un service en précisant son type et les critères le caractérisant (différentes politiques de recherche possibles) Opérations principales découvrir et importer des services : Interface LookUp : query (type de service recherché, contraintes, préférences, politique de recherche, ….) parcourir les réponses : Interface OfferIterator mise à jour du service Vendeur : Interface Register export, withdraw …... équivalent des pages jaunes : modes de recherche politique de recherche : un ou des services vendeurs contraintes : le service vendeur définit un langage de contraintes, il est possible d ’en utiliser ou d ’en définir d ’autres SQL par ex. préférences : manières dont les résultats seront rournés : ordre de découverte, aléatoire, etc….

Directory Service Retour sur JNDI et LDAP

Directory Service Naming + attributs

Les fonctions de base void bind(    String stringName,    Object object,    Attributes attributes ) Même méthode que Context, mais avec un paramètre de plus : les attributs. Idem rebind, lookup Idem createSubcontext Créé à partir de InitialDirContext

GetAttributes 2 formes possibles Attributes getAttributes(    String stringName )    String stringName,    String [] rgstringAttributeNames

modifyAttributes Avec les opérations : void modifyAttributes(    String stringName,    int nOperation,    Attributes attributes ) Avec les opérations : ADD_ATTRIBUTE, REPLACE_ATTRIBUTE, et REMOVE_ATTRIBUTE

Search La forme la plus simple passe une liste d'attributs Il est possible d'utiliser des filtres selon la norme RFC 2254 Les contrôles permettent la mise en forme des résultats (par exemple tri ascendant, etc…)

Search : pour faire des requêtes NamingEnumeration search(   String stringName,   Attributes attributesToMatch ) On peut utiliser des filtres de recherche selon la spécification RFC 2254: (cn=Babs Jensen) (!(cn=Tim Howes)) (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*))) (o=univ*of*mich*) search(Name stringName, String stringRFC2254Filter, SearchControls searchcontrols)

Search : contrôle de la recherche On peut utiliser des contrôles permettant : De définir les attributs à renvoyer De définir la portée de la recherche (récursive en arbre, locale…) Le nombre maximum de réponses Le temps maximum d'attente De renvoyer ou non l'objet Java associé De déréférencer ou non les liens

Un exemple String filter = "(objectclass=Inetorgperson)"; SearchControls controls = new SearchControls(); controls.setSearchScope(SearchControls.SUBTREE_SCOPE); controls.setReturningObjFlag(false); controls.setReturningAttributes(attrIds); try { NamingEnumeration enumDev = initCtx.search("ou=people", filter, sc);

Utilisation d'un SearchResult while (enumDev.hasMore()) { SearchResult sr = (SearchResult)enumDev.next(); Attributes attributes = sr.getAttributes(); NamingEnumeration ne = attributes.getAll(); while (ne.hasMore()) Attribute attr = (Attribute) ne.next(); String attrID = attr.getID(); NamingEnumeration values = attr.getAll(); . . . while (values.hasMore()) child.add( new DefaultMutableTreeNode(values.nextElement())); }

Résumé : Directory Mêmes méthodes que Context Créé à partir de InitialDirContext Rajoute la gestion des attributs Rajoute les fonctions de recherche

Le service de Concurrence Le service de Concurrence ou Concurrency control service permet de contrôler l’accès à un objet de manière à gérer la cohérence et la consistance des opérations entre cet objet et les objets qu’il accède ou bien qui l’accèdent. Il permet de créer des verrous répartis et de spécifier le type de verrou crée (lecture, écriture, mise-à-jour etc...). concu pour être utilisé avec le service Transaction.

Le service de Transaction Le service de Transaction ou Transaction service permet d’assurer la consistance des traitements en respectant les propriétés ACID (Atomicité, Consistance, Isolation et durabilité) des transactions. Il permet : de commencer et de terminer une transaction; de contrôler la propagation d’une transaction; d’associer plusieurs objets répartis à une seule et même transaction; de coordonner la terminaison d’une transaction (2 phase commit). Propriétés ACID : Atomicité : une transaction n’est pas décomposable, il faut qu’elle aille jusqu’au bout ou que rien n’ait été fait. Consistence : après la transaction l’ensemble des données est dans un état cohérent. Isolement : si exécution simultanée de plusieurs transactions, les mise à jour de chacunes n’interfèrent pas avec les autres. Durabilité : après une transaction terminée normalement par un COMMIT, le système conservera les valeurs des données (journalisation, sauvegarde, reprise).

Le service d’Externalisation Le service d’Externalisation ou Externalization service permet : l’externalisation d’un objet, c’est à dire la représentation de l’état de l’objet dans une séquence d’octets (en mémoire, sur disque, sur réseau) transportable, de durée de vie illimitée indépendante de l’environnement (ORB) d’origine. l’internalisation des données, impliquant la création d’un nouvel objet dans le même environnement ou dans un environnement différent. le déplacement (migration d’objets), passage par valeur et la sauvegarde des objets doivent reposer sur ce service.

Le service Cycle de vie Le service Cycle de vie ou Life cycle service permet : de gérer la création, la destruction, la copie et le déplacement des objets du bus; les objets sont créés par l’intermédiaire d’objets appelés Factories dont la référence est accessible au client; un objet est détruit, copié ou déplacé à l’aide d’opérations définies dans l’interface de base LifeCycleObject; The Factory pattern can be applied in a wide variety of situations, including the following: • Security - A client is required to provide security information before the factory object will allow the client to have access to another object. Load-balancing - The factory object manages a pool of objects, often representing some limited resource, and assigns them to clients based on some utilization algorithm. • Polymorphism - A factory object enables the use of polymorphism by returning object references to different implementations depending on the criteria specified by a client.

Le service de Relations Le service de Relations ou Relationships service permet d’établir dynamiquement des relations entre les objets distribués. Une relation est définie par un rôle, un degré, une cardinalité et des attributs. Trois niveaux de services : basique : service de base permettant de créer les relations et les objets et de naviguer à travers la relation, de détruire la relation; graphes d’objet en relation; relations spécifiques : Containment (1-n) et référence (n-m). Ex relation : emploie compangie personne Role de compagnie : employeur Role de personne : employée Degré de la relation emploie : relation binaire (nombre de role requis = 2) Cardinalité de la relation emploie : (nbre max des relations impliquées pour un rôle) Ex => aux nbres max des personnes employés pour une compagnie. Attributs de la relation emploie : titre du job, date de début, etc .... Les relations sont encapsulées dans des objets, des contraintes??, et différents types de relations : appartenance, inclusion, référence, l ’auteur et l ’emploi. Manipulation de graphes d ’objets

Affecte le bus, les services, les utiltaires, les applicatifs Sécurité et temps Le service de Sécurité (Security) permet de gérer les fonctions suivantes : authentification autorisation sûreté et intégrité des communications encryptage administration de la sécurité Le service de Temps (Time) permet la synchronisation périodique d’horloges dans tous les composants d’un système réparti. autentifier les clients , chiffrer et certifier les communications, contrôler les autorisation d’accès. Ce service utilise les notions de serveurs d’authentifications, de clients/rôle/droits (et délégation de droits), d’IIOP sécurisé permet d’obtenir une horloge globale sur le bus de mesurer le temps et de synchroniser les objets. Affecte le bus, les services, les utiltaires, les applicatifs

Le service de notification d'événements La plupart des requêtes CORBA se traduisent par l’exécution synchrone d’une opération (le client connaît la référence de l’objet auquel la requête s’adresse et le client ainsi que l’objet doivent être tous deux actifs) et sinon? Le service d'Evénements ou Event service permet de découpler la communication entre objets. Mode de communication découplé : lorsque le client et l’objet ne se connaissent pas; lorsque le client et l’objet ne sont pas actifs simultanément. Je saurais le compléter.par un dessin.. Il permet aux objets de produire des événements asynchrone à destination d’objets consommateurs. Producteurs et consommateurs dialoguent à travers un intermédiaire appelé canal d’événements. Les producteurs n’ont pas besoins de connaître tous les consommateurs intéressés. Etendu avec le Notification service ou les consommateurs sont notifiés uniquement des évènements les interessant ce qui permet de réduire le trafic. Voir l ’exemple de Douglas si je pouvais recuperer le transparent…. dans le mode push le producteur a l ’initiative de la production le consommateur est notifié. Dans le mode pull, le consommateur demande explicitement les événements, le producteur est alors sollicité. ..

Communication événementielle principes de fonctionnement • concepts de base : événements, réactions (traitements associés à l’occurrence d’un événement) • principe d’attachement : association dynamique entre un nom d’événement et une réaction • communication anonyme : indépendance entre l’émetteur et les “consommateurs” d’un événement

Un canal d’évènements Flot des évènements Consommateur Producteur

Un canal d’évènements : notification PushConsumer PushSupplier Consommateur Producteur Push void push(in any data) raises(Disconnected); Consommateur Producteur Canal Push Consommateur Consommateur Producteur actif / Consommateur réactif Le canal diffuse les évènements

Un canal d’évènements : demande Consommateur Producteur Pull() Consommateur Producteur Canal Pull() Consommateur PullSupplier { //demande de production d’un événement any pull() raises(Disconnected); // présence d’un événement any try_pull(out boolean has_event) raises(Disconnected); demande Like consumers, suppliers can also use push or pull behavior. Push suppliers are the more common type, in which the supplier directly forwards data to the event channel and thus plays the client role in the link to the channel. Pull suppliers, on the other hand, are polled by the event channel and supply an event in response, if a new event is available. Polling is done by the try_pull() operation if it is to be non-blocking or by the blocking pull() call: // IDL interface PullSupplier { any pull() raises(Disconnected); any try_pull(out boolean has_event) void disconnect_pull_supplier(); }; Consommateur Producteur réactif / Consommateur actif Le canal procure les évènements

Un canal d’évènements : file d’évènements Consommateur Producteur Pull() Consommateur Producteur Canal Push() Consommateur Consommateur Producteur actif / Consommateur actif Le canal gère des files d’évènements

Un canal d’évènements : collecte d’évènements Consommateur Producteur Push() Consommateur Producteur Canal Pull() Consommateur Consommateur Producteur réactif / Consommateur réactif Le canal est une entité active voire intelligente

4ème RFP Le service de Propriétés (Properties) permet d’associer dynamiquement une liste de propriétés à un objet. Il est possible d’ajouter, de supprimer, de modifier et de retrouver toute propriété associée à un objet. Le service d’interrogations (Query) permet d’exprimer des requêtes sur des ensembles d’objets CORBA. Le service de License (Licensing) contrôle et gère les rémunérations associées à l’utilisation d’un service objet donné. sans modifier son IDL. Ce sont des attributs spécifiques aux besoins du clients date d’expiration ou annotation par ex. il repose sur SQL et permet d’interroger les attributs des objets Permet de manipuler les requêtes comme des objets Corba, les objets resulat sont mis dans une collection.. briques pour mesurer, contrôler et limiter l’utilisation des objets CORBA. Il produit aussi des info pour facturer les clients et rémunérer les fournisseurs…

5ème RFP Le service de Gestion des versions (Change Management) permet de gérer l’évolution des versions des interfaces des objets ainsi que de l'adéquation avec leurs implémentations. Le service d’Annuaire par fonctionnalités (Trader) permet d’associer des fonctionnalités à des objets CORBA. Le client utilise ce service comme l’annuaire des pages jaunes. Le service de Collection (Collection) permet de créer et de manipuler des collections d’objets. ou vendeur : le fournisseur enregistre ces objets en les caractérisant par des propriétés, ... utilise avec le service interrogations il permet de manipuler et effectuer des traitements itératifs sur des ens. d’objets.

Taxonomie des services Nommage + Annuaire par fonctionnalités Persistance + Externalisation Cycle de vie + Relation Serveur de requêtes + Collections + Properties Transaction + Concurrence Sécurité + License Gestionnaire des versions Time Event

CORBA Services en résumé Persistent Object Save objects to databases Concurrency Managing simultaneous access Licensing Managing licensed services Externalization External representation of objects Relationship Manage relationships between objects that don't know about each other Query Query objects on the network Naming How are objects found? Events Standardized mechanism for client notifications. LifeCycle How are objects created, moved, duplicated and deleted? Trader Find objects that have certain properties Transactions Distributed 2-phase commit Interfaced with the XA standard Security Complete distributed security