Share via

XML Web Services 기본 사항

  • 아티클

 

로저 울터
Microsoft Corporation

2001년 12월

요약: SOAP, WSDL 및 UDDI를 소개하는 개발자를 위한 XML 웹 서비스의 가치에 대한 개요입니다. (인쇄된 페이지 6개)

콘텐츠

XML 웹 서비스란?
SOAP
WSDL
UDDI
남은 것은 무엇인가요?

XML 웹 서비스란?

XML 웹 서비스는 인터넷에서 분산 컴퓨팅으로 이동하는 기본 구성 요소입니다. 개방형 표준과 사용자와 애플리케이션 간의 통신 및 협업에 중점을 두어 XML 웹 서비스가 애플리케이션 통합을 위한 플랫폼이 되는 환경을 만들었습니다. 애플리케이션은 상주 위치 또는 구현 방법에 관계없이 함께 작동하는 다양한 원본의 여러 XML 웹 서비스를 사용하여 생성됩니다.

XML 웹 서비스에 대한 정의는 빌드하는 회사만큼 많을 수 있지만 거의 모든 정의에는 다음과 같은 공통점이 있습니다.

  • XML Web Services는 표준 웹 프로토콜을 통해 웹 사용자에게 유용한 기능을 노출합니다. 대부분의 경우 사용되는 프로토콜은 SOAP입니다.
  • XML 웹 서비스는 사용자가 클라이언트 애플리케이션을 빌드하여 통신할 수 있도록 인터페이스를 자세히 설명하는 방법을 제공합니다. 이 설명은 일반적으로 WSDL(Web Services Description Language) 문서라는 XML 문서에 제공됩니다.
  • XML 웹 서비스는 잠재적 사용자가 쉽게 찾을 수 있도록 등록됩니다. 이 작업은 UDDI(유니버설 검색 설명 및 통합)를 사용하여 수행됩니다.

이 문서에서는 이러한 세 가지 기술을 모두 다루겠지만 먼저 XML 웹 서비스에 관심을 가져야 하는 이유를 설명하겠습니다.

XML 웹 서비스 아키텍처의 주요 이점 중 하나는 서로 다른 플랫폼의 다른 언어로 작성된 프로그램이 표준 기반 방식으로 서로 통신할 수 있다는 것입니다. 한동안 업계에 종사해 온 분들은 이제 "잠깐 만요! CORBA와 그 DCE 이전의 동일한 약속을 듣지 못했나요? 어떻게 다른가요?" 첫 번째 차이점은 SOAP가 이전 접근 방식보다 훨씬 덜 복잡하기 때문에 표준 규격 SOAP 구현에 대한 진입 장벽이 훨씬 낮다는 것입니다. Paul Kulchenko는 SOAP 구현 목록을 유지 관리합니다 http://www.soapware.org/directory/4/implementations . 마지막으로 79개의 항목이 포함되었습니다. 예상대로 대부분의 대형 소프트웨어 회사에서 SOAP 구현을 찾을 수 있지만 단일 개발자가 빌드하고 유지 관리하는 많은 구현도 찾을 수 있습니다. XML 웹 서비스가 이전 작업보다 갖는 다른 중요한 이점은 표준 웹 프로토콜(XML, HTTP 및 TCP/IP)에서 작동한다는 것입니다. 많은 회사에 이미 웹 인프라가 있으며, 웹 인프라를 유지 관리하는 데 대한 지식과 경험이 있는 사용자가 있으므로 XML 웹 서비스에 대한 진입 비용은 이전 기술보다 훨씬 적습니다.

XML 웹 서비스를 SOAP를 통해 웹에 노출되고 WSDL 파일로 설명되고 UDDI에 등록된 소프트웨어 서비스로 정의했습니다. 다음 논리적 질문은 입니다. "XML 웹 서비스로 무엇을 할 수 있나요?" 첫 번째 XML 웹 서비스는 주식 시세, 일기 예보, 스포츠 점수 등 애플리케이션에 쉽게 통합할 수 있는 정보 원본인 경향이 있었습니다. 관심 있는 정보를 분석하고 집계하여 다양한 방법으로 사용자에게 표시하도록 빌드할 수 있는 애플리케이션의 전체 클래스를 쉽게 상상할 수 있습니다. 예를 들어 주식, 401K, 은행 계좌, 대출 등 전체 재무 그림을 요약한 Microsoft® Excel 스프레드시트가 있을 수 있습니다. 이 정보를 XML 웹 서비스를 통해 사용할 수 있는 경우 Excel에서 지속적으로 업데이트할 수 있습니다. 이 정보 중 일부는 무료이며 일부는 서비스에 대한 구독이 필요할 수 있습니다. 이 정보의 대부분은 현재 웹에서 사용할 수 있지만 XML 웹 서비스는 프로그래밍 방식으로 더 쉽고 안정적으로 액세스할 수 있도록 합니다.

