우리는 현재 많은 SOAP 호출을 수락하고 SOAP 호출을해야하는 응용 프로그램의 응용 프로그램 아키텍처를 결정하려고합니다. 설계 목표 중 하나는 우리가 고려해야 할 단순성과 견고성입니다.ESB/MessageBroker 또는 Grails로 SOAP 호출을 처리 하시겠습니까?
Grails 공간에서 우리는 이것을 하나의 큰 Grails 애플리케이션으로 묶을 수 있습니다. 그러나 Grails 애플리케이션의 견고성 측면에서 골칫거리입니다. Grails 애플리케이션의 업데이트는 들어오는 모든 SOAP 요청을 비활성화합니다.
Grails 앱을 나눠서 ActiveMQ/ServiceMix/Mule 등과 같은 것을 사용하면 좋을까요? 어떤 조언이나 의견을 부탁드립니다! 그리고 어떤 종류의 해결책이 좋은 후보가 될까요?
네트워크로드 밸런서 뒤에서 실행하면 모 놀리 식 Grails 애플리케이션에서 견고성을 얻을 수 있습니다. 이렇게하면 다운 타임없이 롤링 업그레이드를 수행 할 수 있습니다.
이제는 도달 할 수없는 원격 SOAP 서비스 등을 처리해야 할 필요성과 같은 다른 문제를 해결하지 않습니다 ... 이것은 Mule과 같은 도구/프레임 워크가 예외 처리, 재시도 및 기타 등등.
SOAP 브릿지의 의도 된 동작에 따라 조건이 달라집니다. 비동기식입니까 (예 : 화재 및 잊어 버리거나, 브릿지에 메시지를 보내고, 즉각적인 ACK를 받고 가능할 때마다 원격 파견을 수행하도록 함) 그것은 동기식입니다 (즉, 브리지의 발신자는 원격 응답이 수신되어 다시 전달 될 때까지 유지됩니다).
브릿지가 기본적으로 동기식이라면, 하나의 Grails 앱을 고수하고로드 밸런서를 사용할 수 있습니다. 재 시도를 처리하는 것은 발신자에게 달려 있습니다.
그렇지 않은 경우 비동기 인 경우 일시적인 메시지 지속성 및 오류 발생시 재전송을 돕는 메시징 미들웨어를 고려하십시오.