아키텍트2009. 4. 1. 15:31

REST 아키텍처 스타일에 대해서는 앞의 글에서도 소개했었는데, 오늘은 WCF 서비스를 활용한 방법에 대해 이야기하려고 합니다. REST(Representational State Transfer)에 대해서는 많은 분들이 도대체 뭐야? 라는 반응을 보이십니다.
하지만, 앞으로 정말 많이, 여러번 듣게 되실 개념이기 때문에 꼭 이해가 필요합니다.

WOA(Web Oriented Architecture)가 결국은 RESTful 아키텍처를 의미합니다.

REST란?
아키텍처 스타일이란 말은 어떤 무엇인가를 구축할 때 적용되는 규약들의 집합이라고 이야기할 수 있습니다. 즉, 소프트웨어 시스템을 구현할 때 사용되는 가이드 정도로 이해하면 되겠습니다.

클라이언트가 서비스(Endpoint)를 요청할 때 사용되는 클라이언트 – 서버 아키텍처 스타일 중의 하나입니다.
HTTP 스펙을 만든 사람 중의 한 명인 Roy Fielding 교수가 박사학위 논문에서 사용한 개념 입니다.
Architectural Styles and the Design of Network-based Software Architectures

Web이 바로 REST 아키텍처 스타일을 그대로 따르고 있는 시스템 입니다. 원칙을 한 번 살펴보도록 하죠.

  • 사용자 에이전트가 자원과 상호작용하는데, 자원은 URI로 표현될 수 있는 모든 것들이 대상입니다.
  • 자원과의 상호작용은 HTTP의 표준 동사(GET, POST, PUT, and DELETE)를 사용하여 이루어집니다. 또한, 상호작용을 위해 자원의 미디어타입이 결정되는데 HTTP 컨텐츠 타입의 헤더를 사용합니다.
    (XHTML, XML, JPG, PNG, and JSON are some well-known media types.)
  • 자원은 필요한 모든 정보를 다 포함하고 있습니다. (서비스가 stateless 형태로 존재)
  • 자원은 다른 자원과의 링크를 포함합니다. (하이퍼미디어)

하나의 간단한 예제로 이해를 해보도록 하죠.

MSDN 매거진의 데이터을 처리하는 서비스를 만든다고 가정해보죠.
- 해당 서비스는 지금까지 발행된 모든 MSDN 매거진에 대한 정보를 알려줍니다.
  매거진의 편집자가 이 서비스를 쓸 것이고 새로 발행되는 매거진에 대한 정보를 추가하고, 관리하는 등의 작업을 할
   예정 입니다.

RESTful 서비스를 구축할 때 서비스 디자인 단계를 살펴보죠

  1. 자원은 어떤 것들이 될 것인지?
  2. 자원을 표현하는데 사용할 URI로 어떤 값을 쓸 것인지?
  3. 단일 인터페이스 (HTTP 동사) 중 어떤 것을 쓸 것인지?

RESTful endpoint를 만드는 기본적인 블럭들입니다. 자원, 그리고 표현 방법

자원: MSDN 잡지가 출간된 모든 년도, 매년 발행된 이슈, 매거진에 게재된 기사
해당 자원을 표현하기 위해 XML을 사용하기로 하죠, 하지만 RESTful서비스는 XML에 한정된 것은 아니고 여러 유형으로 표현 가능합니다.

이제 URI를 결정해보죠. 절대경로는 이 endpoint를 어떤 호스트에 배치할 것인지에 달라지기 때문에, 여기서는 상대경로로 표현하도록 하겠습니다.
모든 년도들의 리스트, 즉 서비스의 루트 URI로 / 를 사용합니다.
이 구문을 활용하면, /{year} 는 해당 년도에 발행된 모든 잡지들에 대한 정보를 리턴합니다.
/{year}/{issue}는 해당 년도에 발행된 특정한 이슈에 대한 값을 리턴하겠죠.
/{year}/{issue}/{article}은 해당 이슈의 기사에 대한 정보값을 리턴하는데, 각 기사는 1 .. n까지 번호가 매겨졌다고 가정하죠

자, 이제 해당 URI를 단일인터페이스 (HTTP 동사)와 연결해보죠. 해당 잡지의 히스토리는 읽기 전용이어야 하므로, 해당 root 자원은 GET 동사만 사용되어야 합니다. 새로운 년도는 추가될 수 있으므로 PUT을 통해 /{year}가 추가되고, PUT을 통해 수정도 이루어질 수 있습니다. POST 연산을 통해서는 해당 자원을 신규로 생성할 때 사용되는데 해당 이슈를 만드는, /{year}/{issue} 등으로 사용합니다.

