<img src="http://blogimgs.naver.com/nblog/ico_scrap01.gif" class="i_scrap" width="50" height="15" alt="본문스크랩" /> WSDL 상세

Architecture 2006. 5. 12. 20:08

WSDL 상세

2005-11-21 11:31

카테고리 : Apache Php Mysql

http://blog.paran.com/sputnik/7025859

개요

WSDL은 문서 지향적 또는 프로시저 지향적인 정보를 포함한 메시지에서 작동하는 종점 집합으로서의 네트워크 서비스를 설명하는 XML 형식입니다. 이러한 작동 및 메시지에 대해 대략적으로 설명한 다음, 구체적인 네트워크 프로토콜 및 메시지 형식으로 연결하여 종점에 대해 정의합니다. 관련된 구체적인 종점은 추상 종점(서비스)과 결합되어 있습니다. WSDL은 통신에 사용되는 메시지 형식 또는 네트워크 프로토콜과는 상관 없이 종점 및 종점의 메시지를 설명하도록 확장할 수 있습니다. 하지만, 이 문서에 설명된 바인딩만이 SOAP 1.1, HTTP GET/POST 및 MIME과 함께 WSDL을 사용하는 방법을 설명합니다.

이 WSDL 언어 버전은 종점의 컴퍼지션 및 결합을 설명하는 프레임워크를 포함하지 않는 첫 번째 단계입니다. 계약을 설명하는 전체 프레임워크는 메시지를 받거나 보내는 순서 규칙과 같이 서비스의 동작을 표현하는 방법과 서비스를 작성하는 방법을 포함합니다. 서비스의 컴퍼지션은 모든 형식을 지원해야 하지만 런타임에 교환되고 바운드되는 서비스 참조와 함께 전달되는 참조를 허용해야 합니다. 특히, 후자는 런타임 계약 협상의 중요한 요소이며 참조 동작을 캡처하고 서비스를 중개합니다.

WSDL 스펙 작성자들은 (1)서비스를 작성하는 프레임워크 및 (2)서비스의 동작을 설명하는 프레임워크를 포함하는 WSDL의 수정된 버전 및/또는 추가 문서를 적시에 게시하고 있습니다.

상태

여기에서는 Ariba, IBM 및 Microsoft 내에서 서비스의 설명과 관련한 현재 고려 사항을 보여 주며 NASSL, SCL 및 SDL(이 분야에서의 이전 제안)의 개념을 통합합니다.

1 소개
1.1 WSDL 문서 예제
1.2 국제 규칙
2 서비스 정의
2.1 WSDL 문서 구조
2.1.1 문서 명명 및 연결
2.1.2 제작 스타일
2.1.3 언어 확장성 및 바인딩
2.1.4 설명서
2.2 형식
2.3 메시지
2.3.1 메시지 부분
2.3.2 추상 메시지와 구체적인 메시지
2.4 포트 형식
2.4.1 단방향 작업
2.4.2 요청-응답 작업
2.4.3 검색-응답 작업
2.4.4 알림 작업
2.4.5 작업 내 요소의 이름
2.4.6 작업 내 매개 변수 순서
2.5 바인딩
2.6 포트
2.7 서비스
3 SOAP 바인딩
3.1 SOAP 예제
3.2 SOAP 바인딩이 WSDL을 확장하는 방법
3.3 soap:binding
3.4 soap:operation
3.5 soap:body
3.6 soap:fault
3.7 soap:header
3.8 soap:address
4 HTTP GET 및 POST 바인딩
4.1 HTTP GET/POST 예제
4.2 HTTP GET/POST 바인딩이 WSDL을 확장하는 방법
4.3 http:address
4.4 http:binding
4.5 http:operation
4.6 http:urlEncoded
4.7 http:urlReplacement
5 MIME 바인딩
5.1 MIME 바인딩 예제
5.2 MIME 바인딩이 WSDL을 확장하는 방법
5.3 mime:content
5.4 mime:multipartRelated
5.5 soap:body
5.6 mime:mimeXml
6 참조
A 1 URI에 대한 참고
A 1.1 XML 이름 공간 및 스키마 위치
A 1.2 상대 URI
A 1.3 URI 작성
A 2 네트워크 형식의 WSDL 예제
A 2.1 예제 1
A 3 확장성 요소의 위치
A 4 스키마
A 4.1 WSDL 스키마
A 4.2 SOAP 바인딩 스키마
A 4.3 HTTP 바인딩 스키마
A 4.4 MIME 바인딩 스키마

1. 소개

통신 프로토콜 및 메시지 형식이 웹 커뮤니티에서 표준화됨에 따라, 통신을 어느 정도 구조적인 방법으로 설명하는 것이 점차 가능해지고 중요해지게 되었습니다. WSDL은 네트워크 서비스를 메시지를 교환할 수 있는 통신 종점의 컬렉션으로 설명하는 XML 문법을 정의하여 이러한 필요성을 해결합니다. WSDL 서비스 정의는 분산 시스템에 대한 설명서를 제공하고 응용 프로그램 통신과 관련된 자세한 정보를 자동화할 수 있도록 합니다.

WSDL 문서는 services를 네트워크 종점의 컬렉션 또는 ports로 정의합니다. WSDL에서 종점 및 메시지의 추상 정의는 구체적인 네트워크 구축 또는 데이터 형식 바인딩과는 구분되며 이러한 특성은 추상 정의를 재사용 가능하도록 합니다. 즉, messages는 교환되는 데이터의 추상 설명이고, port types은 operations의 추상 컬렉션입니다. 특정 포트 유형에 대한 구체적인 프로토콜과 데이터 형식 지정은 재사용 가능한 binding을 구성합니다. 포트는 네트워크 주소를 재사용 가능한 바인딩에 연결하여 정의되고, 포트의 컬렉션은 서비스를 정의합니다. 따라서 WSDL 문서는 네트워크 서비스의 정의에서 다음과 같은 요소를 사용합니다.

Types? XSD와 같은 특정 형식 시스템을 사용하는 데이터 형식 정의에 대한 컨테이너.
Message? 통신할 데이터에 대한 추상적이고 형식화된 정의.
Operation? 서비스가 지원하는 동작에 대한 추상적인 설명.
Port Type? 하나 이상의 종점에서 지원하는 추상적인 작업 집합.
Binding? 특정 포트 유형에 대한 구체적인 프로토콜 및 데이터 형식 지정.
Port? 바인딩과 네트워크 주소가 결합되어 정의되는 단일 종점.
Service? 관련된 종점의 컬렉션.

이러한 요소들은 2절에서 자세하게 설명합니다. WSDL이 새로운 형식 정의 언어를 도입하는 것은 아니라는 것을 알아두십시오. WSDL은 메시지 형식을 설명하는 다양한 형식 시스템의 필요성을 인식하여 정식의 형식 시스템으로 XML 스키마 규격(XSD)[11]을 지원합니다. 그러나 현재의 메시지 형식을 포함하여 앞으로 사용하게 될 모든 메시지 형식을 설명하는 데 있어 단일 형식 시스템 문법을 기대하기 어렵기 때문에, WSDL은 확장성을 통해 다른 형식의 정의 언어를 사용할 수 있도록 합니다.

또한 WSDL은 일반적인 binding 메커니즘을 정의합니다. 이 메커니즘은 특정 프로토콜이나 데이터 형식 또는 구조를 추상 메시지, 작업 또는 종점에 연결하는 데 사용되고 추상 정의를 재사용할 수 있도록 합니다.

이 규격은 주요 서비스 정의 프레임워크와 함께 다음 프로토콜 및 메시지 형식에 대해 특정 바인딩 확장을 소개합니다.

SOAP 1.1 (3절 참조)
HTTP GET / POST (4절 참조)
MIME (5절 참조)

위의 언어 확장은 이 문서에 정의되어 있지만, 주요 서비스 정의 프레임워크 상단에 계층화 되어있습니다. WSDL을 사용하면 언제든지 다른 바인딩 확장을 사용할 수 있습니다.

1.1 WSDL 문서 예제

다음은 주식 시세를 제공하는 간단한 서비스에 대한 WSDL 정의 예제를 보여 줍니다. 이 서비스는 HTTP상에 SOAP 1.1 프로토콜을 사용하여 구축된 GetLastTradePrice라고 하는 단일 작업을 지원합니다. 요청은 문자열 형식의 증권 시세 표시기 기호를 입력으로 받아, 부동 소수점 형식의 가격을 반환합니다. 이 정의에 사용된 요소에 대한 자세한 설명은 2절(주요 언어) 및 3절(SOAP 바인딩)에서 볼 수 있습니다.

이 예제는 SOAP 인코딩 대신 고정 XML 형식을 사용합니다(SOAP 인코딩을 사용하는 예제는 예제 4를 참조하십시오).

예제 1 HTTP를 통한 SOAP 1.1 요청/응답

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/1999/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>

<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePriceResult"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="literal" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>

<service name="StockQuoteService">
<documentation>첫 번째 서비스</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>

</definitions>

1.2 국제 규칙

1. 이 문서에 있는 키워드인 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 및 "OPTIONAL" 는 RFC-2119 [2]에 설명된 바와 같이 해석됩니다.

2. 다음 이름 공간 접두사는 이 문서 전반에 걸쳐 사용됩니다.

