WebService를 위한 표준
홍영준
들어가면서
지난 2000년 8월, Microsoft사의 NGWS(New Generation Windows Service)와 함께 대중적으로 WebService가 알려지기 시작했다. 이후 NGWS는 .NET이란 이름으로 변경이 되어졌고 베타 1이 출시되었으며, 이제 막 베타 2가 출시되었다. 이후 사람들은 실제 .NET 프레임워크를 이용하여 편리하게 WebService를 구축하기 시작했으며 그 가능성이 전파되고 있다.
WebService는 소위 말하는 XML형태의 RPC 프로토콜이다. 물론 XML-RPC, XMOP(XML Metadata Object Persistence)과 같은 표준이 있기는 하지만, XML-RPC, XMOP는 널리 받아들여지지 못했다. 이때 SOAP (Simple Object Access Protocol)이 새롭게 등장했다. SOAP 0.9 스팩은 기존의 COM을 기초로 하여 Microsoft사를 주축으로 1999년 처음 세상에 등장했으며 1999년 11월 1.0을 그리고 2000년 4월 1.1 버전(http://www.w3.org/TR/SOAP/)이 그리고 현재는 1.2 버전(http://www.w3.org/TR/2001/WD-soap12-20010709/)이 발표되었다. 뿐만 아니라 관련된 프로토콜들이 속속 등장했으며 그 중 가장 주목할 것들은 바로 SOAP과 함께 WSDL(Web Service Description Language), DISCO(Web Services Discovery), UDDI(Universal Description, Discovery and Integration) 같은 것들이 있다.
이후 WebService는 W3C표준 절차를 밟고 있을 뿐 아니라, IBM, Oracle, SUN, Borland 같은 주요 벤더들에게 폭넓게 지지를 받고 있으며 각 벤더들의 주요 개발 툴들은 이 WebService를 수용하기 위해서 끊임없이 노력하고 있다.
WebService는 향후 IT분야에 큰 변화를 초래할 것이다. 이것은 마치 FTP 같은 파일 전송 프로토콜에서 시작한 인터넷이 RPC(Remote Procedure Protocol)로 클라이언트/서버 환경의 중요 인프라로 떠올랐듯이, WebService는 HTML 기반의 페이지 서비스로써의 웹을 진정한 분산 어플리케이션의 중요 인프라로 만들어 줄 것이다. 그러므로 앞으로 웹 프로그래밍의 수준이 이전과는 완전히 달라지게 될 것이다.
기존 분산 어플리케이션 환경의 문제점
앞서 WebService는 XML 기반의 RPC 프로토콜이라고 전제 했다. 좀더 자세하게 말하면 ORPC(Object RPC)라고 하는 것이 맞을 것이다. RPC와 ORPC의 차이는 Object RPC의 경우 RPC의 endpoint를 실제 프로그래밍 언어의 객체로 매핑시킬 수 있는 기능을 제공하고 있다는 것이다. 즉, 통신 프로토콜과 객체 지향의 결합이라고 할 수 있다. 현재 가장 많이 사용되고 있는 ORPC 기반의 분산 어플리케이션 환경으로 DCOM, CORBA, JAVA RMI같은 것들이 있다. 물론 DCOM의 경우 ORPC, CORBA의 경우 IIOP(Internet Inter-ORB Protocol (IIOP)), JAVA RMI의 경우 JRMP(Java Remote Method Protocol)로 그 이름은 약간 씩 다를 수 있다.
그러나 이러한 프로토콜들은 모두 현재의 인터넷 환경을 고려하지 않고 만들어 진 것들이며, 대체로 아래와 같은 한계를 가진다.
첫째, 단일 벤더의 솔루션이라는 한계
DCOM 뿐 아니라 JCP, OMG에서 관리하고 있는 JAVA RMI, CORBA 조차도 실제로는 단일 벤더의 솔루션이라고 할 수 있다. 즉, 실제 클라이언트/서버를 연결할 경우 동일한 벤더의 제품을 사용해야만 다양한 서비스를 연결할 수 있다. 이는 구현의 수준과 내부 프로토콜, 그리고 벤더마다 다른 최적화 기법을 사용함으로써 기인하는 것이다. 그러나 이는 현재의 다양한 환경을 기반으로 하고 있는 인터넷 구성 요소에 적합하지 않다.
둘째, 관리가 가능한 네트워크 환경을 기반
기존의 솔루션들은 모두 관리가 가능한 네트워크 환경을 기반하고 있다. 즉, 신뢰성 있고 보안에 대한 설정 및 관리가 가능한 네트워크 환경에 기반하고 있다. 이러한 특징을 tightly coupled 라고 표현하는데, 이러한 점 역시 현재의 인터넷 환경에 적합하지 않다.
셋째, 고 수준의 실행 환경을 요구한다.
기존의 분산 어플리케이션 환경들은 다양한 분야에 동일한 고 수준의 서비스(객체 생성, 객체 라이프타임 관리,보안…)를 적용시키기를 강요한다. 결과적으로 각 솔루션들을 위한 실행 환경 구현 비용이 증가되며 벤더 종속적인 구현을 부채질하는 요인이 되기도 한다.
넷째, 방화벽/프락시 서버 문제
현대 인터넷 환경에서 빠질 수 없는 것이 바로 방화벽과 프락시 서버이다. 기존의 분산 어플리케이션 환경들은 모두 이 두 가지를 고려하고 있지 않다. 그러므로 만약 이러한 것들을 기초로 분산 환경을 구축할 경우, 방화벽과 프락시 서버를 제거하고 각 구성 요소는 직접 인터넷에 연결되어야 한다. 이것은 사실상 불가능한 일이다.
기타 DCOM의 경우 ping 에 기초한 분산 가비지 컬렉션, 그리고 JAVA RMI의 상태 관리 로 인해 스케일러블한 환경을 구성하기가 쉽지 않다.
이러한 문제들로 기존의 솔루션들이 인터넷 환경에서 그렇게 많이 활용되고 있지 않다. SOAP은 기존의 솔루션이 가지는 이러한 단점을 극복하고자 설계 되었다. 결과적으로 현재 각 솔루션을 주도하고 있는 각 벤더들은 다양한 이름(.NET SUN ONE, HP Netaction,…)으로 WebService 솔루션에 치중하고 있다.
SOAP (Simple Object Access Protocol)
먼저 WebService의 핵심 프로토콜로 SOAP을 소개하도록 하겠다. SOAP 표준은 크게 두 가지를 정의하고 있다. 바로 메시징 시스템 기술과 함께 XML 데이터 표현, 즉 XML 스키마 정의에 대한 부분이며, 객체 생성, 객체 생명 주기, 보안, 전송 프로토콜과 같은 이슈들은 모두 기존의 인프라를 이용토록 설계되어 있다.
SOAP의 메시징 시스템
SOAP 1.0의 경우 기본 전송 프로토콜로 HTTP를 기초로 작성되었다. 그러나 1.2에서는 이것을 메시징 시스템과 원격 프로시져 호출에 필요한 XML 데이터 표현 방식으로 분리시켰다. 즉, SOAP 1.2의 경우 전송 프로토콜로 SMTP, FTP같은 프로토콜을 사용할 수 있는 가능성을 열어 둔 것이다.
전송 프로토콜에 독립적이라 할 지라도 서버 상의 메쏘드를 호출하기 위하여 필요한 과정이 있다. SOAP를 RPC로 사용하기 위하여 필요한 과정이 바로 Request/Response이며 HTTP를 전송 프로토콜을 이용할 경우, 자연스럽게 이러한 과정들은 HTTP Request/Response에 대응되게 된다.
기본적으로는 HTTP POST 방식의 Request를 사용하나 SOAP HTTP Request임을 의미하기 위하여 M-POST를 권장하고 있다.
아래 리스트는 각기 POST 방식의 SOAP HTTP Request와 M-POST방식의 SOAP HTTP Request를 나타낸다.
-------------------------------------------------------------------
M-POST /StockQuote HTTP/1.1
Man: "http://www.w3.org/2001/06/soap-envelope"; ns=NNNN
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
NNNN-SOAPAction: "http://electrocommerce.org/abc#MyMessage"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
. . .
</env:Envelope>
-------------------------------------------------------------------
리스트 1. HTTP Extension Framework 를 이용한 SOAP Request
-------------------------------------------------------------------
POST /StockQuote HTTP/1.1
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "http://electrocommerce.org/abc#MyMessage"
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
. . .
</env:Envelope>
-------------------------------------------------------------------
리스트 2. POST를 이용한 SOAP HTTP Request
위의 SOAP HTTP Request의 <env:Envelope/>에 해당하는 부분이 실제 메쏘드 호출에 필요한 정보를 담고 있는 XML 데이터이다. 이와 같은 SOAP HTTP Request에 대해 서버는 적당한 메쏘드를 호출한 후 그 결과를 SOAP HTTP Response로 반환하게 된다. 아래는 SOAP HTTP Response의 한 예이다.
-------------------------------------------------------------------
HTTP/1.1 200 OK
Ext:
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
. . .
</env:Envelope>
-------------------------------------------------------------------
리스트 3. SOAP HTTP Response
역시 <env:Envelope/>에 해당하는 부분이 실제 결과를 표현한 XML 데이터이다.
SOAP Envelope
앞서 기술한 메시징 시스템, 특히 HTTP을 기반으로 한 RPC 시스템에서 실제 메쏘드 호출 및 결과에 대한 데이터 표현을 위해서 사용되는 것이 바로 SOAP Envelope이다. SOAP Envelope은 XML Schema 및 XML Namespace 표준을 이용해서 기술되었다. SOAP Envelop은 크게 메쏘드 호출, 메쏘드 호출 결과 반환, 그리고 메쏘드 호출 및 결과 반환 시 사용할 데이터 타입에 대한 정의로 나눌 수 있다. 아래는 메쏘드 호출 시, 사용되는 SOAP Envelope의 한 예이다.
-------------------------------------------------------------------
<SOAP-ENV:Envelope>
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/>
<SOAP-ENV:Header>
<r:Transaction xmlns:r="http://example.org/2001/06/tx" env:mustUnderstand="1" > 2
</r:RequestNumber>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetTemperature xmlns:m=”Thermostat-URI”>
<City>
<State>FL</State>
</m:GetTemperature>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-------------------------------------------------------------------
리스트 4. 메쏘드 호출을 위한 SOAP Envelope
위의 리스트 4.에서 보듯이 SOAP Envelope는 크게 헤더와 본문으로 구분되어져 있다. 본문의 경우 실제 메쏘드 호출에 필요한 정보, 즉 메쏘드 이름과 인자 값을 기술하며(위의 경우 GetTemperature 메쏘드와 City, State 인자), 헤더의 경우는 기타 추가적인 정보(트랜잭션, 인증,…)를 기술하는 데 사용되어진다.
메쏘드 호출에 대한 결과를 전송하기 위해서 역시 SOAP Envelope이 사용된다. 이러한 결과는 크게 성공적인 실행 결과의 반환 혹은 실행 오류에 대한 내용이 될 것이다. 아래 리스트 5는 성공적인 실행 결과를 반환하는 SOAP Envelope의 예이다.
-------------------------------------------------------------------
<env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" >
<env:Header>
<t:Transaction xmlns:t="http://example.org/2001/06/tx"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:int"
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
env:mustUnderstand="1" >
5
</t:Transaction>
</env:Header>
<env:Body>
<m:GetLastTradePriceResponse
env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"
xmlns:m="http://example.org/2001/06/quotes" >
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</env:Body>
</env:Envelope>
-------------------------------------------------------------------
리스트 5. 메쏘드 실행 Request에 대한 결과 값 반환
메쏘드 호출 실패의 경우는 크게 HTTP Request 처리의 실패와 메쏘드 실행 시 발생하는 어플리케이션 오류가 있을 수 있다. 전자의 경우 HTTP 에러 코드가 반환되어 질 것이며 후자의 경우는 SOAP Fault가 반환되어진다.
사실 개발자가 SOAP에 대해 자세한 스팩을 세세하게 알 필요는 없을 것이다. 점점 더 개발자들은 자신의 언어와 플랫폼으로 프로그램을 작성하고 실제 SOAP 프로토콜로 투명하게 매핑되는 환경에서 작업하게 될 것이 분명하다. 예를 들어 .NET Framework를 사용하는 개발자라면 ASP.NET WebService 혹은 .NET Remoting 서비스를 이용해서 부가적인 지식 없이 WebService 어플리케이션을 작성하게 될 것이다. 그러나 어플리케이션의 설계 시 SOAP 프로토콜의 기능과 제약 사항을 이해하는 것이 매우 중요하며, SOAP을 이용한 분산 어플리케이션의 디버깅 시 이 SOAP에 대한 이해가 필요하다. 네트워크 모니터링 툴을 이용하여 분산 어플리케이션 간에 발생하는 SOAP payload를 조사할 수 있으므로 관심 있는 독자들은 시도해보기 바란다.
WSDL (Web Service Description Language)
SOAP이 실제 메쏘드 호출에 필요한 데이터를 전송한다면, WSDL은 IDL(Interface Definition Language)과 동일한 역할을 한다. WSDL을 이용하여 WebService 제공자는 사용자에게 해당 WebService의 정확한 인터페이스와 사용되는 데이터 타입, 그리고 전송 프로토콜에 대한 상세 정보를 전달 할 수 있다. WSDL은 SDL로 출발하여 현재 1.1버전(http://www.w3.org/TR/wsdl)이 Microsoft사와 IBM사에 의해 작성되어 있으며 역시 주요 벤더들로부터 폭넓은 지지를 받고 있다.
WSDL 문서는 Types, Messages, PortType, Binding, Services에 대한 영역들로 구성되어져 있다. Types의 경우 해당 WebService가 사용하는 데이터 타입에 대해 기술하고 있다. 사용 가능한 타입으로는 XML Schema에서 정의한 기본형, 복합 형, 그리고 배열을 사용할 수 있다. 기본적으로 XML Schema 에서 정의한 데이터 타입을 사용하고 있지만 배열의 경우 SOAP에서 정의한 데이터 타입을 사용하기도 한다. Messages의 경우 실제 SOAP Envelope에 대한 스키마를 정의하고 있는 부분이다. 예를 들어 int foo(int arg); 메쏘드에 대한 호출을 표현하기 위하여 WSDL의 message 요소가 아래와 같이 정의되어 있다면,
-------------------------------------------------------------------
<message name="Simple.foo">
<part name="arg" type="xsd:int"/>
</message>
<message name="Simple.fooResponse">
<part name="result" type="xsd:int"/>
</message>
-------------------------------------------------------------------
이에 해당하는 실제 SOAP Envelope는 아래와 같이 될 것이다.
-------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<m:foo xmlns:m="http://tempuri.org/message/">
<arg>5131953</arg>
</m:foo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAPSDK1:fooResponse xmlns:SOAPSDK1="http://tempuri.org/message/">
<result>5131953</result>
</SOAPSDK1:fooResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
-------------------------------------------------------------------
portType은 위와 같은 SOAP Envelope를 사용하는 실제 메쏘드 시그너처를 기술하고 있다. 즉, portType은 Messages 영역을 참조하게 된다.
-------------------------------------------------------------------
<portType name="fooSamplePortType">
<operation name="foo" parameterOrder="arg " >
<input name="foo1" message="wsdlns:foo1"/>
</operation>
<operation name="foo" parameterOrder="arg " >
<input name="foo2" message="wsdlns:foo2"/>
</operation>
</portType>
-------------------------------------------------------------------
위는 portType 영역이며 foo 메쏘드가 foo1 Message와 foo2 Message을 SOAP Envelope으로 사용한다는 것을 의미한다. 위의 경우 메쏘드 이름이 모두 foo 인데 이는 메쏘드 오버로딩을 의미한다. 즉, 메쏘드 이름은 같다하더라도 사용하는 SOAP Envelope은 다른 것이다.
앞서 설명한 Types, Messages, PortType 영역이 메쏘드 호출 시 필요한 정보를 기술한다면 Binding과 Services 영역은 실제 물리적 수준의 인코딩 방식, 프로토콜 종류, 그리고 서비스를 제공하는 실제 URL을 나타낸다. 그러므로 WebService 제공자로부터 WSDL을 제공 받은 사용자는 해당 서비스에 대한 메쏘드 시그너쳐 뿐 아니라 사용하는 데이터 타입, 그리고 프로토콜, 인코딩 방식 및 서비스를 제공 URL에 대한 모든 정보를 얻을 수 있다. 이는 이후 해당 서비스에 대한 프록시를 자동으로 생성하는 데 사용되어질 수도 있다. 실제 WSDL에 대한 상세한 기술도 개발자는 무시할 수 있다. 왜냐면 이 모든 과정 역시 진정한 WebService 플랫폼이라면 모두 개발자에게 투명하게 처리할 수 있어야 하기 때문이다. 예를 들어 .NET Framework의 경우 WSDL은 아래와 같이 ASP.NET을 제공하는 URL에 WSDL이라는 인자를 줌으로써 자동으로 추출이 가능하다. 즉, 개발자는 자신이 제공하고자 하는 서비스를 .NET Framework에서 동작하는 각종 언어로 기술하고 이에 해당하는 WSDL 파일은 자동으로 추출하는 것이다. 이렇게 추출된 WSDL은 역시 .NET Framework SDK에서 제공하는 wsdl 유틸리티를 이용하여 간단하게 원하는 언어로 작성된 프락시를 생성할 수 있게 한다.
-------------------------------------------------------------------
http://www.webservice.com/Stock.asmx?WSDL
wsdl c:\service\Stock.wsdl /language:cs
-------------------------------------------------------------------
DISCO (WebService Discovery)
WebService Discovery는 WSDL에 대한 위치 지정 서비스라고 할 수 있다. 즉, 해당 서버는 자신 혹은 자신과 관련된 WebService를 기술한 WSDL 파일에 대한 위치 정보를 DISCO파일에 기술할 수 있다. DISCO는 크게 두 가지 형태가 있는데, 동적 DISCO와 수동 DISCO가 그것이다. 수동 DISCO의 경우 필요한 WSDL파일의 URL을 직접 기술하는 데 사용된다.
-------------------------------------------------------------------
<?xml version="1.0" ?>
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco"
xmlns:scl="http://schemas.xmlsoap.org/disco/scl">
<scl:contractRef ref="http://MyWebServer/UserName.asmx?WSDL"/>
</disco:discovery>
-------------------------------------------------------------------
앞서 말한 바와 같이 ASP.NET WebService의 경우 실제 서비스를 제공하는 URL에 WSDL이라는 인자를 사용하여 WSDL을 생성한다고 했다. 그러므로 위의 DISCO 파일은 실제 WSDL의 위치를 지정하고 있다고 할 수 있다.
동적 DISCO의 경우는 해당 웹 어플리케이션 내의 모든 WebService에 대한 WSDL의 위치를 자동으로 찾아주는 데 사용된다.
-------------------------------------------------------------------
<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco/">
</disco:discovery>
-------------------------------------------------------------------
동적 DISCO, 및 수동 DISCO는 ASP.NET WebService의 경우 모두 .vsdisco라는 확장자로 기술되어진다.
UDDI (Universal Description, Discovery and Integration)
UDDI(www.uddi.org)는 Microsoft, IBM, Ariba가 추축이 되어서 제안한 WebService 에 대한 디렉토리 서비스며 현재 2.0까지 발표되었다. 물론 Microsoft, SUN, Oracle, IBM같은 주요 벤더들의 폭넓은 지지를 받고 있다. WebService 제공자들은 UDDI를 이용하여 자신이 제공하는 서비스에 대한 정보를 등록하고, 사용자들은 UDDI 서비스를 이용하여 자신이 원하는 WebService를 제공하는 서비스 제공자에 대한 정보를 받게 된다. UDDI 서비스의 핵심은 UDDI Business Registration이라고 할 수 있다. 이것은 WebService 제공자와 제공자가 서비스 중인 WebService에 대한 정보를 기술하고 있는 XML 데이터이다. 이러한 Business Registration은 크게 White Pages, Yellow Pages, Green Pages로 나눌 수 있다. White Pages의 경우 WebService를 제공하고자 하는 사업자의 주소, 전화 번호, 이름과 같은 정보를 포함하고 있다. Yellow Pages의 경우 Universal Standard Products and Services Codes, ISO 3166 Geographic Taxonomy 같은 표준적인 산업 분류법에 따라 제공자들을 분류해 놓았다. 그리고 Green Pages는 실제 WebService를 제공하는 URL 및 WSDL 같은 기술적인 사항을 포함하고 있다.
이러
'Dev... > 웹서비스' 카테고리의 다른 글
| [펌] WebService Behavior (0) | 2005.01.29 |
|---|---|
| [펌] WebService의 간략한 소개 (0) | 2005.01.29 |
| [펌] ASP.NET을 사용하여 만든 XML Web services의 상태 관리 (0) | 2005.01.29 |
| [펌] webservice (0) | 2005.01.29 |
| [펌] SOAP 인코딩이 웹 서비스 퍼포먼스에 미치는 영향 (0) | 2005.01.29 |
