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 으로 내용을 보내주시면 감사하겠습니다.

목차

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)

1. 개론

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은 틀림없이 전체 솔루션의 일부분일 것이고 예제들에서 포함하지 않은 응용 프로그램 특화된 요구사항들이 존재할 것임이 분명하다.

1.1 개관

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은 참고 문헌들을 제공한다.

참고하기 용이하도록, 이 입문서에 사용된 용어와 개념은 메인 규격에 있는 해당 개념에 대한 정의로 하이퍼 링크된다.

1.2 표기법 약정

이 입문서에서는, 간단한 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 네임스페이스 이름들과 관련된다.

어떤 다른 네임스페이스 접두어의 선택은 임의이며 의미상 중요하지는 않다.

"http://example.org/..."와 "http://example.com/..." 등 일반적인 형식의 네임스페이스 URI들은 응용 프로그램에 따라 또는 문맥에 따라 다른 URI [RFC 2396]를 나타낸다.

2. 기본 사용 시나리오들

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은 장애 처리 예제를 보여준다.

2.1 SOAP 메시지들

예제 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>

예제 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 메시지들과 처리 방법의 상세 설명에 집중한다.

2.2 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.2.1 대화형 메시지 교환

예제 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>

이전에 설명한 것처럼, 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.2.2 원격 프로시저 호출들

SOAP 버전 1.2의 설계 목표 중에 하나는 XML의 확장성과 유연성을 사용하여 RPC를 담는(encapsulate) 것이다. SOAP Part 2 section 4는 SOAP 메시지들로 전달되는 RPC 호출과 응답에 대한 공통 표현을 정의한다. 이 절은 여행 예약 시나리오를 계속 사용하여 RPC와 해당되는 응답이 SOAP 메시지를 사용하여 전달되는 방법을 설명한다.

그런 목적으로, 다음 예제는 신용 카드를 사용하여 여행에 대한 지불을 하는 것을 보여준다. (section 2.2.1에 설명된 대화형 교환이 확정된 여행 스케쥴임을 가정한다.) 여기서, 지불은 여행과 숙박이 둘다 확정되었을 때에 신용카드를 요구하는 방식으로 이루어진다고 가정한다. 여행 예약 어플리케이션이 신용 카드 정보를 제공하고 카드 청구를 위한 서로 다른 절차들을 성공적으로 완료하면 예약 코드가 리턴된다. 여행 예약 어플리케이션과 여행 서비스 어플리케이션 간의 이런 예약-그리고-청구 거래는 SOAP RPC로 모델링된다.

SOAP RPC를 호출하기 위해, 다음 정보가 필요하다:

1. 수신 SOAP 노드의 주소
2. 프로시저 또는 메쏘드 명
3. 출력 파라미터 및 리턴값과 함께 프로시저 또는 메쏘드로 전달될 매개 변수들의 식별자들과 값들.
4. 목표 자원이 호출을 처리하는 데 사용할 데이터 또는 제어 정보를 전달하는 것과 대조하여 RPC의 실제 목표인 웹 자원을 명시하는 데 사용되는 매개 변수의 명확한 분리
5. 사용될 소위 "웹 메쏘드"의 명시과 함께, RPC를 전달하는 데 사용할 메시지 교환 패턴
6. 선택사항으로, 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>

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>

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>

예제 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 만으로 제한되지는 않는다는 점을 명심하는 것이 중요하다.

2.3 장애 시나리오들

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>

예제 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 규격의 범위는 아니다.)

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>

만약 이해할 수 없는 몇 가지 필수 헤더 블록들이 있다면, 각각을 일련의 env:NotUnderstood 헤더 블록들에 qname으로 명시할 수 있다.

3. SOAP 처리 모델

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 "env"인 엘리먼트들, 처리할 때 요구사항이 있다. 그런 엘리먼트들은 envelope 그 자체, 헤더 엘리먼트 그리고 body 엘리먼트이다. 첫 단계는 물론 SOAP 메시지가 문법적으로 맞는 지를 전반적으로 체크하는 것이다. 즉, SOAP 메시지는, SOAP Part 1, section 5.에 정의된 XML 구조물의 - 처리 명령들과 문서 양식 정의(Document Type Definition)들 - 사용에 대한 제약사항들을 가정하는 SOAP XML infoset을 사용한다.

3.1 "role" 속성

메시지를 처리할 때 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"는 각각 대응하는 노드가 명명된 역할을 하거나 하지 않는다는 것을 의미한다.)

3.2 "mustUnderstand" 속성

예제 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 노드는 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속성에 따라 헤더 블록에 대한 처리가 어떻게 달라지는 지를 정리한 것이다.

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 참조.)

3.3 "relay" 속성

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>

메시지 경로에서 "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 중간 서버가 처리되지 않은 헤더 블록들을 전달하는 것을 언제 허용할 것인 가를 결정하는 조건들을 요약한다.

4. 여러 가지 프로토콜 바인딩들

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 프로토콜 바인딩 프레임워크의 응용 예를 제공한다.

4.1 SOAP HTTP 바인딩

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 바인딩에 사용하는 예제들을 제공한다.

4.1.1. SOAP HTTP GET 사용

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 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>

예약 상세 내역은 (X)HTML 문서로써 리턴될 수 있지만 이 예제는 예약 어플리케이션이 기계가 처리 가능한 데이터-중심 미디어 형식으로 자원을 리턴하는 경우를 보여준다. 사실상, SOAP을 사용하는 대부분의 어플리케이션은 브라우저가 아닐 것이다.

또한, 예제에서 보는 것처럼, HTTP 응답 body에 SOAP의 사용은 SOAP 헤더들의 사용을 통해 어플리케이션-특화된 특징을 표현할 가능성을 제공한다. SOAP을 사용함으로써, 어플리케이션은 그런 특징들을 표현하는 데 유용하고 지속적인 프레임워크와 처리 모델을 제공받는다.

4.1.2 SOAP HTTP POST 사용

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>

예제 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 바인딩 규격은, 서버 측에서 처리 에러를 나타내는 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>

SOAP Part 2 Table 16은 여러 가지 가능한 HTTP 응답 코드들을 처리하는 것에 관한 상세 처리 절차를 제공한다.

4.1.3 웹 구조 호환 SOAP 사용

월드 와이드 웹의 가장 중심적인 개념들 중 하나는 자원 식별자가 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>

예제 13에서, 처리될 자원은 두 가지 것으로 명시된다: 첫째는 예약(메쏘드명 부분), 그리고 두번째는 특정 예약 인스턴스 (메쏘드의 code 파라미터의 값)이다. creditCard 번호와 같은 RPC에 나머지 파라미터들은 자원에 의해 처리될 부가 데이터지만, 자원을 지정하는 데 사용되는 것은 아니다. [SOAP Part2]는 SOAP 기반 RPC들에 의해 access될 자원들은, 해당 자원을 지정하는 데 사용되는 정보를, RPC의 target을 명시하는 URI에 포함할 것을 권장한다. 하지만, [SOAP Part2]는 그렇게 하는 알고리즘은 제공하지 않음을 주지해라. 그런 알고리즘들은 추후에 개발될 수도 있다. 그러나, 모든 자원-지정 엘리먼트들은 예제 9에서 처럼 SOAP env:Body 엘리먼트에 인코드된 형태로 유지됨을 주목해라.