접두사	이름 공간 URI	정의
wsdl	http://schemas.xmlsoap.org/wsdl/	WSDL 프레임워크에 대한 WSDL 이름 공간.
soap	http://schemas.xmlsoap.org/wsdl/soap/	WSDL SOAP 바인딩에 대한 WSDL 이름 공간.
http	http://schemas.xmlsoap.org/wsdl/http/	HTTP GET & POST 바인딩에 대한 WSDL 이름 공간.
mime	http://schemas.xmlsoap.org/wsdl/mime/	MIME 바인딩에 대한 WSDL 이름 공간.
soapenc	http://schemas.xmlsoap.org/soap/encoding/	SOAP 1.1 [8]에 의해 정의된 인스턴스 이름 공간.
soapenv	http://schemas.xmlsoap.org/soap/envelope/	SOAP 1.1 [8]에 의해 정의된 인스턴스 이름 공간.
xsi	http://www.w3.org/1999/XMLSchema-instance	XSD[10]에 의해 정의된 인스턴스 이름 공간.
xsd	http://www.w3.org/1999/XMLSchema	XSD [10]에 의해 정의된 스키마 이름 공간.
tns	(다양함)	“this namespace”를 의미하는 (tns) 접두사는 현재 문서를 참조하는 규칙으로 사용됩니다.
(기타)	(다양함)	다른 모든 이름 공간 접두사는 단지 예제일 뿐입니다. 특히, “http://example.com”으로 시작하는 URI는 어느 정도 응용 프로그램 종속적이거나 컨텍스트 종속적인 URI[4]를 나타냅니다.

3. 이 규격은 비공식 구문에 사용되어 WSDL 문서의 XML 문법을 설명합니다.

구문은 XML 인스턴스로 나타나지만, 값은 값이라기 보다는 데이터 형식을 나타냅니다.
문자는 "?" (0 또는 1), "*" (0 또는 그 이상의 숫자), "+" (1 또는 그 이상의 숫자)와 같이 요소 및 특성에 추가됩니다.
<element…/> 또는 <element…>에서처럼 "…"로 끝나는 요소 이름들은 컨텍스트에 관계 없는 요소/특성이 생략된다는 것을 나타냅니다.
굵게 되어 있는 문법은 이전 문서에 소개되지 않았거나 해당 예제에서 특별히 중요한 부분입니다.
<-- extensibility element -->는 XSD 이외인 경우 ##과 같이 어떤 "다른" 이름 공간에서 온 요소에 대한 자리 표시자입니다.
위에 정의된 XML 이름 공간 접두사는 정의되는 요소의 이름 공간을 나타내는 데 사용됩니다.
<?xml로 시작되는 예제에는 이 규격을 준수하는 충분한 정보가 있습니다. 다른 예제는 단편적이므로 규격에 맞도록 지정해야 되는 추가 정보가 필요합니다.

XSD 스키마는 WSDL 문법의 공식적인 정의로서 제공됩니다(A4항목을 참조 하시기 바랍니다).

2. 서비스 정의

이 절에서는 WSDL 언어의 주요 요소를 설명합니다. SOAP, HTTP 및 MIME의 바인딩 확장은 3절, 4절 및 5절에서 설명하였습니다.

2.1 WSDL 문서 구조

WSDL 문서는 단순한 정의의 집합입니다. 루트에 definition 요소가 있고 그 안에 정의가 있습니다. 문법은 다음과 같습니다.

<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>

<import namespace="uri" location="uri"/>*

<wsdl:documentation…/> ?

<wsdl:types> ?
<wsdl:documentation…/>?
<xsd:schema…/>*
<-- extensibility element --> *
</wsdl:types>

<wsdl:message name="nmtoken> *
<wsdl:documentation…/>?
<part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>

<wsdl:portType name="nmtoken">*
<wsdl:documentation…/>?
<wsdl:operation name="nmtoken">*
<wsdl:documentation…/> ?
<wsdl:input name="nmtoken"? message="qname">?
<wsdl:documentation…/> ?
</wsdl:input>
<wsdl:output name="nmtoken"? message="qname">?
<wsdl:documentation…/> ?
</wsdl:output>
<wsdl:fault name="nmtoken" message="qname"> *
<wsdl:documentation…/> ?
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>

<wsdl:binding name="nmtoken" type="qname">*
<wsdl:documentation…/>?
<-- extensibility element --> *
<wsdl:operation name="nmtoken">*
<wsdl:documentation…/> ?
<-- extensibility element --> *
<wsdl:input name="nmtoken"?> ?
<wsdl:documentation…/> ?
<-- extensibility element -->
</wsdl:input>
<wsdl:output name="nmtoken"?> ?
<wsdl:documentation…/> ?
<-- extensibility element --> *
</wsdl:output>
<wsdl:fault name="nmtoken"> *
<wsdl:documentation…/> ?
<-- extensibility element --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>

<wsdl:service name="nmtoken"> *
<wsdl:documentation…/>?
<wsdl:port name="nmtoken" binding="qname"> *
<wsdl:documentation…/> ?
<-- extensibility element -->
</wsdl:port>
<-- extensibility element -->
</wsdl:service>

<-- extensibility element --> *

</wsdl:definitions>

서비스는 다섯 개의 중요한 요소를 사용하여 정의됩니다.

types는 교환된 메시지를 설명하는 데 사용된 데이터 형식 정의를 제공합니다.
message는 전송되는 데이터의 추상 정의를 나타냅니다. 메시지는 논리적인 부분으로 이루어져 있으며 각 부분은 특정 형식 시스템 내의 정의와 연관되어 있습니다.
portType은 추상 작업의 집합이며 각 작업은 입력 메시지 및 출력 메시지를 참조합니다.
binding은 특정 portType에 의해 정의된 메시지 및 작업에 대해 구체적인 프로토콜과 데이터 형식을 지정합니다.
port는 바인딩에 대해 주소를 지정하기 때문에 단일 통신 종점을 정의합니다.
service는 관련된 포트의 집합을 집계하는 데 사용됩니다.

2.2절에서 2.7절은 이러한 요소를 설명합니다. 이 절의 나머지 부분은 문서 명명, 문서 정의 참조, 언어 확장 사용 및 컨텍스트 설명서 추가에 대해 WSDL로 소개된 규칙을 설명합니다.

2.1.1 문서 명명 및 연결

WSDL 문서는 간단한 형태의 설명서로 제공되는 NCNAME 형식의 선택적인 name 특성으로 지정될 수 있습니다. 또한 URI 형식의 targetNamespace 특성을 지정할 수도 있습니다. URI는 상대 URI일 수 없습니다.

WSDL은 import 문을 사용하여 문서 location과 namespace를 연결할 수 있도록 합니다.

<definitions…>
<import namespace="uri" location="uri"/> *
</definitions>

WSDL 정의 참조는 QName 을 사용하여 만들어집니다. WSDL 문서에 포함된 다음과 같은 정의 형식이 참조될 수도 있습니다.

WSDL 정의: service, port, message, bindings, 및 portType
기타 정의: 추가 정의가 확장성을 통해 추가되는 경우, 이 정의는 QName 연결을 사용합니다.

위에 나열된 WSDL 정의 형식은 자체 이름 범위를 가지고 있습니다. 즉, port 이름과 message 이름은 충돌하지 않습니다. 이름 범위내에 있는 이름은 WSDL 문서 내에서 고유해야 합니다.

WSDL에서 QNames 확인은 XML 스키마 규격[11]으로 설명된 QNames 확인과 유사합니다.

2.1.2 제작 스타일

import 요소를 사용하여 서비스 정의의 서로 다른 요소들을 별도의 문서로 분리하여 필요할 때 가져올 수 있습니다. 이 기능은 서비스의 추상화 수준에 따라 정의를 분리하여 서비스 정의를 더 명확하게 작성할 수 있도록 도와 줍니다. 또한 모든 종류의 서비스 정의를 재사용하는 기능을 최대화합니다. 따라서 이러한 방법으로 구조화된 WSDL 문서는 사용 및 유지 관리가 쉽습니다. 아래의 예제 2는 예제 1에 나타난 서비스를 정의하는 제작 스타일의 사용 방법을 보여 줍니다. 여기서는 정의를 데이터 형식 정의, 추상 정의 및 특정 서비스 바인딩의 세 개 문서로 분리하였습니다. 이 메커니즘의 사용은 이 규격에 정의된 언어 요소만 사용하는 예제에 명시적으로 나타난 정의에만 제한되지는 않습니다. 추가 언어 확장을 기반으로 하는 다른 형식의 정의는 유사한 방법으로 인코드되고 다시 사용될 수 있습니다.

예제 2. 예제 1의 서비스에 대한 대체 제작 스타일

http://example.com/stockquote/stockquote.xsd

<?xml version="1.0"?>
<schema targetNamespace="http://example.com/stockquote/schemas"
xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>

http://example.com/stockquote/stockquote.wsdI

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote/definitions"
xmlns:tns="http://example.com/stockquote/definitions"
xmlns:xsd1="http://example.com/stockquote/schemas"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<import namespace="http://example.com/stockquote/schemas"
location="http://example.com/stockquote/stockquote.xsd"/>

<message name="GetLastTradePriceRequest">
<part name="body"element="xsd1:GetLastTradePrice"/>
</message>

<message name="GetLastTradePriceResponse">
<part name="body"element="xsd1:GetLastTradePriceResult"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceRequest"/>
<output message="tns:GetLastTradePriceResponse"/>
</operation>
</portType>
</definitions>

http://example.com/stockquote/stockquoteservice.wsdI

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote/service"
xmlns:tns="http://example.com/stockquote/service"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:defs="http://example.com/stockquote/definitions"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<import namespace="http://example.com/stockquote/definitions"
location="http://example.com/stockquote/stockquote.wsdl"/>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://my.org/GetLastTradePrice"/>
</operation>>
</binding>

<service name="StockQuoteService">
<documentation>첫 번째 서비스</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://my.org/stockquote"/>
</port>
</service>
</definitions>

2.1.3 언어 확장성 및 바인딩

WSDL에서 바인딩이라는 용어는 프로토콜 또는 데이터 형식 정보와 message, operation 또는 portType과 같은 추상 엔티티를 연결하는 과정을 나타냅니다. WSDL는 WSDL로 정의된 다양한 요소 아래 특정 기술(확장성 요소)을 나타내는 요소를 허용합니다. 이러한 확장성은 일반적으로 특정 프로토콜 또는 메시지 형식에 대한 바인딩 정보를 지정하는 데 사용되지만 이러한 사용에 제한되지 않습니다. 확장성 요소는 WSDL 이름 공간과는 다른 XML 이름 공간을 사용해야 합니다. 확장성 요소가 나타날 수 있는 문서에서 특정 위치는 부록 A3에 자세히 설명되어 있습니다.

