웹서비스

웹서비스(web service)란 인터넷 웹사이트를 통해 제공하는 서비스를 말한다. 인터넷 정보 제공, 포털, 검색, 뉴스, 메일, 커뮤니티, 블로그, 채팅, 메신저, 쇼핑, 부동산, 증권, 뱅킹, 게임, 미팅, 교육, 사전, 책, 지도, 사진, 만화, 음악, 동영상, 가상현실 등 다양한 서비스를 제공한다. 웹서비스는 인터넷에서 단일한 비즈니스 또는 다수의 비즈니스 업체 간의 기존 컴퓨터 시스템 프로그램을 결합시키는 표준화된 소프트웨어 기술로서, 이러한 표준 기술을 이용해 모든 비즈니스 기능을 가능하게 하는 서비스이다.

개요

웹서비스란 SOAP(Simple Object Access Protocol)이나 WSDL(Web Service Description Language), UDDI(Universal Description, Discovery, and Integration) 등의 표준 기술을 이용하여 네트워크에 연결된 다른 컴퓨터 간의 분산 컴퓨팅을 지원하는 소프트웨어 및 기술이다. 웹서비스는 '웹'과 '서비스'라는 두 단어가 결합해 생겨난 용어인 만큼 단순하게 해석하면 웹을 통해 서비스를 교환하는 것이다. '웹'은 표준 방식으로 분산되어 있는 정보자원들을 공유하고 호환시키는 인터넷의 응용이다. 이는 전 세계적으로 정치, 경제, 사회, 산업 전반에 걸쳐 큰 변화를 가져왔다. '서비스란' 사용자에게 세부적인 사항은 감추고 추상적인 관점에서 제공되는 기능을 의미한다. 종합적으로 웹서비스는 분산되어 있는 콘텐츠를 서비스 형태로 추상화 시켜 표준 방식으로 연계하거나 공유하는 기술이다. 웹서비스의 초기 표준화 작업부터 지속적으로 참여해 온 아이비엠(IBM)은 웹서비스를 표준화된 XML(eXtensible Markup Language) 메세지를 통하여 네트워크로 접근 가능한 오퍼레이션들을 기술하는 인터페이스 라고 정의하고 있다.

등장배경

아이티(IT)는 놀라울 정도로 빠르게 발전하고 있으며, 이에 따라 수많은 개념이나 용어들이 등장하고 있다. RTE(Real Time Enterprise), 광대역통합망(BcN) 및 그리드 컴퓨팅에서 공유되고 있는 교집합적인 기술은 바로 웹서비스이다. 수년 전부터 사전적 용어로 사용되어 왔지만 한 단계 나아가 우리 생활에서, 없어서는 안 될 필수적인 서비스로 대두되었다. 그러나 웹서비스 환경에서 전자상거래를 수행할 때는 신뢰가 필요하다. 전자상거래에서의 믿음이란 트랜잭션의 믿음을 말하며 모임에 대한 믿음 그리고 통제 메커니즘의 믿음으로 나눌 수 있다. 전자는 개인 A가 예측하기를 개인 B가 어떤 행위를 할 주관적인 확률을 말한다. 한편, 후자는 객관적인 관점에서의 믿음을 말하며 개인이 그 내부 메커니즘을 이해하기 어렵다. 웹서비스에서 신뢰감을 형성하는 것은 중요한 문제다. 신뢰의 실체는 전자상거래의 기술적 요인과 인적 요인으로 나눌 수 있다. 기술적 요인은 보안성이 높은 암호화 기술을 개발하여 전자지불시스템에 도입하거나 방화벽과 같은 하드웨어를 보강하여 해킹당하는 일이 없도록 하는 것이다. 인적 요인은 시스템 개발자, 웹사이트 설계자, 전자 상점을 운영하는 사람, 상점주인, 상점을 이용하는 다른 사용자와 같이 전자상거래에 참여하는 사람들을 믿느냐는 것이다. 아무리 신뢰성 있는 시스템일지라도 그것을 운영하는 사람을 믿을 수 없다면 전자거래의 신뢰성은 무너지고 만다. 실제 전자 상점 주인이 자신의 개인정보를 목적 이외로 이용할 수도 있기 때문이다. 웹서비스는 이제 클라이언트 환경을 극복하고 차세대 컴퓨팅 시대를 여는 서막 역할을 하고 있다. 인터넷의 급속한 확산은 클라이언트 환경에 대한 문제를 해결하고자 하는 아이티 업계의 노력을 더욱 가속화하는 계기가 되었다.

특징

인터넷을 통한 웹서비스는 거래업체 간의 이질적인 운영시스템, 이질적인 프로그램언어 간의 커뮤니케이션 차이를 극복해주는 연결고리 역할을 해준다. 웹서비스의 기본적인 요소는 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은 마이크로소프트와 아이비엠 주도로 어느 정도 표준이 제정된 상태이고, WSDL(Web Services Description Language)은 호환성 문제가 논의되고 있다.

웹서비스는 클라이언트와 서버의 분리를 통해 플랫폼 중립과 독집적인 진화를 이룬다. 이것을 이루기 위해 서비스 프로바이더와 클라이언트는 각각의 노력을 한다. 먼저 서비스 프로바이더는 서비스의 구현과 클라이언트 간의 기능 결합도를 줄이기 위해 서비스의 스팩을 분리하여 서비스 API를 제공한다. 그럼 클라이언트는 API에만 의존하게 되고, 구현체와는 낮은 결합도를 가지게 된다. 그리고 클라이언트에서는 프록시에게 통신 관련 처리를 위임하여, 서비스와 URI 결합도와 데이터구조 결합도를 줄일 수 있다. 즉, 서비스의 위치가 변하거나 데이터구조가 변하여도 클라이언트 핵심 비즈니스 로직에는 영향이 미치지 않으며, 프록시만 재생성하여 적용할 수 있다. 그리고 웹서비스는 위치 투명성을 가진다. 웹서비스는 네트워크 공간에서 접근 가능 해야 하기 때문에 서비스만의 위치를 가지고 있다. 이것은 웹서비스의 특징 중 하나인 위치 투명성을 의미한다. 누구에게나 공개해야 한다는 의미가 아닌, 정확한 위치가 있다는 의미로 이해할 수 있다. 또 웹서비스는 전반적인 과정은 웹서비스 프레임워크가 도와준다. 웹서비스의 구현을 보다 쉽게 하기 위해서 훌륭한 웹서비스 프레임워크가 많이 등장했다. 즉, 웹서비스 프레임워크를 적절히 사용하면 내가 웹서비스를 구현하고 있는지 느끼지 못할 정도로 편리하다. WSDL의 생성과 적용된 OXM으로 메시지를 변환해서 SOAP에 담아 통신하는 과정까지 담당해주고 있다.

