Technologies pour le Metacomputing Thierry Priol IRISA/INRIA

Métacomputing Introduction, définition et applications Technologies pour le Metacomputing Cobra: un environnement fondé sur CORBA Un exécutif pour des grappes de PC Concept d’objet CORBA parallèle Quelques applications en cours de réalisation Traitement du signal Réalité virtuelle

Introduction, définitions Metacomputer (métacalculateur) Collection de calculateurs/supercalculateurs Dispersion géographique des calculateurs/supercalculateurs Connexion par un réseau à très haut-débit Vision logique d’une seule machine: le métacalculateur Il y a 15 ans, cela s’appelait tout simplement un système distribué ! Metacomputing (métacalcul) Programmation des métacalculateurs (systèmes, éxécutifs, langages, outils, applications)

Meta application Une application qui ne peut s’exécuter sur une seule machine limitation des ressources (puissance des processeurs, mémoire, disque) absence de certains types de ressources (visualisation, …) Une application qui est une collection de modules relativement indépendants pouvant s’exécuter de façon asynchrone Le parallélisme est présent à l’intérieur d’un module Exemple d’une méta application: conception d’un satellite Analyse de structure, dynamique, thermique, optique, ...

Métacomputing: vers l’informatique de demain ? Un accroissement sensible de la demande en ressources de calculs Généralisation des outils de simulation à tous les niveaux de l’industrie (Petites, Moyennes et Grandes Entreprises) Calculateurs de plus en plus complexes à utiliser Calculateurs de plus en plus chers à maintenir Un regard sur le passé Analogie avec l’énergie électrique...

Energie

Informatique

Applications du Métacomputing Visualisation à distance Systèmes de réalité virtuelle (CAVE, …) Simulation distribuée (ou Problem Solving Environment) La puissance de calcul disponible sur un simple PC permet d’envisager le couplage de codes de simulation Travail coopératif Faire travailler plusieurs experts simultanément sur les résultats d’une simulation

Problèmes liés au Metacomputing Metacomputer : une collection de machine environnement logiciel hétérogène (système d’exploitation, exécutif) pas de partage de fichiers possible règles de sécurité différentes dans chaque site Les problèmes à résoudre Allocation de ressources Communication Gestion des données distribuées Sécurité Tolérance aux défaillances

Allocation de ressources: problèmes Autonomie des sites participants différentes organisations avec leurs propres règles (allocation, sécurité, …) Gestionnaire de ressources hétérogènes Condor, NQE, CODINE, EASY, LSF, PBS, LoadLeveler,… Extensibilité ajout de nouvelles ressources, impact sur les autres sites ? Allocation simultanée des ressources distribuées Certaines applications nécessitent une co-allocation (allocation simultanée de ressources sur plusieurs sites)

Communication Contraintes Différentes approches: Technologies réseaux variées (ATM, HIPPI, Gigabit, …) Performance (TCP/IP ?) Interopérabilité Différentes approches: Echange de message (PVM, MPI) RPC (DCE, …) Objet distribué (CORBA, …)

Gestion de données distribuées: problèmes La distribution d’une application, sous forme de composants, pose le problème de l’accès aux données Chaque composant consomme et produit des données (fichiers) Echange de données (transfert de fichiers entre machines) Mécanismes de mouvement et d’accès aux données Limitation des solutions existantes (NFS, MPI-IO, WWW, …) Contraintes de conception: Doit nécessiter peu de modifications dans les applications Ne doit pas imposer de fortes contraintes à l’installation Doit pouvoir exploiter le maximum de performance offerte par le réseau

Sécurité Utilisation de plusieurs machines avec ses propres règles de sécurité Impossible de transférer des fichiers de façon transparente (mot de passe!) Confidentialité des données Transfert de données confidentielles à l’échelle de l ’Internet Cryptage des données