다른 말로, 위의 예제들에서 보는 것처럼, SOAP 표준들은 웹-구조와 호환되도록 URI들을 사용할 것을 권장한다, GET이 사용되든 POST가 사용되든 상관없이.

4.2 전자우편을 통한 SOAP

어플리케이션 개발자들은 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>

예제 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>

5. 고급 사용 시나리오들

5.1 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>

5.2 다른 인코딩 스킴들을 사용해서

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>

예제 17에서, SOAP 메시지의 body는, RDF(Resource Description Framework) [RDF]의 문법에 따라 구성된, 자원과 해당 자원의 속성 그래프의 인코딩을 사용하여 여정을 묘사한다. (RDF 문법 또는 사용법은 이 입문서의 주제가 아니므로 매우 간략하게, RDF 그래프는 자원들을 - http://travelcompany.example.org/reservations?code=FT35ZBQ 에 가용한 여행 예약 자원과 같은 - 속성(예를 들어, passenger, outbound 그리고 return 날짜 등)을 통해서 다른 자원들과 관계를 만든다. 여정에 대한 RDF 인코딩은 여행객의 여행 어플리케이션이 RDF-지원 일정(calendar) 어플리케이션이 그것을 저장하여 복잡한 방법으로 쿼리할 수 있도록, 여정에 대한 RDF 인코딩을 선택할 수 있을 것이다.)

6. SOAP 1.1과 SOAP 1.2 간의 차이점

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 헤더 블록을 정의한다.

7. 참고 문헌

A. 감사의 글

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의 논의에 기여했던 모든 사람들에게 감사한다.

⊙ SOAP 구조

⊙ SOAP Part 구조HTTP

1. 요 청 (Request)

▷ Method

◦ POST

메시지의 entity body에 포함되어 있는 자원을 Request-Line에 있는 Request-URI에 지정되어 있는 대로 서버에서 수용해달라고 요청할 때 쓰인다

HTTP/1.0의 모든 POST 요구 메시지에는 Content-Length가 반드시 있어야 하며, 서버가 이에 대한 정보를 확보하지 못하게 되면 400 (Bad Request) 메시지를 응답해야 한다.

▷ Header Field

◦ Content-Length

Entity-Body의 크기를 바이트 단위로 표시하여 수신측에게 알려주는 용도.

◦ Content-Type

수신측에게 전달하는 Entity-Body의 데이타 형식을 표시한다. (MIME)

◦ Pragma

general-header 필드. request/response chain을 따라 어떤 수신측에도 적용할 수 있는 구현 방식에 한정된 지시자(implementation-specific)를 포함하는 데 사용한다

"no-cache" 변수가 요구 메시지에 존재한다면 응용 프로그램에서는 해당 자원이 캐시되어 있을지라도 원래 위치하고 있는 서버로 요구 메시지를 전달해야 한다. 이것은 클라이언트가 보내는 요구에 대해 신뢰할 수 있는 응답을 받고자 할 때 쓰일 수 있으며, 또한 클라이언트에게 데이타 오류와 같이 문제가 발생한 캐시 문서를 갱신할 수 있도록 할 때 쓰일 수 있다.

◦ Cache-Control

브라우저나 프록시 서버로 하여금 요청시에 캐시된 문서를 사용하지 말고 매번 서버로부터 새로운 문서를 다시 전송받아 사용하도록 알리는 헤더.

HTTP1.0 에서는 Pragma 헤더에 'no-cache'를, HTTP1.1 에서는 Cache-Control 헤더에 'no-cache'를 각각 지정함으로써 가능하다.

◦ User-Agent

사용자가 요구 메시지를 생성시키는 브라우저에 대한 정보를 나타낸다.

◦ Host
request-header 필드. 자원의 인터넷 호스트와 포트 숫자를 명시.

◦ Accept
request-header 필드. 요구에 대한 응답 메시지로서 허용할 수 있는 media type 범위를 알려줄 때 사용한다.
"type/*" 표시는 해당 type에 대한 모든 종류의 subtype 형식을 허용한다는 뜻.

◦ Date
메시지가 만들어지는 날짜와 시간

2. 응 답 (Response)

▷ 상태 코드 (Status Code)

◦ Informational 1xx

임시적인 응답을 의미. Status-Line과 선택적인 헤더들로 구성되어 빈줄로서 끝을 나타낸다.

◦ Successful 2XX

클라이언트의 요구가 성공적으로 수신되어 처리되었다는 것을 의미.

- 200 OK

클라이언트의 요구가 서버에서 성공적으로 처리되었음.

◦ Redirection 3xx

해당 요구를 수행하기 위해 추가적인 동작이 필요

◦ Client Error 4xx

클라이언트에 의해 생긴 오류 상황들에 대해 사용한다.

◦ Server Error 5xx

서버에게 일어난 오류상황이나 요구 사항을 처리할 수 없을 때.

⊙ SOAP Part 구조

▷ <env:Envelop>

◦ 루트 엘리먼트

◦ SOAP 메시지를 위한 네임스페이스

-         SOAP 네임스페이스 : http://schemas.xmlsoap.org/soap/envelope/

-         XML Schema 네임스페이스 : http://www.w3.org/2001/XMLSchema

-         XML Schema 인스턴스 네임스페이스 : http://www.w3.org/2001/XMLSchema-instance

-         데이터 타입 인코딩 네임스페이스

: http://schemas.xmlsoap.org/soap/encoding/

◦ SOAP 버전

-         SOAP 의 Envelope 엘리먼트는 명시적으로 프로토콜의 버전을 표현하지 않는다.

-         대신 XML 네임스페이스의 능력을 증대시키고, SOAP envelope namespace 의 URI가 되기 위한 프로토콜의 버전을 정의한다.

◦ 예제

▷ <env:Header>

◦ <env:Envelop> 엘리먼트의 하위 엘리먼트.

◦ SOAP 메시지 처리하는데 필요한 추가 정보를 기술한다. (인증 정보, 세션, 트랜잭션 등)

◦ 바디 엘리먼트에서 인코딩하기 힘든 데이터를 전달할 때 이용한다. (예를 들어, 압축메시지를 풀기 위한 알고리즘...)

◦ Header 요소를 사용하는 경우
    1) 인증 (Authentication)
        : 수신받은 메시지를 사용하기 전 허가된 전송자가 송신한 메시지인지 확인해야 하는 경우 사용한다.
    2) 보안 (Sercurity degest information)
        : 메시지를 수신하는 입장에서는 수신메시지가 훼손되지 않은 상태임을 보장받고 싶어한다.
          이 경우, 전송자는 디지털 서명을 메시지 본문에 전송하고 digest 를 헤더에 포함해 보낸다.
    3) 정보 라우팅 (Routing information)
        : 메시지를 전송해야 할 곳이 많다면 헤더에 그 리스트 및 순서를 포함할 수 있다.
    4) 트랜잭션 (Transaction)
        : 메시지를 수신한 쪽에서 어떤 행위를 수행할 때 송신측의 트랜잭션 범주 내에 포함되어야 하는 경우 사용한다.
    5) 지불 정보 (Payment information)
        : 서비스 호출 단위로 그 사용료를 지불하는 경우라면 지불 정보 수집에 필요한 정보를 헤더에 포함시킬 수 있다.
 