예를들어, 2006년 1월 이슈의 모든 기사를 원한다면 HTTP GET /2006/January 라고 가져올 수 있을 것이고 2009년 3월 이슈를 만들려면 POST /2008/december라고 쓸 수 있다는 것이죠.

그렇다면 왜 REST에 대해 이야기를 할까요?
서비스를 사용하는 방법이 REST 밖에 없을까요? 그렇지 않습니다.

클라이언트 서버 스타링의 애플리케이션을 구현하는데 있어서 다른 아키텍처 스타일을 사용할 수 있습니다. .NET의 특화된 RPC(Remote Procedure Call), 즉 DCOM 및 .NET 리모팅 등을 사용하거나 상호운용성이 제공되는 ASMX를 사용하는 SOAP, WCF 등의 RPC 기술을 사용할 수 있었죠.
그런데, REST를 사용하면 첫째, 훨씬 간편하고 쉽게 서비스를 구현할 수 있고 둘째, 마이크로소프트가 RPC 기술(SOAP 포함)에 비해 REST 아키텍처 스타일을 훨씬 더 선호하고 있기 때문인데, 그 이유가 있다는 거죠. 마이크로소프트의 클라우드 컴퓨팅, 애저 서비스 플랫폼과 윈도 애저에서도 REST 스타일을 채택하고 있습니다.

장점
Caching HTTP 동사를 통해 RESTfu endpoint가 불리워 질 때, HTTP 동사 GET을 사용합니다. GET으로 불리워진 자원들은 여러 다양한 방법으로 캐싱이 가능합니다. 결국 속도와 확장성이 향상됩니다.

Scale-Out REST는 각 자원이 특정 요청에 필요한 모든 상태 값을 다 가지고 있기 때문에, 즉 stateless기 때문에 확장이 훨씬 용이합니다.

Idempotent GET을 이용해 자원을 요청할 때 추가적인 부작용이 벌어지지 않습니다 (즉, 다시 한 번 GET, DELETE 등을 불러도 두번 중복작업이 이루어지지 않음)

Interoperability SOAP이 클라이언트 서버 프로그램을 통해 상호운용성이 뛰어나다고 하지만, 몇 몇 언어 및 환경은 여전히 SOAP 툴킷을 갖고 있지 못하고, 툴킷을 가지고 있는 언어의 경우에도 최신 표중르 가진 다른 툴킷과 통신할 수 없는 경우가 종종 발생합니다. REST는 HTTP 동사만을 사용하기 때문에 어떤 언어, 플랫폼과도 상호운용이 가능합니다.

Simplicity 너무 단순하게 구현이 가능합니다. URI와 HTTP 동사는 모든 웹개발자들이 다 알고 있는 내용입니다.

가능한 경우에 REST를 많이 사용하시기 바라고, 엔터프라이즈에서도 고려하고 있는 중입니다.

WCF and REST

WCF는 스타일, 프로토콜에 무관하게 통신이 가능한 분산 컴퓨팅 환경의 애플리케이션을 구축하는데 사용되는 마이크로소프트의 프레임웍 입니다. WCF 개념은 개발자가 한 프로그래밍 언어를 통해 다른 많은 분산 시스템을 사용 가능하도록 돕는 기술 입니다.

이전 버전의 WCF는 RPC(SOAP 등)를 이용하도록 사용되었는데, .NET Framwork 3.0부터는 REST 서비스를 사용할 수 있도록 지원하고 있었는데 REST 기반 서비스 프로그래밍이 가능한 모델 및 인프라 지원이 부족했는데, .NET Framwork 3.5 SP1에 프로그래밍 모델 및 기타 많은 부분이 개선되었습니다. 저도 조금 살펴봤는데 잘 만들어졌습니다.

프로그래밍 모델 중 두가지 속성, WebGetAttribute 과 WebInvokeAttribute, URI template 메커니즘이 주목할 만합니다.
URI, 메쏘드에 적용될 동사를 정의할 수 있도록 해주는 거죠. 인프라 영역에서는 WebHttpBinding 바인딩과 REST가 적절한 네트웍 스택을 사용할 수 있도록 WebHttp­Behavior가 지원됩니다. 또한, 커스톰 Service­Host (WebServiceHost) 와 ServiceHostFactory (WebServiceHostFactory)가 포함되어 있습니다.