기술

요소

UDDI

다수의 웹서비스를 제공하는 소프트웨어 환경을 고려해 보면 웹서비스 검색 방법, 웹서비스 정보를 의미 있게 분류할 수 있는 방법, 지역화와 관련된 문제, 독점 기술이 미치는 영향검색, 메커니즘의 상호 운용성을 보장할 수 있는 방법과 같은 문제가 제기될 수 있다. 이러한 문제에 대응하기 위해 UDDI가 출현했다. 마이크로소프트, 아이비엠, 썬, 오라클, 콘파쿠, 에이치피, 인텔 및 에스에이피와 300개가 넘는 다른 회사를 비롯한 다양한 회사가 공동으로 이러한 문제를 해결하기 위해 개방형 표준과 비독점적 기술을 기반으로 한 사양을 개발하게 되었다. 그 결과 2000년 12월 베타 버전으로 시작되어 2001년 3월 제품으로 출시된 것이 전역 비즈니스 레지스트리이다. 이 레지스트리는 다양한 운영자 노드에서 운영되므로 사용자가 전혀 비용을 들이지 않고 웹서비스를 검색하고 게시할 수 있다. 최근 전자 정부의 UDDI를 일원화한 국가공인서비스등록저장소를 구축해 민원안내 등 기존 공통서비스의 재사용률을 높이는 방안도 추진하고 있다. 이를 위해 전자정부 표준 공통 서비스 및 개발 프레임워크 구축사업 내에서 서비스 데이터의 정합성을 확보하고 흩어져 있는 데이터를 단일 저장소로 통합하는 작업이 진행 중이다.

데이터 구조

• 비즈니스 개체 : 어떤 업체가 웹서비스를 하고자 한다면 제공자에 대한 비즈니스 정보를 알려 주어야 할 것이다. 즉 서비스를 제공한 업체 이름, 전화번호, 웹주소 같은 연락처 정보를 비롯하여 카테고리와 같은 기본 정보를 제공해야 한다. 이러한 기본적인 비즈니스 정보에 해당하는 것이 비즈니스 개체이다.

• 비즈니스 서비스 : 비즈니스 개체가 제공하는 서비스에 대한 정보이다, 제공되는 서비스에 대한 산업별, 제품별, 지역별 분류와 같은 정보, 서비스가 어떤 기능을 하는지에 대한 정보, 그밖에 비즈니스 프로세스나 서비스 집합에 관련된 논리적 서비스 분류 정보 등 서비스 정보를 제공하는 것이다.

• 바인딩 템플릿 : 비즈니스 서비스와 티모델(tModel) 사이의 사상을 담당하는 웹서비스를 위한 기술적인 정보다. 여기서 서비스를 찾기 위한 시작점을 제공하게 된다.

• 티모델(tModel) : 서비스들은 UDDI 데이터 모델에 따라 분류가 된다. 또한 여러 서비스들은 분류 기준과는 별도로 일정한 유형에 따라 그룹화될 수 있다. 티모델은 이런 분류 기준과 유형 기준을 관리하는 개체이다. 티모델을 따로 관리함으로써 서비스를 찾고자 할 때 분류별, 유형별로 검색이 가능하게 된다.

• 퍼블리셔 가정(Publisher Assertion) : 기업 간의 연관 관계를 부정하는 상황이 발생할 때, 공증서처럼 기업 간의 연관이 있음을 증명해 주는 역할을 수행하게 된다.

WSDL

WSDL은 비즈니스 서비스를 기술하여 비즈니스들끼리 전자적으로 서로 접근하는 방법을 제공하기 위해 사용되는 XML 기반의 언어이며 웹서비스 시스텀 기능들을 명세화시키는 방법을 표준화하기 위하여 만들어졌다. WSDL은 웹서비스 시스템에서 제공하는 기능들을 외부에서 이용할 수 있도록 사용법을 알려주는 인터페이스 언어로써, 코바(CORBA) 의 IDL(Interface Definition Language)에 해당한다. UDDI의 기초가 되는 언어로서 SOAP 와 NASSL(Network Accessible Service Specification Language)로부터 나왔다.

구문 분석

WSDL의 기본적인 형태는 아래와 같다.

 <wsdl:definitions>
   <wsdl:types>...</wsdl:types>
   <wsdl:message>...</wsdl:message>
   <wsdl:portType>...</wsdl:portType>
   <wsdl:binding>...</wsdl:binding>
   <wsdl:service>...</wsdl:service>
 </wsdl:definitions>

 <definitions name="EndorsementSearch"
    targetNamespace="(주소)"
    xmlns:es="(주소)"
    xmlns:esxsd="(주소)"
    xmlns:soap="(주소)"
    xmlns="(주소)"
 >
    <types>
      <esxsd:schema>
        <esxsd:import schemaLocation="EndorsementSearch.xsd" namespace="(주소)" 
 />
      </esxsd:schema>
    </types>

    <message name="GetEndorsingBoarderRequest">
      <part name="body" element="esxsd:GetEndorsingBoarder"/>
    </message>

    <message name="GetEndorsingBoarderResponse">
      <part name="body" element="esxsd:GetEndorsingBoarderResponse"/>
    </message>

    <portType name="GetEndorsingBoarderPortType">
      <operation name="GetEndorsingBoarder">
        <input message="es:GetEndorsingBoarderRequest"/>
        <output message="es:GetEndorsingBoarderResponse"/>
        <fault message="es:GetEndorsingBoarderFault"/>
      </operation>
    </portType>

    <binding name="EndorsementSearchSoapBinding"
             type="es:GetEndorsingBoarderPortType">
      <soap:binding style="document"
                    transport="(주소)"/>
      <operation name="GetEndorsingBoarder">
        <soap:operation
          soapAction="(주소)"/>
        <input>
          <soap:body use="literal"
            namespace="(주소)"/>
        </input>
        <output>
          <soap:body use="literal"
            namespace="(주소)"/>
        </output>
        <fault>
          <soap:body use="literal"
            namespace="(주소)"/>
        </fault>
      </operation>
    </binding>

    <service name="EndorsementSearchService">
       <documentation>snowboarding-info.com Endorsement Service</documentation> 
       <port name="GetEndorsingBoarderPort"
             binding="es:EndorsementSearchSoapBinding">
         <soap:address location="(주소)"/>
       </port>
       </service>

     </definitions>

