Developments

[본문스크랩] SOAP v1.2

W3C

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분

정오표는 이 문서에 대한 공식적인 수정을 포함할 수 있다. 이를 참조해라.

이 문서의 영어 버전이 공식 버전이다. 비공식적인 번역본들이 가용할 수 있다.

Translated document may contain errors from translation.
이 번역본은 원본 문서에는 없지만, 번역 과정에서 발생한 오류를 포함할 수 있습니다. 번역 과정에서 생긴 오류를 발견하신 분은 guldook at gmail.com 으로 내용을 보내주시면 감사하겠습니다.


개요

SOAP Version 1.2 Part 0: Primer는, SOAP 버전 1.2 규격의 특징들을 쉽게 이해할 수 있는 튜토리얼을 제공하는 것을 목적으로 하는, 비공식적인 문서이다. 특히, 이 문서는 여러가지 사용 시나리오들을 통해서 특징을 설명하고 SOAP 1.2 규격의 Part 1Part 2에 포함된 공식 내용들을 보완하는 데 목적이 있다.

이 문서의 상태

이 절은 출판 시점에 이 문서의 상태를 설명한다. 다른 문서들이 이 문서를 대체할 수 있다. 이 문서의 최신 상태는 W3C에서 유지된다.

이 문서는 W3C의 권고안 이다. 이 문서는 XML Protocol Working Group에 의해 쓰여졌으며, Web Services Activity의 부분이다. 이 문서는 W3C 멤버들과 그 밖에 관심있는 참여자들에 의해 검토되었고, 의장(Director)에 의해 W3C 권고안으로 채택되었다. 이 문서는 확정된 문서이며 다른 문서에 공식적인 참조문서로써 사용될 수 있다. 권고안을 만드는 데 있어서 W3C의 역할은 규격에 대한 관심을 이끌어내고 폭넓은 적용을 촉진하는 것이다. 이것은 웹의 기능과 상호 운용성을 향상시킨다.

이 문서에 대한 의견을 환영한다. 의견은 공개 메일링 리스트 xmlp-comments@w3.org (아카이브)로 보내라. 이 주소로 토론 전자우편을 보내는 것은 적합하지 않다.

이 규격과 관련된 구현에 대한 정보는 http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html에 있는 구현 보고서에서 찾을 수 있다.

이 규격과 관련된 특허는 W3C 정책에 따라 워킹 그룹의 특허 공개 페이지에서 찾을 수 있다.

현재 W3C 권고안들과 다른 기술 보고서들은 http://www.w3.org/TR에서 찾을 수 있다.

목차

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 6SOAP 버전 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 네임스페이스 이름들과 관련된다.

이 문서의 섹션들에서 사용된 네임스페이스 접두어 “xs”와 “xsi”는 각각 “http://www.w3.org/2001/XMLSchema” 그리고 “http://www.w3.org/2001/XMLSchema-instance”와 관련된다. 둘다 XML Schema 규격들 [XML Schema Part1], [XML Schema Part2]에서 정의된다.

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

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

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 메시지들

예제 1SOAP 메시지로 표현된 여행 예약 데이터를 보여준다.

uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:20:00.000-05:00 Ake Jogvan Oyvind

New York

Los Angeles

2001-12-14

late afternoon

aisle

Los Angeles

New York

2001-12-20

mid-morning

none

헤더 블록과 본문을 포함한 여행 예약에 대한 SOAP 예제 메시지

예제 1에 SOAP 메시지는 전체 env:Envelope 내에 두 개의 SOAP 특화된 서브 엘리먼트들을 포함한다, 즉 env:Headerenv: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 메시지를 그림으로 설명한다.

Figure 1: SOAP 메시지 구조

예제 1에서 헤더는 두 가지 헤더 블록들을 포함한다, 각 블록은 그 자신의 XML 네임스페이스로 정의되고 SOAP 메시지의 body를 처리하는 전 과정과 관련된 특징을 표현한다. 이 여행 예약 어플리케이션에서, 모든 요청에서 유지되는 그런 “메타” 정보에 해당하는 것은, 특정 예약의 인스턴스를 지정하는 참조자와 타임스탬프를 제공하는 reservation 헤더 블록과 passenger 블록에 있는 여행자의 identity이다.

헤더 블록 reservationpassenger는 메시지 경로 상 다음에 있는 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 메시지를 보여준다. 이 응답은 요청에 있는 특정 정보 – 즉 출발 도시의 공항 선택 – 를 상세히 하고자 한다.

uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:35:00.000-05:00 Ake Jogvan Oyvind

JFK LGA EWR

JFK LGA EWR

예제 1에 있는 메시지의 응답으로써 보내진 SOAP 메시지