◦ Attribute

1)     actor

-         해당 Header 블록을 누가 처리해야 하는지 지정.

-         지정된 경우 : actor 어트리뷰트에 지정된 노드가 SOAP Header 블록을 처리

-         지정되지 않은 경우 : SOAP 메시지의 최종 수신자가 처리

2)       mustUnderstand

-         Header에 포함된 내용이 반드시 처리되어야 하는지 지정.

-         값이 1 일 때 : 반드시 처리

-         값이 0 일 때 : 처리하지 않아도 무방.

3)        

◦ 예제

▷ <env:Body>

◦ Web Service 를 이용하기 위한 실제 메시지 기술.

-         서비스 호출, 응답에 관련된 내용

-         웹 서비스 수행 후, 에러 있을 때 SOAP Fault 를 기술한다.

◦ Attribute

1)       encodingStyle : 인코딩 타입 지정.

-         데이터 타입이 사용된 엘리먼트의 어트리뷰트로 선언한다.

-         SOAP 1.1 의 인코딩 규칙 : http://schemas.xmlsoap.org/encoding/

-         SOAP 1.2 의 인코딩 규칙 : http://www.w3.org/2001/09/soap-encoding

◦ 예제

▷ <env:Fault>

◦ <env:Body> 엘리먼트의 하위 엘리먼트.

◦ SOAP 문서 처리 할 때 에러가 발생할 경우, 그 내용을 기술한다.

◦ 작성

 
* 예제
SOAP_request

POST /axis/services/axisTest HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: 127.0.0.1:1234
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: ""
Content-Length: 934

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>
<ns1:example soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://classArrayTest.ex">
<in0 soapenc:arrayType="xsd:int[2]" xsi:type="soapenc:Array" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
<in0 href="#id0"/>
<in0 href="#id1"/>
</in0>
</ns1:example>

<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:int" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">4</multiRef>

<multiRef id="id1" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:int" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">9</multiRef>

</soapenv:Body>

</soapenv:Envelope>

SOAP_response

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Mon, 19 Nov 2007 05:53:00 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>
<ns1:exampleResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://classArrayTest.ex">
<exampleReturn href="#id0"/>
</ns1:exampleResponse>

<multiRef id="id0" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:A" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns2="http://classArrayTest.ex">
<a href="#id1"/>
<b href="#id2"/>
</multiRef>

<multiRef id="id2" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:int" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">9</multiRef>

<multiRef id="id1" soapenc:root="0" soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:int" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">4</multiRef>

</soapenv:Body></soapenv:Envelope>

<REFERENCE>
http://blog.naver.com/semi7623?Redirect=Log&logNo=100005637477

http://blog.naver.com/cycle98/140001019681
http://blog.naver.com/chjs22?Redirect=Log&logNo=60035982706

소설같은XML & XML Web Services 

웹서비스란

• 웹 서비스는 네트워크 상에서 상호 운용 가능한 소프트웨어 컴포넌트들이다

웹서비스 아키텍처

• client와 server 사이에 통신을 하기 위해서
• service Provider는 UDDI에 등록
• Client는 UDDI을 이용하여 탐색 & 서비스 정보

SOAP(Simple Object Access Protocol)

• wsdl에서 설명하는 것을 기반으로
• 클라이언트와 서버 간에 서로 통신하는 메시징 프로토콜을 발한다.
• 서버는 Axis Engine을 이용해서 SOAP을 통해 들어온 메시지를 해석 한다.

• 구성

  • Envlelop - 필수

    • SOAP Part

      • Header - 옵션 => 서비스에 대한 부가적인 정보(트랜잭션, 보안, 신뢰성 문제 등)
      • Body - 필수 => 서비스 호출에 대한 정보,.

    • Attachment Part

      • Attchment 들 - 옵션 => 첨부 파일들(바이너리 정보)
• SOAP의 바탕은 WSDL 이다.

