Vamos imaginar que temos um sistema de processamento de pedidos para uma pizzaria projetar e construir.

Os requisitos são:

R1 O sistema deve ser independente de caso e de uso, o que significa que o sistema pode ser acessado por um cliente que não foi levado em conta durante o projeto inicial. Por exemplo, se a pizzaria decidir que muitos de seus clientes usam os smartphones Samsung Bada posteriormente, escrever um cliente para o Bada OS não exigirá reescrever a API do sistema e o próprio sistema; ou, por exemplo, se o uso de iPads em vez de dispositivos Android for de alguma forma melhor para drivers de entrega, seria fácil criar um cliente iPad e não afetaria a API do sistema de forma alguma;

R2 Reusabilidade, o que significa que o sistema pode ser facilmente reconfigurado sem reescrever muito código se o processo de negócios mudar. Por exemplo, se mais tarde a pizzaria começar a aceitar pagamentos on-line junto com a aceitação de dinheiro pelos condutores de entrega (aceitando um pagamento antes de aceitar um pedido VS, aceitando um pagamento na entrega), seria fácil adaptar o sistema ao novo processo de negócios ;

R3 Alta disponibilidade e tolerância a falhas, o que significa que o sistema deve estar on-line e aceitar pedidos 24 horas por dia, sete dias por semana.

Então, para conhecer o R3, podemos usar o Erlang / OTP e ter a seguinte arquitetura:

O problema aqui é que esse tipo de arquitetura tem muita funcionalidade "codificada". Se, por exemplo, a pizzaria passar de aceitar pagamentos em dinheiro na entrega para aceitar pagamentos on-line antes do pedido ser feito, será preciso muito tempo e esforço para reescrever todo o sistema e modificar a API do sistema.

Além disso, se a pizzaria precisar de alguns aprimoramentos em seu cliente CRM, então, novamente, teríamos que reescrever a API, os clientes e o próprio sistema.

Assim, a arquitetura a seguir tem como objetivo resolver esses problemas e, assim, ajudar a atender às necessidades de R1, R2 e R3:

Cada 'serviço' no sistema é um servidor da Webmachine com uma API RESTful. Essa abordagem tem os seguintes benefícios:

todo o bem de Erlang / OTP, já que cada Webmachine é um aplicativo Erlang, que pode ser supervisionado e pode ser colocado em uma versão Erlang;arquitetura orientada a serviços com todo obenefícios de SOA;fácil adaptável aalterar no processo de negócios;É fácil adicionar novos clientes e novas funções aos clientes (por exemplo, ao cliente CRM), porque um cliente pode usar APIs RESTful de todos os serviços do sistema em vez de uma API 'central' (composição de serviço em termos de SOA).

Assim, essencialmente, a arquitetura do sistema proposta na segunda imagem é uma Arquitetura Orientada a Serviços, na qual cada serviço tem uma API RESTful em vez de um contrato WSDL e onde cada serviço é um aplicativo Erlang / OTP.

E aqui estão minhas perguntas:

Figura 2: Estou tentando reinventar a roda aqui? Eu deveria ficar com a arquitetura pura Erlang / OTP? ("Erlang puro" significa aplicativos Erlang compactados em uma liberação, conversando entre si via gen_server: call e gen_server: chamadas de função de transmissão);Você pode nomear quaisquer desvantagens na abordagem sugerida? (Figura 2)Você acha que seria mais fácil manter e crescer (R1 e R2) um sistema como este (Figura 2) do que um sistema verdadeiramente Erlang / OTP?A segurança de tal sistema (Figura 2) pode ser um problema, já que existem muitos pontos de entrada abertos para a web (APIs RESTful de todos os serviços) em vez de apenas um ponto de entrada (Figura 1), não é?Não há problema em ter vários 'módulos de orquestração' em tal sistema ou talvez exista alguma prática melhor? (Serviços "Aceitar pedidos", "CRM" e "Pedidos de despacho" na Figura 2);O Erlang / OTP puro (Figura 1) tem alguma vantagem sobre essa abordagem (Figura 2) em termos de passagem de mensagens e as limitações do protocolo? (em parte discutido no meu anterior semelhantequestão, gen_server: chame chamadas HTTP RESTful do VS)