1. 웹 서비스의 탄생
컴포넌트 기반의 대표적인 분산 컴퓨팅 모델로서는 CORBA, DCOM, RMI 프로토콜이 있으며, 이런 분산 컴퓨팅 모델의 대부분은 RPC(Remote Procedure Call)를 시발점으로 하고 있다.
즉 아무리 방법론적이나 기술적으로 향상된 분산 컴퓨팅 모델이라고 해도 기본적인 구조와 메커니즘은 RPC에서 벗어나나지 않는다는 의미이다.
< 용어 >
분산 컴퓨팅
컴퓨터 프로그램이나 데이터가 네트워크 상에, 즉 대개 두 대 이상의 컴퓨터에 걸쳐 있는 경우로서,
화면 구성 및 단순한 데이터의 입출력은 클라이언트에서 수행하고 비즈니스 로직 및 저장 기능은 여러 서버에서 수행하는 컴퓨팅 모델을 의미한다.
컴포넌트
하나의 객체 또는 여러 개의 객체로 구성된 재사용이 가능한 소프트웨어 단위를 의미하는 것으로,
하나의 애플리케이션을 형성하기 위해 같은 컴퓨터에 있거나 또는 네트워크 상의 다른 컴퓨터에 있는 컴포넌트들과 조합될 수 있다.
이것은 네트워크 상에 있는 다른 서버들로 배포될 수 있으며, 필요한 서비스를 위해 서로 통신할 수 있다.
RPC (원격 프로시저 호출)
한 프로그램이 네트워크에서 물리적으로 다른 컴퓨터에 위치한 프로그램에게 서비스를 요청할 때 사용하는 프로토콜로서, 이때 서비스를 요청하는 프로그램은 네트워크에 대한 상세 내용을 알 필요가 없다. RPC는 클라이언트/서버 모델을 사용하는데 서비스를 요청 하는 프로그램이 클라이언트이고 서비스를 제공하는 프로그램이 서버이다 , .
이와 같은 기존의 분산 컴퓨팅 모델은 다음과 같은 문제점을 가지고 있다.
① 서로 다른 컴포넌트 모델
EJB, DCOM, CORBA 등의 다양한 컴포넌트 모델은 인터페이스가 서로 다르기 때문에 컴포넌트간의 연동이 어렵다.
<참고 사이트>
EJB
http://java.sun.com/products/ejb/
② 특정 구현 언어에의 의존성
자바 혹은 MS계열의 개발 언어에 의존적으로 분산 시스템을 구축해야 하므로 서로 다른 언어로 개발된 산출물을 함께 사용하기 어렵다.
③ 상호 호환성의 부재
분산 컴포넌트 간에 사용하는 프로토콜의 구조가 모두 다르기 때문에 컴포넌트 간에 데이터를 주고 받을 수 없다.
따라서 데이터 교환의 표준이 존재하지 않는다.
④ 서비스 중복 개발
이미 존재하는 서비스가 있어도 플랫폼이 다르면 다시 개발해야하고, 어떤 서비스가 이미 존재하는지를 알아볼 수 있는 방법이 없다.
⑤ 긴밀히 연결된 (tightly coupled) 서비스
특정 언어 플랫폼 컴포넌트 모델에 의존적인 분산 시스템이 구축될 수밖에 없기 때문에 분산 컴퓨팅의 장점을 살릴 수 없고, 중복 투자의 가능성이 크다.
⑥ 연결지향 (connection-oriented) 프로토콜
연결된 상태에서 클라이언트 또는 서버의 갑작스런 연결 끊김이 발생했을 경우에 적절히 대응하지 못한다.
한편 이런 프로토콜은 대부분 방화벽을 통과하지 못하기 때문에 보안이 강화된 인터넷 상에서 컴포넌트 기반의 분산 컴퓨팅이 어렵다.
이러한 문제점을 가진 기존의 컴퓨팅 환경에서 점차로 비즈니스 규모가 커지고 기업 간의 전자상거래가 활발해짐에 따라 서로 다른 시스템 간의 연동 통합을 위한 새로운 분산 컴포넌트 기반의 컴퓨팅 기술이 요구되었고,
그 결과로 탄생한 것이 바로 웹 서비스 기술이다.
2. 웹 서비스의 정의
어떤 기술들과 컴포넌트들이 웹 서비스를 구성하는 지를 정의하는 것은 어렵지 않지만, 산업계의 대다수가 공감할 수 있는 웹 서비스에 대한 정의를 내리기는 쉽지 않다. 따라서 관련 업체와 단체에 따라서 서로 관점에서 다양하게 웹 서비스를 정의할 수 있지만, 웹 서비스는 새로운 기술이 아니라 지난 몇 년간 인터넷을 이끌어 왔던 기술들의 진화를 보여주는 것이라는 점을 기억하기 바란다.
웹 서비스란?
① IBM
표준화된 XML 메시징을 통하여 접근 가능한 네트워크 명령들의 집합을 기술한 인터페이스이다.
표준화된 XML 메시징이라는 것의 의미는 메시지 포맷, 전송 프로토콜, 접속 URL등의 서비스를 위한 필요 요건들을 상세히 기술한 서비스 명세서를 표준 형식의 XML을 통하여 표현한다는 것이다.
인터페이스는 서비스 구현의 세부 사항을 숨김으로써 서비스가 구현된 하드웨어나 소프트웨어에 독립적이고, 구현된 프로그래밍 언어에 독립적으로 사용될 수 있는 특징을 지닌다.
② Microsoft
다른 응용 프로그램에게 데이터와 서비스를 제공하는 HTTP SOAP와 같은 프로토콜과 XML데이터 포맷을 이용하는 응용 프로그램 로직의 단위이다.
③ Sun
사용자의 요청에 솔루션을 제공하기 위하여 임의로 찾아서 조합될 수 있는 소프트웨어 컴포넌트이다.
④ Gartner Group
웹 서비스는 표준 인터넷 기술을 이용하여 동적으로 상호작용하는 소프트웨어 컴포넌트이다.
⑤ Forrester Research
인터넷 프로토콜과 포맷들을 통하여 다른 소프트웨어가 이용할 수 있도록 설계된 소프트웨어이다.
이와 같은 다양한 웹 서비스에 대한 정의들을 종합해서 정리해 보면,
⑥ 웹을 기반으로 일관성 있고 메시지 지향의 전송 메커니즘을 사용한 서비스의 호출을 위한 투명한 (transparent) API 등을 제공하며, 데이터의 표현과 변환을 위해서 XML 프로토콜을 사용하는 플랫폼과 구현 언어에 독립적인 컴포넌트 기반의 분산 컴퓨팅 서비스이다.
즉, 웹의 기반인 HTTP와 XML 이라는 플랫폼 독립적인 업계 표준을 사용하여 여러 곳에 분산되어 존재하는 유용한 기능을 지닌 프로그램들을 모든 사용자에게 서비스로 제공하는 기능을 하는 것이 바로 웹 서비스이다.
3. 웹 서비스의 장점과 특징
3.1 웹 서비스의 장점
웹 서비스는 분산 프로그래밍의 새로운 컴퓨팅 모델을 정의하고 있는 것으로, 어느 한 플랫폼이나 언어에 국한된 것이 아니고 많은 업체들이 표준화 과정에 참여하여 합의해서 만들어낸 표준으로서 다음과 같은 장점을 가진다.
① 서비스 이용도(availability)
이미 존재하고 있는 인터넷 관련 기술을 이용해 웹 서비스를 사용하고 배포할 수 있다.
② 서비스 이용의 투명성(transparency)
웹 서비스는 어떤 곳이던 관계없이 설치할 수 있고 사용자는 언제 어디서나 HTTP를 이용할 수 있는 곳이면 웹 서비스를 사용할 수 있다.
③ 서비스 캡슐화(encapsulation)
웹 서비스 내부가 자바이건 닷넷이건 혹은 유닉스이건 윈도우이건 관계없이 사용자들은 웹 서비스를 사용할 수 있다.
④ 플랫폼 독립성
특정 회사나 기술에 얽매이지 않는다.
⑤ 표준 기반
웹 서비스에는 다양한 표준이 존재하며 이 표준들이 대부분의 웹 서비스를 기술하고 있다.
⑥ 상호운영성(interoperability)
표준에 입각하여 플랫폼 독립적이고 개방형으로 구현되었기 때문에 서비스의 상호운영성을 위한 기반을 이미 갖추고 있다.
⑦ 지원(support) 의 용이성
웹 서비스의 모든 표준 사항과 구현 내용은 대부분 업계 선두와 표준 협의회에 의해 매우 충실히 지원된다.
3.2 웹 서비스의 특징
① 클라이언트가 웹 서비스 시스템이 제공하는 메소드를 호출하면 메소드의 실행 결과를 클라이언트에게 알려주고 즉시 연결을 해제한다. 이와 같이 웹 서비스 시스템과 클라이언트가 지속적인 연결을 가지지 않기 때문에 안정적이고 리소스가 절약된다.
② 클라이언트의 요청을 처리한 후 응답을 보내고 즉시 연결을 해제하기 때문에 이전 클라이언트의 상태 정보를 유지하지 않는다 따라서 동일한 클라이언트의 요청이 다시 발생해도 이것을 새로운 클라이언트의 요청으로 취급해서 처리하게 된다.
③ 웹 서비스와 클라이언트 간에 XML 기반의 SOAP 프로토콜이 사용된다. 플랫폼 독립적인 프로토콜로서 XML기반의 프로토콜이 사용되기 때문에 XML문서를 인식하고 처리할 수 있는 모든 플랫폼에서 SOAP을 이용할 수 있고 결국 웹 서비스와 클라이언트가 개별적으로 개발될 수 있다.
이것은 웹 서비스와 클라이언트가 각각 어떠한 프로그래밍 언어를 사용해서 개발되더라도 XML기반의 SOAP을 사용하면 전혀 상관이 없게 된다는 아주 중요한 의미를 가진다.
④ 기존의 다른 프로토콜로 구현된 분산 컴포넌트 환경을 통합하는 것은 무척 힘든 일이다. 하지만 기존의 컴퓨팅 환경에서 웹 서비스를 양단에 각각 위치시키게 되면 기존의 다른 프로토콜로 구현된 분산 컴포넌트 환경을 간단히 통합할 수 있다.
⑤ 인터넷상에서의 분산 컴퓨팅이 가능하다. 웹 서비스와 클라이언트는 SOAP을 사용해서 요청 및 응답을 담당하는데 이러한 SOAP은 일반적으로 전송 프로토콜로서 HTTP를 사용하기 때문에 방화벽을 넘나들며 원격 객체의 메소드를 호출할 수 있다. 하지만 이런 특징으로 인해 허가되지 않은 사용자도 SOAP응용 프로그램에 접근할 수 있게 되므로 심각한 보안 문제가 대두되어 오히려 약점이 될 수도 있다.
4. 웹 서비스의 형태
4.1 동기적 형태
동기적 웹 서비스 형태는 요청 SOAP 메시지를 보내는 클라이언트 응용 프로그램과 응답 SOAP 메시지를 보내는 웹 서비스 시스템과 일대일로 연결되는 형태를 의미한다. 따라서 클라이언트는 서비스를 요청한 후 웹 서비스 시스템에서 그것을 처리하고 결과로 응답을 보낼 때까지 연결을 유지하고 있다가 응답 SOAP 메시지가 도착하면 연결을 해제하는 방식이므로 요청 후 응답이 도착할 때까지 클라이언트는 어떤 다른 작업도 수행할 수 없게 된다. 일반적으로 RPC방식의 웹 서비스가 이에 해당한다.
4.2 비동기적 형태
요청 SOAP 메시지를 보내는 클라이언트 응용 프로그램과 메시지를 임시로 보관하는 메시지 큐, 그리고 SOAP 메시지를 처리하는 웹 서비스 시스템으로 구성된다. 이 형태는 클라이언트가 요청 SOAP 메시지를 전송하면 이것이 큐를 통해서 저장되고 웹 서비스 시스템에게 제공되기 때문에 클라이언트는 웹 서비스의 응답을 무작정 기다릴 필요 없이 곧 바로 다른 작업을 할 수 있는 장점이 있다.
이러한 방식에서 사용되는 메시지 큐는 별도로 설치되거나 클라이언트와 웹 서비스 시스템에 각각 설치될 수도 있다.
5. 웹 서비스 구조
서비스 지향적인 환경을 구축하기 위해서는 다음과 같은 몇 가지 조건이 충족되어야 한다.
▷ 웹 서비스의 인터페이스와 호출 메소드가 정의되고 생성되어야 한다.
▷ 웹 서비스는 이를 이용하려는 사용자가 접근할 수는 있는 하나 이상의 인트라넷 또는 인터넷 저장소에 공개되어 있어야 한다.
▷ 웹 서비스는 더 이상 이용이 불가능하거나 필요하지 않은 경우에 삭제될 수 있어야 한다.
웹 서비스 구조는 이러한 조건을 만족시키기 위해 서비스 제공자, 서비스 중개자, 서비스 소비자의 세 요소로 구성되며,
공개(publish), 검색(find), 바인드(bind) 라는 기본적인 연산을 지원한다.
즉 서비스 제공자는 서비스 중개자에게 서비스를 공개하고 서비스 소비자는 서비스 중개자를 이용해서 서비스를 검색하며, 이때 서비스 소비자와 서비스 제공자 사이에 바인딩이 일어난다.
웹 서비스의 세 요소는 모두 독립적으로 존재하며 이들 간의 통신 과정은 모두 XML로 표준화되어 있기 때문에 구조적으로 매우 유연하며, 한편 서비스 중개자가 제공하는 저장소를 사용하기 때문에 서비스와 사용자가 자유롭게 분산될 수 있는 구조이다.
5.1 서비스 제공자
실제로 웹 서비스를 개발하는 회사 또는 개인을 의미하며, 여러 가지의 비즈니스 기능을 웹 상에서 이용할 수 있도록 웹 서비스 시스템을 개발한다. 웹 서비스를 개발한다는 말은 기존에 존재하고 있던 모든 서비스를 새로 개발한다는 의미가 아니라, 개발되어 사용되고 있는 서비스에 웹 서비스를 위한 인터페이스를 개발하는 것으로 개발의 의미를 이해할 수 있다.
서비스 제공자가 제공하는 서비스를 웹 서비스로 전환하기 위해서는 두 가지 작업을 수행한다.
① 서비스 기술
서비스 제공자는 제공하려는 서비스를 표준 형식에 맞게 기술(describe) 하여 이를 사용자가 쉽게 이해하고 사용할 수 있도록 한다.
② 서비스 공개
서비스 제공자의 물리적인 위치를 모르더라도 임의의 사용자가 서비스를 사용할 수 있도록 하기 위해서 회사의 정보 및 웹 서비스 시스템 이용에 대한 상세 내역을 서비스 중개자가 운영하는 레지스트리(저장소)에 공개한다 .
5.2 서비스 중개자
서비스 제공자가 개발한 웹 서비스 시스템의 상세 내역을 공개하고, 서비스 소비자가 원하는 웹 서비스를 검색할 수 있도록 해 주는 중앙 저장소를 운영한다.
5.3 서비스 소비자
서비스 소비자는 서비스 제공자가 제공하는 서비스 기술(description)을 보고 어떻게 사용하는 지 알 수 있는데, 이런 기술 정보를 얻기 위해서 서비스 중개자의 중앙 저장소에서 원하는 웹 서비스를 검색하여 이용하는 방법을 찾아야 한다.
찾아진 웹 서비스에 바인딩(binding)하여 실제 웹 서비스의 기능을 이용하는 것이 바로 서비스 소비자의 가장 큰 역할이다.
<용어>
바인딩
특정 프로토콜을 사용하여 웹 서비스 시스템에 접속하는 것.
6. 웹 서비스 스택
웹 서비스의 개념적인 구조를 실제로 수용하기 위해서는 웹 서비스 스택이라고 하는 기술 명세를 알아야 구현할 수 있다.
웹 서비스 스택은 그림과 같은 네 가지 기술로 구현된다.
6.1 전송 네트워크
웹 서비스가 어떤 전송 수단을 사용하더라도 서로 연동이 가능하도록 추상화를 제공하는 부분이다.
일반적으로 웹 서비스라고 하면 대부분의 응용 프로그램이 제공하고 있어 광범위한 호환성을 보장받을 수 있는 HTTP에서의 동작을 말한다. 즉 서비스 요청과 응답을 위한 메시지의 전송 프로토콜로서 기본적으로 HTTP를 사용한다는 의미이다.
물론 HTTP 이외에 SMTP, FTP, HTTPS 등을 사용할 수 있다.
6.2 XML 메시징
웹 서비스 사용자와 서비스간의 서비스 호출과 결과에 대한 전송 방법을 정의하는 부분이다.
웹 서비스에서는 이 부분을 SOAP이라는 XML기반의 표준 방식을 사용한다. SOAP은 전송 네트워크 부분과 분리되어 추상화되어 있기 때문에 어떤 프로토콜을 사용하는 가에 관계없이 사용할 수 있다.
따라서 이런 SOAP을 사용하면 플랫폼 운영체제 개발 언어 프로토콜에 관계없이 독립된 형태로서 웹 서비스를 이용할 수 있다.
6.3 서비스 기술
서비스 제공자가 제공하는 웹 서비스를 기술하기 위한 부분으로 웹 서비스에서는 WSDL이라는 XML표준 기술 방식을 이용한다. WSDL은 서비스의 추상적인 부분과 실제 구현 부분을 분리할 수 있어 동일한 서비스를 다양하게 정의할 수 있다.
이런 방식으로 인해 서비스 내용의 변경 없이 동일한 서비스 기술로 다양한 프로토콜에 대한 경로를 지정할 수 있다.
6.4 서비스 공개와 검색
서비스 중개자가 운영하는 레지스트리에 서비스 제공자의 서비스를 공개해 놓으면 사용자가 이를 검색하여 서비스를 이용하기 위한 것으로 이는 서비스 소비자와 제공자 모두에게 편리성을 제공한다.
즉, 소비자는 자신이 원하는 서비스의 정확한 위치를 모르더라도 찾을 수 있고, 찾아낸 결과가 여러 개라면 원하는 정보를 선택할 수 있으며, 서비스 제공자는 좀 더 많은 사용자에게 서비스를 쉽게 제공할 수 있기 때문이다.
웹 서비스에서는 이와 같은 기능을 제공하기 위해서 UDDI라는 XML 표준 기술 방식을 사용한다.
5장에서 살펴본 웹 서비스 구조와 스택 내용을 바탕으로 실제 웹 서비스의 전형적인 모습은 다음 그림과 같이 표현할 수 있다.
7. 웹 서비스의 핵심 기술
현재 모습의 웹 서비스가 가능하게 된 데에는 대표적으로 다음과 같은 기술이 밑바탕으로 깔려 있다.
7.1 XML
XML(eXtensible Markup Language)은 W3C의 텍스트 기반 마크업 언어에 대한 표준안으로 HTML과 달리 사용자가 정의하는 태그를 이용해서 각종 표현과 데이터를 나타낼 수 있다.
XML은 이식성이 높은 구조화된 데이터를 기술하는 데 유용하여 주로 데이터를 기술할 때 많이 이용된다 특히 메시징 프로토콜과 상호 교환을 필요로 하는 데이터 포맷으로 많이 이용되고 있다.
기존의 대표적인 분산 컴퓨팅 모델인 CORBA, RMI, DCOM 등은 동일한 플랫폼/프로토콜 환경에서 응용 프로그램을 개발하는 데는 아무런 문제가 없지만, 플랫폼이 다양한 환경이나 인터넷 상에서 분산 응용 프로그램을 개발하기에는 적합하지 않다.
하지만, XML을 이용하면 서로 다른 시스템에서 응용 프로그램 간에 정보를 공유할 수 있고 기업 간의 각종 데이터 교환이 가능하다. 따라서 XML이 웹 서비스의 가장 중요한 기반 기술이 된다. 즉 웹 서비스의 원격 프로시저 호출은 을 이용한 메시지로 이루어져 있고 반환되는 결과 형식도 XML을 이용한 SOAP 메시지로 이루어져 있다.
결국 XML을 이용하기 때문에 어떠한 장소에서든 어떤 기기를 사용하든 상관없이 웹 서비스가 제공하는 정보를 동일하게 이용할 수 있게 된다.
7.2 웹 서비스의 호출 - SOAP
웹 서비스의 호출을 책임지는 것이 SOAP(Simple Object Access Protocol)이다.
웹 서비스 구조에서 가장 중요한 기술이라고 할 수 있는 SOAP은 원격 응용 프로그램 간의 정보를 교환하는데 사용되는 확 장성이 좋은 일종의 메시지 포맷 프로토콜이다. 이것은 XML문서로 구성되어 정보 표현력이 아주 우수하며 가볍고 구조가 간단하기 때문에 정보 표현 및 교환에 중점을 둔 프로토콜이다.
SOAP은 단순히 정보 전달용으로 사용될 수도 있지만 주로 원격 프로시저 호출용으로 사용된다.
SOAP 메시지는 HTTP, SMTP 와 같은 다양한 인터넷 표준 통신 프로토콜을 이용해서 원하는 목적지로 전송된다.
인터넷에서 전송용 프로토콜로서 현재 가장 많이 사용되고 있는 HTTP가 SOAP 메시지를 전달하는 최적의 전송 프로토콜로서 일반적으로 사용된다.
(1) SOAP의 기본적인 이해
SOAP에서 정의하고 있는 것은 메시지를 교환하기 위한 단순한 방식과 모듈화된 패키지를 만드는 방법,
XML 스키마에 기반을 두고 메시지 내부에 데이터를 인코딩하는 방법이 전부다.
SOAP이 전송 프로토콜을 정의하고 있지 않기 때문에, SOAP이 전송 프로토콜로서 HTTP, SMTP, TCP/IP 등 어떤 것을 이용하더라도 결국은 동일한 SOAP 메시지를 이용한다.
따라서 일단 SOAP을 지원하는 웹 사이트와 웹 애플리케이션은 웹 서비스를 제공할 수 있는 기본 자격을 갖추게 되는 것이다. 그리고 추가적인 프로그래밍을 하지 않고도 다른 컴퓨터의 서비스들과 연계가 가능하다.
(2) SOAP과 기존 분산 프로토콜의 비교
▶ CORBA 등은 객체의 실행과 생명주기 관리 등과 같은 여러 관리적인 면에서의 구현 부분을 필요로 하기 때문에 무거운 프로토콜이다. 하지만 SOAP은 이러한 면에서 수많은 분산 프로토콜과 교감을 이룰 수 있게 하려고 최대한 가볍고 공통적인 부분만 수용한 단순한 프로토콜이다.
▶ SOAP은 기존의 분산 프로토콜들과는 달리 XML을 이용하고 전송 프로토콜에 대한 의존도가 없기 때문에 확장이 매우 용이하다는 장점을 가진다.
▶ SOAP은 기존의 인터넷 인프라구조에서 돌아가기 때문에 라우터나 방화벽 프록시 서버 등에 SOAP을 동작시키기 위한 특별한 작업이 필요 없다. 이러한 특징은 SOAP 이용시 배포가 용이하지만 보안이라는 측면에서는 단점이 될 수도 있다.
SOAP이 기존의 분산 프로토콜에 비해서 위와 같은 장점을 가지지만 여기서 한 가지 반드시 기억해야 할 것은 SOAP이 기존의 CORBA, DCOM, RMI와 같은 프로토콜을 완전히 대체할 수는 없다는 것이다.
왜냐하면 SOAP은 기존의 분산 프로토콜을 공통적인 기능을 모아 최대한 가볍게 만든 것이기 때문에 기존 분산 프로토콜이 가진 여러 기능을 지원할 수 있는 방법은 따로 마련되어야 하기 때문이다.
(3) SOAP 메시지
클라이언트와 웹 서비스 시스템 간의 요청과 응답을 위한 SOAP 메시지는 다음과 같은 특징을 가진다.
▶ SOAP 메시지 전송은 기본적으로 발신자가 수신자에게 보내는 단방향 전송이다.
▶ SOAP의 메시지 전송은 보통 요청/응답 세트로 구현되는 특징을 가진다.
▶ 모든 SOAP 메시지는 XML 문서로 구성되기 때문에 자신의 스키마를 가지고 있다.
▶ SOAP은 SOAP (envelope) 엔빌로프 와 직렬화 (serialization) 또는 인코딩이라는 2개의 네임스페이스를 정의한다.
▶ SOAP이 지정하는 규칙의 일부는 XML 자체보다 다소 엄격하다 (예를 들어, DTD(Document Type Definition)나 PI(Processing Instruction)를 가질 수 없다.)
▶ SOAP 메시지의 구성은 다음 그림과 같이 SOAP 엔빌로프, SOAP 헤더, SOAP 바디로 구성된다.
7.3 웹 서비스의 기술 - WSDL
WSDL(Web Service Description Language)은IBM의 NASSL과 마이크로소프트의 SDL을 통합하여 탄생한 산출물로서 표준화된 방식으로 웹 서비스의 인터페이스를 기술하는 XML기술 언어이다.
XML 웹 서비스를 기술하기 위해서는 기본적으로 어떤 메시지를 생성하고 받아들일 수 있는 지를 정의하는 것이 중요한데, WSDL은 XML스키마를 이용해서 이 문제를 해결하고 있다 웹 서비스를 기술하는데 WSDL 이외에도 워크플로우와 관련된 WSFL이나 자원 분배와 위치에 대한 내용인 RDF와 같은 관련 표준들도 많지만 현재 상태로는 WSDL이 가장 중요한 위치를 차지하고 있다 XML스키마를 이용하면 아무리 복잡한 데이터 타입도 정의할 수 있는데 이것이 의 WSDL기반이 된다.
<참고 사이트>
RDF (Resource Description Framework)
http://www.w3.org/RDF/
WSDL은 네트워크 서비스를 문서 지향(document-oriented) 또는 프로시저 지향(procedure-oriented) 적인 내용을 담고 있는 메시지들에 대한 종점(endpoint) 으로 간주한다. 다시 말해 연산이나 프로시저를 추상적인 방법으로 먼저 기술한 다음 구체적인 네트워크 프로토콜과 메시지 포맷으로 바인딩한다.
WSDL은 하부 네트워크나 메시징 프로토콜이 무엇이든지 네트워크 서비스를 기술할 수 있다는 측면에서 확장성이 매우 좋다. 현재의 WSDL은 SOAP, HTTP GET, HTTP POST, MIME 만 지원하고 있다.
서비스 제공자는 WSDL을 통해 원격 메소드 호출을 지원하기 위한 요청, 응답 메시지 포맷을 기술할 수 있다.
일반적으로 WSDL은 해당하는 관련 연산을 정의하며 매개변수와 데이터 타입도 정의한다.
또한 서비스의 위치와 바인딩에 대한 세부 내용도 정의한다 서비스 소비자는 이런 WSDL문서를 이용해서 웹 서비스 시스템에 접속하는 방법을 알게 된다.
7.4 웹 서비스의 검색 - UDDI
UDDI(Universal Description, Discovery and Integration) 표준은 서비스 중개자를 구현하기 위한 SOAP API의 공통적인 집합을 제공한다. 즉 웹 서비스의 공개와 검색을 위한 XML 레지스트리(저장소)의 구현과 사용 방법을 표준화한 것이다.
UDDI스펙에는 웹 서비스 중개자가 운영해야 할 XML레지스트리 기능 웹 서비스 제공자가 어떻게 자신의 웹 서비스를 공개해야 되는지 그리고 웹 서비스 소비자가 어떻게 검색할 수 있는 지에 대해서 설명하고 있다.
지금까지 살펴 본 SOAP, WSDL, UDDI 간의 관계는 다음 그림과 같이 표현될 수 있다.
▶ 웹 서비스 제공자
- UDDI 스펙에 정의되어 있는 방법대로 웹 서비스 중개자가 운영하는 중앙 저장소에 정보를 공개한다.
- 한편, WSDL을 이용하여 공개되는 웹 서비스에 대한 상세 기능을 작성하여 웹 서비스 중개자에 서비스를 공개할 때 WSDL 문서의 URL를 포함시킨다.
▶ 웹 서비스 소비자
- UDDI 스펙에 정의되어 있는 방법대로 중앙 저장소에서 정보를 검색한다.
- 웹 서비스의 상세 기능을 기술한 WSDL문서의 경로를 확인하고 WSDL문서를 다운로드받아 호출 가능한 프로시저명과 매개변수 등에 대한 정보를 알아낸다. 그리고 웹 서비스 소비자의 프로그래밍 언어로서 웹 서비스의 원격 프로시저를 호출할 준비를 한다.
- SOAP 스펙에 정의되어 있는 메시지 형태로 웹 서비스가 제공하는 원격 프로시저를 호출한다.
그러면 웹 서비스 시스템은 결과값을 다시 SOAP스펙에 맞는 메시지 형태로 웹 서비스 소비자에게 보내준다.
▶ 웹 서비스 중개자
- UDDI 스펙에 정의되어 있는 방법대로 실행되는 중앙 저장소를 구현한다.
정리
① 웹 서비스는 갑작스럽게 등장한 혁명적인 기술이 아니라 소프트웨어 기술의 발전과 함께 진화해온 성숙된 분산 기술이다.
② 웹 서비스는 기존에 자리잡고 있던 원격지와 이기종간의 분산 컴퓨팅의 방법을 새로운 발상으로 전환한 것이다.
③ 웹 서비스는 웹 기반 위에 XML프로토콜을 사용하여 플랫폼과 구현 언어에 독립적인 컴포넌트 기반의 분산 컴퓨팅 서비스이다.
④ 웹 서비스는 서비스 제공자, 서비스 중개자, 서비스 소비자의 세 가지 요소로 구성된다.
⑤ 웹 서비스에서는 공개, 검색, 바인드의 대표적인 세 가지 동작을 위해서 SOAP, WSDL, UDDI라는 표준을 정의하고 있다.
⑥ 웹 애플리케이션과 웹 서비스를 비교하면 다음과 같다.
⑦ RPC와 웹 서비스를 비교하면 다음과 같다.
'정보과학 > 웹서비스특론' 카테고리의 다른 글
| SOAP (0) | 2023.09.07 |
|---|---|
| XML 스키마 (2) (0) | 2023.09.06 |
| XML 스키마 (1) (0) | 2023.09.05 |
| XML 네임스페이스 (0) | 2023.09.05 |
| XML 문법 (0) | 2023.09.04 |