WebGetAttribute 와 WebInvokeAttribute

WCF는 연결된 시스템 구축을 간단하게 해주는데, 네트웍 메시지를 여러분이 서비스를 구현하기 위해 정의한 클래스의 인스턴스로 라우팅해버린다. 결국, 네트웍 트랙픽을 처리하기 위한 인프라에 신경쓰지 않고, 코드의 로직에 집중할 수 있게 해주는 거죠. WCF와 인프라를 함께 사용할 때 기본 디스패처는 요청에서 사용하는 URI를 기준으로 라우팅을 진행합니다. 즉, 이 라우팅 방식을 사용하면 RESTful endpoint를 아주 쉽게 구현할 수 있고, 실제로 WebHttpDispatchOperationSelector를 사용합니다. 

이것이 가능하도록 하는 핵심은 WebHttpDispatch­OperationSelector는 서로 다른 URI와 동사를 여러분이 만든 메쏘드에 어떻게 매핑할 것인지를 아는 거죠. WebGetAttribute 와 WebInvokeAttribute는 WCF ServiceContract Type의 메쏘드에 반드시 포함되어야 합니다. WebGetAttribute는 디스패처에게 해당 HTTP GET 요청에 응답해야 한다고 알려주고, WebInvokeAttribute는 디폴트로 HTTP POST에 매핑됩니다. 메쏘드 속성은 다른 HTTP 동사를 지원하기 위해 설정 가능합니다. (PUT 과 DELETE ). 디폴트로 URI는 메쏘드에 이름으로 결정됩니다.
UriTemplate 과 UriTemplateTable

WCF는 각 자원의 URI를 정의할 수 있습니다.
이 경우에 AddArticle 메쏘드에 Method="POST"를 가독성을 위해 추가했습니다. (디폴트: WebInvokeAttribute POST). GET 과 POST 메쏘드는 uriTemplate을 통해 URI 커스토마이제이션 가능합니다.

WebHttpBinding 와 WebHttpBehavior

WCF에서 바인딩이 WCF가 어떻게 통신할 것인지를 결정합니다. RESTful endpoint를 위해 WebHttpBinding을 사용합니다. 다른 바인딩과 다르게 WebHttpBinding는 굉장히 간단합니다. 두 개의 컴포넌트 (HTTP transport 와 text message encoder)

WebHttpBehavior는 URI와 동사 디스패처를 위해 사용됩니다. WebHttpBinding과 항상 함께 사용된다고 보면 되죠.

ServiceHost sh =
  new ServiceHost(typeof(MSDNMagazineServiceType));
string baseUri = "http://localhost/MagazineService";
ServiceEndpoint se =
  sh.AddServiceEndpoint(typeof(IMSDNMagazineService),
  new WebHttpBinding(), baseUri);
se.Behaviors.Add(new WebHttpBehavior());
sh.Open();
WebHttpBinding을 지정해야할 뿐 아니라, ServiceHost의 endpoint도 추가해야 합니다. 또한, 명시적으로 WebHttpBehavior를 추가하여 endpoint에 URI와 동사 디스패칭 시스템이 동작하도록 하는 작업이 추가되어야 합니다.
물론, 설정으로도 위와 동일한 작업을 할 수 있죠.
WebServiceHost 와 WebServiceHostFactory

WCF에 대한 불만 중 하나가 설정에 관해 때때로 너무 복잡하다는 것입니다. RESTful endpoint의 이러한 불만을 줄이기 위해, 마이크로소프트는 WebServiceHost 와 WebServiceHostFactory를 .NET Framework 3.5에 추가하였습니다.
WebServiceHost 는 RESTful endpoint의 자체 호스팅 시나리오를 간단히 하기 해 추가된 유형입니다.

string baseUri = "http://localhost/MagazineService";
WebServiceHost sh =
  new WebServiceHost(typeof(MSDNMagazineServiceType),
  new Uri(baseUri));
sh.Open();