확장성 요소는 일반적으로 몇몇 특정 기술 관련 바인딩을 지정하는 데 사용됩니다. 통신에 기술 관련 바인딩 기능이 필요한지 또는 선택적인지를 구별하기 위해 확장성 요소는 해당 요소에 부울 형식의 wsdl:required 특성을 배치할 수도 있습니다. 필요한 기본값은 false입니다. 필요한 특성은 이름 공간 "http://schemas.xmlsoap.org/wsdl/"에서 정의됩니다.

확장성 요소를 사용하면 기본 WSDL 규격을 개정하지 않고 네트워크와 메시지 프로토콜 영역을 새로 바꿀 수 있습니다. WSDL은 이러한 프로토콜을 정의하는 규격이 프로토콜이나 형식을 설명하는 데 사용하는 필수 WSDL 확장도 정의할 것을 권장합니다.

확장성 요소에 대한 예제를 보려면 3절, 4절 및 5절을 참조하십시오.

2.1.4 설명서

WSDL은 육안으로 읽을 수 있는 설명서의 컨테이너로서 선택적인 wsdl:document 요소를 사용합니다. 요소의 컨텐트는 임의의 텍스트 및 요소입니다(XSD의 "mixed"). 설명서 요소는 모든 WSDL 언어 요소 안에 허용됩니다.

2.2 형식

types 요소는 교환된 메시지와 관련된 데이터 형식 정의를 묶습니다. 상호 운영성 및 플랫폼 중립성을 최대화 하기 위해 WSDL은 정식의 형식 시스템으로서 XSD를 사용하고 이것을 기본적인 형식 시스템으로 처리합니다.

<definitions…>
<types>
<xsd:schema…/>*
</types>
</definitions>

XSD 형식 시스템은 결과 네트워크 형식이 실제 XML인지 또는 결과 XSD 스키마가 특정 네트워크 형식을 확인하는지 여부에 관계 없이 메시지의 형식을 정의하는 데 사용될 수 있습니다. 특히, 동일한 메시지에 대해 다중 바인딩이 있거나 하나의 바인딩만 존재하지만 해당 바인딩 형식이 널리 사용되는 형식 시스템을 가지지 않는 경우에 유용합니다. 이러한 경우, XSD를 사용하여 추상 형식을 인코딩하기 위한 바람직한 접근 방법은 다음과 같습니다.

특성이 아닌 요소 폼을 사용합니다.
네트워크 인코딩에 고유한 특성이나 요소를 포함하지 않습니다(즉, 메시지의 추상 컨텐트와 무관함). soap:root, soap:encodingStyle, xmi:id, xmi:name 등이 이에 해당하는 예입니다.
배열 형식을 모델링하려면 결과 폼이 SOAP v1.1 문서의 5절에 지정된 인코딩을 실제 사용하는지 여부와 관계 없이, Soap:Array 형식을 사용합니다. 배열 형식에 대해 ArrayOfXXX 이름을 사용합니다(여기서 XXX는 배열에서 항목의 형식임).
xsd:anyType 형식을 사용하여 모든 형식을 가질 수 있는 필드/매개 변수를 표현합니다.

하지만 현재의 추상적인 형식을 포함하여 앞으로 사용하게 될 모든 추상적인 형식을 설명하는 데 사용할 단일 형식의 시스템 문법을 기대하기 어렵기 때문에, WSDL은 형식 시스템이 확장성 요소를 통해 추가될 수 있도록 합니다. 확장성 요소는 types 요소 아래 나타나며 사용되는 형식 정의 시스템을 식별하고 형식 정의에 대해 XML 컨테이너 요소를 제공합니다. 이 요소의 역할은 XML 스키마 언어의 schema 요소의 역할과 비교할 수 있습니다.

<definitions…>
<types>
<-- type-system extensibility element --> *
</types>
</definitions>

2.3 메시지

메시지는 하나 이상의 논리적인 parts로 구성되어 있습니다. 각 부분은 메시지 형식 특성을 사용하는 특정 형식 시스템의 형식과 연관되어 있습니다. 메시지 형식의 특성 집합은 확장할 수 있습니다. WSDL은 XSD에 사용되는 몇몇 메시지 형식의 특성을 정의합니다.

element. QName을 사용하는 XSD 요소를 참조합니다.
type. QName을 사용하는 XSD simpleType 또는 complexType을 참조합니다.

WSDL의 이름 공간과는 다른 이름 공간을 사용하면 다른 메시지 형식 특성이 정의될 수도 있습니다. 확장성 요소 바인딩에도 메시지 형식 특성이 사용됩니다.

메시지를 정의하는 구문은 다음과 같습니다. 사용된 형식 시스템에 따라 다양한 메시지 형식 특성은 굵게 표시되어 있습니다.

<definitions…>
<message name="nmtoken"> *
<part name="nmtoken"? element="qname" type="qname"?/> *
</message>
</definitions>

메시지 name 특성은 해당 WSDL 문서에 정의된 모든 message 간에 고유한 이름을 제공합니다.

부분 name 특성은 해당 메시지의 모든 부분 간에 고유한 이름을 제공합니다.

2.3.1 메시지 부분

part는 message의 논리적인 추상 컨텐트를 설명하는 융통성 있는 메커니즘입니다. 바인딩은 부분에 관한 바인딩별 정보를 지정하기 위해 부분의 이름을 참조할 수 있습니다. 예를 들어, RPC를 사용하기 위해 메시지를 정의하는 경우, 부분은 메시지에 매개 변수를 나타낼 수도 있습니다. 하지만 부분의 실제 의미를 결정하기 위해서는 반드시 바인딩을 점검해야 합니다.

다중 부분 요소는 메시지에 여러 개의 논리적 단위가 있는 경우에 사용됩니다. 예를 들어, 다음 메시지는 주문서와 고객으로 구성되어 있습니다.

하지만, 메시지 컨텐트가 너무 복잡한 경우에는 대체 구문을 사용하여 형식 시스템을 직접 사용하는 복합 메시지 구조를 지정할 수 있습니다. 다음 예제에서, 본문은 주문서 또는 고객 집합이 될 수 있습니다.

2.3.2 추상적인 메시지와 구체적인 메시지

메시지 정의는 항상 메시지 컨텐트의 추상 정의로 간주합니다. 메시지 바인딩은 추상 컨텐트가 구체적인 서식에 매핑되는 방법을 설명합니다. 경우에 따라, 추상 정의가 구체적인 표현과 매우 흡사하거나 하나 이상의 바인딩과 정확히 일치하기도 합니다. 따라서 이러한 바인딩은 매핑 정보를 거의 제공하지 않습니다. 하지만 동일한 메시지 정의의 다른 바인딩은 확장 가능한 매핑 정보가 필요하기도 합니다. 따라서 바인딩을 점검해야 메시지가 실제로 "추상화되는 방법"을 결정할 수 있습니다.

2.4 포트 형식

포트 형식은 추상 작업 및 포함된 추상 메시지의 명명된 집합입니다.

<wsdl:definitions…>
<wsdl:portType name="nmtoken">
<wsdl:operation name="nmtoken"…/> *
</wsdl:portType>
</wsdl:definitions>

포트 형식의 name 특성은 해당 WSDL 문서에 정의된 모든 포트 형식에 고유한 이름을 제공합니다.

작업은 name 특성을 통해 명명됩니다.

WSDL에는 종점에서 지원할 수 있는 네 가지 전송 방식이 있습니다.

단방향. 종점이 메시지를 받습니다.
요청-응답. 종점이 메시지를 받고 관련된 메시지를 보냅니다.
검색-응답. 종점이 메시지를 보내고 관련된 메시지를 받습니다.
알림. 종점이 메시지를 보냅니다.

WSDL은 이러한 전송 방식을 operations로 참조합니다. 요청/응답 또는 검색/응답 작업이 두 개의 단방향 메시지를 사용하여 추상적으로 모델링되더라도, 이 작업을 근본적인 작업의 형식으로서 모델링하는 것이 유용하며 그 이유는 다음과 같습니다.

요청/응답 또는 검색/응답 작업은 일반적입니다.
더 복잡한 이동 정보를 도입하지 않고도 순서가 상호 연관될 수 있습니다.
몇몇 종점은 메시지가 동기화된 요청/응답 작업의 결과일 경우에만 메시지를 받을 수 있습니다.
단순한 흐름은 흐름 정의가 필요한 시점에 이러한 방식으로부터 알고리즘적으로 파생될 수 있습니다.

요청/응답 또는 검색/응답이 WSDL 문서에 논리적으로 상호 연관되어 있어도, 지정된 바인딩은 구체적인 상호 관련 정보를 설명합니다. 예를 들어, 요청 및 응답 메시지는 하나 또는 두 개의 실제 네트워크 통신의 부분으로 교환될 수도 있습니다.

기본 WSDL 구조가 4가지 전송 방식의 바인딩을 지원하지만 WSDL은 단방향과 요청-응답 방식의 바인딩만 정의합니다. 검색-응답 또는 알림용 프로토콜을 정의하는 규격이 이러한 방식을 사용할 수 있는 WSDL 바인딩 확장도 포함할 것으로 기대하고 있습니다.

작업은 QName 형식의 message 특성을 사용하여 포함된 메시지를 참조합니다. 이 특성은 WSDL에 의해 정의된 연결 규칙을 따릅니다(2.1.1절 참조).

2.4.1 단방향 작업

단방향 작업의 문법은 다음과 같습니다.

<wsdl:definitions…> <wsdl:portType…> *
<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

