Notifications - Push, Pull, Stream Notification #1
| Exchange 2013을 기반으로 개발을 진행하면서 맞닥뜨리게 된 케이스에 대해서 공유 하고자 한다. 이전에 잠깐 EWS(Exchange Web Service)를 통해 간단한 기능을 사용해본 경험이 전부라서 하나의 기능을 구현하기 위해 여러가지 방안에 대해서 바위에 계란치기로 직접 부딪혀 볼 수 밖에 없었다. 이런 힘들고 시간 싸움을 줄이는데 도움을 드리는데 일조 하고자 이곳에 공유 하고자 합니다. 비록 덜 정제 되고 문서 미비할 수 있지만 참고 사항으로 알아 두셨으면 합니다. |
Exchange에는 메일(Item, 아이템 - 메일, 캘린더, 일정, 명함, ... - 이곳에서는 메일에 대해서만 언급 하도록 하겠다.)의 상태( 아래 "리스트1" 참고 )에 대해서 알아 낼 수 있는 방법이 Exchange에서 제공하는 EWS를 통해서 Notification이벤트로 알아 낼 수 있다.
public enum EventType { Status = 0, NewMail = 1, Deleted = 2, Modified = 3, Moved = 4, Copied = 5, Created = 6, FreeBusyChanged = 7, }
[리스트1] Notification 이벤트 타입
EWS를 통해서 Notification을 알아 내는 방법은 아래와 같다.
- Pull Notification
- Push Notification
- Stream Notification ( 2010 SP1 ↑ 지원 )
각 사용법에 대한 장단점은 아래 "표1", "표2", "표3"을 참고 하기 바란다.
Push Notification vs Pull Notification vs Stream Notification
Push Notifications
|
Pros |
Cons |
|
Nearly instantaneous notifications |
Have to write a listener |
|
No wasted traffic 적은 트래픽 |
Listener must be addressable by the Exchange server 리스너를 받기 위해서 IP기반 주소가 필요 |
|
Does not require CAS affinity CAS를 이용하지 않는다 |
|
[표1] Push Notification
Pull Notifications
|
Pros |
Cons |
|
Same simple request/response protocol as all other EWS web methods EWS 웹 메소드와 같이 간단하게 사용 | Receive notifications as frequently as client polls 클라이언트 Polling을 통해 자주 요청해야 한다. |
|
Client does not need to be addressable (can be behind a proxy or firewall) IP기반 주소가 필요 없다. |
Wasted traffic Polling 때문에 낭비되는 트래픽이 발생 |
|
Authentication is handles in the same way as for all other EWS web methods 다른 EWS 메소드와 같은 방식으로 인증 |
Fine tuning required to get optimal polling interval 최선의 Polling 주기를 조율해야 한다. |
[표2] Pull Notification
Stream Notifications
(아직 공식적인 문서는 없으며 Pull, Push를 기반으로 작성 되었다.)
|
Pros |
Cons |
|
Same simple request/response protocol as all other EWS web methods EWS 웹 메소드와 같이 간단하게 사용 |
Watermask를 사용해서 지난 메세지를 받을 수 없다. (SyncFolderItems 으로 가능한지 테스트 중) |
|
Client does not need to be addressable (can be behind a proxy or firewall) IP기반 주소가 필요 없다. |
즉시적인 Notifications을 받을 수 없다. 그렇지만 연결된 상태에서는 특정 주기(기본 5초)마다 이벤트를 구독할 수 있다. - 이벤트 방식으로 동작 |
|
Authentication is handles in the same way as for all other EWS web methods 다른 EWS 메소드와 같은 방식으로 인증 |
|
[표3] Stream Notification
다음은 전체적이 흐름을 이해하기 쉽도록 간단하게 도식을 살펴 보도록 하자.
[그림1] Push notification
Push notification은 Register에서 CAS에 Push사용자를 등록하고 MBX에서는 Listener에게 발생된 이벤트를 즉시적으로 넘겨 준다. 다른 notification 방식보다 복잡하며 MBX에서 접근 할 수 있는 Listener 서버가 필요 하다. 그렇지만 세가지 방식중에서 가장 실시간 이벤트 정보를 받아 볼 수 있으므로 실시간 연동이 필요한 부분에서는 고려해 볼 만하다. 그렇지만 MBX에서 데이터를 XML 형식으로 넘겨 주기 때문에 Listener에서 XML을 파싱하는 작업이 수반되어야 한다.
[그림2] Pull notification
Pull notification은 CAS에 각 사용자를 Pulling하고 받은 정보를 받아와 처리한다. 다음 이벤트를 받기 위해서는 다시 같은 프로세스를 다시 실행해야 한다. Pull은 Receiver에서 주도적으로 CAS에 질의를 해야 하며 필요 없는 트래픽이 많이 발생 할 수 있거나 Pulling 주기에 따라 시간 차이가 발생 할 수 있다. 실 시간적인 처리가 필요한 시스템 연동에서는 데이터 불일치가 발생할 수 있다.
[그림3] Stream notification
Stream notification은 Pull과 Push의 장점을 합쳐서 만든 방식이다. 1번 처럼 한번 등록이 되면 DisConnection이 되기 전까지는 주기적(기본적으로는 5초 단위)으로 CAS에서 Receiver에게 이벤트를 보내 준다. 그리고 EWS와 같은 방식으로 메소드를 사용할 수 있으며 별도의 파싱 작업을 해야 할 필요는 없다. 그렇지만 현 시점에서는 Watermask를 통해 지난 이벤트를 가지고 올 수 있는 방안을 제공하지 않고 있다. ( SyncFolderItems 으로 지난 Notification을 가져올 수 있는지 테스트 중에 있다. 관련 자료 - Stream Notification )
지금까지 Notification을 구독하는 컨셉에 대해서 알아 보았다면 다음 포스트에서는 실 서버 환경에서 구축하는 방안에 대해서 알아 보도록 하겠다.
Exchange flow diagram V1.pptx위 다이어그램 관련 작업하며 추가하고 있는 자료입니다. 시간이 지나면서 점점더 추가 하도록 하겠습니다.