바로 이 코드를 사용하면 WebHttpBinding, WebHttpBehavior를 수작업으로 매번 추가하는 번거로움을 덜 수 있습니다. WebServiceHost 클래스가 자동으로 endpoint을 만들고, WebHttpBinding, WebHttpBehavior가 하는 설정을 대신해주기 때문이죠. IIS 웹서버에서 WCF 매니지드 호스팅 시나리오에서 WCF는 보통 서비스 타입을 가리키기 위해 .svc 파일이필요하고, WCF에게 endpoint에 대한 정보를 알려주기 위해 web.config 파일에 entry 를 추가합니다.
즉, 매니지드 호스팅 시나리오를 단순화 하기 위해 마이크로소프트는 WebServiceHostFactory를 추가했는데, 여러 RESTful 서비스의 설정 관련 부분을 덜어주기 위해 확장 point를 개방합니다.

<%@ ServiceHost Factory=
  "System.ServiceModel.Activation.WebServiceHostFactory"  
  Service="MSDNMagazine.MSDNMagazineServiceType" %>
WebServiceHostFactory는  WebServiceHost의 인스턴스를 생성하고, WebServiceHost는 WebHttpBinding과 WebHttpBehavior를 이용해 endpoint를 자동설정 합니다. 물론 바인딩에 대한 정보가 변경될 때는 설정 파일에 적절한 entries 값을 추가해야 겠죠.

Figure 1 서비스 endpoint에 HTTP 기본 인증을 설정하는 파일
Figure 1 HTTP Basic Authentication

예제 코드 사용하기

서비스를 만들고 구동하고 있다면, 어떤 클라이언트를 통해서도 root URI를 입력할 수 있습니다. 브라우저를 이용한 RESTful endpoint 테스트를 위해 아래와 같이 한 번 해보시죠.

Figure 2

Figure 2 Root Resource URI
이 경우에 나는 Visual Studio 2008 웹 개발 서버에 해당 코드를 호스팅하고 있습니다. Issues.svc 파일은 WCF 매니지드 호스팅 시나리오에서 필요한 파일 입니다. 특정 년도 값을 보기 위해서는 아래와 같이 입력합니다. Figure 3
Figure 3 2007년도를 나타내는 자원
만약 2008년 10월을 요청하려고 한다면, URI는 localhost:1355/Issues.svc/2008/October가 될 것이다. (현재 10월 값이 없다고 하자) 추가하려면 HTTP POST로 해당 기사를 요청해보자.
 
 
Figure 4 기사 자원 생성
 
URI 자원을 알고, 원하는 동작을 안다면 서비스로 활용이 충분히 가능함을 느낄 수 있으시죠?
바로 이 REST 아키텍처 스타일을 활용하면 Web Feeds (RSS, Atom), JSON 등을 AJAX와 연동하여 활용가능함이 느껴지나요?

MSDN Jon Flanders의 글을 번역하였습니다.

Posted by 조이트리
아키텍트2009. 3. 16. 15:37

주관: 서강대학교 지식서비스R&D센터
주최:  KRG
일시: 2009년 3월 24일(화) 09:30 ~ 17:00
장소: 서강대학교 마태오관 9층 리셉션홀

위 행사에서 14:10 ~ 14:50까지 ‘클라우드 컴퓨팅과 WOA’라는 주제로 발표를 진행합니다.
유료 세미나라 참석해달라고 하긴 좀 부담스럽네요. ^^

나중에 해당 내용에 대해서 공유하도록 하겠습니다.

감사합니다.

Posted by 조이트리
마이크로소프트2009. 3. 2. 17:45

제가 ZDNet과 인터뷰했던 부분이 아래와 같이 나왔네요.

http://www.zdnet.co.kr/ArticleView.asp?artice_id=20090302141715
관심 있는 분들은, 들어가셔서 봐주세요. ^^

Posted by 조이트리
아키텍트2008. 10. 24. 10:28
블로터닷넷 도안구 기자님이 아래와 같이 써 주셨습니다.

http://bloter.net/archives/7561

mmshsshin신현석 한국마이크로소프트 개발자와 플랫폼 사업총괄 부장은 “아마존의 아마존 웹서비스(Amazon Web Service)가 대표적이며 마이크로소프트의 버추얼어스를 부동산 정보와 결합해 제공하는 메시업, 다음커뮤니케이션과 NHN이 진행하고 있는 메시업, 오픈마루의 다양한 서비스 시도들이 WOA의 초기 모델이라고 볼 수 있습니다”라고 밝혔다.