Tolérance aux défaillances Meta application: une application distribuée! Que faire si un composant de l’application tombe en panne ? Techniques Checkpointing problème de la définition d’un état cohérent nécessite souvent la modification des logiciels (définition d’un état) sauvegarde des états Réplication impossibilité de répliquer tous les modules quel module choisir ?

Quelques exemples d’environnements pour le Metacomputing Approche par échange de messages Globus Approche par RPC (Remote Procedure Call) Netsolve Ninf Approche orientée objet distribué Pardis Cobra

Approche par échange de messages

Globus I. Foster et C. Kesselman Une boite à outils plutôt qu’un environnement de metacomputing Un ensemble de services: Allocation de ressources (GRAM) Communication unicast/multicast (Nexus) Gestion de l’information, état du système (MDS) Sécurité (GSI) Monitoring (HBM) Accès aux données à distance (GASS) Gestion des exécutables (GEM)

Architecture de Globus

Allocation de ressource (GRAM) Concept de gestionnaire local des ressources Offrir une vision homogène de l’allocation des ressources quelque soit le gestionnaire de ressource utilisé (NQE, LSF, CODINE, …) Service d’information Disponibilité, caractéristiques, propriétés des ressources Langage de spécification de ressources (RSL) Langage pour exprimer un besoin particulier en ressources Exemple: &(executable=myprog) (|(&(count=5)(mempry>=64)) (&(count=10)(memory>=32))) Courtier de ressources Spécialisation: transformation de requêtes RSL en requêtes plus simples avec l’ajout d’un nom de machine identifiant le gestionnaire de ressource

Allocation de ressources (GRAM)

Accès aux données (GASS) GASS: Global Access to Secondary Storage Un mécanisme de mouvement et d’accès aux données Optimisé pour les patrons d’accès des applications de metacomputing Implémentation de nécessitant pas de services particuliers Contrôle de l’utilisateur pour optimiser les transferts de données cache de donnée, filtrage, … Problèmes à résoudre: Nommage, API, authentification, communication, performance...

Accès aux données (GASS) Nommage par URL x-gass://host:port/filename ftp://host/filename Interface de programmation: proche de celle d’UNIX globus_gass_open() globus_gass_close() globus_gass_cache() Sémantique copie vers le cache à l’ouverture mise à jour du fichier à la fermeture si modification Performance: optimisation pour des patrons d’accès (via un cache) lecture-seulement (à partir du cache local) écriture-seulement (vers le cache local) lecture-écriture (à partir/vers le cache local) écriture-seulement, ajout (vers le serveur à distance) Support de GASS dans GRAM &(executable=x-gass://quad:12/file) (stdin = x-gass://quad:12/myin) (stdout = /home/bester/output) (stderr = x-gass://qd:1/dev/stdout)

Accès aux données (GASS)

Approches par RPC

Netsolve (Univ. Tennessee) H. Casanova & J. Dongarra Concept de librairie étendu à l’échelle d’Internet ou d’un Intranet « Librairie virtuelle » Eviter l’installation de logiciels Concepts de base accès à distance à des ressources de calcul (client/serveur) Espace de nommage Données du problème sont transmises à un serveur Interfaces avec C, Fortran, Matlab, Java, … Equilibrage des charges entre serveurs

NetSolve: programmation Du coté du client Transparence de la localisation des serveurs (réseau transparent) Accès à la « librairie virtuelle » par identificateur Appel synchrone/asynchrone parameter (MAX=100) double precision A(MAX,MAX),B(MAX) integer IPIV(MAX),N,INFO,LWORK integer NSINFO c Solve linear equations call DGESV(N,1,A,MAX,IPIV,B,MAX,INFO) call NETSL(‘DGESV()’,NSINFO, N,1,1,MAX,IPIV,B,MAX,INFO)

NetSolve: accès aux logiciels Du coté du serveur Gestion du matériel et du logiciel Interface avec les logiciels scientifiques installés sur le serveur BLAS, LAPACK, ItPack, FitPack, FFTPack, NAG Software, … Outils pour l’installation de nouveaux logiciels (Compilateur NetSolve) Du coté de l’agent Courtier en ressources Stocke l’information concernant la disponibilité des machines sur le réseau et des logiciels scientifiques disponibles Equilibrage des charges par prédiction des temps d’exécution performance du réseau performance du serveur (LINPACK) et de sa charge Temps d’exécution du logiciel en fonction de la taille du problème

