Version imprimable
Bonjour,
Je ne sais pas si CORBA pourrait m'aider à résoudre ce problème, mais j'aimerais savoir si il serait possible de réaliser le pattern Observer avec une couche CORBA. Pensez-vous que cela soit possible ?
Je suis entrain de lire un livre sur CORBA et je n'en suis qu'au début, par ailleurs j'ai commandé l'ouvrage "Advanced CORBA(R) Programming with C++" mais je ne devrais le recevoir que d'ici 3 à 4 semaines.
Merci d'avance
Pourquoi pas !
Si tu souhaites que l'observeur et l'observé soient dans des process distincts, ça ne pose pas de problème, il suffit de définir le contrat IDL adpaté.
A mon avis, il faut simplement être vigilant sur l'implémentation du "update()" côté Observer.
Sémantiquement c'est une notification, on ne s'attends pas à être bloqué côté objet observé lorsqu'on l'appelle.
Mais là on a affaire à un appel distant qui peut-être coûteux en temps, côté objet observé. Donc si plusieurs Observer sont inscrits, on aura à chaque fois le coût d'un appel distant + le temps de traitement de la méthode côté Observer (on peut même rester bloqué le temps qu'un timeout IP pète si l'Observeur n'est plus accessible).
En fonction des contraintes de ton appli tu pourras:
- ne rien faire de spécial, si tu n'as pas de contraintes spéciales,
- implémenter une vraie notification afin de rendre rapidement la main côté objet observé.
Ex: ajouter un traitement asynchrone côté serveur ou client (voir AMI CORBA, en fonction de ton ORB, ou bien se faire ça à la main en passant la main à un autre thread lors du "update()").
Dans la documentation de Ice (middleware CORBA-like), il y a un bon chapitre sur l'invocation de méthode asynchrone, les appels bloquants/non bloquants, depuis le client ou dans le serveur.
Voir aussi chez TAO, ils maîtrisent aussi tous ces cas de figures, cet ORB ayant une vocation "temps réel".
Merci beaucoup,
Je réfléchirai avec attention à ce que tu viens de me dire.
Par contre, j'ai lû que la version 3.0 de CORBA contenait du MOM comme JMS, qu'en penses-tu ?
Je réitère que je découvre ce domaine.
Je connais peu CCM mais parlons-en ! :P
Il me semble que CCM exploite le service de notification existant avant CORBA 3.0.
Ce service est effectivement une API vers un MOM comparable à JMS :
- échanges de messages (notifications)
- livraison garantie
- files d'attentes, abonnements à des topics...
CCM définit un moyen standard de connecter le service de notification aux composants CCM.
On peut utiliser le service de notification hors CCM évidemment.
Comme c'est un service délicat à implémenter (il implique une réelle "qualité de service"), tous les ORB ne l'offrent pas.
Pour un pattern "Observer", utiliser ce service est pertinent, ça résoud le problème de blocage du client.
Maintenant je n'ai pas d'avis sur CCM en soi, mis à part qu'il ne me semble pas qu'il existe d'impléméntation "industrielle".
A propos du CCM, attention:
La spec ne dit pas que le Notification Service doit être utilisé.
Elle dit juste que les interfaces du component event model peuvent être mappées sur un sous-ensemble du Notification Service.
De fait, beaucoup des implémentations CCM actuelles n'utilisent pas le Notification Service, mais l'Event Service.
L'Event Service est plus "basique": pas de filtrage, best-effort ...