• 타입(Type) : 웹서비스에서 사용될 타입을 정의한다. 위에서 타입이 보이지 않는 이유는 .xsd파일로 타입들은 따로 분리해서 import로 가져와서 쓰기 때문이다. 가끔 타입 태그 사이에 직접 기술할 때도 있다.

• 메세지(Message) : GetEndorsingBoarderRequest가 있고 GetEndorsingBoarderResponse가 있다. 요청 메세지와 리스폰 메세지를 정의한 것이다. 추가로 더 많은 메세지를 정의할 수도 있다. 그리고 메세지 태그 안에 part는 파라미터를 의미한다. 즉 body라는 이름으로 GetEndorsingBoarder타입의 파라미터가 사용될 것을 의미한다.

• 포트 타입(Port type) : 위의 두 메세지를 묶어서 하나의 함수로 만든다. 하나의 오퍼레이션으로 만들면서 <input>, <output>, <fault>가 존재하는데 이것은 input=Request, output=Response, fault=error(default)로 생각하면 된다. 즉 들어오는 메시지는 GetEndorsingBoarderRequest이고 return 되는 메시지는 GetEndorsingBoarderResponse 이며 실패시 GetEndorsingBoarderFault 메시지를 보낼 것이라고 정의한 것이다. 만약 output, input 순으로 되어있으면 웹서비스를 하는 서버가 먼저 클라이언트에게 메시지를 보내고 클라이언트에게 메시지를 받는 것을 의미하게 된다.

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 중 선택 할 수 있으며, 기업 간 이용에는 방화벽을 안전하게 통과 할 수 있다.

매시업

기술 분야에서는 복수의 소스에서 제공되는 콘텐츠를 조합한 복합형 소프트웨어를 만들거나, 복수의 응용들을 연계하여 새로운 응용 또는 사이트를 만들어내는 것을 의미한 다. 예를 들어 구글의 지도 서비스와 플리커의 사진 공유 서비스를 합치고, 여기에 위치 정보 등을 결합시키는 시도 등과 같이 기존 서비스를 융합시킨 하이브리드형의 새로운 서비스를 말한다. 최근 매시업은 다양한 분야에서 시도되고 있는데, 특히 구글과 아마존 등이 다양한 데이터와 온라인 지도를 간단히 통합할 수 있는 기능들을 제공하면서, 구글맵의 디지털 지도 분야 같은 경우 많은 성과를 거두었다. (글로벌 웹서비스중개사이트)Programmableweb의 통계에 따르면 지난 6개월 동안 매시업 서비스는 2배 이상 증가하여 현재 1,000개 정도의 매시업 서비스가 나왔고, 매일 적어도 3개 이상의 새로운 매시업 응용들이 등장하고 있다. 가트너는 2006년 보고서에서 웹 2.0 기술 중 에이잭스(AJAX)와 매시업이 기업에 가장 큰 영향을 줄 것이며, 앞으로 2년 이내에 성숙기에 이를 것이라고 예상했다. 이런 흐름은 SOA(Service Oriented Architecture)나 SaaS(Software as a Service)와 같은 서비스 중심의 소프트웨어 환경과 플랫폼 비즈니스(또는 API 기반 비즈니스) 모델의 성장과 함께 중요한 기술적인 동향들을 형성할 것으로 보인다. 그러나 아직 대규모 비즈니스 응용이나 상용 서비스 모델의 적용에 대한 문제, API 이용 과정에서의 QoS(Quality of Service)와 SLA(Service Level Agreement) 문제, API 변경에 따른 변경 관리의 문제 등과 같은 잠재적인 많은 이슈들을 안고 있는 상황이며, 이런 문제에 대한 연구개발이 진행될 것으로 예상된다.

REST

매시업 서비스가 가능하도록 하는 기본적인 요소는 REST, XML, SOAP 기반의 웹서비스, 그리고 XML-RPC, 그리고 RSS, Atom 등의 기술이 활용되는 Open API 기술에 있다. 이중 REST는 HTTP와 URI 표준 개발자 중 하나인 로이 필딩(Roy Fielding)에 의해 2000년에 제안된 것으로, 프로토콜이나 규격이 아닌 하나의 아키텍처 스타일로 초기 웹의 구조와 동일하게 HTTP와 URI에 기반하여 자원을 중심으로 자원의 상태를 변화시키는 관점으로 설계하는 방식을 말한다. 여기서 자원에 대한 요청은 얻다(GET), 뒤에(POST), 넣다(PUT), 삭제(DELETE)와 같은 HTTP 요청으로 표현되며, 이런 요청을 통해 자원에 대한 접근과 상태 변화 등이 가능하도록 하는 방식이다. REST 구조의 응용들은 SOAP과 같은 복잡한 메시징을 사용하지 않고, XML+HTTP의 형태를 사용하므로 4~10배 정도의 빠른 속도의 처리들이 가능하다는 장점을 갖고 있어 구글, 아마존 등의 많은 Open API 응용에서 사용되고 있다.

XML-RPC

