Imaginemos que tenemos un sistema de procesamiento de pedidos para que diseñe y construya una pizzería.

Los requisitos son:

R1. El sistema debe ser independiente del caso del cliente y del uso, lo que significa que el cliente puede acceder al sistema, lo que no se tuvo en cuenta durante el diseño inicial. Por ejemplo, si la pizzería decide que muchos de sus clientes usan los teléfonos inteligentes Samsung Bada más adelante, escribir un cliente para Bada OS no requerirá volver a escribir la API del sistema y el sistema en sí; o por ejemplo, si resulta que usar iPads en lugar de dispositivos Android es algo mejor para los controladores de entrega, entonces sería fácil crear un cliente iPad y no afectará de ninguna manera la API del sistema;

R2. Reutilización, lo que significa que el sistema puede reconfigurarse fácilmente sin tener que volver a escribir mucho código si el proceso de negocio cambia. Por ejemplo, si más tarde la pizzería comenzará a aceptar pagos en línea junto con el pago en efectivo por parte de los conductores de entrega (aceptar un pago antes de tomar un pedido VS aceptar un pago por entrega), entonces sería fácil adaptar el sistema al nuevo proceso de negocios. ;

R3. Alta disponibilidad y tolerancia a fallos, lo que significa que el sistema debe estar en línea y debe aceptar pedidos 24/7.

Entonces, para cumplir con R3 podríamos usar Erlang / OTP y tener la siguiente arquitectura:

El problema aquí es que este tipo de arquitectura tiene muchas funcionalidades "codificadas". Si, por ejemplo, la pizzería pasará de aceptar pagos en efectivo en la entrega a aceptar pagos en línea antes de que se realice el pedido, entonces llevará mucho tiempo y esfuerzo reescribir todo el sistema y modificar la API del sistema.

Además, si la pizzería necesitará algunas mejoras en su cliente de CRM, tendríamos que volver a escribir la API, los clientes y el sistema en sí.

Por lo tanto, la siguiente arquitectura apunta a resolver esos problemas y, por lo tanto, a ayudar a cumplir con R1, R2 y R3:

Cada 'servicio' en el sistema es un servidor web de Webmachine con una API RESTful. Tal enfoque tiene los siguientes beneficios:

todas las bondades de Erlang / OTP, ya que cada Webmachine es una aplicación de Erlang, que se puede supervisar y poner en una versión de Erlang;Arquitectura orientada a servicios con toda labeneficios de SOA;fácil adaptable acambios en el proceso de negocio;es fácil agregar nuevos clientes y nuevas funciones a los clientes (por ejemplo, al cliente de CRM), porque un cliente puede usar las API RESTful de todos los servicios en el sistema en lugar de una API "central" (Composability del servicio en términos de SOA).

Entonces, esencialmente, la arquitectura del sistema propuesta en la segunda imagen es una Arquitectura Orientada a Servicios donde cada servicio tiene una API RESTful en lugar de un contrato WSDL y donde cada servicio es una aplicación Erlang / OTP.

Y aquí están mis preguntas:

Imagen 2: ¿Estoy tratando de reinventar la rueda aquí? ¿Debería seguir con la arquitectura Erlang / OTP pura en su lugar? ("Pure Erlang" significa las aplicaciones Erlang empaquetadas en un lanzamiento, hablando entre sí a través de gen_server: call y gen_server: cast function calls);¿Puedes nombrar alguna desventaja en el enfoque sugerido? (Foto 2)¿Crees que sería más fácil mantener y hacer crecer (R1 y R2) un sistema como este (Imagen 2) que uno verdaderamente Erlang / OTP?La seguridad de dicho sistema (Imagen 2) podría ser un problema, ya que hay muchos puntos de entrada abiertos a la web (API RESTful de todos los servicios) en lugar de un solo punto de entrada (Imagen 1), ¿no es así?¿Está bien tener varios 'módulos de orquestación' en un sistema de este tipo o tal vez exista alguna práctica mejor? (Servicios de "Aceptar pedidos", "CRM" y "Enviar pedidos" en la Imagen 2);¿El Erlang / OTP puro (Imagen 1) tiene alguna ventaja sobre este enfoque (Imagen 2) en cuanto al paso de mensajes y las limitaciones del protocolo? (En parte discutido en mi anterior similarpregunta, gen_server: call VS HTTP RESTful calls)