Discussion :

[Anonymous]

Bonjour,

Mon application possède de grosses classes, je voudrais les partager dans mon fichier IDL. En ce moment, j'accède à mon objet partagé par les méthodes corba de chaque attribut. Je voudrais recupérer mon objet en une seule fois, pour accéder à chacun de mes attributs en local.

J'essaye de tester ceci avec une classe simple possèdant seulement 4 attributs.

MON FICHIER IDL:

module RealTime
{
interface Bus {
long getId();
void setId(in long id);
string getName();
void setName(in string name);
long getCourse();
void setCourse(in long course);
long getService();
void setService(in long service);
Bus getBus();
void setBus(in Bus _bus);
};
};

J'utilise le visibroker sous Delphi ou Linux. J'ai essayé de construire la méthode getBus comme ceci:

constructor TBus.Create;
begin
inherited;
end;

function TBus.getBus : RealTime_i.Bus;
begin
Result := TBus.Create;
with Result do
_id := Bus.getId;
_name := Bus.getName;
_course := Bus.getCourse;
_service := Bus.getService;
end
end;


Ceci compile mais lors de l'exécution, le client se termine brutalement. J'ai essayé également de construire seulement un nouveau objet sans l'initialiser, et c'est identique. Je ne comprend pas pourquoi. Il est apparament impossible de retourner l'objet lui même.

function TBus.getBus : RealTime_i.Bus;
begin
Result := TBus.Create;
end;


Si nous avons une classe de 100 attributs, et on veut consulter cahque attribut, je suis sur qu'il existe une façon de ne pas encoder, transmetre sur le réseau et décoder pour chaque attribut.

Quelqu'un peut il m'aider?

[knotty]

Deplacer un objet, ca n'a pas vraiment de sens. Le principe meme de Corba, c'est d'avoir un objet sur un serveur que tu peux distribuer entre plusieurs applications. Si tu en fais une copie locale, oui, mais alors les clients ne sont plus synchronises entre eux.

Si tu veux recuperer une liste d'attributs, c'est different. Pourquoi ne pas ajouter une fonction a ta classe du genre getAttributes() qui retourne du XML par exemple.

Remarque au passage. Si tu as une classe avec 100 membres que tu dois tester un a un, c'est peut etre qu'il y a un probleme dans ton design.

[Anonymous]

Je suis en train de faire des tests de performances pour savoir si CORBA se prête au temps réel.

Ma synchronisation de clients se fait à l'aide du service Concurrence d'accès à l'aide de verrous. A mon sens, c'est l'unique solution. Puisque avec CORBA de base, deux clients ne peux accéder au même objet en même temps. Un des deux clients reçoit un message disant qu'il ne peut accéder à cet objet déja utilisé par quelqu'un d'autre.

Faire une copie locale, ou bien récupérer une liste d'attributs permet de vérifier rapidement l'état de l'objet. Ceci évite de faire des requêtes au serveur pour connaître l'état de chaque attribut (emballage des arguments, transport de l'invocation, déballage des arguments, invocation de l'objet réel, emballage des résultats, transport des résultats, déballage des résultats). On récupère ainsi tous les attributs en une seule fois. Pour un système Temps Réel, les performances sont de taille.

J'essaye de trouver une solution. Ensuite, suivant les performances et les contraintes de l'application Temps Reel, je verrai si je peux utiliser CORBA. La solution la plus simple est de renvoyer une copie de l'objet que je peux consulter rapidement localement. Mais avec Corba et Delphi, ceci ne fonctionne pas et je ne comprends pas pourquoi.

100 attributs est un exemple, pour faire des tests je me place dans le pire des cas.

[knotty]

Tout n'est pas clair dans ma tete sur ce que tu veux faire exactement, mais essaie de suivre mon raisonnement, reprends-moi si mes suppositions sont fausses.

>>
Je suis en train de faire des tests de performances pour savoir si CORBA se prête au temps réel.
<<
oui.

>>>
Puisque avec CORBA de base, deux clients ne peux accéder au même objet en même temps.
<<<
Non, certaines implementation de CORBA ne sont pas multithreadee, mais les implementations commerciales comme orbacus le sont. 100 clients peuvent se connecter simultanement au meme objet, et meme appeler la meme fonction.

Il y a plusieurs niveau de multi-tier. Soit aucun pour des implementation de Corba partielles (comme les versions stables de MICO actuelles)
Soit un meme client peut faire du multi-thread
Soit, des clients differents peuvent se connecter simultanement.

Quand je disais que c'etait surement une mauvaise solution de faire un duplique de ton objet, je parlais en particulier si tu fais du temps reel (autrement, pas de probleme).

Si tu fais du temps reel, que tu fais une copie de ton objet sur le client, et que la valeur change sur le serveur, le client n'est pas mis a jour.

Par exemple pour une application boursiere, inutile de deplacer l'object (Stock:CSCO), puisque qu'il change constamment. Il faut bel et bien que tu lises sa valeur a partir du serveur a chaque fois que ton client fait un refresh.

Mais comme je saisis mal ton probleme, si pour une raison ou pour une autre, tu as effectivement 100 Attributs dans ton objets, passe-les d'un coup. Cree un objet de type
Struct
dans ton IDL, avec le nombre d'attributs que tu veux.
Dans ces cas la, l'objet partage retourne un seul attribut: la struct.

