Erlang vs The Real / Outside world, come comunicare?

Question

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

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

Quello che ho trovato finora:

(A) OTP.net , una libreria .net opensource che implementa il protocollo di comunicazione erlang "nativo"

Problemi qui:

• La libreria non è molto matura
• Non mi piace il modello a oggetti portato da Java (troppe repliche quasi esatte delle classi BCL)
• Non mi piace l'uso del modello di threading per le connessioni.
• Sono necessarie molte porte TCP aperte
• Mancanza di sicurezza

(B) Usa le porte / socket in erlang e implementa un protocollo personalizzato.

Problemi qui:

• Non ho alcuna esperienza
• Difficile da mantenere / espandere per le versioni future

Hai qualche consiglio, esperienza in questo argomento?

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

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

Answer 1

La soluzione port / socket è una buona idea e non è difficile come potrebbe sembrare. Buffer di protocollo di Google è proprio ciò di cui hai bisogno. È molto facile da usare, efficiente e mantenibile. Ha implementazioni per C #, erlang, java, python e molti altri (vedi OtherLanguages ?? e guida per sviluppatori )

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

Il vantaggio di questo approccio è che:

1. Puoi facilmente estendere e modificare il protocollo in futuro
2. È molto più efficiente di Approccio REST
3. Attualmente è utilizzato da Google per quasi tutto il suo RPC interno protocolli e formati di file

Answer 2

Se vuoi 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.

Esistono diversi tutorial su come farlo, tra cui un screencast set dai programmatori pragmatici.

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

Answer 3

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 sessioni sulla cooperazione Erlang / Python, vedi www.pycon.it se sei vicino alla Toscana ;-).

Answer 4

Esiste anche un JSON libreria per Erlang, che potresti voler esaminare. Non l'ho usato, quindi non posso dire nulla al riguardo per esperienza.

Answer 5

Mentre sono d'accordo che una soluzione REST sia utile, sia che tu utilizzi Yaws o Mochikit, ti ritroverai a provare a definire un linguaggio "quotato" intermedio al fine di generare query che Mnesia sarebbe in grado di elaborare.

Pertanto offro questo consiglio; qualunque progetto tu abbia in mente per te, implementalo in erlang e usa 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 delega semplicemente 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 del protocollo di Google sarebbero migliori) - e mantenendo la connessione "attiva". nel linguaggio HTTP ha contribuito a ridurre tutti i costi di installazione e il numero di connessioni socket non aggiornate. Se stai restituendo grandi quantità di dati devi diventare un po 'più creativo con lo streaming dei risultati. Per la maggior parte delle richieste di dati che non costituivano un problema, la risposta poteva facilmente adattarsi alla memoria.

Alcuni aspetti positivi se le prestazioni non elaborate del protocollo non rappresentano un grosso problema:

• Puoi collegarti a un modello di sicurezza (HTTPS o autenticazione)
• Puoi chiamare l'API da qualsiasi cosa possa fare una richiesta web (avevamo un sacco di vecchio codice perl e fogli Excel in giro - ordinarli era 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)

Dai un'occhiata a questo post:

http: //blog.aumcode. com / 2013/10 / nfx-native-interoperabilità-di-net-with.html