저희 EVA 네 식구 (현종님, 지원군, 민정님, 희정양, 정민군)와 함께 Half-Push/Half-Polling 패턴에 대해서 또 한번의 저자 워크샾을 가졌습니다.  POSA2에 대한 이해도가 PLoP에 있는 분들보다는 높기 때문에, 좀더 수월하게 Writer’s Workshop이 진행될 수 있었던 것 같습니다.

재미난 것은 PLoP에서 받은 피드백과 유사한 내용도 많았고, 다양한 의견도 많이 나와 도움이 많이 되었습니다.

Introduction.

Half-Push/Half-Polling에 대한 명칭에 대한 설명 부분이 Introduction에 추가되었으면 좋겠다

Example

예제에 대한 배경을 잘 모르겠다. 그림에 대한 설명이 서술적으로 추가되었으면, 좋겠다. 이게 네트워크에서 업그레이드가 필요해서 한 것이다. 그림을 그릴 때 물리적인 요소들을 직접 그리는게좋을 것다. 예를 들면 아파트 안에 실제 디바이스들을 직접 보여주는게 좋지않을까?

Context

Context에 대한 내용이 많이 부족하다. 좀더 자세하게 설명해라. 데이터 처리 시스템이면 어떤 시스템인지 잘 모르겠다. 어떠한 정보를 전송해야 하는지 구체적으로 설명해라.

목적에 해당하는 내용들을 너무 간결하게 표현했다. 왜 이러한 업그레이드 방식이 필요한지 설명이 좀 나왔으면 좋겠다. -> 뒷 부분에 나왔는데 이걸 좀 앞 부분으로 끌어오겠다.

네트웍의 물리적 구성과 Throughput에 대한 애기들을 Context에서 명확히 설명해야 Problem을 설명하기 쉽지 않나?  ->  Target / 실제 구축된 사례로 좀도 좁혀서 설명하면 이해하기가 쉬워질 것이다.

Problem

Problem안에서 Force를 설명하는 게 좀 이상하다. -> Forces를 따로 떼자.

Problem에 있는 설명들을 그림을 넣어서 첨부해서 설명이 좀더 되었다면, 여기서 제시하는 시스템의 문제가 뭔지 좀더 명확해 지지 않았을까?

.. 클라이언트를 그룹별로 관리할 수 있다는 것이 장점인데 왜 요구사항에 반영하지 않았나?

Polling과 Push에 대한 용어들을 명확하게 설명할 필요가 있다.  서버 모델에 익숙하지 않은, 처음 보는 사람이 보기에 이해하기 힘들 수도 있다.

Solution

Structure

Pusher와 Poller의 메소드를 서버와 클라이어트를 구분지어서 설명하면 도움이 되었을것이다.

Dynamics

Poller가 죽었을 때, 어떻게 되었냐? IsPossibleUpgrade -> AreYouAlive로 바꾸어야 된다.

왜 Timespan을 다시 받는지 생각해보자.

Timespan의 값을 선정하는데, 시스템에 따라 어떻게 시간을 배분해야 하는가?에 대한 설명을 추가해라. Example/context에서 좀더 환경을 명확히 기술해라.

Implementation.

특성 파악 – 스케쥴링 알고리즘 선택 – 메세징 포멧 결정 – 주고받는 메시지의 확장성을 고려해라 – 그룹화 –

Pusher 에 특성에 대한 설명이 없다.

Step 2.

QoS를 파악하여 적합한 스케쥴링 알고리즘을 가진 논문이나 자료를 좀더 추가적으로 기술해라.

QoS중 시스템의 규모에 대한 애기가 있었으면 좋겠다. 서버/클라이언트의 수, 네트웍 규모등을 설명했으면 좋겠다.

Step 3.

상호 호환 포멧이나 이러한 부분의 예로 WCF와 같은 명확한 예를 들어 설명해야된다.

메시지 포멧이 결국 프로토콜에 종속적일 것인데 이부분도 좀 애기를 했으면 좋겠다.

Step 4.

Composite Message, Pipe-filter, 와 같은 관련 패턴 내용을 좀더 상세히 추가해줬으면 좋겠다.

주고 받는 메시지의 확장성을 고려하는 부분이 앞에 Force 부분에 없다.

이 부분을 앞에 추가하는 것이 좋을거 같다.

Step 5. 그룹 화

요구사항에 다양한 클라이언트를 그룹화하거나, Poller들이 다양한 것을 지원한다라는 부분이 명세되었으면 좋겠다.

이벤트 채널에 대한 설명이, 좀더 앞부분으로 왔으면 좋겠다. 앞부분에 디자인 부분에 포함이 되되 될 것 처럼 보인다. -> 여기에 확장된 다이어그램을 추가해야하나? (손영수)

실제 케이스를 보강해서 설명해라 -> 타입이 뭔지, 디바이스가 뭔지. 좀더 그림이나 좀더 자세하게 설명해라. 그냥 나오니 뭔지 모르겠다.

Step 6.

WatchDog, 타이머 가 어디에 있는냐  DB는 어디에 저장되느냐?

설명을 괜찮은데, DB에 데이터를 저장해야 된다고 나와있는데, DB 정보, 어떻게 저장해야 할지 좀더 자세하게 설명해야 한다.

Watchdog과 타이머가 DB에 저장된다. 이게 Dynamics와 매치가 잘 안된다.

Step 7.

파일이 뭐냐? 디바이스 정보가 파일로 관리되는 것인지 명확히 기술해라.

여러가지 상황이 존재하니, 상황에 맞는 전략에 맞춰서 사용해라.

여기나온 Step이 앞부분에 특성에 맞추어서 애기하는 것이 좋다.

Known Use & Variant

원래 이러한 패턴을 약간 변형시키면 언제 언제 써먹을수 잇는 패턴이 된다.

이것도 도식화 해서 설명하는 것이 좋다.

Example Resolved

Alive Check Manager 개입을 해서, 그림을 넣어주면 확실할거 같다.

Alive check manager를 중간에계속 체크함으로써, 비워져 있는 시간에 새로운 서버를 할당할 수 있어야 한다.

Consequense

단점을 극복할수 있는 대안이 있었으면 좋겠다.