input 요소는 단방향 작업에 대한 추상적인 메시지 형식을 지정합니다.

2.4.2 요청-응답 작업

요청-응답 작업의 문법은 다음과 같습니다.

<wsdl:definitions…>
<wsdl:portType…> *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

input 및 output 요소는 각각 요청과 응답에 대한 추상적인 메시지 형식을 지정합니다. 선택적인 fault 요소는 프로토콜에 한정된 메시지뿐만 아니라 작업의 결과로서 출력되는 모든 오류 메시지에 대한 추상적인 메시지 형식을 지정합니다.

요청-응답 작업은 추상 개념입니다. 특정 바인딩은 HTTP 요청/응답과 같은 단일 통신 내에서 또는 HTTP 요청과 같은 두 개의 독립적인 통신으로서의 메시지를 실제로 보내는 방법을 결정하는 데 사용됩니다.

2.4.3 검색-응답 작업

검색-응답 작업의 문법은 다음과 같습니다.

<wsdl:definitions…>
<wsdl:portType…> *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

output 및 input 요소는 각각 검색된 요청 메시지와 응답 메시지에 대해 추상적인 메시지 형식을 지정합니다. 선택적인 fault 요소는 프로토콜에 한정된 메시지뿐만 아니라 작업의 결과로서 출력되는 모든 오류 메시지에 추상적인 메시지 형식을 지정합니다.

2.4.4 알림 작업

단방향 작업의 문법은 다음과 같습니다.

<wsdl:definitions…>
<wsdl:portType…> *
<wsdl:operation name="nmtoken">
<wsdl:output name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

output 요소는 알림 작업에 추상적인 메시지 형식을 지정합니다.

2.4.5 작업 내 요소의 이름

input 및 output 요소의 name 특성은 이를 포함하는 포트 형식 내에서 모든 input 및 output 요소 간에 고유한 이름을 제공합니다.

작업 중 각 input 및 output 요소의 이름을 지정할 필요가 없도록 하기 위해 WSDL이 작업 이름을 기반으로 하는 몇몇 기본값을 제공합니다. name 특성이 단방향 또는 알림 메시지에 지정되지 않은 경우 기본값은 작업 이름이 됩니다. name 특성이 요청-응답 또는 검색-응답 작업의 input 또는 output 메시지에 지정되지 않은 경우, "Request"/"Solicit" 또는 "Response"가 각각 추가된 작업 이름이 기본값이 됩니다.

각 fault 요소는 바인딩이 fault 메시지의 구체적인 서식을 지정하도록 명명되어야 합니다. fault 요소의 이름은 작업에 대해 정의된 fault의 집합 내에서 고유합니다.

2.4.6 작업 내 매개 변수 순서

작업은 RPC 방식의 바인딩과 함께 사용될지의 여부를 지정하지 않습니다. 하지만 작업과 RPC 바인딩을 함께 사용하는 경우에는 원래 RPC 함수의 서명을 캡처하는 것이 유용합니다. 따라서 요청-응답 또는 검색-응답 작업은 nmtokens 형식의 parameterOrder 특성을 통해 매개 변수 이름 목록을 지정할 수도 있습니다. 특성 값은 단일 공백으로 분리된 메시지 부분의 이름 목록입니다. 명명된 부분은 다음 규칙을 반드시 준수해야 합니다.

부분의 순서는 RPC 서명에서 매개 변수의 순서를 반영하도록 명명됩니다.
return 값 부분은 목록에 없습니다.
부분 이름이 input 메시지와 output 메시지에 모두 나타나면 in/out 매개 변수입니다.
부분 이름이 input 메시지에만 나타나면 in 매개 변수입니다.
부분 이름이 output 메시지에만 나타나면 out 매개 변수입니다.

이 정보는 "참고"로 제공되는 것이므로 RPC 서명과는 관계 없는 경우에는 무시해도 됩니다. 또한 작업이 RPC 방식 바인딩과 함께 사용되는 경우에도 이 정보 제공이 필요하지 않습니다.

2.5 바인딩

바인딩은 특정 portType에 의해 정의된 작업 및 메시지에 대해 메시지 형식 및 프로토콜 정보를 정의합니다. 지정된 portType에 대한 바인딩 수는 제한이 없습니다. 바인딩의 문법은 다음과 같습니다.

<wsdl:definitions…>
<wsdl:binding name="nmtoken" type="qname"> *
<-- extensibility element (1) --> *
<wsdl:operation name="nmtoken"> *
<-- extensibility element (2) --> *
<wsdl:input name="nmtoken"?> ?
<-- extensibility element (3) -->
</wsdl:input>
<wsdl:output name="nmtoken"?> ?
<-- extensibility element (4) --> *
</wsdl:output>
<wsdl:fault name="nmtoken"> *
<-- extensibility element (5) --> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>

name 특성은 이를 포함하는 WSDL 문서에 정의된 모든 바인딩에 고유한 이름을 제공합니다.

바인딩은 type 특성을 사용하여 바인드하는 portType을 참조합니다. 이 QName 값은 WSDL에 의해 정의된 연결 규칙을 따릅니다(2.1.1절 참조).

바인딩의 operation, input, output 및 fault 요소는 portType 내에서 정확히 작동하는 각 요소의 name 특성을 사용하는 해당 portType 요소와 상호 연관되어 있습니다(2.4.5절 참조).

바인딩 확장성 요소는 input (3), output (4) 및 fault 메시지 (5)에 대해 구체적인 문법을 지정하는 데 사용됩니다. 바인딩 단위 정보 (1)뿐만 아니라, 작업 단위 바인딩 정보 (2)도 지정됩니다.

바인딩 내의 작업은 바인딩의 portType 내에서 같은 이름을 가진 작업에 대한 바인딩 정보를 지정합니다. 예를 들어, 메서드 이름을 오버로드하는 경우처럼 작업 이름은 고유할 필요가 없기 때문에 작업 바인딩 요소의 이름 특성만으로 작업을 고유하게 식별하지 못할 수 있습니다. 이러한 경우에는 해당 wsdl:input과 wsdl:output 요소의 name 특성을 제공하여 올바른 작업을 식별하도록 해야 합니다.

한개의 바인딩은 한개의 프로토콜만 지정해야 합니다.

바인딩은 주소 정보를 지정하지 않을 수도 있습니다.

2.6 포트

포트는 바인딩에 대해 단일 주소를 지정하여 개별적인 종점을 정의합니다.

<wsdl:definitions…>
<wsdl:service…> *
<wsdl:port name="nmtoken" binding="qname"> *
<-- extensibility element (1) -->
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

name 특성은 이를 포함하는 WSDL 문서에 정의된 모든 포트에 고유한 이름을 제공합니다.

QName 형식의 binding 특성은 WSDL에 의해 정의된 연결 규칙을 사용하는 바인딩을 참조합니다(2.1.1절 참조).

바인딩 확장성 요소 (1)는 포트에 대해 주소 정보를 지정하는 데 사용됩니다.

한개의 포트는 두개 이상의 주소를 지정하지 않을 수도 있습니다.

포트는 주소 정보가 아닌 바인딩 정보를 전혀 지정하지 않을 수도 있습니다.

2.7 서비스

서비스는 관련된 포트의 집합을 그룹화합니다.

<wsdl:definitions…>
<wsdl:service name="nmtoken"> *
<wsdl:port…/>*
</wsdl:service>
</wsdl:definitions>

name 특성은 이를 포함하는 WSDL 문서에 정의된 모든 서비스에 고유 이름을 제공합니다.

서비스 내의 포트는 다음과 같은 관계를 가지고 있습니다.

포트 간에 서로 통신하지 않습니다(예: 한 포트의 output은 다른 포트의 input이 될 수 없습니다).
별도의 바인딩 및 주소를 사용하면서도 한개의 서비스에 포트 형식을 공유하는 여러 개의 포트가 있는 경우 포트는 대체 요소가 됩니다. 각 포트는 기능적으로 동등한 동작을 제공합니다(전송 및 메시지 형식은 각 바인딩에 의해 제한됨). 이 기능으로 WSDL 사용자는 프로토콜, 거리 등과 같은 몇몇 조건을 기반으로 하여 통신할 수 있는 특정 포트를 선택할 수 있습니다.
이 포트를 확인하여 서비스의 포트의 형식을 결정할 수 있습니다. 이렇게 하면 WSDL 문서의 고객은 이 문서가 여러 개의 포트를 지원하는지의 여부에 따라 특정 서비스와 통신할지를 결정할 수 있습니다. 이 기능은 포트 형식의 작업간에 몇몇 묵시적인 관계가 있는 경우에 유용하며, 특정 작업을 수행하기 위해서는 포트 형식의 전체 집합이 반드시 표시되어야 합니다.

3. SOAP 바인딩

WSDL은 다음과 같은 프로토콜별 정보의 규격을 지원하는 SOAP 1.1 종점에 대한 바인딩을 포함합니다.

바인딩과 SOAP 1.1 프로토콜과의 바운드 표시.
SOAP 종점에 대한 주소 지정 방법.
SOAP의 HTTP 바인딩에 대한 SOAPAction HTTP 헤더의 URI.
SOAP Envelope의 일부로서 전송되는 헤더의 정의 목록.
XSD의 SOAP 루트 지정 방법.

SOAP 바인딩의 집합은 진화하기 때문에 이 바인딩 문법은 아주 확실한 규격은 아닙니다. 추가 SOAP 바인딩은 반드시 이 문법의 개념에서 파생됩니다. 예를 들면 다음과 같습니다.

URI 주소 지정 스키마를 사용하지 않는 SOAP 바인딩은 3.8절에 정의된 soap:address 요소를 재배치하여 다른 주소 지정 스키마를 대체 사용합니다.
SOAPAction이 필요 없는 SOAP 바인딩은 3.4절에 정의된 soapAction 특성을 생략합니다.

3.1 SOAP 예제