기존 애플리케이션을 XML 웹 서비스로 노출하면 사용자가 XML 웹 서비스를 구성 요소로 사용하는 새롭고 강력한 애플리케이션을 빌드할 수 있습니다. 예를 들어 사용자는 구매 애플리케이션을 개발하여 다양한 공급업체로부터 가격 정보를 자동으로 가져오고, 사용자가 공급업체를 선택하고, 주문을 제출한 다음, 배송이 수신될 때까지 배송을 추적할 수 있습니다. 공급업체 애플리케이션은 웹에 서비스를 노출하는 것 외에도 XML 웹 서비스를 사용하여 고객의 신용을 검사 고객의 계정을 청구하고 배송 회사와 함께 배송을 설정할 수 있습니다.

나중에 가장 흥미로운 XML 웹 서비스 중 일부는 웹을 사용하여 현재 수행할 수 없는 작업을 수행하는 애플리케이션을 지원합니다. 예를 들어 XML Web Services에서 사용할 수 있는 서비스 중 하나는 일정 서비스입니다. 치과 의사와 정비사가 이 XML 웹 서비스를 통해 일정을 노출한 경우 약속을 줄에 예약하거나 원하는 경우 일정에서 직접 청소 및 일상적인 유지 관리를 위한 약속을 예약할 수 있습니다. 약간의 상상력으로 웹을 프로그래밍할 수 있게 되면 빌드할 수 있는 수백 개의 애플리케이션을 구상할 수 있습니다.

XML 웹 서비스 및 빌드에 도움이 되는 애플리케이션에 대한 자세한 내용은 MSDN XML Web Services 개발자 센터를 참조하세요.

SOAP

Soap은 XML 웹 서비스에 대한 통신 프로토콜입니다. SOAP가 통신 프로토콜로 설명될 때 대부분의 사람들은 DCOM 또는 CORBA를 생각하고 "SOAP는 개체 활성화를 어떻게 하나요?" 또는 "SOAP가 어떤 명명 서비스를 사용하나요?"와 같은 질문을 시작합니다. SOAP 구현에는 이러한 항목이 포함될 수 있지만 SOAP 표준은 지정하지 않습니다. SOAP는 메시지에 대한 XML 형식을 정의하는 사양이며, 이는 사양의 필수 부분에 대한 것입니다. 올바른 형식의 XML 조각이 SOAP 요소 몇 개로 묶인 경우 SOAP 메시지가 표시됩니다. 간단하지 않습니까?

프로그램 데이터를 XML로 나타내는 방법과 SOAP를 사용하여 원격 프로시저 호출을 수행하는 방법을 설명하는 SOAP 사양의 다른 부분이 있습니다. 사양의 이러한 선택적 부분은 호출 가능한 함수가 포함된 SOAP 메시지와 함수에 전달할 매개 변수가 클라이언트에서 전송되고 서버가 실행된 함수의 결과와 함께 메시지를 반환하는 RPC 스타일 애플리케이션을 구현하는 데 사용됩니다. SOAP의 최신 구현은 COM 또는 CORBA 애플리케이션을 수행하는 데 사용되는 프로그래머가 RPC 스타일을 이해하기 때문에 RPC 애플리케이션을 지원합니다. SOAP는 SOAP 메시지가 XML 문서의 래퍼일 뿐인 문서 스타일 애플리케이션도 지원합니다. 문서 스타일 SOAP 애플리케이션은 매우 유연하며 많은 새로운 XML 웹 서비스가 이러한 유연성을 활용하여 RPC를 사용하여 구현하기 어려운 서비스를 빌드합니다.