Ninf (Electronical Lab., Tsukuba) Nakada et al. Network Infrastructure for Global Computing Accès aux serveurs par RPC protocole dynamique + interopérabilité Interface de programmation RPC synchrone/asynchrone Transaction Callback Langage de description d’interface Langage IDL spécifique Equilibrage dynamique des charges allocation dynamique des ressources NumericalRoutine Ninf Server C Client NumericalRoutine Ninf Server Excel Client MetaServer Java Client NumericalRoutine Ninf Server Mathematica Client

Ninf: Interface de programmation Caractéristiques: Langage cible: C, C++, Fortran, Java, Lisp …,Mathematica, Excel Nommage des fonctions: ninf://HOST:PORT/ENTRY_NAME Appel synchrone/asynchrone: double A[n][n],B[n][n],C[n][n]; /* multiplication de matrice */ Ninf_call(«ninf://etlhpc.etl.go.jp:3000/dmmul»,n,A,B,C); id = Ninf_call_async(«dmmul»,n,A,B,C); Ninf_wait(id);

Ninf: Interface de programmation Transaction: exploitation du parallélisme au niveau du réseau analyse de dépendance à l’exécution exécution de type dataflow dmmul A B C D E F G double A[n][n],B[n][n],C[n][n]; Ninf_transaction_start(); Ninf_call(«dmmul»,n,A,B,E); Ninf_call(«dmmul»,n,C,D,F); Ninf_call(«dmmul»,n,E,F,G); Ninf_transaction_end();

Ninf: Interface de programmation Callback: notification du client par le serveur exécution d’une fonction du client par le serveur Client Serveur Ninf_call Void CallbackFunc(…) { /* corps de la fonction */ } Ninf_call(« func », arg, …, CallbackFunc); CallbcakFunc

Ninf: Langage de description d’interface Spécifications: Fonctions et arguments (mode) Librairies associées aux fonctions Complexité Spécification du langage d’implémentation Ninf Executable Ninf Computational Server Define dmmul(long mode_in int n, mode_in double A[n][n], mode_in double B[n][n], mode_out double C[n][n]) “ description “ Required “libXXX.o” CalcOrder n^3 Calls “C” dmmul(n,A,B,C); Stub Program Ninf Procedure Ninf Stub Generator IDL File

Ninf: équilibrage des charges Comment répartir les calculs afin d’exploiter au mieux les ressources de calcul ? Changement dynamique de la charge (réseau, serveurs) Informations distribuées Informations nécessaires pour une répartition équitable de la charge Caractéristiques des serveurs Etat des serveurs (charge, …) Etat des réseaux (latence, débit) Caractéristiques des applications (complexité, taille du problème, …)

Ninf: équilibrage des charges Directory Service Server Side Server Proxy MetaServer Client Side Scheduler Server Probe Module Server Proxy Client Server Load query Schedule query Data Client Client Proxy Server Proxy Server Throughput Measurement

Approche orientée objet distribué

CORBA et le Metacomputing CORBA est un standard pour la conception d’applications distribuées proposé par l’OMG (Object Management Group) Orienté objet Mécanisme d’invocation à distance (RPC) Indépendance vis à vis du matériel, des systèmes d’exploitation et des langages de programmation Indépendance vis à vis des implémentations (interoperabilité) Concept de bus logiciel Composants principaux: Interface Description Language (IDL) Object Request Broker (ORB): communication entre objets Ensemble de services (nommage, événement, …)

Architecture de CORBA operation() client Implémentation de l’objet IDL in args operation() client Implémentation de l’objet out args + return value Répertoire d’implémentation IDL skeleton DSI Répertoire d’interface IDL stub ORB interface DII Adaptateur d’objet GIOP / IIOP / ESIOP ORB core

