난이도 : 초급 Uche Ogbuji, Consultant, Fourthought, Inc.
2000 년 11 월 01 일 Web Services Description Language (WSDL)는 네트워크로 연결된 XML 기반 서비스를 기술하는 새로운 스팩이다. 서비스 공급자가 기반 프로토콜(Simple Object Access Protocol 또는 XML)이나 인코딩(Multipurpose Internet Messaging Extensions)과는 무관하게 기본 요청 포맷을 시스템에 제공할 수 있는 간단한 방식이다.
WSDL은 Universal Description, Discovery and Integration (UDDI) 이니셔티브의 핵심 부분으로서 , 인터넷 비즈니스를 위한 온라인 서비스등의 디렉토리와 관련설명을 제공한다. 이 글에서 WSDL의 배경과 기술을 설명한다. XML과 XML Namespaces에 대한 기초적인 이해와 XML Schemas와 SOAP을 이해하고 있다면 이 글이 더욱 유용할 것이다.
지난 몇 년 동안 수 많은 표준 제안이 생겼다. 바로 네트워크로 연결된 서비스 요청(networked service requests)의
핵심적인 요소들을 다루기 위한 노력들이었다. 네트워크로 연결된 서비스 요청은 원격 머신에서
인터넷 같은 네트워크를 통해 XML 관련 기능들을 요청하는 하나의 방식이다.
표준 시장의 경쟁자들이 앞다투어 생겨났다. Allaire Corp의 Web Distributed Data eXchange (WDDX) (참고자료),
UserLand Inc의 XML Remote Procedure Call (XML-RPC), Microsoft의 Simple Object Access Protocol (SOAP)
(David Winer, IBM, Microsoft)이 바로 그 예이다. 이와 동시에 몇몇 개발자들은 평범한 HTTP를 통해서도
애플리케이션을 잘 구현했다. XML 기반 네트워크 서비스에서 가장 성장한 분야는 콘텐트 교환과 신디케이션이었다.
아울러, 이 같은 콘텐트의 디스크립션과 구조를 정의하기 위한 수 많은 제안들이 있었다.
이 중에는 Vignette Corp와 파트너사가 만든 Information Content Exchange (ICE), Netscape와 파트너사가
만든 RDF (Resource Description Framework) Site Summary (RSS)가 있다. 많은 개발자들은
Multipurpose Internet Messaging Extensions (MIME)의 일반적인 인터넷 표준을 사용해왔다.
이 외에도 너무나 많은 XML 프로토콜 제안들이 있다. W3C도 이러한 현상들을 다루기 위해
새로운 XML Protocol Working Group을 만들었을 정도다. (참고자료) W3C가 이러한 혼란 속에서
무엇인가 공통된 것을 끌어내려고 하였다.
웹 애플리케이션들간 통신하는 다양한 방식들 속에서 통신 프로토콜과 요청 구조와 관계없이
XML 기반의 네트워크 서비스를 기술할 수 있는 메커니즘에 대한 필요성이 대두되었다. 이 같은 메커니즘을 사용하여
많은 웹 개발 태스크들이 자동화되고 있다.
- 포탈 툴킷들은 콘텐트 섹션에 플러그인 시스템을 제공하기 때문에 디자이너들이 광범위한 온라인 서비스들 중에서 쉽게 선택할 수 있다. 기술의 상세한 부분들을 알지 않아도 된다.
- 기업들과 서비스 브로커들은 XML 서비스에 대한 포괄적인 백서와 옐로우 페이지를 출판하여 개발자들이 기술적인 평가와 비교를 할 수 있도록 돕는다.
- 서비스 공급자들은 표준 포맷으로 업데이트와 요청 구조들의 버전을 빠르게 발표하여 개발자들이 쉽게 채택할 수 있도록 한다.
IBM, Ariba, Microsoft는 그 같은 메커니즘을 만들기 시작하여 9월 25일에 Web Services Description Language (WSDL) version 1.0을
발표하게 되었다. (참고자료) 그 때까지 이 "1.0" 스팩이 베일 속에 가려져있었다는 것이 약간 이상하다.
XML 커뮤니티는 릴리스 되기 전에 공식적으로 리뷰 할 기회도 없었다. 어쨌든, WSDL은 네트워크로 연결된 XML 서비스를
기술하는 포맷이고 앞서 언급한 필요 조건들을 많은 부분 충족시킨다.
배경
WSDL은 이전의 스팩들과 많은 부분 중복된다. 원격 웹 서비스의 디스크립션 분야의 선두주자였던
WebMethods의 Web Interface Definition Language (WIDL)은 RPC와 CORBA 사용자들에게 친숙한 접근 방식을 취한
XML 포맷이었다. WIDL과 XML-RPC 시스템간 맞는 부분이 있었다. 메시지 기반 XML 기술이 절차적 장치 보다
대중성을 확보하게 되면서 WIDL은 사라졌다. 후자는 SOAP에게 길을 내주었다.
SOAP은 envelope과 메시지 포맷을 기술하고 기본적인 요청/응답 프로토콜을 갖고 있다.
Microsoft는 한 해 전에 SOAP Contract Language (SCL)을 개발하여 SOAP 기반 애플리케이션에
온라인 서비스 디스크립션을 제공했다. SCL의 작동은 WSDL로 많은 부분 편입되었다.
WSDL이 탄생하기 전에 IBM, Ariba, Microsoft 등이 포함된 36개 기업들의 컨소시엄은
Universal Description, Discovery and Integration (UDDI) 시스템(참고자료)을 발표했다.
이것은 온라인 비즈니스 서비스의 표준 디렉토리에 정교한 API를 제공하고자 하는 제안이었다.
Microsoft는 WSDL이 등장하기 전에 웹 서비스 디스크립션 분야에서 바쁘게 움직였다.
Microsoft는 Discovery of Web Services (DISCO) (참고자료)도 만들었다. 이것은 지금 Microsoft의 공식적인
.NET 플랜의 변방으로 밀려나있다. DISCO는 ("discover") SCL 디스크립션을 찾는 방법을 기술하고 있다.
솔직히 DISCO 스팩을 읽어보면 이것의 가치를 알 수 없다.
SCL에 대한 Microsoft의 노력과 발맞추어 IBM은 Network Accessible Service Specification Language (NASSL)
(참고자료)를 만들었다. IBM은 WSDL과 특별히 NASSL 에디터에 집중했다. IBM은 또한
Advertisement and Discovery of Services (ADS)와 함께 작동하는 서비스 디렉토리에도 개입했다.
IBM의 alphaWorks 프로젝트의 Web Services Toolkit이 레퍼런스 구현을 가졌음에도 ADS의 정식 스팩이 되기에는 부족하다.
지금 혼돈스러워 한다면 그래도 여러분은 좋은 사람이다. XML은 수 많은 다른 스팩들을 만들어내는 것 외에는
달리 사용할 데가 없는 스팩이라고 빈정대는 사람들도 있다. UDDI 의 포메이션은 서비스 디스크립션 분야에서
도움을 줄 것으로 기대된다. 이것은 아마도 개별적인 형태로 되겠지만 서비스 디렉토리, 디스크립션,
요청/응답 프로토콜, 요청 구조와 데이터 타이핑, 의미 발견, 전송 프로토콜 등의 포맷들과 연결될 것이다.
그림 1은 앞서 언급했던 다양한 스팩들을 배치해놓은 다이어그램이다.
이 다이어그램이 여러분의 이해를 돕게 되길 바란다. 이 그림에서 WSDL은 서비스의 디스크립션 메커니즘을 핸들한다.
그림 1. 서비스 역할과 인터랙션
WSDL 문서 샘플
이제 다음 예제를 통해서 WSDL과 SOAP이 어떻게 작동하는지를 보자. snowboard-info.com 이라는
가상 기업을 운영한다고 가정해보자. 사람들이 스노우보드 제조자들이 승인을 받았는지를 확인 할 수 있는
서비스를 제공한다. 클라이언트는 SOAP 요청을 사용하여 요청을 보낼 수 있다. (Listing 1)
Listing 1의 코드는 "어떤 스노우보드 전문가가 K2 FatBob을 승인했는가?"로 해석된다.
Listing 1. SOAP 1.1 요청
POST /EndorsementSearch HTTP/1.1
Host: www.snowboard-info.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 261
SOAPAction: "http://www.snowboard-info.com/EndorsementSearch"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">
<manufacturer>K2</manufacturer>
<model>Fatbob</model>
</m:GetEndorsingBoarder>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
이 서버는 앞서 이루어졌던 요청에 대해 SOAP 1.1 응답(HTTP header 없음)을 보낼 수 있다. (Listing 2)
응답 내용을 요약해 보면 "영국인 Chris"이다.
Listing 2. SOAP 1.1 응답
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
<endorsingBoarder>Chris Englesmann</endorsingBoarder>
</m:GetEndorsingBoarderResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
|
이제 전체 요청 구조, 관련 데이터 유형, 사용된 XML 엘리먼트의 스키마, 기타 여러 사항들이 SOAP 스팩에 의해
해당 파트너들에게 남겨진다. WSDL은 요청 유형과 요구사항들을 통합하는 표준 서비스 스팩을 제공한다.
스노우보드 포탈과 토론 사이트들을 우리 시스템으로 연결시키려면 WSDL 통신 포트를 정의해야 한다.
스노우보딩 승인 쿼리용 WSDL 디스크립션과 같은 WSDL 디스크립션을 공개한다.
Listing 3은 다소 길다. 하지만 WSDL은 실제로 매우 간단하다.
우리의 WSDL 문서 샘플은 WSDL의 모든 면을 사용하고 있을 뿐만 아니라, 매우 큰 XML 스키마 청크를 갖고,
WSDL에 대한 SOAP 바인딩을 활용하고 있다. 마지막 부분은 표준 서비스 디스크립션의 확장이다.
관련 서비스들을 기술하는 <definitions>엘리먼트로 끝난다.
<types>엘리먼트는 메시지 또는 프로시저 콘텐트의 저급 데이터 타이핑의 스팩을 허용한다.
다른 메커니즘들도 허용되지만 대부분의 사용자들은 XML 스키마를 선택할 것이다. 우리 예제도 마찬가지다.
Listing 1과 Listing 2의 샘플 교환을 매치할 수 있는
간단한 엘리먼트 콘텐트 모델을 지정한다. WSDL은 개별 리소스들로 배치된 중요한 데이터 유형 스팩용 시스템을 제공한다.
그리고 다중 사용 도메인에 있는 복잡한 메시지의 경우 여러 리소스들이 있을 수 있다.
<message> 엘리먼트는 각 개별 전송의 데이터 포맷을 정의한다.
우리 같은 경우 한 개의 메시지는 EndorsingBoarder 요청을 나타내고, 다른 것은 응답을 나타낸다.
우리 예제에서 메시지의 바디는 유형 섹션의 스키마로부터 온 특정 엘리먼트라는 간단한 문장이다.
전송을 메시지 부분들로 나누는 것은 데이터에 논리적 뷰에 의존한다. 예를 들어, 전송이 원격 프로시저 호출이면
메시지는 다중 부분들로 나뉘어지고, 이중 하나는 프로시저 이름과 메타 데이터이고, 나머지는 프로시저 매개변수들이다.
데이터-타이핑의 세분성과 메시지를 부분들로 나누는 것 사이에 관계가 성립된다.
<portType>엘리먼트는 하나의 논리적 연산을 형성하는 메시지들을 그룹핑한다.
예를 들어, 우리는 EndorsingBoarder 응답을 실행하는
EndorsingBoarder 요청을 갖고 있거나,
에러나 예외일 경우 EndorsingBoarderFault를 갖게 된다.
이러한 특별한 교환은 모두 WSDL 포트 유형으로 그룹핑된다. 여러분도 보듯 메시지에 대한 관계는 qualified name 레퍼런스로 만들어진다.
WSDL에서 빌트인 지원을 갖춘 연산은 네 가지 형태가 있다. 일방(one-way),
요청-응답(request-response), 간청-응답(solicit-response), 공지(notification)이다.
마지막 두 개는 첫 번째 두 개와 정 반대이다. 기본적으로 WSDL은 일방향(일방과 공지)와
양방향(요청-응답과 간청-응답) 포트 유형을 지원한다. 오류는 양방향 포트 유형에서만 지원된다.
CORBA 모델과는 다르다.
WSDL 문서는 구체적이고 물리적인(데이터 타이핑)에서 추상적이고 논리적인(메시지와 포트 유형)으로 옮겨왔다.
<binding>엘리먼트는 논리적 모델과 물리적 모델 사이에 연결을 확실히 제공한다.
이 경우 우리가 추상적 포트 유형을 통해 정의했던 연산을 사용하여 이것을 구체적 디스크립션으로 연결한다.
WSDL은 또한 HTTP와 MIME으로의 바인딩을 제공하고 다른 프로토콜로도 확장된다.
우리의 샘플 바인딩은 GetEndorsingBoarderPortType을
SOAP "스타일"의 문서를 갖는 것처럼 지정한다. 이 스타일은 RPC 또는 문서가 될 수 있다.
보다 절차적인 전자는 통신에 전념하고 후자는 메시지 교환으로 기울어진다. 물론 이들간 나뉘어진 라인은 매우 광범위하고,
주어진 포트 유형이 이것 또는 다른 것인지를 논의하는 것은 무의미하다. 내 논의의 경향은 거의 모든 곳에서
문서를 사용하는 것이다.
네트워크 전송은 HTTP 로 지정한다. SOAP은 다른 수단들(SMTP)을 통해 전송될 수 있다.
<soap:operation> 엘리먼트는 포트 유형의 개별 매시지들을 SOAP 전송으로 매핑한다.
우리는 SoapAction을 지정한다. 이것은 HTTP를 통하는 SOAP에 필요하다. 주어진 값은 실제 메시지의 HTTP 헤더에서
사용되어서 메시지의 의도를 나타내야 한다. 이로서 지능적인 프록싱과 SOAP 트래픽의 방화벽이 허용된다.
마지막 엘리먼트인 <service>는 통신 엔드 포인트의 물리적 위치를 지정한다.
이것은 포트 유형과 바인딩을 사용하고 특정 공급자용 웹 주소 또는URI를 부여한다. 우리 예제에서, 이것은 우리가 SOAP
서버를 설치했던 주소이다.
하지만 일단 서비스가 시작되고 사용자가 히트하게 되고, 트래픽은 서버를 압도하기 시작한다면?
우리는 미러를 설치하기로 결정한다. 아마 유럽이 될 것이다. 이 경우 서비스는 정확히 같다.
하지만 우리는 개별 URI를 제공한다. WSDL 스키마에서 우리가 해야 할 일은 WSDL 문서를 수정하여
또 다른 <service> 엘리먼트를 추가하는 것이다. (Listing 4)
Listing 4. 다중 사이트를 핸들하기 위한 대안 <service> 엘리먼트
<service name="EndorsementSearchEuropeanService">
<documentation>snowboarding-info.com Endorsement Service European
Mirror</documentation>
<port name="GetEndorsingBoarderPort"
binding="es:EndorsementSearchSoapBinding">
<soap:address location="http://www.snowboard-info.co.uk/EndorsementSearch"/>
</port>
</service>
|
달라진 서비스 이름과 주소를 주목하라. 이제 서비스 디렉토리의 어떤 수단을 통해서든
WSDL 문서를 찾는 모든 사용자들은 실제 요청을 하는 장소에 대해 두 가지 옵션을 갖게 된다.
우리의 WSDL 예제에 대해 몇 가지 일반적인 주목할 사항이 있다. 우리는 WSDL이 XML 네임스페이스에 완전히 의존한다는 것을 볼 수 있다.
<definition> 엘리먼트의 targetNameSpace 애트리뷰트에
주어진 XML 네임스페이스는 기본적으로 다른 상위 레벨 WSDL 엘리먼트에 사용된 모든 이름들에 붙여진다.
개발자들은 자격이 있는 이름들을 사용하여 특정 네임스페이스 정의에서 접두사를 사용하여 이러한 엘리먼트를 언급한다.
디폴트 네임스페이스는 WSDL 애트리뷰트 내에서 접두사가 붙지 않은 이름들에는 적용되지 않는다.
이것은 XML 네임스페이스 메커니즘이 XML 스팩의 문자 데이터에서 정확한 이름에 사용하는 곳과 일치한다.
XML 네임스페이스는 또한 WSDL 엘리먼트들을 <types>엘리먼트에 제공된
데이터 타이핑으로 연결하는데 사용된다. 우리 예제에서 우리는 디폴트 네임스페이스
(http://schemas.xmlsoap.org/wsdl/)를 사용하여 WSDL의 공식 엘리먼트임을 나타낸다.
하지만 이 스팩은 정확히 다른 네임 스페이스의 엘리먼트를 사용하는 핵심 엘리먼트를 확장하는 옵션에도 넓게 확장되어 있다.
전체적으로 이 예제는 매우 간단하다. 이것은 짧은 SOAP 전송들로 구성된 통신을 설명한다.
두 개의 인풋 스트링과 한 개의 아웃풋을 각 연산에 갖고 있다. WSDL은 완전히 이상한 범위의
XML 스키마를 사용하는 메시지들로 구성된 다중 포트 유형들을 쉽게 정의한다. 적어도 단기적으로 볼 때
XML 공급자와 사용자들간 보다 간단한 통신이 이어질 것이다.
맺음말
WSDL은 XML 기반 커머스의 중요한 구현 블록이다. WSDL은 매우 간단하다.
IBM, Microsoft, Ariba는 스팩을 구현할 때 여러 벤더들이 어떤 역할을 해야 하는지를 보여주는 좋은 예이다.
WSDL은 XML 네임스페이스를 통해 강력한 확장성을 제공하고, 매우 복잡한 서비스를 기술하는데도
효과적으로 사용할 수 있는 다양한 툴을 제공한다. 다만 공식적인 리뷰를 거치지 않고,
"1.0" 버전이 나온 것은 조금 안타깝다.
이 글에서 언급하지 않은 한가지는 RDF와의 통합이다. W3C의 "semantic Web"이
확장하면서, 온라인 서비스 디스크립션이 RDF를 통해서도 효용을 얻을 수 있다. 다음에는 RDF와 WSDL을 함께 사용하는 법을 설명하겠다.
참고자료
필자소개  | 
| Uche Ogbuji : 컨설턴트, Fourthought, Inc. |
기사에 대한 평가
| 
