Erlang vs El mundo real/exterior, ¿cómo comunicarse?

Question

Estoy aprendiendo erlang y estoy muy fascinado con mnesia db. Quiero construir alguna aplicación del mundo real en C#/F # usando erlang como back-end.

Estoy buscando una buena solución para comunicarme con los nodos erlang del mundo exterior.

lo que he encontrado hasta ahora:

(A) OTP.net, una biblioteca de código abierto .NET que implementa el protocolo comunicación Erlang 'nativo'

problemas aquí:

• La biblioteca es no muy maduro
• No me gusta el modelo de objeto portado desde Java (demasiadas réplicas casi exactas de las clases BCL)
• No me gusta el uso del modelo de subprocesamiento para las conexiones.
• Muchos puertos TCP abiertos son necesarios
• La falta de seguridad

(B) Use puertos/sockets en Erlang e implementar un protocolo personalizado.

problemas aquí:

• no tengo ninguna experiencia
• duro para mantener/ampliar para futuras versiones

¿Tiene algún consejo, la experiencia en este tema?

¿Debo trabajar en la biblioteca OTP.net para que se ajuste a mis necesidades o intente implementar un nuevo protocolo desde cero?

¿Qué tal una solución JSON o REST? ¿Hay alguna biblioteca de erlang que haga el truco?

Answer 1

La solución de puerto/socket es una buena idea y no es difícil como parece. Google's protocol buffers es justo lo que necesita. Es muy fácil de usar, eficiente y fácil de mantener. Tiene implementaciones para C#, erlang, java, python y muchos más (Consulte OtherLanguages y developer guide)

Puede usar los búferes de protocolo para definir la estructura del protocolo de solicitud y respuesta. Luego úsela para comunicarse entre Erlang y cualquier otro lenguaje compatible. El tutorial lo explicará todo. Después de eso, todo lo que necesita hacer es enviar la respuesta por el puerto.

La ventaja de este enfoque es que:

1. Se puede extender fácilmente y cambiar el protocolo en el futuro
2. Es mucho más eficiente que el enfoque RESTO
3. Se utiliza actualmente por Google para casi todos sus RPC internos protocolos y formatos de archivo

Answer 2

Claro, puedes hacer REST con Erlang, ver p. http://www.infoq.com/articles/vinoski-erlang-rest - si corresponde para las necesidades de sus aplicaciones, REST es un excelente enfoque. (Pycon Italia Tre, la semana próxima en Florencia, tiene sesiones sobre la cooperación de Erlang/Python, mira www.pycon.it si estás cerca de Tuscany ;-).

Answer 3

También hay un JSON library para Erlang, que es posible que desee investigar. No lo he usado, así que no puedo decir nada por experiencia.

Answer 4

Si desea implementar una API REST en Erlang, solo hay una cosa que hacer. Use el excelente MochiWeb Kit para construir su propio servidor HTTP que implemente su protocolo.

No se asuste, realmente es más fácil de lo que parece.

Hay una serie de tutoriales sobre cómo hacerlo, incluido un screencast set de los programadores pragmáticos.

Viene con un conjunto completo de bibliotecas json, ¡así que estarás bien!

Answer 5

Aunque estoy de acuerdo en que alguna solución REST es útil, ya sea que use Yaws o Mochikit, se encontrará tratando de definir algún "lenguaje" intermedio para generar consultas que Mnesia podría procesar.

Por lo tanto, ofrezco este consejo; cualquiera que sea el proyecto que tenga en mente para usted, simplemente impleméntelo en erlang y use las herramientas disponibles. Serás recompensado de muchas maneras.

Por otra parte siempre puedes probar CouchDB.

Answer 6

Hacemos esto usando YAWS y una simple implementación de solicitud/respuesta http en el lado del cliente. La implementación de YAWS simplemente delega la llamada al proceso gen_server apropiado después de extraer los argumentos.

El único inconveniente de este enfoque es que no es tan rápido (los búferes del protocolo de Google serían mejores) y manteniendo la conexión "viva" en el lenguaje HTTP ayudó a reducir todo el costo de configuración y reduce el número de problemas conexiones de enchufe. Si devuelve grandes conjuntos de datos, debe ser un poco más creativo con la transmisión de los resultados. Para la mayoría de nuestras solicitudes de datos eso no fue un problema, la respuesta podría caber fácilmente en la memoria.

Algunos aspectos positivos si el rendimiento bruto del protocolo no es que gran parte de un problema:

• Puede enlazar en un modelo de seguridad (HTTPS o autenticación)
• Puede llamar a la API de cualquier cosa que pueda hacer una solicitud web (teníamos un montón de código perl viejo y hojas de Excel dando vueltas - repartirlas fue trivial)

Answer 7

hemos reescrito desde OTP.NET

Esta biblioteca es mucho más madura, ya que ha sido reescrita desde cero.NET/CLR, (a diferencia de su predecesor, que se acaba de convertir desde Java)

Tome un vistazo a este post:

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