ESB

[Ricardo Morais]

Cleuton,

Tudo bem?
Aqui em meu órgão estamos deixando de ter um acoplamento por modelo de dados e buscando uma integração e dependência em serviços.
Estamos idealizando microserviços e construindo interfaces mínimas e pretendemos aderir a um barramento de serviços para que este nos ajude na escalabilidade, agregação de serviços maiores e controle transacionais.

Até o momento, os serviços que escrevemos foram REST e apenas GET, porém surgiu a demanda de construir dois serviços PUT e que estes sejam considerados uma unidade atômica. Como por padrão REST não guarda estado, pensamos até em ir pro SOAP nestes casos, ou usar Ejbs, o que amarraria a tecnologia.

Como você contornaria tal problema?
Basicamente um chamador faz uma série de coisas, e deve chamar esse serviço que é um agregado de serviços. Este agregado deve responder atomicamente e fazer parte da transação chamadora.

Em termos de barramento vocês estão usando o que? MuleSoft? Ele é gratuito, mas seus plugins são pagos, certo? Pegaram surpote ou consultoria no Brasil, no órgão que trabalhas?

[Ricardo Morais]

[Cleuton]

Se você quer criar uma arquitetura de microsserviços, REST é melhor do que SOAP.

Você não precisa manter o estado da conversaçào em seus microsserviços. Apenas o estado dos recursos. O estado da conversação pode ser mantido no Cliente ou então em um business façade.

Lá, eles usam o TIBCO, que, na minha opinião, foi uma escolha infeliz. Eu preferia o Mule.