일단 프로젝트 정의 부터

1. 다수의 마쉰이 하나의 중앙서버 와 IPC프로토콜을 주고 받으면서 상태를 보고
2. 중앙서버에는 IIS나 그에 준하는 웹서버 설치 후 SOAP 통신을 이용하여 마쉰들의 상태에 대해 외부에 인터페이스를 규정함
3. 클라이언트에서는 중앙서버와 HTTP/SOAP통신을 이용해서 정보를 주고 받음

내가 나름 이해하기는 이렇고, 이런 구조 상황이라면 가장 곤란한게 HTTP는 기본적으로 Request-Response이후에

연결이 끊기기 때문에 비동기 통신 처리가 매우 꽁기 하다는 점인데~

데이터베이스를 경유해서 처리하면 어떻겠음?

시나리오 1.
1) 클라이언트에서 중앙서버로 서버 상태에 대한 쿼리를 요청 하고 2)의 작업후 work번호를 받아서 가지고 있음
2) 중앙서버에서는 그 시그날을 받으면 디비서버에 각 서버들의 상태를 받아서 기록하라는 Work를 세팅
3) 중앙서버에 있는 다른 어플리케이션 프로그램에서는 디비서버를 계속 주시하다가 work가 생기면
   각 머쉰들과 통신하여 상태들을 기록하여 디비에 넣고, 아까 work에 대해 complete세팅함
4) 클라이언트는 1)의 요청을 하고 일정시간 ( 대략 처리 예상 시간은 있을 테니 ) 후에 결과를 보고받기
   위한 SOAP을 호출
5) 중앙서버는 work 에 대해 complete가 떨어졌는지 확인하고 complete면 결과에 대해 반환, complete가
   아니면 working이라는 응답을 클라이언트에 줌
6) 클라이언트는 결과가 오면 우왕ㅋ굳ㅋ 아니면 일정시간 후에 다시 요청

만약 이게 시간 지연이 많이 발생해서 문제가 된다면
시나리오2
1) 중앙서버에 있는 어플리케이션에서 정기적으로 각 머쉰들과 통신하여 서버 상태를 디비에 기록
2) 클라이언트는 중앙서버에 SOAP으로 보고서를 요청
3) 중앙서버는 가장 최근의 결과를 반영

시나리오 2번이 신속한 응답을 받을 수 있고 구조가 심플한 반면, 최장 1)의 시간 상태이후의 것이라 실제로는 죽었는데
보고가 안된 걸 수도 있다는 거, 또한 1)의 과정에서 정기적인 네트워크 및 서버 자원을 소모한다는 단점이 있음