|
|
Prog. Perl | Art Roman | Voyager | Cartes | |
La version 2 beta 1 permet une intégration bidirectionnelle de CORBA, ce qui permet à Voyager d'être utilisé comme client ou serveur CORBA 2. Il est possible de générer une interface distante Voyager à partir de n'importe quel fichier IDL. Cette interface est utilisable pour communiquer avec n'importe quel serveur Voyager ou CORBA.
- Les composants Voyager
Ils étendent les propriétés de l'objet avec une interface spéciale (IIdentity, IMobility, ILyfecycle et IProperty).
IIdentity donne un alias à un objet et donne accès à son adresse courante. Cela permet d'adresser ultérieurement un objet.
IMobility permet de déplacer un objet d'une VM à une autre dans un même système, ou à travers le réseau.
avant déplacement
ILifecycle controle le cycle de vie et la persistance d'un objet. Lorsqu'un objet atteint la fin de son cycle de vie, il ``meurt'', détruit par le Garbage Collector (GC). Le cycle de vie par défaut d'un objet dure tant qu'une référence régulière de Java ou d'un proxy le réfère. Celui d'un Agent est d'une journée (24 heures).
IProperty associe une paire clef/valeur à un objet.
IProxy permet de modifier différents attributs d'un proxy.
Dans cet exemple, tout message envoyé au proxy à travers l'instance virtuelle locale de StockMarket est automatiquement envoyé à l'objet distant, comme s'il était local.
- mobilité : Voyager supporte la mobilité d'objets sérialisables, pas seulement les Agents. Il n'est pas nécessaire de modifier les classes pour avoir le support de mobilité. La mobilité permet :
- de rapprocher deux objets nécessitant d'avoir une discussion utilisant beaucoup de bande passante, et ainsi d'augmenter la vitesse de leur traffic et réduire la charge du réseau.
- de déplacer un objet qui a besoin de la persistance ou d'un processeur puissant, vers une machine qui a ces propriétés.
- de déplacer l'objet d'une machine qui est sur le point d'être déconnectée du réseau, et de le placer sur une autre machine et continuer sa tâche.
Il est possible de déplacer un objet vers un nouveau programme, même s'il est en train de reçevoir de nouveaux messages, comme Voyager gère toute la synchronisation et le forwarding des messages.
- itinéraires : C'est un ensemble de tâches qui doivent être exécutées sur un ensemble de sites.
- persistance : C'est l'habilité qu'à un objet de vivre au-delà de la vie d'une application. Elle est obtenue en stoquant l'objet dans une BDD, spécifiée au démarrage de Voyager. Ensuite, un message destiné à un objet persistant qui n'est pas actuellement en mémoire, charge (automatiquement) l'objet de la BDD et l'active. En interne est utilisé VoyagerDb, mais il est possible de spécifier une autre base de donnée (via JDBC).
- agents : Un Agent est un agent spécial de Voyager qui est autonome. Un agent peut être programmé pour atteindre un ou plusieurs buts, même si l'agent se déplace et perd le contact de son créateur. L'autonomy d'un Agent lui permet de se déplacer de lui-même.
- scalabilité et espaces : Un espace logique (Space) consiste en un ensemble d'objets sous-espaces (subspace), chacun contenant un sous-ensemble des éléments de l'espace. L'architecture Space exploite le parallélisme de telle façon que les opérations sur un espace utilise le temps processeur de chaque machine qui contient un sous-espace. Chaque message envoyé à un sous-espace est cloné pour chaque sous-espace dans l'espace, ce qui fair un rapide déploiement de messages à chaque objet dans l'espace. Chaque sous-espace s'assure qu'aucun message ou évènement n'est délivré plus d'une fois.
- services temporels : cela contient deux classes, l'une Stopwatch génère des statistiques d'exécution (profiling), l'autre Timer permet de générer des alarmes ponctuelles ou périodiques.
- types de messages :cinq types de messages sont supportés : synchrones, #677#>unidirectionnel}unidirectionnel, bidirectionnel, unidirectionnel par Multicast et future. Chaque fois qu'un objet se déplace, il laisse derrière lui un objet forwarder qui fait suivre les messages vers la nouvelle position de l'objet. Quand l'objet meurt, ses forwarders aussi. Comme Voyager traite les Agents comme des objets, on peut créer des agents distants et leur envoyer des messages pendant qu'ils se déplacent.
- messages dynamiques via IProperty, cela permet ce que l'on appelle le Publie/Souscrit (Publish/Subscribe); un objet souscrit à un sujet en utilisant IProperty et associant une clef au sujet. Un message Multicast peut alors être délivré à tous les objets ayant souscrit au sujet.
- Naming et Directory Service : cela permet d'associer un alias à un objet et de se connecter à cet objet via son alias plus tard, même s'il a bougé. Cela est aussi associé à la persistance de l'objet.
- garbage collector (GC) : Il s'agit de la destruction automatique d'un objet, libérant la mémoire utilisée par l'objet à la demande de la VM Java. le GC détruit aussi les objets persistants de la BDD quand cela est nécessaire.
- durée de vie (Life Spans) : un Agent peut avoir un cycle de vie normal, c'est à dire mourir quand il n'y a plus de référence le pointant, mais aussi une durée fixée, une date fixée, vivre et rester inactif pendant une certaine période, ou vivre indéfiniment.
- transaction de services (Voyager Transaction Services (VTS)) est une API basée sur Voyager compatible avec CORBA OTS et JTS de Java, permettant de gérer des séquences d'opérations au niveau d'atomes, pour gérer si la séquence entière fonctionne ou échoue.
- connectivité avec les applets : Voyager inclut un routeur logiciel minimal qui permet à un serveur de servir de passerelle (gateway), et donc permettant une complète connectibilité applet à applet et applet à programme. Le routeur permet aussi aux Agents Voyager de se déplacer librement entre les applets et les programmes.
- #678#>sécurité}sécurité : la classe VoyagerSecurityManager peut etre installée et personnalisée par dessus celui de Java, et permet de restreindre les actions que peuvent faire les agents mobiles.
|
|
Pour tout commentaire, webmaster@e-nef.com Dernière MaJ 15/12/2017 |
|
|
|