SOAP 사양의 마지막 선택적 부분은 SOAP 메시지가 포함된 HTTP 메시지의 모양을 정의합니다. HTTP는 거의 모든 현재 OS(및 현재가 아닌 많은 OS)에서 지원되므로 이 HTTP 바인딩은 중요합니다. HTTP 바인딩은 선택 사항이지만 SOAP에 대한 유일한 표준화된 프로토콜이기 때문에 거의 모든 SOAP 구현이 이를 지원합니다. 이러한 이유로 SOAP에 HTTP가 필요하다는 일반적인 오해가 있습니다. 일부 구현은 MSMQ, MQ 시리즈, SMTP 또는 TCP/IP 전송을 지원하지만 거의 모든 현재 XML 웹 서비스는 유비쿼터스이므로 HTTP를 사용합니다. HTTP는 웹의 핵심 프로토콜이므로 대부분의 조직에는 HTTP를 지원하는 네트워크 인프라와 이미 관리하는 방법을 이해하는 사람들이 있습니다. HTTP에 대한 보안, 모니터링 및 부하 분산 인프라는 현재 쉽게 사용할 수 있습니다.

SOAP를 시작할 때 혼동의 주요 소스는 SOAP 사양과 SOAP 사양의 많은 구현 간의 차이입니다. SOAP를 사용하는 대부분의 사람들은 SOAP 메시지를 직접 작성하지 않고 SOAP 도구 키트를 사용하여 SOAP 메시지를 만들고 구문 분석합니다. 이러한 도구 키트는 일반적으로 함수 호출을 일종의 언어에서 SOAP 메시지로 변환합니다. 예를 들어 Microsoft SOAP Toolkit 2.0은 COM 함수 호출을 SOAP로 변환하고 Apache 도구 키트는 JAVA 함수 호출을 SOAP로 변환합니다. 함수 호출 형식 및 지원되는 매개 변수의 데이터 형식은 각 SOAP 구현에 따라 다르므로 한 도구 키트에서 작동하는 함수가 다른 도구 키트에서 작동하지 않을 수 있습니다. 이는 SOAP의 제한이 아니라 사용 중인 특정 구현의 제한 사항입니다.

지금까지 SOAP의 가장 매력적인 기능은 다양한 하드웨어 및 소프트웨어 플랫폼에서 구현되었다는 것입니다. 즉, SOAP를 사용하여 organization 내부 및 없이 서로 다른 시스템을 연결할 수 있습니다. 과거에는 시스템 통합에 사용할 수 있는 일반적인 통신 프로토콜을 마련하기 위해 많은 시도가 있었지만 SOAP가 광범위하게 채택한 것은 없었습니다. 그 이유는 무엇입니까? SOAP는 이전 프로토콜보다 훨씬 작고 구현이 더 간단하기 때문입니다. 예를 들어 DCE 및 CORBA는 구현하는 데 수년이 걸렸기 때문에 몇 가지 구현만 릴리스되었습니다. 그러나 SOAP는 기존 XML 파서 및 HTTP 라이브러리를 사용하여 대부분의 작업을 수행할 수 있으므로 SOAP 구현은 몇 달 만에 완료될 수 있습니다. 이 때문에 70개 이상의 SOAP 구현을 사용할 수 있습니다. SOAP는 DCE 또는 CORBA가 수행하는 모든 작업을 수행하지는 않지만 기능에 대한 대가로 복잡성이 부족하여 SOAP를 쉽게 사용할 수 있습니다.

HTTP의 보편성과 SOAP의 단순성은 거의 모든 환경에서 호출할 수 있는 XML 웹 서비스를 구현하기 위한 이상적인 기반이 됩니다. SOAP에 대한 자세한 내용은 MSDN SOAP 홈페이지를 참조하세요.

보안은 어떻습니까?

SOAP 신규 이민자가 묻는 첫 번째 질문 중 하나는 SOAP가 보안을 어떻게 처리하는가하는 것입니다. 개발 초기에 SOAP는 HTTP 기반 프로토콜로 간주되었으므로 HTTP 보안이 SOAP에 적합하다고 가정했습니다. 결국 현재 HTTP 보안을 사용하여 실행되는 수천 개의 웹 애플리케이션이 있으므로 SOAP에 적합합니다. 이러한 이유로 현재 SOAP 표준은 보안이 전송 문제이며 보안 문제에 대해 침묵한다고 가정합니다.

