Roger Wolter
Microsoft Corporation
요약: 이 기사는 SOAP, WSDL, UDDI 소개 및 개발자용 XML Web services 값의 개요를 설명합니다(6페이지/인쇄 페이지 기준).
목차
XML Web Service
XML Web services는 인터넷상에서 분산된 컴퓨팅으로 이동하는 데 기본이 되는 빌딩 블록입니다. 열린 표준과 통신 중심, 작업자 및 응용 프로그램간의 공동 작업으로 응용 프로그램을 통합하는 데 XML Web services가 플랫폼이 되는 환경을 만들었습니다. 응용 프로그램은 위치나 구현 방법과 상관없이 함께 작동하는 다양한 소스의 여러 XML Web services를 사용하여 구성됩니다.
XML Web Service를 만드는 회사가 많은 만큼 XML Web Service의 정의도 다양하겠지만 모든 정의에는 다음과 같은 공통점이 있습니다.
- XML Web Services는 표준 웹 프로토콜을 통해 웹 사용자들에게 유용한 기능을 표시합니다. 대부분의 경우 SOAP 프로토콜이 사용됩니다.
- XML Web services는 사용자와 대화할 수 있는 클라이언트 응용 프로그램을 만들 수 있는 인터페이스를 세부적으로 설명하는 방법을 제공합니다. 일반적으로 이 설명은 Web Services 설명 언어(WSDL) 문서라고 하는 XML 문서에 제공됩니다.
- XML Web services는 잠재적인 사용자가 XML Web services를 쉽게 찾을 수 있도록 등록됩니다. XML Web services는 UDDI(Universal Discovery Description and Integration)에 등록됩니다.
본 기사에서 위의 세가지 기술을 모두 설명하겠지만 XML Web services에 주의를 기울여야 하는 이유를 먼저 설명하겠습니다.
XML Web services 아키텍처의 주요 장점 중 하나는 별도의 플랫폼에 별도의 언어로 작성된 프로그램들이 표준 기반으로 서로 통신할 수 있다는 점입니다. 이 점에 대해 산업 분야에 종사했던 사람들은 DEC 이전과 CORBA에서도 같은 내용이 있었기 때문에 차이점이 없을 것 같다는 의문이 생길 수 있습니다. 첫 번째 차이점은 SOAP가 이전의 접근 방법보다 훨씬 간단하여 표준 규격의 SOAP 구현을 입력하는 작업이 더욱 용이하다는 것입니다. Paul Kulchenko는 79항목이 포함된 마지막 카운트인 http://www.soapware.org/directory/4/implementations 
에서 SOAP 구현 목록을 유지 관리합니다. SOAP 구현은 규모가 큰 소프트웨어 회사에서 찾을 수 있지만 개인 개발자가 작성하고 유지 관리하는 구현도 많이 찾을 수 있습니다. 이전에 비해 XML Web services가 갖는 또 다른 큰 장점은 표준 웹 프로토콜인 XML, HTTP 및 TCP/IP와 작동한다는 것입니다. 수 많은 회사들이 웹 인프라와 이를 유지 관리하는 지식과 경험이 있는 직원들을 갖추었기 때문에 XML Web services에 대한 항목에 소모되는 비용이 이전 기술에 비해 현저히 감소됩니다.
지금까지 WSDL 파일에 설명되고 UDDI에 등록된 XML Web service를 SOAP를 통해 웹에 나타나는 소프트웨어 서비스로 정의했습니다. 그 다음 논리적인 질문은 XML Web services로 무엇을 할 수 있는가 하는 것입니다. 처음에 XML Web services는 주식 시세, 일기 예보, 스포츠 등 응용 프로그램에 쉽게 통합될 수 있는 정보원이었습니다. 원하는 정보를 분석하고 집계하여 다양한 방법으로 표시하도록 작성할 수 있는 응용 프로그램이 있습니다. 예를 들어, Microsoft® Excel 스프레드시트를 사용하여 주식, 401K, 은행 계좌, 대출 등의 전체 금융 상태를 요약할 수 있습니다. 이 정보를 XML Web services에서 사용할 수 있는 경우 Excel은 이 Web services를 계속 업데이트합니다. 이 정보 중 일부는 무료이며 어떤 정보는 서비스 구독이 필요할 수도 있습니다. 대부분의 정보는 웹에서 현재 사용할 수 있지만 XML Web services는 더욱 쉽고 안정적인 프로그래밍 방식으로 액세스됩니다.
기존 응용 프로그램을 XML Web services로 나타내면 XML Web services를 빌딩 블록으로 사용하는 더욱 강력한 새 응용 프로그램을 작성할 수 있습니다. 예를 들어, 여러 공급업체의 가격 정보를 자동으로 얻을 수 있고 공급업체를 선택할 수 있으며 주문한 다음 제품이 도착할 때까지 배달 과정을 확인할 수 있습니다. 공급업체 응용 프로그램은 웹상에 서비스를 표시한 다음 XML Web services를 사용하여 고객의 신용 확인, 요금 부과 및 배달 회사에 배달을 의뢰할 수도 있습니다.
앞으로 몇몇 중요한 XML 웹 서비스를 사용하면 웹을 사용하는 응용 프로그램을 지원하여 오늘날에는 실행하지 못하는 사항들을 실행할 수 있게 될 것입니다. 예를 들어, 일정 관리 서비스는 Microsoft .NET My Services 프로젝트가 지원하는 서비스 중 하나입니다. 치과 의사나 정비사가 XML Web service를 사용하여 일정을 관리하는 경우 고객이 온라인으로 시간 약속을 예약하거나, 고객이 원할 경우 치과 의사나 정비사가 직접 고객과 청소 및 정기 점검 약속을 할 수 있습니다.조금만 생각해 보면, 웹을 프로그램할 수 있는 능력이 있기만 하면 작성할 수 있는 응용 프로그램이 많이 있습니다.
XML Web services 및 응용 프로그램 작성에 대한 더 자세한 내용은 MSDN Web services 홈 페이지를 참조하십시오.
SOAP
SOAP는 XML Web services용 통신 프로토콜입니다. SOAP를 통신 프로토콜로 설명하면 대부분의 사람들은 DCOM 또는 CORBA를 생각하고 "SOAP가 객체를 활성화하는 방법은 " 또는 "SOAP가 사용하는 이름 서비스는 " 등과 같은 질문을 합니다. SOAP 구현에 이러한 내용이 포함되기는 하지만 SOAP 표준은 이 내용을 지정하지 않습니다. SOAP는 메시지 즉, 요청된 사양의 일부에 대한 XML 형식을 정의하는 사양입니다. 몇몇 SOAP 요소에 포함된 올바른 형식의 XML 조각이 있는 경우 SOAP 메시지가 나타납니다. 간단합니다.
SOAP 사양의 다른 부분은 프로그램 데이터를 XML로 표시하고 SOAP를 사용하여 원격 프로시저 호출을 수행하는 방법을 설명합니다. 이러한 사양의 선택적 부품은 클라이언트에서 전송되는 SOAP 메시지에 호출 가능한 함수와 해당 함수에 전달되는 매개 변수가 포함되어 있는 RPC 스타일 응용 프로그램을 구현하는 데 사용되며 서버는 실행된 함수의 결과와 함께 메시지를 반환합니다. COM 또는 CORBA 응용 프로그램을 실행하는 프로그래머들은 RPC 스타일을 이해하기 때문에 현재 대부분의 SOAP 구현은 RPC 응용 프로그램을 지원합니다. 또한 SOAP는 SOAP 메시지가 XML 문서에서 래퍼 기능만 수행하는 문서 스타일 응용 프로그램도 지원합니다. 문서 스타일 SOAP 응용 프로그램은 매우 융통성이 있으며 여러 새 XML Web services는 이 장점을 활용하여 RPC를 사용하여 구현하기 어려운 서비스를 만듭니다.
SOAP 사양의 마지막 선택 부분은 SOAP 메시지를 포함한 HTTP 메시지의 형식을 정의합니다. HTTP 바인딩은 HTTP가 거의 모든 현재 OS 및 현재가 아닌 여러 OS에 의해 지원되기 때문에 중요합니다. HTTP 바인딩은 선택 사항이지만 SOAP에 대해 유일하게 표준화된 프로토콜이기 때문에 거의 모든 SOAP 구현은 HTTP 바인딩을 지원합니다. 이러한 이유로 인해 SOAP에 HTTP가 필요한 것으로 잘못 생각하는 경우가 있습니다. 몇몇 구현은 MSMQ, MQ 시리즈, SMTP 또는 TCP/IP 전송을 지원하지만 거의 모든 현재 XML Web services는 흔히 사용되는 HTTP를 사용합니다. HTTP는 핵심 웹 프로토콜이므로 대부분의 회사는 HTTP를 지원하는 네트워크 인프라와 이를 관리하는 인력을 갖추고 있습니다. 보안, 모니터링 및 HTTP에 대한 로드 균형 인프라는 오늘날 쉽게 사용할 수 있습니다.
SOAP를 시작할 때 혼동되는 주요 원인은 SOAP 사양과 여러 SOAP 사양 구현간의 차이점입니다. SOAP를 사용하는 대부분의 사람들은 SOAP 메시지를 직접 작성하지는 않지만 SOAP 도구 키트를 사용하여 SOAP 메시지를 만들고 구문 분석합니다. 일반적으로 이러한 도구 키트는 함수 호출을 몇몇 종류의 언어에서 SOAP 메시지로 변환합니다. 예를 들어, Microsoft SOAP Toolkit 2.0은 COM 함수 호출을 SOAP로 전환하고 Apache Toolkit는 JAVA 함수 호출을 SOAP로 변환합니다. 함수 호출의 유형과 지원되는 매개 변수의 데이터 유형은 각 SOAP 구현에 따라 다양하기 때문에 한 개의 도구 키트와 함께 작동하는 함수는 다른 도구 키트와 작동하지 않을 수도 있습니다. 이것은 SOAP의 제한 사항이 아니라 사용자가 사용하는 특정 구현입니다.
훨씬 강제적인 SOAP의 기능은 많은 별도의 하드웨어 및 소프트웨어 플랫폼에 구현되었다는 점입니다. 이것은 사용자의 회사 내부, 외부의 서로 다른 시스템을 연결하는 데 SOAP를 사용할 수 있다는 의미입니다. 과거에 시스템을 통합하는 일반 통신 프로토콜을 개발하려는 노력은 많았지만 아무도 SOAP를 일반적으로 채택하지는 않았습니다. 왜냐하면, SOAP는 이전의 많은 프로토콜에 비해 구현하는 데 훨씬 작고 단순했기 때문입니다. 예를 들어, DCE 및 CORBA는 구현하는 데 수 년이 걸렸기 때문에 소수의 구현만이 출시되었습니다. 그러나 SOAP는 기존의 XML 파서 및 HTTP 라이브러리를 사용하여 대부분의 힘든 작업을 수행하므로 수 개월 내에 SOAP 구현을 완료할 수 있습니다. 따라서 70종류의 SOAP 구현을 사용할 수 있습니다. SOAP는 DCE 또는 CORBA가 수행하는 작업을 모두 수행하지는 않지만 기능 교환이 복잡하지 않기 때문에 SOAP를 쉽게 사용할 수 있습니다.
HTTP의 보편성와 SOAP의 간소성이 동시에 존재하면 거의 모든 환경에서 호출할 수 있는 XML Web services를 구현하는 데 있어 이상적인 기반이 됩니다. SOAP에 대한 더 자세한 내용은 MSDN SOAP 홈 페이지를 참조하십시오.
보안
SOAP를 처음 사용하는 사람들의 첫 번째 질문 중 하나는 SOAP가 보안을 다루는 방법입니다. SOAP 개발 초기에는 SOAP가 HTTP 기반 프로토콜로 표시되어 HTTP 보안이 SOAP에 충분했습니다. 오늘날 수 많은 웹 응용 프로그램이 HTTP 보안을 사용하여 실행되므로 HTTP 보안은 SOAP에 충분합니다. 따라서 현재 SOAP 표준은 보안 문제보다는 전송 문제를 다룹니다.
SOAP가 여러 전송 작업에서 제대로 실행되는 보다 일반적인 용도의 프로토콜로 확장되면 보안은 더욱 큰 문제가 됩니다. 예를 들어, HTTP는 SOAP를 호출하는 사용자를 인증하는 몇 가지 방법을 제공하지만 메시지가 HTTP에서 SMTP로 전송될 때 해당 ID의 전파 방법에 대한 문제가 발생합니다. 다행히 SOAP는 빌딩 블록 프로토콜로 디자인되었기 때문에 SOAP를 작성하는 작업에 이미 사양이 포함되어 Web services에 대한 추가 보안 기능을 제공합니다. WS-Security specification 은 전체 암호화 시스템을 정의하고 WS-License specification 은 호출자의 ID와 권한이 부여된 사용자만 Web service를 사용할 수 있도록 하는 기술을 정의합니다.
WSDL
whiz-dull이라고도 하는 WSDL는 Web Services Description Language의 약어입니다. 편의상, WSDL 파일을 SOAP 메시지 집합 및 해당 메시지가 교환되는 방법을 설명하는 XML 문서라고 할 수 있습니다. 다시 말해서 WSDL은 IDL이 CORBA 또는 COM인 SOAP입니다. WSDL은 XML이기 때문에 읽을 수 있고 편집할 수 있지만 대부분의 경우에는 소프트웨어에 의해 작성되고 사용됩니다.
WSDL의 값을 보려면 비즈니스 파트너가 제공하는 SOAP 메서드를 호출해야 합니다. 비즈니스 파트너에게 몇몇 예제 SOAP 메시지를 요청하고 해당 예제와 같은 메시지를 작성하고 사용하는 응용 프로그램을 작성할 수 있으나, 오류가 발생하기 쉽습니다. 예를 들어, 고객 ID가 2387인 경우 메시지가 문자열이면 ID는 정수입니다. WSDL은 요청 메시지에 포함되는 사항과 응답 메시지의 형식을 명백한 노테이션으로 지정합니다.
WSDL 파일이 메시지 형식을 설명하기 위해 사용하는 노테이션은 XML 스키마 표준을 기반으로 하며, 이것은 프로그래밍 언어 중립적이며 또한 표준 기반이어서 다양한 플랫폼과 프로그래밍 언어에서 액세스할 수 있는 XML Web services 인터페이스를 설명하기에 적합하다는 것을 의미합니다. WSDL은 메시지 컨텐트를 설명할 뿐만 아니라 서비스를 사용할 수 있는 위치 및 서비스와 대화하는 데 사용되는 통신 프로토콜을 정의합니다. 즉, WSDL 파일은 XML Web service와 함께 작동하는 프로그램을 쓰는 데 필요한 모든 사항을 정의합니다. WSDL 파일을 읽고 XML Web service와 통신하는 데 필요한 코드를 생성할 수 있는 몇 가지 도구가 있습니다. 그 중에서 성능이 뛰어난 몇몇 도구들이 Microsoft Visual Studio® .NET에 있습니다.
많은 현재 SOAP 도구 키트에는 기존 프로그램 인터페이스에서 WSDL 파일을 생성하는 도구가 포함되지만 WSDL을 직접 작성하는 도구는 거의 없으며 WSDL에 대해 필요한 만큼 도구가 지원되지 않습니다. WSDL 파일 작성자에게 도구가 지원되어 COM IDL과 같은 프록시 및 스텁을 작성하는 것은 대부분의 SOAP 구현의 일부분이 됩니다. 이런 점에서 WSDL은 XML Web services에 대한 SOAP 인터페이스를 만드는 데 좋은 방법입니다.
http://www.w3.org/TR/wsdl 에서 WSDL 사양을 볼 수 있으며 우수한 description of WSDL을 사용할 수 있습니다.
UDDI
UDDI(Universal Discovery Description 및 Integration)는 Web services의 옐로 페이지입니다. 전통적인 옐로 페이지에서는 필요한 서비스를 제공하는 회사를 찾아 제공된 서비스를 검토한 후에 담당자와 연락하여 자세한 정보를 구할 수 있습니다. 지하실에서 비즈니스를 시작하고 말로 광고를 할 수 있는 것처럼 UDDI에 등록하지 않고도 Web service를 제공할 수는 있습니다. 그러나 시장을 넓히기 위해서는 고객이 Web services를 찾을 수 있도록 UDDI에 등록해야 합니다.
UDDI 디렉터리 항목은 비즈니스 및 제공되는 서비스를 설명하는 XML 파일입니다. UDDI 디렉터리의 항목은 세 부분으로 되어 있습니다. "화이트 페이지"는 서비스를 제공하는 회사의 이름, 주소, 연락처 등을 설명합니다. "옐로 페이지"에는 북미 산업 분류 시스템 및 표준 산업 분류 등과 같은 표준 분류법을 기반으로 하는 산업 범주가 나와 있습니다. "그린 페이지"는 Web service를 사용하는 응용 프로그램을 작성할 수 있도록 서비스에 인터페이스를 세부적으로 설명합니다. 서비스 방법은 유형 모델 또는 tModel이라고도 하는 UDDI 문서를 통해 정의됩니다. 많은 경우에, tModel에는 XML Web service에 SOAP 인터페이스를 설명하는 WSDL 파일이 포함되어 있지만 tModel은 융통성이 있어 거의 모든 종류의 서비스를 설명할 수 있습니다.
또한 UDDI 디렉터리에는 사용자의 응용 프로그램을 작성하는 데 필요한 서비스를 검색하는 몇 가지 방법이 있습니다. 예를 들어, 지정된 지역 및 지정된 유형의 비즈니스로 서비스 공급자를 검색할 수 있습니다. 그런 다음 UDDI 디렉터리는 정보, 연락처, 링크 및 기술적인 데이터를 공급하여 사용자의 요구 사항에 맞는 서비스를 평가할 수 있도록 합니다.
UDDI를 사용하여 Web services를 얻을 수 있는 비즈니스를 찾을 수 있습니다. 비즈니스 파트너는 알고 있지만 제공되는 서비스가 무엇인지 모를 경우에는 WS-Inspection specification 을 사용하여 특정 서버에 제공된 XML Web services의 컬렉션을 검색하여 필요한 서비스를 찾을 수 있습니다.
UDDI에 대한 더 자세한 내용은 http://www.uddi.org/about.html 를 참조하십시오.
기타
지금까지 XML Web services와의 대화 방법(SOAP), XML Web services 설명 방법(WSDL) 및 XML Web services 찾는 방법(UDDI)에 대해 설명했습니다. 이러한 사항들은 응용 프로그램 통계 및 집계에 대한 기초를 제공하는 기준 사양 집합을 구성합니다. 회사는 기준 사양을 이용하여 실제 솔루션을 구축하고 실제 값을 얻습니다.
실제 XML Web services를 만드는 데 많은 노력을 해왔지만 앞으로 더욱 많은 노력이 필요합니다. 오늘날 XML Web services를 성공적으로 작성하고는 있지만 보안, 운영 관리, 트랜잭션, 안정된 메시징과 같이 개발자가 개발해야 할 사항들이 여전히 남아 있습니다. 전역 XML Web Services 아키텍처는 모듈화 및 확장 가능한 XML Web services에 새 고급 기능을 추가하는 데 정확한 다용도 모델을 제공하여 XML Web services를 다음 단계로 이동할 수 있도록 도와줍니다.
위에서 언급한 보안 모듈(WS-Security 및 WS-License) 은 전역 Web Services 아키텍처의 사양 중 일부입니다. 운영 관리를 프로세싱하려면 여러 서버 간에 메시지를 라우팅하고 해당 서버를 동적으로 구성해야 하는데 이러한 작업도 전역 Web Services 아키텍처의 일부이며 WS-Routing specification 및 WS-Referral specification 과 일치합니다. 전역 Web Services 아키텍처가 발전함에 따라 해당 사양 및 기타 필요 사항이 소개됩니다.
더 자세한 내용은 Global XML Web Services Architecture 를 참조하십시오.
