2011-03-18 7 views
2

웹 응용 프로그램을 설계 할 때 많은 양의 데이터를 지속적으로 처리하고 웹 인터페이스를 사용하여 결과를 제시해야합니다.J2EE - 지속적으로 실행되는 구성 요소/데몬 구현

작동 방식은 다음과 같이 대략 간다 :

  1. 전자 센서 어레이는 항상 같은 빨리 가능한 한 및 DB로로드 (USB
  2. A "변기"애플리케이션 프로세스 데이터를 통해 램으로 데이터를 유출 스테이징 영역)은 트리거를 사용
  3. 다른 스키마 (데이터 영역 내의 데이터 저장 결과)의 DB 수행 계산
  4. 클라이언트 웹 애플리케이션 수요
  5. 에 등 그래프/보고서의 데이터 처리 표시 할 수
솔루션은 이상적으로 같을 것이다

:

  1. 데이터베이스 서버 - PostgreSQL의는
  2. 는 관리 웹 인터페이스, 즉 플러 셔를 모니터링 할 수 있습니다 되세요 (즉, 시간당 처리되는 레코드 또는 그와 유사한 것), 별도의 데몬으로 구현 된 경우이를 제어하십시오.
  3. 변기 및 클라이언트 응용 프로그램은 이상적으로 이제 저를 귀찮게 계속 문제를

J2EE을 사용하여 자바로 작성된 나는 답을 찾을 수 없습니다 :이 지속적으로 변기 구성 요소를 작성에 대한 이동하는 방법, 즉 프로세스 J2EE에서 백그라운드로 실행됩니다. 웹을 수색하여

는 기본적으로 세 가지 가능성 등장 :

가) 메시지 구동 빈으로 플러 셔 쓰기 JMS를 사용하여 마스터 응용 프로그램을 제어 할 수 있습니다. 그러나 : MDB가 계속 실행되는 것에 대한 생각이 맘에 들지 않습니다. 가능한 경우조차도 확실하지 않습니다.

b) 플러 셔를 EJB로 작성하고 Timer/Scheduling 서비스를 사용하여 제어하십시오. 그러나 이벤트는 실제로 타이밍이 맞지 않습니다. 단지 그렇게하지 말라고 할 때까지 무한 루프로 실행해야합니다. 기술의 잘못된 사용법처럼 보입니다.

c) 플러 셔를 별도의 Java 응용 프로그램으로 작성하고 OS 서비스 (Linux 또는 Windows)로 실행하고 EJB에서 호출 한 ProcessBuilder를 통해 시작 스크립트를 사용하여 제어합니다. 상태를 모니터하려면 JMS를 사용하십시오. 그러나 이것은 지나치게 복잡한 솔루션, 플랫폼 의존 및 어쩌면 신뢰할 수없는 것으로 보이며 EJB는 자체 스레드를 생성하거나 관리해서는 안되기 때문에 ProcessBuilder는 기본적으로 그렇게합니다. 단지 잘못되었습니다.

기본적으로 이들 중 어느 것도 나에게 맞는 것이 아니며 Java/J2EE 세계에서 우리가 옳은 해결책은 무엇인지 알 수 없습니다.

내가 독립형 자바 프로세스와 "변기"응용 프로그램을 작성합니다 당신 토마스

+0

MDB를 지속적으로 실행하는 것이 좋습니다. 실제로, 그것이 그들이 일하기로되어있는 방법입니다. MDB를 배포 한 다음 메시지가 도착하자마자 처리합니다. 즉, 나는 MDB가이 상황에서 옳다고 생각하지 않는다. 센서 데이터를 JMS 메시지에 랩핑 한 다음, 불필요한 복잡성을 추가하는 것처럼 보이는 큐에 놓는 또 다른 프로세스가 필요합니다. –

+1

답변 해 주셔서 감사합니다. 매우 도움이됩니다. MDB의 주제에 대해 자세히 설명하기 위해, 나는 그 뒤에있는 원칙을 가지고있다. 그러나이 경우에 그것을 분명히하자. 나는 끊임없이 실행하는 것이 의미하는 것은 bean에게 메시지를 보내면된다. 무한 루프에서 실행, 데이터 처리 및 플러시. 그리고 이것은 컨테이너가 빈을 적절히 관리 할 수 ​​없기 때문에 잘못되었다. (예를 들어), 메소드 실행은 예를 들어 웹 인터페이스에서 전송 된 중지 메시지 나 서버 종료시에만 종료되기 때문이다. –

+0

지금 네가하는 말을 알아. 나는 그것이 MDB 앱에 대한 끔찍한 디자인이 될 것이라고 동의한다. –

답변

2

감사드립니다. 아마도 Java Service Wrapper과 같은 것을 사용하여 OS 용 서비스로 전환하십시오. Java를 통해 RAM 디스크와 인터페이싱하는 옵션에 익숙하지 않지만, 프로세스 수명 동안 계속 열어 놓고 계속 읽을 수있는 InputStream으로 끝나거나 while 루프에서 지속적으로 폴링 할 것입니다.

private volotile boolean stopFlag; 

... 

while(!stopFlag) { 
    processNextInput(); 
} 

그런 다음 당신은 당신이 프로세스를 종료하고 싶어 할 때 true로 stopFlag을 설정할 수 있습니다 다른 스레드에서 다른 메커니즘을 것이다 : 그것은 다음과 같은 일을 할 수 있도록 완벽하게 괜찮아요.

플러 셔를 모니터링하는 데있어 JMX는 좋은 해결책 인 것 같습니다. 그것이 정확히 의도 한 바입니다. 원하는 모든 종류의 상태 또는 통계를 노출하는 MBean을 작성한 다음 다른 프로세스가 해당 MBean에 연결하여 해당 데이터를 쿼리 할 수 ​​있습니다.

"클라이언트"응용 프로그램은 데이터베이스에 대한보고를 수행하고 플러시 프로그램에서 MBean의 프론트 엔드를 제공하는 간단한 서블릿 응용 프로그램입니다. 또는 JMX 콘솔을 사용하여 플러 셔를 모니터링하고 클라이언트와 관련되지 않은 시스템을 모니터링 할 수도 있습니다.

EJB가 실제로이 시스템에 적합하지 않다고 생각합니다. 나는 EJB에 대해 다소 편견을 가지고 있으므로, 소금 한 알을 가지고 조언을 구한다. 그러나 나에게 나는이 애플리케이션에서 정말로 필요하지 않다.

+0

음, flusher/JMX 솔루션은 훌륭하게 보입니다 (스스로 실현해야 함). 클라이언트/모니터링 webapp에서 flusher 데몬을 중지하기 만하면됩니다 (구성 요소가 실행되는 경우). J2EE 컨테이너 환경에서), 맞습니까? –

+0

나는 아파치 데몬 코드를 사용하여 매우 비슷한 것을 구현했다 : http://commons.apache.org/daemon/jsvc.html. JMX 모니터링은 매우 간단하며 Zenoss를 사용하여 성능 통계를 그래프로 나타낼 수 있습니다. –

+0

@Adrian : 그만한 가치있는 제안입니다. 고마워요. –

관련 문제