je ne peux pas penser a un seul cas de figure ou tu aurais besoin de faire plusieurs appels a ton objet partage.

Exemple, appli boursiere, retourne l'ensemble des valeurs du NASDAQ
en IDL:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
struct Valeur {
   string name;
   float price;
  string date;
}

typedef sequence<Valeur> ValeurList;

interface NASDAQMgr {
   ValeurList getNASDAQ();  
}

Cela veut dire, a chaque appel, tu recois une liste de tous les stocks, avec pour chacun, leur valeur, nom et date de derniere mise a jour.

J'espere que cela repond, au moins partiellement a ta question...
Bonne chance

[Anonymous]

Je trouve ce forum intéressant, puisqu'on obtient des réponses et on peut discuter de tout ceci, contrairement aux newsgroups de borland.

<<
Non, certaines implementation de CORBA ne sont pas multithreadee, mais les implementations commerciales comme orbacus le sont.
>>

C'est intéressant ce que tu dis. Je possède Visibroker Cpp 4.1 pour Delphi Entreprise et apparement elle n'est pas multithreadee. C'est pour cela que je passe par des verrous.


<<
Si tu fais du temps reel, que tu fais une copie de ton objet sur le client, et que la valeur change sur le serveur, le client n'est pas mis a jour.
>>

Justement, j'utiliserai des verrous pour bloquer les autres clients, pendant la lecture et la modification de l'objet.

<<
Cree un objet de type Struct dans ton IDL, avec le nombre d'attributs que tu veux. Dans ces cas la, l'objet partage retourne un seul attribut: la struct.
>>

C'est ce que je voudrais faire. Pour l'instant, je n'y arrive pas. Cela va surement venir.

idl2pas pour Delphi, convertie toute structure en classe. Pour retourner cette structure, il faut d'abord la créer en appelant le constructeur Create. Et c'est à ce moment que le client plante, je ne sais pas pourquoi. Et pourquoi le client, alors que c'est le serveur qui excute le constructeur?

Mais bon je vais reessayer, on verra bien. Je suis novice en pascal objet, il y a surement des choses qui m'échappent.

Merci knotty pour tes réponses.

[knotty]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
struct Bus {
 string name;
 long id;
 long course;
}

interface BusMgr {
 Bus getBus();
 void setBus(in Bus b);
}

Sur ton serveur, tu as un Objet BusMgr que tu references dans ton Naming Service.
Ensuite, a l'interieur de cette meme instance de BusMgr, tu crees le ou les objet Bus, avec nom, id, course etc... (soit a l'initialisation, soit y a une thread qui lit ca a partir d'une source temps reel)
Connait pas Pascal, mais apparement,

Create Bus("Ligne 2", 2, 124);

Si quelque chose crashe a ce moment la, ca ne peut pas etre un client, il n'y en a pas encore.

Ensuite, fais demarrer ton client.
En utilisant le NamingService, le client recupere une reference locale de BusMgr, une sorte de passerelle qui va permettre de faire des appels.

Ensuite, le client appelle
busMgr.getBus();

et voila.

Si ton client est conecte avec une reference a BusMgr, que, pour x raison, ton serveur plante (surement une erreur de programmation), et que ton client essaie de se connecter au serveur, ca va pas lui plaire car la liaison est cassee.

Exemple,

Dans ton impl de getBus dans BusMgr, tu as :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Bus BusMgr::getBus() {
 Bus bus = Create Bus("", 1, 1); //pour x raison, ca plante
 // a ce moment, ton client est connecte, donc il plante aussi ...
 return bus;
}

Tout ca pour dire, c'est peut etre pour ca que ton client plante, cherche la raison cote serveur.

Argh.. j'espere que je suis a peu pres clair

[Anonymous]

En construisant une structure différente de l'interface pour stocker les attributs, ça fonctionne et même bien.

Avec une structure de 4 entiers et une chaine de 6 caractères, j'accède ou j'écris sur les attributs 4 fois plus vite. Ceci est logique puisque j'appelle seulement une invocation contre 4 auparavant pour chaque attributs.

Merci pour votre aide.

[Anonymous]

En construisant une structure différente de l'interface pour stocker les attributs, ça fonctionne et même bien.

Avec une structure de 3 entiers et une chaine de 6 caractères, j'accède ou j'écris sur les attributs 4 fois plus vite. Ceci est logique puisque j'appelle seulement une invocation contre 4 auparavant pour chaque attributs.

Merci pour votre aide.

[Anonymous]

> Puisque avec CORBA de base, deux clients ne peux accéder au même objet en même temps.
<

>>Non, certaines implementation de CORBA ne sont pas multithreadee, mais les implementations commerciales comme orbacus le sont. 100 clients peuvent se connecter simultanement au meme objet, et meme appeler la meme fonction.
<<

J'ai testé Visibroker C++ 4.5 avec une implémentation C++ et une implémentation Delphi.
L'implémentation C++ est multithreadée, celle de Delphi ne l'ai pas.

Mes developpements étant en Delphi, j'ai résolue mon problème en ayant un client Deplhi et un serveur C++. Avec cette solution mixte, plusieurs clients peuvent également accéder à un même objet en même temps.