Exemple de spécification IDL interface MatOps { typedef long vect[100]; typedef long mat[100][100]; void MatVect( in mat A, in vect B, out vect C ); }; Implémentation de l’objet Compilateur IDL Serveur Invocation de l’objet Client IDL skeleton IDL stub Object Adapter Object Request Broker (ORB) server->MatVect( A, B, C);

Pardis (Univ. Indiana) K. Keahey et D. Gannon Une approche « à la CORBA » reprend les même concepts: ORB + IDL a priori non interopérable avec des implémentations de CORBA Intégration du parallélisme Concept d’objet SPMD Concept de séquence distribuée Support de l’asynchronisme grâce au future Associé à l’appel non bloquant d’une opération future = valeur + sémaphore Exemples d’utilisation Traitement des résultats intermédiaires (visualisation, mise au point, …) Couplage de codes (synchronisation lâche)

Pardis: concept d’objet SPMD IDL (du service) C++ (client) typedef dsequence <double,1024, (BLOCK,BLOCK)> diff_array; interface diff_object { void diffusion( in long timestep, inout diff_array darray); }; diff_object* diff = diff_object::_spmd_bind(“example”, HOST1); diff->diffusion(64, my_diff_array); spmd_bind diffusion spmd_bind diffusion spmd_bind diffusion Application B Application A diff_object

Pardis: les futures IDL service A IDL service B interface direct { void solve(in mat A, in vec B, out vec X); }; interface iterative { void solve(in double tol, mat A, in vec B, out vec X); }; C++ (client) direct_var = d_solver = direct::_spmd_bind(“direct_solver”, HOST_1); iterative_var = i_solver = iterative::_spmd_bind(“itrt_solver”, HOST_2); ... PARDIS::future <vec_var> X1; vec_var X1_real, X2_real; i_solver->solve_nb(tolerance, A, B, X1); d_solver->solve_nb(A,B,X2_real) X1_real = X1; double diff = compute_diff(X1_real, X2_real); Client A B

Cobra: un environnement fondé sur CORBA Un environnement à l’échelle d’un Intranet Problem Solving Environment Application de type client/serveur ou serveur/serveur (couplage de codes) Adoption de standards CORBA: communication entre composants MPI: communication au sein d’un composant Cobra un gestionnaire de ressources pour un réseau de PC/stations de travail une extension de CORBA pour supporter le parallélisme (SPMD)

CORBA et le parallélisme SPMD Un programme parallèle SPMD est un ensemble de processus identique Comment encapsuler un tel programme au sein d’un objet CORBA parallèle ? Programme Parallèle Programme Parallèle Objet CORBA IDL Extended-IDL MPI MPI obj. obj. proc proc obj. After this short overview of CORBA, I come back to our work that aims at combining parallelism and distributed programming . A parallel solver is made of a set of identical processes. We assume that we have a SPMD execution model within a parallel solver. Therefore each process is independent and can be executed in parallel. These processes use MPI or PVM to communicate between themselves. The problem is to encapsulate a parallel solver into a CORBA object. There are two alternatives to do this. The first one consists in creating a CORBA object. This object is used as an interface between message-passing environment and CORBA environment. Indeed, it uses message-passing to communicate with processes of the solver and it receives CORBA requests from the client. This approach has a major drawback: everything is centralized by the CORBA object. The second alternative (our solution) consists in defining a new kind of object: Parallel CORBA object. This object is described by an extension of the IDL. A parallel CORBA object is a collection of identical CORBA objects. Each object in the collection plays the same role as a process within a parallel solver. The main difference from the first approach is that each object of the collection receives request from client. proc proc MPI obj. obj. Processus SPMD Objet CORBA parallèle

Concept d’objet CORBA parallèle Serveur 1 Service parallèle Serveur n Implémentation de l’objet Adaptateur d’objet Squelette IDL Implémentation de l’objet Adaptateur d’objet Squelette IDL Process Objet CORBA parallèle = Collection d’objets CORBA Client Invocation objet ... Talon IDL Courtier d’objet (ORB)

