XML 웹 서비스는 인터넷의 분산 컴퓨팅을 위한 기본 구성 요소입니다. 개방형 표준과 사용자와 응용 프로그램 간의 통신 및 공동 작업에 중점을 두면서 XML Web Services가 응용 프로그램 통합을 위한 플랫폼이 되는 환경이 조성되었습니다. 응용 프로그램은 위치나 구현 방법에 관계없이 함께 작동하는 다양한 소스의 XML Web Services를 사용하여 구성됩니다.
XML Web Services를 구축하는 회사 수만큼 XML Web Service 정의가 있습니다. 그러나 거의 모든 정의에는 다음과 같은 공통점이 있습니다.
XML 웹 서비스는 표준 웹 프로토콜을 통해 웹 사용자에게 유용한 기능을 제공합니다. 대부분의 경우 SOAP 프로토콜이 사용됩니다.
XML Web Services는 인터페이스를 매우 자세하게 지정할 수 있으므로 사용자는 클라이언트 응용 프로그램을 만들어 통신할 수 있습니다. 이 설명은 일반적으로 WSDL(웹 서비스 설명 언어) 문서라는 XML 문서에 포함되어 있습니다.
XML 웹 서비스는 잠재적인 사용자가 쉽게 찾을 수 있도록 등록되며, 이는 UDDI(Universal Discovery, Description, and Integration)를 통해 수행됩니다.
이 기사에서는 이 세 가지 기술을 소개하지만 먼저 XML Web Services에 주목해야 하는 이유를 설명해야 합니다.
XML 웹 서비스 아키텍처의 주요 장점 중 하나는 다양한 플랫폼에서 다양한 언어로 작성된 다양한 프로그램이 표준 기반 방식으로 서로 통신할 수 있다는 것입니다. 이 업계에 대해 아는 사용자는 즉시 다음과 같이 말할 수 있습니다. "잠깐만요. CORBA와 이전 DCE도 같은 약속을 하지 않았습니까? 이것과 둘 사이의 차이점은 무엇입니까? 가장 중요한 차이점은 SOAP가 이전보다 낫다는 것입니다." 접근 방식이 훨씬 간단하므로 표준 준수 SOAP 구현에 대한 장벽이 훨씬 적습니다. Paul Kulchenko는 http://www.soapware.org/directory/4/implementations (영문)에서 SOAP 구현 목록을 제공합니다. 마지막 조사 결과 목록에는 79개의 항목이 포함되어 있었습니다. 예상할 수 있듯이 대부분의 주요 소프트웨어 회사는 SOAP 구현을 제공하지만 개별 개발자가 만들고 유지 관리하는 구현도 많이 있습니다. 이전 솔루션에 비해 XML 웹 서비스의 또 다른 주요 이점은 표준 웹 프로토콜(XML, HTTP 및 TCP/IP)을 사용한다는 것입니다. 많은 기업이 이미 웹 인프라를 구축했으며 직원들은 이를 유지 관리할 수 있는 지식과 경험을 보유하고 있습니다. 따라서 XML Web Services 도입 비용은 이전 기술 도입 비용보다 훨씬 저렴합니다.
우리는 XML 웹 서비스를 SOAP를 통해 웹에 제공되고, WSDL 파일을 사용하여 설명되고, UDDI를 통해 등록되는 소프트웨어 서비스로 정의합니다. 따라서 "XML Web Services로 무엇을 할 수 있습니까?"라고 질문할 수 있습니다. 원래 XML Web Services는 주식 가격, 일기 예보, 스포츠 경기 결과 등과 같이 응용 프로그램에 쉽게 통합될 수 있는 정보 소스인 경우가 많았습니다. 관심 있는 정보를 분석 및 요약하고 해당 정보를 다양한 방법으로 사용할 수 있도록 구축할 수 있는 전체 응용 프로그램 클래스를 상상하기는 쉽습니다. 예를 들어 Microsoft® Excel 스프레드시트를 사용하여 모든 재무 정보를 요약할 수 있습니다. 정보—주식, 401K, 은행 예금, 대출 등 XML Web Services를 통해 이 정보를 사용할 수 있는 경우 Excel에서는 해당 정보를 지속적으로 업데이트할 수 있습니다. 이 정보 중 일부는 무료이며 일부는 해당 서비스를 받으려면 가입이 필요할 수 있습니다. 이 정보의 대부분은 이미 웹에서 사용할 수 있지만 XML Web Services를 사용하면 프로그래밍 방식으로 더욱 쉽고 안정적으로 액세스할 수 있습니다.
기존 응용 프로그램은 XML Web Services로 제공되며, XML Web Services를 구성 요소로 사용하여 보다 강력한 새 응용 프로그램을 구축할 수 있습니다. 예를 들어, 사용자는 다양한 공급업체로부터 가격 정보를 자동으로 가져오는 구매 애플리케이션을 개발하여 사용자가 공급업체를 선택하고 주문을 제출한 다음 상품을 받을 때까지 상품 배송을 추적할 수 있습니다. 웹에서 서비스를 제공하는 것 외에도 공급자의 응용 프로그램은 XML Web Service를 사용하여 고객 신용을 확인하고 지불금을 징수하며 화물 회사와의 화물 절차를 처리할 수도 있습니다.
미래에는 가장 흥미로운 XML Web Services 기반 응용 프로그램 중 일부가 웹을 활용하여 현재 불가능한 작업을 수행할 수 있게 될 것입니다. 예를 들어 달력 서비스는 Microsoft .NET My Services(영어) 프로젝트에서 지원되는 서비스 중 하나입니다. 치과 의사와 정비사가 이 XML 웹 서비스를 통해 일정을 제공하는 경우 원하는 경우 웹을 통해 약속을 예약할 수 있으며 달력에서 직접 청소 및 정기 유지 관리 날짜를 예약할 수도 있습니다. 웹을 프로그래밍할 수 있다면 수백 개의 애플리케이션을 만들 수 있다고 상상하기 쉽습니다.
XML 웹 서비스 및 구축할 수 있는 응용 프로그램에 대한 자세한 내용은 MSDN 웹 서비스(영어) 홈 페이지를 참조하세요.
SOAP
SOAP는 XML 웹 서비스의 통신 프로토콜입니다. SOAP를 통신 프로토콜로 설명할 때 대부분의 사람들은 DCOM이나 CORBA를 생각하고 "SOAP는 어떻게 객체를 활성화합니까?" 또는 "SOAP는 어떤 이름 지정 서비스를 사용합니까?"와 같은 질문을 합니다. SOAP 구현에는 이러한 요소가 포함될 수 있지만 SOAP 표준에서는 이를 지정하지 않습니다. SOAP 메시지의 XML 형식을 정의하는 사양 - 이는 사양의 필수 부분입니다. SOAP 요소 쌍 내에 포함된 올바른 형식의 XML 세그먼트는 SOAP 메시지입니다. 이것은 간단하지 않습니까?
SOAP 사양의 다른 부분에서는 프로그램 데이터를 XML로 표현하는 방법과 RPC(원격 프로시저 호출)에 SOAP를 사용하는 방법을 설명합니다. 사양의 이러한 선택적 부분은 클라이언트가 SOAP 메시지(호출 가능한 함수 및 함수에 전달될 매개변수 포함)를 발행하고 서버가 결과가 포함된 메시지를 반환하는 RPC 스타일 애플리케이션을 구현하는 데 사용됩니다. 기능 실행의. 현재 대부분의 SOAP 구현은 COM 또는 CORBA 애플리케이션 개발에 익숙한 프로그래머가 RPC 형식에 익숙하기 때문에 RPC 애플리케이션을 지원합니다. SOAP는 SOAP 메시지가 XML 문서를 둘러싼 래퍼인 문서 스타일 애플리케이션도 지원합니다. 문서 기반 SOAP 응용 프로그램은 매우 유연하며 많은 새로운 XML 웹 서비스는 이 기능을 활용하여 RPC를 사용하여 구현하기 어려운 서비스를 구축합니다.
SOAP 사양의 마지막 선택 부분은 SOAP 메시지를 포함하는 HTTP 메시지의 스타일을 정의합니다. 거의 모든 현재 OS(및 많은 이전 OS)가 HTTP를 지원하기 때문에 이 HTTP 바인딩은 중요합니다. 선택 사항이지만 HTTP 바인딩은 SOAP의 유일한 표준 프로토콜이기 때문에 거의 모든 SOAP 구현에서 지원됩니다. 이러한 이유로 사람들은 종종 SOAP가 HTTP를 사용해야 한다고 잘못 생각합니다. 실제로 일부 구현에서는 MSMQ, MQ 시리즈, SMTP 또는 TCP/IP 전송도 지원하지만 HTTP는 어디에나 있기 때문에 현재 거의 모든 XML 웹 서비스에서 이를 사용합니다. HTTP는 웹의 핵심 프로토콜이기 때문에 대부분의 조직의 네트워크 인프라는 HTTP를 지원하며 직원들은 이미 이를 관리하는 방법을 알고 있습니다. 오늘날 HTTP 보안, 모니터링 및 로드 밸런싱을 위한 인프라가 구축되었습니다.
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 웹 서비스의 이상적인 기반이 됩니다. SOAP에 대한 자세한 내용은 MSDN SOAP(영어) 홈 페이지를 참조하세요.
얼마나 안전합니까?
종종 SOAP를 처음 접하는 사용자가 묻는 첫 번째 질문은 SOAP가 보안 문제를 해결하는 방법입니다. 초기 개발 단계에서 SOAP는 HTTP 기반 프로토콜로 간주되었으므로 SOAP에는 HTTP의 보안이 충분하다고 간주되었습니다. 결국, 현재 HTTP 보안을 사용하는 웹 애플리케이션이 수천 개 있으므로 SOAP에는 이 정도면 충분합니다. 따라서 현재 SOAP 표준에서는 보안이 전송 문제이며 보안 문제로 처리되지 않는다고 가정합니다.
SOAP가 보다 일반적인 프로토콜로 확장되고 수많은 전송에서 실행됨에 따라 보안 문제가 더욱 두드러집니다. 예를 들어, HTTP는 SOAP 호출을 하는 사용자를 인증하는 여러 가지 방법을 제공하지만 메시지가 HTTP에서 SMTP 전송으로 라우팅될 때 해당 ID가 어떻게 전파됩니까? SOAP는 빌딩 블록 프로토콜로 설계되었으므로 다행히 SOAP 기반 웹 서비스에 추가 보안 기능을 제공하기 위한 사양이 마련되어 있습니다. WS-Security 사양(영문)은 완전한 암호화 시스템을 정의하고, WS-License 사양(영문)은 호출자의 신원을 확인하고 인증된 사용자만 웹 서비스를 사용할 수 있도록 하는 해당 기술을 정의합니다.
WSDL
WSDL(웹 서비스 설명 언어)은 웹 서비스 설명 언어를 나타냅니다. 이 기사의 목적에 따라 WSDL 파일은 SOAP 메시지 세트와 이를 교환하는 방법을 설명하는 XML 문서로 생각할 수 있습니다. 즉, WSDL은 IDL이 CORBA 또는 COM에 대한 SOAP인 것입니다. WSDL은 XML 문서이기 때문에 읽고 편집하기 쉽지만 대부분의 경우 소프트웨어에 의해 생성되고 사용됩니다.
WSDL의 값을 보려면 비즈니스 파트너 중 하나가 제공하는 SOAP 메서드를 호출한다고 가정해 보세요. 몇 가지 샘플 SOAP 메시지를 요청한 다음 애플리케이션을 작성하여 샘플과 유사한 메시지를 생성하고 사용할 수 있지만 이는 실수하기 쉽습니다. 예를 들어, 고객 ID 2837을 보고 그것이 정수라고 가정하지만 실제로는 문자열일 수 있습니다. WSDL은 명시적 표기법을 통해 요청 메시지에 포함되어야 하는 내용과 응답 메시지의 모양을 지정합니다.
메시지 형식을 설명하기 위해 WSDL 파일에서 사용하는 표기법은 XML 스키마 표준을 기반으로 합니다. 즉, 프로그래밍 언어에 구애받지 않고 표준 기반이므로 다양한 플랫폼 및 프로그래밍 방식으로 액세스할 수 있는 XML 웹 서비스를 설명하는 데 적합합니다. 언어. 메시지 내용을 설명하는 것 외에도 WSDL은 서비스의 위치와 서비스와 통신하는 데 사용되는 통신 프로토콜을 정의합니다. 즉, WSDL 파일은 XML Web Services를 사용하는 프로그램을 작성하는 데 필요한 모든 것을 정의합니다. WSDL 파일을 읽고 XML 웹 서비스와 통신하는 데 필요한 코드를 생성할 수 있는 여러 도구가 있습니다. 가장 강력한 도구 중 일부는 Microsoft Visual Studio® .NET에서 찾을 수 있습니다.
현재 많은 SOAP 툴킷에는 기존 프로그램 인터페이스에서 WSDL 파일을 생성하기 위한 도구가 포함되어 있지만 WSDL을 직접 작성하기 위한 도구는 거의 없으며 WSDL에 대한 도구 지원은 불완전합니다. 그러나 곧 WSDL 파일 작성을 위한 도구가 등장하고 그 뒤를 이어 프록시 및 스텁 생성 도구(COM IDL 도구와 유사)가 나올 것이며 이러한 도구는 대부분의 SOAP 구현의 일부가 될 것입니다. 그때까지는 WSDL이 XML 웹 서비스에 대한 SOAP 인터페이스를 생성하는 데 선호되는 방법이 될 것입니다.
여기에(영문) WSDL에 대한 아주 좋은 설명이 있으며, http://www.w3.org/TR/wsdl (영문)에서도 WSDL 사양을 찾을 수 있습니다.
UDDI
Universal Discovery, Description, and Integration(UDDI)은 웹 서비스의 Yellow Pages입니다. 기존 전화번호부와 마찬가지로 필요한 서비스를 제공하는 회사를 검색하고, 제공되는 서비스에 대해 읽어본 다음, 자세한 내용을 알아보려면 담당자에게 문의하세요. 물론 UDDI에 등록하지 않고도 웹 서비스를 제공할 수 있습니다. 이는 마치 지하실에서 입소문에 의존하여 사업을 운영하는 것과 같지만, 시장을 확장하려면 UDDI가 필요합니다. 고객.
UDDI 디렉토리 항목은 제공된 서비스 및 서비스를 설명하는 XML 파일입니다. UDDI 디렉토리 항목은 세 부분으로 구성됩니다. "화이트 페이지"는 이름, 주소, 연락처 정보 등 서비스를 제공하는 회사를 소개합니다. "옐로우 페이지"에는 표준 분류(예: 북미 산업 분류 시스템 및 표준 산업 분류)에 따른 산업 범주가 포함됩니다. 정보 사용자가 웹 서비스를 사용하는 애플리케이션을 작성할 수 있도록 서비스에 대한 인터페이스에 액세스합니다. 서비스 정의는 유형 모델(또는 tModel)이라는 UDDI 문서를 통해 수행됩니다. 대부분의 경우 tModel에는 XML 웹 서비스에 액세스하기 위한 SOAP 인터페이스를 설명하는 WSDL 파일이 포함되어 있지만 tModel은 매우 유연하며 거의 모든 유형의 서비스를 설명할 수 있습니다.
UDDI 디렉토리에는 애플리케이션을 구축하는 데 필요한 서비스를 검색하기 위한 여러 가지 방법도 포함되어 있습니다. 예를 들어 특정 지리적 위치에 있는 서비스 제공업체를 검색하거나 특정 비즈니스 유형을 검색할 수 있습니다. 그러면 UDDI 디렉토리는 귀하의 요구 사항에 맞는 서비스를 식별할 수 있도록 정보, 연락처 세부 정보, 링크 및 기술 데이터를 제공합니다.
UDDI를 사용하면 필요한 웹 서비스를 제공하는 회사를 찾을 수 있습니다. 누구와 사업을 하고 싶은지 이미 알고 있지만 그 외에 무엇을 제공할 수 있는지 아직 모른다면 어떻게 하시겠습니까? WS-Inspection 사양(영문)을 사용하면 특정 서버에서 사용할 수 있는 XML 웹 서비스 컬렉션을 탐색하여 필요한 서비스를 찾을 수 있습니다.
UDDI에 대한 자세한 내용을 보려면 http://www.uddi.org/about.html (영문)을 방문하세요.
기타 콘텐츠
지금까지 XML 웹 서비스(SOAP)와 통신하는 방법, XML 웹 서비스 설명(WSDL) 및 XML 웹 서비스(UDDI)를 찾는 방법에 대해 논의했습니다. 이는 애플리케이션 통합 및 집계의 기초를 제공하는 기본 사양 세트를 형성합니다. 이러한 기본 사양을 기반으로 기업은 실용적인 솔루션을 구축하고 이를 통해 이점을 얻을 수 있습니다.
우리는 XML Web Services를 구현하기 위해 많은 작업을 수행했지만 아직 해야 할 일이 많이 남아 있습니다. 오늘날 사람들은 XML Web Services를 사용하여 성공을 거두었지만 개발자에게는 개선해야 할 여지가 여전히 많이 있습니다. 예를 들어 보안, 운영 관리, 트랜잭션 처리, 안정적인 메시징 등이 있습니다. 글로벌 XML 웹 서비스 아키텍처는 모듈식 및 확장 가능한 방식으로 XML 웹 서비스에 새로운 고급 기능을 추가하기 위한 일관되고 공통된 모델을 제공함으로써 XML 웹 서비스가 다음 진화 단계로 진입하는 데 도움이 될 것입니다.
위에 언급된 보안 모듈(WS-Security[영어] 및 WS-License[영어])은 글로벌 웹 서비스 아키텍처 사양의 일부입니다. 운영 관리 요구 사항(예: 여러 서버 간 메시지 라우팅 및 처리를 위해 해당 서버를 동적으로 구성)도 WS-Routing 사양(영어) 및 WS-Referral 사양(영어)을 통해 글로벌 웹 서비스 아키텍처의 일부입니다. 글로벌 웹 서비스 아키텍처가 발전함에 따라 이러한 요구 사항과 기타 요구 사항을 해결하는 사양이 도입될 것입니다.