이전에 설명한 것처럼, env:Body는 XML 네임스페이스 http://travelcompany.example.org/reservation/travel의 스키마 정의를 따르는 메시지의 주요 컨텐츠 – 이 예제에서는 여러 가지 선택 가능한 공항 리스트를 포함하는 – 를 포함한다. 이 예제에서, 예제 1의 헤더 블록들은 (변경된 서브-엘리먼트 값들을 가진) 응답으로 리턴된다. 이것은 SOAP 수준에서의 메시지 상관성(correlation)을 제공할 뿐만 아니라, 다른 어플리케이션 특화된 사용 용도를 가질 가능성이 많다.

예제 1과 2의 메시지 교환은, 어플리케이션에서 정의한 스키마를 따르는 XML 기반 컨텐츠를 SOAP 메시지를 통해서 교환한 경우이다. 다시 한번, 그런 메시지들이 전달되는 수단에 대한 논의는 section 4로 미룬다.

그런 교환들을 어떻게 다수의 양방향 “대화형” 메시지 교환 패턴으로 만들 수 있는 지는 알기 쉽다. 예제 3은 여행 예약 어플리케이션이 가용한 공항 리스트 중에서 하나를 선택해서 예제 2의 응답으로 보낸 SOAP 메시지를 보여준다. 같은 reference 서브-엘리먼트 값을 가지는 헤더 블록 reservation은 이 대화의 각 메시지와 동반하여, 어플리케이션 수준에서 교환된 메시지들을, 필요하다면, 상관시키는 방법을 제공한다.

uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d 2001-11-29T13:36:50.000-05:00 Ake Jogvan Oyvind

LGA

EWR

대화형 메시지 교환을 계속하는 예제 2의 메시지에 대한 응답

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 4Item 5는 SOAP을 채택한 RPC 어플리케이션이 월드 와이드 웹의 구조적인 원칙들과 부합하는 방식으로 동작할 수 있도록 하기 위해 필요하다. Section 4.1.3은 item 4와 5에 의해 제공된 정보를 어떻게 활용하는 지를 설명한다.

이 절의 나머지에서는, 예제 4에서 볼 수 있는 것처럼 SOAP 메시지로 전달되는 RPC는 적합하게 목표를 지정하고 획득한다고 가정한다. 이 절의 목적은 SOAP 메시지 내에 전달되는 RPC 요청들과 응답들의 문법적인 특징들을 조명하는 것이다.

5 <m:chargeReservation env:encodingStyle=”http://www.w3.org/2003/05/soap-encoding” xmlns:m=”http://travelcompany.example.org/”> FT35ZBQ Ake Jogvan Oyvind 123456789099999 2005-02 </m:chargeReservation>
필수 헤더와 두 개의 입력(즉 “in”) 파라미터들을 가진 SOAP RPC 요청

RPC 자체는 env:Body 엘리먼트의 차일드로써 전달되며 프로시저 또는 메쏘드의 이름 – 이 경우에는 chargeReservation – 을 갖는 struct로써 모델링된다. (struct는 일반적인 프로그래밍 언어에 있는 구조체 또는 레코드 형식을 모델로 하는, [SOAP Part2]에서 정의한 SOAP 데이터 모델의 개념이다.) 예제에서 RPC의 설계는 두 가지 입력 파라미터, 예약 code에 의해 명시된 여행의 reservationcreditCard 정보를 받는다. 후자는 또한 카드 소유자 name, 카드 numberexpiration 날짜 등 세 가지 엘리먼트를 가지는 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가 어떤 트랜젝션 내에서 수행되는 지를 명시한다.

5 FT35ZBQ http://travelcompany.example.org/reservations?code=FT35ZBQ
예제 4의 호출에 대한, 두 개의 출력 (즉 “out”) 파라미터를 가지는 RPC 응답

RPC들은 종종 특정 출력 파라미터를 구별하기 위한 소위 “return”값으로 불리는 명세(description)들을 가진다. SOAP RPC 관행은 프로시저를 기술할 때, 이런 “return”값을 다른 출력 파라미터들과 구별하는 방법을 제공한다. 이것을 보여주기 위해, 과금 예제를 예제 5a와 거의 같은 RPC 명세(description)를 가지도록 수정한다, 즉 두 개의 “out” 파라미터들을 가지지만, 부가적으로 “confirmed”와 “pending” 값을 가질 수 있는 목록(enumeration)인 “return” 값을 또한 가진다. 이런 명세(description)를 따르는 RPC 응답이 예제 5b에 있다, 여기서도 전에 처럼 SOAP 헤더는 RPC가 어떤 트랜젝션 내에서 수행되는 지를 명시한다.

5 m:status confirmed FT35ZBQ http://travelcompany.example.org/reservations?code=FT35ZBQ
예제 4의 호출에 대해 “return” 값과 두 개의 “out” 파라미터들을 가지는 RPC 응답

예제 5b에서 rpc:result 엘리먼트가 리턴 값을 명시하

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.