XML-RPC와 웹서비스는 모두 XML 기반의 메시징을 한다는 특징을 갖고 있다. 최근 REST 기반의 구조들이 보편화하면서 다시 활용이 증대하고 있는 XML-RPC는 RPC(Remote Procedure Call) 프로토콜의 일종으로, RPC요청을 XML 기반으로 인코딩하고 HTTP 전송 프로토콜로 보내고, 이를 해석하여 처리하는 방식이다. 1998년 당시 Microsoft에 Dave Winer가 만든 것으로, 이후 XML-RPC를 확장한 표준이 웹서비스 메시징의 기본 표준인 SOAP이다. XML-RPC는 HTTP 기반으로 간단한 XML 처리만으로도 타 시스템의 기능들을 호출하고 연계할 수 있다는 장점을 갖고 있어 다양한 시스템에서 연동 방법으로 활용되고 있다. 반면 확장성과 보안의 문제점이 있으며, HTTP 자체가 갖고 있는 성능상의 제약과 같은 문제를 그대로 갖게 되는 단점들을 갖고 있다. WSDL과 SOAP으로 대표되는 웹서비스 기술은 서비스 제공 방식의 변화를 촉발했던 중요한 초기 기술 중 하나이다. 초기에는 다양한 비즈니스 응용들과 서비스들을 연동하기 위한 목적에서 개발되었으나, 다양한 디바이스와 네트워크 환경에서의 응용들을 연동하고 시스템을 연동하기 위한 표준기술이 되었다. 초기의 단순한 웹서비스 모델을 확장하고 다양한 인터랙션에 대한 처리를 효과적이고 빠르게 할 수 있도록 하기 위한 SOAP MTOM, XOP 등에 대한 표준 개발, 웹서비스에 대한 접근과 관리를 효과적으로 하기 위한 WS-Addressing, WS-Eventing, WS-Policy, WS-ReliableMessaging, WSDM(Web Services Distributed Management) 표준 개발, 다양한 비즈니스 프로세스 및 응용들과 효과적으로 연동될 수 있도록 하기 위한 WS-CDL, BPEL4WS 표준 개발, 유비쿼터스 환경에서의 서비스와 디바이스 연동을 위한 UWS(ubiquitous web services) 기술, 웹서비스 기반의 포털을 위한 WSRP(Web Server for Remote Portlets) 등과 같은 다양한 확장 표준과 기술 개발이 진행되고 있다.

보안

XML정보보호

XML 정보보호 기술은 웹서비스 보안기술의 바탕이 되는 핵심 보안 기술로 XML 문서에 대한 전자서명 생성 및 검증 기능을 지원하는 XML 전자서명, XML 문서에 대한 암호화 및 복호화 기능을 제공하는 XML 암호화 기술, XML 기반의 키 관리 기능을 제공하는 XML 기반 키 관리 기술, 서비스 요청 객체에 대한 인증, 인가 속성 정보를 교환하기 위한 보안 정보교환 기술 및 보안이 요구되는 자원에 대해 XML 기반의 접근제어 서비스를 제공하는 XML 기반 접근제어 기술 등으로 구성된다.

전자서명

XML 전자서명은 XML을 비롯한 다양한 형태의 전자문서에 대해 XML 형태의 전자서명을 생성하고 검증할 수 있는 XML 기반의 전자서명 기법이며, 전자문서에 대한 인증, 무결성, 부인봉쇄 등의 정보보호 기능을 제공해 줄 수 있다. XML 전자서명에서는 서명된 결과가 XML 문서 형식으로 생성되어 XML 기반 애플리케이션에 통합이 용이하고, 알고리즘 식별자가 사용자와 애플리케이션에서 이해하고 처리하기 쉬운 URI 형식으로 저장된다. 또한 전자서명과 관련된 정보가 사용자와 애플리케이션에서 처리하기 쉬운 텍스트 형태의 XML 노드 형태로 생성되어 이에 대한 처리가 쉽다. XML 전자서명은 XML 데이터뿐만 아니라 어떠한 디지털 콘텐츠에도 적용이 가능하다. XML 전자서명은 다수의 리소스에 대한 전자서명을 한꺼번에 처리하여 하나의 전자서명 문서로 나타낼 수 있으며, XML 전자문서에 대해서는 문서 전체에 대한 전자서명뿐만 아니라 XML 문서의 특정 부분에 대해서도 전자서명을 할 수 있어 효율적인 전자서명 처리가 가능하다.

암호기술

XML 암호화는 XML 문서의 내용이 의도된 사용자에게만 구별 가능하고, 그 외의 사람들에게는 알기 힘들게 XML 문서를 암호화하는 방법을 기술한다. W3C XML 암호화 작업 그룹은 XML 문서와 그 일부분을 포함한 디지털 콘텐츠를 암호화, 복호화하는 절차를 개발하고, 의도된 사용자만이 복호화할 수 있도록 정보들과 암호화된 내용을 표시하는 데 사용하는 XML 구문을 정의한다. XML 암호화는 전달되는 정보뿐 아니라 저장된 정보에 대해서도 기밀성을 제공한다. 기존의 SSL이나 TLS, VPNs(Virtual Private Networks) 같은 기술들은 정보 전달 시만 기밀성을 제공해주고 저장된 형태의 문서에 대한 기밀성은 제공하지는 않는다. 암호화는 양이 많은 문서를 효과적으로 암호화하기 위해 대칭 키를 사용하여 수행된다. 대칭 키는 복호화를 위해 암호화한 키와 동일한 키를 사용해야 한다. 대칭 키를 공유하기 위해 XML 암호화 표준에서는 암호화에 사용된 대칭 키를 공개 키 암호화를 사용하는 방법을 사용하여 대칭 키를 상대방에게 전달한다. 공개 키 방식은 상대방의 공개 키를 사용하여 암호화에 사용된 대칭 키를 암호화하여 암호문과 같이 전달하여, 상대방이 자신의 개인 키로 대칭 키를 복호화하여 문서 복호화에 사용하도록 한다.

키 관리 기술