다음 예제에서 SubscribeToQuotes SOAP 1.1 단방향 메시지는 SMTP 바인딩을 통해 StockQuote 서비스로 전달됩니다. 요청은 문자열 형식의 증권 시세 표시기 기호를 입력으로 받고, 대체 URI를 정의하는 헤더를 포함합니다.

예제 3. SOAP 헤더를 사용하는 SMTP에서의 단방향 작업의 SOAP 바인딩

이 예제는 GetLastTradePrice SOAP 1.1 요청이 SOAP 1.1 HTTP 바인딩을 통해 StockQuote 서비스로 전달될 수도 있음을 설명합니다. 이 요청은 문자열 형식의 주식 시세 표시기 기호 즉, timeInstant 형식의 time을 입력 받아 SOAP 응답에서 부동 소수점 형식으로 된 가격을 반환합니다.

예제 4. HTTP에서의 요청-응답 RPC 작업의 SOAP 바인딩

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<message name="GetLastTradePriceRequest">
<part name="tickerSymbol" element="xsd:string"/>
<part name="time" element="xsd:timeInstant"/>
</message>

<message name="GetLastTradePriceResponse">
<part name="result" type="xsd:float"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceRequest"/>
<output message="tns:GetLastTradePriceResponse"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>>
</binding>

<service name="StockQuoteService">
<documentation>첫 번째 서비스</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>

이 예제에서는 SOAP 1.1 HTTP 바인딩을 통해 StockQuote 서비스로 GetTradePrices SOAP 1.1 요청을 전송할 수 있음을 설명합니다. 요청은 시작과 종료 시간이 포함된 TimePeriod 구조를 정의한 응용 프로그램인 주식 시세 기호 문자열의 입력을 받아 해당 기간 내에 서비스가 기록한 주식 시세 배열뿐만 아니라 SOAP 응답으로 기록된 주기를 반환합니다. 이 서비스에 대응하는 RPC 서명은 매개 변수 tickerSymbol 및 timePeriod와 함께 출력 매개 변수 주기를 가지며 부동 소수점 배열을 반환합니다.

예제 5. HTTP에서의 요청-응답 RPC 작업의 SOAP 바인딩

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
xmlns:xsd1="http://example.com/stockquote/schema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<schema targetNamespace="http://example.com/stockquote/schema"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<complexType name="TimePeriod">
<all>
<element name="startTime" type="xsd:timeInstant"/>
<element name="endTime" type="xsd:timeInstant"/>
</all>
</complexType>
<complexType name="ArrayOfFloat">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:float[]"/>
</restriction>
</complexContent>
</complexType>
</schema>
</types>

<message name="GetTradePricesInput">
<part name="tickerSymbol" element="xsd:string"/>
<part name="timePeriod" element="xsd1:TimePeriod"/>
</message>

<message name="GetTradePricesOutput">
<part name="result" type="xsd1:ArrayOfFloat"/>
<part name="frequency" type="xsd:float"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice"
parameterOrder="tickerSymbol timePeriod frequency">
<input message="tns:GetTradePricesInput"/>
<output message="tns:GetTradePricesOutput"/>
</operation>
</portType>

<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetTradePrices">
<soap:operation soapAction="http://example.com/GetTradePrices"/>
<input>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded" namespace="http://example.com/stockquote"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>>
</binding>

<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>

3.2 SOAP 바인딩이 WSDL을 확장하는 방법

SOAP 바인딩은 다음과 같은 확장성 요소로 WSDL을 확장합니다.

SOAP 바인딩의 각 확장 요소는 다음 절에 설명하였습니다.

3.3 soap:binding

Envelope, Header 및 Body와 같은 SOAP 바인딩 요소의 목적은 바인딩이 SOAP 프로토콜 서식에 바운드된다는 것을 나타내는 것입니다. 이 요소는 메시지의 인코딩 및 서식에 요청을 만들지 않습니다(예: SOAP 1.1 규격의 5절을 따르는 메시지).

soap:binding 요소는 SOAP 바인딩을 사용할 때 반드시 표시되어야 합니다.

<definitions…>
<binding…>
<soap:binding transport="uri"? style="rpc|document"?>
</binding>
</definitions>

style 특성의 값은 포함된 각 작업에 대한 style 특성의 기본값입니다. style 특성이 생략된 경우 "document"로 간주됩니다. style의 기능에 대한 정보는 3.4절을 참조하십시오.

요청된 transport 특성의 값은 이 바인딩이 SOAP의 어느 전송에 해당하는지를 나타냅니다. URI 값 http://schemas.xmlsoap.org/soap/http는 SOAP 규격에서 HTTP 바인딩에 해당합니다. SMTP, FTP 등과 같은 다른 전송을 나타내기 위해 여기에 다른 URI가 사용되기도 합니다.

3.4 soap:operation

soap:operation 요소는 작업에 대한 전반적인 정보를 제공합니다.

<definitions…>
<binding…>
<operation…>
<soap:operation soapAction="uri"? style="rpc|document"?>
</operation>
</binding>
</definitions>

style 특성은 작업이 매개 변수 및 반환값을 포함하는 RPC 지향적인 메시지인지 문서를 포함하는 문서 지향적인 메시지인지를 나타냅니다. 이 정보는 적합한 프로그래밍 모델을 선택하는 데 사용됩니다. 특성이 지정되지 않은 경우 soap:binding 요소에 지정된 값이 기본값이 됩니다. soap:binding 요소가 스타일을 지정하지 않은 경우에는 "document"로 간주됩니다.

soapAction 특성은 이 작업에 대한 SOAPAction 헤더의 값을 지정합니다. 이 URI 값은 SOAPAction 헤더에 대한 값으로 직접 사용되어야 하며 요청 시 상대적인 URI 값을 절대값으로 만들 수 없습니다. SOAP의 HTTP 프로토콜 바인딩인 경우에는 이 값이 필요하며 기본값이 없습니다. 다른 SOAP 프로토콜 바인딩의 경우 이 값은 지정되지 않을 수도 있고 soap:operation 요소가 생략될 수도 있습니다.

3.5 soap:body

soap:body 요소는 SOAP Body 요소에서 메시지 부분이 나타나는 방법을 지정합니다.