SOAP가 여러 전송을 기반으로 실행되는 보다 범용 프로토콜이 되도록 확장되면 보안이 더 큰 문제가 되었습니다. 예를 들어 HTTP는 SOAP 호출을 수행하는 사용자를 인증하는 여러 가지 방법을 제공하지만 메시지가 HTTP에서 SMTP 전송으로 라우팅될 때 해당 ID가 어떻게 전파되나요? SOAP는 빌딩 블록 프로토콜로 설계되었으므로 다행히 SOAP를 기반으로 웹 서비스에 대한 추가 보안 기능을 제공하기 위한 사양이 이미 있습니다. WS-Security 사양은 완전한 암호화 시스템을 정의합니다.

WSDL

WSDL(종종 whiz-dull로 발음)은 웹 서비스 설명 언어를 의미합니다. WSDL 파일은 SOAP 메시지 집합과 메시지 교환 방법을 설명하는 XML 문서라고 말할 수 있습니다. 즉, WSDL은 CORBA 또는 COM에 대한 IDL을 SOAP로 지정합니다. WSDL은 XML이므로 읽을 수 있고 편집할 수 있지만 대부분의 경우 소프트웨어에서 생성되고 소비됩니다.

WSDL의 가치를 확인하려면 비즈니스 파트너 중 한 명이 제공하는 SOAP 메서드 호출을 시작한다고 상상해 보세요. 그에게 샘플 SOAP 메시지를 요청하고 애플리케이션을 작성하여 샘플처럼 보이는 메시지를 생성하고 사용할 수 있지만 오류가 발생할 수 있습니다. 예를 들어 2837의 고객 ID가 표시되고 실제로 문자열인 경우 정수라고 가정할 수 있습니다. WSDL은 요청 메시지에 포함해야 하는 항목과 명확한 표기법에서 응답 메시지가 어떻게 표시되는지 지정합니다.

WSDL 파일이 메시지 형식을 설명하는 데 사용하는 표기법은 XML 스키마 표준을 기반으로 합니다. 즉, 프로그래밍 언어 중립 및 표준 기반이므로 다양한 플랫폼 및 프로그래밍 언어에서 액세스할 수 있는 XML 웹 서비스 인터페이스를 설명하는 데 적합합니다. WSDL은 메시지 내용을 설명하는 것 외에도 서비스를 사용할 수 있는 위치와 서비스와 통신하는 데 사용되는 통신 프로토콜을 정의합니다. 즉, WSDL 파일은 XML 웹 서비스를 사용하는 프로그램을 작성하는 데 필요한 모든 것을 정의합니다. WSDL 파일을 읽고 XML 웹 서비스와 통신하는 데 필요한 코드를 생성하는 데 사용할 수 있는 몇 가지 도구가 있습니다. 이러한 도구 중 가장 가능한 도구 중 일부는 Microsoft Visual Studio® .NET에 있습니다.

많은 현재 SOAP 도구 키트에는 기존 프로그램 인터페이스에서 WSDL 파일을 생성하는 도구가 포함되어 있지만 WSDL을 직접 작성하는 도구는 거의 없으며 WSDL에 대한 도구 지원은 예상대로 완료되지 않습니다. 도구가 WSDL 파일을 작성한 다음 COM IDL 도구와 마찬가지로 프록시 및 스텁을 생성하는 것이 대부분의 SOAP 구현의 일부가 되기까지는 그리 오래 걸리지 않습니다. 이 시점에서 WSDL은 XML 웹 서비스에 대한 SOAP 인터페이스를 작성하는 기본 방법이 됩니다.

WSDL에 대한 훌륭한 설명을 사용할 수 있으며 에서 http://www.w3.org/TR/wsdlWSDL 사양을 찾을 수 있습니다.

UDDI

유니버설 검색 설명 및 통합은 웹 서비스의 노란색 페이지입니다. 기존 노란색 페이지와 마찬가지로 필요한 서비스를 제공하는 회사를 검색하고 제공된 서비스에 대해 읽고 다른 사람에게 문의하여 자세한 내용을 확인할 수 있습니다. 물론 UDDI에 등록하지 않고도 웹 서비스를 제공할 수 있습니다. 지하에서 사업을 열고 입소문 광고에 의존할 수 있지만 중요한 시장에 도달하려면 고객이 찾을 수 있도록 UDDI가 필요합니다.

