Interaction Styles
(상호작용 형태)
서비스에 대한 IPC 메커니즘을 고르느느 경우, 서비스가 어떻게 상호작용 하는지를 먼저 생각보면 유용하다. Client와 서비스간 상호 작용 형태는 다양하다. 2가지 관점에 따라 카테고리지어질 수 있다. 첫번째 관점은 상호작용이 one-to-one 인지, one-to-many 인지에 대한 것이다.
- One-to-one : Client의 각 요청은 정확하게 하나의 서비스 인스턴스에 의해 처리된다.
- One-to-many : 각 요청은 여러 서비스 인스턴스에 의해 처리된다.
두번째 관점은 상호작용이 Syncronous(동기)인지 Asynchronous(비동기)인지에 대한 것이다.
- Synchronous : Client는 서비스로부터 시기적절한 응답을 기대하고, 기다리는 동안은 대기한다.
- Asynchronous : Client는 응답을 기다리는 동안 대기하지 않는다. 그리고 만약에 있다면 즉시 응답을 보낼 필요가 없다.
다음 표는 다양한 상호작용 형태를 보여준다.
| | One-to-One | One-to-Many |
| Synchronous | Request/Response | - |
| Asynchronous | Notification | Publish/Subscribe |
| Request/Async Response | Publish/Async Responses |
One-to-One 상호작용에는 다음과 같은 종류가 있다.
- Request/Response : Client는 서비스로 요청을 보내고, 응답을 기다린다. Client는 시기 적절하게 응답을 받을 수 있기를 기대한다. Thread기반 어플리케이션에서는 thread가 요청을 하고, 기다리는 동안 대기하고 있을 것이다.
- Notification (단방향 요청으로도 알려짐): Client는 비동기적으로 응답하는 서비스로 요청을 보낸다. Client는 기다리는 동안 대기하지 않는다. 그리고 얼마 동안은 응답이 도착하지 않는다고 가정하고 설계된다.
One-to-Many 상호작용에는 다음과 같은 종류가 있다.
- Publish/Subscribe : Client는 0개 이상의 관련된 서비스에서 소비되는 Notification message를 발행한다.
- Publish/Async Responses : Client는 요청 메시지르르 발행하고, 관련된 서비스로부터의 응답을 정해진 시간 동안 기다린다.
각 서비스는 일반적으로 이러한 상호작용 형태를 조합하여 사용한다. 어떤 서비스들에 대해서는 하나의 IPC 메커니즘으로도 충분하다. 다른 서비스들은 IPC 메커니즘의 조합을 사용하는 것이 필요하다. 다음 다이어그램은 택시 호출 어플리케이션에서 사용자들이 이동을 요청했을 때, 어떻게 서비스들이 상호작용 하는지를 보여준다.
서비스들은 Notification, request/response, publish/subscribe를 조합하여 사용한다. 예를 들면, 승객의 스마트폰은 pickup을 요청하기 위해 Trip Management Service에 Notification을 보낸다. Trip Management Service는 Passenger Service를 호출하기 위해서 request/response를 사용하여 승객의 계정이 활성화되어 있는지 검증한다. 그리고 나서 Trip Management Service는 택시호출을 생성하고, Dispatcher(차량 배치 담당 서비스)를 포함하여 가용가능한 운전사 위치를 다른 서비스들에게 알리기 위해 publish/subscribe를 사용한다.
지금까지 우리는 상호작용 형태에 대해서 살펴보았는데, 이제 어떻게 API를 정의하는지에 대해서 알아보자.
트랙백 주소 :: http://www.yongbi.net/trackback/759
트랙백 RSS :: http://www.yongbi.net/rss/trackback/759
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/760