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

StackOverflow https://stackoverflow.com/questions/807355

Pregunta

Estoy aprendiendo erlang y estoy muy fascinado por la mnesia db. Quiero crear alguna aplicación del mundo real en C # / F # usando erlang como backend.

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

Lo que encontré hasta ahora:

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

Problemas aquí:

  • La biblioteca no es muy madura
  • No me gusta el modelo de objetos portado desde Java (demasiadas réplicas casi exactas de clases BCL)
  • No me gusta el uso del modelo de subprocesos para las conexiones.
  • Se requieren muchos puertos TCP abiertos
  • Falta de seguridad

(B) Use ports / sockets en erlang e implemente un protocolo personalizado.

Problemas aquí:

  • No tengo ninguna experiencia
  • Es difícil de mantener / expandir para futuras versiones

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

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

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

¿Fue útil?

Solución

La solución de puerto / socket es una buena idea y no es tan difícil como puede parecer. búferes de protocolo de Google 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 muchas más (consulte OtherLanguages ?? y guía para desarrolladores )

Puede usar búferes de protocolo para definir la estructura del protocolo de solicitud y respuesta. Luego, úselo para comunicarse entre erlang y cualquier otro idioma compatible. El tutorial lo explicará todo. Después de eso, todo lo que debe hacer es enviar la respuesta a través del puerto.

La ventaja de este enfoque es que:

  1. Puedes extender y cambiar fácilmente la protocolo en el futuro
  2. Es mucho más eficiente que el Enfoque REST
  3. Actualmente es utilizado por Google para casi todos sus RPC internos protocolos y formatos de archivo

Otros consejos

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

No te asustes, realmente es más fácil de lo que parece.

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

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

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

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

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

Por eso ofrezco este consejo; sea ??cual sea el proyecto que tenga en mente para usted mismo, simplemente implementelo en erlang y use las herramientas disponibles. Serás recompensado de muchas maneras.

Una vez más, siempre puedes probar CouchDB.

Hacemos esto utilizando YAWS y una implementación de solicitud / respuesta http simple 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 al mantener la conexión " viva " en el lenguaje HTTP ayudó a reducir todos los costos de instalación y reduce el número de conexiones de socket obsoletas. Si está devolviendo 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.

Algunas ventajas si el rendimiento sin formato del protocolo no es un gran problema:

  • Puede conectarse a un modelo de seguridad (HTTPS o autenticación)
  • Puede llamar a la API desde cualquier cosa que pueda hacer una solicitud web (teníamos un montón de código perl antiguo y hojas de Excel por ahí - clasificarlas fue trivial)

Desde entonces, hemos reescrito OTP.NET

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

Echa un vistazo a esta publicación:

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top