UDDI 디렉터리 항목은 비즈니스 및 제공하는 서비스를 설명하는 XML 파일입니다. UDDI 디렉터리에 항목에는 세 부분이 있습니다. "화이트 페이지"는 서비스(이름, 주소, 연락처 등)를 제공하는 회사를 설명합니다. "노란색 페이지"에는 북미 산업 분류 시스템 및 표준 산업 분류와 같은 표준 분류를 기반으로 하는 산업 범주가 포함됩니다. "녹색 페이지"는 다른 사용자가 웹 서비스를 사용하기 위해 애플리케이션을 작성하기에 충분한 세부 정보로 서비스에 대한 인터페이스를 설명합니다. 서비스를 정의하는 방법은 형식 모델 또는 tModel이라는 UDDI 문서를 사용하는 것입니다. 대부분의 경우 tModel에는 XML 웹 서비스에 대한 SOAP 인터페이스를 설명하는 WSDL 파일이 포함되어 있지만 tModel은 거의 모든 종류의 서비스를 설명할 수 있을 만큼 유연합니다.

UDDI 디렉터리에는 애플리케이션을 빌드하는 데 필요한 서비스를 검색하는 여러 가지 방법도 포함되어 있습니다. 예를 들어 지정된 지리적 위치 또는 지정된 유형의 비즈니스에서 서비스 공급자를 검색할 수 있습니다. 그런 다음 UDDI 디렉터리에서 정보, 연락처, 링크 및 기술 데이터를 제공하여 요구 사항을 충족하는 서비스를 평가할 수 있습니다.

UDDI를 사용하면 웹 서비스를 가져올 비즈니스를 찾을 수 있습니다. 누구와 사업을 하고 싶은지 이미 알고 있지만 어떤 서비스가 제공되는지 모르는 경우 어떻게 해야 할까요? WS-검사 사양을 사용하면 특정 서버에서 제공되는 XML 웹 서비스 컬렉션을 검색하여 요구 사항을 충족할 수 있는 서비스를 찾을 수 있습니다.

UDDI에 대한 자세한 내용은 에서 http://www.uddi.org/about.html확인할 수 있습니다.

남은 것은 무엇인가요?

지금까지 SOAP(XML Web Services)와 통신하는 방법, XML 웹 서비스를 설명하는 방법(WSDL) 및 UDDI(XML 웹 서비스)를 찾는 방법에 대해 설명했습니다. 이는 애플리케이션 통합 및 집계를 위한 토대를 제공하는 기준 사양 집합을 구성합니다. 이러한 기준 사양에서 기업은 실제 솔루션을 빌드하고 실제 가치를 얻고 있습니다.

XML 웹 서비스를 현실로 만들기 위해 많은 작업이 수행되었지만 더 많은 작업이 필요합니다. 오늘날 사람들은 XML 웹 서비스에서 성공을 거두었지만 여전히 개발자®를 위한 연습으로 남아 있는 것들(예: 보안, 운영 관리, 트랜잭션, 신뢰할 수 있는 메시징)이 남아 있습니다. 글로벌 XML 웹 서비스 아키텍처는 모듈식으로 확장 가능한 XML 웹 서비스에 새로운 고급 기능을 추가하기 위한 일관된 범용 모델을 제공하여 XML 웹 서비스를 한 단계 더 발전시키는 데 도움이 됩니다.

WS-Security 는 글로벌 웹 서비스 아키텍처의 사양 중 하나입니다. 많은 서버 간에 메시지를 라우팅하고 처리를 위해 동적으로 해당 서버를 구성하는 것과 같은 운영 관리 요구 사항은 글로벌 웹 서비스 아키텍처의 일부이기도 하며 WS 라우팅 사양 및 WS-조회 사양에 의해 충족됩니다. 글로벌 웹 서비스 아키텍처가 증가함에 따라 이러한 요구 사항 및 기타 요구 사항에 대한 사양이 도입됩니다.

자세한 내용은 글로벌 XML 웹 서비스 아키텍처에서 확인할 수 있습니다.