Erlang vs The Real/Outside world, come comunicare?

Question

Sto imparando l'erlang e sono molto affascinato dalla mnesia db. Voglio costruire alcune applicazioni del mondo reale in C#/F # usando erlang come backend.

Sto cercando una buona soluzione per comunicare con i nodi di erlang dal mondo esterno.

Quello che ho trovato finora:

(A) OTP.net, una libreria opensource .net attuazione del protocollo 'nativo' comunicazione Erlang

problemi qui:

• La biblioteca è non molto maturo
• Non mi piace il modello oggetto portato da Java (troppe repliche quasi esatte di classi BCL)
• Non mi piace il modello di thread utilizzato per le connessioni.
• Molte le porte TCP aperte sono tenuti
• La mancanza di sicurezza

(B) utilizzare le porte/prese in Erlang e implementare un protocollo personalizzato.

problemi qui:

• non ho alcuna esperienza
• difficile da mantenere/espandersi per le future versioni

Avete qualche consiglio, esperienza in questo argomento?

Devo lavorare sulla libreria OTP.net per adattarlo alle mie esigenze o provare a implementare un nuovo protocollo da zero?

Che dire di una soluzione JSON o REST? C'è qualche libreria di erlang che farebbe il trucco?

Answer 1

La soluzione di porta/presa è una buona idea e non è difficile come potrebbe sembrare. Google's protocol buffers è proprio quello di cui hai bisogno. È molto facile da usare, efficiente e manutenibile. Ha implementazioni per C#, erlang, java, python e molte altre (Vedi OtherLanguages e developer guide)

È possibile utilizzare i buffer di protocollo per definire la struttura del protocollo di richiesta e risposta. Quindi usalo per comunicare tra erlang e qualsiasi altra lingua supportata. Lo tutorial spiegherà tutto. Dopodiché, tutto ciò che devi fare è inviare la risposta sulla porta.

Il vantaggio di questo approccio è che:

1. si può facilmente estendere e modificare il protocollo in futuro
2. E 'molto più efficiente rispetto all'approccio REST
3. E' attualmente utilizzato di Google per quasi tutti i suoi protocolli e formati di file RPC interni

Answer 2

Certo, puoi fare REST con Erlang, vedi ad es. http://www.infoq.com/articles/vinoski-erlang-rest - Se appropriato per le esigenze delle tue app, REST è un approccio eccellente. (Pycon Italia Tre, la prossima settimana a Firenze, ha delle sessioni sulla cooperazione tra Erlang/Python, vedi www.pycon.it se sei vicino alla Toscana ;-).

Answer 3

C'è anche un JSON library per Erlang, che si potrebbe voler esaminare. Non l'ho usato, quindi non posso dire nulla sull'esperienza.

Answer 4

Se si desidera implementare un'API REST in Erlang, c'è solo una cosa da fare. Utilizza l'eccellente MochiWeb Kit per creare il tuo server HTTP che implementa il tuo protocollo.

Non fatevi prendere dal panico, è davvero più facile di quanto sembrerebbe.

Ci sono un numero di tutorial su come farlo, incluso uno screencast set dai programmatori pragmatici.

Viene fornito con un set completo di librerie JSON, quindi starai bene!

Answer 5

Mentre sono d'accordo sul fatto che alcune soluzioni REST siano utili, sia che utilizziate Yaws o Mochikit, vi troverete a cercare di definire un "linguaggio" intermedio per generare query che Mnesia sarebbe in grado di elaborare.

Pertanto offro questo consiglio; qualunque progetto tu abbia in mente per te, basta implementarlo in erlang e utilizzare gli strumenti disponibili. Sarai ricompensato in molti modi.

Quindi puoi sempre provare CouchDB.

Answer 6

Lo facciamo usando YAWS e una semplice implementazione di richiesta/risposta http sul lato client. L'implementazione di YAWS semplicemente delega la chiamata al processo gen_server appropriato dopo aver estratto gli argomenti.

L'unico aspetto negativo di questo approccio è che non è così veloce (i buffer di protocollo di Google sarebbe meglio) - e mantenendo la connessione "vivo" nel gergo HTTP aiutato ridurre tutti i costi di installazione e riduce il numero di stantio connessioni socket Se restituisci insiemi di dati di grandi dimensioni, devi ottenere un po 'più di creatività con lo streaming dei risultati. Per la maggior parte delle nostre richieste di dati non si trattava di un problema: la risposta poteva facilmente adattarsi alla memoria.

Alcuni aspetti positivi se le prestazioni grezzo del protocollo non è che molto di un problema:

• È possibile collegare in un modello di sicurezza (HTTPS o autenticazione)
• È possibile chiamare l'API da tutto ciò che può fare una richiesta web (avevamo un sacco di vecchio codice perl e fogli di Excel in giro - li smistamento è stato banale)

Answer 7

Da allora abbiamo riscritto OTP.NET

Questa libreria è molte volte più matura, poiché è stata riscritta da zero per.NET/CLR, (a differenza del suo predecessore, che è stato appena convertito da Java)

Date un'occhiata a questo post:

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