 |
|
난이도 : 초급 James M. Snell, Software Engineer, IBM
2004 년 10 월 12 일 최근 출시된 Bloglines API로 REST(Representational State Transfer)대 SOAP(Simple Object Access Protocol) 웹 서비스간 논쟁 라운드가 뜨거워졌다. 이들 서비스 지향 아키텍쳐(SOA) 디자인 패턴은 상호 배타적인 것이 아니다. 하나가 다른 것보다 일반적으로 우월한 것도 아니다. 각각은 다양한 애플리케이션 시나리오에 따라 강점과 약점을 갖고 있다. 실제 고객들이 직면한 실제 문제를 해결하는 유효한 접근 방식들도 갖고 있다. 트릭은 어떤 접근방식을 사용할 것인지를 결정할 때 나온다. 해답은 생각보다 쉽다.
다루는 웹 애플리케이션 서비스 공급자들이 개발자들이 그들의 서비스들을 통합할 수 있도록 하는 웹 서비스 API를 고려할 때 이 API에 의해 구현되는 인터랙션 디자인 패턴에 많은 신경을 쓴다. API가 REST 스타일의 인터랙션을 사용하면 REST 접근 방식 지지자들은 REST 스타일의 서비스가 SOAP 스타일의 서비스 보다 훨씬 앞서는 이유에 대한 예로서 API를 큰 소리로 주장한다. 마찬가지로 SOAP 스타일의 웹 서비스 패턴을 사용하는 API의 경우도 이와 다르지 않다. 패턴의 선택이 구현되고 있는 애플리케이션의 유형에 크게 의존한다는 사실에도 관심이 모아지고 있는 것 같다. 개발자들은 특정한 기술적 필요와 개발되고 있는 애플리케이션의 성격에 기반하여 선택을 해야 한다. 한 아키텍쳐의 접근 방식에 대한 특별한 호감으로 선택해서는 안된다.
Resource vs. activity
기본적인 수준에서 REST 스타일과 SOAP 스타일 웹 서비스의 차이는 애플리케이션이 리소스 지향(resource-oriented)인지 또는 액티비티 지향(activity-oriented)인지에 따라 달라진다.
리소스 지향 서비스는 기본적인 표준 작동이 수행될 수 있는 뚜렷한 데이터 객체들에 초점을 맞춘다. 객체 지향 디자인 패턴의 개념에 익숙한 개발자의 경우 리소스 지향 서비스들은 기본 Memento 패턴과 비슷하다. (Gang of Four (GoF) Design Patterns) 서비스 공급자들은 리소스들의 컬렉션을 관리하고 기본 연산의 컬렉션을 노출하여 다음과 같은 태스크를 수행한다:
- 리소스 검색
- 리소스 변경
- 새로운 리소스 생성
- 리소스 삭제
정의에 따라 REST 스타일의 웹 서비스는 리소스 지향의 서비스이다. Universal Resource Identifier (URI)에 의해 리소스를 구분하고 배치할 수 있고 이러한 리소스들에 대해 수행되는 연산들은 HTTP 스팩에 의해 정의된다. 핵심 연산에는 다음이 포함된다:
- GET - 이 연산은 구분된 리소스의 상태 구현을 리턴한다. 누가 요청을 제출하는지, (HTTP 헤더 또는 쿼리 스트링 매개변수로서 전달된) 연산의 매개변수, 서비스 공급자가 관리하고 있는 현재 세션 상태 같은 많은 정황 요소들에 의해 상태를 결정할 수 있다.
- POST - 이 연산은 구분된 리소스에 대해 애플리케이션 스팩의 업데이트를 수행한다. 이 연산의 작동은 이를 구현하는 서비스에 달려있다. 이 연산에 의해 리턴된 데이터는 완전히 이 애플리케이션에 의존한다. 예를 들어 GET 연산 처럼 상태 구현을 리턴하거나 또는 표준의 필요한 HTTP 응답 외에 어떤 데이터도 리턴하지 않을 수 있다.
- PUT - 이 연산은 지정된 장소(URI)에서 새로운 리소스를 만든다. 이 연산 인풋에는 리소스의 상태 구현이 포함되어야 한다. 상태 구현에 의존하는 리소스를 만들기 위해 서비스에 의존한다.
- DELETE - DELETE 연산은 지정된 장소(URI)에서 리소스를 삭제한다.
다양한 방식으로 리소스 스타일의 웹 서비스는 SQL, tuple spaces, simple message queues 같은 기술을 선호한다. 이 모두가 일반적인 간단한 연산을 사용하여 특정 리소스들에 대해 작동한다.
- SQL - SELECT, INSERT, DELETE, UPDATE 등
- Tuple spaces - GET, PUT
- Message queues - SEND, RECEIVE
각 경우, 서비스 인터페이스의 디자인은 리소스에 대한 정보를 주변으로 옮기면서 요청자에게 남겨 어떤 것이 정말 원하는 정보인지 파악할 수 있도록 한다.
동전의 다른 한면은 액티비티 지향의 서비스이다. 이 유형의 애플리케이션들은 리소스 보다는 여러분이 수행하는 액션에 초점을 맞춘다. 액티비티 서비스에 대한 예로는 고객이 한 계정에서 다른 계정으로 돈을 옮기는 은행 트랜잭션이 있겠다. 고객은 리소스(돈, 은행 계정 등)와 직접 작업하기를 원치 않는다. 그들은 단지 은행과 통신하여 은행이 리소스들을 핸들하기를 원한다. GoF의 관점에서는 다음의 애플리케이션들이다:
리소스 유형에 상관없이 수행되는 연산들이 비교적 일정하게 유지되는 리소스 지향의 서비스와는 달리 액티비티 지향의 서비스에서의 연산은 수행되는 액티비티의 유형에 전적으로 의존한다. 예를 들어 은행 서비스는 transferFunds라고 하는 연산을 노출하는데 이것의 다양한 인풋은 서비스의 자금 이동 기능에 대한 것이다.
리소스 지향의 서비스에서 일반적인 연산들은 지원 역할을 하면서 클라이언트가 리소스에 액세스하여 이 리소스들을 조작할 수 있도록 한다. 하지만 리소스는 관심의 중심에 있다. (그림 1)
그림 1. 리소스 지향 서비스와 액티비티 지향 서비스 비교
액티비티 지향 서비스에서 연산은 관심의 중심에 있다. 클라이언트가 요청하는 각 액티비티를 위한 연산이 수행된다.
SOAP 스타일의 웹 서비스는 일반적으로 액티비티 지향이다. WSDL 문서는 서비스 스팩의 연산을 정의 및 설명하고 있다. 연산은 서비스 스팩의 메시지들의 교환으로 구성된다. 각 연산은 수행될 액티비티이다. 그러한 연산이 수행되는 대상은 일반적으로 무관하다. 리소스들은 액티비티에 함축되어 있다. WS-Resource Framework 스팩들이 이를 설명하고 있다. 하지만 그와 같은 내포는 액티비티의 정의에만 직접 관련이 있는 것이고 액티비티가 수행되는 해당 정황만을 다루는데 작용한다. 리소스에 대해 액티비티가 작동한다는 측면에서 리소스 지향 서비스와 이를 대비하는 것은 리소스에 액세스하기 위해 사용되는 서비스 인터페이스에만 적용된다.
Bloglines 서비스
Bloglines는 웹 기반 애플리케이션 서비스로서 웹로그에 대한 다양한 섭스크립션과, Really Simple Syndication (RSS)과 Atom feed의 형태로 전달되는 새로운 피드(feed) 콘텐트를 트래킹할 수 있도록 한다.
Bloglines 서비스는 근본적으로 리소스 지향이다. 사용자들은 섭스크립션을 생성, 업데이트 삭제하고 정기적으로 서비스에 접근하여 사이트에 어떤 것이 업데이트 되었는지를 확인한다. Bloglines API는 REST 스타일의 웹 서비스 인터페이스를 사용함으로서 이러한 리소스 지향성을 적절히 반영한다.
특히 사용자의 섭스크립션 컬렉션들은 Bloglines 서비스로 집중되어 있다. 일반적으로 blogroll로서 알려져 있다. 하나의 blogroll은 다양한 많은 섭스크립션들로 구성되어 있다. 섭스크립션은 RSS 또는 Atom 피드를 지목한다.
blogroll과 섭스크립션은 모두 리소스들이다. Bloglines API는 기본 HTTP 연산을 사용하여 사용자의 blogroll과 섭스크립션 리소스에 대한 현재 상태 정보를 검색한다.
예를 들어, 사용자의 blogroll의 현재 스냅샷에 접근하려면 사용자는 HTTP GET 요청을 URI //rpc.bloglines.com/listsubs로 보낸다. 엄격히 REST 관점에서 보면 이 API는 모든 Bloglines 사용자들의 섭스크립션을 구분한다. 연산을 호출할 때, HTTP 인증 요청은 사용자의 섭스크립션이 어떤 것을 검색하는지에 대한 추가 콘텍스트를 모은다. 연산에 의해 리턴된 정보는 인증을 받은 사용자들의 개별 섭스크립션을 모두 나열한 XML 문서로 구성된다.
특정 섭스크립션의 현재 스냅샷에 액세스하기 위해 사용자는 HTTP GET 요청을 URI http://rpc.bloglines.com/getitems?s={subid}로 보낸다. {subid}는 위에 설명한 listsubs 연산의 결과로 디스플레이될 때 고유의 섭스크립션 식별자로 할당된 Bloglines이다. GET 연산은 idempotent 해야 한다는 기본적은 REST 규칙을 실제로 위반한 한 가지를 포함하여 추가 매개변수가 정의된다. 매개변수 (n=1)는 Bloglines 서비스가 이전에 읽히지 않은 섭스크립션 엔트리를 읽혀진 것으로 표시할 것을 명령하면서 그 리소스의 상태를 효과적으로 바꾼다.
사용자 blogroll에 현재 읽히지 않은 섭스크립션 아이템들이 얼마나 많은지를 리턴하려면 사용자는 HTTP GET 요청을 http://rpc.bloglines.com/update?user={email}&ver=1로 보낸다. {email}은 해당 계정의 이메일 주소가 읽히지 않은 섭스크립션 엔트리를 위해 검사된다.
Bloglines API가 우려하는 단 한가지는 blogroll과 섭스크립션 리소스에 프로그램 방식의 접근을 허용하는 것이다. API는 어떤 클라이언트가 blogroll 또는 섭스크립션과 작동하는지 상관하지 않는다.
이것과 최근에 proof-of-concept 프로젝트를 비교하기 위해 IBM은 웹 서비스를 사용하여 병원 환자의 기록 접근, 처방전 쓰기, 수술 스케줄링등을 자동화하는 것을 구현했다. 자세한 것 까지는 깊이 들어가지 않고 이 시스템에서 사용자가 수행할 수 있었던 액티비티에 정확히 초점을 맞추겠다. 예를 들어 환자를 위해 절차 또는 테스트를 스케줄링하고 테스트 결과 같은 이벤트의 비동기식 공지를 요청하기 이다. 환자 기록들이(리소스들) 이 시스템의 중요한 측면인 반면 이것들은 일반적으로 전체 애플리케이션에서는 지원하는 역할을 수행할 뿐 시스템의 주요 초점은 아니다. 오히려 병원 프로토타입은 액티비티 지향 서비스이다. SOAP 스타일의 웹 서비스 아키텍쳐로 정확히 반영된다.
이 모든 것의 포인트는 간단하다: REST 이냐 SOAP 이냐를 선택하는 것은 특정 애플리케이션에서 가장 중요한 것이 무엇인가에 대한 기본적인 이해에 달려있다. 애플리케이션이 정보 리소스에 접근하는 기능에 주요 초점을 맞춘다면(Bloglines 서비스 처럼), 기본적으로 리소스 지향 서비스를 갖추고 애플리케이션을 REST 스타일 디자인 패턴으로 전향해야 한다. Amazon, del.icio.us, Flickr, Safari에서 제공되는 서비스 API를 고려할 때 중요한 절차가 있다. (참고자료) 하지만 애플리케이션이 그 작동 기반이 되는 리소스들에 대해 직접 액션을 수행하는 것이라면 그 서비스는 액티비티 지향이 되어야 하고 SOAP 스타일의 디자인 패턴을 사용해야 할 것이다.
기능 vs 형식
REST 기반 패턴의 지지지들은 SOAP 관련 웹 서비스 스팩이 천성적으로 갖고 있는 복잡함에 비교되는 REST 기반의 아키텍쳐 단순성을 주장한다. 이것이 REST가 더 나은 접근 방식이라고 주장하는 이유이다. 두 가지 접근 방식이 다른 유형의 문제들을 해결하기 때문에 이러한 논쟁은 잘못된 것이다. Bloglines, Amazon, flikr, del.icio.us 같은 웹 기반 애플리케이션 서비스들은 다른 종류의 문제들에 직면해있다. 병원이 오더 프로세스를 위한 내부 절차와 처방전 작성을 자동화하는 방법을 찾기 위해 다른 아키텍쳐 접근 방식을 찾는 것처럼 말이다. 이것이 바로 디자인 패턴이 존재하는 이유이다. 다양한 문제를 풀기 위해서는 다양한 접근 방식이 필요하다.
특정 비즈니스 요구사항의 정황의 밖에서 비교해보면 REST 아키텍쳐는 WS-* 스팩으로 정의된 SOAP 웹 서비스 아키텍쳐 보다 훨씬 덜 복잡하다. 하지만 특정 핵심 분야에서는 훨씬 덜 기능적이기도 하다. Reliable 메시징이 대표적인 예이다. HTTP는 믿을 수 있는 프로토콜이 아니다. HTTP 요청이 딱 한번 또는 성공될 때까지 재시도 문법을 사용하여 믿을 수 있게 전달되도록 하는 빌트인 메커니즘이 없다. REST/HTTP에는 기본 HTTP 프록시 밖에서 메시지 라우팅을 위한 메커니즘이 없다. REST 스타일의 서비스에서 보안이란 것은, 애플리케이션이 외부에서 정의된 보안 메커니즘을 채택하지 않는 한, HTTP 프로토콜에 의해 제공되는 보안 메커니즘으로 제한된다. (예를 들어, REST 서비스는 디지털로 서명되거나 암호화된 SOAP 메시지를 HTTP GET 요청에 대한 응답으로 리턴할 수 있다.)
Bloglines 같은 서비스의 경우 이러한 기능적 제한은 중요하지 않다. HTTP에서 제공하는 기본 옵션들로 충분히 애플리케이션의 필요를 맞출 수 있기 때문이다. API는 다음을 필요로 하지 않는다:
- Reliable 메시징
- 디지털 서명
- 메시지 라우팅
- 리소스 수명 주기 관리
- 비동기식 이벤트 공지
- SOAP WS-* 스팩에 도입된 기타 기능들
이는 다른 애플리케이션들이 액티비티 기반의 접근방식으로 제공되는 기능을 필요로 하지 않는다는 것을 의미하지는 않는다.
오해하지 말라! 적어도 이론상으로는 REST 스타일 서비스에서 이 모든 일들을 수행하는 것은 전적으로 가능하다. 어떤 누구도 일관성 있고 표준화된 방식을 정의하는 작업을 하지 않았다는 것이 문제인 것이다. 그러기 전 까지는 REST 스타일의 인터페이스에서 누군가가 취하는 어떤 접근방식도 다른 REST 스타일 서비스에서는 지원되지 않는 일회성 서비스 구현이 될 것이다. 하지만 더욱 중요한 것은 이러한 확장된 기능들은 리소스 지향 서비스 보다는 액티비티 지향의 서비스에 보다 더 적용가능성이 높다는 것이다. 따라서 액티비티 지향의 SOAP 스타일 서비스가 엄청난 수의 스팩과 복잡함이 늘어난다고 해서 놀랄 필요는 없다.
Quick note: 적절히 다뤄지기만 한다면 복잡함은 그리 나쁜 것이 아니다. 사실, 많은 WS-* 스팩들은 광범위한 기술적 문제들을 다루고 있다. 전체적으로 보자면 이들은 상당한 수준의 복잡함을 드러내는 것이다. 하지만 그들이 정의되는 방식은 애플리케이션을 실행하는데 필요한 개념을 포함하고 있다. 어떤 누구도 모든 웹 서비스가 모든 WS-* 스팩을 구현하기를 기대하지 않는다.
결론
산업계가 지속적으로 서비스 지향 아키텍쳐(SOA) 방향으로 움직이고 있다는 것은 매우 중요하다. REST 스타일 또는 SOAP 스타일을 선택하는 것은 애플리케이션 컴포넌트를 위해 Command, Mediator, Observer, Strategy, Visitor 디자인 패턴 중에서 선택하는 것과 같은 문제로 취급되어야 한다. 이는 단지 비즈니스 필요와 애플리케이션 필요에 근거한 디자인 전략상의 선택일 뿐이다. 하지만 애플리케이션이 시간이 흐르면서 사용되고 진화하는 방법에 근본적인 영향을 줄 수 있는 선택이기도 하다. 그 무엇보다도 중요한 것은 웹 서비스 디자인 패턴의 선택은 웹 서비스를 공급하기 위한 것이라는 것이다.
참고자료
필자소개 | 
| | James Snell은 IBM Emerging Technologies Toolkit의 회원이고 웹 서비스 기술과 표준을 연구하고 있다. |
기사에 대한 평가
| 