야후의 교통정보라는 서비스를 마이크로소프트의 버추얼어스나 구글어스와 결합하거나 부동산 전문 업체들이 전세계 지도 서비스 업체들의 인프라를 활용해 3차원적인 정보 서비스를 별도로 만들어 내면서 이전과는 전혀 다른 서비스들이 속속 출현하고 있다. 이런 서비스를 제공하기 위해 자사의 서비스 아키텍처를 좀더 유연하게 만들어 내는 것이 WOA이다.

그렇다면 왜 WOA가 주목을 받을까?

신현석 부장은 “웹이 하나의 플랫폼이 됐기 때문입니다”라고 설명한다. 수 많은 웹 서비스 업체들은 자신들의 서비스를 네티즌들에게 제공하고 있지만 이와는 별개로 수많은 개발자들이 웹서비스 업체의 인프라를 활용해 또 다른 서비스를 만들어 낼 수 있도록 돕고 있다. 이런 서비스 인프라를 만들어 제공하지 않으면 경쟁 업체들이 선점하면서 생태계를 이끌어가기 때문에 웹서비스 업체들이 주목을 하고 있다.

그렇다고 해서 웹서비스 업체들만 관심을 가지는 것은 아니다. 일반 기업들도 인터넷뱅킹 서비스와 같은 다양한 인터넷 서비스를 제공하고 있는데 이런 사이트 구축을 할 때 WOA 형태로 진행할 수 있다. 다만 그동안 기업 내부적으로 SOA의 표준들이 다양하게 사용돼 왔기 때문에 웹 서비스 분야에서도 SOA 표준 중 하나인 SOAP를 사용할지 아니면 WOA의 REST를 사용할지의 선택을 해야 한다. 일장일단이 있기 때문에 어떤 아키텍처로 가져갈지에 대한 다각도의 검토 작업이 필수적이다.

공공 기관들의 경우, 통계정보나 지리정보, 기상정보 등 원천 데이터들을 보유하고 있고, 지속적으로 이를 담는 그릇을 서비스 형태로 만들어가기 위해 노력하고 있는만큼 WOA를 검토할 필요성은 기업이나 웹서비스 업체에 뒤쳐지지 않을 것으로 보인다.

신현석 부장은 “WOA가 SOA를 모두 대체할 수 있다고 보지는 않습니다. 어떤 서비스를 제공하기 위해 최적의 아키텍처는 무엇인지 검토가 필요한 상황이죠”라고 전하고 “SOA가 소개된지 오래됐지만 꾸준히 변화하고 있듯이 이제 막 소개되고 있는 WOA도 적용 가능한 분야를 찾아 진화, 진보해 나갈 것으로 봅니다”라고 밝혔다.

Posted by 조이트리
아키텍트2008. 10. 17. 10:19
2008년 10월 15일자 디지털타임즈에 위와 같은 제목의 기사가 게재되었습니다.
그 내용 중 제가 밝힌 내용도 나와서 참고로 올려 놓습니다.
http://www.dt.co.kr/contents.html?article_no=2008101602010560744002

SOA의 ROI에 의문이 제기 되고 있다.

"이런 가운데 기존 SOA의 단점을 보완하기 위한 대안찾기 움직임도 활발하다. 웹지향아키텍처(WOA)가 바로 그것으로 `단순함'이라는 웹의 근본적 장점을 충분히 살려 부동산 회사가 외부 지도정보 위에 매물정보를 함께 보여주는 등 기존의 웹 서비스를 차용해 빠르게 새로운 서비스를 개발하는 개념이다.

신현석 한국MS 개발자플랫폼 사업총괄 부장은 "WOA를 SOA와 같은 형태로 기업 환경에 적용하기 위해서는 데이터 암호화나 서비스 단위의 재사용 등 해결해야 할 기술적 과제가 아직 많이 남아있다"며 "그러나 일반 소비자 대상 서비스 영역에서 SOA의 단점을 보완해 활용할 수 있는 가능성은 충분할 것"이라고 말했다."

제일 중요한 것은 "고객이 얼마나 Benefit, 즉 혜택을 느낄 수 있는가" 라고 생각합니다. 그것이 SOA를 기반으로 개발되었든, 아니면 전통적 개발 방식으로 개발되었든 최종 사용자는 차이를 느끼기 어렵기 때문입니다. 그렇다면 비즈니스적으로 비용, 시간 등의 가시적인 효과가 없다면 무슨 이유로? 이런 질문을 해보게 됩니다.


Posted by 조이트리
아키텍트2008. 10. 15. 13:10

