"WOA는 웹을 이루는 검증된 기술인 HTTP 프로토콜을 그대로 사용하고, SOAP 보다 간단한 REST 아키텍처 스타일을 사용하여 URI 형태로 참조되면서 웹 서비스를 구현할 수 있다." 마이크로소프트의 Virtual Earth를 이용하여 부동산 중개업소가 활용하는 경우 아주 획기적인 서비스를 제공할 수 있습니다.
아래 그림에서 보듯, 해당 지도에 나타나는 매물을 보실 수 있죠. 집 모양의 아이콘을 클릭하면 상세 가격, 정보가 나타납니다. 이런 형태로 중개업소 사이트를 구축하는 것이 어려울까요? 어렵지 않습니다. Virtual Earth API가 제공되기 때문에 그대로 가져다가 쓰면 된다는 거죠. 이것이 WOA의 장점 입니다.
위와 같이 WOA를 활용하면 누구나 거대한 서비스 공급망의 일원이 될 수 있습니다.
SOAP vs REST 비교 자료를 올려 보겠습니다.
SOAP(Simple Object Access Protocol) vs REST(Representational State Transfer)
새로 웹서비스를 시작하려는 개발자는 많은 기술 및 개념에 압도되곤 합니다. SOAP, REST, WSDL, XML Schema, UDDI, WS-I, WS-Security, WS-* 등 정말 많고 계속 생겨나고 있죠. 그 중 웹서비스 개발에서 가장 대표적인 SOAP과 REST 중에서 한가지를 선택하게 됩니다.
SOAP
SOAP은 1998년 CORBA나 DCOM 같은 미들웨어 기술에 대한 대안으로 마이크로소프트에 의해 언어 및 플랫폼 중립적으로 선보였습니다. 이후 수정을 거쳐 1999년 12월 SOAP 1.0, 2000년 5월에 1.1 버전이 W3C에 제출되었고 웹서비스의 핵심으로 부각되었습니다. 현재는 1.2버전이 사용되고 있습니다. SOAP과 함께 WSDL, XML Schema는 XML 기반의 메시지를 교환하는 표준이며 디자인 개념에 확장이 가능하도록 설계되어 다른 표준이 통합되기 쉽습니다. 현재도 계속 추가되고 있고, WS-*로 표현할 수 있습니다. 쉽게 말하면 점점 복잡해지고 있는 거죠. 하지만 필요한 것만 선택해서 사용할 수 있기에 걱정할 필요는 없습니다. SOAP의 기본 구조는 <Header>, <Body>로 구성되어 있습니다. <Header>는 선택, <Body>는 필수적으로 있어야 합니다. SOAP의 <Body>는 메시지를 보낼 때 에러가 발생하면 전송자에게 알려주는데 <Fault> element가 <Body> element의 자식으로 포함되어 보내지는데, 분산 컴퓨팅에서는 아주 중요한 개념 입니다.
SOAP을 이용하여 개별 종목의 주가를 가져오는 웹 서비스 예제를 살펴보겠습니다.
The request:
GET /StockPrice HTTP/1.1Host: cooolguy.netContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn <?xml version="1.0"?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:s="http://www.cooolguy.net/stock-service"> <env:Body> <s:GetStockQuote> <s:TickerSymbol>MSFT</s:TickerSymbol> </s:GetStockQuote> </env:Body></env:Envelope>
The response:
HTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn <?xml version="1.0"?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:s="http://www.cooolguy.net/stock-service"> <env:Body> <s:GetStockQuoteResponse> <s:StockPrice>30.08</s:StockPrice> </s:GetStockQuoteResponse> </env:Body></env:Envelope>
REST
HTTP/1.0 Spec, HTTP/1.1, URI(Uniform Resource Identifiers) 등 인터넷의 표준을 수립하던 ROY T.FIELDING 교수가 웹 어플리케이션간 상호작용을 위한 이상적인 모델을 만들었는데, 그것이 바로 REST(Representational State Transfer) 아키텍처 스타일이며 최초 버전은 1995년에 만들어졌고, 현재 존재하는 웹 아키텍처의 근간을 이루고 있습니다. REST를 정의하기에 앞서 잘 디자인된 웹 어플리케이션이 동작하는 방식을 살펴보면 왜 이런 이름이 붙여졌는지 이해할 수 있습니다. 네트웍 상의 웹 페이지를 상태(State)를 가진 객체로 본다면 사용자가 링크를 클릭하거나 간단한 입력 값을 넣은 후 버튼을 클릭하면 해당 상태(State)가 특정한 형태(Representation)로 전송되고, 이 상태(State) 역시 다른 형태로 전송되는 과정을 갖게 됩니다. 결국 현재 우리가 매일 사용하는 Web이 REST를 가장 잘 표현한 아키텍처의 예가 됩니다. REST는 자원(Resource)에 대한 정의를 제공하는데 웹페이지, 이미지, 텍스트, 비디오, MP3, 슬라이드쇼, 지도 등 어떤 것도 자원이 될 수 있습니다. 자원을 명사라고 하면, 이 자원에 어떤 동작을 취하도록 하는 동사(Verb)가 필요하게 되는데 HTTP에서는 ‘GET’, ‘PUT’, ‘DELETE’, ‘POST’ 4개를 사용하고 있습니다.
|
HTTP |
동작 |
|
GET |
읽기 |
|
PUT |
생성, 수정 |
|
POST |
생성, 수정, 삭제 |
|
DELETE |
삭제 |
RESTful 웹 서비스는 Plain old XML(POX)을 HTTP 프로토콜을 이용하여 사용하는 방식 입니다. 위의 4개의 동사를 이용하여 네트웍 상에 위치하는 자원에 원하는 조작을 하게 됩니다.‘신현석’ 이라는 사용자의 상세한 정보를 가져오는 웹서비스를 만든다고 했을 때 HTTP GET 방식으로 “http://www.cooolguy.net/users/신현석’과 같이 사용할 수 있는 겁니다.
주가 정보를 가져오는 서비스를 RESTful 웹서비스로 구현하면 아래와 같습니다. SOAP 방식과 비교하면 훨씬 간단한 것을 느끼실 수 있습니다.
The request:
GET /StockPrice/MSFT HTTP/1.1
Host: coooguy.net
Accept: text/xml
Accept-Charset: utf-8
The response:
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<s:Quote xmlns:s="http://cooolguy.net/stock-service">
<s:TickerSymbol>MSFT</s:TickerSymbol>
<s:StockPrice>32.08</s:StockPrice>
</s:Quote>
SOAP이 XML 기반의 분산 컴퓨팅을 위한 프로토콜이라면, REST는 웹기반의 아키텍처 스타일 입니다. 이렇게 역사가 오래된 REST가 지금 부각되고 있는 이유는 웹은 “간단함”을 통해 성장 발전했는데, SOAP을 이용한 웹서비스는 복잡하다는 겁니다. HTTP, XML, URI만 가지고 웹서비스에 생명력을 불어넣고 싶어졌다는 거죠. 한가지 잊지 말아야 할 것은 RESTful 웹서비스를 가지고 SOAP이 할 수 있는 모든 것을 구현할 수는 없겠지만, “간단함”, “매시업” 같은 형태를 통해 웹의 서비스화가 가속화되고 있다는 사실 입니다.
SOAP의 장점
1. 언어, 플랫폼, 전송(Transport) 중립
2. 분산컴퓨팅 환경에서 사용하기 위한 디자인
3. 웹서비스를 위해 널리 사용되는 표준이며, 다른 표준과 통합을 통한 확장성이 뛰어나고 다양한 Vendor를 통한 지원이 이루어지고 있음
4. 에러처리 기능이 포함되어 있음
SOAP의 단점
1. 개념적으로 REST보다 더 어렵고, 무거움
2. 개발이 REST 보다 어렵고 Tool이 필요한 경우가 많음
REST의 장점
1. 언어, 플랫폼 중립
2. 일반적으로 SOAP보다 웹서비스 개발이 더 쉬움
3. 매시업을 통한 새로운 형태의 웹서비스 개발을 쉽게 할 수 있음
. Virtual Earth API와 연계하여 교통정보 제공 웹사이트를 개발하는 등
REST의 단점
1. 분산환경에서 메시지가 중간 경유지를 여러 번 통과하는 경우 사용하기 어려움
2. 보안, 정책, 안정적인 메시지 전달을 지원하기 위한 표준이 부족함
즉, 복잡한 요구사항을 표현하기 위해 직접 구현해야 함
