SOAP이냐 REST이냐

객체지향기술을 넘어 소프트웨어 컴포넌트 기술 그리고 이제 서비스를 기반으로 한 기술로 이전하는 추세이다. 이 서비스를 기반으로 한 아키텍처가 SOA(Service Oriented Architecture)인데 여기에서 이야기하는 Service는 기존의 API 수준을 넘어 비즈니스 프로세스 수준에서 재 사용할 수 있는 단위 비즈니스 업무의 서비스를 이야기한다. 즉 기존 기술의 API 보다 좀 더 비즈니스에 가깝게 추상화된 고수준의 서비스이다.

SOA가 추구하고자 하는 것은 서비스의 구현기술에 상관없이 서비스들을 엮어 좀 더 가치있는 새로운 서비스를 쉽게 창출하는데 그 목적이 있다.

SOA 기반기술

SOA 기반의 시스템을 구축하는데 필요한 기술을 이야기하면 SOAP을 많이 이야기하는데 엄밀히 이야기하면 반드시 SOAP을 이용해서 서비스 기반 아키텍처를 만들어야 하는 것은 아니다.

SOA를 설계하고 구축하는데 사용할 기술이나 프로토콜은 SOAP 뿐만 아니라 다른 기술로 가능하며 SOA에서 이러한 기술을 제약하지 않는다. 기업이나 조직의 제반환경이나 아키텍트의 결정에 따라 SOA는 다양한 형태로 구현할 수 있다.

그럼 SOAP외에 어떤 기술을 사용할 수 있을까? 물론 메시징 기반의 기술등 여러 기술이 가능하겠지만 많이 회자되는 기술 중 REST를 빼놓을 수가 없다.

그럼 서비스를 구현하는 기술로 SOAP과 REST가 어떻게 다르고 어떤 장단점이 있을까?

SOAP

SOAP은 웹서비스를 만들기 위한 많은 표준들이 있다. (WSDL, WS-Security, WS-...)

바로 SOAP의 힘은 이러한 표준에서 나온다. 표준에는 매우 강력한 힘이 있다.

마치 국회에서 새로운 법을 지정하면 그 법에 의해 시스템이 돌아가는 것처럼 표준이 있고 그 표준을 지키면 그 서비스는 표준에서 이야기하는 것들이(상호운영, 보안, 라우팅,...) 시스템에서 돌아갈 거라는 확신을 가질 수 있다.

즉 내가 SOAP 표준을 지켜 서비스를 구현하면 기술에 대한 세세한 동작 메커니즘을 설명하지 않더라도 전혀 다른 플랫폼이나 언어로 그 서비스를 사용할 수 있을 것이다. (물론 현실적으로 이게 100% 맞는 이야기인지는 SOAP으로 프로젝트를 해 본 사람이라면 의문을 던질 것이지만...)

SOAP의 단점은 복잡성이다. SOAP 자체가 복잡성이 높다고 보기는 어려울 수도 있지만 SOAP 헤더, 바디, Fault등의 envelope 방법자체도 그렇고 보안, 트랜잭션 등 부수적인 문제해결을 위한 다양한 표준은 사실 이해하기 쉬운 부분도 아니다. (여기서 이야기하는 복잡도는 REST와 비교해서 하는 이야기이다)

한가지 또 단점은 REST에 비해 무겁다는 것이다. 이것은 통신기술에 의존하지 않는 표준이라는 특성에 기인한다.

장점

• 언어, 플랫폼 그리고 통신에 중립적
• 분산 컴퓨팅 환경을 다루기 위해 설계
• 웹서비스를 위해 보급된 많은 표준 (WSDL, WS-*)과 벤더에서 제공하는 도구들
• 에러 처리에 대한 내용이 기본으로 내장
• 확장성

단점

• 개념적으로 REST 보다 어렵고 무거움
• 시시콜콜한 것들이 많아 복잡함(verbose)
• 개발하기 어렵고, 보통 도구가 필요함

 

REST

원래 REST는 HTTP의 주요 저자인 Roy Fielding의 2000년 논문에 의해 소개된 네트워크 아키텍처를 위한 구조인데(참조 The Resource-Oriented Architecture) 여기서 이야기하는 REST는 HTTP의 기본 개념에 충실히 따르는 웹서비스를 이야기한다.

이러한 웹서비스를 RESTful 웹서비스라고 하며 단순한 HTTP 요청과 그 결과를 단순한 XML등의 포맷으로 돌려주는 구조이다.

예)

요청:

GET /StockPrice/IBM HTTP/1.1

Host: example.org

Accept: text/xml

