"웹서비스"의 두 판 사이의 차이
48번째 줄: | 48번째 줄: | ||
SOAP 기반 웹서비스의 요구가 기업의 비즈니스 환경에서 응용 서비스 간 상호 운용을 위해 시작된데 비해, RESTful 웹서비스는 인터넷 서비스 업체들이 응용 개발자들에게 손쉬운 데이터 제공을 목적으로 출발했다. 따라서 SOAP 기반 웹서비스는 서비스를 제공하고 이용하는 프로그램들이 잘 이해할 수 있도록 엄격한 문법에 따라 개발되었고, 때문에 개발자들에게는 웹서비스 기본 스펙을 알아야 하는 비교적 고난이도의 프로그래밍 능력이 요구되었다. 따라서 SOAP 기반 웹서비스 개발의 편의성을 도모하기 위해 다양한 개발 환경들이 지원되고있다. 반면 RESTful 웹서비스는 기계보다는 사람이 이해하기 쉽도록 인터넷 기본(HTTP와 XML) 이외에 별도의 개발, 실행 환경을 필요로 하지 않는다. 특히 RESTful 웹서비스를 제공하는 인터넷 서비스 업체들은 무료로 이용할 수 있는 서비스 매시업 환경을 함께제공하고있어개발자폭이 널리확대되고있다. 그러나 RESTful 웹서비스의 인기를 주도한 이유였던 인터넷 기본 외 별도의 표준을 요구하지 않는다는 특성이, 개발 및 관리를 어렵게 만드는 문제를 파생하게 되었다. 데이터에 대한 의미 자체가 비즈 | SOAP 기반 웹서비스의 요구가 기업의 비즈니스 환경에서 응용 서비스 간 상호 운용을 위해 시작된데 비해, RESTful 웹서비스는 인터넷 서비스 업체들이 응용 개발자들에게 손쉬운 데이터 제공을 목적으로 출발했다. 따라서 SOAP 기반 웹서비스는 서비스를 제공하고 이용하는 프로그램들이 잘 이해할 수 있도록 엄격한 문법에 따라 개발되었고, 때문에 개발자들에게는 웹서비스 기본 스펙을 알아야 하는 비교적 고난이도의 프로그래밍 능력이 요구되었다. 따라서 SOAP 기반 웹서비스 개발의 편의성을 도모하기 위해 다양한 개발 환경들이 지원되고있다. 반면 RESTful 웹서비스는 기계보다는 사람이 이해하기 쉽도록 인터넷 기본(HTTP와 XML) 이외에 별도의 개발, 실행 환경을 필요로 하지 않는다. 특히 RESTful 웹서비스를 제공하는 인터넷 서비스 업체들은 무료로 이용할 수 있는 서비스 매시업 환경을 함께제공하고있어개발자폭이 널리확대되고있다. 그러나 RESTful 웹서비스의 인기를 주도한 이유였던 인터넷 기본 외 별도의 표준을 요구하지 않는다는 특성이, 개발 및 관리를 어렵게 만드는 문제를 파생하게 되었다. 데이터에 대한 의미 자체가 비즈 | ||
니스의 필수 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 요구되었을 뿐 산업계 표준이 필요하지 않았다. 현재 REST의 산업계 표준이 없다 보니 개발에 있어서 여러 가지 문제점이 드러나게 되었다. 표준이 없는 경우에는 자체 스펙을 정하거나 유사 표준을 따라야 하는데, 자체 스펙을 정하는 것이 쉽지 않을 뿐더러 REST에 대한 잘못된 이해로 인한 잘못된 유사 표준들이 등장하는 경우도 발생하였다. 따라서 표준과 개발 인프라가 잘 갖추어진 SOAP 기반 웹서비스에 비해, RESTful 서비스는 표준과 개발 인프라에 얽매이지 않는 대신 서비스와 시스템도 REST | 니스의 필수 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 요구되었을 뿐 산업계 표준이 필요하지 않았다. 현재 REST의 산업계 표준이 없다 보니 개발에 있어서 여러 가지 문제점이 드러나게 되었다. 표준이 없는 경우에는 자체 스펙을 정하거나 유사 표준을 따라야 하는데, 자체 스펙을 정하는 것이 쉽지 않을 뿐더러 REST에 대한 잘못된 이해로 인한 잘못된 유사 표준들이 등장하는 경우도 발생하였다. 따라서 표준과 개발 인프라가 잘 갖추어진 SOAP 기반 웹서비스에 비해, RESTful 서비스는 표준과 개발 인프라에 얽매이지 않는 대신 서비스와 시스템도 REST | ||
− | 개념에 맞는 설계가 필요하다.<ref name="다"></ref> | + | 개념에 맞는 설계가 필요하다.<ref name="다"></ref> |
+ | |||
+ | ;시맨틱 기술 | ||
+ | 시맨틱 웹서비스란 인터넷에 개발된 수많은 웹서비스를 보다 의미적으로 활용하기 위하여 시맨틱 기술을 도입한 웹서비스를 의미하며, 웹서비스에 다양한 의미 정보를 부가하여 궁극적으로 의미적 검색을 통한 동적 서비스 조합을 실현하는 데 필요한 요소 기술이다. 머지않은 미래에 인터넷의 수많은 서비스 중 사용자의 의도와 목적에 꼭 맞는 서비스를 손쉽게 찾고 또는 즉시 새로 만들어 사용할 수 있는 서비스 환경이 도래할 것이며, 이때 시맨틱 웹서비스 기술이 견인차 역할을 하게 될 것이다. OWL-S는 표준 웹 온톨로지 언어인 OWL을 개발한 미국의 DAML 컨소시엄에 의해 W3C 표준으로 제안된 시맨틱 웹서비스이다. OWL-S는 서비스 개요를 기술하는 서비스 프로파일(profile)과 서비스 실행과 연관된 프로세스 정보를 제공하는 프로세스 모델(process model), 서비스 매핑을 담당 | ||
+ | 하는 서비스 그라운딩(grounding)으로 구성되어 있다. OWL-S를 이용한 시맨틱 웹서비스 검색(discovery)에 대한 연구로는 OWL-S/UDDI Matchmaker, OWL-S Broker, OWL-S for P2P 등이 있다. 서비스 조합은 OWL-S4UDDI, Planner, OWL-S Reasoner, OWM-S VM을 이용한 접근 방법들이 시도되고 있다. 또한 OWL-S Broker를 이용하여 서비스 중재(mediation) 기능을 제공할 수 있으며, 서비스 실행은 OWL-S Virtual Machine을 이용한 접근 방법이 있다. WSMO는 시맨틱 웹서비스의 다양한 측면을 서술하기 위한 개념 모델로서, 4가지 시맨틱 웹서비스의 핵심 요소(ontologies, goals, web services, mediation)를 온톨로지 형태로 정의한 명세서이다. WSML은 WSMO를 표현하기위한언어이고, WSMO Studio에서제공하는 choreography designer를 이용하여 서비스를 조합할 수 있으며, WSMX의 choreography engine에서 실행한다. 또한 시맨틱 웹서비스를 실행하기 위한 BEPL 엔진에 대한 연구도 있다. 반면, RESTful 기반의 웹서비스에 시맨틱 기술이 도입되고 있는 현황으로는 hREST | ||
+ | 의 경우 MicroWSMO에 대한 연구가 있지만, SOAP 기반 웹서비스에서의 시맨틱 기술 도입 연구에 비해 연구 범위나 기술 표준화 상황이 미진한 상황이다. 전반적으로 기능적(functional), 비기능적(nonfunctional), 행위적(behavioral), 정보(informational) | ||
+ | 시맨틱 기반의 반자동 어노테이션 기법과 검색 기술들이 일부 연구되고 있으나, RESTful 웹서비스의 중재 및 컴포지션 기술에 대해서는 시맨틱 기술 도입의 관심이 필요한 시점이다. 이는 RESTful 웹서비스 구현에 관한 표준기술이 부재하여 구현기술의 제약이 없으므로 다양한 기술로 빠르게 인터넷에 전파되는 장점이 있지만, 반대로 구현 기술의 다양성이 RESTful 웹서비스에 시맨틱 기술을 적용하기위한 본격적인 연구가 늦어지는 주요 원인으로 분석된다.<ref name="다"></ref> | ||
:{|class=wikitable width=1000 style="background-color:#ffffee" | :{|class=wikitable width=1000 style="background-color:#ffffee" |
2020년 8월 24일 (월) 11:29 판
웹서비스(web service)란 인터넷 웹사이트를 통해 제공하는 서비스를 말한다. 인터넷 정보 제공, 포털, 검색, 뉴스, 메일, 커뮤니티, 블로그, 채팅, 메신저, 쇼핑, 부동산, 증권, 뱅킹, 게임, 미팅, 교육, 사전, 책, 지도, 사진, 만화, 음악, 동영상, 가상현실 등 다양한 서비스를 제공한다. 웹서비스는 인터넷에서 단일한 비즈니스 또는 다수의 비즈니스 업체간의 기존 컴퓨터 시스템 프로그램을 결합시키는 표준화된 소프트웨어 기술로서, 이러한 표준 기술을 이용해 모든 비즈니스 기능을 가능하게 하는 서비스이다.
목차
개요
웹서비스란 SOAP(Simple Object Access Protocol)이나 WSDL(Web Service Description Language), UDDI(Universal Description, Discovery, and Integration) 등의 표준 기술을 이용하여 네트워크에 연결된 다른 컴퓨터 간의 분산 컴퓨팅을 지원하는 소프트웨어 및 기술이다. 웹서비스는 '웹'과 '서비스'라는 두 단어가 결합해 생겨난 용어인 만큼 단순하게 해석하면 웹을 통해 서비스를 교환하는 것이다. '웹'은 표준 방식으로 분산되어 있는 정보자원들을 공유하고 호환시키는 인터넷의 응용이다. 이는 전 세계적으로 정치, 경제, 사회, 산업 전반에 걸쳐 큰 변화를 가져왔다. '서비스란' 사용자에게 세부적인 사항은 감추고 추상적인 관점에서 제공되는 기능을 의미한다. 종합적으로 웹서비스는 분산되어 있는 콘텐츠를 서비스 형태로 추상화시켜 표준 방식으로 연계하거나 공유하는 기술이다. 웹서비스의 초기 표준화 작업부터 지속적으로 참여해 온 아이비엠(IBM)은 웹서비스를 표준화된 XML(eXtensible Markup Language) 메세지를 통하여 네트워크로 접근 가능한 오퍼레이션들을 기술하는 인터페이스라고 정의하고 있다.[1]
등장배경
아이티(IT)는 놀라울 정도로 빠르게 발전하고 있으며, 이에 따라 수많은 개념이나 용어들이 등장하고 있다. RTE(Real Time Enterprise), 광대역통합망(BcN) 및 그리드 컴퓨팅에서 공유되고 있는 교집합적인 기술은 바로 웹서비스이다. 수년 전부터 사전적 용어로 사용되어 왔지만 한 단계 나아가 우리 생활에서 없어서는 안 될 필수적인 서비스로 대두되었다. 그러나 웹서비스 환경에서 전자상거래를 수행할 때는 신뢰가 필요하다. 전자상거래에서의 믿음이란 트랜젝션의 믿음을 말하며 모임에 대한 믿음 그리고 통제 메커니즘의 믿음으로 나눌 수 있다. 전자는 개인 A 가 예측하기를 개인 B 가 어떤 행위를 할 주관적인 확률을 말한다. 한편, 후자는 객관적인 관점에서의 믿을을 말하며 개인이 그 내부 메커니즘을 이해하기 어렵다. 웹서비스에서 신뢰감을 형성하는 것은 중요한 문제다. 신뢰의 실체는 전자상거래의 기술적 요인과 인적 요인으로 나눌 수 있다. 기술적 요인은 보안성이 높은 암호화 기술을 개발하여 전자지불시스템에 도입하거나 방화벽과 같은 하드웨어를 보강하여 해킹 당하는 일이 없도록 하는 것이다. 인적 요인은 시스템 개발자, 웹사이트 설계자, 전자상점을 운영하는 사람, 상점주인, 상점을 이용하는 다른 사용자와 같이 전자상거래에 참여하는 사람들을 믿느냐는 것이다. 아무리 신뢰성 있는 시스템일지라도 그것을 운영하는 사람을 믿을 수 없다면 전자거래의 신뢰성은 무너지고 만다. 실제 전자상점 주인이 자신의 개인정보를 목적 이외로 이용할 수도 있기 때문이다. 웹서비스는 이제 클라이언트 환경을 극복하고 차세대 컴퓨팅 시대를 여는 서막 역할을 하고 있다. 인터넷의 급속환 확산은 클라이언트 환경에 대한 문제를 해결하고자 하는 아이티 업계의 노력을 더욱 가속화시키는 계기가 되었다.[1]
특징
인터넷을 통한 웹서비스는 거래업체간의 이질적인 운영시스템, 이질적인 프로그램언어간의 커뮤니케이션 차이를 극복해주는 연결고리 역할을 해준다. 웹서비스의 기본적인 요소는 XML(Extensible Markup Language), UDDI(Universal Description, Discovery and Integration), WSDL(Web Service Description Language), SOAP(Simple Object Access Protocol)이다. XML은 인터넷을 통해 데이터를 교환하는 표준 양식으로 오픈 프레임워크인 웹서비스의 기반 구조를 이루고 있다. UDDI는 업체가 자사의 웹서비스를 온라인 디렉토리에 등록·광고하거나 외부에서 웹서비스를 검색하는데 사용되고, WSDL은 웹서비스를 정의하는 언어로서 소프트웨어 업체가 웹서비스를 기술할 때사용되며, SOAP은 인터넷을 통해 웹서비스가 통신할 수 있게 하는 역할을 한다. UDDI, WSDL, SOAP은 MS와 IBM 주도로 어느 정도 표준이 제정된 상태이고, WSDL(Web Services Description Language)은 호환성 문제가 논의되고 있다.[2]
기술
UDDI
다수의 웹서비스를 제공하는 소프트웨어 환경을 고려해 보면 웹서비스 검색 방법, 웹서비스 정보를 의미 있게 분류할 수 있는 방법, 지역화와 관련된 문제, 독점 기술이 미치는 영향검색, 메커니즘의 상호 운용성을 보장할 수 있는 방법과 같은 문제가 제기될 수 있다. 이러한 문제에 대응하기 위해 UDDI가 출현했다. 마이크로소프트, 아이비엠, 썬, 오라클, 콘파쿠, 에이치피, 인텔 및 에스에이피와 300 개가 넘는 다른 회사를 비롯한 다양한 회사가 공동으로 이러한 문제를 해결하기 위해 개방형 표준과 비독점적 기술을 기반으로 한 사양을 개발하게 되었다. 그 결과 2000년 12월 베타 버전으로 시작되어 2001년 3월 제품으로 출시된 것이 전역 비즈니스 레지스트리이다. 이 레지스트리는 다양한 운영자 노드에서 운영되므로 사용자가 전혀 비용을 들이지 않고 웹서비스를 검색하고 게시할 수 있다. 최근 전자 정부의 UDDI를 일원화한 국가공인서비스등록저장소를 구축해 민원안내등 기존 공통서비스의 재사용률을 높이는 방안도 추진하고 있다. 이를 위해 전자정부 표준 공통 서비스 및 개발 프레임워크 구축사업 내에서 서비스 데이터의 정합성을 확보하고 흩어져 있는 데이터를 단일 저장소로 통합하는 작업이 진행 중이다.[1]
- 데이터 구조
- 비즈니스 개체 : 어떤 업체가 웹서비스를 하고자 한다면 제공자에 대한 비즈니스 정보를 알려 주어야 할 것이다. 즉 서비스를 제공한 업체 이름, 전화번호, 웹주소 같은 연락처 정보를 비롯하여 카테고리와 같은 기본 정보를 제공해야 한다. 이러한 기본적인 비즈니스 정보에 해당하는 것이 비즈니스 개체이다.[1]
- 비즈니스 서비스 : 비즈니스 개체가 제공하는 서비스에 대한 정보이다, 제공되는 서비스에 대한 산업별, 제품별, 지역별 분류와 같은 정보, 서비스가 어떤 기능을 하는지에 대한 정보, 그밖에 비즈니스 프로세스나 서비스 집합에 관련된 논리적 서비스 분류 정보 등 서비스 정보를 제공하는 것이다.[1]
- 바인딩 템플릿 : 비즈니스 서비스와 티모델(tModel) 사이의 사상을 담당하는 웹서비스를 위한 기술적인 정보다. 여기서 서비스를 찾기 위한 시작점을 제공하게 된다.[1]
- 티모델(tModel) : 서비스들은 UDDI 데이터 모델에 따라 분류가 된다. 또한 여러 서비스들은 분류 기준과는 별도로 일정한 유형에 따라 그룹화될 수 있다. 티모델은 이런 분류 기준과 유형 기준을 관리하는 개체이다. 티모델을 따로 관리함으로써 서비스를 찾고자 할 때 분류별, 유형별로 검색이 가능하게 된다.[1]
- 퍼블리셔 가정(Publisher Assertion) : 기업간의 연관 관계를 부정하는 상황이 발생할 때, 공증서처럼 기업간의 연관이 있음을 증명해 주는 역할을 수행하게 된다.[1]
WSDL
WSDL은 비즈니스 서비스를 기술하여 비즈니스들끼리 전자적으로 서로 접근하는 방법을 제공하기 위해 사용되는 XML 기반의 언어이며 웹서비스 시스텀 기능들을 명세화시키는 방법을 표준화하기 위하여 만들어졌다. WSDL은 웹서비스 시스템에서 제공하는 기능들을 외부에서 이용할 수 있도록 사용법을 알려주는 인터페이스 언어로써, CORBA 의 IDL(Interface Definition Language)에 해당한다. UDDI의 기초가 되는 언어로서 SOAP 와 NASSL(Network Accessible Service Specification Language)로부터 나왔다.[1]
SOAP
SOAP가 생겨나기 전에, 이러한 종류의 정보를 사용하는 프로그램들은 웹페이지를 가져와서 해당 텍스트를 찾기 위해 HTML을 분석해야 했다. 그런한 웹페이지들을 다시 디자인 하는 것은 이러한 프로그램을 쓸모 없게 만들기만 할 뿐이었다. 그러므로 강력한 클라이언트와 서버간 연결 프레임워크를 제공하는 생성엔진이 필요하게 되었는데 이것이 바로 SOAP이다. SOAP는 XML 과 HTTP 등을 베이스로 한, 다른 컴퓨터에 있는 데이터난 서비스를 호출하기 위한 프로토콜이며 점점 더 많은 SOAP 서버들을 웹에서 사용할 수 있게 되면서, SOAP은 거의 모든 프로그램에서 실행될 수 있다. SOAP를 통해 웹에서 사용할 수 있는 많은 정보 소스들을 활용할 수 있다. SOAP를 통한 통신에는 XML 문서에 봉투라 불리는 부대정보가 포함된 메시지를 HTTP등의 프로토콜로 교환한다. 서비스를 이용하는 클라이언트와, 서비스를 제공하는 서버의 양방이 SOAP의 생성과 해석 엔진을 창착함으로써, 서로 다른 환경에서 객체의 호출을 가능하게 한다. SOAP를 사용해서 프로그램은 요청을 SOAP서버로 보낸다. SOAP서버는 그러한 매개변수를 가진 메소드를 실행하고 SOAP 응답을 다시 프로그램으로 보낸다, 응답은 실행 결과가 되거나 에러 메세지가 될 수 있다. 서버는 주식 가격, 최신 환율, 운송 정보에 대한 해답, 모든 종류의 정보를 SOAP 클라이언트에 제공할 수 있다. 미들웨어와 기업응용간의 통신은 SOAP를 많이 사용하기 때문에 웹서비스 시큐리티가 좋은 인증 방법이 될 수 있다. 이 시큐리티는 SOAP 헤더에 사용자 인증 정보를 담아 보내기 때문에 SOAP 바디에 존재하는 미들웨어 통신 프로토콜을 변경하지 않고도 보안 적용이 가능하다. 이때 사용할 수 있는 인증 방법은 아이디, 패스워드 또는 공개키 기반 인증서이다. SOAP 1.0은 HTTP에 한하지만 SOAP1.1에서는 실제로 데이터의 송수신에 사용하는 하위 프로토콜은, 이미 광범위하게 보급이 진행된 HTTP, SMTP, FTP 중 선택 할 수 있으며, 기업간 이용에는 방화벽을 안전하게 통과 할 수 있다.[1]
비교
SOAP 기반
일반적으로 ‘웹서비스’란 분산되어 있는 콘텐츠를 추상적인 서비스 형태로 개방하여 표준화된 형태로 공유하는 기술로서 SOA 개념을 실현하기 위한 대표적 기술이라 할 수 있다. 웹서비스 내의 모든 데이터는 XML로 표현되고, 그 데이터들과 이를 다룰 수 있는 오퍼레이션들이 WSDL로 정의되면 UDDI라는 전역적 서비스 저장소에 등록되어 누구라도 서비스를 찾을 수 있도록 공개된다. 공개된 웹서비스가 이용될 때, 서비스 요청자와 서비스 제공자 간에 SOAP을 이용하여 서비스를 호출하고 결과를 돌려받게 된다. 이러한 웹서비스 기술은 이기종 플랫폼 위에 구축된 응용들 간에 연동을 목적으로, 상호 이해 가능한 포맷의 메시지를 SOAP으로 송수신함으로써 원격지에 있는 서비스 객체나 API를 자유롭게 사용하고자 하는 기업의 요구에서 출발하였다. SOAP은 특정 분산 기술 또는 플랫폼에 의존하지 않고 분산 객체를 액세스 할 수 있는 프로토콜로서 HTTP 상에 서 전송된다. 모든 SOAP 메시지는 SOAP 봉투(envelope), SOAP 헤더(header), SOAP 바디(body)로 구성된 하나의 XML 문서로 표현되는데 이러한 복잡한 구성으로 인해 HTTP 상에서 전달되기 무겁고, 메세지 인코딩, 디코딩 과정 등 웹서비스 개발의 난이도가 높아 개발 환경의 지원이 필요하다. 이러한 SOAP을 통해 전달하려는 대상은 웹서비 스를 기술(description)한 WSDL 문서이다. WSDL은 특정 비즈니스가 제공하는 서비스를 요청자들이 전자적으로 접근하여 이용할 수 있도록 표준 형태로 정의하는 XML 기반의 언어이다. 여기에는 웹서비스 이름과 주소(URI), 인터페이스, SOAP 메시지 인코딩 방식, SOAP 전달을 위한 전송 프로토콜 등이 기술된다. WSDL은 W3C에서 표준화되고있으며 현재산업계에서는 WSDL 1.1과 2.0을지원하고있다.[3]
RESTful 기반
REST는 부수적인 레이어나 세션 관리를 추가하지 않고도 HTTP 프로토콜로 데이터를 전달하는 프레임워크이다. 또한 클라이언트/서버 간의 구성요소를 엄격히 분리하여 구현은 단순화시키고 확장성과 성능은 높일 수 있는 아키텍처다. 최근 들어 REST는 웹에 개방된 리소스들을 원격에서 또는 지역적으로 쉽게 이용하려는 웹 응용에 정착하게 되었고, REST 아키텍처 스타일에 따라 정의되고 이용되는 서비스나 응용을 RESTful 웹서비스라 한다. 여기서 리소스란 REST 아키텍처의 핵심 요소로서 웹사이트, 블로그, 이미지, 음악, 이용자, 지도, 검색 결과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미한다. REST 구조에서의 리소스는 그들의 고유한 URI를 가지며, HTTP의 기본 메소드인 GET/PUT/POST/DELETE만으로 접근할 수 있다. HTTP 기본 메소드로 전달되는 리소스는 다양한 방식으로 표현되는데, XML, JSON, HTML, 텍스트, 이미지 등이 가능하며 클라이언트에서 원하는 형식으로 표현하면 서버에서 이를 처리하게 된다. 리소스의 다양한 표현 방식은 HTTP의 수용 헤더 값 또는 URI 파라미터로 지정하면 된다. 리소스와 그를 지칭하는 URI, HTTP로 단일화된 인터페이스, 다양한 리소스 표현 등과 더불어 빼놓을 수 없는 RESTful 웹서비스의 특성이 스테이트리스(statelessness)이다. HTTP의 특성을 상속하여 REST 역시 스테이트리스 특성을 가지게 되는데 스테이트리스란 웹서비스 제공 서버 측에서 클라이언트의 상태 정보를 저장, 관리하지 않는 것을 의미한다. 그러나 RESTful 웹서비스 제공시 응용의 상태와 리소스의 상태 관리가 필요할 수 있으며, 이를 위해서는 서버와 클라이언트 간에 이들의 상태를 명시적으로 전달하는 방법을 이용해야 한다. 이는 REST라는 이름이 함축하고 있는 특성이기도 하다. 이와 같이 RESTful 웹서비스는 리소스 중심의 표현, 전달, 접근 방식의 특성으로 인해 리소스 기반 아키텍처라고한다. ROA는서비스중심의 SOA에 대응되는 개념으로 일컬어지고 있다. 즉, RESTful 웹서비스는 리소스 URI를 알면 웹서버와 웹클라이언트의 종류에 상관없이 HTTP 프로토콜만으로 접근 가능한 서비스라 할 수 있다. 이러한 단순 명료한 접근 방식 때문에 구글, 야후, 트위터 등 대부분의 웹 2.0 API가 RESTful 웹서비스로 제공되고 있으며, 위젯을 이용한 서비스 매시업(mashup)을 활성화시킨 원동력이기도 하다. 또한 기존에 제공되던 SOAP 기반의 웹서비스 조차도 RESTful 웹서비스화 되어 동시에 제공되는 추세이다.[3]
- 서비스 구조
SOAP 기반 웹서비스가 SOA 구조에 따라 UDDI 레지스트리를 통해 웹서비스를 등록하고, 탐색하고, 바인딩하여 이용한다면, RESTful 웹서비스는 리소스를 등록하고 저장해두는 중간 매체 없이 리소스 제공자가 직접 리소스 요청자에게 제공하는 방법을 따르고있다. 서비스 실행 관점에서, SOAP 기반 웹서비스에서는 서비스 제공자와 요청자 간에 SOAP 프로토콜로 메시지를 주고 받는 방식으로 서비스를 이용한다. 즉, 서비스 요청자가 웹서비스 요청을 SOAP으로 인코딩하여 서비스 제공자에게 전달하면, 서비스 제공자는 이를 디코딩하여 적절한 서비스 로직을 통하여 결과를 얻고, 그 결과를 다시 SOAP 인코딩하여 서비스 요청자에게 반환한다. 한편, RESTful 웹서비스는 기본 HTTP 프로토콜의 메소드 GET, PUT, POST, DELETE를 이용하여 다양한 형태로 표현된(JSON, XML, RSS 등) 리소스를 직접 실어 나른다.[3]
- 서비스 기술
SOAP 기반 웹서비스의 요구가 기업의 비즈니스 환경에서 응용 서비스 간 상호 운용을 위해 시작된데 비해, RESTful 웹서비스는 인터넷 서비스 업체들이 응용 개발자들에게 손쉬운 데이터 제공을 목적으로 출발했다. 따라서 SOAP 기반 웹서비스는 서비스를 제공하고 이용하는 프로그램들이 잘 이해할 수 있도록 엄격한 문법에 따라 개발되었고, 때문에 개발자들에게는 웹서비스 기본 스펙을 알아야 하는 비교적 고난이도의 프로그래밍 능력이 요구되었다. 따라서 SOAP 기반 웹서비스 개발의 편의성을 도모하기 위해 다양한 개발 환경들이 지원되고있다. 반면 RESTful 웹서비스는 기계보다는 사람이 이해하기 쉽도록 인터넷 기본(HTTP와 XML) 이외에 별도의 개발, 실행 환경을 필요로 하지 않는다. 특히 RESTful 웹서비스를 제공하는 인터넷 서비스 업체들은 무료로 이용할 수 있는 서비스 매시업 환경을 함께제공하고있어개발자폭이 널리확대되고있다. 그러나 RESTful 웹서비스의 인기를 주도한 이유였던 인터넷 기본 외 별도의 표준을 요구하지 않는다는 특성이, 개발 및 관리를 어렵게 만드는 문제를 파생하게 되었다. 데이터에 대한 의미 자체가 비즈 니스의 필수 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 요구되었을 뿐 산업계 표준이 필요하지 않았다. 현재 REST의 산업계 표준이 없다 보니 개발에 있어서 여러 가지 문제점이 드러나게 되었다. 표준이 없는 경우에는 자체 스펙을 정하거나 유사 표준을 따라야 하는데, 자체 스펙을 정하는 것이 쉽지 않을 뿐더러 REST에 대한 잘못된 이해로 인한 잘못된 유사 표준들이 등장하는 경우도 발생하였다. 따라서 표준과 개발 인프라가 잘 갖추어진 SOAP 기반 웹서비스에 비해, RESTful 서비스는 표준과 개발 인프라에 얽매이지 않는 대신 서비스와 시스템도 REST 개념에 맞는 설계가 필요하다.[3]
- 시맨틱 기술
시맨틱 웹서비스란 인터넷에 개발된 수많은 웹서비스를 보다 의미적으로 활용하기 위하여 시맨틱 기술을 도입한 웹서비스를 의미하며, 웹서비스에 다양한 의미 정보를 부가하여 궁극적으로 의미적 검색을 통한 동적 서비스 조합을 실현하는 데 필요한 요소 기술이다. 머지않은 미래에 인터넷의 수많은 서비스 중 사용자의 의도와 목적에 꼭 맞는 서비스를 손쉽게 찾고 또는 즉시 새로 만들어 사용할 수 있는 서비스 환경이 도래할 것이며, 이때 시맨틱 웹서비스 기술이 견인차 역할을 하게 될 것이다. OWL-S는 표준 웹 온톨로지 언어인 OWL을 개발한 미국의 DAML 컨소시엄에 의해 W3C 표준으로 제안된 시맨틱 웹서비스이다. OWL-S는 서비스 개요를 기술하는 서비스 프로파일(profile)과 서비스 실행과 연관된 프로세스 정보를 제공하는 프로세스 모델(process model), 서비스 매핑을 담당 하는 서비스 그라운딩(grounding)으로 구성되어 있다. OWL-S를 이용한 시맨틱 웹서비스 검색(discovery)에 대한 연구로는 OWL-S/UDDI Matchmaker, OWL-S Broker, OWL-S for P2P 등이 있다. 서비스 조합은 OWL-S4UDDI, Planner, OWL-S Reasoner, OWM-S VM을 이용한 접근 방법들이 시도되고 있다. 또한 OWL-S Broker를 이용하여 서비스 중재(mediation) 기능을 제공할 수 있으며, 서비스 실행은 OWL-S Virtual Machine을 이용한 접근 방법이 있다. WSMO는 시맨틱 웹서비스의 다양한 측면을 서술하기 위한 개념 모델로서, 4가지 시맨틱 웹서비스의 핵심 요소(ontologies, goals, web services, mediation)를 온톨로지 형태로 정의한 명세서이다. WSML은 WSMO를 표현하기위한언어이고, WSMO Studio에서제공하는 choreography designer를 이용하여 서비스를 조합할 수 있으며, WSMX의 choreography engine에서 실행한다. 또한 시맨틱 웹서비스를 실행하기 위한 BEPL 엔진에 대한 연구도 있다. 반면, RESTful 기반의 웹서비스에 시맨틱 기술이 도입되고 있는 현황으로는 hREST 의 경우 MicroWSMO에 대한 연구가 있지만, SOAP 기반 웹서비스에서의 시맨틱 기술 도입 연구에 비해 연구 범위나 기술 표준화 상황이 미진한 상황이다. 전반적으로 기능적(functional), 비기능적(nonfunctional), 행위적(behavioral), 정보(informational) 시맨틱 기반의 반자동 어노테이션 기법과 검색 기술들이 일부 연구되고 있으나, RESTful 웹서비스의 중재 및 컴포지션 기술에 대해서는 시맨틱 기술 도입의 관심이 필요한 시점이다. 이는 RESTful 웹서비스 구현에 관한 표준기술이 부재하여 구현기술의 제약이 없으므로 다양한 기술로 빠르게 인터넷에 전파되는 장점이 있지만, 반대로 구현 기술의 다양성이 RESTful 웹서비스에 시맨틱 기술을 적용하기위한 본격적인 연구가 늦어지는 주요 원인으로 분석된다.[3]
서비스 기술 비교 비교 SOAP 기반 웹서비스 RESTful 웹서비스 배경 및 현황 - 기업을 위한 비즈니스 응용에서부터 출발
- 아이비엠, 오라클 등을 선두로 하는 웹서버 벤더에서 주창
- SOA의 서비스는 대부분이 비즈니스 컴포넌트로서의 의미를 가짐
- 웹 2.0은 서비스 애플리케이션에서부터 시작
- 구글, 아마존, 야후와 같은 인터넷 서비스 기업에 의해서 주창
- 맵이나 뉴스, 가젯 등과 같이 UI 성격을 갖는 서비스가 대다수임
특징 - The Machine-Readable Web: 사람보다는 기계가 해석할 수 있는 웹
- Stateful: 오퍼레이션 중 서비스 상태가 일관되게 유지, 관리되어야 함
- 엄격한 문법 검사, 서비스 계약에 충실
- 웹 서버 등 웹서비스 개발 환경이 지원되어야 함
- The Human-Readable Web: 사람이 해석할 수 있는웹
- Stateless: 오퍼레이션 중 서비스/리소스의 상태를 관리하지 않음(HTTP의 기본 메커니즘), 필요한 경우에 직접 관리해야 함
- 기본 XML만으로 서비스 개발 가능
- 별도의 개발 환경 지원이 필요 없음
전달 메커니즘 Remote Procedure Call Publish, Syndicate Pattern 전달 프로토콜 SOAP/HTTP, SMTP HTTP 서비스 명세 WSDL WADL, XML, JSON, hREST(시맨틱 REST) 등 서비스 레지스트리 UDDI 없음 필요 스택 W3C의 WS-*스택(WS-addressing, WS-security 등) 없음
동향
웹서비스가 진정한 차세대 e-비즈니스 프레임워크로 발전하기 위해서는 현재 웹서비스 개발 업체간의 많은 차이를 보이고 있는 웹서비스 범위, 개발언어, 다른 기업과의 연계 등 실질적인 구현 방법을 효율적으로 통합, 호환시키는 것이 가장 큰 문제로 대두되고 있다. 이를 위해 업체가 모여 개최한 웹서비스 상호운영성 포럼(Web Services Interoperability Forum)을 통해 웹서비스 구축시 사용되는 툴의 호환성을 테스트하였다. 하지만 이번 포럼에는 MS, IBM, HP, Oracle 등이 주도로 구성된 산업 컨소시엄인 WS-I(Web Services Interoperability)에 참여업체로만 이루어지고 가장 큰 대립 양상을 띄고 있는 Sun은 참여하지 않아 여전히 상호 운영성에 대한 문제는 해결될 여지를 보이고 있지 않다. 이렇게 개발 업체별로 상호운영성이 없는 소프트웨어를 개발하여 사용한다면 웹서비스의 본래 의지인 오픈 네트워크를 통한 이질적 시스템 통합 기능은 제 기능을 할 수 없을 것이다. 향후 웹서비스가 개발 업체간의 상호운영성을 확보하고 통합된 표준화에 합의한다면 W3C 및 OASIS 등 국제적 표준화 기구에서 만들어지고 있는 ebXML과 더불어 차세대 e-비즈니스 프레임워크로 자리잡을 수 있을 것이다.[2]
각주
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 웹서비스 개념 및 응용 서비스 동향 백서 - https://www.itfind.or.kr/WZIN/jugidong/1395/file55968-139502.pdf
- ↑ 2.0 2.1 웹서비스(Web Services) 현황 및 전망 백서 - http://letsweb.tistory.com/attachment/49618b2f6f084DK.pdf
- ↑ 3.0 3.1 3.2 3.3 3.4 SOAP 기반 웹서비스와 RESTful 웹서비스 기술 비교 백서 - https://ettrends.etri.re.kr/ettrends/122/0905001533/25-2_112_120.pdf
참고자료
- 웹서비스 개념 및 응용 서비스 동향 백서 - https://www.itfind.or.kr/WZIN/jugidong/1395/file55968-139502.pdf
- 웹서비스(Web Services) 현황 및 전망 백서 - http://letsweb.tistory.com/attachment/49618b2f6f084DK.pdf
- SOAP 기반 웹서비스와 RESTful 웹서비스 기술 비교 백서 - https://ettrends.etri.re.kr/ettrends/122/0905001533/25-2_112_120.pdf
같이 보기