Objet CORBA parallèle mise en oeuvre Contraintes Ne pas modifier le courtier d’objets (ORB), rester compatible CORBA Gestion des données Distribution ou réplication des valeurs de paramètres au sein de la collection d’objets Invocation entre objets Objet standard  objet parallèle Objet parallèle  objet standard Objet parallèle  objet parallèle Interface avec les services CORBA nommage des services parallèles As we have seen in the previous slide, a parallel CORBA object is made of a collection of identical objects. Since objects are associated to parallel processes, data have either to be replicated or distributed among objects of the collection depending on the data distribution needed by the parallel solver. These two points are the main features of a parallel CORBA object. To well integrate parallel CORBA object within a CORBA environment, a parallel CORBA object has to be invoked by a standard object. Moreover, a parallel CORBA object has to be able to invoke a standard CORBA object or another parallel CORBA object.

Compilateur Extended-IDL Définition de l’interface d’un service parallèle Distinction entre service standard et service parallèle Distribution des valeurs des paramètres lors d’une invocation Génération du talon Appel simultané de chaque opération sur l’ensemble des objets de la collection Utilisation d’une librairie de communication (MPI) au sein du talon pour la distribution ou la redistribution des données Génération du squelette Stockage de l’information sur la distribution des paramètres We want to have a programming environment that has to be CORBA-compliant as possible. We can’t make any modification to the ORB. The only other alternative is to modify the code generation process of the stub and the skeleton. As a parallel CORBA object has not the same features than a standard CORBA object, we extended the IDL. We call it Extended-IDL Our extension consists in adding new keywords in order to specify the number of objects in the collection and data distribution. In the following slides, to avoid any confusion, I will talk about parallel interface and standard interface. A parallel interface is the Extended-IDL specification of a parallel CORBA object whereas a standard interface is the IDL specification of a standard CORBA object.

Spécification du nombre d’objets au sein d’une collection Plusieurs possibilités offertes un nombre indéterminé Un nombre fixe Une fonction Problème de l’héritage d’interfaces interface [*] MatOps { ... }; interface [2^n] Compute: MatOps { ... }; interface [*] I1 { ... }; interface [4] I2 { ... }; interface [2 .. 4] I3 { ... }; interface [2^n] I4 { ... }; To differentiate a parallel interface from a standard interface, we add two brackets after the keyword “interface”. Within the two brackets, we can specify the number of objects within the collection of the corresponding parallel CORBA object. There are several ways to specify this number of objects. A star means that this number does not need to be fixed. An integer value indicates that parallel interface is implemented by this specific number of objects. In parallel interface I3, this number is specified by an interval whereas in parallel interface I4, it is specified by a function. This function describes any number that is a power of 2. Interface inheritance exists in the IDL. So we allow parallel interface inheritance but with some restrictions. Parallel interface inheritance is allowed when it does not modify the specification of the service. In these 2 examples, the parallel interface Compute inherits from the parallel interface MatOps. Consider this example. Any power of 2 objects can implement parallel interface Compute and MatOps. So in such situation inheritance is allowed. But in this example, any number of objects can implement parallel interface Compute, but not parallel interface MatOps. So inheritance is forbidden. interface [2^n] MatOps { ... }; interface [*] Compute: MatOps { ... };