키 관리 기술은 W3C에 의하여 주도적으로 표준화가 진행되고 있는 XML 키 관리 명세이다. W3C는 마이크로소프트와 베리사인(Verisign), 웹 방법론(Web Methods)이 공동 개발하고, 볼티모어(Baltimore), 앤트러스트 테크놀로지스(Entrust Technologies), 씨티그룹(Citigroup), 아이비엠(IBM, 아이오나 테크놀로지스(IONA Technologies), 퓨어에지솔루션(PureEdge Solution), 휼렛패커드(Hewlett Packard), 로이터 유한회사(Reuters Limited) 등이 웹 표준으로 제출한 XML 키 관리 명세서를 승인하고 워킹 그룹을 구성하여 표준화를 진행하고 있다. W3C의 키 관리 기술 워킹그룹은 클라이언트가 웹 서비스로부터 키 정보(키 값, 인증서, 관리 혹은 신뢰 데이터)를 얻도록 XML 애플리케이션과 프로토콜 명세를 개발하는 일을 한다. XKMS는 키의 등록, 키 정보의 해결이나 유효성 검증 등의 서비스 인터페이스와 프로토콜을 정하고 있으며, XML 기반의 공개키 관리를 위한 프로토콜로 공개키의 효율적인 공유 기능을 제공한다. XML 암호화, XML 전자서명, WS-Security, SAML(Security Assertion Markup Language) 등은 많은 부분에서 공개키 기반구조(PKI)에 의존하고 있는데 기존의 공개키 기반구조를 이용하기 위해서는 복잡한 데이터 구조나 API를 구현해야 한다. 이를 웹서비스를 통해 해결하고 이용 가능하게 하는 것이 키 관리 기술의 목적이다. XKMS는 XML 키 정보 서비스(XKISS)와 XML 키 등록 서비스(XKRSS)로 구분된다. 키 정보 서비스는 XML 전자서명에 포함된 공개키 정보의 실제 내용인 인증서 정보, 공개키 매개변수, 인증서 폐지정보, 유효성 상태 정보 등을 전송하는 데 사용되며, 키 등록 정보 서비스는 클라이언트가 이러한 공개키 정보를 신뢰할 수 있는 인증 기관에 등록 또는 폐기, 갱신 등을 요청하는 데 사용된다.

접근제어 기술

XML 기반 접근제어 기술은 OASIS에서 표준화가 진행되고 있으며, 2003년 1월에 XACML V1.0이 OASIS 표준으로 채택된 상태이며, 현재는 V2.0에 대한 표준화가 진행되고 있는 상태이다. 그 밖에 XACML과 관련된 여러 프로파일들도 표준화가 진행되고 있다. XACML은 XML 정보보호기술 중의 하나로서 자원들 혹은 접근 요청 개체들에 권한 부여(authorization)를 통해 자원들에 대한 접근 제어(access control)를 하는 XML 기반의 언어이다. 또한, 다양한 접근제어 제품들에게 일관되게 적용될 수 있는 권한 부여 정책들을 위한 통합 언어를 제공함으로써 광범위한 관리 및 권한 부여 제품들에게 상호운용성을 제공한다. XACML은 특정 자원에 접근하기 위해 전송되는 요청자의 속성들을 안전 한 메커니즘들과 결합시켜 웹 서비스, J2EE 및 다른 전자상거래 환경들의 권한 부여 인프라를 구성하게 하는 요소기술이기도 하다. 현재 파르테논 컴퓨팅(Parthenon Computing), 썬 마이크로 시스템즈(Sun Micro systems), 레거시 시스템(Lagash Systems) 등에서 XACML 버전 1.0 및 1.1 제품들을 개발하여 호환성 테스트를 진행하고 있다.

보안 프레임워크

웹서비스 보안 프레임워크 기술은 웹서비스의 핵심 보안 기술로 XML 정보보호 기술을 기초 기술로 가지며, SOAP 기반의 안전한 웹서비스 메시지 교환을 위한 웹서비스 메시지 보안 기술(WSSecurity), 웹서비스 응용에 대한 보안 정책의 생성과 교환을 위한 웹서비스 보안 정책 기술(WSPolicy), 개인의 프라이버시 선호도와 응용 정책 교환에 대한 웹서비스 프라이버시 보호 기술(WSPrivacy), 상이한 보안 체계에 속한 웹서비스 응용들 간의 인증 및 인가를 가능하게 하는 웹서비스 신뢰 관리 기술(WS-Trust) 등 및 그 밖의 다양한 기술들로 구성된다.

메세지 보안

웹서비스의 메시지 교환 프로토콜인 SOAP을 기반으로 하며 인증, 무결성, 부인봉쇄, 기밀성 등의 보안 기능을 확장하여 제공하는 웹서비스 보안의 핵심이 되는 기술로 2004년 OASIS에서 표준으로 채택된 기술로 W3C의 XML 전자서명 및 XML 암호를 확장하여 적용 및 공개키 등의 보안 정보를 교환하기 위해 다양한 형태의 보안 토큰(security token)을 지원한다. 재전송 공격(replay attack) 등을 방지하기 위해 타임 스탬프(timestamp) 관련 기능 및 멀티 홉(multi-hop)을 거쳐 전달되는 SOAP 메시지의 안전한 단대단(end-to-end) 전송 기능을 포함한다. X.509 Certificate Token Profile은 X.509 인증 프레임워크를 WS-Security에 적용하기 위한 구문과 처리 규칙을 규정하고, username token profile은 웹서비스 사용자가 사용자 ID(username)로 웹서비스 제공자에게 인증받기 위한 처리 방법을 규정하며, 이밖에 security token과 관련된 다수의 프로파일들이 표준화 진행 중으로 아직 드래프트 상태이다.

신뢰관리

IBM과 Microsoft 등의 산업체 공동 작업을 통해 2004년에 WS-Trust V1.1이 발표되었으며 WSSecurity에서 제공되는 보안 메시지를 위한 기본 메커니즘을 기반으로 구현되어 다양한 신뢰 도메인 내에서 보안 토큰의 발행 및 교환 방법과 신뢰 관계의 존재 설정 및 액세스 방법에 대한 확장을 정의한 기술이다. 이 확장을 사용하여 응용 프로그램은 WSDL 서비스 설명, UDDI business-services와 bindingtemplates 및 SOAP 메시지를 비롯한 일반 웹 서비스 프레임워크와 함께 작동하도록 디자인된 보안 통신에서 작업이 가능하며, 이를 위해 이 명세는 보안토큰을 요청하고 신뢰 관계를 관리하는 데 사용되는 많은 헤더와 요소를 제공한다.

보안 정책

웹서비스의 정책을 설명하고 전달하기 위한 범용모델과 해당 구문을 제공하는 명세로, BEA, IBM, Microsoft, SAP이 함께 공동으로 제정, 여기에서 정책은 보안, 신용, 트랜잭션, 사생활 보호 등이 포함된 포괄적인 용어를 의미한다. 이 기술은 다른 웹서비스 사양에서 광범위한 서비스 요구 사항, 우선순위 및 기능을 설명하기 위해 사용하고 확장할 수 있는 기본 구문 집합을 정의하고 있다.

통신키 관리

보안 컨텍스트의 생성과 공유 등을 위한 프로토콜과 기능을 설명하는 명세로, IBM과 Microsoft 등의 산업체 공동 작업을 통해 2004년 WS-Secure Conversation V1.1이 발표되었다. 보안 컨텍스트 설정과 공유, 세션 키 파생을 가능하게 하는 확장 기능을 제공하며, 메시지 인증 모델에 중점을 두었고, WSTrust가 전체적인 신용 관계 작동을 정의한다면, 이 명세는 통신 보안 측면에서 보안을 정의한다.

비교

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을 지원하고 있다.

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 웹서비스화 되어 동시에 제공되는 추세이다.

서비스 구조

SOAP 기반 웹서비스가 SOA 구조에 따라 UDDI 레지스트리를 통해 웹서비스를 등록하고, 탐색하고, 바인딩하여 이용한다면, RESTful 웹서비스는 리소스를 등록하고 저장해두는 중간 매체 없이 리소스 제공자가 직접 리소스 요청자에게 제공하는 방법을 따르고 있다. 서비스 실행 관점에서, SOAP 기반 웹서비스에서는 서비스 제공자와 요청자 간에 SOAP 프로토콜로 메시지를 주고받는 방식으로 서비스를 이용한다. 즉, 서비스 요청자가 웹서비스 요청을 SOAP으로 인코딩하여 서비스 제공자에게 전달하면, 서비스 제공자는 이를 디코딩하여 적절한 서비스 로직을 통하여 결과를 얻고, 그 결과를 다시 SOAP 인코딩하여 서비스 요청자에게 반환한다. 한편, RESTful 웹서비스는 기본 HTTP 프로토콜의 메소드 GET, PUT, POST, DELETE를 이용하여 다양한 형태로 표현된(JSON, XML, RSS 등) 리소스를 직접 실어 나른다.

서비스 기술

SOAP 기반 웹서비스의 요구가 기업의 비즈니스 환경에서 응용 서비스 간 상호 운용을 위해 시작된 데 비해, RESTful 웹서비스는 인터넷 서비스 업체들이 응용 개발자들에게 손쉬운 데이터 제공을 목적으로 출발했다. 따라서 SOAP 기반 웹서비스는 서비스를 제공하고 이용하는 프로그램들이 잘 이해할 수 있도록 엄격한 문법에 따라 개발되었고, 때문에 개발자들에게는 웹서비스 기본 스펙을 알아야 하는 비교적 고난이도의 프로그래밍 능력이 요구되었다. 따라서 SOAP 기반 웹서비스 개발의 편의성을 도모하기 위해 다양한 개발 환경들이 지원되고 있다. 반면 RESTful 웹서비스는 기계보다는 사람이 이해하기 쉽도록 인터넷 기본(HTTP와 XML) 이외에 별도의 개발, 실행 환경을 필요로 하지 않는다. 특히 RESTful 웹서비스를 제공하는 인터넷 서비스 업체들은 무료로 이용할 수 있는 서비스 매시업 환경을 함께 제공하고 있어 개발자폭이 널리확대되고 있다. 그러나 RESTful 웹서비스의 인기를 주도한 이유였던 인터넷 기본 외 별도의 표준을 요구하지 않는다는 특성이, 개발 및 관리를 어렵게 만드는 문제를 파생하게 되었다. 데이터에 대한 의미 자체가 비즈니스의 필수 요건이 아니었기 때문에 서로 데이터를 전송할 수 있는 정도의 상호 이해 수준의 표준만이 요구되었을 뿐 산업계 표준이 필요하지 않았다. 현재 REST의 산업계 표준이 없다 보니 개발에 있어서 여러 가지 문제점이 드러나게 되었다. 표준이 없는 경우에는 자체 스펙을 정하거나 유사 표준을 따라야 하는데, 자체 스펙을 정하는 것이 쉽지 않을뿐더러 REST에 대한 잘못된 이해로 인한 잘못된 유사 표준들이 등장하는 경우도 발생하였다. 따라서 표준과 개발 인프라가 잘 갖추어진 SOAP 기반 웹서비스에 비해, RESTful 서비스는 표준과 개발 인프라에 얽매이지 않는 대신 서비스와 시스템도 REST 개념에 맞는 설계가 필요하다.

시맨틱 기술

시맨틱 웹서비스란 인터넷에 개발된 수많은 웹서비스를 보다 의미적으로 활용하기 위하여 시맨틱 기술을 도입한 웹서비스를 의미하며, 웹서비스에 다양한 의미 정보를 부가하여 궁극적으로 의미적 검색을 통한 동적 서비스 조합을 실현하는 데 필요한 요소 기술이다. 머지않은 미래에 인터넷의 수많은 서비스 중 사용자의 의도와 목적에 꼭 맞는 서비스를 손쉽게 찾고 또는 즉시 새로 만들어 사용할 수 있는 서비스 환경이 도래할 것이며, 이때 시맨틱 웹서비스 기술이 견인차 역할을 하게 될 것이다. 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-SVM을 이용한 접근 방법들이 시도되고 있다. 또한 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의 경우 마이크로WSMO(Web Service Modeling Ontology)에 대한 연구가 있지만, SOAP 기반 웹서비스에서의 시맨틱 기술 도입 연구에 비해 연구 범위나 기술 표준화 상황이 미진한 상황이다. 전반적으로 기능적(functional), 비기능적(nonfunctional), 행위적(behavioral), 정보(informational) 시맨틱 기반의 반자동 어노테이션 기법과 검색 기술들이 일부 연구되고 있으나, RESTful 웹서비스의 중재 및 컴포지션 기술에 대해서는 시맨틱 기술 도입의 관심이 필요한 시점이다. 이는 RESTful 웹서비스 구현에 관한 표준기술이 부재하여 구현기술의 제약이 없으므로 다양한 기술로 빠르게 인터넷에 전파되는 장점이 있지만, 반대로 구현 기술의 다양성이 RESTful 웹서비스에 시맨틱 기술을 적용하기 위한 본격적인 연구가 늦어지는 주요 원인으로 분석된다.

서비스 기술 비교

비교	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 등)	없음

