SOA: ¿Por qué no usar servidores web Erlang/OTP como servicios?

Question

Después de leer el sitio Service Oriented Architecture Principles y la respectiva Wikipedia article tuve un pensamiento: la plataforma Erlang/OTP puede considerarse como una plataforma SOA y las aplicaciones SOA se pueden construir en ella.

Lo único es que el Service Contract para cada servicio en un sistema así es muy específico: para llamar a un servicio en Erlang/OTP, la capa de orquestación debería realizar llamadas a través de mensajes Erlang o llamadas a gen_server (depende de la implementación).

Esto no permitiría hacer ninguna llamada a los servicios fuera del alcance de la plataforma Erlang/OTP.

Pero, ¿qué ocurre si tratamos de construir cada servicio moviendo todas las funcionalidades de servicio respectivas a un servidor web basado en Erlang, como Mochiweb y esencialmente cambiando la interfaz de cada servicio de gen_server: ¿llame a XML?

Esto permitirá componer varias aplicaciones de 'ladrillos' estandarizados con contratos de servicio universales basados ​​en WSDL.

Además, este enfoque nos permitirá seguir utilizando los supervisores de OTP y otras características de OTP, ya que dicho servicio seguirá siendo una aplicación de OTP.

Entonces, la pregunta es: ¿Cree que la construcción de una aplicación de software con el enfoque de Arquitectura Orientada a Servicios mediante el uso de servidores web OTP (Mochiweb) como Servicios es una buena idea? ¿Puede la capa de procesamiento XML adicional destruir todas las ventajas de dicho enfoque?

Answer 1

La razón principal de esto no se hace es porque usted se limite al protocolo de SOA. Erlang implementa el protocolo de IP con algunos puntos agregados (monitores). Mientras puedes hacerlo, me pregunto si valdría la pena.

En principio, Erlang ya tiene todas las herramientas para la idea de SOA, pero sin todos los excesos de de SOAP y WSDL :)

Answer 2

SOA se puede aplicar a muchas tecnologías de implementación, no sólo SOAPy Web Services, y he encontrado que siempre ha sido beneficioso. Por ejemplo, puede modelar sus vistas de base de datos y procedimientos almacenados como servicios. Puedes modelar tus API java son servicios. etc.

Ahora, volviendo a sus preguntas reales:

Entonces, la pregunta es: ¿Usted cree que la construcción de una aplicación de software con el enfoque de arquitectura orientada a servicios mediante el uso de servidores web (OTP Mochiweb) como Servicios es una buena idea?

No. Todos se están alejando de SOAP y hacia REST; sin embargo, construir una aplicación de software con el enfoque de Arquitectura Orientada a Servicios mediante el uso de servidores web OTP (Mochiweb) como Servicios REST puede ser una buena idea.

¿Puede la capa de procesamiento XML adicional destruir todas las ventajas de dicho enfoque?

Depende de cuál sea su objetivo. Si solo está agregando una capa XML porque cree que es "Lo correcto para hacer ™", entonces siempre tendrá problemas con la capa XML porque será una solución que busca un problema para resolver. Si su objetivo es desacoplar la tecnología de implementación del servidor de la implementación del cliente, creando representaciones comúnmente entendidas para sus entidades, entonces la capa adicional de procesamiento XML (o JSON o lo que sea más adecuado) lo vale.

Answer 3

Esta es nuestra aplicación principal de Erlang: servicios web. Normalmente usamos Yaws Appmods y un article here puede mostrarle mucho sobre cómo se hace. Erlang ha sido una buena plataforma para SOA, debido a lo siguiente:

1. El código libre de efectos laterales se escribe y prueba muy fácilmente.
2. Aislamiento: los procesos en Erlang ayudan a aislar cada solicitud de servicio de una manera limpia.
3. La mayoría de las bibliotecas Erlang como mochiweb, misultin y Chicago Boss se han creado desde cero para admitir sistemas SOA escritos en Erlang.

Es una gran idea aplicar su propia aplicación OTP detrás de cualquiera de estos marcos. Otra gran razón por la cual erlang es adecuado para SOA es la redundancia. Los sistemas SOA deben estar activos. Si una solicitud de servicio falla, se vuelve a intentar a lo largo de una ruta diferente (que, por supuesto, en la capa física, es manejada por una máquina diferente donde se ha distribuido la aplicación OTP).

Dale una oportunidad, gran idea