Spécification de la distribution des paramètres Mode de distribution proche de celle d’HPF void MatVect( in dist[BLOCK][*] mat A, in vect B, out dist[BLOCK] vect C ); Nouveau type pour les paramètres distribués Compilateur Extended-IDL Now I show you how to specify data distribution within a parallel interface. Only array can be distributed. All other CORBA types are replicated. Parameters that need to be distributed are preceded by the keyword “dist”. This keyword is followed by the distribution mode of each array dimension. We have the same distribution mode that those specified in HPF. We have block distribution, cyclic distribution, block cyclic distribution. On this example, we distribute matrix A by row. The star means that the second dimension of the matrix A is not distributed. We distribute vector C by block. Vector B is not distributed, so it is replicated among objects of the collection. The extended-IDL compiler has to generate two method prototypes. One is used by standard CORBA object on client side. The other is used on the server side. On the client side, type of parameter is an array because sequential clients see entirely each array. On the server side, we introduce a new type (distributed array) because each object receives only a part of the array. Size of each part is often unknown at compile time. So, distributed array is an extension of CORBA type called sequence. A sequence is a kind of array whose size is variable. void MatVect( const mat A, const vect B, vect C ); void MatVect( const darray_mat &A, const darray_vect &B, darray_vect &C ); Talon Squelette

Génération du talon Distribution physique des données (mode in) Construction d’une requête multiple Assemblage des données distribuées (mode out) pco->MatVect( A, B, C ); void MatVect(in dist[BLOCK][*] mat A, in vect B, out dist[BLOCK] vect C ); talon A B C #2 squel. obj. 1 A A B C #1 objet Objet CORBA parallèle Objet CORBA B The stub code generation process has to be modified to handle parallelism and data distribution. Consider this example. Our client, a CORBA object invokes the method MatVect implemented by a parallel CORBA object. When the client invokes method MatVect, stub receives arrays A and B entirely. But each object of the server operates only on a subset of distributed data. Therefore, the first thing that the stub must do, is to split distributed arrays. Matrix A is split in 2 parts because we have a block distribution and parallel CORBA object is implemented using 2 objects. Then, the stub creates 2 requests where it puts a copy of the replicated data B and a different part of the distributed data A. The stub sends simultaneously these requests through the ORB to the parallel CORBA object. As each object of the server receives a request at the same time, they can be executed in parallel. Output parameters sent back by parallel CORBA object are stored into the request data structure. As C is distributed, stub must gather all parts of C before sending it back to the client. squel. obj. 2 C ORB Requests serveur client

Génération du talon Objet CORBA parallèle Lorsque l’objet appelant est parallèle et l’appelé est séquentiel Election d’un objet pour l’invocation Assemblage des données Lorsque à la fois l’objet appelant et l’objet appelé sont parallèles Election d’un sous-ensemble d’objets pour l ’invocation Redistribution des données en fonction de la distribution chez l’appelant et celle de l’appelé Objet CORBA squel. obj. obj. 1 talon Objet CORBA parallèle obj. 2 talon squel. obj. 1 MPI Previously, I talked about the work that a stub must do when a standard CORBA object invokes a parallel CORBA object. Now, I will show you what a stub must do when a parallel CORBA object wants to invoke another service. First, consider the situation where a parallel CORBA object invokes a standard CORBA object. As the server is sequential, only one request must be sent through the ORB. Therefore, objects of the client must synchronize themselves and choose which one has to send the request. Stub is in charge of this operation. Moreover, in some situation, data are distributed among objects of the client. Stub that is responsible to send the request has to gather such data from each object of the client, before creating the request. When the stub receives results from the skeleton, it has to forward them to each object of the client Now, consider another situation where a parallel CORBA object invokes another parallel CORBA object. The main difference from the first situation is that here “p” requests must be sent by the client. One for each object of the server. These “p” requests must be dispatched on the “n” objects belonging to the client. Moreover chosen objects have to do the same operations I presented in the previous slide after gathering distributed data. obj. n talon squel. obj. p ORB client serveur

