Erlang vs Le monde réel / extérieur, comment communiquer?

Question

J'apprends le erlang et je suis très fasciné par le db mnesia Je souhaite construire une application du monde réel en C # / F # en utilisant erlang comme backend.

Je recherche une bonne solution pour communiquer avec les nœuds erlang du monde extérieur.

Ce que j'ai trouvé jusqu'à présent:

(A) OTP.net , une bibliothèque .net opensource implémentant le protocole de communication erlang "natif"

Problèmes ici:

• La bibliothèque n'est pas très mature
• Je n'aime pas le modèle objet porté depuis Java (trop de répliques presque exactes de classes BCL)
• Je n'aime pas le modèle de thread utilisé pour les connexions.
• De nombreux ports TCP ouverts sont requis
• Manque de sécurité

(B) Utilisez ports / sockets dans erlang et implémentez un protocole personnalisé.

Problèmes ici:

• Je n'ai aucune expérience
• Difficile à maintenir / développer pour les versions futures

Avez-vous des conseils, une expérience dans ce domaine?

Devrais-je travailler sur la bibliothèque OTP.net pour l'adapter à mes besoins ou pour implémenter un nouveau protocole à partir de zéro?

Qu'en est-il d'une solution JSON ou REST? Existe-t-il une bibliothèque erlang qui ferait l'affaire?

Answer 1

La solution port / socket est une bonne idée et n’est pas si difficile que cela puisse paraître. Les tampons de protocole de Google sont exactement ce dont vous avez besoin. Il est très facile à utiliser, efficace et maintenable. Il a des implémentations pour C #, erlang, java, python et bien d’autres (Voir Autres langues . et Guide du développeur )

Vous pouvez utiliser des tampons de protocole pour définir la structure du protocole de demande et de réponse. Ensuite, utilisez-le pour communiquer entre erlang et toute autre langue prise en charge. Le tutoriel vous expliquera tout. Après cela, il ne vous reste plus qu'à envoyer la réponse par le port.

L’avantage de cette approche est que:

1. Vous pouvez facilement étendre et modifier le protocole à l'avenir
2. Il est beaucoup plus efficace que le Approche REST
3. Il est actuellement utilisé par Google pour presque tout son RPC interne protocoles et formats de fichier

Answer 2

Si vous souhaitez implémenter une API REST dans Erlang, vous n'avez qu'une seule chose à faire. Utilisez l'excellent MochiWeb Kit pour créer votre propre serveur HTTP qui implémente votre protocole.

Ne paniquez pas, c'est vraiment plus facile qu'il n'y paraît.

Il existe plusieurs tutoriels sur la procédure à suivre, notamment un screencast set des programmeurs pragmatiques.

Il est livré avec un ensemble complet de bibliothèques JSON, donc tout ira bien!

Answer 3

Bien sûr, vous pouvez faire du REST avec Erlang, voir par exemple. http://www.infoq.com/articles/vinoski-erlang-rest - si cela convient aux besoins de vos applications, REST est une excellente approche. (Pycon Italia Tre, la semaine prochaine à Florence, organise des sessions sur la coopération Erlang / Python, voir www.pycon.it si vous êtes près de la Toscane; -).

Answer 4

Il existe également un JSON bibliothèque pour Erlang, sur laquelle vous pouvez vous pencher. Je ne l'ai pas utilisé, je ne peux donc rien en dire par expérience.

Answer 5

Bien que je sois d’accord pour dire qu’une solution REST est utile, que vous utilisiez le yaws ou le mochikit, vous vous retrouverez en train de définir un "langage" intermédiaire. afin de générer des requêtes que Mnesia serait en mesure de traiter.

C’est pourquoi j’offre ce conseil; Quel que soit le projet que vous envisagiez pour vous-même, il vous suffit de le mettre en œuvre en erlang et d'utiliser les outils disponibles. Vous serez récompensé de nombreuses manières.

Là encore, vous pouvez toujours essayer CouchDB.

Answer 6

Nous faisons cela en utilisant YAWS et une simple implémentation requête / réponse http côté client. L’implémentation YAWS délègue simplement l’appel au processus gen_server approprié après avoir extrait les arguments.

Le seul inconvénient de cette approche est que ce n’est pas si rapide (les tampons de protocole Google seraient meilleurs) - et en maintenant la connexion "active". dans le langage HTTP a permis de réduire tous les coûts d’installation et le nombre de connexions de socket obsolètes. Si vous renvoyez des ensembles de données volumineux, vous devez faire preuve d'un peu plus de créativité en retransmettant en continu les résultats. Pour la plupart de nos demandes de données, ce n’était pas un problème - la réponse pourrait facilement entrer dans la mémoire.

Quelques avantages si les performances brutes du protocole ne posent pas vraiment problème:

• Vous pouvez vous connecter à un modèle de sécurité (HTTPS ou authentification)
• Vous pouvez appeler l'API à partir de tout ce qui peut générer une requête Web (nous avions beaucoup d'anciens codes Perl et Excel en attente - leur tri était trivial)

Answer 7

Nous avons depuis réécrit OTP.NET

Cette bibliothèque est plusieurs fois plus mature, car elle a été ré-écrite à partir de zéro pour .NET / CLR,  (contrairement à son prédécesseur qui vient d'être converti à partir de Java)

Jetez un coup d'œil à ce message:

http: //blog.aumcode. com / 2013/10 / nfx-native-interoperability-of-net-with.html