메시지의 부분은 추상적인 형식 정의 또는 구체적인 스키마 정의가 될 수 있습니다. 추상 정의인 경우, 인코딩 스타일에 의해 정의된 일부 규칙 집합에 따라 형식에 순서가 정해집니다. 각 인코딩 스타일은 SOAP 규격에 정의된 바와 같이 URI 목록을 사용하여 식별됩니다. SOAP 인코딩(http://schemas.xmlsoap.org/soap/encoding/)과 같은 일부 인코딩 스타일은 지정된 추상적인 형식 집합에 대한 메시지 형식의 변형을 허용하기 때문에, 모든 변형된 형식을 이해하는 것은 메시지를 읽는 사람의 몫입니다. 즉, 읽는쪽이 올바르게 읽어야 합니다. 모든 변형을 지원할 필요가 없도록 하려면 메시지가 구체적으로 정의된 다음, 참고로서 원래 인코딩 스타일(있는 경우)임을 나타내야 합니다. 이 경우 메시지 작성자는 지정된 스키마를 정확하게 준수해야 합니다. 즉, 쓰는쪽이 올바르게 써야 합니다.

soap:body 바인딩 요소는 SOAP 메시지의 Body 요소 내에 있는 메시지 부분을 조합하는 방법에 대한 정보를 제공합니다. soap:body 요소는 RPC 지향적 메시지와 문서 지향적 메시지에 사용되지만 enclosing 작업의 스타일은 Body 구역을 구성하는 방법에 중요한 영향을 미칩니다.

작업 스타일이 rpc인 경우 각 부분은 매개 변수 또는 반환 값이며 body에 있는 wrapper 요소에 나타납니다(SOAP 규격의 7.1절 참조). wrapper 요소는 작업 이름과 동일한 이름을 가지며 이름 공간은 이름 공간 속성의 값입니다. 각 메시지 부분(매개 변수)은 래퍼 아래 나타나며 호출에 대응하는 매개 변수와 동일한 이름의 accessor로 표현됩니다. 여기서 각 부분은 호출의 매개 변수와 같은 순서로 배열됩니다.
작업 스타일이 문서인 경우 추가 래퍼는 없으며 메시지 부분은 SOAP Body 요소 바로 아래 나타납니다.

Body와 매개 변수 accessor 요소의 컨텐트를 정의하는 데 동일한 메커니즘을 사용합니다.

<definitions…>
<binding…>
<operation…>
<input>
<soap:body parts="nmtokens"? use="literal|encoded"?
encodingStyle="uri-list"? namespace="uri"?>
</input>
<output>
<soap:body parts="nmtokens"? use="literal|encoded"?
encodingStyle="uri-list"? namespace="uri"?>
</output>
</operation>
</binding>
</definitions>

nmtokens 형식의 선택적인 parts 특성은 어느 부분이 메시지의 SOAP Body 내에서 어디에 나타나는지를 표시합니다. 메시지의 다른 부분은 SOAP가 multipart/related MIME 바인딩과 함께 사용될 때와 같이 다른 메시지 영역에 나타날 수 있습니다. parts 특성이 생략되면 메시지에서 정의한 모든 부분이 SOAP Body 영역에 포함된 것으로 간주됩니다.

요청된 use 특성은 몇몇 인코딩 규칙을 사용하여 메시지 부분이 인코드되는지의 여부 또는 부분이 메시지의 구체적인 스키마를 정의했는지의 여부를 나타냅니다.

use가 encoded인 경우에는 각 메시지 부분은 type 특성을 사용하여 추상적인 형식을 참조합니다. 이러한 추상적인 형식은 encodingStyle 특성으로 지정된 인코딩을 적용하여 구체적인 메시지를 작성하는 데 사용됩니다. namespace 특성이 추상적인 형식에 의해 명시적으로 정의되지 않은 컨텐트에만 적용되는 경우에도, names, types 부분 및 namespace 특성의 값은 모두 인코딩의 입력이 됩니다. 참조된 인코딩 스타일이 SOAP 인코딩과 마찬가지로 인코딩 스타일의 변형을 허용하면 모든 변형이 지원되어야 합니다. 즉, 읽는쪽이 올바르게 읽어야 합니다.

use가 literal인 경우에 각 부분은 간단한 부분에 대해서는 element 특성을 사용하거나 복잡한 부분에 대해서는 type 특성을 사용해서 구체적인 스키마를 참조합니다(2.3.1절 참고). encodingStyle 특성의 값은 구체적인 서식이 SOAP 인코딩과 같은 특정 인코딩을 사용하여 파생된 것이지만 지정된 변형만 지원한다는 것을 나타냅니다. 즉, 쓰는쪽이 올바르게 써야 합니다.

encodingStyle 특성의 값은 각각이 단일 공백으로 분리된 URI 목록입니다. URI는 메시지 내에서 사용되는 인코딩을 제한 사항이 가장 많은 것에서 가장 적은 것의 순서로 표시합니다(SOAP 규격에 정의된 encodingStyle 특성과 동일함).

3.6 soap:fault

soap:fault 요소는 SOAP Fault Details 요소의 컨텐트를 지정합니다. 이 요소는 soap:body 요소 뒤에 패턴화됩니다(3.5절 참조).

<definitions…>
<binding…>
<operation…>
<fault>*
<soap:fault name="nmtoken" use="literal|encoded"
encodingStyle="uri-list"? namespace="uri"?>
</fault>
</operation>
</binding>
</definitions>

name 특성은 soap:fault를 작업에 대해 정의된 wsdl:fault에 연결합니다.

fault 메시지는 단일 부분을 가져야 합니다. use, encodingStyle 및 namespace 특성은 모두 soap:body와 동일한 방법으로 사용됩니다(3.5절 참조).

3.7 soap:header

soap:header 요소는 header가 SOAP Envelope의 Header 요소 내에서 전송되도록 정의할 수 있습니다. 이 구역에 모든 헤더를 나열할 필요는 없습니다. WSDL 문서의 다른 규격에 의해 헤더가 실제 페이로드에 추가되도록 하는 것이 일반적이기 때문에 여기에 모든 헤더를 나열할 필요가 없습니다.

use, encodingStyle 및 namespace 특성은 모두 soap:body(3.5절 참조)와 같은 방식으로 사용되며 헤더에 매개 변수가 포함되지 않기 때문에 only style="document"인 것으로 가정합니다

Qname 형식의 message 특성과 nmtoken 형식의 part 특성은 헤더 형식을 정의하는 메시지 부분을 참조합니다. 부분 MAY가 참조하는 스키마는 use="literal"일 경우 soap:actor와 soap:mustUnderstand 특성의 정의를 포함하지만 use="encoded"일 경우에는 포함해서는 안됩니다. 참조된 메시지는 SOAP Body를 정의하는 메시지와 같지 않아도 됩니다.

soap:header 내에 나타나고 soap:header와 같은 구문을 갖는 선택적인 headerfault 요소를 사용하면 soap:header에서 정의하는 헤더에 속하는 오류 정보를 전송하는 데 사용된 헤더 형식 규격이 허용됩니다. SOAP 규격은 헤더에 속하는 오류가 헤더로 반환되어야 한다고 규정하며 이러한 메커니즘을 사용하면 이와 같은 헤더 형식 규격이 허용됩니다.

3.8 soap:address

SOAP 주소 바인딩은 포트에 주소(URI)를 지정하는 데 사용됩니다. SOAP 바인딩을 사용하는 포트는 반드시 하나의 주소만 지정해야 합니다.

<definitions…>
<port…>
<binding…>
<soap:address location="uri"/>
</binding>
</port>
</definitions>

4. HTTP GET 및 POST 바인딩

WSDL은 웹 브라우저와 웹 사이트 간의 상호 작용을 설명하기 위해 HTTP 1.1의 GET 및 POST 동사에 대한 바인딩을 포함합니다. 이 기능은 웹 브라우저가 아닌 응용 프로그램이 사이트와 상호 작용하도록 합니다. 다음과 같은 프로토콜별 정보를 지정할 수 있습니다.

HTTP GET 또는 POST를 사용하는 바인딩 표시
포트에 대한 주소
각 작업에 대한 상대 주소(포트에서 정의한 기본 주소에 상대적임)

4.1 HTTP GET/POST 예제

다음 예제는 지정된 포트 형식에 대해 다르게 바운드된 세 개의 포트를 보여 줍니다.

전달된 값이 part1=1, part2=2, part3=3인 경우, 각 포트에 대한 요청 형식은 다음과 같습니다.

port1: GET, URL="http://example.com/o1/A1B2/3"
port2: GET, URL="http://example.com/o1?p1=1&p2=2&p3=3
port3: POST, URL="http://example.com/o1", PAYLOAD="p1=1&p2=2&p3=3"

각 포트에 대한 응답은 GIF 또는 JPEG 이미지가 됩니다.

예제 5. GIF 또는 JPG를 반환하는 GET 및 FORM POST

<definitions…>
<message name="m1">
<part name="part1" type="xsd:string"/>
<part name="part2" type="xsd:int"/>
<part name="part3" type="xsd:string"/>
</message>

<message name="m2">
<part name="image" type="xsd:binary"/>
</message>

<portType name="pt1">
<operation name="o1">
<input message="tns:m1"/>
<output message="tns:m2"/>
</operation>
</portType>

<service name="service1">
<port name="port1" binding="tns:b1">
<http:address location="http://example.com/"/>
</port>
<port name="port2" binding="tns:b1">
<http:address location="http://example.com/"/>
</port>
<port name="port3" binding="tns:b1">
<http:address location="http://example.com/"/>
</port>
</service>

<binding name="b1" type="pt1">
<http:binding verb="GET"/>
<operation name="o1">
<http:operation location="o1/A(part1)B(part2)/(part3)"/>
<input>
<http:urlReplacement/>
</input>
<output>
<mime:content type="image/gif"/>
<mime:content type="image/jpeg"/>
</output>
</operation>
</binding>

<binding name="b2" type="pt1">
<http:binding verb="GET"/>
<operation name="o1">
<http:operation location="o1"/>
<input>
<http:urlEncoded/>
</input>
<output>
<mime:content type="image/gif"/>
<mime:content type="image/jpeg"/>
</output>
</operation>
</binding>

<binding name="b3" type="pt1">
<http:binding verb="POST"/>
<operation name="o1">
<http:operation location="o1"/>
<input>
<mime:content type="application/x-www-form-urlencoded"/>
</input>
<output>
<mime:content type="image/gif"/>
<mime:content type="image/jpeg"/>
</output>
</operation>
</binding>
</definitions>

4.2 HTTP GET/POST 바인딩이 WSDL을 확장하는 방법

HTTP GET/POST 바인딩은 다음과 같은 확장 요소를 사용하여 WSDL을 확장합니다.

<definitions…>
<binding…>
<http:binding verb="nmtoken"/>
<operation…>
<http:operation location="uri"/>
<input…>
<-- mime elements -->
</input>
<output…>
<-- mime elements -->
</output>
</operation>
</binding>

<port…>
<http:address location="uri"/>
</port>
</definitions>

이러한 요소는 다음 절에 설명되어 있습니다.

4.3 http:address

location 특성은 포트에 대해 기본 URI를 지정합니다. 이 특성의 값은 http:operation 바인딩 요소의 location 특성의 값과 결합됩니다. 자세한 내용은 4.5절을 참조하십시오.

4.4 http:binding

http:binding 요소는 이 바인딩이 HTTP 프로토콜을 사용한다는 것을 나타냅니다.

<definitions…>
<binding…>
<http:binding verb="nmtoken"/>
</binding>
</definitions>

요청된 verb 특성의 값은 HTTP 동사를 나타냅니다. 일반적인 값은 GET 또는 POST이지만 다른 값이 사용될 수도 있습니다. HTTP 동사는 대소문자를 구별해야 합니다.

4.5 http:operation

location 특성은 작업에 대해 상대 URI를 지정합니다. 이 URI는 http:address 요소에 지정된 URI와 결합하여 HTTP 요청에 대한 전체 URI를 만듭니다. URI 값은 상대 URI여야 합니다.

<definitions…>
<binding…>
<operation…>
<http:operation location="uri"/>
</operation>
</binding>
</definitions>

4.6 http:urlEncoded

urlEncoded 요소는 메시지의 모든 부분이 표준 URI 인코딩 규칙(name1=value&name2=value…)을 사용하는 HTTP 요청 URI에 인코드된다는 것을 나타냅니다. 매개 변수의 이름은 메시지 부분의 이름에 해당합니다. 부분에서 제공한 각 값은 이름=값 쌍을 사용하여 인코드됩니다. 이 값은 GET과 함께 사용되어 URL 인코딩을 지정하거나 POST와 함께 사용되어 FORM-POST를 지정하기도 합니다. GET과 함께 사용될 경우 "?" 문자는 필요할 때 자동으로 추가됩니다.

<http:urlEncoded/>

URI 인코딩 매개 변수의 규칙에 대한 자세한 내용은 [5], [6] 및 [7]을 참조하십시오.

4.7 http:urlReplacement

http:urlReplacment 요소는 메시지의 모든 부분이 배치 알고리즘을 사용하는 HTTP 요청 URI로 인코드된다는 것을 나타냅니다.

http:operation의 상대 URI 값을 검색하여 검색 패턴 집합을 찾습니다.
http:operation의 값이 http:address의 location 특성 값과 결합되기 전에 검색이 수행됩니다.
메시지 부분마다 하나의 검색 패턴이 있습니다. 검색 패턴 문자열은 괄호"(" 및 ")"로 둘러 쌓인 메시지 부분의 이름입니다.
일치하는 경우 해당 메시지 부분의 값은 일치된 위치에 있는 내용으로 대치됩니다.
일치 항목을 찾은 후에 값이 바뀌며 바뀐 값은 추가적인 검색 작업을 수행하지 않습니다.

메시지 부분에는 반복되는 값이 없을 수도 있습니다.

<http:urlReplacement/>

5. MIME 바인딩

WSDL은 추상적인 형식을 특정 MIME 형식으로 된 구체적인 메시지에 바인드하는 방법을 가지고 있으며 다음과 같은 MIME 형식에 대한 바인딩이 정의되어 있습니다.

multipart/related
text/xml
application/x-www-form-urlencoded (HTML로 된 폼을 전송하는 데 사용하는 형식)
기타(MIME 형식 문자열 지정)

정의된 MIME 형식의 집합은 계속적으로 크기가 증가하기 때문에, 각 MIME 형식에 대해 XML 문법을 철저하게 정의하는 것이 WSDL의 목표는 아닙니다. 필요한 경우 언제든지 추가적인 MIME 형식에 대한 추가 문법을 정의할 수 있습니다. 컨텐트를 설명하는 데 MIME 형식 문자열을 사용할 수 있다면 아래 정의된 mime 요소를 사용할 수 있습니다.

5.1 MIME 바인딩 예제

예제 7. SOAP에 multipart/related 사용

이 예제는 SOAP 1.1 HTTP 바인딩을 통해 GetCompanyInfo SOAP 1.1 요청을 StockQuote 서비스로 보내는 내용을 설명합니다. 요청은 문자열 형식의 증권 시세 표시기 기호를 입력으로 받습니다. 응답에는 MIME 형식 multipart/related로 인코드된 여러 개의 부분이 포함되어 있습니다. 즉, 부동 소수점으로 된 현재 증권 시세 가격이 있는 SOAP Envelope, HTML 형식으로 된 제로 또는 그 이상의 마케팅 자료 및 GIF 또는 JPFG 형식으로 된 선택적인 회사 로고 등이 여기에 해당합니다.

<definitions…>

<types>
<schema…>
<element name="GetCompanyInfo">
<complexType>
<all>
<element name="tickerSymbol " type="string"/>
</all>
</complexType>
</element>
<element name="GetCompanyInfoResult">
<complexType>
<all>
<element name="result" type="float"/>
</all>
</complexType>
</element>
<complexType name="ArrayOfBinary" base="soap:Array">
<all>
<element name="value" type="xsd:binary"/>
</all>
</complexType>
</schema>
</types>

<message name="m1">
<part name="body" element="tns:GetCompanyInfo"/>
</message>

<message name="m2">
<part name="body" element="tns:GetCompanyInfoResult"/>
<part name="docs" type="xsd:string"/>
<part name="logo" type="tns:ArrayOfBinary"/>
</message>

<portType name="pt1">
<operation name="GetCompanyInfo">
<input message="m1"/>
<output message="m2"/>
</operation>
</portType>

<binding name="b1" type="tns:pt1">
<operation name="GetCompanyInfo">
<soap:operation soapAction="http://example.com/GetCompanyInfo"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<mime:multipartRelated>
<mime:part>
<soap:body parts="body" use="literal"/>
</mime:part>
<mime:part>
<mime:content part="docs" type="text/html"/>
</mime:part>
<mime:part>
<mime:content part="logo" type="image/gif"/>
<mime:content part="logo" type="image/jpeg"/>
</mime:part>
</mime:multipartRelated>
</output>
</operation>
</binding>

<service name="CompanyInfoService">
<port name="CompanyInfoPort"binding="tns:b1">
<soap:address location="http://example.com/companyinfo"/>
</port>
</service>
</definitions>

5.2 MIME 바인딩이 WSDL을 확장하는 방법

MIME 바인딩은 다음과 같은 확장 요소를 사용하여 WSDL을 확장합니다.

<mime:content part="nmtoken"? type="string"?/>

<mime:multipartRelated>
<mime:part> *
<-- mime element -->
</mime:part>
</mime:multipartRelated>

<mime:mimeXml part="nmtoken"?/>

이러한 요소는 다음과 같은 WSDL의 위치에서 사용됩니다.

<definitions…>
<binding…>
<operation…>
<input…>
<-- mime elements -->
</input>
<output…>
<-- mime elements -->
</output>
</operation>
</binding>
</definitions>

MIME 요소는 input 및 output 아래 나타나 MIME 형식을 지정합니다. 여러 개의 MIME 요소가 나타나는 경우 이를 대체 요소로 간주합니다.

5.3 mime:content

모든 MIME 형식에 대해 새 요소를 정의할 필요가 없도록 하기 위해, MIME 형식 문자열 외에 전달할 추가 정보가 없는 경우 mime:content 요소를 사용할 수 있습니다.

<mime:content part="nmtoken"? type="string"?/>

part 특성은 메시지 부분의 이름을 지정하는 데 사용됩니다. 메시지가 단일 부분을 가지고 있는 경우에는 부분의 특성은 선택적입니다. type 특성은 MIME 형식 문자열을 포함합니다. 형식의 값은 슬래시(/) 또는 와일드카드(*)로 구분된 두 영역이 있습니다. type 특성을 지정하지 않으면 모든 MIME 형식을 허용한다는 것을 나타냅니다.

반환 형식이 XML인데 스키마가 미리 알려지지 않은 경우, text/xml을 표시하는 일반적인 mime 요소를 사용할 수 있습니다.

<mime:content type="text/xml"/>

와일드카드(*)는 모든 텍스트 형식과 같이 mime 형식의 패밀리를 지정하는 데 사용됩니다.

<mime:content type="text/*"/>

다음 두 예제는 모든 mime 형식을 지정합니다.

<mime:content type="*/*"/>
<mime:content/>

5.4 mime:multipartRelated

multipart/related MIME 형식은 MIME 형식으로 된 부분의 임의 집합을 MIME 형식 "multipart/related"를 사용하는 하나의 메시지에 집계합니다. mime:multipartRelated 요소는 이런 메시지의 구체적인 형식을 나타냅니다.

<mime:multipartRelated>
<mime:part> *
<-- mime element -->
</mime:part>
</mime:multipartRelated>

mime:part 요소는 multipart/related 메시지의 각 부분을 설명합니다. MIME 요소는 mime:part에 나타나며 해당 부분에 대한 구체적인 MIME 형식을 지정합니다. mime:part 내에 둘 이상의 MIME 요소가 나타나면 이들은 대체 요소입니다.

5.5 soap:body

SOAP 요청과 함께 MIME 바인딩을 사용할 때, MIME 요소로 soap:body 요소를 사용할 수 있습니다. 이것은 컨텐트 형식이 "text/xml"이고, 이를 포함하는 SOAP Envelope가 있음을 나타냅니다.

5.6 mime:mimeXml

SOAP 규격이 아니면서(SOAP Envelope가 없음) 특정 스키마를 가지고 있는 XML 페이로드를 지정하기 위해, mime:mimeXml 요소를 사용하여 구체적인 스키마를 지정할 수 있습니다. part 특성은 루트 XML 요소의 구체적인 스키마를 정의하는 메시지 부분을 참조합니다. part 특성은 메시지가 단일 부분을 가지고 있는 경우에는 생략될 수도 있습니다. 해당 부분은 간단한 부분에 대해서는 element 특성을 사용하고 복잡한 부분에 대해서는 type 특성을 사용하여 구체적인 스키마를 참조합니다(2.3.1절 참조).

<mime:mimeXml part="nmtoken"?/>

6. 참조

[2] S. Bradner, "RFC에서 요청 수준을 표시하는 키워드 사용법", RFC 2119 , Harvard University, 1997년 3월

[4] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): 일반 구문", RFC 2396 , MIT/LCS, U.C. Irvine, Xerox Corporation, 1998년 8월.