용어정리

• ROA(Resource Oriented Architecture) : 인터넷의 모든 콘텐츠(예, HTML, 텍스트, 이미지, 이메일 등)를 리소스로 활용하기 위한 구조로서 REST가 지향하는 서비스

구조이며, 서비스 중심의 SOA(Service Oriented Architecture)와 대비되는 개념으로 주로 사용된다.

• 시맨틱 웹서비스 : 웹서비스에 시맨틱 웹을 접목시킨 기술로서, 온톨로지를 활용하여 웹서비스의 비기능적, 기능적, 정보적, 행위적 특성을 부가적으로 명세(description)함으로써 궁극적으로 웹서비스 검색, 조합, 중재 과정을 자동화, 정교화하기 위한 기술

이다.

사례

경찰청 : 경찰청의 미아 정보를 한국복지재단, 포탈업체 등의 관계기관과 신속하고 효율적으로 공유하며 미아 정보를 일괄 등록, 검색 및 현황 조회가 가능한 종합 미아 정보관리 웹서비스 시스템 구축을 위해 웹서비스를 도입했다. 도입 후, 웹서비스 기술을 활용한 미아 정보 공유 서비스 구축을 통해 미아 발생 정보 등록 및 미아 찾기 관련한 업무를 지원하여 미아 찾기게 대한 국가적, 사회적 책임을 다하고 서비스를 실현하였고, 사전 미아 예방 컨텐츠 및 프로그램 확산 및 공유를 통한 원천적 미아 발생을 예방하는 효과를 보였다.