Accept-Charset: utf-8

응답:

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: nnn

<?xml version="1.0"?>

<s:Quote xmlns:s="http://example.org/stock-service">

     <s:TickerSymbol>IBM</s:TickerSymbol>

     <s:StockPrice>45.25</s:StockPrice>

</s:Quote>

RESTful 웹서비스의 강점은 단순함과 간결함이다. 잘 구현된 RESTful 웹서비스는 간결하고 일관된 인터페이스 구조를 지니고 있어 어려움 없이 쉽게 사용이 가능하다.

반면 RESTful 서비스에 대한 표준은 없어 그 구현방법이 다양해질 수 있다. 또한 보안이나 에러처리등과 같은 부수적인 문제는 직접 해결해야 한다.

장점

• 언어, 플랫폼에 중립적
• SOAP보단 개발하기 단순함
• 학습곡선이 작고 도구가 거의 필요없음
• 간결함. 추가적인 메시징 계층이 없다.
• 웹에 가까운 설계와 철학

단점

• point-to-point 통신 모델을 가정함. 둘 이상을 대상으로 상호작용하는 분산환경에는 유용하지 않음
• 보안, 정책 등에 대한 표준이 없음. 이런 것까지 고려해서 구현할 경우 좀 더 어려움.
• HTTP 통신 모델에 의존

 

표준이냐 간결함이냐

표준의 힘은 위에 이미 언급을 하였다. 그러나 간결함의 힘도 무시할 수 없다.

단순함 간결함은 직관적이며 쉽게 개발하거나 사용할 수 있어 기술의 전파 속도가 굉장히 빠르다는 것이다.

단순함이나 간결함을 가진 기술은 굳이 따로 배우지 않더라도 바로 사용할 수 있는 힘이 있다.

따라서 아키텍처나 설계에 있어 단순함, 간결함을 매우 강조하는 이유가 여기에 있다.

SOAP은 통신에 중립적인 구조로 설계되어 있어 부수적인 메시징 정보를 또 포함하고 있다.

HTTP를 이용하여 SOAP을 이용할 경우 이미 HTTP에 포함된 메시징 정보(URL 또는 각종 헤더)에 또 메시징 정보를 포함한다.

이는 편지를 붙이기 위해 주소를 적은 편지봉투를 다시 조금 더 큰 편지봉투에 넣어 보내는 것과 같은 꼴이 된다.

SOAP이 HTTP를 이용하지 않고 다른 프로토콜로 구현한다면 복잡하고 장황한 스팩이 나름대로 의미가 있겠지만 HTTP를 이용한 SOAP 통신이 주를 이루고 있어 위와 같은 상황이 되는게 사실이다.

그러나 SOAP을 무시할 수 없는게 표준이라는 힘에 의해 많은 개발도구들이 SOAP을 지원하여 SOAP을 이용하면 특별한 노력없이 바로 연동이 가능한 점이 있다.

이렇게 표준의 힘을 사용할 것인가 아니면 간결함의 힘에 의지할 것인가에 대한 고민이 있고 이에 대한 논의는 계속되는 상황이다.

트랜드

물론 두 가지의 기술 중에 한 가지만 고집하고 사용할 필요는 없다. 여력이 되는데로 모두 배우고 상황에 맞춰 선택하여 사용해도 될 것이다. 그러나 앞으로 어떤 기술이 주를 이룰지 예측해보는 것은 가치가 있는 일이다.

여러 웹 사이트에서 자료를 수집해 보니 역시 단순한 기술의 전파력이 무섭다는 것을 알 수 있다.

아마존은 SOAP과 REST 서비스 모두 제공하는데 85% 정도가 REST 서비스를 사용하는 것으로 알려졌다. (2003년)

Google은 SOAP 기술에 대해 그리 좋게 보지 않고 있으며 더 이상 SOAP API에 대한 지원을 하지 않는다. (http://radar.oreilly.com/archives/2006/12/google-depreciates-SOAP-API.html)

야후는 현재까지 SOAP API를 제공할 계획이 없다. (http://developer.yahoo.com/faq/#soap)

 

이런 전쟁에서 항상 우수한 기술이나 표준 기술이 이겨온 것은 아니다.

필자는 1997년도 즈음 CORBA를 이용했는데 그 기술의 비전과 우수성만 보고 온 세상은 CORBA로 통합될 줄 알았다.

그러나 현실은 그렇지 않았다. 배우기 어렵고 성숙한 구현기술이 부족한 CORBA는 자취를 감추고 IIOP만 J2EE 스팩에 남아있을뿐이다.