[5] http://www.w3.org/TR/html401/interact/forms.html - submit-format

[6] http://www.w3.org/TR/html401/appendix/notes.html - ampersands-in-uris

[7] http://www.w3.org/TR/html401/interact/forms.html - h-17.13.4

[8] Simple Object Access Protocol (SOAP) 1.1 "http://www.w3.org/TR/2000/NOTE-SOAP-20000508/"

[10] W3C Working Draft "XML 스키마 1부: 구조 ". 현재 처리 중입니다.

[11] W3C Working Draft "XML 스키마 2부: 데이터형식 ". 현재 처리 중입니다.

A 1. URI에 대한 참고

이 절에서는 해당 규격에 직접적인 관련은 없지만 규격을 구현할 때 유용한 배경 정보를 제공합니다.

A 1.1 XML 이름 공간 및 스키마 위치

XML 스키마의 targetNamespace 또는 XML 인스턴스의 xmlns 특성을 해당 스키마의 위치로 잘못 인식하는 경우가 많습니다. 이름 공간은 사실 URI이고 이 URI는 위치를 나타낼 수 있으며 해당 위치에서 스키마를 검색할 수 있기는 하지만 이 스키마만 이름 공간과 연관된 것은 아닙니다. 특정 이름 공간과 연관된 여러 개의 스키마가 있을 수 있고, 특정 처리 컨텍스트에서 어떤 스키마를 사용할지는 XML의 프로세서가 결정합니다. 여기서 WSDL 규격은 유사한 개념의 XML 스키마를 기반으로 하는 <import> 메커니즘을 통해 처리 컨텍스트를 제공합니다.

A 1.2 상대 URI

이 문서를 통해 WSDL 및 XSD 문서에서 정식 URI를 볼 수 있습니다. 정식 URI의 사용은 단순히 참조하는 개념을 보여주는 것입니다. 상대 URI의 사용은 전적으로 허용되며 많은 경우에 그 사용이 보장됩니다. 상대 URI 처리에 관한 내용은 http://www.normos.org/ietf/rfc/rfc2396.txt 를 참조하십시오.

