프런트 엔드 사용자 인터페이스는 물론 자체 엔진을 갖춘 시스템을 구축하려고합니다. 나는이 두 가지를 가능한 한 분리시키고 싶다. 엔진은 명령과 데이터를 받아 들일 수 있어야하며,이 데이터를 처리하고 결과를 반환 할 수 있어야합니다. 엔진 작업이 길어질 수 있으며 클라이언트는 현재 상태에 대해 언제든지 엔진을 쿼리 할 수 있어야합니다.응용 프로그램 아키텍처에 대한 조언
디플로 프 프런트 엔드/백엔드 시스템은 새로운 영역이며 최고의 아키텍처를 확신하지 못합니다. 프론트 엔드를 웹 기반으로하고 싶습니다. 양식을 통해 엔진에 명령을 보내고 엔진 출력과 현재 상태를 모두 아약스 호출을 통해 표시합니다. 나는 Tomcat 내부에서 Spring 기반의 웹 애플리케이션을 사용할 가능성이 높다.
내 질문에는 엔진 구성 요소에 대한 최상의 구조가 포함됩니다. 다음은 내가 고려하고있는 가능성입니다.
웹 응용 프로그램에서 스레드와 데이터 구조로 엔진을 구현하십시오. 여기에있는 장점은 더 간단한 구현 일 것이고 웹 앱 프론트 엔드와 엔진 사이의 메시징은 단순 할 것입니다 (일부 공유 된 데이터 구조 이상은 아닙니다). 단점은 엔진을 관리하기 위해 서버 컨테이너에 의존하여 (예 : 웹 서버 또는 웹 응용 프로그램이 충돌 한 경우 엔진도 마찬가지) 앞면과 뒷면 사이의 밀접한 결합입니다.
백 엔드를 독립 실행 형 Java 응용 프로그램으로 구현하고 TCP 포트의 일부 서비스를 통해 해당 기능을 노출합니다. 웹 서버와 분리되어 있기 때문에이 방법이 마음에 듭니다. 그러나 필자는 필요한 저수준 네트워킹/통신 코드의 양에 대해 호소하지 않았습니다. 그 추상 소켓 등을 통과하는 메시지의 일부 높은 수준을 선호 할 것입니다.
웹 서버와 엔진을 모두 호스팅하는 스프링 DM 서버와 같은 OSGi 컨테이너를 사용하십시오. 네트워킹 코드가 존재하지 않기 때문에이 방법이 좋습니다. 엔진은 웹 응용 프로그램이 사용할 수 있도록 OSGI 컨테이너에 서비스를 제공합니다. 여기서의 단점은 새로운 기술의 학습 곡선과 오버 헤드 인 OSGi입니다. 또한, 앞과 뒤의 끝은 내가 정말로 원하지 않는 다시 결합 된 채로있다. 즉, 이전 서블릿 컨테이너에 프런트 엔드를 배치 할 수 없었기 때문에 엔진과 동일한 OSGi 컨테이너에 있어야했습니다.
이 나는 느낌 RMI 여기에 갈 수있는 방법이지만, 다시는 나를 위해 기술의 새로운 영역, 그리고 여전히 기본 시스템의 아키텍처를 설계하는 방법을 설명하지 않습니다 있습니다. JMS는 어떻습니까?
감사합니다.
+1 권장 REST – medopal