"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.1
Host: cooolguy.net
Content-Type: application/soap+xml; charset=utf-8
Content-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 OK
Content-Type: application/soap+xml; charset=utf-8
Content-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.     보안, 정책, 안정적인 메시지 전달을 지원하기 위한 표준이 부족함
, 복잡한 요구사항을 표현하기 위해 직접 구현해야 함

Posted by 조이트리
아키텍트2008. 9. 10. 20:31

consultant1.jpg

SOA에 대하여 수년간 이야기되고 있고, 아직도 IT의 주요한 Trend 라고 이야기 합니다. 많은 기업들이 SOA를 구현하는 프로젝트를 수행했고, 지금도 진행하고 있습니다. 그렇지만 성공한 프로젝트는 그렇게 많지 않은 것 같습니다. 왜 그럴까요? SOA가 잘못된 개념일까요? 그렇지 않죠. SOA는 훌륭한 개념입니다.

잘 적용된다면 이라는 가정이 필수적이죠. 잘 적용됐을 때의 이점은 분명합니다.
서비스의 재사용으로 인해 비용 절감, 빠른 시장 진입, 비즈니스 유연성 등을 보장 받을 수 있죠.
문제는 개념이 아니라 실행입니다.
비즈니스 부서에서 시작되어야 하는데, IT 부서가 SOA를 Drive하는 형태로 진행된다면 정말 성공하기 어려울 겁니다. 투입되는 막대한 예산에 대한 ROI를 얻기가 정말 어렵죠.

조금 더 구체적으로 설명해보면 SOA 디자인의 핵심은 독특한 비즈니스 기능을 수행하는 서비스를 재활용 가능하도록 만드는 것이었습니다. 웹서비스를 만드는데 기본 프로토콜은 SOAP을 사용했고, WSDL, UDDI 등의 기본적인 표준이 포함됐고 기타 플랫폼과의 상호운영성을 위해 XML 스키마를 이용하여 개발되는 등 복잡하고 어려운 단점이 있습니다. 이에 반해 오늘 설명할 WOA(Web Oriented Architecture)는 데이터에 초점이 맞춰져 있습니다.
또한, 검증된 기술, 바로 WWW을 이루는 HTTP 프로토콜을 그대로 사용하고, SOAP보다 간단한 REST(Representational State Transfer) 프로토콜을 사용하여 URI(Uniform Resource Identifier) 형태로 참조되면서 웹서비스를 구현할 수 있습니다.

이렇게 말하면 WOA가 SOA를 대체하는 개념인가? 하고 궁금하실 겁니다. 그렇지는 않고 상호 보완 관계로 이해하시면 될 것 같습니다. SOA가 사용하는 SOAP, WSDL, UDDI 는 처음에는 스펙이 단순했지만 약 8년간 지나오면서 지원해야 하는 스펙이 타 기술과의 경쟁, 비준 등의 이유로 50개 이상으로 확대 되었습니다. 따라서, 이런 복잡한 방식말고 그냥 쉽게 웹서비스를 가져다가 쓰고 싶은 욕구가 당연히 생기겠죠? 그때 사용한 프로토콜이 바로 REST 입니다. 간단한 것이 대중화가 훨씬 쉬운 법이죠. 아마존의 웹서비스, AWS 중 S3 (Simple Storage Service), EC2(Elastic Cloud Computing) 역시 REST/WOA 방식으로 서비스 되고 있습니다. 처음 개발자들에게 SOA/SOAP, WOA/REST 방식을 선택해서 쓰라고 해봤더니 85%가 WOA/REST 방식을 선택하였기에 해당 서비스가 WOA/REST 방식으로 이루어지고 있는 거죠. 마이크로소프트도 역시 REST 방식의 프로토콜을 이용한 WOA를 지원하는데, .NET Framework 3.0 SP1에서 제공하는 WCF 서비스, ADO.NET 서비스, SQL Server Data Services 등도 모두 이 예에 속합니다.

이렇게 설명하면 WOA가 새로운 기술이라고 생각하시나요? 그렇게 보지 마시고, 기존에 모두 있던 기술, 즉 "REST, HTTP 프로토콜을 활용해 웹서비스를 생성한 것"이라고 이해하시면 되는데, 여기에 이름을 붙였다라고 보시면 될 것 같네요.