A 1.3 URI 작성

WSDL로 작업할 때 항상 전역적으로 고유한 URI를 작성하는 대신 특정 엔티티에 대한 URI를 작성하여 해당 엔티티 버전(스키마, WSDL 문서 등)을 "의미"하도록 하는 것이 바람직한 경우가 있습니다. 이러한 유형의 동작에 사용하기 위해 예약된 특별한 기본 URI가 있습니다. 기본 URI인 http://tempuri.org/는 어떤 엔티티와도 고유한 연관성이 없는 URI를 구성하는 데 사용될 수 있습니다. 예를 들어, 두 사람 또는 두개의 프로그램에서 완전히 다른 두 스키마에 대해 URI인 http://tempuri.org/myschema를 동시에 사용할 수 있고 URI 사용의 범위가 교차하지 않으면 고유한 URI로 간주됩니다. 이러한 기능은 URI에 의해 참조된 엔티티가 처리 중인 컨텍스트 내에서 유효하기만 하다면 새로운 URI를 작성하지 않고도 설명될 수 있다는 장점이 있습니다. 안정적이고 고정된 엔티티에 대해, http://tempuri.org/를 기본 URI로 사용하는 것은 바람직하지 못합니다.

A 2. 네트워크 형식의 WSDL 예제

A 2.1. 예제 1

HTTP 요청에 포함된 SOAP 메시지

POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<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:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

HTTP 응답에 포함된 SOAP 메시지

HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn

<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:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

A 3. 확장성 요소의 위치

확장성 요소는 WSDL 문서의 다음과 같은 위치에서 나타날 수 있습니다.

위치	의미	사용법
definitions	확장성 요소는 WSDL 문서에 전반적으로 적용됩니다.	· WSDL 문서에 추가 정보 또는 정의를 전반적으로 소개합니다.
definitions/types	확장성 요소는 형식 시스템입니다.	· XSD가 아닌 형식 시스템에 메시지의 서식을 지정합니다.
definitions/service	확장성 요소는 service에 적용됩니다.	· service에 추가 정보 또는 정의를 소개합니다.
definitions/service/port	확장성 요소는 port에 적용됩니다.	· port에 address를 지정합니다.
definitions/binding	확장성 요소는 binding에 전반적으로 적용됩니다.	· 모든 작업에 적용할 프로토콜별 정보를 바운드 될 port 형식에 제공합니다.
definitions/binding/operation	확장성 요소는 operation에 전반적으로 적용됩니다.	· input 및 output 메시지에 적용할 프로토콜별 정보를 제공합니다.
definitions/binding/operation/input	확장성 요소는 operation에 대한 input 메시지를 적용합니다.	· 추상 메시지 부분이 바인딩 데이터 형식 및 구체적인 프로토콜에 매핑되는 방법에 대한 자세한 정보를 제공합니다. · input 메시지에 추가적인 프로토콜별 정보를 제공합니다.
definitions/binding/operation/output	확장성 요소는 operation에 대한 output 메시지에 적용됩니다.	· 추상 메시지 부분이 바인딩 데이터 형식 및 구체적인 프로토콜에 매핑되는 방법에 대한 자세한 정보를 제공합니다. · output 메시지에 추가 프로토콜별 정보를 제공합니다.
definitions/binding/operation/fault	확장성 요소는 operation의 fault 메시지에 적용됩니다.	· 추상 메시지 부분이 바인딩 데이터 형식 및 구체적인 프로토콜에 매핑되는 방법에 대한 자세한 정보를 제공합니다. · fault 메시지에 추가적인 프로토콜별 정보를 제공합니다.

A 4. 스키마

A 4.1 WSDL 스키마

<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
targetNamespace="http://schemas.xmlsoap.org/wsdl/"
elementFormDefault="qualified">
<element name="documentation">
<complexType mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<any minOccurs="0" maxOccurs="unbounded"/>
</choice>
<anyAttribute/>
</complexType>
</element>
<complexType name="documented" abstract="true">
<sequence>
<element ref="wsdl:documentation" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="openAtts" abstract="true">
<annotation>
<documentation>
This type is extended by component types
to allow attributes from other namespaces to be added.
</documentation>
</annotation>
<sequence>
<element ref="wsdl:documentation" minOccurs="0"/>
</sequence>
<anyAttribute namespace="##other"/>
</complexType>
<element name="definitions" type="wsdl:definitionsType">
<key name="message">
<selector xpath="message"/>
<field xpath="@name"/>
</key>
<key name="portType">
<selector xpath="portType"/>
<field xpath="@name"/>
</key>
<key name="binding">
<selector xpath="binding"/>
<field xpath="@name"/>
</key>
<key name="service">
<selector xpath="service"/>
<field xpath="@name"/>
</key>
<key name="import">
<selector xpath="import"/>
<field xpath="@namespace"/>
</key>
<key name="port">
<selector xpath="service/port"/>
<field xpath="@name"/>
</key>
</element>
<complexType name="definitionsType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<element ref="wsdl:import" minOccurs="0" maxOccurs="unbounded"/>
<element ref="wsdl:types" minOccurs="0"/>
<element ref="wsdl:message" minOccurs="0" maxOccurs="unbounded"/>
<element ref="wsdl:portType" minOccurs="0" maxOccurs="unbounded"/>
<element ref="wsdl:binding" minOccurs="0" maxOccurs="unbounded"/>
<element ref="wsdl:service" minOccurs="0" maxOccurs="unbounded"/>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded">
<annotation>
<documentation>to support extensibility elements </documentation>
</annotation>
</any>
</sequence>
<attribute name="targetNamespace" type="uriReference" use="optional"/>
<attribute name="name" type="NMTOKEN" use="optional"/>
</extension>
</complexContent>
</complexType>
<element name="import" type="wsdl:importType"/>
<complexType name="importType">
<complexContent>
<extension base="wsdl:documented">
<attribute name="namespace" type="uriReference" use="required"/>
<attribute name="location" type="uriReference" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="types" type="wsdl:typesType"/>
<complexType name="typesType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="message" type="wsdl:messageType">
<unique name="part">
<selector xpath="part"/>
<field xpath="@name"/>
</unique>
</element>
<complexType name="messageType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<element ref="wsdl:part" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="part" type="wsdl:partType"/>
<complexType name="partType">
<complexContent>
<extension base="wsdl:openAtts">
<attribute name="name" type="NMTOKEN" use="optional"/>
<attribute name="type" type="QName" use="optional"/>
<attribute name="element" type="QName" use="optional"/>
</extension>
</complexContent>
</complexType>
<element name="portType" type="wsdl:portTypeType"/>
<complexType name="portTypeType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<element ref="wsdl:operation" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="operation" type="wsdl:operationType"/>
<complexType name="operationType">
<complexContent>
<extension base="wsdl:documented">
<choice>
<group ref="wsdl:one-way-operation"/>
<group ref="wsdl:request-response-operation"/>
<group ref="wsdl:solicit-response-operation"/>
<group ref="wsdl:notification-operation"/>
</choice>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<group name="one-way-operation">
<sequence>
<element ref="wsdl:input"/>
</sequence>
</group>
<group name="request-response-operation">
<sequence>
<element ref="wsdl:input"/>
<element ref="wsdl:output"/>
<element ref="wsdl:fault" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</group>
<group name="solicit-response-operation">
<sequence>
<element ref="wsdl:output"/>
<element ref="wsdl:input"/>
<element ref="wsdl:fault" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</group>
<group name="notification-operation">
<sequence>
<element ref="wsdl:output"/>
</sequence>
</group>
<element name="input" type="wsdl:paramType"/>
<element name="output" type="wsdl:paramType"/>
<element name="fault" type="wsdl:faultType"/>
<complexType name="paramType">
<complexContent>
<extension base="wsdl:documented">
<attribute name="name" type="NMTOKEN" use="optional"/>
<attribute name="message" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="faultType">
<complexContent>
<extension base="wsdl:documented">
<attribute name="name" type="NMTOKEN" use="required"/>
<attribute name="message" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="startWithExtensionsType" abstract="true">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="binding" type="wsdl:bindingType"/>
<complexType name="bindingType">
<complexContent>
<extension base="wsdl:startWithExtensionsType">
<sequence>
<element name="operation" type="wsdl:binding_operationType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
<attribute name="type" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="binding_operationType">
<complexContent>
<extension base="wsdl:startWithExtensionsType">
<sequence>
<element name="input" type="wsdl:startWithExtensionsType" minOccurs="0"/>
<element name="output" type="wsdl:startWithExtensionsType" minOccurs="0"/>
<element name="fault" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="wsdl:startWithExtensionsType">
<attribute name="name" type="NMTOKEN" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="service" type="wsdl:serviceType"/>
<complexType name="serviceType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<element ref="wsdl:port" minOccurs="0" maxOccurs="unbounded"/>
<any namespace="##other" minOccurs="0"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="port" type="wsdl:portType"/>
<complexType name="portType">
<complexContent>
<extension base="wsdl:documented">
<sequence>
<any namespace="##other" minOccurs="0"/>
</sequence>
<attribute name="name" type="NCName" use="required"/>
<attribute name="binding" type="QName" use="required"/>
</extension>
</complexContent>
</complexType>
<attribute name="arrayType" type="string"/>
</schema>

A 4.2 SOAP 바인딩 스키마

A 4.3 HTTP 바인딩 스키마

A 4.4 MIME 바인딩 스키마

'Architecture' 카테고리의 다른 글

티스토리 시스템 장애 관련 (0)	2009.04.17
Map Reduce (2)	2008.05.14
네트워크 프로그래밍시 유의사항 (0)	2006.07.20
공짜 라이브러리 (0)	2006.01.23
[펌] Dual Core 란 무엇인가? (0)	2006.01.04

Posted by '김용환'