Génération du squelette Stockage de l’information sur la distribution associée à l’objet (distributed array). void op1( in vect A, in dist[BLOCK] vect B ); A squel. Objet 1 talon void op2( in vect C ); B A squel. Objet Objet talon MPI B squel. A Objet 2 talon As I showed you, most of the modification are applied to the stub code generation process. The skeleton code generation process has to be modified to handle data distribution information. Let me illustrate this on an example. First, a standard CORBA object invokes the method op1 implemented by a parallel CORBA object. This method has two input parameters, one non-distributed (vector A) and one distributed (vector B). After this invocation, A is replicated among objects of the collection where as B is distributed by block among them. Only the skeleton knows how arrays A and B are distributed because it is generated from the Extended-IDL specification. So to provide data distribution information, skeleton puts them into the distributed array data structure. In this example, method op1 invokes method op2 implemented by a standard CORBA object. This method has one input parameter (vector C). Thanks to information stored with the distributed array, the stub of the parallel CORBA object knows if it has to gather data before creating a request. ORB ORB B co->op2( A ); co->op2( B ); pco->op1( A, B );

Interface avec le service de nommage Le service de nommage permet d’associer un nom à un objet Serveur: objet de la collection OpMat_Impl* obj = new OpMat_Impl(); NamingService->join_collection("Matrice", obj); ... NamingService->leave_collection("Matrice", obj); Client objs = NamingService->resolve_collection("Matrice", obj); svr = OperationsMatricielles::_narrow(objs) /* ... */ svr->multiplication(A,B,C);

Cobra: un éxécutif pour les objets CORBA parallèles Nœud de calcul Objectifs Exécution des objets CORBA parallèles Allocation de ressources aux utilisateurs Administration de la plate-forme Contraintes Services accessibles sur le réseau Exécutif Cobra Un ensemble de services CORBA pour une grappe de PCs interconnectés par SCI Anneau SCI (200 MB/s) Grappe SCI Comm. SCI PC SMP 2 x Pentium Pro/II 128 Mo EDO RAM 2 Go Disk PCI-SCI Card Nœud de service

L’exécutif Cobra Gestion de ressources Administration Extensibilité Machine parallèle virtuelle Région de mémoire partagée Administration Configuration Utilisateurs Extensibilité Plusieurs nœuds de service

Application de traitement du signal Modèle réduit sur un socle pivotant IDAHO: une application de traitement du signal (électromagnétisme) Un modèle réduit d’avion est illuminé par un faisceau pour chaque angle de (de 0 à 360°) et pour des fréquences variant de 2 à 8 GHz L’expérience dure 90 heures et génère 1Goctets de données Chambre

Architecture logicielle Chargement de l’applet JAVA du serveur WEB (1) Serveur WEB Apache Objet CORBA parallèle IDAHO Création de la VPM (2) Objets CORBA IDAHO ... Services Cobra Destruction de la VPM (6) Objet CORBA Applet Java proxy IDAHO Initialisation (3) Exécution (4) Visualisation (5) Station de travail Nœuds de calcul Nœuds de service

Applications de réalité virtuelle Résultats du calcul de radiosité RADIOSITE: une étape de prétraitement pour calculer l’échange d’énergie entre objets dans une scène Le calcul du radiosité est effectué de façon itérative Plusieurs heures de calcul Nécessité de visualiser à chaque itération dans le cas d’un processus d’optimisation (placement de sources lumineuses)

Réalité Virtuelle ... Objet CORBA parallèle VRML Applet Serveur WEB Apache Objet CORBA parallèle Chargement de l’applet JAVA du serveur WEB (1) RADIOSITY Objets CORBA RADIOSITY ... Services Cobra Destruction de la VPM (6) RADIOSITY Objet CORBA Création de la VPM (2) VRML proxy RADIOSITY Initialisation (3) Exécution (4) Visualisation (5) Applet Station de travail Nœud de calcul Nœud de service

Conclusion & perspectives Metacomputing De nombreux systèmes existent mais ne sont pas interopérables! On réinvente souvent la roue! Réels besoins: à l’échelle de l’INTERNET ou de l’INTRANET ? Nos travaux actuels et le futur proche Approche: utilisation et extension de standards existants Conception d’un ORB efficace (ESIOP) Système de gestion de données (service CORBA) Langage de coordination pour la conception d’applications Applications via des contrats (Aerospatiale, Esprit Jaco3, Soft-IT)