SOAP Version 1.2 Part 0: Primer
W3C Recommendation 24 June 2003
- 현재 버전:
- http://www.w3.org/TR/2003/REC-soap12-part0-20030624/
- 최신 버전:
- http://www.w3.org/TR/soap12-part0/
- 이전 버전:
- http://www.w3.org/TR/2003/PR-soap12-part0-20030507/
- 저자:
- Nilo Mitra (Ericsson)
- 번역자:
- ChangHee Lee (Initech)
- 최종 번역 수정일:
- 2004년 10월 6일 17시 49분
정오표는 이 문서에 대한 공식적인 수정을 포함할 수 있다. 이를 참조해라.
이 문서의 영어 버전이 공식 버전이다. 비공식적인 번역본들이 가용할 수 있다.
Copyright 2003 W3C@ (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
Translated document may contain errors from translation.
이 번역본은 원본 문서에는 없지만, 번역 과정에서 발생한 오류를 포함할 수 있습니다. 번역 과정에서 생긴 오류를 발견하신 분은 guldook at gmail.com 으로 내용을 보내주시면 감사하겠습니다.
SOAP Version 1.2 Part 0: Primer는, SOAP 버전 1.2 규격의 특징들을 쉽게 이해할 수 있는 튜토리얼을 제공하는 것을 목적으로 하는, 비공식적인 문서이다. 특히, 이 문서는 여러가지 사용 시나리오들을 통해서 특징을 설명하고 SOAP 1.2 규격의 Part 1 과 Part 2에 포함된 공식 내용들을 보완하는 데 목적이 있다.
- 1. 소개
-
- 1.1 개요
- 1.2 기호 표기 약정
- 2. 기본 사용 시나리오
-
- 2.1 SOAP 메시지들
- 2.2 SOAP 메시지 교환
-
- 2.2.1 대화형 메시지 교환
- 2.2.2 원격 프로시저 호출들 (RPCs)
- 2.3 장애(Fault) 시나리오들
- 3. SOAP 처리 모델
-
- 3.1 "role" 속성
- 3.2 "mustUnderstand" 속성
- 3.3 "relay" 속성
- 4. 여러 가지 프로토콜 바인딩들
-
- 4.1 SOAP HTTP 바인딩
-
- 4.1.1 SOAP HTTP GET 사용
- 4.1.2 SOAP HTTP POST 사용
- 4.1.3 웹 구조 호환 SOAP 사용
-
- 4.2 전자우편을 통한 SOAP
- 5. 고급 사용 시나리오들
-
- 5.1 SOAP 중간 서버들(Intermediaries)을 사용해서
- 5.2 다른 인코딩 스킴들을 사용해서
- 6. SOAP 1.1과 SOAP 1.2간의 차이점
- 7. 참고 문헌
- A. 감사의 글(Acknowledgment)
SOAP 버전 1.2 Part 0: Primer는 SOAP 버전 1.2 규격의 특징들을 쉽게 이해할 수 있는 튜토리얼을 제공하는 것을 목적으로 하는 비공식적인 문서이다. 이 문서는 대표적인 SOAP 메시지 구조들과 메시지 교환 패턴들을 설명함으로써, 기술자들이 SOAP을 어떻게 사용해야 하는 지 이해하도록 하는 데 그 목적이 있다.
특히, 이 입문서는 여러 가지 사용 시나리오들을 통해서 SOAP의 특징들을 설명하고, SOAP 버전 1.2 Part 1: 메시지 프레임워크 (이 문서에서 [SOAP Part1]) 와 SOAP 버전 1.2 규격의 SOAP 버전 1.2 Part 2: 부가물(Adjuncts) (이 문서에서 [SOAP Part2])의 본문을 보충 설명한다.
이 문서의 독자들은 XML 네임스페이스 및 infoset들의 사용을 포함하는 XML의 기본 문법과 URI 및 HTTP와 같은 웹의 개념들을 이해하고 있다고 가정한다. 이 문서는 주로 SOAP 규격을 구현하려는 사람보다는 응용 프로그램 설계자들과 같이 SOAP의 사용자들을 위해 쓰여졌다. 이 문서는 SOAP 버전 1.2의 모든 뉘앙스 또는 모든 사용 예를 완벽하게 설명하는 데 촛점을 두지 않고, 핵심적인 특징들을 조명하는 데 촛점을 두었다. 따라서, SOAP에 대한 완전한 이해를 얻는 데 있어서 입문서(primer)는 메인 규격의 대체가 아니다. 그런 목적하에, 이 입문서는 새로운 개념이 소개되거나 사용될 때마다 메인 규격의 해당 개념에 대한 많은 참조 링크를 제공한다.
[SOAP Part1]은 SOAP envelope을 정의한다. SOAP envelope은 SOAP 메시지의 컨텐츠를 표현하고, 해당 컨텐츠의 일부 혹은 전체를 누가 처리해야 하는 지 그리고 그런 부분을 처리하는 것이 선택인 지 필수인 지를 명시하기 위한 전반적인 프레임워크를 정의한다. SOAP envelope은 또한 SOAP이 다른 프로토콜로 어떻게 바인딩되는 지를 설명하는 프로토콜 바인딩 프레임워크를 정의한다.
[SOAP Part2]는 SOAP의 데이터 모델, 특히 [SOAP Part1]에 정의된 프로토콜 바인딩 프레임워크의 구체적인 하나의 구현 뿐만 아니라 RPC를 전달하는 데 사용될 수 있는 데이터 타입들에 대한 인코딩 스킴(scheme)을 정의한다. 이 바인딩은 SOAP 메시지들을 HTTP POST 요청과 응답의 내용(payload)으로써 또는 HTTP GET 응답의 내용으로써 SOAP 메시지를 교환할 수 있도록 한다.
이 문서는 공식 문서가 아니다, 즉 SOAP 버전 1.2의 최종 규격을 제공하지는 않는다. 여기서 제공되는 예제들은 공식 규격을 보충 설명하기 위함이고, 해석할 때 공식 문서가 당연히 선행한다. 이 문서의 예제들은 SOAP의 다양한 이용 방법들 중에 일부를 보여준다. 실제 사용 시나리오에서, SOAP은 틀림없이 전체 솔루션의 일부분일 것이고 예제들에서 포함하지 않은 응용 프로그램 특화된 요구사항들이 존재할 것임이 분명하다.
SOAP 버전 1.2는 분산된 환경에 있는 참여자들 간에 구조화되고 형식화된 정보를 교환하는 데 사용하는, XML 기반의 정보에 대한 정의를 제공한다. [SOAP Part1]은 SOAP 메시지를 형식적으로는 컨텐츠에 대한 추상적인 설명을 제공하는 XML Infoset으로써 정의한다고 설명한다. Infoset들은 하나 하나가 [XML 1.0] 문서인, 서로 다른 통신상의 표현들을 가질 수 있다.
SOAP은 기본적으로 무상태(stateless), 일방향 메시지 교환 패러다임이지만, 응용 프로그램은 그런 일방향 교환과 하위 프로토콜에 의해 제공되는 특징들을 결합함으로써 훨씬 더 복잡한 상호 작용 패턴(예: 요청/응답, 요청/multiple 응답s 등)을 만들 수 있다. SOAP은 전달하는 응용 프로그램 관련 데이터의 의미에 대해서는 언급하지 않는다. 그러나, SOAP은 응용 프로그램이 관련 정보를 확장 가능한 방식으로 전달할 수 있는 프레임워크를 제공한다. 또한 SOAP은, SOAP 노드가 SOAP 메시지를 받아서 처리하는 과정에서의 필수 조치들에 대한 전체적인 설명을 제공한다.
이 문서의 Section 2는 가장 간단한 사용 시나리오-즉 일방향 SOAP 메시지-를 가지고 출발해서 SOAP의 기본적인 특징들을 소개한다. 이 간단한 시나리오 이후에 RPC들을 포함하여 여러 가지 요청-응답 형식의 교환이 일어난다. 장애 상황들 또한 설명된다.
Section 3은 메시지의 초기 구성에 대한 규칙, 중개 또는 최종 목적지에서 받았을 때의 메시지 처리 규칙, 중간(intermediary) 서버에서 메시지의 일부를 추가, 삭제, 수정하는 규칙 등을 설명하는 SOAP 처리 모델의 개관을 제공한다.
이 문서의 Section 4는 여러 가지 사용 시나리오들을 실현하기 위해 SOAP 메시지들을 전송하는 방법을 설명한다. 어떻게 전자 우편 메시지로 SOAP 메시지들 전달할 수 있는 지에 대한 예제를 포함하여 [SOAP Part2]에 정의된 SOAP HTTP 바인딩을 설명한다. HTTP 바인딩의 부분으로써, 응용 프로그램이 사용할 수 있는 두 가지 메시지 교환 패턴을 소개한다. 하나는 HTTP POST 방법이고, 다른 것은 HTTP GET을 사용하는 것이다. 예제들은 또한 어떻게 월드 와이드 웹의 구조적인 원칙들에 부합하는 방식의 SOAP 메시지 교환을 통해 RPC들을 처리할 수 있는 지를 설명한다,특히 "안전한" 정보 획득을 해야 하는 경우에 그러하다.
이 문서의 Section 5는 훨씬 더 복잡한 사용 시나리오에 적용할 수 있는 SOAP의 여러 특징을 취급하는 방법을 설명한다. 여기에는 헤더 엘리먼트(element)들을 사용하여 제공되는 확장 메커니즘이 포함된다. 이 방법은 중간 SOAP 노드들이 송수신 어플리케이션에 부가 서비스를 제공하고, SOAP 메시지들에 포함된 응용 프로그램 특화된 데이터를 여러 가지 인코딩 스킴들을 사용해서 직열화(serialize)하기 위함이다.
이 문서의 Section 6은 SOAP 버전 1.1 [SOAP 1.1]과의 차이점을 설명한다.
이 문서의 Section 7은 참고 문헌들을 제공한다.
참고하기 용이하도록, 이 입문서에 사용된 용어와 개념은 메인 규격에 있는 해당 개념에 대한 정의로 하이퍼 링크된다.
이 입문서에서는, 간단한 SOAP envelope들과 메시지들을 [XML 1.0] 문서들로 표현한다. [SOAP Part1]은 공식적으로 SOAP 메시지를 - 해당 SOAP 메시지의 컨텐츠에 대한 추상적인 설명인 - [XML InfoSet]으로써 정의한다. 이 입문서를 통해 SOAP에 입문하는 사람들은 SOAP XML Infoset들과 XML 1.0 문서들 간의 차이점에는 거의 관심이 없을 것이다; 관심있는 사람들 - 특히 SOAP을 새로운 프로토콜 바인딩으로 포팅하는 사람들 - 은 이 문서의 예제들을, 그것과 대응되는 XML infoset들을 참조해서 이해해야 한다. 이 점에 대한 상세 설명은 이 문서의 Section 4에서 제공된다.
이 문서의 섹션들에 사용되는 네임스페이스 접두어들 "env", "enc", 그리고 "rpc"는 각각 "http://www.w3.org/2003/05/soap-envelope", "http://www.w3.org/2003/05/soap-encoding", 그리고 "http://www.w3.org/2003/05/soap-rpc" SOAP 네임스페이스 이름들과 관련된다.
이 문서의 섹션들에서 사용된 네임스페이스 접두어 "xs"와 "xsi"는 각각 "http://www.w3.org/2001/XMLSchema" 그리고 "http://www.w3.org/2001/XMLSchema-instance"와 관련된다. 둘다 XML Schema 규격들
[XML Schema Part1],
[XML Schema Part2]에서 정의된다.
어떤 다른 네임스페이스 접두어의 선택은 임의이며 의미상 중요하지는 않다.
"http://example.org/..."와 "http://example.com/..." 등 일반적인 형식의 네임스페이스 URI들은 응용 프로그램에 따라 또는 문맥에 따라 다른 URI [RFC 2396]를 나타낸다.
SOAP 메시지는 기본적으로 SOAP 송신자로부터 SOAP 수신자로의 SOAP 노드들 간의 일방향 트랜젝션이다, 하지만 SOAP 메시지들은 요청/응답에서부터 다수, 양방향 "대화형" 통신에 이르기까지 훨씬 더 복잡한 상호 작용 패턴을 구현하기 위해 어플리케이션에 의해 합쳐질 것이다.
이 입문서는 SOAP 메시지의 구조와, 여행 예약 어플리케이션에서의 간단한 사용 시나리오들를 기반으로 SOAP 메시지의 통신을 설명하는 것으로 시작한다. 이 어플리케이션 시나리오의 여러 가지 측면들이 입문서 전체에 사용될 것이다. 이 시나리오에서, 회사 직원용 여행 예약 어플리케이션은, 여행 계획에 대해서 여행 예약 서비스와 협상한다. 여행 예약 어플리케이션과 여행 서비스 어플리케이션 간에 교환되는 정보는 SOAP 메시지의 형태이다.
여행 예약 어플리케이션으로부터 송신된 SOAP 메시지의 궁극적인 수신자는 여행 서비스 어플리케이션이다, 하지만 SOAP 메시지가 하나 또는 훨씬 많은 SOAP 중간 서버들을 통해 라우팅될 수 있다. 그런 SOAP 중간 서버들 중에 몇몇은 각 여행 요청를 로깅하고, 감사하고, 또는 수정하는 것일 수 있다. 예제들과 SOAP 중간 서버들의 동작과 역할에 대한 상세한 논의는 section 5.1로 미룬다.
Section 2.1은 SOAP 메시지로 표현된 여행 예약 요청을 통해 SOAP 메시지의 여러 가지 "부분들"을 설명한다.
Section 2.2.1은 다른 SOAP 메시지 - 여행 요청의 제약조건을 만족하는 여러 가지 선택 사항들을 협상하는 대화형 메시지 교환을 구성하는 - 의 형태로 여행 서비스로부터의 응답를 보여주기 위해 같은 시나리오를 사용한다.
Section 2.2.2는 여행자가 여러 가지 여행 예약의 파라미터에 동의했고, 여행 예약과 여행 서비스 어플리케이션 간에 예약 지불 확인을 위한 -RPC를 모델로 하는- 통신이 이루어진다고 가정한다.
Section 2.3은 장애 처리 예제를 보여준다.
예제 1은 SOAP 메시지로 표현된 여행 예약 데이터를 보여준다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid-morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>헤더 블록과 본문을 포함한 여행 예약에 대한 SOAP 예제 메시지
예제 1에 SOAP 메시지는 전체 env:Envelope 내에 두 개의 SOAP 특화된 서브 엘리먼트들을 포함한다, 즉 env:Header 와 env:Body. 이 엘리먼트들의 내용은 어플리케이션이 정의하는 것이고 SOAP 규격에 포함되지 않는다, 후자가 그런 엘리먼트들을 어떻게 처리해야 하는 지를 설명하는 부분을 가지고 있을지라도.
A SOAP 헤더 엘리먼트는 선택이지만, SOAP의 어떤 특징들을 설명하기 위해 예제로 포함되었다. SOAP 헤더는 어플리케이션이 전달하고자 하는 내용이 아닌 정보를 SOAP 메시지로 전달하기 위한 확장 메커니즘이다. 그런 "제어" 정보는, 예를 들어, 메시지의 처리와 관련된 명령들 또는 처리 환경(contextual) 정보의 전달을 포함한다. 이를 통해 SOAP 메시지를 어플리케이션 특화된 방법으로 확장할 수 있다. env:Header 엘리먼트의 하위 차일드 엘리먼트들은 헤더 블록들이라고 부르며 각각은, 송신자에서 궁극적인 수신자로의 메시지 전달 경로 상에 있는 SOAP 노드들로 전달될 수 있는, 데이터의 논리적 그룹을 나타낸다.
SOAP 헤더들은 SOAP에서 여러 가지 용도로 사용될 수 있도록 설계되었다. 이 용도 중 많은 것들은 초기 SOAP 송신자로부터 궁극적인 SOAP 수신자까지의 메시지 전송 경로 상의 다른 SOAP 처리 노드들- SOAP 중간 서버들로 불리는-의 참여를 포함할 것이다. 이것은 SOAP 중간 서버들이 부가 서비스를 제공할 수 있도록 한다. 후에 설명하겠지만, 헤더들은 SOAP 메시지 경로 상에서 만날 수 있는 SOAP 노드들에 의해 검사되고, 추가되고, 삭제되고 또는 전달될 수 있다. (그럼에도불구하고, SOAP 규격은 헤더 엘리먼트의 내용이 뭔지, SOAP 메시지들이 노드들 간에 어떻게 라우팅되어야 하는 지, 경로가 결정되는 방식 등등을 다루지 않는다.)
SOAP body는 SOAP env:Envelope 내에 필수 엘리먼트이다, 즉 이 엘리먼트에 SOAP 메시지로 전달되는 메인 단대단 정보가 포함되어야 한다는 것을 의미한다.
예제 1은 SOAP 메시지를 그림으로 설명한다.
예제 1에서 헤더는 두 가지 헤더 블록들을 포함한다, 각 블록은 그 자신의 XML 네임스페이스로 정의되고 SOAP 메시지의 body를 처리하는 전 과정과 관련된 특징을 표현한다. 이 여행 예약 어플리케이션에서, 모든 요청에서 유지되는 그런 "메타" 정보에 해당하는 것은, 특정 예약의 인스턴스를 지정하는 참조자와 타임스탬프를 제공하는 reservation 헤더 블록과 passenger 블록에 있는 여행자의 identity이다.
헤더 블록 reservation과 passenger는 메시지 경로 상 다음에 있는 SOAP 중간 서버에 의해, 만약 그런 중간 서버가 없다면 메시지의 궁극적인 수신자에 의해 처리되어야 한다. 값이 "http://www.w3.org/2003/05/soap-envelope/role/next"(이후로 단지 "next")인 env:role 속성 - 모든 SOAP 노드들은 맡아야 할 role이 있다 - 은 헤더 블록들이 라우팅 경로 상에 있는 다음 SOAP 노드를 목표로 한다는 사실을 명시한다. "true"값을 가지는 env:mustUnderstand 속성은 헤더를 처리하는 노드가 반드시 이러한 헤더 블록을 그들의 규격에 부합하는 방식으로 처리하거나, 그렇지 않으면 전혀 처리하지 말고 장애(fault)를 던져라라는 것을 명시한다. 헤더 블록을 처리할 때마다, env:mustUnderstand="true"로 설정되었기 때문에 또는 다른 이유로 해당 블록을 그 블록의 규격에 따라 처리해야 한다는 것을 주지해라. 그런 헤더 블록 규격들은 어플리케이션이 정의할 부분이며 SOAP의 부분이 아니다. Section 3은 이런 속성들의 값을 바탕으로 SOAP 메시지 처리를 더욱 상세화할 것이다.
헤더 블록과 SOAP body에 어떤 데이터를 포함할 지는 어플리케이션 설계 단계에서 이루어지는 결정이다. 명심할 점은 헤더 블록들이 송신자에서부터 궁극적인 수신자로의 메시지 경로 상에 있는 여러 노드들을 거쳐야 한다는 것이다. 그런 중간 SOAP 노드들은 헤더에 포함된 데이터를 기초로 부가 서비스를 제공할 수도 있다. 예제 1에서는, SOAP 중간 서버가 어떻게 헤더 블록에 포함된 여행자 데이터를 사용하여 추가 처리를 하는 지를 설명한다. 예를 들어, 이후에 section 5.1에서 설명하겠지만, SOAP 중간 서버는 여행자에게 유지될 여행 정책을, 헤더 블록으로써 메시지에 추가하는 방식으로 outbound 메시지를 변경한다.
env:Body 엘리먼트와 관련 차일드 엘리먼트들, itinerary 그리고 lodging,은 초기 SOAP 송신자와 메시지 경로에서 궁극적인 SOAP 수신자-여행 서비스 어플리케이션-의 역할을 하는 SOAP 노드 간에 정보의 교환을 목적으로 한다. 따라서, env:Body와 그 내용들은 암묵적으로 궁극적인 수신자를 향한 것이고 수신자는 그것들을 이해한다고 기대한다. SOAP 노드가 그런 역할을 가정하는 수단은 SOAP 규격에서 정의되지 않고, 일부 어플리케이션 시맨틱스와 관련 메시지 흐름으로써 결정된다.
SOAP 중간 서버가 주어진 메시지 전달에서 궁극적인 SOAP 수신자의 역할을, 따라서 env:Body를 처리할 수도 있다는 점을 주지해라. 그러나, 이렇게 처리하는 것은 막을 수 없음에도 불구하고, 그것이 메시지 송신자의 의도를 곡해하고 원하지 않는 부산물(메시지 경로 상에 이어지는 중간 서버를 향하는 헤더 블록들을 처리하지 않는 것과 같은)을 낳을 수 있기 때문에 가볍게 처리될 것은 아니다.
예제 1에 있는 것과 같은 SOAP 메시지는 서로 다른 하위 프로토콜로 전달될 수 있고 여러 가지 메시지 교환 패턴들에서 사용될 수 있다. 예를 들어 웹 기반으로 여행 서비스 어플리케이션에 접근할 때, HTTP POST 요청의 body에 SOAP 메시지를 포함할 수 있다. 또 다른 프로토콜 바인딩에서, 메시지는 전자 우편 메시지로 보내질 수도 있다( section 4.2 참조). Section 4 는 어떻게 SOAP 메시지들이 여러 가지 하위 프로토콜들에 의해 전달되는 지를 설명할 것이다. 당분간 메시지 전달을 위한 메커니즘은 있다고 가정하고 이 절의 나머지는 SOAP 메시지들과 처리 방법의 상세 설명에 집중한다.
SOAP 버전 1.2는 초기 SOAP 송신자와 궁극적인 SOAP 수신자 간에 XML infoset의 형태로 정의된 정보를 전달하는 간단한 메시지 프레임워크이다. 월씬 더 흥미있는 시나리오들은 이러한 두 노드들 간에 다수의 메시지 교환들을 포함한다. 가장 간단한 교환은 요청-응답 패턴이다. [SOAP 1.1]의 초기에는 RPC를 전달하는 수단으로써 이런 패턴의 사용을 강조했다, 하지만 모든 SOAP 요청-응답 교환들이 RPC 모델이 될 수 없거나 그럴 필요가 없다는 점을 주목하는 것이 중요하다. 후자(다수의 메시지 교환 모델)는, 미리 정의된 원격 호출 및 응답에 따라 메시지를 교환함으로써, 어떤 프로그램적인 행동을 모델링할 필요가 있을 때 사용한다.
양방향 "대화" 형식의 SOAP 메시지들로 교환된 XML 기반의 컨텐츠로써 모델링하는 것이 요청-응답 패턴을 적용한 것보다 훨씬 더 많은 사용 시나리오들을 다룰 수 있다, 여기서 시맨틱스들은 송신하고 수신하는 어플리케이션의 문제이다. Section 2.2.1은 여행 예약 어플리케이션과 여행 서비스 어플리케이션 간에 SOAP 메시지을 통해 교환된 XML 기반 컨텐츠의 경우를 다루고, section 2.2.2는 RPC를 모델로 하는 교환 예제를 설명한다.
예제 2는, 여행 요청 시나리오를 계속 사용해서, 예제 1에 있는 여행 서비스가 여행 요청 메시지의 응답으로 보낸 SOAP 메시지를 보여준다. 이 응답은 요청에 있는 특정 정보 - 즉 출발 도시의 공항 선택 - 를 상세히 하고자 한다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itineraryClarification
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>
<p:airportChoices>
JFK LGA EWR
</p:airportChoices>
</p:departing>
</p:departure>
<p:return>
<p:arriving>
<p:airportChoices>
JFK LGA EWR
</p:airportChoices>
</p:arriving>
</p:return>
</p:itineraryClarification>
</env:Body>
</env:Envelope>예제 1에 있는 메시지의 응답으로써 보내진 SOAP 메시지
이전에 설명한 것처럼, env:Body는 XML 네임스페이스 http://travelcompany.example.org/reservation/travel의 스키마 정의를 따르는 메시지의 주요 컨텐츠 - 이 예제에서는 여러 가지 선택 가능한 공항 리스트를 포함하는 - 를 포함한다. 이 예제에서, 예제 1의 헤더 블록들은 (변경된 서브-엘리먼트 값들을 가진) 응답으로 리턴된다. 이것은 SOAP 수준에서의 메시지 상관성(correlation)을 제공할 뿐만 아니라, 다른 어플리케이션 특화된 사용 용도를 가질 가능성이 많다.
예제 1과 2의 메시지 교환은, 어플리케이션에서 정의한 스키마를 따르는 XML 기반 컨텐츠를 SOAP 메시지를 통해서 교환한 경우이다. 다시 한번, 그런 메시지들이 전달되는 수단에 대한 논의는 section 4로 미룬다.
그런 교환들을 어떻게 다수의 양방향 "대화형" 메시지 교환 패턴으로 만들 수 있는 지는 알기 쉽다. 예제 3은 여행 예약 어플리케이션이 가용한 공항 리스트 중에서 하나를 선택해서 예제 2의 응답으로 보낸 SOAP 메시지를 보여준다. 같은 reference 서브-엘리먼트 값을 가지는 헤더 블록 reservation은 이 대화의 각 메시지와 동반하여, 어플리케이션 수준에서 교환된 메시지들을, 필요하다면, 상관시키는 방법을 제공한다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-29T13:36:50.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>LGA</p:departing>
</p:departure>
<p:return>
<p:arriving>EWR</p:arriving>
</p:return>
</p:itinerary>
</env:Body>
</env:Envelope>대화형 메시지 교환을 계속하는
예제 2의 메시지에 대한 응답
SOAP 버전 1.2의 설계 목표 중에 하나는 XML의 확장성과 유연성을 사용하여 RPC를 담는(encapsulate) 것이다. SOAP Part 2 section 4는 SOAP 메시지들로 전달되는 RPC 호출과 응답에 대한 공통 표현을 정의한다. 이 절은 여행 예약 시나리오를 계속 사용하여 RPC와 해당되는 응답이 SOAP 메시지를 사용하여 전달되는 방법을 설명한다.
그런 목적으로, 다음 예제는 신용 카드를 사용하여 여행에 대한 지불을 하는 것을 보여준다. (section 2.2.1에 설명된 대화형 교환이 확정된 여행 스케쥴임을 가정한다.) 여기서, 지불은 여행과 숙박이 둘다 확정되었을 때에 신용카드를 요구하는 방식으로 이루어진다고 가정한다. 여행 예약 어플리케이션이 신용 카드 정보를 제공하고 카드 청구를 위한 서로 다른 절차들을 성공적으로 완료하면 예약 코드가 리턴된다. 여행 예약 어플리케이션과 여행 서비스 어플리케이션 간의 이런 예약-그리고-청구 거래는 SOAP RPC로 모델링된다.
SOAP RPC를 호출하기 위해, 다음 정보가 필요하다:
- 수신 SOAP 노드의 주소
- 프로시저 또는 메쏘드 명
- 출력 파라미터 및 리턴값과 함께 프로시저 또는 메쏘드로 전달될 매개 변수들의 식별자들과 값들.
- 목표 자원이 호출을 처리하는 데 사용할 데이터 또는 제어 정보를 전달하는 것과 대조하여 RPC의 실제 목표인 웹 자원을 명시하는 데 사용되는 매개 변수의 명확한 분리
- 사용될 소위 "웹 메쏘드"의 명시과 함께, RPC를 전달하는 데 사용할 메시지 교환 패턴
- 선택사항으로, SOAP 헤더 블록의 일부로 전달될 데이터
그런 정보는 공식적인 Interface Definition Languages(IDL)을 포함하여 여러 가지 수단으로 표현될 수 있다. SOAP은 공식적으로 또는 비공식적으로든 IDL을 제공하지 않는다는 점을 주지해라. 또한 위의 정보는 일반적으로 SOAP RPC가 아닌 RPC들을 호출하는 데 필요한 정보와 아주 미묘하게 다르다.
위의 Item 1에 관해서, SOAP의 관점에서 RPC의 목표(target)를 포함하거나 지원하는 SOAP 노드가 있다. 그 노드는 궁극적인 SOAP 수신자의 역할을 채택한 SOAP 노드이다. Item 1에서 요구된 데로, 궁극적인 수신자는 지명된 프로시저 또는 메쏘드 목표를 URI를 찾음으로써 알아낼 수 있다. 목표 URI를 가용하게 만드는 방법은 하위 프로토콜 바인딩에 따라 다르다. 한 가지 가능성은 목표를 명시하는 URI가 SOAP 헤더 블록으로 전달되는 것이다. 다른 프로토콜 바인딩은, [SOAP Part2]에 정의된 SOAP HTTP 바인딩과 같은, SOAP 메시지 밖에서 URI를 전달하는 메커니즘을 제공한다. 일반적으로, 프로토콜 바인딩 규격의 특성 중에 하나는 어떻게 목표 URI가 바인딩의 일부로써 전달되는 지를 설명하는 것이다. Section 4.1은 HTTP로 바인딩한 표준 SOAP 프로토콜의 경우에 URI가 어떻게 전달되는 지에 대한 구체적인 예제를 제공한다.
위의 Item 4 와 Item 5는 SOAP을 채택한 RPC 어플리케이션이 월드 와이드 웹의 구조적인 원칙들과 부합하는 방식으로 동작할 수 있도록 하기 위해 필요하다. Section 4.1.3은 item 4와 5에 의해 제공된 정보를 어떻게 활용하는 지를 설명한다.
이 절의 나머지에서는, 예제 4에서 볼 수 있는 것처럼 SOAP 메시지로 전달되는 RPC는 적합하게 목표를 지정하고 획득한다고 가정한다. 이 절의 목적은 SOAP 메시지 내에 전달되는 RPC 요청들과 응답들의 문법적인 특징들을 조명하는 것이다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true" >5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard xmlns:o="http://mycompany.example.com/financial">
<n:name xmlns:n="http://mycompany.example.com/employees">
Ake Jogvan Oyvind
</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>필수 헤더와 두 개의 입력(즉 "in") 파라미터들을 가진 SOAP RPC 요청
RPC 자체는 env:Body 엘리먼트의 차일드로써 전달되며 프로시저 또는 메쏘드의 이름 - 이 경우에는 chargeReservation - 을 갖는 struct로써 모델링된다. (struct는 일반적인 프로그래밍 언어에 있는 구조체 또는 레코드 형식을 모델로 하는, [SOAP Part2]에서 정의한 SOAP 데이터 모델의 개념이다.) 예제에서 RPC의 설계는 두 가지 입력 파라미터, 예약 code에 의해 명시된 여행의 reservation과 creditCard 정보를 받는다. 후자는 또한 카드 소유자 name, 카드 number 및 expiration 날짜 등 세 가지 엘리먼트를 가지는 struct이다.
이 예제에서 http://www.w3.org/2003/05/soap-encoding 값을 가지는 env:encodingStyle 속성은, chargeReservation 구조의 컨텐츠가 SOAP 인코딩 규칙 - 즉 SOAP Part 2 section 3에 정의된 규칙들 - 에 따라 직열화되었다는 것을 의미한다 SOAP이 이런 특정 인코딩 스킴을 지정할 때 조차도, 그것의 사용은 선택사항이고 명백히 다른 인코딩 스킴들이 SOAP 메시지 내에 어플리케이션별 데이터로 사용될 수 있다. 이런 목적에서 헤더 블록과 body 서브 엘리먼트를 한정하는(qualify) env:encodingStyle 속성을 제공한다. 이 속성 값의 선택은 어플리케이션이 결정할 것이고 호출자와 호출된 자의 상호 작용 가능성은 "논외"로 남겨두었다고 가정한다. Section 5.2는 또 다른 인코딩 스킴을 사용하는 예제를 보여준다.
위의 Item 6에서 언급된 바대로, RPC들은 분산된 환경에서 호출을 처리하는 데 중요할 수 있지만, 공식적인 프로시저 또는 메쏘드 기술 부분이 아닌 부가 정보를 전달할 필요가 있을 수 있다. (그러나, 그런 부가적인 정황(contextual) 정보를 제공하는 것은 RPC들에 국한된 것은 아니고 분산된 어플리케이션의 처리에 일반적으로 필요한 것이다.) 이 예제에서, RPC는 몇 가지 동작들을 포함하는 트랜젝션으로 취급되는 데, 이 동작들이 모두 완료되어야 성공적으로 리턴된다. 예제 4는 궁극적인 수신자를 향하는 헤더 블록 (env:role 속성의 부재가 의미하는) transaction이 그런 정보를 전달하는 데 어떻게 사용되는 지를 보여준다. (값 "5"는 어플리케이션이 설정한, 어플리케이션에 의미가 있는 어떤 거래 식별자이다. 이 헤더의 어플리케이션별 의미의 더 이상의 상세는, SOAP RPC의 문법을 논할 때 일반적인 것이 아니므로, 여기서 제공되지 않는다.)
과금 예제에서 RPC가, 두개의 출력 파라미터들(하나는 예약에 대한 참조 코드이고 다른 것은 예약의 상세를 볼 수 있는 URL)이 있다는 것을 명시하는 처리 절차 명세을 포함하도록 설계되었다고 가정하자. RPC 응답은 SOAP 메시지의 env:Body 엘리먼트로 리턴되는 데, 해당 엘리먼트는 프로시저 명이 chargeReservation이고, 관행상 단어 "Response"를 덧붙인 struct의 형태이다. 응답에 포함된 두 가지 출력 파라미터들은 해당 예약을 명시하는 문자와 숫자를 포함하는 code와 예약을 조회하는 URI 형태의 위치인 viewAt이다.
이런 것이 예제 5a에서 설명된다, 여기서 헤더는 다시 이 RPC가 어떤 트랜젝션 내에서 수행되는 지를 명시한다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservationResponse
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:code>FT35ZBQ</m:code>
<m:viewAt>
http://travelcompany.example.org/reservations?code=FT35ZBQ
</m:viewAt>
</m:chargeReservationResponse>
</env:Body>
</env:Envelope>예제 4의 호출에 대한, 두 개의 출력 (즉 "out") 파라미터를 가지는 RPC 응답
RPC들은 종종 특정 출력 파라미터를 구별하기 위한 소위 "return"값으로 불리는 명세(description)들을 가진다. SOAP RPC 관행은 프로시저를 기술할 때, 이런 "return"값을 다른 출력 파라미터들과 구별하는 방법을 제공한다. 이것을 보여주기 위해, 과금 예제를 예제 5a와 거의 같은 RPC 명세(description)를 가지도록 수정한다, 즉 두 개의 "out" 파라미터들을 가지지만, 부가적으로 "confirmed"와 "pending" 값을 가질 수 있는 목록(enumeration)인 "return" 값을 또한 가진다. 이런 명세(description)를 따르는 RPC 응답이 예제 5b에 있다, 여기서도 전에 처럼 SOAP 헤더는 RPC가 어떤 트랜젝션 내에서 수행되는 지를 명시한다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservationResponse
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:rpc="http://www.w3.org/2003/05/soap-rpc"
xmlns:m="http://travelcompany.example.org/">
<rpc:result>m:status</rpc:result>
<m:status>confirmed</m:status>
<m:code>FT35ZBQ</m:code>
<m:viewAt>
http://travelcompany.example.org/reservations?code=FT35ZBQ
</m:viewAt>
</m:chargeReservationResponse>
</env:Body>
</env:Envelope>예제 4의 호출에 대해 "return" 값과 두 개의 "out" 파라미터들을 가지는 RPC 응답
예제 5b에서 rpc:result 엘리먼트가 리턴 값을 명시하는 데, m:status struct내에 다른 엘리먼트의 (xs:QName 형식의) XML Qualified Name을 포함한다. 차례로 이것은 실제 리턴 값 "confirmed"를 포함한다. 이렇게 하는 것은 리턴 값이 엄격하게 어떤 스키마를 따르도록 한다. 만약 예제 5a의 경우에서 처럼, rpc:result 엘리먼트가 없다면, 리턴 값이 존재하지 않거나 void 형식이 된다.
RPC 호출과 응답을 어떤 수단으로 전달할 것인가는 원칙적으로 SOAP을 RPC에 사용하는 것과는 무관하고, SOAP 요청-응답 메시지 교환 패턴을 지원하는 프로토콜 바인딩에 의해 결정된다. 이런 메시지 교환 패턴을 지원하는 프로토콜 바인딩은 요청와 응답 간의 관계를 제공할 수 있다. 물론 RPC 기반의 어플리케이션 설계자는 SOAP 헤더에 호출 및 응답과 관련된 correlation ID를 넣을 수 있다. 어떤 경우든 어플리케이션 설계자는 SOAP RPC들을 전달하는 데 선택된 특정 프로토콜들의 모든 특성을 - 대기(latency), 동시성(synchrony) 등과 같은 - 알아야 한다.
SOAP Part 2 section 7에 표준화된, 하위 전송 프로토콜로써 HTTP를 사용하는 일반적인 경우에, RPC 호출은 자연히 HTTP 요청으로 연결되고 RPC 응답은 HTTP 응답으로 연결된다. Section 4.1는 HTTP 바인딩을 사용해서 RPC들을 전달하는 예제를 제공한다.
그러나, RPC에 대한 SOAP의 예제가 대부분 HTTP 프로토콜 바인딩을 사용함에도 불구하고 HTTP 만으로 제한되지는 않는다는 점을 명심하는 것이 중요하다.
SOAP은 메시지 처리 과정에서 일어난 장애 상황을 다루는 모델을 제공한다. SOAP은 장애를 야기한 조건과, 그 장애를 해당 메시지의 생성자 또는 다른 노드로 알리는 기능을 구별한다. 장애를 알리는 기능은 사용된 메시지 전송 메커니즘에 따라 다르다, 그리고 어떻게 장애를 알리는 지는 SOAP 하위 프로토콜로의 바인딩 규격으로 정의된다. 이 절의 나머지는, 받은 메시지를 처리하는 동안 발생한 장애를 알리는 전송 메커니즘은 있다고 가정하고 SOAP 장애 메시지의 구조에 집중한다.
SOAP env:Body 엘리먼트는 그런 장애 정보가 있는 곳에서 다른 역할을 가진다. SOAP 장애 모델 ( SOAP Part 1, section 2.6 참조)은 모든 SOAP 관련 그리고 어플리케이션 관련 장애가 env:Body 엘리먼트 내에 있는 하나의 엘리먼트, env:Fault, 를 사용해서 보고되도록 했다. env:Fault 엘리먼트는 두 개의 필수 서브 엘리먼트, env:Code 와 env:Reason 그리고 선택적으로 env:Detail 서브-엘리먼트로 어플리케이션별 정보를 표현한다. 또 다른 선택 서브-엘리먼트, env:Node는 URI 형식으로 장애를 발생시킨 SOAP 노드를 명시한다, 없으면 장애가 메시지의 궁극적인 수신자로부터 발생된 것임을 의미한다. 또 다른 서브-엘리먼트 env:Role 은 장애를 발생시킨 노드의 역할을 명시한다.
env:Fault의 env:Code 서브-엘리먼트는 그 자체로 필수 env:Value 서브-엘리먼트 - 컨텐츠는 SOAP 규격에 정의됨 ( SOAP Part 1 section 5.4.6참조) - 와 env:Subcode 선택 서브-엘리먼트로 구성된다.
예제 6a는 예제 4에 RPC 요청의 응답으로 리턴된, RPC를 처리하는 데 실패했음을 나타내는 SOAP 메시지를 보여준다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:rpc='http://www.w3.org/2003/05/soap-rpc'>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">Processing error</env:Text>
<env:Text xml:lang="cs">Chyba zpracovani</env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails
xmlns:e="http://travelcompany.example.org/faults">
<e:message>Name does not match card number</e:message>
<e:errorcode>999</e:errorcode>
</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>예제 4의 RPC를 처리하면서 발생한 장애를 명시하는 간단한 SOAP 메시지
예제 6a에서 최고수준 env:Value는 env:Sender 장애 - 이것은 메시지에 문법적 에러 또는 부적절한 정보가 있음을 의미한다 - 임을 명시하기 위해 표준화된 (xs:QName 형식의) XML Qualified Name을 사용한다. (송신자는 env:Sender 장애를 받으면, 유사한 메시지를 다시 받기 전에 수정작업을 해야 한다) env:Subcode 엘리먼트는 선택사항이고, 있다면, 이 예제에서 처럼 상위 값(value)을 더 상세히 한다. 예제 6a에서 env:Subcode는 SOAP Part 2 section 4.4에 정의된 RPC 특화된 장애, rpc:BadArguments, 가 요청 처리 실패의 원인이었음을 나타낸다.
env:Subcode 엘리먼트의 구조는 어플리케이션 지정 코드들을 전달할 수 있도록 계층적이다, 즉 각 차일드 env:Subcode 엘리먼트는 필수 env:Value 와 선택 env:Subcode 서브-엘리먼트를 가진다. env:Code 엘리먼트의 계층적 구조는 여러 가지 수준의 장애 코드들을 전달하기 위한 일관된(uniform) 메커니즘을 허용한다. 최상위 env:Value 는 SOAP 버전 1.2 규격에 정의된 기본 장애( SOAP Part 1 section 5.4.6 참조)이며 모든 SOAP 노드들이 이해해야 한다. 내포된 env:Value들은 어플리케이션 마다 다르고 어플리케이션 측면에서 기본 장애의 상세 설명을 나타낸다. 이런 값 중 어떤 것은, RPC코드가 SOAP 1.2 ( SOAP Part 2 section 4.4 참조) 또는 하위(encapsulation) 프로토콜로 SOAP을 사용하는 다른 표준에서 표준화된 것처럼, 잘 표준화되었을 수 있다. 그런 어플리케이션별 subcode 값들을 정의하는 데 있어서 유일한 조건은 그들이 SOAP env 네임스페이스 - SOAP 장애들에 대한 메인 분류를 정의하는 - 와 다른 네임스페이스를 사용해서 지정되어야 한다는 것이다. SOAP을 처리하는 데 있어서, 어플리케이션이 모든 수준의 subcode 값들을 이해할 필요는 없다, 심지어 어떤 수준이냐에 따라 볼 필요도 없다.
env:Reason 서브-엘리먼트는 알고리즘 처리를 위한 것이 아니고 오히려 인간의 이해를 돕기 위함이다; 그래서, 이것이 필수 항목임에도 불구하고 선택된 값을 이해할 필요는 없다. 따라서 필요한 모든 것은 장애 상황을 합리적으로 정확하게 묘사하는 것이다. 각각이 서로 다른 xml:lang 속성을 가진 다수의 env:Text 서브-엘리먼트들을 가져야 한다, 이것은 어플리케이션이 장애 원인을 여러 가지 언어로 표현할 수 있도록 한다. (어플리케이션들은 SOAP 헤더를 사용하는 메커니즘을 통해 장애 내용의 언어를 협상할 수 있다; 하지만 이것은 SOAP 규격의 범위는 아니다.)
예제 6a에서
env:Fault내에
env:Node 서브-엘리먼트의 부재는 장애 메시지가 RPC 호출의 궁극적인 수신자로부터 생성된 것이다라는 것을 의미한다. 예제에서 보는 것처럼
env:Detail의 컨텐츠는 어플리케이션과 관련된 것이다.
SOAP 메시지를 처리하는 동안, 필수 헤더 엘리먼트를 해석할 수 없거나 포함된 정보를 처리할 수 없는 경우 장애가 발생한다. 헤더 블록을 처리할 때 에러들 또한 env:Body내에 env:Fault 엘리먼트를 사용해서 통보되는 데, 문법 위반 헤더 블록임을 명시하는 env:NotUnderstood 헤더 블록을 동반한다.
예제 6b는 t:transaction 헤더 블록을 처리하는 데 실패했다는 것을 알리는 예제 4의 RPC에 대한 응답의 예제이다. env:Body에 env:MustUnderstand 장애 코드의 존재와 특정 헤더 블록 env:NotUnderstood에 (정의되지 않은) 속성인 qname을 사용해서 이해할 수 없는 헤더를 명시한 것을 주지해라.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope>
<env:Header>
<env:NotUnderstood qname="t:transaction"
xmlns:t="http://thirdparty.example.org/transaction"/>
</env:Header>
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:MustUnderstand</env:Value>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">Header not understood</env:Text>
<env:Text xml:lang="fr">En-t?e non compris</env:Text>
</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>예제 4에 헤더 블록을 처리하다가 발생한 장애를 명시하는 예제 SOAP 메시지
만약 이해할 수 없는 몇 가지 필수 헤더 블록들이 있다면, 각각을 일련의 env:NotUnderstood 헤더 블록들에 qname으로 명시할 수 있다.
SOAP 메시지의 여러 가지 문법적인 특징들과 몇몇 기본 메시지 교환 패턴을 만들면서, 이 절은 SOAP 처리 모델의 일반적 개관을 제공한다. ( SOAP Part 1, section 2에 정의된) SOAP 처리 모델은 SOAP 노드가 SOAP 메시지를 받아서 처리하는 과정들을 설명한다.
예제 7a는 (간결함을 위해 컨텐츠는 생략된 채로) 몇 가지 헤더 블록들을 가지는 SOAP 메시지를 보여준다. 이 절의 나머지에서는 처리 모델의 여러 가지 특징들을 설명하기 위해 이 예제의 변형들을 사용할 것이다.
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock xmlns:p="http://example.com"
env:role="http://example.com/Log">
...
...
</p:oneBlock>
<q:anotherBlock xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
...
...
</q:anotherBlock>
<r:aThirdBlock xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body >
...
...
</env:Body>
</env:Envelope>다양한 헤더 블록들을 보여주는 SOAP 메시지
SOAP 처리 모델은 SOAP 노드가 SOAP 메시지를 받아서 처리하는 과정들을 설명한다. 노드가 SOAP 관련 메시지의 부분들을, 즉 네임스페이스가 SOAP "env"인 엘리먼트들, 처리할 때 요구사항이 있다. 그런 엘리먼트들은 envelope 그 자체, 헤더 엘리먼트 그리고 body 엘리먼트이다. 첫 단계는 물론 SOAP 메시지가 문법적으로 맞는 지를 전반적으로 체크하는 것이다. 즉, SOAP 메시지는, SOAP Part 1, section 5.에 정의된 XML 구조물의 - 처리 명령들과 문서 양식 정의(Document Type Definition)들 - 사용에 대한 제약사항들을 가정하는 SOAP XML infoset을 사용한다.
메시지를 처리할 때 SOAP 노드에 가정된 role에 따라 헤더 블록들과 body의 처리는 달라진다. SOAP은 (선택사항으로) env:role 속성을 - 문법적으로는 xs:anyURI - 정의한다. 이 속성은 헤더 블록에 나타날 수 있으며, 해당 블록의 목적 노드가 맡아야 할 역할을 명시한다. 어떤 SOAP 노드가 URI로 명시된 역할에 해당하는 경우 해당 헤더 블록을 처리해야 한다. SOAP 노드에 어떻게 특정 역할을 부여하는 지는 SOAP 규격의 부분이 아니다.
세 가지 표준 역할들이 정의된다 ( SOAP Part 1, section 2.2 참조),
- "http://www.w3.org/2003/05/soap-envelope/role/none" (이후로 간략히 "none")
- "http://www.w3.org/2003/05/soap-envelope/role/next" (이후로 간략히 "next"), and
- "http://www.w3.org/2003/05/soap-envelope/role/ultimateReceiver" (이후로 간략히 "ultimateReceiver").
예제 7a에서 헤더 블록 oneBlock은 어플리케이션 정의 역할이 URI로 http://example.com/Log인 SOAP 노드를 향한다. 설명을 목적으로, 이런 역할에 해당되는 모든 SOAP 노드는 전체 메시지를 로깅할 것이 요구된다고 가정하자.
"next" env:role 속성은 모든 SOAP 노드에 해당되는 역할이기 때문에, "next" env:role 속성을 가진 헤더 블록을 수신한 모든 SOAP 노드들은 해당 블록의 엘리먼트의 내용을 처리할 수 있어야 한다. 따라서 이 속성을 가진 헤더 블록은 메시지 경로 상에 이어지는 SOAP 노드에 의해 검사되고 처리될 것이다, 물론 그런 헤더가 메시지 경로 상에 이전에 있는 어떤 노드의 처리 과정에서 제거되지 않는다는 가정하에.
예제 7a에서, 헤더 블록 anotherBlock은 메시지 경로 상 다음 노드를 향한다. 어플리케이션에서 정의한 "http://example.com/Log"의 역할을 하는 노드가 이 SOAP 메시지를 받은 경우에도 (SOAP에서 정의한) "next" 역할로써 이 블록을 처리해야 한다. 메시지의 궁극적인 수신 노드들 또한 분명히 (암묵적으로) 메시지 경로 상에 다음 노드에 해당되기 때문에 해당 블록을 처리해야 한다.
예제 7a에 세번째 헤더 블록, aThirdBlock에는 env:role 속성이 없다. 이것은 "ultimateReceiver" 역할을 하는 SOAP 노드를 향한 것이다. 특별한 SOAP 메시지의 궁극적인 수신자 역할을 하는 SOAP 노드가 "ultimateReceiver" 역할을 (명시적으로 선언되거나 env:role 속성이 헤더 블록에 없으면 암묵적으로 선언되는) 한다. aThirdBlock 헤더 블록에 env:role 속성의 부재는 이 헤더 엘리먼트가 "ultimateReceiver" 역할을 하는 SOAP 노드를 향한다는 것을 의미한다.
env:Body 엘리먼트는 env:role 속성을 가지지 않음을 주지해라. body 엘리먼트는 항상 "ultimateReceiver" 역할을 가정하는 SOAP 노드를 향한다. 그런 관점에서 body 엘리먼트는 궁극적인 수신자를 향하는 헤더 블록과 같다, 하지만 궁극적인 수신자가 아닌 역할을 가정하는 SOAP 노드들이 해당 블록을 건너뛸 수 있도록 하기 위해 구별되어 왔다. SOAP은 모든 서브-엘리먼트들이 한정된(qualify) XML 네임스페이스가 되어야 한다는 것을 제외하고는, env:Body 엘리먼트에 대한 구조를 규정하지 않는다. 예제 1에서 처럼 어떤 어플리케이션은 env:Body의 서브-엘리먼트들을 블록들로 만들 수도 있다, 하지만 이것은 SOAP 처리 모델과는 상관없는 것이다.
env:Body 엘리먼트의 또 다른 역할은, SOAP-지정 장애들, 즉 SOAP 메시지의 엘리먼트들을 처리하는 데 있어서의 장애에 대한 정보를 포함하는 컨테이너로써의 역할인 데, section 2.3에서 이미 설명되었다.
헤더 엘리먼트가 "none"값을 가진 표준화된 env:role 속성을 가진다면, 컨텐츠를 처리해야 하는 SOAP 노드는 없음을 의미하는 데, 특정 SOAP 노드를 향하는 다른 헤더 엘리먼트가 해당 컨텐츠의 데이터를 참조하는 경우에는 해당 컨텐츠를 검사하는 것이 필요할 수 있다.
env:role 속성이 빈 값이라면, 즉 env:role="", role을 명시하는 상대 URI가 문제의 SOAP 메시지에 대한 기저(base) URI로 해석된다는 것을 의미한다. SOAP 버전 1.2는 SOAP 메시지에 대한 기저 URI를 정의하지 않는다, 하지만 기저 URI를 구할 때 [XMLBase]에 정의된 메커니즘에 의존한다, 이 메커니즘은 모든 상대 URI들을 절대 URI로 만드는 데 사용될 수 있다. 그런 메커니즘 중 하나는 프로토콜 바인딩이, 가능하다면 전송을 위해 SOAP 메시지를 포함하는 하위 프로토콜을 참조해서, 기저 URI를 정의하도록 하는 것이다. (사실상, SOAP 메시지가 HTTP를 사용해서 전달될 때, SOAP Part 2 section 7.1.2는 기저 URI를 HTTP 요청의 요청-URI 또는 HTTP Content-Location 헤더의 값으로 정의한다.)
다음 표는 여러 가지 SOAP 노드들에 가정된 표준화된 역할들을 요약한다. ("Yes"와 "No"는 각각 대응하는 노드가 명명된 역할을 하거나 하지 않는다는 것을 의미한다.)
| Role |
absent |
"none" |
"next" |
"ultimateReceiver" |
| Node |
|
|
|
|
| initial sender |
not applicable |
not applicable |
not applicable |
not applicable |
| intermediary |
no |
no |
yes |
no |
| ultimate receiver |
yes |
no |
yes |
yes |
예제 7b는 이전 예제의 헤더 블록에 다른 (선택) 속성 env:mustUnderstand 을 덧붙인다.
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock xmlns:p="http://example.com"
env:role="http://example.com/Log"
env:mustUnderstand="true">
...
...
</p:oneBlock>
<q:anotherBlock xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next">
...
...
</q:anotherBlock>
<r:aThirdBlock xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body >
...
...
</env:Body>
</env:Envelope>다양한 헤더 블록들(그 중 하나는 필수적으로 처리해야 하는)을 보여주는 SOAP 메시지
SOAP 노드는 env:role 속성, 그 외 속성, env:mustUnderstand를 사용해서 자신에게로 향하는 헤더 블록들을 인식한 후에 취해야할 다음 동작들을 결정한다. SOAP 노드들이 어플리케이션의 전체 목적에 중요한 헤더 블록들을 무시하지 않도록 하기 위해, SOAP 헤더 블록들은 추가 선택 속성, env:mustUnderstand, 을 제공한다. 이 속성이 "true"라면 해당되는 SOAP 노드는 그 블록의 규격에 따라 해당 블록을 처리 해야 한다는 것을 의미한다. 그런 블록은 일반적으로 필수 헤더 블록으로써 언급된다. 사실상, SOAP 메시지의 처리는 심지어 노드가 자신에게로 향하는 모든 필수 헤더 블록들을 인식하고 이해할 때까지 출발하지 않아야 한다. 헤더를 이해하는 것은 노드가 그 블록의 규격에서 언급된 모든 것을 수행할 준비가 되어야 함을 의미한다.(헤더 블록들의 규격은 SOAP 규격의 일부가 아님을 명심해라.)
예제 7b에서 헤더 블록 oneBlock는 값이 "true"로 설정된 env:mustUnderstand를 포함한다, 이것은 SOAP 노드가 "http://example.com/Log"로 명시된 역할을 한다면 이 블록을 처리해야 한다는 것을 의미한다. 다른 두 헤더 블록들은 그렇게 표시되지 않는다, 이것은 이 블록들을 수신하는 SOAP 노드들은 그것들을 처리할 필요가 없음을 의미한다. (이 블록들에 대한 규격이 아마 이것을 허용할 것이다.)
값이 "true"인 env:mustUnderstand는 SOAP 노드가, 해당 헤더 규정에 언급된 의미에 따라 헤더를 처리하거나, SOAP 장애로 응답해야 한다는 것을 의미한다. 헤더를 적당히 처리하는 것은 생성된 SOAP 메시지로부터 헤더를 제거하는 것, 헤더에 같은 혹은 다른 값을 다시 넣는 것, 또는 새로운 헤더를 넣는 것을 포함할 것이다. 필수 헤더를 처리하지 못할 경우, SOAP 메시지에 대한 모든 처리를 중단하고 SOAP 장애를 생성해야 한다. 메시지는 더 이상 전달되지 않는다.
env:Body 엘리먼트는 env:mustUnderstand 속성을 가지지 않지만 궁극적인 수신자는 이 엘리먼트를 처리해야 한다. 예제 7b에서 메시지의 궁극적인 수신자는 - "ultimateReceiver" 역할을 수행하는 SOAP 노드 - env:Body를 처리해야 하고 헤더 블록 aThirdBlock은 처리할 수도 있다. 그것은 또한 헤더 블록 anotherBlock을 처리할 수도 있다, 왜냐하면 ("next" 의 역할로 인해) 이 블록이 궁극적인 수신자를 향할 수 있기 때문이다. 하지만 블록들을 처리하는 규정이 처리하는 것을 요구하지 않는다면 필수는 아니다. (anotherBlock에 대한 규정이 다음 수신자가 처리할 것을 요구한다면, env:mustUnderstand="true"로 표시해야 할 것이다.)
SOAP 노드가 SOAP 메시지를 처리할 때 맡을 역할은 많은 요소들에 의해 결정될 수 있다. 역할은 미리(priori) 알려지거나, 어떤 다른 외부 수단에 의해 알려지거나, 또는 메시지를 처리하기 전에 자신이 수행해야 할 역할을 결정하기 위해 받은 메시지의 모든 부분을 검사할 수도 있다. 재미있는 경우는 SOAP 노드가 메시지를 처리하는 과정에서 자신이 또 다른 역할을 맡아야 할 필요가 있다고 결정했을 때이다. 이런 결정이 만들어진 때와 무관하게, 그런 역할은 외부적으로는 처리 모델에 있었던 것처럼 나타나야 한다. 즉, 그 역할이 메시지를 처리하기 시작할 때 알려진 것처럼 처리되어야 한다. 특히, 외부 존재(appearance)는 메시지 처리가 시작되기 전에 그런 추가된 역할을 가진 모든 헤더의 env:mustUnderstand 확인이 수행되어야 한다. 또한, 만약 SOAP 노드가 그런 추가 역할이 있다면, 그런 역할들에 대한 규정이 요구하는 모든 것을 수행할 준비가 되어 있음을 확인해야 한다.
다음 표는 (env:role 속성을 통하여) 적합하게 지정된 노드의 입장에서 env:mustUnderstand속성에 따라 헤더 블록에 대한 처리가 어떻게 달라지는 지를 정리한 것이다.
| Node |
intermediary |
ultimate receiver |
| mustUnderstand |
|
|
| "true" |
must process |
must process |
| "false" |
may process |
may process |
| absent |
may process |
may process |
SOAP 노드가 메시지를 처리하는 데 실패한다면, 노드는 SOAP 메시지 처리의 결과로써 하나의 SOAP 장애를 생성하거나 어플리케이션에 따라 다른 SOAP 노드들을 위한 추가 SOAP 메시지들을 생성할 것이다. SOAP Part 1 section 5.4는 SOAP 처리 모델이 정의한 조건에 따라 생성된 장애 메시지의 구조를 설명한다. section 2.3에서 설명된 것처럼, SOAP 장애는 env:Fault로 명명된 표준 env:Body 서브-엘리먼트를 가진 SOAP 메시지이다.
SOAP은 장애를 생성하는 것과, 장애가 메시지의 생성자 또는 이런 정보가 유용한 다른 적당한 노드에게로 돌아가는 것을 확신하는 것을 구별한다. 그러나, 생성된 장애가 적합하게 전달될 수 있는 지는, SOAP 메시지 교환을 위해 선택된 하위 프로토콜 바인딩에 따라 다르다. 규격은 일방향 메시지의 전달 동안에 발생된 장애들에 대한 처리는 정의하지 않는다. 단지 표준 하위 프로토콜 바인딩만, 즉 SOAP HTTP 바인딩, 들어오는 SOAP 메시지에 장애를 보고하는 수단으로써 HTTP 응답를 제공한다. (SOAP 프로토콜 바인딩들에 대한 보다 상세한 정보는 Section 4 참조.)
SOAP 버전 1.2는 헤더 블록들에 대한 또 다른 추가 속성,env:relay (xs:boolean 형식), 을 정의한다. 이 속성은 SOAP 중간 서버가 자신에게로 지정된 헤더 블록을 처리하지 않은 경우에도 계속 전달해야 하는 지를 나타낸다.
헤더 블록이 처리된다면 SOAP 처리 규칙 (SOAP Part 1 section 2.7.2 참조)은 outbound 메시지로 부터 그것을 제거할 것을 요구한다. (그러나, 다른 헤더 블록들을 처리하는 과정에서 전달되는 메시지에 그 헤더 블록을 유지하기로 결정한다면, 변경되지 않거나 변경된 컨텐츠와 함께 삽입될 수도 있다) SOAP 중간 서버의 역할로 지정된, 처리 되지 않은 헤더 블록에 대한 기본적인 처리는 메시지를 전달하기 전에 해당 헤더 블록을 제거하는 것이다.
기본 처리를 이렇게 선택한 이유는 SOAP 중간 서버가 자신의 역할로 지정된 헤더 블록을 처리한 후에 어떻게 해야 하는 지에 대한 어떤 가정도 하지 않도록 함으로써 안전성에 치중하기 위함이다, 그리고 특히 헤더 블록을 이해할 수 없어서 헤더 블록을 처리하지 않기로 결정하는 경우에 어떤 부가적인 특징을 표현하기 위함이다(그렇지 않으면 추가 특징을 표현한 헤더 블록을 이해할 수 없다는 이유로 떼어낼 수 있으므로). 이것은 어떤 헤더 블록은 노드마다의 특징들을 표현하기 때문이다, 그리고 모르고서 그것을 단대단으로 전달한다는 것도 말이 안되므로 처리되지 않은 헤더 블록들은 전달되기 전에 제거되는 것이 안전하다고 생각된다.
그러나, 어플리케이션 설계자가 SOAP 메시지 경로에서 나타날 수 있는 모든 중간 서버를 대상으로 하는, SOAP 헤더 블록을 통해 명시된 새로운 특징을 소개하고자 하는 경우가 있다. 그런 헤더 블록은 그것을 "이해하는" 중간 서버들은 사용하겠지만, 그렇지 않은 중간 서버들은 계속 무시하거나 전달할 것이다. 새로운 특징이 되려면, 이러한 헤더 블록을 처리하는 소프트웨어가 모든 SOAP 노드들에서는 아니지만 몇몇 노드들에서는 구현되어야 한다. 새로운 특징을 구현하지 않은 중간 서버들이 장애를 생성하지 않도록, 해당 헤더 블록을 env:mustUnderstand = "false"로 표시하는 것은 분명히 필요하다. 처리 모델의 기본 규칙을 피하기 위해, 헤더 블록을 값이 "true"인 추가 속성 env:relay로 표시하는 것은 중간 서버가 처리하지 않기로 결정한, 자신을 향하는 헤더 블록을 전달할 수 있도록 한다.
"true"로 설정된 env:relay 속성을 가지고 "next" 역할로 헤더 블록을 지정하는 것은 항상 각 중간 서버가 헤더를 검사할 기회를 가지도록 할 수 있다, 왜냐하면 "next" 역할의 예상 사용법 중에 하나가 SOAP 메시지 경로를 따라 유지되어야 하는 정보를 헤더 블록들이 전달하도록 하는 것이기 때문이다. 물론 어플리케이션 설계자는 항상 특정 역할을 정의해서 이 역할을 할 특정 중간 서버를 향하도록 할 수 있다. 그러므로, env:relay 속성이 어떤 역할과 함께 사용되어야 하는 지에 대한 제약은 없다, 물론 아무런 의미가 없는 "none"과 "ultimateReceiver" 역할은 제외하고.
예제 7c는 env:relay 속성의 사용을 보여준다.
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<p:oneBlock xmlns:p="http://example.com"
env:role="http://example.com/Log"
env:mustUnderstand="true">
...
...
</p:oneBlock>
<q:anotherBlock xmlns:q="http://example.com"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:relay="true">
...
...
</q:anotherBlock>
<r:aThirdBlock xmlns:r="http://example.com">
...
...
</r:aThirdBlock>
</env:Header>
<env:Body >
...
...
</env:Body>
</env:Envelope>처리되지 않아도, 전달되어야 하는 하나의 헤더 블록을 포함하여 다양한 헤더 블록을 보여주는 SOAP 메시지
메시지 경로에서 "next" 노드로 지정된 헤더 블록 q:anotherBlock는 추가 속성 env:relay="true"를 가진다. 이런 메시지를 수신한 SOAP 노드는 이해한다면 이 헤더 블록을 처리할 것이지만, 만약 그렇게 한다면 처리 규칙들은 이 헤더 블록을 전달하기 전에 제거할 것을 요구한다. 그러나, 만약 SOAP 노드가 이 헤더 블록을 처리하는 것이 필수가 아니기 때문에 무시하기로 결정한다면, env:mustUnderstand 속성의 존재에 의해 명시되는 것처럼, 전달되어야 한다.
p:oneBlock 헤더 블록의 처리는 필수이고 SOAP 처리 규칙들은 어떤 헤더 블록의 처리가 outbound 메시지에 그것을 남기도록 요구하지 않는 한 전달하지 않을 것을 요구한다. r:aThirdBlock 헤더 블록은 env:relay 속성을 가지지 않는다, 즉 값이 "false"인 env:relay를 가진 것과 같다. 따라서, 이 헤더는 처리되지 않는다면 전달되지 않는다.
SOAP 1.2 Part 1 Table 3은 주어진 역할을 가정한 SOAP 중간 서버가 처리되지 않은 헤더 블록들을 전달하는 것을 언제 허용할 것인 가를 결정하는 조건들을 요약한다.
SOAP 메시지들은 다른 어플리케이션 계층 프로토콜들을 포함해서 여러 가지 "하위" 프로토콜들을 사용해서 교환될 수 있다. SOAP 바인딩은 SOAP 메시지가 하위 프로토콜을 사용해서 어떻게 한 SOAP 노드로부터 다른 노드로 전달되는 지에 관한 규격이다. [SOAP Part1] 은 [XML Infoset]의 형태로 SOAP 메시지를 정의한다, 즉 env:Envelope로 불리는 추상적인 "문서"의 엘리먼트와 속성 정보 요소들의 용어로 ( SOAP Part 1, section 5 참조). 모든 SOAP env:Envelope infoset 표현은 프로토콜 바인딩을 통해서 구체화될 것이다, 프로토콜 바인딩은, infoset이 정보의 누락없이 infoset을 다시 만들 수 있도록 하면서 다음 SOAP 노드로 전달하기 위한 infoset의 직열화된 표현법을 제공한다. SOAP 메시지들의 전형적인 예와 이 입문서 에 모든 예제들에서, 직열화는 잘 정의된(well-formed) [XML 1.0] 문서이다. 그러나 다른 프로토콜 바인딩들 - 예를 들어 제한된 대역폭을 통한 두 개의 SOAP 노드들 간의 프로토콜 바인딩 - 은 같은 infoset의 압축된 직열화를 선택할 수도 있다. 다른 목적을 위해 선택된 다른 바인딩은 같은 infoset을 표현하는 암호화된 구조의 직열화를 제공할 수도 있다.
SOAP 메시지 경로 상의 인접한 SOAP 노들들 간의 SOAP infoset의 구체적인 표현(realization)을 제공하는 데 덧붙여, 프로토콜 바인딩은 SOAP 어플리케이션에 필요한 특징들을 지원하는 메커니즘을 제공한다. 특징은 바인딩에 의해 제공되는 어떤 기능의 규격이다. 특징 묘사는, 그것을 참조하는 모든 어플리케이션에게 같은 의미를 전달하기 위해, URI에 의해 명시된다. 예를 들어, 전형적인 사용 시나리오는 인접한 SOAP 노드들 간에 동시에 많은 요청-응답 교환들을 요구할 것인 데, 이런 경우 요구되는 특징은 요청와 응답를 연관시키는 능력이다. 다른 예제들은 "암호화된 채널" 특징 또는 "안정적인 전송 채널" 특징, 또는 특별한 SOAP 메시지 교환 패턴 특징을 포함한다.
SOAP 바인딩 규격 (SOAP Part 1 section 4 참조)은 다른 것들을 포함하여 제공하는 특징들을 설명한다. 어떤 특징들은 하위 프로토콜에 의해 자연스럽게 제공될 것이다. 만약 특징이 바인딩을 통해서 가용하지 않다면, 그것은 SOAP envelope 내에서 SOAP 헤더 블록들을 사용해서 구현될 것이다. SOAP 헤더 블록들을 사용하여 구현된 특징의 규격은 SOAP module이라고 부른다.
예를 들어, 만약 SOAP 메시지 교환들이 UDP와 같은 데이터그램 프로토콜을 통해 직접 전달되고 있다면, 분명히 메시지 연관 특징은 어플리케이션에서 직접이든 교환될 SOAP infoset들의 일부로써든 간에 제공되어야 할 것이다. 후자의 경우에, 메시지 연관 특징은 SOAP envelope 내에 바인딩에 적합한 방식의 표현을 가진다, 예를 들면, URI로 명시된 "요청-응답 상관" 모듈에 정의된 SOAP 헤더 블록으로써. 그러나, 만약 SOAP infoset들이 그 자체로 요청/응답인 하위 프로토콜을 사용하여 교환되고 있다면, 어플리케이션은 암묵적으로 바인딩에 의해 제공되는 이런 특징을 "상속"할 수 있으며 어플리케이션 또는 SOAP 수준에서의 추가적인 지원은 필요없다. (사실, SOAP의 HTTP 바인딩이 HTTP의 이러한 특징의 장점을 취한다.)
그러나, SOAP 메시지는 송신자와 궁극적인 수신자 사이에 여러 개의 hop들을 거칠 것이다, 여기서 각 hop은 서로 다른 프로토콜 바인딩을 사용할 수 있다. 달리 표현하면, 한 hop에서 프로토콜 바인딩에 의해 지원된 특징이 메시지 경로 상의 다른 hop에서는 지원되지 않을 수도 있다. SOAP 그 자체는 서로 다른 하위 프로토콜들에 의해 제공되는 특징들에 차이들을 감추기 위한 어떤 메커니즘도 제공하지 않는다. 그러나, 특정 어플리케이션에서 필요로 하지만 예상 메시지 경로 상에 하위 구조에서 가용하지 않은 특징은 SOAP 메시지 infoset의 일부분으로써, 즉 어떤 모듈에 정의된 SOAP 헤더 블록으로써, 전달됨으로써 보충될 수 있다.
따라서 어플리케이션 설계자들이 특정 어플리케이션 시멘틱스들을 완성하기 위해 풀어야할 몇 가지 이슈들이 있다, 여기에는 주어진 상황에서 사용 가능한 하위 프로토콜들이 가진 특징들을 어떻게 이용하는 지도 포함된다.SOAP Part 1 section 4.2는 SOAP 기반 어플리케이션들이 특정 어플리케이션 시멘틱스들을 완성하기 위해, 하위 프로토콜 바인딩에서 제공하는 특징들을 어떻게 선택해야 하는 지를 기술하는 것에 대한 프레임워크를 제공한다. 이 프레임워크는 SOAP 메시지들을 교환 용으로 상호 운용 가능한 프로토콜 바인딩을 만드는 방법에 대한 가이드라인들을 제공하는 것이 목적이다.
바인딩 규격은 다른 것들 중에서도 한 가지 특별한 특징, 즉 지원하는 메시지 교환 패턴,을 정의해야 한다. [SOAP Part2]는 두 가지 메시지 교환 패턴들을 정의한다, 즉 하나의 SOAP 메시지가 두 개의 인접한 SOAP 노드들 간에 교환되는 SOAP 요청-응답 메시지 교환 패턴, 그리고 non-SOAP 메시지 형식의 요청에 대한 응답으로 SOAP 메시지 형식의 응답를 전달하는 SOAP 응답 메시지 교환 패턴
[SOAP Part2]는 또한 어플리케이션 설계자에게 SOAP 웹 메쏘드 특징이라는 일반적인 특징을 제공한다, 이 특징은 "웹 메쏘드"를 - GET, POST, PUT, [HTTP 1.1] 규격에 추가된 DELETE 중 하나 - 선택하는 데 있어서 모든 결정권을 어플리케이션에게 부여한다. 이 특징은 SOAP을 사용하는 어플리케이션들이 월드 와이드 웹의 구조적인 원칙들과 호환되는 방식으로 동작할 수 있도록 하기 위해서 정의된다. (아주 간단하게, 웹의 단순함과 확장성은 URI를 통해서 웹에서 가용한 모든 리소스와 상호 작용할 수 있는 몇 가지 "일반적인" 방법들(GET, POST, PUT, DELETE)이 있다는 사실에 기인한다.) 원칙적으로는 모든 SOAP 하위 프로토콜 바인딩들에 가용함에도 불구하고 SOAP 웹 메쏘드 특징는 SOAP HTTP 바인딩에 의해 지원된다.
SOAP Part 2 section 7은 [SOAP Part1]의 바인딩 프레임워크를 사용하는 하나의 표준화된 프로토콜 바인딩을 정의한다, 즉 SOAP이 어떻게 하위 프로토콜로써 HTTP와 결합되어 사용되는 지를 정의한다. SOAP 버전 1.2는 요청-응답 메시지 교환 패턴과 POST를 SOAP 응답 메시지 교환 패턴은 GET과 결합하여 사용하도록 HTTP 바인딩의 사용을 제한한다. 향후 다른 규격들은 다른 웹 방법(즉, PUT, DELETE)을 사용하는 HTTP 또는 다른 전송들로의 SOAP 바인딩들을 정의할 수 있다.
다음 절은 SOAP에 대한 두 가지 하위 프로토콜 바인딩, [HTTP 1.1]과 전자우편,의 예제들을 보여준다. 다시 한번 강조하면 SOAP 1.2 메시지들에 대한 표준 바인딩은 [HTTP 1.1]이다. 전자우편을 SOAP에 대한 전송 메커니즘으로 보여주는 section 4.2에 예제들은 단지 SOAP 메시지들을 전송하는 데 다른 것을 선택할 수 있다는 것을 의도한다. W3C Note [SOAP 전자우편 바인딩]은 SOAP을 전자우편 전송, 특히 [RFC 2822]-기반 메시지 전송, 으로 바인딩하는 것을 실험적으로 보여줌으로써, [SOAP Part1]의 SOAP 프로토콜 바인딩 프레임워크의 응용 예를 제공한다.
HTTP는 잘 알려진 연결 모델과 메시지 교환 패턴을 가진다. 클라이언트는 서버를 URI를 통해 인식하고, 하위 TCP/IP 네트웍을 사용해서 서버에 연결하고, 같은 TCP 연결을 통해 HTTP 요청 메시지를 발행하고 HTTP 응답 메시지를 받는다. HTTP는 암묵적으로 요청 메시지와 응답 메시지를 연관시킨다; 따라서, 이 바인딩을 사용하는 어플리케이션은 HTTP 요청 메시지의 body로 보내진 SOAP 메시지와 HTTP 응답로 리턴된 SOAP 메시지 간에 상호 관계를 유추할 수 있다. 유사하게, HTTP는 다른 쪽의 서버를 URI, 요청-URI,를 통해서 명시한다, 이 URI는 또한 서버의 SOAP 노드를 명시하는 것으로도 동작할 수 있다.
HTTP는 초기 클라이언트와 요청-URI에 의해 명시된 원래(origin) 서버 사이에 다수의 중간 서버들을 허용한다. 그러나, HTTP 중간 서버들은 SOAP 중간 서버들과는 다르다는 것을 주지해라.
[SOAP Part2]에 HTTP 바인딩은 어플리케이션들이 소위 웹 메쏘드를 HTTP 메시지 교환에 사용하도록 하기 위해 SOAP 웹 메쏘드 특징으로 구성된다. 추가로, 이 바인딩은 HTTP를 통해 SOAP 메시지들을 교환하는 두 가지 방법을 어플리케이션에 제공하기 위해, 두 가지 메시지 교환 패턴을 사용하는 데, 1) HTTP 요청과 응답 메시지들의 body들로 SOAP 메시지들을 전달하는 HTTP POST 메쏘드의 사용, 그리고 2) HTTP 요청으로 HTTP GET 메쏘드를 사용하고, HTTP 응답의 body에 SOAP 메시지를 리턴하는 방법이 여기에 해당한다. 첫 번째 사용 패턴은 SOAP 요청-응답 메시지 교환 패턴으로 불리는 바인딩 특징의 HTTP 특화된 실례인 반면, 두번째는 SOAP 응답 메시지 교환 패턴으로 불리는 특징을 사용한다.
이런 두 가지 사용법들을 제공하는 목적은 월드 와이드 웹을 기반으로, 잘 만들어진 두 가지의 통신 패러다임들을 채택하기 위함이다. 첫 번째 유형의 통신은, HTTP 요청이 URI를 통해 지정한 자원의 상태를 생성하거나 수정하는 데 HTTP POST의 body 데이터를 사용하도록 한다. 두번째 유형의 통신은 상태를 변경하는 것 없이 자원의 내용을 얻기 위해 HTTP GET을 사용하도록 한다. 첫번째 경우, SOAP 측면에서 관심있는 부분은 HTTP POST 요청의 body가 SOAP 메시지라는 것인 데, 이 경우 SOAP 메시지는 POST 의미(semantics)를 준수하기 위한 어플리케이션에서의 처리 절차의 일부로써 처리되어야 한다. 두번째 경우에, 예상되는 전형적인 사용법은 요청한 자원이 HTML 또는 일반 XML 문서가 아니라 SOAP 메시지로 리턴되는 경우이다. 즉, 응답 메시지의 HTTP content type 헤더가 미디어 형식이 "application/soap+xml"으로 정의되는 경우이다. 아마, 웹 상의 자원을 SOAP 메시지의 형태로 만들어두고 가져가도록 하는 것이 최선이라고 생각하는 웹 상의 출판자들이 있을 것이다. 그러나, 그 자원들은 일반적으로 여러 가지로 표현할 수 있고, 원하는 또는 선호하는 표현법은, 요청하는 어플리케이션이 HTTP Accept 헤더를 사용하여 지정하도록 함을 주지해라.
SOAP HTTP 바인딩의 한 가지 부가적인 측면은 어플리케이션이 이 두 가지 메시지 교환 패턴들 중 어떤 것을 사용할 지를 어떻게 선택하는 가에 대한 질문이다.[SOAP Part2] 은 어플리케이션이 두 가지 메시지 교환 패턴들 중 하나를 사용하는 상황에 대한 안내를 제공한다. (이것은 안내이다 - 강한 것이지만 - IETF [RFC 2119]의 용어에서 정의된 용어로 표현하면, MUST로 명시되는 절대 요구사항보다는 SHOULD의 형태로 표현되는 것과 같은). HTTP GET 메쏘드를 사용하는 SOAP 응답 메시지 교환 패턴은 어플리케이션이 메시지 교환이 정보 획득을 목적으로 한다는 것이 확실할 떄 사용된다, 즉 정보 자원은 상호 통신 후에도 "변함없다". 그런 상호 통신들은 HTTP 규격에서 안전하고 변함없는으로써 표현된다. HTTP SOAP GET 사용법은 요청에 SOAP 메시지를 허용하지 않기 때문에, SOAP infoset(즉, SOAP 헤더 블록들) 내에 바인딩 관련 표현들에 의해서만 지원될 수 있는 outbound 통신 특성들을 필요로 하는 어플리케이션들은 분명히 이 메시지 교환 패턴을 사용할 수 없다. HTTP POST 바인딩은 모든 경우에 사용할 수 있음을 주지해라.
이어지는 세부 절에서는 이러한 두 가지 메시지 교환 패턴들을 HTTP 바인딩에 사용하는 예제들을 제공한다.
SOAP 응답 메시지 교환 패턴과 함께 HTTP 바인딩을 사용하는 것은 HTTP GET 메쏘드에 국한된다. 이것은 요청하는 SOAP 노드로부터의 HTTP GET 요청에 대한 응답은 HTTP 응답에 SOAP 메시지임을 의미한다.
예제 8a는 여행자 어플리케이션에서 여행자의 일정을 보여줄 URI http://travelcompany.example.org/reservations?code=FT35ZBQ로 향하는 HTTP GET을 보여준다. (이 URL이 어떻게 가용해졌는 지는 예제 5a에서 볼 수 있다.)
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html;q=0.5, application/soap+xml
HTTP GET 요청
HTTP Accept 헤더는 요청된 자원이 어떤 표현 형식으로 리턴되기를 원하는 가를 지정하는 데 사용된다. 이 예제에서는 브라우저 클라이언트가 인간에게 보여주기 위해 사용하는 "text/html" 미디어 형식보다는 기계(machine) 클라이언트에서의 사용을 위해 "application/soap+xml" 미디어 형식이다.
예제 8b는 예제 8a의 GET에 대한 HTTP 응답을 보여준다. HTTP 응답의 body는 여행의 상세내역을 보여주는 SOAP 메시지를 포함한다. SOAP 메시지의 컨텐츠에 대한 논의는 section 5.2까지 미룬다, HTTP GET 바인딩 사용법을 이해하는 이 시점에서는 관련이 없기 때문이다.
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://travelcompany.example.org/vocab#"
env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<x:ReservationRequest
rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
<x:passenger>Ake Jogvan Oyvind</x:passenger>
<x:outbound>
<x:TravelRequest>
<x:to>LAX</x:to>
<x:from>LGA</x:from>
<x:date>2001-12-14</x:date>
</x:TravelRequest>
</x:outbound>
<x:return>
<x:TravelRequest>
<x:to>JFK</x:to>
<x:from>LAX</x:from>
<x:date>2001-12-20</x:date>
</x:TravelRequest>
</x:return>
</x:ReservationRequest>
</rdf:RDF>
</env:Body>
</env:Envelope>예제 8a에 있는 HTTP GET에 대한 응답으로써 리턴된 SOAP 메시지
예약 상세 내역은 (X)HTML 문서로써 리턴될 수 있지만 이 예제는 예약 어플리케이션이 기계가 처리 가능한 데이터-중심 미디어 형식으로 자원을 리턴하는 경우를 보여준다. 사실상, SOAP을 사용하는 대부분의 어플리케이션은 브라우저가 아닐 것이다.
또한, 예제에서 보는 것처럼, HTTP 응답 body에 SOAP의 사용은 SOAP 헤더들의 사용을 통해 어플리케이션-특화된 특징을 표현할 가능성을 제공한다. SOAP을 사용함으로써, 어플리케이션은 그런 특징들을 표현하는 데 유용하고 지속적인 프레임워크와 처리 모델을 제공받는다.
SOAP 요청-응답 메시지 교환 패턴을 가지고 HTTP 바인딩을 사용하는 것은 HTTP POST 메쏘드에 국한된다. SOAP HTTP 바인딩에서 이런 메시지 교환 패턴의 사용은 모든 어플리케이션들에 가용하다, 그 어플리케이션들이 SOAP 메시지들로 싸여 있는 일반적인 XML 데이터 또는 RPC들의 교환을 포함할지라도.
예제들 9와 10은 예제 4와 예제 5a에서 사용된 것과 같은 시나리오를 사용해서, SOAP 요청-응답 메시지 교환 패턴을 사용하는 HTTP 바인딩의 예제를 보여준다. 예제들과 이 절에서의 논의는 단지 HTTP 헤더들과 그들의 역할에 집중한다.
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true" >5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard xmlns:o="http://mycompany.example.com/financial">
<n:name xmlns:n="http://mycompany.example.com/employees">
Ake Jogvan Oyvind
</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>HTTP POST 요청으로 전달된,
예제 4의 RPC
예제 9는 여행 서비스 어플리케이션을 향하는 RPC 요청를 보여준다. travelcompany.example.org 서버에 "예약" 자원을 명시하는 URI로 향하는 HTTP POST 메쏘드의 body로 SOAP 메시지가 전달된다. HTTP를 사용할 때, 요청-URI는 요청이 어디로 "post 되어야" 하는 지를 나타낸다. SOAP은, 요청 URI의 구문과 관련해서, 타당한 URI인가를 제외하고는 구문 관련해서는 어떤 제약도 두지 않는다 (URI에 대한 상세 정보는 [RFC 2396] 참조). 그러나, 웹 구조의 원칙들 중에 하나는 모든 중요한 자원들이 URI들에 명시된다는 것이다. 이것은 가장 잘 구조화된 SOAP 서비스들은, 각 자원이 자신의 URI를 가지는 형태로, 많은 수의 자원들을 포함할 것이다라는 것을 의미한다. 사실상, 그런 많은 자원들은 서비스 동작 과정에서 동적으로 생성될 것이다. 그러므로, 잘 구조화된 여행 서비스 어플리케이션은 각 예약에 대해서 서로 다른 URI들을 가져야 하고, 예약들을 처리하거나 조작하는 SOAP 요청들은, 예제 9에서 보는 것처럼, 다수의 "예약들"을 가르키는 하나의 URI가 아니라, 하나의 URI가 하나의 예약을 명시하는 URI들을 향하게 될 것이다. section 4.1.3에 예제 13은 특정 여행 예약과 같은 자원을 바탕으로 바람직한 방법을 보여준다. 따라서, 웹 구조 호환 SOAP/HTTP 사용에 대한 추가적인 논의는 section 4.1.3까지 연기한다.
SOAP 메시지들을 HTTP body들 내에 놓을 때, HTTP Content-type 헤더는 "application/soap+xml"여야 한다. ("utf-8" 또는 "utf-16"이 될 수 있는 선택 파라미터인 charset이 이 예제에서 표기될 수 있지만, 없다면 [XML 1.0]에 대한 character set 규칙들이 HTTP 요청의 body에 적용된다.)
예제 10은 (상세는 생략한 채로) 예제 5a의 요청에 대응되는 HTTP 응답으로, 여행 서비스 어플리케이션가 보내는 RPC 리턴을 보여준다. HTTP 전송을 사용하는 SOAP은 HTTP로 상태 정보를 교환할 때 HTTP 상태 코드들의 의미들을 그대로 수용한다. 예를 들어, HTTP 상태 코드들 중 2xx 시리즈들은 클라이언트의 요청를 잘 받았고, 이해했고, 받아들였다라는 것을 명시한다.
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
...
...
</env:Header>
<env:Body>
...
...
</env:Body>
</env:Envelope>성공적으로 완료됐음을 명시하는 HTTP 응답으로 표현된,
예제 5a의 RPC 응답
만약 요청을 처리하다 에러가 발생하면, HTTP 바인딩 규격은, 서버 측에서 처리 에러를 나타내는 SOAP 장애를 포함하는 SOAP 메시지와 함께 HTTP 500 "Internal Server Error"를 사용할 것을 요구한다.
예제 11은 예제 6a와 같은 SOAP 장애 메시지이다, 하지만 이번에는 HTTP 헤더들이 추가된다.
HTTP/1.1 500 Internal Server Error
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>rpc:BadArguments</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en-US">Processing error</env:Text>
<env:Text xml:lang="cs">Chyba zpracov??lt;/env:Text>
</env:Reason>
<env:Detail>
<e:myFaultDetails
xmlns:e="http://travelcompany.example.org/faults" >
<e:message>Name does not match card number</e:message>
<e:errorcode>999</e:errorcode>
</e:myFaultDetails>
</env:Detail>
</env:Fault>
</env:Body>
</env:Envelope>예제 4의 SOAP Body를 처리하다가 발생한 장애를 명시하는 HTTP 응답으로의 SOAP 메시지 예제
SOAP Part 2 Table 16은 여러 가지 가능한 HTTP 응답 코드들을 처리하는 것에 관한 상세 처리 절차를 제공한다.
월드 와이드 웹의 가장 중심적인 개념들 중 하나는 자원 식별자가 URI라는 것이다. HTTP 바인딩을 사용하고 다른 웹 소프트웨어들과 호환되기를 원하는 SOAP 서비스들은 서비스에 포함된 모든 중요한 자원들을 가르키는 데 URI들을 사용해야 한다. 예를 들어, 매우 중요한 - 사실상 지배적인 - 월드 와이드 웹의 사용법은, URI로 명시된 자원을 자원에 영향을 주는 것없이 HTTP GET 요청를 통해서 얻는 순수한 정보 획득이다. (이것은 HTTP 용어로 안전하고 변함없는 메쏘드로 불린다.) 핵심은 자원의 배포자가, 자원의 이용자가 "GET"할 해당 URI를 가용하도록 해야 한다는 것이다.
SOAP 메시지들이 순수하게 정보 획득을 목적으로 설계된 많은 예들이 있다, 자원에 대한 조작을 수행하는 데 사용하지 않고 단지 자원의 상태를 요청할 때처럼. 그런 예에서, 문제의 객체를 표현하는 body의 요소들을 가지고 그 객체의 상태에 대한 요청을 전달하는 데 SOAP body의 사용은, 자원이 HTTP GET의 요청-URI에 의해 명시되지 않기 때문에 웹의 정신에 위배되는 것처럼 보인다. (어떤 SOAP/RPC 구현에서는, HTTP 요청-URI는, 종종 자원의 식별자 그 자체가 아니라 자원을 명시하기 위해 SOAP 메시지들을 처리해야 하는 어떤 중간 엔티티이다.)
요구되는 변화들을 강조하기 위해, 예제 12a는 웹에서 안전한 정보 획득을 하기 위해 권장되지 않는 방법을 보여준다. 이것은 또 다시 여행 예약 주제를 사용하여, RPC를 SOAP 메시지로 전달하는 예제인 데, 이 예제는 RPC의 파라미터들 중 하나인, reservationCode에 의해 특정 예약을 명시하고, 그 예약에 대한 여정을 얻는 요청을 한다. (논의를 목적으로 이 RPC 요청를 사용하는 어플리케이션은 SOAP 헤더들의 사용할 필요가 없다고 가정한다.)
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Body>
<m:retrieveItinerary
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservationCode>FT35ZBQ</m:reservationCode>
</m:retrieveItinerary>
</env:Body>
</env:Envelope>이 표현법은 "안전하지 않은" 획득인 경우 권장되지 않는다(즉, 이것이 부산물을 가지지 않는다)
획득되는 자원은 HTTP 요청에 target URI로 명시되지 않고 SOAP envelope 안을 보아야 얻을 수 있음을 주지해라. 따라서, 웹 상에서 "gettable"한 다른 URI들의 경우와는 달리 윌드 와이드 웹의 사용자들에게 HTTP만으로는 가용하게 할 수 없다.
SOAP Part 2 section 4.1 은 안전하고 변함없는 정보 획득을 하는 RPC들이 어떻게 윕 친화적인 방법으로 정의될 지에 대한 권장사항들을 제공한다. 이것은 자원을 명시하는 데 사용되는 RPC의 메쏘드 및 파라미터들을 다른 목적을 위해 사용되는 것들과 구분함으로써 가능하다. 예제 12a에서, 획득될 자원은 다음 두 가지로 명시된다: 첫째는 여정(메쏘드 이름 부분), 그리고 둘째는 특정 인스턴스(instance)로의 참조자(메쏘드의 파라미터 부분). 그런 경우, 리소스-지정 부분이 자원을 명시하는 HTTP 요청-URI 내에 가용하도록 할 것이 권장된다, 예를 들면 다음과 같다: http://travelcompany.example.org/reservations/itinerary?reservationCode=FT35ZBQ.
더우기, 메쏘드 명세 부분이 자원-명시로써 묘사될 수 있도록 RPC가 정의되는 경우, RPC의 전체 target은 URI에 의해 명시될 것이다. 이런 경우, 자원 제공자는 또한 획득 요청이 safe함을 확신할 수 있고, 그러면 SOAP 버전 1.2는 GET 웹 메쏘드를 선택하고 section 4.1.1에 설명된 데로 SOAP 응답 메시지 교환 패턴을 사용할 것을 권장한다. 이것은 SOAP RPC가 웹 구조 호환되는 방법으로 수행되는 것을 확신할 수 있도록 한다.Example 12b 는 자원의 safe 획득을 요청하는 SOAP 노드가 선호하는 방법을 보여준다.
GET /Reservations/itinerary?reservationCode=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: application/soap+xml
SOAP 버전 1.2가 실제 정보 획득을 위해 RPC의 정의로부터 어떻게 URI를 계산하는 지에 대한 어떤 알고리즘도 정의하고 있지 않음을 명심해야 한다.
그러나, 만약 어플리케이션이 SOAP infoset(즉, SOAP 헤더 블록들) 내에 바인딩-관련된 표현들만이 가질 수 있는 특징들을 사용할 필요가 있다면, 어플리케이션은 요청 body에 SOAP 메시지를 포함하는 HTTP POST 메쏘드를 선택해야 한다.
또한, RPC 명세가 리소스-지정이 아닌 데이터(파라미터)를 포함한다면, HTTP POST를 통해서 구현된 SOAP 요청-응답 메시지 교환 패턴을 사용할 것이 요구된다. 이 경우에 조차도, SOAP 메시지를 포함하는 HTTP POST는 웹-친화적인 방법으로 표현될 수 있다. GET의 사용에서 처럼, [SOAP Part2]는 요청가 POST될 자원을 명시하기 위해 SOAP 메시지의 일부가 HTTP 요청-URI에 나타나도록 할 것을 권장한다. 같은 파라미터들이 물론 SOAP env:Body 엘리먼트에 유지된다. (파라미터들은 수신하는 어플리케이션의 프로시저/메쏘드와 관련이 있기 때문에, SOAP 기반의 RPC에서 Body에 유지되어야 한다)
예제 13은 HTTP 요청-URI가 예약 code를 포함한다는 것을 제외하면 예제 9에 있는 것과 같다.
POST /Reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
<?xml version='1.0'?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true" >5</t:transaction>
</env:Header>
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard xmlns:o="http://mycompany.example.com/financial">
<n:name xmlns:n="http://mycompany.example.com/employees">
Ake Jogvan Oyvind
</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation>
</env:Body>
</env:Envelope>예제 4의 RPC를 웹 친화적인 방법으로 HTTP POST 요청을 통해 전달한 것
예제 13에서, 처리될 자원은 두 가지 것으로 명시된다: 첫째는 예약(메쏘드명 부분), 그리고 두번째는 특정 예약 인스턴스 (메쏘드의 code 파라미터의 값)이다. creditCard 번호와 같은 RPC에 나머지 파라미터들은 자원에 의해 처리될 부가 데이터지만, 자원을 지정하는 데 사용되는 것은 아니다. [SOAP Part2]는 SOAP 기반 RPC들에 의해 access될 자원들은, 해당 자원을 지정하는 데 사용되는 정보를, RPC의 target을 명시하는 URI에 포함할 것을 권장한다. 하지만, [SOAP Part2]는 그렇게 하는 알고리즘은 제공하지 않음을 주지해라. 그런 알고리즘들은 추후에 개발될 수도 있다. 그러나, 모든 자원-지정 엘리먼트들은 예제 9에서 처럼 SOAP env:Body 엘리먼트에 인코드된 형태로 유지됨을 주목해라.
다른 말로, 위의 예제들에서 보는 것처럼, SOAP 표준들은 웹-구조와 호환되도록 URI들을 사용할 것을 권장한다, GET이 사용되든 POST가 사용되든 상관없이.
어플리케이션 개발자들은 SOAP 메시지를 전달하기 위해 인터넷 전자우편 구조를 사용할 수 있다, 전자우편 text 또는 첨부를 통해. 아래 예제들은 SOAP 메시지들을 전달하는 한 가지 방법을 제공하지만, 그렇게 하는 표준적인 방법이라고 이해하지 않아야 한다. SOAP 버전 1.2 규격들은 그런 바인딩을 지정하지 않는다. 그러나, SOAP의 전자우편 바인딩을 설명하는 non-normative W3C Note [SOAP 전자우편 바인딩]가 있다, 이것의 주 목적은 [SOAP Part 1]에서 설명하는 범용 SOAP 프로토콜 바인딩 프레임워크의 응용 어플리케이션을 보여주기 위함이다.
예제 14는 예제 1의 여행 예약 요청 메시지가, 송신 메일 사용자 프로그램과 수신 메일 사용자 프로그램 간에 전자 우편 메시지로 전달되는 것을 보여준다. 전자 우편 body를 처리할 수신 노드는 SOAP을 해석할 수 있다고 가정한다. (응답으로 전달되는 SOAP 장애를 처리하기 위해 또는 요청와 응답으로 받은 SOAP 메시지를 연관시키기 위해 송신 측도 SOAP을 해석할 수 있다고 가정한다.)
From: a.oyvind@mycompany.example.com
To: reservations@travelcompany.example.org
Subject: Travel to LA
Date: Thu, 29 Nov 2001 13:20:00 EST
Message-Id: <EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>예제 1의 SOAP 메시지를 SMTP 메시지로 전달한 것
예제 14에 헤더는 전자 우편 표준 형식 [RFC 2822]이다.
전자우편이 단 방향 통신이고 전송을 보장하지 않음에도 불구하고, Simple Mail Transport Protocol(SMTP) 규격 [SMTP]과 같은 전자 우편 구조는, DSN(Delivery Status Notification) 및 MDN(Message Disposition Notification)과 같은 전송 확인 메커니즘을 제공한다. 이런 확인 방법들은, 메일 헤더에 지정된 전자 우편 주소로 보내지는 전자 우편 메시지들의 형태를 취한다. 최종 전자 우편 사용자 뿐만 아니라 어플리케이션들도 전자우편 전송의 상태를 제공하기 위해 이런 메커니즘을 사용할 수 있다, 하지만 이런 것들은 SMTP 수준에서의 확인이다. 어플리케이션 개발자는 이런 전송 확인들의 기능과 제한들을 완전히 이해해야 한다.
SMTP 전송 상태 메시지들은 SOAP 계층에서 처리되는 메시지와 분리된다. 포함된 SOAP 데이터에 대한 SOAP 응답들은 SMTP 수준에서 원래 요청하는 전자 우편으로의 링크를 가질 수도 있고 그렇지 않을 수도 있는 새로운 전자 우편 메시지를 통해서 리턴될 것이다. 상관성(correlation) 부분은 [RFC 2822] In-reply-to: 헤더의 사용을 통해 SMTP 수준에서 처리될 수 있으므로, SOAP 수준에서 상관성을 제공할 필요는 없다.
예제 15는 전자우편 메시지로 전달된다는 것을 제외하고는 예제 2에서 언급한 시나리오와 정확히 똑같다, 이 시나리오는 여행 서비스 어플리케이션이 어떤 예약 상세 내용을 찾기 위해 여행 예약 어플리케이션으로 보낸 SOAP 메시지를 보여준다. 이 예제에서, 원래 전자우편의 Message-Id는, SMTP 수준에서 전자우편 메시지들을 상관시키기 위해, 부가 전자우편 헤더 In-reply-to:로 전달된다, 하지만 SOAP 메시지 연관성을 제공할 수는 없다. 이 예제에서, 어플리케이션은 SOAP 메시지들을 연관시키기 위해 reservation 헤더 블록에 의존한다. 다시 한번 말하지만, 그런 상관성이 어떻게 달성되는 지는 어플리케이션 이슈이지, SOAP 규격의 범위는 아니다.
From: reservations@travelcompany.example.org
To: a.oyvind@mycompany.example.com
Subject: Which NY airport?
Date: Thu, 29 Nov 2001 13:35:11 EST
Message-Id: <200109251753.NAA10655@travelcompany.example.org>
In-reply-to:<EE492E16A090090276D208424960C0C@mycompany.example.com>
Content-Type: application/soap+xml
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:35:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:itineraryClarifications>
...
...
</p:itineraryClarifications>
</p:itinerary>
</env:Body>
</env:Envelope>이전 메시지와의 상관된 헤더를 포함하여 전자우편 메시지로 전달된
예제 2의 SOAP 메시지
입문서 전체에 사용된 여행 예약 시나리오는 SOAP 중간 서버들의 사용을 볼 수 있는 기회를 제공한다. 기본 통신은 여행 예약 어플리케이션과 예행 서비스 어플리케이션 간에 여행 예약 요청이었음을 상기해라. SOAP은 그런 메시지 경로가 어떻게 결정되고 이어지는 지를 정의하지 않는다. 그것은 SOAP 규격의 범위를 벗어난다. 그럼에도 불구하고, SOAP 노드가 궁극적인 수신자가 아닌 SOAP 메시지를 받았다면 어떻게 동작해야 하는 지를 설명한다. SOAP 버전 1.2는 두 가지 중간 서버들, 전달하는 중간 서버들와 능동적인 중간 서버들를 설명한다.
A 전달하는 중간 서버는 수신한 SOAP 메시지의 헤더 블록의 의미에 따라 또는 사용하는 메시지 교환 패턴에 따라 SOAP 메시지를 다른 SOAP 노드로 전달하는 SOAP 노드이다. 예를 들어, 수신한 SOAP 메시지에서 메시지 경로 특성을 설명하는 "routing" 헤더 블록이, 그 헤더 블록의 데이터에 의해 명시된 다른 SOAP 노드로 SOAP 메시지를 전달하도록 강제할 수도 있다. 처리된 헤더 블록들의 의미에 따라, 전달하는(forwarding) 중간 서버는 outbound SOAP 메시지의 SOAP 헤더 형식을 결정한다.
능동적(active) 중간 서버는, SOAP 헤더 블록들 또는 사용되고 있는 메시지 교환 패턴에 의해 설명되지 않는 기준을 사용해서, 메시지를 전달하기 전에 SOAP 메시지에 추가 처리를 하는 노드이다. SOAP 노드의 능동적인 개입의 예제는, SOAP 메시지의 일부를 암호화하고 헤더 블록에 암호화 키에 대한 정보를 제공하거나, timestamp 또는 주석을 제공하는 추가 정보를 outbound 메시지의 새로운 헤더 블록에 포함하는 것일 수 있다.
능동적인 중간 서버가 메시지에서 수정한 내용을 설명할 수 있도록 하는 한 가지 메커니즘은 outbound SOAP 메시지로 헤더 블록들을 삽입하는 것이다. 이런 헤더 블록들은, notification에 따라 동작이 달라지는 그런 역할을 수행하는 SOAP 노드들에게 영향을 줄 수 있다. 이런 경우 삽입된 헤더 블록들은, 더 이후의 노드들에 의해 메시지들이 안전하게 처리될 수 있음을 확신하기 위해, 이어지는 중간 서버들이 필요에 따라 같거나 또는 다른 헤더 블록들을 (재)삽입할 것을 요구해야 한다. 예를 들어, 만약 암호화를 위해 제거된 헤더 블록들을 가진 메시지가 두번째 중간 서버를 통해 전달된다면 (원래 헤더 블록들이 복호화되어 다시 만들어지는 것없이), 암호화가 일어났다는 표시는 두번째 전달되는 메시지에 유지되어야 한다.
다음 예제에서, 여행 예약과 여행 서비스 어플리케이션 사이의 메시지 경로 상에 SOAP 노드를 도입하는 데, 이 SOAP 노드가 예제 1에 있는 메시지를 가로챈다. 그런 SOAP 노드의 예제는 여행사에서 오프라인 검토를 위해 모든 여행 요청들을 기록하는 것을 들 수 있다. 예제에서 헤더 블록 reservation과 passenger는 "next"의 역할에 해당하는 노드를 위한 것이다. 헤더 블록들은 필수이다(mustUnderstand 속성이 "true"로 설정된다), 이것은 노드가 (헤더 블록들의 의미들에 대한 외부 규격을 통해) 어떻게 해야 할 지를 알아야 한다는 것을 의미한다. 그런 헤더 블록들을 기록하는 규격이 단순히 메시지를 받는 모든 노드에서 메시지의 여러 가지 상세 사항들을 기록할 것을 요구할 수도 있고, 변경되지 않은 메시지 경로를 따라 전달되도록 요구할 수도 있다. (헤더 블록들에 대한 규격들은 같은 헤더 블록들이 outbound 메시지에 다시 삽입될 것을 요구해야 한다, 그렇지 않으면 SOAP 처리 모델이 헤더 블록들을 제거할 것을 요구할 수 있기 때문에.) 이런 경우, SOAP 노드는 전달하는 중간 서버로 동작한다.
훨씬 더 복잡한 시나리오는 수신한 SOAP 메시지가 초기 송신자가 기대하지 않은 식으로 수정되는 경우이다. 다음 예제에서, SOAP 중간 서버에 여행 어플리케이션은 궁극적인 수신자인 여행 서비스 어플리케이션으로 향하는 메시지 경로를 따라 메시지를 전달하기 전에, 예제 1의 SOAP 메시지에 헤더 블록을 덧붙인다. 헤더 블록은 해당 여행에 대한 여행 정책으로 인한 제약사항들을 포함한다. 그런 헤더 블록의 규격은 궁극적인 수신자가 메시지의 body를 처리할 때 해당 헤더 블록을 통해 전달되는 정보를 사용할 것을 요구할 수도 있다.
예제 16은 헤더 블록 travelPolicy를 추가하는 능동적인 중간 서버를 보여준다, 이 헤더 블록은 여행 요청에 대한 어플리케이션 수준의 처리 과정을 제한하는 정보를 포함하려는 목적을 가진다.
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</reference>
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n="http://mycompany.example.com/employees"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:name>Ake Jogvan Oyvind</n:name>
</n:passenger>
<z:travelPolicy
xmlns:z="http://mycompany.example.com/policies"
env:mustUnderstand="true">
<z:class>economy</z:class>
<z:fareBasis>non-refundable<z:fareBasis>
<z:exceptions>none</z:exceptions>
</z:travelPolicy>
</env:Header>
<env:Body>
<p:itinerary
xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
<p:departureTime>late afternoon</p:departureTime>
<p:seatPreference>aisle</p:seatPreference>
</p:departure>
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
<p:departureTime>mid morning</p:departureTime>
<p:seatPreference/>
</p:return>
</p:itinerary>
<q:lodging
xmlns:q="http://travelcompany.example.org/reservation/hotels">
<q:preference>none</q:preference>
</q:lodging>
</env:Body>
</env:Envelope>능동적인 중간 서버가 메시지의 궁극적인 수신자를 의도하여 필수 헤더를 삽입한, 여행 예약을 위한
예제 1의 SOAP 메시지
SOAP 버전 1.2가 특정 인코딩 스킴 (a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapenc"> SOAP Part 2 section 3 참조)을 정의함에도 불구하고, 이것을 사용하는 것은 선택사항이고 규격은 다른 인코딩 스킴들이 어플리케이션-관련 데이터에 대해서 사용될 수 있다는 것을 명확히한다. 이런 목적으로 xs:anyURI 형식의 env:encodingStyle 속성을 제공하는 데, 이 속성은 헤더 블록들, SOAP env:Body의 차일드 엘리먼트들, env:Detail 엘리먼트의 차일드 엘리먼트들과 그 하위 엘리먼트들을 qualify한다. 이것은 하위에 포함된 컨텐츠에 적용되는 일괄 적용 스킴이다, 즉 하위에 컨텐츠에 다른 인코딩 스타일을 나타내는 다른 엘리먼트가 나타나기 전에는 최소한 계속 적용된다. env:encodingStyle 속성의 값을 선택하는 것은 어플리케이션의 결정 사항이고 상호 호환성은 "out-of-band"로 해결된다고 가정한다. 이 속성이 존재하지 않으면, 사용될 인코딩에 대한 요구 사항은 없는 것이다.
예제 17에서는 다른 인코딩 스킴의 사용을 보여준다. 계속해서 여행 예약 주제를 가지고, 이 예제는 예약이 확정된 후, 여행 서비스가 여행객에게 보낸, 여행 상세 내역을 나타내는 SOAP 메시지를 보여준다. (같은 메시지가 예제 8b에서 다른 의미로 사용된다.)
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://travelcompany.example.org/vocab#"
env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<x:ReservationRequest
rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
<x:passenger>Ake Jogvan Oyvind</x:passenger>
<x:outbound>
<x:TravelRequest>
<x:to>LAX</x:to>
<x:from>LGA</x:from>
<x:date>2001-12-14</x:date>
</x:TravelRequest>
</x:outbound>
<x:return>
<x:TravelRequest>
<x:to>JFK</x:to>
<x:from>LAX</x:from>
<x:date>2001-12-20</x:date>
</x:TravelRequest>
</x:return>
</x:ReservationRequest>
</rdf:RDF>
</env:Body>
</env:Envelope>Body 엘리먼트에 대해 여러 가지 인코딩을 사용하는 것을 보여주는 SOAP 메시지
예제 17에서, SOAP 메시지의 body는, RDF(Resource Description Framework) [RDF]의 문법에 따라 구성된, 자원과 해당 자원의 속성 그래프의 인코딩을 사용하여 여정을 묘사한다. (RDF 문법 또는 사용법은 이 입문서의 주제가 아니므로 매우 간략하게, RDF 그래프는 자원들을 - http://travelcompany.example.org/reservations?code=FT35ZBQ 에 가용한 여행 예약 자원과 같은 - 속성(예를 들어, passenger, outbound 그리고 return 날짜 등)을 통해서 다른 자원들과 관계를 만든다. 여정에 대한 RDF 인코딩은 여행객의 여행 어플리케이션이 RDF-지원 일정(calendar) 어플리케이션이 그것을 저장하여 복잡한 방법으로 쿼리할 수 있도록, 여정에 대한 RDF 인코딩을 선택할 수 있을 것이다.)
SOAP 버전 1.2는 문법에 있어서 몇 가지 변화가 있고 [SOAP 1.1]에서 기술된 것에 부가적인 의미들을 제공한다. 다음은 두 규격들 간에 차이가 있는 특징들의 목록이다. 이 목록의 목적은 두 규격들 간에 차이점을 독자에게 빠르고 쉽게 전달하기 위함이다. 특징들은 참조하기 편리하도록 범주를 나누었고 어떤 경우에는 한 item이 똑같이 다른 범주에 있을 수도 있다.
문서 구조
- The SOAP 1.2 규격은 두 부분으로 제공된다. [SOAP Part1]은 Infoset 기반으로 SOAP 메시지 구조, 처리 모델 그리고 하위 프로토콜 바인딩 프레임워크의 추상적인 정의를 제공한다, 반면 [SOAP Part2]는 특정 HTTP 바인딩 뿐만 아니라 그런 infoset을 전달하는 직렬화(serialization) 규칙을 제공한다.
- SOAP 1.2 는 약어를 풀어쓰지 않았다.
- SOAP 1.2 는 SOAP 1.1에서 요구된 <?xml....?> 형태의 직렬화(serialization)으로써가 아니고, XML infoset의 용어로 다시 쓰여졌다.
추가 또는 변경된 문법
- SOAP 1.2는 body 이후에 어떤 엘리먼트도 허용하지 않는다. SOAP 1.1 스키마 정의는 그것에 대해서 서술하지는 않았지만, 그런 가능성을 허용한다.
- SOAP 1.2는 SOAP
env:Envelope에 env:encodingStyle 속성을 허용하지 않는다, 반면 SOAP 1.1은 모든 엘리먼트에 사용 가능한다. SOAP 1.2는 이 속성이 사용될 특정 엘리먼트들을 지정한다.
- SOAP 1.2는
env:NotUnderstood 헤더 엘리먼트를 새로 정의한다, 이 엘리먼트는, env:MustUnderstand 실패 코드로써 명시되는 것과 같이, 처리하지 않아도 되는 정보를 필수 헤더 블록으로 전달하기 위해 사용된다. SOAP 1.1은 실패 코드를 제공한다, 하지만 그 사용에 대한 상세는 없다.
- SOAP 1.2 infoset 기반 명세에서, 헤더 엘리먼트들에
env:mustUnderstand 속성은 (논리) 값 "true" 또는 "false"를 취한다, 반면 SOAP 1.1에서는 각각 문자 값 "1" 또는 "0"이었다.
- SOAP 1.2는 새로운 실패 코드
DataEncodingUnknown을 제공한다.
- 두 프로토콜들에서 정의된 여러 가지 namespace들 또한 물론 다르다.
- SOAP 1.2는
env:actor 속성을 env:role로 대체하지만 의미는 완전히 동일하다.
- SOAP 1.2는 처리되지 않은 헤더 블록이 전달되어야 하는 지를 명시하기 위해 새로운 속성
env:relay를 도입한다.
- SOAP 1.2는 "none"과 "ultimateReceiver"라는 두 가지 새로운 역할들을 이것들이 어떻게 동작해야 하는 지에 관한 상세 처리 모델과 함께 정의한다.
- SOAP 1.2는 실패 코드들에 "dot" 표시를 제거했다, 지금은 단지 namespace 접두어가 SOAP envelope namespace인 XML Qualified Name이다.
- SOAP 1.2는 "client"와 "server" 실패 코드들을 "Sender"와 "Receiver"로 대체한다.
- SOAP 1.2는 SOAP 1.1에서
faultcode와 faultstring으로 불리던 것에 대해, 각각 env:Code와 env:Reason 엘리먼트들를 사용한다. SOAP 1.2는 또한 실패 원인을 다수의 언어로 표현할 수 있도록, xml:lang을 지정한 다수의 env:Text 차일드 엘리먼트들을 env:Reason 하위에 둘 수 있도록 했다.
- SOAP 1.2는
env:Fault 엘리먼트 내에, 필수 SOAP env:Code 서브-엘리먼트를 위한 계층적 구조를 제공한다, 그리고 두 가지 새로운 서브 엘리먼트들, env:Node와 env:Role을 도입한다.
- SOAP 1.2는, SOAP 1.1에서
env:Fault 내에 env:Details 엘리먼트의 존재 유무로 명시되던 헤더와 body 실패 간의 구분을 제거한다. SOAP 1.2에서, env:Details 엘리먼트의 존재는 실패 SOAP 메시지를 처리하는 데 있어서 아무런 의미가 없다.
- SOAP 1.2는 상대 URI 참조자들의 기본 URI를 결정하는 데 XML Base [XML Base]를 사용한다, 반면 SOAP 1.1은 언급하지 않는다.
SOAP HTTP 바인딩
- SOAP 1.2 HTTP 바인딩에서, SOAP 1.1에서 정의된
SOAPAction HTTP 헤더는 제거된다, 그리고 서버 어플리케이션이 재량에 따라 그것이 필요하다는 것을 명시하기 위한 새로운 HTTP 상태 코드 427이 IANA로부터 추진되었다. 이전의 SOAPAction HTTP 헤더의 컨텐츠는 HTTP 바인딩으로 알려지는 "application/soap+xml" 미디어 형식의 "action" (선택) 파라미터의 값으로써 표현된다.
- SOAP 1.2 HTTP 바인딩에서, Content-type 헤더는 SOAP 1.1에서의 "text/xml" 대신에 "application/soap+xml"이어야 한다. 이 새로운 미디어 형식에 대한 IETF 등록은 진행 중에 있다 [SOAP MediaType].
- SOAP 1.2는 여러 가지 2xx, 3xx, 4xx HTTP 상태 코드들의 사용에 대한 훨씬 더 자세한 단위의 설명을 제공한다.
- HTTP 확장 프레임워크의 지원은 SOAP 1.2에서 제거되었다.
- SOAP 1.2는 안전하고 변함없는 정보 획득을 위해 HTTP GET을 사용할 수 있도록 하는, HTTP 바인딩의 일부로써 사용될 수도 있는, 부가적인 메시지 교환 패턴을 제공한다.
RPC
- SOAP 1.2는 RPC에 대해
rpc:result 엘리먼트 accessor를 제공한다.
- SOAP 1.2는 RPC namespace에 몇 가지 실패 코드들을 추가 제공한다.
- SOAP 1.2는, procedure의 목적이 단순히 "안전한" 정보 획득인 RPC들을 웹 친화적으로 정의하는 접근법을 안내한다.
SOAP 인코딩들
- directed edge labeled 그래프에 기초한 추상 데이터 모델이 SOAP 1.2에서 공식화되었다. SOAP 1.2 인코딩들은 이 데이터 모델에 의존한다. SOAP RPC 규정들은 이 데이터 모델에 의존하지만, SOAP 인코딩과는 상관없다. SOAP 1.2 인코딩들과 SOAP 1.2 RPC 규정들에 대한 지원은 선택사항이다.
- SOAP 1.2에서 배열의 직열화에 대한 문법은 SOAP 1.1과 다르다.
- SOAP 1.1에서 제공된, 부분적으로 전달되어 산재된 배열들에 대한 지원은 SOAP 1.2에서 가용하지 않다.
- SOAP 1.2는 multiref 값들에 대한 inline (임베드된) 직열화를 허용한다.
- SOAP 1.1에서 (
xs:anyURI 형식의) href 속성은 SOAP 1.2에서는 enc:ref이고 IDREF 형식이다.
- SOAP 1.2에서, 복합 형식의 생략된 accessor들은 NIL과 같게 만들었다.
- SOAP 1.2는 인코딩 에러들을 명시하는 몇 가지 실패 서브-코드들을 제공한다.
- SOAP 1.2에서 노드들에 Type들은 선택 사항으로 만들었다.
- SOAP 1.2는 SOAP 데이터 모델에서 generic compound value들은 없어졌다.
- SOAP 1.2는 구조(즉, simple value, struct 또는 array)를 명시하기 위해, SOAP 인코딩을 사용해서 인코딩된 엘리먼트로 선택 속성
enc:nodeType를 추가한다.
SOAP Part 1 Appendix A는, SOAP 노드가 [SOAP 1.1]에서 SOAP 버전 1.2로 전환하는 것을 지원할 수 있는, 버전 관리 규칙을 제공한다. 특히, SOAP 1.2 노드에서 [SOAP 1.1] 메시지를 받았을 때, 자신이 지원하는 버전을 알리는 SOAP 실패 메시지를 송신자에게 보내는 데 사용될 수 있는 env:Upgrade 헤더 블록을 정의한다.
[SOAP Part1] W3C Recommendation "SOAP 1.2 Part 1: Messaging Framework", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)
[SOAP Part2] W3C Recommendation "SOAP 1.2 Part 2: Adjuncts", Martin Gudgin, Marc Hadley, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003 (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624.)
[RFC 2396] IETF "RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998. (See http://www.ietf.org/rfc/rfc2396.txt.)
[HTTP 1.1] IETF "RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1", R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee, January 1997. (See http://www.ietf.org/rfc/rfc2616.txt.)
[XML 1.0] W3C Recommendation "Extensible Markup Language (XML) 1.0 (Second Edition)", Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, 6 October 2000. (See http://www.w3.org/TR/2000/REC-xml-20001006.
[Namespaces in XML] W3C Recommendation "Namespaces in XML", Tim Bray, Dave Hollander, Andrew Layman, 14 January 1999. (See http://www.w3.org/TR/1999/REC-xml-names-19990114/.)
[XML Schema Part1] W3C Recommendation "XML Schema Part 1: Structures", Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ )
[XML Schema Part2] W3C Recommendation "XML Schema Part 2: Datatypes", Paul V. Biron, Ashok Malhotra, 2 May 2001. (See http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ )
[SMTP] SMTP is defined in a series of RFCs:
[RDF] W3C Recommendation "Resource Description Framework (RDF) Model and Syntax Specification", O. Lassila and R. Swick, Editors. World Wide Web Consortium. 22 February 1999. (See http://www.w3.org/TR/REC-rdf-syntax.)
[SOAP 1.1] W3C Note "Simple Object Access Protocol (SOAP) 1.1", Don Box et al., 8 May, 2000 (See http://www.w3.org/TR/SOAP/)
[XML Infoset] W3C Recommendation "XML Information Set", John Cowan, Richard Tobin, 24 October 2001. (See http://www.w3.org/TR/xml-infoset/)
[SOAP MediaType] IETF Internet Draft "The 'application/soap+xml' media type", M. Baker, M. Nottingham, "draft-baker-soap-media-reg-03.txt", May 29, 2003. (See http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-03.txt, note that this Internet Draft expires in November 2003)
[SOAP Email Binding] W3C Note "SOAP Version 1.2 Email Binding", Highland Mary Mountain et al, draft June 13, 2002. (See http://www.w3.org/TR/2002/NOTE-soap12-email-20020626.)
[XML Base] W3C Recommendation "XML Base", Jonathan Marsh, 27 June 2001. (See http://www.w3.org/TR/2001/REC-xmlbase-20010627/)
[RFC 2119] IETF "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
Highland Mary Mountain (Intel)은 SMTP 바인딩에 대한 초기 자료를 제공했다. Paul Denning은 사용 시나리오에 대한 자료를 제공했다, 이 시나리오는 SOAP 버전 1.2 사용 시나리오 Working Draft로 옮겨졌다. Stuart Williams, Oisin Hurley, Chris Ferris, Lynne Thompson, John Ibbotson, Marc Hadley, Yin-Leng Husband 그리고 Jean-Jacques Moreau는, Last Call Working Draft 검토 동안에 다른 많은 사람들이 했던 것처럼, 이 문서의 이전 버전에 대한 상세 의견을 제공했다. Jacek Kopecky는 일련의 RPC 및 SOAP 인코딩에 대한 일련의 변화를 제공했다.
이 문서는 W3C XML 프로토콜 워킹 그룹의 작업이다.
워킹 그룹 참가자들 (이 문서 작성 시, 알파벳 순으로): Carine Bournez (W3C), Michael Champion (Software AG), Glen Daniels (Macromedia, formerly of Allaire), David Fallside (IBM, Chair), Dietmar Gaertner (Software AG), Tony Graham (Sun Microsystems), Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor), Marc Hadley (Sun Microsystems), Gerd Hoelzing (SAP AG), Oisin Hurley (IONA Technologies), John Ibbotson (IBM), Ryuji Inoue (Matsushita Electric), Kazunori Iwasa (Fujitsu Limited), Mario Jeckle (DaimlerChrysler R. & Tech), Mark Jones (AT&T), Anish Karmarkar (Oracle), Jacek Kopecky (Systinet/Idoox), Yves Lafon (W3C), Michah Lerner (AT&T), Noah Mendelsohn (IBM, formerly of Lotus Development), Jeff Mischkinsky (Oracle), Nilo Mitra (Ericsson), Jean-Jacques Moreau (Canon), Masahiko Narita (Fujitsu Limited), Eric Newcomer (IONA Technologies), Mark Nottingham (BEA Systems, formerly of Akamai Technologies), David Orchard (BEA Systems, formerly of Jamcracker), Andreas Riegg (DaimlerChrysler R. & Tech), Hervé Ruellan (Canon), Jeff Schlimmer (Microsoft Corporation), Miroslav Simek (Systinet/Idoox), Pete Wenzel (SeeBeyond), Volker Wiechers (SAP AG).
이전 참가자들: Yasser alSafadi (Philips Research), Bill Anderson (Xerox), Vidur Apparao (Netscape), Camilo Arbelaez (WebMethods), Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems), Philippe Bedu (EDF (Electricité de France)), Olivier Boudeville (EDF (Electricité de France)), Don Box (Microsoft Corporation, formerly of DevelopMentor), Tom Breuel (Xerox), Dick Brooks (Group 8760), Winston Bumpus (Novell), David Burdett (Commerce One), Charles Campbell (Informix Software), Alex Ceponkus (Bowstreet), David Chappell (Sonic Software), Miles Chaston (Epicentric), David Clay (Oracle), David Cleary (Progress Software), Conleth O'Connell (Vignette), Ugo Corda (Xerox), Paul Cotton (Microsoft Corporation), Fransisco Cubera (IBM), Jim d'Augustine (eXcelon), Ron Daniel (Interwoven), Dug Davis (IBM), Ray Denenberg (Library of Congress), Paul Denning (MITRE), Frank DeRose (Tibco), Mike Dierken (DataChannel), Andrew Eisenberg (Progress Software), Brian Eisenberg (DataChannel), Colleen Evans (Sonic Software), John Evdemon (XMLSolutions), David Ezell (Hewlett-Packard), Eric Fedok (Active Data Exchange), Chris Ferris (Sun Microsystems), Daniela Florescu (Propel), Dan Frantz (BEA Systems), Michael Freeman (Engenia Software), Scott Golubock (Epicentric), Rich Greenfield (Library of Congress), Hugo Haas (W3C), Mark Hale (Interwoven), Randy Hall (Intel), Bjoern Heckel (Epicentric), Erin Hoffman (Tradia), Steve Hole (MessagingDirect Ltd.), Mary Holstege (Calico Commerce), Jim Hughes (Fujitsu Software Corporation), Yin-Leng Husband (Hewlett-Packard, formerly of Compaq), Scott Isaacson (Novell), Murali Janakiraman (Rogue Wave), Eric Jenkins (Engenia Software), Jay Kasi (Commerce One), Jeffrey Kay (Engenia Software), Richard Koo (Vitria Technology Inc.), Alan Kropp (Epicentric), Julian Kumar (Epicentric), Peter Lecuyer (Progress Software), Tony Lee (Vitria Technology Inc.), Amy Lewis (TIBCO), Bob Lojek (Intalio), Henry Lowe (OMG), Brad Lund (Intel), Matthew MacKenzie (XMLGlobal Technologies), Murray Maloney (Commerce One), Richard Martin (Active Data Exchange), Highland Mary Mountain (Intel), Alex Milowski (Lexica), Kevin Mitchell (XMLSolutions), Ed Mooney (Sun Microsystems), Dean Moses (Epicentric), Don Mullen (TIBCO), Rekha Nagarajan (Calico Commerce), Raj Nair (Cisco), Mark Needleman (Data Research Associates), Art Nevarez (Novell), Henrik Nielsen (Microsoft Corporation), Kevin Perkins (Compaq), Jags Ramnaryan (BEA Systems), Vilhelm Rosenqvist (NCR), Marwan Sabbouh (MITRE), Waqar Sadiq (Vitria Technology Inc.), Rich Salz (Zolera), Krishna Sankar (Cisco), George Scott (Tradia), Shane Sesta (Active Data Exchange), Lew Shannon (NCR), John-Paul Sicotte (MessagingDirect Ltd.), Simeon Simeonov (Allaire), Simeon Simeonov (Macromedia), Aaron Skonnard (DevelopMentor), Nick Smilonich (Unisys), Soumitro Tagore (Informix Software), James Tauber (Bowstreet), Lynne Thompson (Unisys), Patrick Thompson (Rogue Wave), Jim Trezzo (Oracle), Asir Vedamuthu (WebMethods), Randy Waldrop (WebMethods), Fred Waskiewicz (OMG), David Webber (XMLGlobal Technologies), Ray Whitmer (Netscape), Stuart Williams (Hewlett-Packard), Yan Xu (DataChannel), Amr Yassin (Philips Research), Susan Yee (Active Data Exchange), Jin Yu (Martsoft).
우리는 또한 xml-dist-app@w3.org의 논의에 기여했던 모든 사람들에게 감사한다.