WSDL(Web Services De

• 구성요소

  • Service
  • Port
  • Blinding
  • Port type : 인터페이스 선언 => 인터퍼이스로 변환
  • Operation : 함수 선언 => 함수로 변환
  • Message : 함수 인자 선언 => 함수의 인자들
  • Types : 데이터 타입 선언 => 실제적인 데이터 타입

웹 서비스 표준 현황

• 표준을 정하는 단체에 참여하는 단체에서 책정한 표준 스팩들
• UDDI, SOAP(메시지 프로토콜(어플리케이션 단)), WSDL(설명) => 1세대

• 1세대 만으로도 기업용을 사용할 수 없고(트랜잭션 처리 불가능), XML의 보안이 취약함

  • WS-* 단들 : WS-Security. WS-Transaction, WS-Coordination ...
  • 기업체 환경에 적용하기 위한 부과적인 스팩들 => XML 문서로 정의
• BPEL4WS : 흔히 BPEL, 서로 다른 이기종 및 웹 서비스에 대해서 각각의 서비스를 모델링을 통해 하나의 서비스로 조합시키는 것

웹 서비스 보안

• WS-Security를 통하여 지원

WSDL

• types : 실질적인 데이터의 정의
• message : 메소 인자 정의
• portType : 메소드 정의
• binding : 어떤 통신 프로토콜을 통해서 통신을 할 것인지 정의
• service : 클라이언트 단에 제공하기 위해, 처음 호출시 해당 주소를 호출해라. 또한 어떤 서비스를 하는 지 알려 준다.
• xml 자체가 xsd를 통하여 재작

• WSDL이란

  • 서비스의 외부 인터페이스를 표현,
  • CORBA, COM+(ATL)의 IDL에 해당

• WSDL 읽는 방법

  • targetNamespace : 해당 WSDL의 고유한 키. definitions 에서 정의
  • definitions에서는 또한 긴 targetNamespace에 대신에 축약하여 사용할 수 있는 것을 정의할 수 있다.
  • 맨 아랫단부터 service -> binding - > portType -> message -> types 로 올라가면서 찾는다.

• 웹서비스 Stub 생성 : 하부 단에서 local을 호출하지만, 다른 머신의 것을 호출하게 하는 것(RMI)

  • <types> : 문서에서 사용되고 있는 데이터형의 정의 : Class
  • <message> : 서비스가 사용하는 메시지를 정의 : Method Parameter Or Return type
  • <operation> : 서비스의 함수에서 사용되는 요청/ 응답 메시지 저의 : Method
  • <portType> : 여러 오퍼레이션의 묶음 : class
  • <binding> : 포트형과 네트워크 호출 프로토콜
  • <service><port>

• WSDL Document/RPC

  • 통신 방법에 대한 정의 : binding 에서 정의 되어 있다. <soap:binding style="">, soap 메시지가 가는 형식

  • style

    • document : 문서 자체가 가는 개념
    • RPC : 명시적으로 어떤 오퍼레이션을 호출하겠다는 개념

  • use

    • literal
    • Encoded
  • 현재 많이 사용하는 방식 : document/literal 와 document/literal/wrapper 방식을 주로 사용한다. (style/use)
  • 트랜스포트에 독립적이므로 WS-Addressing을 이용해서 정의한다(중요하지 않음.. - 지금은)

서비스 제작 방식

• Top-Down : WSDL을 기반으로 java 파일 생성
• Bottom-Up : java 파일을 기반으로 WSDL를 생성

SOAP

• document/literal 방식은 : 바로 입력하는 형태로 되어 있다 => TYPE 타입을 참조
• document/literal/wrapper 방식은 : 입력하는 것을 한 번더 감싸서 정보를 입력한다. => TYPE 타입을 참조
• RCP/literal 방식 : operation - parameter 를 주어서 호출하는 방법  => PORT 타입을 참조
• WS-Addressing : 주소 결정 방식.. (아직 여기 까지 진전되지 않았다.. => 아직는 독립적이지 못하다.. HTTP 에 종속적..)

[출처] WebService, SOAP, WSDL 설명|작성자 나무늘보

http://cafe.naver.com/toadsoft.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=364

토드를 처음 접했을 때의 느낌은 "정말 편리하다" 였다.
이유는 SQL*NET에서 명령어 또는 SQL에 익숙해져 있었기 때문이다.

하지만 부서에서는 토드를 쓰면 실력이 없는 사람, 명령어를 사용하면 실력이 있는 사람이라는 분위기여서 사용하고 싶었지만 쉽사리 사용하기 어려웠다.
토드는 계속해서 버전 업이 되었지만 나는 여전히 7.3을 사용하고 몰래 몰래 사용하고 있었다.

시간이 흐르면서 회사에서도 점차 개발생산성, 편리성, 업무간소화, 표준화에 초점이 맞춰지고, 토드를 도입하게되어 자연스럽게 토드를 공식적으로(?)사용하게 되었다.

하지만 대부분의 사람들이 토드에 대해 평하기를 토드는 편리하지만 많은기능을 어디에 어떻게 사용하는지 모르겠다는 것 이었다.

개발과 DBA를 같이 하는 나로써는 토드의 많은 기능을 사용하고 싶었다.
때로는 여기 저기 질문해 보고 한글 매뉴얼도 구해서 사용했지만 여전히 부족하다는 느낌을 받았다. 기능을 알게 되어도 어떻게 이용하는지 궁금했었다.

이 문제는 작년에 토드 교육을 통해 대부분 해소 되었다.

하지만 “테이블을 생성하는 창은 어디에 있지?” 등 자주 쓰지 않는 기능은 찾기 힘들었다.
그런데 결국 9.0에서 이러한 부분을 해결해 주었다.

A. 변화된 내용  

1.       로그인 창의 변화

토드9.0을 실행하면 가장 먼저 나타나는 창이 로그인 창이다.

얼핏 보면 변한게 없어 보이는데, 오라클 서버와 통신하기 위해 3가지 접근 방법을

제공한다.

-         TNS : 일반적인 통신방법으로 서버스명을 통해 오라클 서버와 통신하는 방법

-         Direct : IP Address를 통해 오라클 서버와 통신하는 방법

-         LDAP : LDAP환경하에서 LDAP쿼리를 이용하여 오라클 서버와 통신하는 방법

2.       각종 Editor 통합

SQL Editor, Procedure Editor 창은 사라지고 Editor이란 메뉴만 있어 의아하게 생각했으나, Editor창을 열어보니

 Style이라는 선택옵션이 있었다. 예전에 SQL Editor와 Procedure Editor을 동시에 띄어 놓고 작업할 경우 상당히

복잡했는데, 하나의 창에서 페이지 탭이 추가되는 방식으로 작업할 수 있어 매우 편리하다는 느낌을 받았다.

이 밖에도 Text, XML, Hex 형식을 작성 및 편집도 가능하며, 이전 버전에서 반드시 로그인을 해야만 해당 창을 띄울 수 있었는데 로그인 없이도 실행이 가능하다. 물론 SQL문장을 실행할 경우 반드시 로그인은 필요하다.

3.       Excel 변환시 한글깨지는 현상 해결

토드 8.6 버전까지 쿼리한 결과 Excel로 변환시 한글데이타가 깨지는 현상이 발생했다.

물론 Excel 변환시 Export Format를 XSL Instance로 선택한 후 변환하면 한글깨짐 현상이

피할 수 있었으나, 토드9.0에서는 한글과 관련하여 “Write Wide Strings”라 별도의 옵션을 제공하며, 이 옵션을 체크하면 한글데이타가 정상적으로 변환된다.

4.       파일자동 복구 기능

토드가 갑자기 실행을 멈추게 되어 강제 종료된 경우에 작성하던 SQL문장을 날리게 되어 사용자들이 불만이 많았던 것으로 알고 있다. 토드9.0에서 이러한 문제를 파일자동 복구 기능을 구현함으로써 해결하였다.

토드가 갑자기 중단된 경우 재 실행하면 파일 복원 화면이 나타나면서 중단되기전에 작성되었던 SQL구문을 자동으로 복원해 준다.

물론 토드가 죽지 않게 만드는 게 좋겠지만 많은 기능들로 인하여 부하가 심한 것이 사실이고 이로 인해 죽지 않게 만들 수 없다면, 자동 복구 기능은 이에 대한 대안으로 충분한 듯 하다.

5.       Code Folding 기능

토드9.0에서는 코드 접기 기능이 새롭게 추가 되었다.

일반적으로 닷넷 개발툴에 볼 수 있는 기능으로 코딩 블록을 구분하기 쉽고, 블록내의

소스코드를 감출 수 있어 코딩 내용을 쉽게 파악할 수 있는 장점이 있다.

6.       DBA기능에 대한 메뉴 그룹화

DBA모듈을 추가 구매하면 DBA와 관련된 메뉴들이 상당히 많은데, 이전 버전에서는

각 기능들이 아무렇게나 나열되어 있어, 필요할 때 바로 찾는데 매우 불편했다.

그러나 토드9.0에서는 관련성있는 메뉴별로 그룹화하여 구성해 놓았기 때문에 매우 편리한것 같다.

예를 들어 관리자들이 해야 할 작업들(감사, 권한부여, 파라미터 설정,..등)을 Administer 메뉴로 그룹하여 해당 업무별로 쉽게 찾을 수 있도록 배려한 것 같다.

7.       Report Manager 추가

토드9.0에서 추가된 메뉴 중 Report manager이란 기능이 있는데, 이전 버전에서 사용자들이 오라클 정보를 출력하고자 할 때 특별한 기능이 없어 고민을 많이 하였고, 이를 해결할 수 있는 기능을 추가해 줄 것을 Quest Software에 요청했었는데, 토드9.0에서 Report Manager란 기능을 추가함으로써 사용자 요구를 반영한 듯 하다.

Report Manager을 실행하면 오라클과 관련된 정보를 출력할 수 있도록 많은 템플릿을 제공한다. 사용자들은 이 템플릿을 이용하여 오라클 정보와 관련된 내용들을 쉽게 출력할 수 있으며 사용자들의 입맛에 맞게 추가 및 수정하여 사용할 수도 있다.

8.       Toad 옵션 통합

토드9.0에서는 이전 버전에서 있었던 토드 일반옵션과 Edit옵션을 통합하였다.

이전 버전에서 토드 옵션을 찾으려면 어떤 옵션창을 열어 찾아야 할지 몰라 고민도 많았는데 하나의 창으로 통합되어 옵션 찾기가 쉬어진 듯 하다.

 끝으로,

즉, 많은 기능을 추가하기 보다는 사용자의 편리성에 중점을 두어 기능은 많지만  어디에 어떻게 사용하는 지 알기 어렵다는 오명을 벗은 것 같다.

$nm -X비트수 파일명

nm [ -a | --debug-syms ]  [ -g | --extern-only ]
   [ -B ]  [ -C | --demangle[=style] ] [ -D | --dynamic ]
   [ -s | --print-armap ]  [ -A | -o | --print-file-name ]
   [ -n | -v | --numeric-sort ]  [ -p | --no-sort ]
   [ -r | --reverse-sort ]  [ --size-sort ] [ -u | --undefined-only ]
   [ -t radix | --radix=radix ] [ -P | --portability ]
   [ --target=bfdname ] [ -f format | --format=format ]
   [ --defined-only ] [-l | --line-numbers ]  [ --no-demangle ]
   [ -V | --version ]  [ -X 32_64 ]  [ --help ]  [ objfile... ]

GNU nm lists the symbols from object files objfile.... If no object files are listed as arguments, nm assumes the file `a.out'.

For each symbol, nm shows:

GNU nm은 오브젝트 파일 objfile...의 심볼을 출력한다. 아규먼트로 어떤 오브젝트 파일도 사용하지 않으면 `a.out'을 가정한다.

• The symbol value, in the radix selected by options (see below), or hexadecimal by default.
  심볼 값은 아래 설명할 옵션에서 지정한 진수로 출력한다. 기본값은 16 진수이다.
• The symbol type. At least the following types are used; others are, as well, depending on the object file format. If lowercase, the symbol is local; if uppercase, the symbol is global (external).
  심볼 타입. 최소한 다음 타입들이 사용된다. 나머지는 오브젝트 파일 형식에 따라 다르다. 소문자는 심볼이 지역 심볼임을, 대문자는 심볼이 전역 (외부) 심볼임을 나타낸다.

  A

  The symbol's value is absolute, and will not be changed by further linking.
  심볼 값이 절대적이여서, 더 링크를 해도 변경되지 않는다.

  B

  The symbol is in the uninitialized data section (known as BSS).
  심볼이 (BSS라 부르는) 초기화되지않은 자료 섹션에 저장된다.

  C

  The symbol is common. Common symbols are uninitialized data. When linking, multiple common symbols may appear with the same name. If the symbol is defined anywhere, the common symbols are treated as undefined references. For more details on common symbols, see the discussion of --warn-common in section `Linker options' in The GNU linker.
  심볼이 공통 심볼이다. 공통 심볼은 초기화되지않은 자료이다. 링크시 같은 이름을 가진 여러 공통 심볼이 가능하다. 심볼이 어디에도 정의되지 않았다면 공통 심볼은 정의되지 않은 참조로 취급된다. 공통 심볼에 자세히 알려면, The GNU linker의 `Linker options'에서 --warn-common 옵션 설명을 참고하라.

  D

  The symbol is in the initialized data section.
  심볼이 초기화된 자료 섹션에 위치한다.

  G

  The symbol is in an initialized data section for small objects. Some object file formats permit more efficient access to small data objects, such as a global int variable as opposed to a large global array.
  심볼이 크기가 작은 객체를 위한 초기화된 자료 섹션에 위치한다. 몇몇 오브젝트 파일 형식은 (큰 전역 배열에 대응되는 전역 정수 변수와 같이) 작은 자료 객체를 더 효율적으로 접근할 수 있다.

  I

  The symbol is an indirect reference to another symbol. This is a GNU extension to the a.out object file format which is rarely used.
  심볼은 다른 심볼로의 간접 참조이다. 이는 거의 사용되지 않는 a.out 오브젝트 파일 형식에서 대한 GNU 확장이다.

  N

  The symbol is a debugging symbol.
  심볼이 디버그 심볼이다.

  R

  The symbol is in a read only data section.
  심볼이 읽기 전용 섹션에 있다.

  S

  The symbol is in an uninitialized data section for small objects.
  심볼이 작은 객체를 위한 초기화되지않은 자료 섹션에 있다.

  T

  The symbol is in the text (code) section.
  심볼이 텍스트 (text, 코드) 섹션에 있다.

  U

  The symbol is undefined.
  심볼이 정의되지 않았다.

  V

  The symbol is a weak object. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error.
  심볼은 약한 객체이다. 약한 객체가 정의된 심볼과 링크되면 오류없이 정의된 심볼이 사용된다. 정의되지않은 약한 심볼이 링크될 때 정의된 심볼이 없다면 오류없이 약한 심볼 값은 0이 된다.

  W

  The symbol is a weak symbol that has not been specifically tagged as a weak object symbol. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error.
  심볼은 명시적으로 약한 객체 심볼이라고 표시되지 않은 약한 심볼이다. 약한 객체가 정의된 심볼과 링크되면 오류없이 정의된 심볼이 사용된다. 정의되지않은 약한 심볼이 링크될 때 정의된 심볼이 없다면 오류없이 약한 심볼 값은 0이 된다.

  -

  The symbol is a stabs symbol in an a.out object file. In this case, the next values printed are the stabs other field, the stabs desc field, and the stab type. Stabs symbols are used to hold debugging information; for more information, see section `Stabs Overview' in The "stabs" debug format.
  심볼은 a.out 오브젝트 파일에서 stabs 심볼이다. 이 경우 다음으로 출력되는 값은 stabs other 필드, stabs desc 필드, stab 타입이다. stabs 심볼은 디버깅 정보를 저장한다. The "stabs" debug format의 `Stabs Overview'을 참고하라. (역주; 이 문서는 GNU GDB 소스코드에 포함되있다.)

  ?

  The symbol type is unknown, or object file format specific.
  알 수 없거나 오브젝트 파일 형식에 의존하는 심볼 타입.

• The symbol name.
  심볼 이름.

The long and short forms of options, shown here as alternatives, are equivalent.
같이 설명하는 긴 형식과 작은 형식의 옵션은 동일하다.

-A

-o

--print-file-name

Precede each symbol by the name of the input file (or archive member) in which it was found, rather than identifying the input file once only, before all of its symbols.
심볼들 앞에 한번만 입력파일을 출력하지 않고, 각 심볼 앞마다 심볼이 발견된 입력파일 이름을 (혹은 아카이브 멤버를) 출력한다.

-a

--debug-syms

Display all symbols, even debugger-only symbols; normally these are not listed.
보통 출력하지 않는 디버거용 심볼을 포함하여 모든 심볼을 출력한다.

-B

The same as `--format=bsd' (for compatibility with the MIPS nm).
(MIPS nm과 호환을 위해) `--format=bsd'와 동일하다.

-C

--demangle[=style]

Decode (demangle) low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes C++ function names readable. Different compilers have different mangling styles. The optional demangling style argument can be used to choose an appropriate demangling style for your compiler. See section c++filt, for more information on demangling.
저수준 심볼 이름을 사람이 알아볼 수 있게 풀어쓴다(디맹글링). 시스템에서 앞에 붙인 `_'을 제거하는 것 외에 C++ 함수 이름도 풀어쓴다. 컴파일러 마다 다른 맹글링 형식을 사용한다. 선택적인 디맹글링 형식 아규먼트는 컴파일러에 해당하는 디맹글링 형식을 선택한다. 디맹글링에 대해서는 c++filt을 참고하라.

--no-demangle

Do not demangle low-level symbol names. This is the default.
저수준 심볼 이름을 디맹글링하지 않는다. 이것이 기본 행동이다.

-D

--dynamic

Display the dynamic symbols rather than the normal symbols. This is only meaningful for dynamic objects, such as certain types of shared libraries.
보통 심볼이 아니라 동적 심볼을 출력한다. 이는 공유 라이브러리와 같은 동적 객체에만 의미가 있다.

-f format

--format=format

Use the output format format, which can be bsd, sysv, or posix. The default is bsd. Only the first character of format is significant; it can be either upper or lower case.
출력 형식으로 format을 사용한다. 출력 형식에는 bsd, sysv, posix을 사용할 수 있다. 기본값은 bsd이다. 형식은 format의 첫 문자만 보고 결정한다. 대소문자 모두 가능하다.

-g

--extern-only

Display only external symbols.
외부 심볼만 출력한다.

-l

--line-numbers

For each symbol, use debugging information to try to find a filename and line number. For a defined symbol, look for the line number of the address of the symbol. For an undefined symbol, look for the line number of a relocation entry which refers to the symbol. If line number information can be found, print it after the other symbol information.
각 심볼에 대응하는 파일명과 줄 번호를 찾기 위해서 디버깅 정보를 이용한다. 정의된 심볼은 심볼 주소에 대응하는 줄 번호를 찾는다. 정의되지 않은 심볼은 심볼을 참조하는 재배치 항목의 줄 번호를 찾는다. 줄 번호 정보가 발견되면 다른 심볼 정보 뒤에 출력한다.

-n

-v

--numeric-sort

Sort symbols numerically by their addresses, rather than alphabetically by their names.
심볼의 이름이 아니라 주소로 심볼을 정렬한다.

-p

--no-sort

Do not bother to sort the symbols in any order; print them in the order encountered.
심볼을 정렬하지 않는다. 발견되는 순서대로 출력한다.

-P

--portability

Use the POSIX.2 standard output format instead of the default format. Equivalent to `-f posix'.
기본 출력 형식 대신에 POSIX.2 표준 형식을 사용한다. `-f posix'와 같다.

-s

--print-armap

When listing symbols from archive members, include the index: a mapping (stored in the archive by ar or ranlib) of which modules contain definitions for which names.
아카이브 멤버에서 심볼을 출력할 때, 어떤 모듈이 어떤 이름의 정의를 포함하는지 (ar나 ranlib로 아카이브에 저장한) 대응도 출력한다.

-r

--reverse-sort

Reverse the order of the sort (whether numeric or alphabetic); let the last come first.
(숫자순이나 문자순이나) 정렬 순서를 반대로 한다. 뒤의 것이 앞에 오게 한다.

--size-sort

Sort symbols by size. The size is computed as the difference between the value of the symbol and the value of the symbol with the next higher value. The size of the symbol is printed, rather than the value.
크기로 심볼을 정렬한다. 크기는 심볼 값과 다음으로 값이 큰 심볼 값의 차이로 계산된다. 심볼 값 대신 심볼의 크기가 출력된다.

-t radix

--radix=radix

Use radix as the radix for printing the symbol values. It must be `d' for decimal, `o' for octal, or `x' for hexadecimal.
심볼 값을 출력하는 진수로 radix을 사용한다. `d'는 10 진수, `o'는 8 진수, `x'는 16 진수를 나타낸다.

--target=bfdname

Specify an object code format other than your system's default format. See section Target Selection, for more information.
시스템 기본 오브젝트 형식 대신 다른 형식을 지정한다. Target Selection를 참고하라.

-u

--undefined-only

Display only undefined symbols (those external to each object file).
정의되지 않은 (외부) 심볼만 출력한다.

--defined-only

Display only defined symbols for each object file.
각 오브젝트 파일에서 정의된 심볼만 출력한다.

-V

--version

Show the version number of nm and exit.
nm 버전을 출력하고 종료한다.

-X

This option is ignored for compatibility with the AIX version of nm. It takes one parameter which must be the string 32_64. The default mode of AIX nm corresponds to -X 32, which is not supported by GNU nm.
이 옵션은 AIX의 nm와 호환을 위한 것으로 무시된다. 이 옵션은 한 파라미터를 받으며, 그 파라미터는 32_64이어야 한다. AIX nm의 기본값은 GNU nm이 지원하지 않는 -X 32이다.

Sub changeFile()
    For i = 8 To ActiveWorkbook.Sheets.Count
        Worksheets(i).Select
        changeSheet (i)
    Next i
   
    'makeIndex
    deleteHeader
End Sub

Sub makeIndex()
    Worksheets(2).Select
   
    For i = ActiveWorkbook.Sheets.Count To 4 Step -1
        Rows("2:2").Select
        Selection.Copy
        Selection.Insert Shift:=xlDown
       
        Range("F3").Activate
        ActiveCell.FormulaR1C1 = Worksheets(i).Name
    Next i
End Sub

Sub changeSheet(idx As Integer)
   
    '레이아웃 편집
    Rows("1:2").Select
    With Selection
        .MergeCells = False
    End With
    Columns("A:A").Select
    Range("A2").Activate
    Selection.Delete Shift:=xlToLeft
    Columns("B:C").Select
    Selection.Insert Shift:=xlToRight
    Columns("F:F").Select
    Range("F3").Activate
    Selection.Insert Shift:=xlToRight
    Columns("I:J").Select
    Range("I3").Activate
    Selection.Insert Shift:=xlToRight
    Columns("M:Q").Select
    Selection.Insert Shift:=xlToRight
    Columns("M:Q").Select
    Selection.ColumnWidth = 2.3
    Range("B3").Select
    '속성정보 편집
    Columns("G:G").Select
    Range("G5").Activate
    Selection.Replace What:="X", Replacement:="C", LookAt:=xlPart, _
        SearchOrder:=xlByRows, MatchCase:=False, SearchFormat:=False, _
        ReplaceFormat:=False
    Selection.Replace What:="9", Replacement:="N", LookAt:=xlPart, _
        SearchOrder:=xlByRows, MatchCase:=False, SearchFormat:=False, _
        ReplaceFormat:=False
    Columns("B:C").Select
    Selection.ColumnWidth = 3
    Columns("E:E").Select
    Selection.Copy
    Columns("D:D").Select
    Selection.Insert Shift:=xlToRight
    Columns("F:F").Select
    Selection.Delete Shift:=xlToLeft
    Columns("A:A").Select
    Selection.ColumnWidth = 3
    Columns("B:C").Select
    Selection.ColumnWidth = 6
    Columns("D:E").Select
    Selection.ColumnWidth = 20
    Columns("F:K").Select
    Selection.ColumnWidth = 3
    Columns("L:L").Select
    Selection.ColumnWidth = 35
    Columns("R:R").Select
    Selection.ColumnWidth = 15
   
    '비고필드 자동줄바꿈
    Columns("R:R").Select
    Range("R2").Activate
    With Selection
        .VerticalAlignment = xlCenter
        .WrapText = True
        .Orientation = 0
        .AddIndent = False
        .ShrinkToFit = False
        .ReadingOrder = xlContext
    End With
   
    '첫번째시트에서 타이틀 카피
    Worksheets(1).Select
    Rows("1:7").Select
    Range("A7").Activate
    Selection.Copy
    Worksheets(idx).Select
    Rows("1:1").Select
    Selection.Insert Shift:=xlDown
    '타이틀 편집
    Range("E2:H2").Activate
    ActiveCell.FormulaR1C1 = "재무"
    Range("E3:H3").Activate
    ActiveCell.FormulaR1C1 = ""
    Range("A9").Select
    Selection.Copy
    Range("A9").Select
    Range("E4:H4").Select
    ActiveSheet.Paste
    Range("L4").Select
    ActiveCell.FormulaR1C1 = ""
    Range("R2").Select
    ActiveCell.FormulaR1C1 = "재무"
    Range("R3").Select
    ActiveCell.FormulaR1C1 = ""
    Range("R4").Select
    ActiveCell.FormulaR1C1 = Worksheets(idx).Name
    Rows("8:10").Select
    Selection.Delete Shift:=xlToUp
   
    Columns("A:A").Select
    Range("A1").Activate
    With Selection.Font
        .Size = 10
        .Strikethrough = False
        .Superscript = False
        .Subscript = False
        .OutlineFont = False
        .Shadow = False
        .Underline = xlUnderlineStyleNone
    End With
    ActiveWindow.Zoom = 85
   
End Sub

Sub deleteHeader()
    For i = 8 To ActiveWorkbook.Sheets.Count
        Worksheets(i).Select
        Rows("8:21").Select
        Selection.Delete Shift:=xlToUp
       
        Range("A8").Select
        ActiveCell.FormulaR1C1 = "1"
    Next i
End Sub

Sub copyValue()

'값만 copy

    Range("A600").Activate

     Cells.Select

    Selection.Copy

    Range("A1").Select

    Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, SkipBlanks _

        :=False, Transpose:=False

    Range("A1").Select

    Application.CutCopyMode = False

    Range("s1").Select

End Sub

Sub copyValueSheet()

    For i = 8 To ActiveWorkbook.Sheets.Count

        Worksheets(i).Select

        copyValue

    Next i

End Sub

Sub all()

    For i = 8 To ActiveWorkbook.Sheets.Count

        Worksheets(i).Select

        copyValue

        editForm

    Next i

End Sub

Sub editSheet()

    For i = 8 To ActiveWorkbook.Sheets.Count

        Worksheets(i).Select

        editForm

    Next i

End Sub

Sub editForm()

    Columns("B:B").Select

    Selection.Delete Shift:=xlToLeft

    Columns("F:K").Select

    Selection.Delete Shift:=xlToLeft

    Columns("H:H").Select

    Selection.Delete Shift:=xlToLeft

    Columns("I:I").Select

    Selection.Delete Shift:=xlToLeft

    Columns("J:J").Select

    Selection.Delete Shift:=xlToLeft

    Columns("s:S").Select

    Selection.Delete Shift:=xlToLeft

    rowNumbering

End Sub

Sub rowNumbering()

'마지막 row까지

    For i = 8 To Range("A8").End(xlDown).Row

        Range("A" & i).Activate

        ActiveCell.FormulaR1C1 = i - 7

    Next i

End Sub

Glance 란?

Option

Command List

Examples

Base Case 1

FaQ , QnA

http://www.ihelpers.co.kr/programming/qna.php?CMD=view&IDX=8466

1. 가장 많은 원인은 서버의 Oracle 쉐도 프로세스가 예기치 않게 종료된 경우 입니다. 따라서 수행중에 갑자기 ORA-3113과 3114가 발생했다면, 우선 서버의 alert.log를 점검하여 다른 Oracle 오류가 발생했는지 알아보십시요.

<< alert.log >> 서버가 UNIX 인경우 $ORACLE_HOME/rdbms/log/alert_.log 화일에 ORA-3113 에러가
발생했던 시점에서 다른 에러가 발생했는지 점검 합니다. 특히 ORA-600[],[]이 발생했으면 에러 내용을 Oracle Technical Support Center로
연락 하십시오.

2. ORA-3113의 원인 중 그 다음으로 많은 것은 SQL*NET 드라이버가 Unix의 ORACLE 실행 파일과 연결되지 않아 발생한 경우입니다. 연결을 공식적으로 수신하고 그것을 ORACLE 쉐도 프로세스에 전달한다 해도, 쉐도 프로세스는 처리방법을 모르기 때문에 어떤 방법으로도 응답하지 못할 수 있습니다. 그러므로 클라이언트는 연결순간에 ORA-3113을 보게 됩니다.

3. 세번째로 많은 원인은 서버쪽의 기계 손상이나 네트워크 고장입니다.

4. 자주 있는 것은 아니지만 같은 네트워크에서 두 서버가 같은 노드 이름을 가질 때에도 이 오류가 발생합니다.

5. ORA-3113은 토큰링 카드의 공유 RAM 크기가 16KB가 아니라 8KB로 설정 되었음을 나타내기도 합니다. 토큰 링을 사용중이라면 공유 버크 크기를 점검하고 키워 보십시요.

6. ORA-3113은 INIT.ORA 매개변수 CONTEXT_AREA와 CONTEXT_INCR이 4096이라는 값으로 설정된 경우에도 발생합니다. 그럴때는 값을 8192로 키우면ORA-3113이 해소됩니다.

이상 말한 모든 원인은 결국 클라이언트가 서버로부터 어떤 정보를 읽으러 갔다가 거기서 더 이상 연결이 없음을 발견했다는 뜻입니다. ORA-3113은 좀 더 진단해야 추적 가능한 더 큰 문제가 있음을 알리는 신호탄에 불과합니다. 다행히도 앞서 말한 여섯가지 정보를 참고하면 해결책을 찾는 방향은 잡힐 것입니다.
우선 ORA-3113을 디버깅하려면, 루프백을 수행중에 같은 CONNECTING을 여러번 시도해 보는 것이 좋습니다. 즉, 서버의 어떤 툴이든 데스크탑 클라이언트에서 지정하는 것과 같은 연결 스트링을 사용하여 연결할 수 있습니다. 루프백을 수행중에도 똑같은 문제가 발생하면 데스크탑 클라이언트 쪽이 아니라
서버쪽에 문제가 있다고 보아야 합니다. 루프백을 수행하려면 서버에서 SQLPLUS 또는 SQLDBA를 호출하고, 서버의 SQLPLUS 또는 SQLDBA 프롬프트에서 다음과 같이 입력하십시요.

　CONNECT USERNAME/PASSWORD@t:/:

예를 들어, SQL*NET TCP/IP를 통해 Unix 서버에 연결돼 있고 SQL*Plus를 호출하고, 같은 "t::" 연결 스트링을 사용하여, 같은 SELECT 문을 내서 루프백을 해 보십시요.


/*두번째자료*/

ORA-3113의 의미는 클라이언트에서 서버에 대한 접속을 갑작스럽게 잃어 버릴 때에 발생하며 대부분의 경우 서버에서 클라이언트의 접속을 kill하는 경우이다.
이 에러는 주로 서버 장비의 데이타베이스 또는 SQL*NET LISTENER(서버측)의 문제이므로 초기에는 클라이언트측은 무시하고 대신 서버측을 조사해 보아야 한다
드문 경우이긴 하지만 이 것은 클라이언트의 memory나 resource의 부족으로 발생 할수도 있고, DLL 버젼이 서로 맞지 않아 발생하기도 한다. 그러나 이런 경우는 극히 드물다.

1. Server side

첫번째로는 사용자의 DBA에게 도움을 요청한다. 그런 다음 사용자의 응용 프로그램에서 ORA-3113 에러를 재현한다. DBA에게 요청하여 데이타베이스의
alert.log와 trace file을 보고, ORA-3113절에 에러와 동시에 나오는 다른 내용이 있는지를 확인한다.
예로 만일 클라이언트가 ORA-3113에러를 얻게 되면 매번 trace 화일 생성 하거나, 또는 alert.log화일내에 ORA-00600 에러가 남게 되는데 이는 데이타
베이스 또는 SQL*NET의 문제로 인해 생기는 것이다. 

2. Client Side
이 에러는 Windows 3.1에서는 아주 큰 문제이며, Windows 95에서는 문제가 덜 발생하며, Windows NT에서는 드물게 발생한다.

2.1 Memory 문제
2.1.1 Windows 3.1
Test를 하기 위해 Control Panel * 386Enh * Virtual Memory를 통해 Permanent swap file (temporary가 아님)을 생성한다. 특히 클라이언트와
서버 사이에서 매우 큰 data를 전달하는 경우 ORA-3113에러가 발생한다면 보다 큰 sizes로 swap size를 늘린다. 그리고 AUTOEXEC.BAT와 CONFIG.SYS
화일에서 memory에 상주시키는 불필요한 프로그램들은 제거 하도록 한다.

2.1.2 Windows 95
가능하다면 ALT-CTRL-DEL을 누르고 windows 95에 올라와 있는 여러 Tasks을 죽인후 operation을 다시 시도해 본다.
Permanent swap file을 증가시켜 보고 test를 하기 위해 설정 -> 제어판 -> 시스템 -> 성능 -> 가상메모리를 통해 Permanent swap file의 size를 증가시켜 본다.
특히 클라이언트와 서버 사이에서 매우 큰 data를 전달하는 경우 ORA-3113 에러가 발생 한다면 보다 큰 sizes로 swap size를 늘린다.

2.1.3 Windows NT
위의 Windows 95에서와 마찬가지로 Permanent swap file을 증가시킨다. 

2.2 DLL Version mismatch
2.2.1 SQL*NET과 Database의 버젼
Oracle Installer를 수행하여 현재 사용 중인 SQL*NET version을 점검하며 아래에 기술된 내용은 최소한 충족시켜 주어야 합니다.
(아래의 Version이 서로 맞지 않는다고 해서 사용할 수 없는 것은 아님)

 
=============================================
SQL*NET | RDBMS
=============================================
Ver 1 or Ver 2.0 | 7.0 또는 이후 버젼
Version 2.1 | 7.1 또는 이후 버젼
Version 2.2 | 7.2 또는 이후 버젼
Version 2.3 | 7.3 또는 이후 버젼
=============================================
 

2.2.2 OCI 사용자
만일 사용자의 프로그램이 OCIW32.DLL을 링크한다면 PC에 설치되어 있는 가장 최근의 RSF(Required Support File)을 로드할 것 이다.
또한 만일 데이타베이스 버젼 보다 PC에 새로운 RSF가 설치 되어 있는 상태 에서 데이타 베이스에 접속하기를 원한다면 그 것을 remove하고 가급적이면
데이타 베이스의 버젼(처음부터 최소한 2digit : 예로 데이타베이스 버젼이 7.3.2.3이라면 RSF는 최소한 V7.3.x)과 맞추는 것이 좋다.

2.2.3 ODBC 사용자
Oracle Web site(www.oracle.com/products/free_software)에 ODBC driver를 Free software로 올려 놓은 곳이 있으니 SQL*NET 버젼에 해당하는 ODBC Driver를 사용하시기 바란다.

2.2.4 기타
가능하다면 응용 프로그램에서 현재 사용하고 있는 SQL*NET의 버젼과 동일한 Required Support File의 버젼을 사용한다.

SQL*NET | RSF (Required Support File)
======================================================
V2.1 | V7.1
V2.2 | V7.2
V2.3 | V7.3
 
참고 : 3rd party 제품의 경우 Oracle에 접속하는 경우 자체 Native Database driver에서 요구 하는 ORACLE RSF의 버젼을 요구하는 경우도 있다.