Question de conception: Comment puis-je accéder à un mécanisme IPC de manière transparente?

Question

Je veux faire (pas de langue particulière):

print(foo.objects.bookdb.books[12].title); 

ou ceci:

book = foo.objects.bookdb.book.new(); 
book.title = 'RPC for Dummies'; 
book.save(); 

Où foo est en fait un service connecté à mon programme via un IPC, et d'accéder à ses méthodes et objets, une couche envoie et reçoit des messages sur le réseau. Maintenant, je ne cherche pas vraiment un mécanisme IPC, car il y a beaucoup de choix. Ce ne sera probablement pas basé sur XML, mais plutôt sur le s. th. comme les tampons de protocole de Google, dbus ou CORBA. Ce dont je ne suis pas sûr, c'est comment structurer l'application pour pouvoir accéder à l'IPC comme je le ferais pour n'importe quel objet. En d'autres termes, comment puis-je faire en sorte que la POO soit mappée de manière transparente sur les limites du processus?

Pas que ce soit une question de conception et je travaille toujours à un niveau assez élevé de l'architecture globale. Donc, je suis assez agnostique quant à la langue dans laquelle cela va être. C#, Java et Python sont tous susceptibles de s'habituer, cependant.

Answer 1

Vous ne devriez pas le faire! Il est très important pour les programmeurs de voir et de ressentir la différence entre un appel IPC/RPC et un appel de méthode locale dans le code. Si vous le faites, qu'ils n'ont pas à y penser, ils n'y penseront pas, ce qui conduira à un code très médiocre.

Pensez:

foreach o, o.isGreen in someList { 
    o.makeBlue; 
} 

Le programmeur suppose que les boucles prend quelques nanosecondes pour terminer, au lieu qu'il faut près d'une seconde si somelist se trouve être à distance.

Answer 2

Je pense que la façon de faire ce que vous demandez est de faire en sorte que toutes les communications d'objets soient considérées comme un passage de message. C'est ainsi que les méthodes d'objets sont traitées dans ruby ​​et smalltalk, entre autres. Avec le passage de message (plutôt que l'appel de méthode) comme mécanisme de communication d'objet, les opérations telles qu'appeler une méthode qui n'existait pas lorsque vous avez écrit le code devient sensible car l'objet peut quand même faire quelque chose de sensible avec le message recherchez une procédure distante, renvoyez une valeur pour un champ portant le même nom dans une base de données, etc., ou lancez une exception 'méthode introuvable' ou toute autre chose à laquelle vous pourriez penser). Il est important de noter que pour les langages qui ne l'utilisent pas comme mécanisme par défaut, vous pouvez quand même passer un message (chaque objet a une méthode 'handleMessage') mais vous n'obtiendrez pas les subtilités syntaxiques, et vous ne sera pas en mesure d'obtenir l'aide de l'IDE sans un effort supplémentaire de votre part pour que l'EDI analyse votre méthode handleMessage afin de vérifier les entrées valides.

Answer 3

Lire sur Java RMI - le matériel d'introduction montre comment vous pouvez avoir une définition locale d'un objet distant.

L'astuce consiste à avoir deux classes avec des signatures de méthode identiques. La version locale de la classe est une façade sur un protocole réseau. La version distante reçoit des demandes sur le réseau et effectue le travail réel de l'objet.

Vous pouvez définir une paire de classes de sorte qu'un client peut avoir

foo= NonLocalFoo("http://host:port") 
foo.this= "that" 
foo.save() 

Et le serveur reçoit des demandes de méthode set_this() et enregistrer() à partir d'une connexion client. Le côté serveur est (généralement) non trivial car vous avez un tas de problèmes de découverte et de gestion d'instance.