자, 이제 그럼 WOA가 어디에 쓰이고, 왜 많이 쓰일까 좀 살펴봐야겠죠. 웹2.0에서 아주 중요한 개념입니다. 웹기반 SW는 브라우저, 웹서비스로도 지원되어 새로운 형태로 메시업되어 사용될 수 있어야 합니다. 이렇게 되면 SW가 단순한 어플리케이션에서 진정한 플랫폼으로 변환 되는 것을 의미합니다. 마이크로소프트의 Virtual Earth를 가져다가 자동차 보험회사에서 사고처리 하는 웹을 구현하는 것도 하나의 예가 되고, Salesforce.com의 AppExchange를 통해 서비스를 조합하여 원하는 형태의 업무가 가능하게 하는 것도 또다른 예가 되겠죠.
즉, 어플리케이션을 웹서비스로 공유하여 내가 만든 기능과 데이터를 다른 사람이 혁신적인 방식으로 유용하게 사용하는, 이전에는 상상하기 어려운 진보를 이루어 내는 겁니다. 누구나 거대한 서비스의 공급망의 일원이 되는 거죠. 단순하고 직관적으로, "Just Work"를 이루어 내는 겁니다. 내부에서 사용하는 방식도 HTTP의 GET, POST, PUT, DELETE 등의 이미 알고 있는 형태로 조작됩니다.

짐작하셨겠지만 장점만 있을까요? 당연히 아니겠죠. Two-phase commit, 메시징에 대한 보안 등은 처리가 안됩니다. SOAP에서 가능한 WS-* 표준이 지원되지 않기 때문이죠. HTTPS를 통한 전송에 대한 보안만 제공됩니다.

WOA에 대해 조금 설명을 해보겠습니다.
1. 네트웍상에 리소스 형태, 즉 URI로 표현, 접근, 조작됩니다. (HTTP 프로토콜)
2. 네트웍상의 모든 자원은 URI 형태로 배치됩니다.
    - URI는 자원임을 알 수 있는 것이 바람직합니다.
      예) http://domain.com/blogs/feeds/sruby.com -> http://domain.com/resources/1234567
3. 자원은 HTTP 동사(즉, GET, POST, PUT, DELETE)로 조작됩니다. using REST
4. 자원의 형식(XHTML, XML, MP3, AVI 등)은 URI에 인코딩 되어야 합니다. .xml 일반적
5. 네트웍상의 자원에 대한 조작은 네트웍상의 컴포넌트를 통해 조작됩니다. (브라우저, 웹서버)
6. 자원에 대한 접근은 계층적으로 이루어지고, 기본 네트웍 지식으로 사용 가능합니다.
7. 보내지는 상태에 대한 전송은 각 컴포넌트가 책임져야 합니다.
8. WOA 자원은 더 큰 네트웍을 표현할 수 있도록 내장 URI를 가져갈 수 있습니다. (예, 주문 컴포넌트는 인벤토리 포함가능)
9. WOA는 Thomas Erl의 "SOA 핵심 원칙"을 따릅니다.

SOA와 WOA의 차이점 입니다.
1. SOA는 작고, 잘 정의된 Endpoint가 있는 경향이 있습니다. WOA는 매우 크고, Open된 많은 Endpoint가 있습니다. 
2. 전통적으로 SOA는 SOAP을 사용한 HTTP 프로토콜 위에 메시지 Layer를 구축하는데, 유일하고 웹 개발자가 그대로 따라하도록 만들어집니다. WOA는 HTTP 및 그에 맞는 전송 메커니즘을 따르게 됩니다.
3. SOA는 벤더를 중심으로 Top Down 형태로 디자인 되고, WOA는 개발자들 중심의 Bottom Up 방식으로 나타납니다. 간단한 절차 코드와 XML 파서만 있으면 됩니다.
4. SOA는 보안 기능을 위해, 즉 메시지 암호화 등을 위해 WS-Security를 사용하는데 반해 WOA는 HTTPS를 사용합니다.
5. 웹 서비스 간의 상호 운영성을 위해 SOA는 XML 스키마를 사용해야만 합니다 WOA는 일반적으로 어떤 포맷도 가능합니다.
6. 전통적으로 SOA는 웹 브라우저 및 매시업 형태로 사용하기 어렵고 성가십니다. WOA는 어디서나 쉽게 사용 가능합니다.

즉, SOA와 WOA는 완전히 별개가 아니고 상호 보완 하는 형태로 이해하는 것이 좋습니다.

Web-Oriented Architecture
Posted by 조이트리