• 기상청 : 방재, 수문, 환경, 교통, 농수산, 국방기관, 민간예보사업자, 연구기관 등의 관계기관의 방재업무 사전예방 및 신속한 대응을 위한 웹서비스 적용 방재 기상정보 지원체계 구축을 위해 웹서비스를 도입했다. 도입 후, 웹서비스 표준을 활용한 일관된 통합, 연계 모듈을 제공하여 관계기관 접근, 활용의 단순화와 웹서비스 기반환경 조성이 가능한 효과를 보였다.

동향

웹서비스가 진정한 차세대 e-비즈니스 프레임워크로 발전하기 위해서는 현재 웹서비스 개발 업체 간의 많은 차이를 보이고 있는 웹서비스 범위, 개발언어, 다른 기업과의 연계 등 실질적인 구현 방법을 효율적으로 통합, 호환시키는 것이 가장 큰 문제로 대두되고 있다. 이를 위해 업체가 모여 개최한 웹서비스 상호운용성 포럼(Web Services Interoperability Forum)을 통해 웹서비스 구축 시 사용되는 툴의 호환성을 테스트하였다. 하지만 이번 포럼에는 마이크로소프트, 아이비엠, 에이치피, 오라클 등이 주도로 구성된 산업 컨소시엄인 WS-I(Web Services Interoperability)에 참여업체로만 이루어지고 가장 큰 대립 양상을 띄고 있는 썬은 참여하지 않아 여전히 상호 운용성에 대한 문제는 해결될 여지를 보이고 있지 않다. 이렇게 개발 업체별로 상호운용성이 없는 소프트웨어를 개발하여 사용한다면 웹서비스의 본래 의지인 오픈 네트워크를 통한 이질적 시스템 통합 기능은 제 기능을 할 수 없을 것이다. 향후 웹서비스가 개발 업체 간의 상호운용성을 확보하고 통합된 표준화에 합의한다면 W3C 및 오아시스 등 국제적 표준화 기구에서 만들어지고 있는 ebXML과 더불어 차세대 e-비즈니스 프레임워크로 자리잡을 수 있을 것이다.

참고자료

• 웹서비스 개념 및 응용 서비스 동향 백서 - https://www.itfind.or.kr/WZIN/jugidong/1395/file55968-139502.pdf
• 웹서비스(Web Services) 현황 및 전망 백서 - http://letsweb.tistory.com/attachment/49618b2f6f084DK.pdf
• 〈알고보면 쉬운 웹서비스〉, 《넥스트리》, 2014-09-29
• 정아마추어, 〈웹애플리케이션 서비스가 아닌 웹서비스(WebService), WSDL을 아시나요? (WSDL 문법, 구조, 구문 분석)〉, 《티스토리》, 2018-05-16
• 웹 2.0 기술 현황 및 전망 백서 - https://ettrends.etri.re.kr/ettrends/101/0905000727/21-5_141_153.pdf
• 웹서비스 보안 기술의 표준화 및 시장 동향 백서 - https://ettrends.etri.re.kr/ettrends/91/0905000565/20-1_043_053.pdf
• SOAP 기반 웹서비스와 RESTful 웹서비스 기술 비교 백서 - https://ettrends.etri.re.kr/ettrends/122/0905001533/25-2_112_120.pdf
• 웹서비스 구현 사례 백서 - file:///C:/Users/C452/Downloads/%EC%9B%B9%EC%84%9C%EB%B9%84%EC%8A%A4_%EA%B5%AC%ED%98%84%EC%82%AC%EB%A1%80.pdf

같이 보기

• 웹
• 소프트웨어
• 프로그램
• 아이비엠

이 웹서비스 문서는 인터넷에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍, 소프트웨어, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷 □■⊕, 모바일, 사물인터넷, 게임, 메타버스, 디자인 인터넷 PC통신 • 그누텔라 • 네트워크 • 다크넷 • 다크웹 • 딥웹 • 무선인터넷 • 슈퍼피어 • 스타링크 • 아르파넷 • 아이투피(I2P) • 엑스트라넷 • 오버레이 네트워크 • 오투오(O2O) • 오프라인 • 온라인 • 온오프라인 • 유선인터넷 • 인터넷 • 인트라넷 • 초고속 인터넷 • 토어(토르) • 표면웹 • 프리넷 • 피투피(P2P) • 하이브리드 피투피(P2P) • 홈네트워크 인터넷 기술 ARP • DNS • FTP • G-클라우드 • HTTP • HTTPS • IPFS • IPv4 • IPv6 • IRC • IRI • ISBN • LDAP • MOIP • OpenSSL • OSI 7 계층 • RFC • RFID • SFTP • SOAP • SSH • SSL • SSO • TCP • TCP/IP • TLS • UCI • UDP • URI • URL • URN • VoIP • 강화 내부 게이트웨이 라우팅 프로토콜 • 검색 • 검색엔진 • 게이트웨이 • 경계 경로 프로토콜 • 내부 게이트웨이 라우팅 프로토콜 • 다운로드 • 데몬 • 라우팅 정보 프로토콜 • 백엔드 • 사물인터넷 • 서버 • 서버-클라이언트 • 서브넷마스크 • 세션 • 스트리밍 • 식별자 • 아이피(IP) • 업로드 • 에듀테크 • 온프레미스 • 원격 프로시저 호출(RPC) • 유비쿼터스 • 인터넷 기술 • 자율시스템 • 정보기술 • 정보통신 • 채팅 • 챗봇 • 최단경로 우선 프로토콜(OSPF) • 쿠키 • 크롤링 • 클라이언트 • 키워드 • 텔넷 • 토폴로지 • 트래픽 • 패킷 • 포털 • 포트 • 프런트엔드 • 프로토콜 • 프록시 • 해시태그 이메일 IMAP • POP3 • SMTP • 계정메일 • 네이버 메일 • 다음 메일 • 센드메일 • 스팸 • 스팸메일 • 스팸필터링 • 아웃룩 익스프레스 • 야후 메일 • 웹메일 • 이메일 • 지메일 • 카카오 메일 • 한메일 • 핫메일 웹 KWCAG • WCAG • 서핑 • 시맨틱 웹 • 오프라인 웹 • 웹 • 웹 1.0 • 웹 2.0 • 웹 3.0 • 웹개방성 • 웹서비스 • 웹접근성 • 웹접근성 인증마크 • 웹주소 • 웹표준 • 웹호환성 • 피드 웹사이트 BBS • GNB • LNB • UI/UX • 게시판 • 관리자 사이트 • 그래픽 사용자 인터페이스(GUI) • 누리집 • 대시보드 • 드롭다운 메뉴 • 랜딩 템플릿 • 랜딩 페이지 • 리더보드 • 마이홈피 • 메뉴 • 모달창 • 미니홈피 • 방명록 • 배너 • 사용자 경험(UX) • 사용자 인터페이스(UI) • 섹션 • 왼쪽메뉴 • 웹기획 • 웹사이트 • 웹페이지 • 인터페이스 • 쪽지 • 커뮤니티 • 탑메뉴 • 탭메뉴 • 템플릿 • 팝업 • 페이지 • 페이지뷰 • 햄버거 메뉴 • 호버 • 홈페이지 • 화면 웹브라우저 넷스케이프 • 모자이크 • 브라우저 • 브레이브 브라우저 • 블록체인 브라우저 • 사파리 • 삼성인터넷 • 스윙 • 엣지 • 오시리스 • 오페라 • 웨일 • 웹브라우저 • 인터넷 익스플로러(IE) • 크롬 • 파이어폭스 • 판도브라우저 인터넷 서비스 구글 • 구글 미트 • 구글챗 • 구글 행아웃 • 깃허브 • 네아로 • 네이버 • 네이버 웹툰 • 네이버 카페 • 넷플릭스 • 다음 • 라이코스 • 레진코믹스 • 메일루 • 멜론 • 바이두 • 바이트댄스 • 비트토렌트 • 빌리빌리 • 빙 • 소리바다 • 스포티파이 • 아마존 웹서비스(AWS) • 애플 • 야후 • 야후재팬 • 얀덱스 • 에버노트 • 에어비앤비 • 왓챠 • 웹소설 • 웹툰 • 유튜브 • 인스타툰 • 인터넷 서비스 • 인터넷카페 • 잼라이브 • 줌 • 카카오 • 카카오 웹툰 • 카카오페이지 • 탑툰 • 텐센트 • 팟캐스트 • 패스 • 페이오니아 • 페이팔 • 해시넷 • 화상통화 • 화상회의 인터넷쇼핑 11번가 • 그립 • 네이버 쇼핑 • 네이버 쇼핑 라이브 • 라이브방송 • 라이브커머스 • 모바일쇼핑 • 스쉐라이브 • 스타일쉐어 • 아마존 • 알리바바 • 오픈마켓 • 옥션 • 온라인쇼핑 • 위메프 • 이베이 • 인터넷쇼핑 • 인터파크 • 전자상거래 • 지마켓 • 징동닷컴 • 카카오 쇼핑 • 카카오 쇼핑 라이브 • 커머스 • 쿠팡 • 쿠팡 라이브 • 타오바오 • 티몬 소셜 네트워크 SNS(소셜 네트워크 서비스) • 구글 블로거 • 네이버 밴드 • 네이버 블로그 • 디시인사이드 • 링크드인 • 마이크로블로그 • 맞팔 • 브런치스토리 • 블로그 • 소셜 네트워크 • 엑스 (트위터) • 웨이보 • 인스타그램 • 트루스소셜 • 티스토리 • 팔로우 • 페이스북 • 플리커 • 핀터레스트 메신저 골프메신저 • 님버즈 • 대화방 • 두레이 • 디스코드 • 딩톡 • 라인 • 라인웍스 • 마이크로소프트 팀즈 • 메신저 • 버디버디 • 스냅챗 • 스노우 • 스카이프 • 슬랙 • 아이씨큐(ICQ) • 왓츠앱 • 웹메신저 • 위챗 • 잔디 • 직톡 • 카카오워크 • 카카오톡 • 카톡방 • 큐큐(QQ) • 탱고 • 텔레그램 • 틱톡 • 페이스북 메신저 • 플로우 도메인 네임서버 • 다국어도메인 • 도메인 • 레지스트라 • 레지스트리 • 아이피 • 인터넷주소 • 인터넷키워드 • 한글인터넷주소 • 후이즈 호스팅 메일호스팅 • 서버호스팅 • 웹호스팅 • 코로케이션 • 클라우드 • 클라우드 네이티브 • 파킹 • 포워딩 • 호스팅 위키 구스위키 • 나무위키 • 노스모크 • 더위키 • 디시위키 • 리그베다위키(엔하위키) • 리브레위키 • 미디어위키 • 바다위키 • 백괴사전 • 아이티위키 • 알파위키 • 엔하계 위키 • 요다위키 • 우만위키 • 위키 • 위키낱말사전 • 위키독스 • 위키문법 • 위키문서 • 위키문헌 • 위키미디어재단 • 위키백과 • 위키스 • 위키엔진 • 위키원 • 위키원드 • 위키트리 • 위키휴가 • 제이위키 • 제타위키 • 중국위키 • 팬덤(위키아) • 한국어 위키백과 • 한국위키미디어협회 • 항공위키 인터넷 사용자 가입 • 가입자 • 강퇴 • 계정 • 관리자 • 네트워크 관리자 • 네티즌 • 누리꾼 • 대기자 • 데이터베이스 관리자 • 등록자 • 디지털 원패스 • 로그아웃 • 로그인 • 방문자 • 방장 • 블로거 • 블록체인 관리자 • 비회원 • 사용자 • 사이트 관리자 • 서버관리자 • 시삽 • 시스템 관리자 • 아이디(ID) • 운영진 • 웹관리자 • 웹마스터 • 유튜버 • 접속자 • 차단 • 최고관리자 • 탈퇴 • 탈퇴자 • 회원 • 회원제 • 휴면 • 휴면계정 인터넷 단체 IANA • ICANN • W3C • 다르파 • 유럽입자물리연구소(CERN) 위키 : 자동차, 교통, 지역, 지도, 산업, 기업, 단체, 업무, 생활, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반