SOAP 전송 프로토콜

1. HTTP 전송 프로토콜

요청-응답 모드 프로토콜을 기반으로 하는 Hypertext Transfer Protocol(HyperText Transfer Protocol, 약어: HTTP)은 클라이언트가 요청을 보내고 서버가 응답을 제공하고 요청 내용을 반환합니다. 방법은 다음과 같으며, 일반적으로 사용되는 HTTP 전송 프로토콜은 GET 및 POST 방식이며, GET 및 POST 방식에서도 다음 SOAP 프로토콜이 일반적으로 사용됩니다.

방법	의미
얻다	지정된 자원에 "표시" 요청을 발행합니다. GET 메서드를 사용하는 것은 데이터를 읽는 데만 사용해야 하며 웹 애플리케이션과 같은 "부작용" 작업에 사용해서는 안 됩니다. 그 이유 중 하나는 웹 스파이더 등에서 GET에 임의로 액세스할 수 있기 때문입니다.
머리	GET 메서드와 마찬가지로 지정된 리소스에 대한 요청을 서버로 보냅니다. 서버가 리소스의 텍스트 부분을 반환하지 않을 뿐입니다. 이 방법을 사용하면 모든 콘텐츠를 전송하지 않고도 "리소스에 대한 정보"(메타 정보 또는 메타데이터)를 얻을 수 있다는 장점이 있습니다.
우편	지정된 리소스에 데이터를 제출하고 처리(예: 양식 제출 또는 파일 업로드)를 위해 서버에 요청합니다. 데이터는 요청 본문에 포함됩니다. 이 요청은 새 리소스를 생성하거나 기존 리소스를 수정하거나 둘 다 수행할 수 있습니다.
놓다	최신 콘텐츠를 지정된 리소스 위치에 업로드
삭제	Request-URI로 식별된 자원을 삭제하도록 서버에 요청
추적하다	주로 테스트 또는 진단을 위해 서버에서 받은 요청을 에코합니다.
옵션	이 메서드는 서버가 이 리소스에서 지원하는 모든 HTTP 요청 메서드를 반환하도록 합니다. 리소스 이름을 '*'로 대체하고 웹 서버에 OPTIONS 요청을 보내 서버 기능이 정상적으로 작동하는지 테스트합니다.
연결하다	파이프라인에 대한 연결을 변경할 수 있는 프록시 서버용 HTTP/1.1 프로토콜에 예약되어 있습니다. 일반적으로 SSL 암호화 서버에 대한 연결에 사용됨(암호화되지 않은 HTTP 프록시 서버를 통해)

==================================================== =====================

2. SOAP 전송 프로토콜

SOAP(Simple Object Accrss Protocol, Simple Object Access Protocol)는 간단한 XML 기반 프로토콜입니다. SOAP는 웹 서비스용 통신 프로토콜입니다. XML 언어 및 XSD 표준을 기반으로 합니다. 인코딩 규칙 세트를 정의합니다. 정의 방법 인코딩 규칙 데이터를 메시지로 표현하고 HTTP 프로토콜을 통해 SOAP 메시지를 전송하는 방법은 다음 네 부분으로 구성됩니다.

(1) SOAP 엔벨로프(Envelope): 메시지 내용, 발신자, 수신자, 프로세서 및 메시지 처리 방법을 포함하여 메시지에 포함된 내용을 설명하는 프레임워크를 정의합니다.

(2) SOAP 인코딩 규칙: 응용 프로그램에서 정의한 데이터 유형의 인스턴스를 교환하기 위한 직렬화 메커니즘을 정의합니다. (3) SOAP RPC 표현: 원격 프로시저 호출 및 응답을 표현하는 데 사용되는 프로토콜을 정의합니다.

(4) SOAP 바인딩: 기본 전송 프로토콜을 사용하여 노드 간에 SOAP 엔벨로프 교환을 완료하는 규칙을 정의합니다.

SOAP는 정보를 XML로 직렬화한 후 http 프로토콜 형태로 패키징하여 전송하며 전송 방식은 여전히 ​​tcp 또는 udp입니다. 은유로 이해하기 쉽습니다. tcp와 udp는 모두 도로입니다.지금은 tcp를 일반도로, udp고속도로, soap와 http는 모두 자동차이고, soap와 http는 tcp와 udp에서 실행할 수 있습니다. 비누는 http를 통해 전송이 가능하다고 하는데, 사실 비누는 자동차이고 http는 자동차를 실은 트럭입니다.비누의 정보를 http에 실어서 운반합니다. tcp 또는 udp. 비누가 http 프로토콜을 통해 전송될 수 있다고 말하는 것은 정확하지 않으며 더 정확한 표현은 http 프로토콜을 통해 비누 정보를 패키징한 다음 tcp 또는 udp를 통해 전송될 수 있다는 것입니다.

//SOPA协议的基本结构
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
  ...
  ...
</soap:Header>
 
<soap:Body>
  ...
  ...
  <soap:Fault>
    ...
    ...
  </soap:Fault>
</soap:Body>
 
</soap:Envelope>

==================================================== ======================

3. SOAP 전송 프로토콜
1. SOAP 봉투

SOAP 봉투는 메시지를 나타내는 XML 문서의 루트 요소입니다. 메시지 처리 방법과 대상에 대한 프레임워크를 정의합니다. XML 콘텐츠는 SOAP Envelope로 시작합니다. SOAP에서 XML 네임스페이스는 SOAP 식별자를 응용 프로그램별 식별자와 구별하고 SOAP 메시지 요소의 범위를 특정 필드로 제한하는 데 사용됩니다. 다른 네임스페이스가 사용되면 응용 프로그램에서 오류가 발생하고 이 메시지를 버립니다. SOAP 메시지의 모든 요소는 첫 번째 네임스페이스에 의해 규정되어야 합니다.

SOAP 1.1规范如下：

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"

</soap-env:Envelope >

SOAP 1.2规范如下：

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

</soap:Envelope>

2. encodingStyle 속성

 SOAP의 encodingStyle 속성은 문서에서 사용되는 데이터 유형을 정의하는 데 사용됩니다. encodingStyle 속성은 모든 SOAP 요소에 나타날 수 있으며 요소의 내용과 요소의 모든 자식 요소에 적용됩니다. SOAP 메시지에는 기본 인코딩이 없습니다.

3. SOAP 헤더 요소

 SOAP 헤더 요소는 SOAP 엔벨로프의 첫 번째 직계 자식 요소여야 하며 유효한 네임스페이스를 사용해야 합니다. 헤더는 또한 0개 이상의 선택적 하위 요소를 포함할 수 있습니다. 하위 요소를 헤더 항목이라고 합니다. 모든 헤더 항목은 완전히 수정되어야 합니다. 즉, 네임스페이스 URI와 로컬 이름으로 구성되어야 합니다. 네임스페이스는 허용되지 않습니다. 수정된 헤더 항목이 있습니다.

Header 요소는 인증 또는 트랜잭션 정보와 같은 메시지와 함께 추가 정보를 전송하는 데 사용됩니다. Header 요소는 특정 속성을 포함할 수도 있습니다. SOAP는 기본 네임스페이스에서 세 가지 속성인 actor, mustUnderstand 및 encodingStyle을 정의합니다. SOAP 헤더에 정의된 이러한 속성은 컨테이너에 SOAP 메시지 처리 방법을 알려줍니다.

<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:mustUnderstand="1">234</m:Trans>
</soap:Header>
 
...
</soap:Envelope>

3.1 액터 속성

SOAP 메시지는 메시지 경로를 따라 서로 다른 끝점을 통과하여 발신자에서 수신자로 이동할 수 있습니다. SOAP 메시지의 모든 부분이 SOAP 메시지의 최종 끝점으로 전송되도록 의도된 것은 아니며 특정 끝점으로 전송될 수도 있습니다. SOAP의 행위자 속성은 헤더 요소를 특정 끝점으로 지정하는 데 사용할 수 있습니다.

//语法规则：soap:actor="URI"
//下面代码中有一个"Trans"元素的头部，值是234，此元素的"mustUnderstand"属性的值是"1"。
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:actor="http://www.w3school.com.cn/appml/">
234
</m:Trans>
</soap:Header>
 
...
...
 
</soap:Envelope>

3.2 mustUnderstand 속성

SOAP의 mustUnderstand 속성은 수신자가 헤더 항목을 처리하는 데 필수 항목인지 선택 항목인지 식별하는 데 사용할 수 있습니다. Header 요소의 하위 요소에 "mustUnderstand="1"이 추가되면 이 헤더를 처리하는 수신자가 이 요소를 인식해야 함을 나타내며, 수신자가 이 요소를 인식하지 못하면 무효화해야 합니다.

//语法：soap:mustUnderstand="0|1"
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Header>
<m:Trans
xmlns:m="http://www.w3school.com.cn/transaction/"
soap:mustUnderstand="1">
234
</m:Trans>
</soap:Header>
 
...
...
 
</soap:Envelope>

3.3 encodingStyle 속성

SOAP의 encodingStyle 속성은 Envelope 요소와 동일합니다.

==================================================== ========================

4. SOAP 본문 요소

  SOAP 메시지의 본문 블록은 다음 요소 중 하나를 포함할 수 있습니다: RPC 메서드 및 해당 매개 변수, 대상 응용 프로그램(메시지 수신자) 특정 데이터, SOAP 오류 보고 오류 및 상태 메시지. Body 요소의 모든 직계 자식 요소는 Body 항목이라고 하며 Body 항목은 네임스페이스로 장식되어야 합니다. 필수 SOAP 본문 요소에는 메시지의 궁극적인 끝점으로 전달될 실제 SOAP 메시지가 포함될 수 있습니다.

SOAP Body 요소의 직계 자식 요소는 네임스페이스로 한정될 수 있습니다. SOAP는 기본 네임스페이스("http://www.w3.org/2001/12/soap-envelope")의 Body 요소 내부에 요소를 정의합니다. 즉, 오류 메시지를 나타내는 데 사용되는 SOAP의 Fault 요소입니다.

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
 
<soap:Body>
   <m:GetPriceResponse xmlns:m="http://www.w3school.com.cn/prices">
      <m:Price>1.90</m:Price>
   </m:GetPriceResponse>
</soap:Body>
 
</soap:Envelope>

==================================================== ========================

5. SOAP 결함 요소

SOAP 오류 요소는 SOAP 메시지에서 오류 및 상태 정보를 전송하는 데 사용됩니다. SOAP 메시지가 SOAP 결함 요소를 포함해야 하는 경우 SOAP 결함 요소는 본문 항목으로 나타나야 하며 최대 한 번 나타나야 합니다. SOAP 결함에는 faultcode, faultstring, faultactor, detail과 같은 하위 요소가 포함됩니다.

하위 요소	설명하다
<결함 코드>	오류 식별 코드
<고장 문자열>	결함에 대한 사람이 읽을 수 있는 설명
<결함자>	실패 원인에 대한 정보
<상세>	Body 요소와 관련된 애플리케이션별 오류 메시지 유지

SOAP Fault 요소에는 다음과 같은 하위 요소가 있으며, 아래에 정의된 faultcode 값은 fault를 기술할 때 faultcode 요소에 사용되어야 합니다.

버전 불일치	SOAP Envelope 요소에 대해 잘못된 네임스페이스가 발견되었습니다.
반드시 이해해야 합니다	헤더 요소의 직계 자식 요소(mustUnderstand 특성이 "1"로 설정됨)를 이해할 수 없습니다.
고객	메시지가 부적절하게 구성되었거나 잘못된 정보가 포함되어 있습니다.
섬기는 사람	서버에 문제가 있어 더 이상 진행할 수 없습니다.

==================================================== ========================

6. SOAP 첨부 파일

SOAP1.1 사양에 따르면 SOAP 메시지는 XML 형식의 기본 SOAP 엔벨로프와 ASCII 또는 바이너리와 같은 데이터 형식의 SOAP 첨부 파일을 포함할 수 있습니다. SOAP 메시지에 첨부 파일이 포함되어 있으면 SOAP 메시지는 SOAP 콘텐츠와 하나 이상의 다른 유형의 첨부 파일을 포함하는 MIME 인코딩 메시지가 됩니다. 따라서 SOAP 메시지는 실제로 다음 두 가지 유형으로 나뉩니다.

    A. XML 콘텐츠만 포함된 메시지

    B. 초기 XML 페이로드 및 여러 첨부 파일을 포함하는 MIME 인코딩 메시지. 첨부 파일은 다른 유형의 데이터일 수 있습니다.

==================================================== ========================

7. SOAP 메시지 바인딩

웹 서비스의 페이로드는 일반적으로 SOAP 메시지에 래핑되며 SOAP 메시지 구조는 WSDL 문서의 SOAP 바인딩 정의에 의해 결정됩니다. 서로 다른 호출 방법 및 인코딩 방법을 결합하여 여러 바인딩 스타일을 생성할 수 있으며 각 스타일의 애플리케이션 시나리오 및 해당 SOAP 메시지 구조가 다릅니다. SOAP 메시지를 적절히 구성하지 않으면 서비스의 페이로드를 올바르게 교환할 수 없습니다.

 SOAP 본문은 SOAP 메시지의 실제 로드이며 모든 콘텐츠를 포함할 수 있는 메시지 교환을 위한 메커니즘을 제공합니다. SOAP 메시지 본문(SOAP Body)은 서비스 호출 방법(RPC 또는 문서)을 바인딩하여 작업을 캡슐화하고 인코딩 방법(Encoded 또는 Literal)을 바인딩하여 매개 변수를 직렬화합니다. SOAP 메시지의 바인딩 스타일은 style, use 및 encodingStyle의 세 가지 속성에 의해 공동으로 설정됩니다. style 속성은 서비스의 호출 방식, RPC 방식 또는 Document 방식 사용 여부, use 속성은 메시지의 인코딩 방식, Encoded 방식 또는 Literal 방식 사용 여부, encodingStyle 속성은 특정 SOAP 인코딩 규칙 지정, XML 스키마 코딩 규칙 등과 같은 인코딩 규칙은 일반적으로 XML 스키마를 사용합니다.

7.1 스타일 속성

        style 속성은 서비스가 호출되는 방식을 설명하며 값은 "rpc" 또는 "document"이고 기본값은 "document"입니다. SOAP Body 요소의 자식 요소(및 가능한 손자)에 적용됩니다. 이 옵션은 WSDL 문서의 soap:binding 요소(보통) 또는 soap:operation의 스타일 속성으로 지정됩니다.

A.RPC: 클라이언트/서버 방식(요청/응답)을 이용하여 요청을 서버로 보내고, 서버는 해당 방식을 실행한 후 결과를 반환한다. 장점은 크로스 언어 및 크로스 플랫폼이라는 점이며, 단점은 컴파일 타임에 디버깅할 수 없고 런타임에만 확인할 수 있다는 것입니다.

SOAP 메시지는 본질적으로 발신자에서 수신자로의 단방향 전송이지만 SOAP는 종종 요청/응답 메커니즘을 구현하기 위해 결합됩니다. RPC가 SOAP를 사용하려면 몇 가지 규칙을 따라야 합니다. 첫째, 요청 및 응답 메시지는 구조체 유형으로 인코딩되어야 합니다. 둘째, 오퍼레이션의 각 입력 매개변수에 대해 매개변수와 동일한 이름을 가진 요소(또는 입력 구조의 구성원)가 있어야 합니다. 마지막으로 각 출력 매개변수에 대해 이름이 일치하는 요소(또는 출력 구조의 구성원)가 있어야 합니다.

style="rpc"는 SOAP 표준 준수를 나타내며 SOAP 본문에서 RPC 호출의 요청 및 반환 작업을 캡슐화합니다. 이 유형의 메시지에 대한 제약 조건은 작업 이름이 작업에 대한 요청 및 응답 메시지의 페이로드를 캡슐화하는 루트 요소의 이름으로 사용되어야 한다는 것입니다. SOAP 요청 메시지의 경우 요청 작업의 이름은 웹 서비스 메서드에 해당하는 WSDL 문서의 wsdl:operation 요소를 기반으로 합니다. SOAP 응답 메시지의 경우 응답 작업의 이름은 "Response"가 추가된 요청 작업의 이름입니다. operation 요소의 각 하위 요소는 WSDL 문서의 wsdl:part 요소에 따라 이름이 지정된 매개변수를 나타냅니다. RPC 요청/응답 메시지(네임스페이스 자격 생략)의 형식은 다음과 같습니다.

RPC请求消息格式：

<SOAP信封>

<SOAP头部>

     ……

</SOAP头部>

    <SOAP消息体>

<请求操作名称>

          <参数名1>值</参数名1>

          <参数名2>值</参数名2>

             ......

        </请求操作名称>

</SOAP消息体>

</SOAP信封>

RPC响应消息格式：

<SOAP信封>

<SOAP头部>

  ……

</SOAP头部>

    <SOAP消息体>

       <响应操作名称>

          <参数名1>值</参数名1>

          <参数名2>值</参数名2>

              ......

        </响应操作名称>

    </SOAP消息体>

</SOAP信封>

B. RPC와 비교하여 Document 메서드는 원격 메서드를 XML 파일에 매핑하지 않고 완전한 자체 포함 비즈니스 문서를 매핑합니다. 서버는 이 문서를 받으면 먼저 사전 처리(예: 단어 번역 및 매핑)를 수행한 다음 반환 메시지를 구성합니다. 반환 메시지를 구성하는 과정에서 더 이상 단순한 메서드 호출이 아니라 여러 개체가 협력하여 트랜잭션 처리를 완료한 다음 결과를 반환하는 경우가 많습니다.

 문서는 메시지를 구성하는 데 사용되며 SOAP Body 요소의 내용은 WSDL의 XML 스키마에 의해 완전히 정의되므로 XML 스키마를 사용하여 SOAP Body 요소의 내용을 확인할 수 있습니다. SOAP 본문의 하위 요소는 XML 스키마 요소 선언을 가리키는 WSDL 문서에 정의된 wsdl:part 요소의 메시지 부분으로 지정됩니다. 일반적으로 wsdl:message는 여러 wsdl:part 요소를 포함하지 않으므로 WSDL 자체가 여러 wsdl:part 요소를 포함하는 것을 금지하지는 않지만 SOAP 본문 콘텐츠는 실제 XML 문서입니다. 문서 요청/응답 메시지(네임스페이스 한정 생략)의 형식은 다음과 같습니다.

Document请求消息格式：

<SOAP信封>

<SOAP头部>

     ……

</SOAP头部>

    <SOAP消息体>

        <输入消息>

   ….

 </输入消息>

….

</SOAP消息体>

</SOAP信封>

Document响应消息格式：

<SOAP信封>

<SOAP头部>

 ……

</SOAP头部>

    <SOAP消息体>

         <输出消息>

   ….

  </输出消息>

….

    </SOAP消息体>

</SOAP信封>

7.2 사용 속성

 use 속성은 메시지가 직렬화되는 방식을 설명합니다. 값은 "encoded" 또는 "literal"이고 기본값은 "literal"입니다. use="encoded"인 경우 encodingStyle 속성 값을 설정하여 인코딩 규칙을 지정합니다. use="literal"인 경우 encodingStyle 속성의 값을 설정할 필요가 없으며 일반적으로 기본 XML 스키마가 사용됩니다. 다음 수준에 나타나는 웹 서비스 메서드 매개 변수(또는 반환 값)에 적용됩니다. 이 옵션은 WSDL 문서에서 soap:body, soap:header, soap:fault 및 soap:headerfault 요소의 사용 속성으로 지정됩니다.

A. 인코딩된 SOAP 인코딩은 XML 스키마의 하위 집합을 사용하여 XML 문서와 해당 문서가 나타내는 데이터를 바인딩합니다. SOAP 인코딩은 또한 href 속성을 사용하여 문서에서 여러 번 나타나는 요소를 참조합니다. SOAP 인코딩과 XML 스키마 인코딩 간의 완전한 차이점은 배열입니다. SOAP 사양의 섹션 5.4.2는 특수 SOAP-ENC:Array 유형을 사용하여 프로그래밍 언어 배열을 XML로 나타내는 특수 메커니즘을 지정합니다. XML 스키마에서 배열은 요소의 minOccurs 및 maxOccurs 속성 값을 설정하여 표현됩니다. 예를 들어, 이 두 가지 인코딩 방법을 사용하는 정수 배열의 정의는 다음과 같습니다.

<complexType name="ArrayOfInt"> 
  <complexContent> 
     <restriction base="SOAP-ENC:Array"> 
<sequence>
    <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/>
</sequence>
        <attribute ref=" SOAP-ENC:arrayType"  wsdl:arrayType="xsd:ArrayOfInt[]"/> 
      </restriction> 
  </complexContent> 
</complexType>  

=================================================

//XML Schema定义数组
<complexType name="ArrayOfInt">  
<sequence>
 <element name=”item” type=”xsd:int” minOccurs=”0” maxOccurs=”unbounded”/>
</sequence>
  </complexContent> 
</complexType>

B. Encoded와 비교할 때 Literal은 SOAP 인코딩 대신 XML Schema 인코딩을 사용하며 Literal 인코딩은 데이터 유형 속성이 필요하지 않습니다. 데이터는 WSDL 문서에 지정되거나 WSDL 문서로 가져온 XML 스키마 정의에 따라 형식이 그대로 지정됩니다. Literal 모드로 인코딩된 add 메서드의 메시지 형식은 다음과 같습니다.

<op:add xmlns:op=”http://act.buaa.edu.cn/add”>
<a>
<item>45</item>
<item>36</item>
</a>
 <b>
<item>235</item>
<item>67</item>
</b>
</op:bdd>

7.3 encodingStyle 속성

        WSDL 사양의 encodingStyle 속성은 SOAP 사양의 encodingStyle 속성과 동일하게 정의됩니다. encodingStyle 속성의 값은 단일 공백으로 구분된 URI 목록이며 각 URI는 메시지 인코딩 규칙을 나타내며 강한 인코딩 제약 조건에서 약한 인코딩 제약 조건으로 정렬됩니다. encodingStyle 속성은 SOAP 메시지의 인코딩 규칙, 즉 직렬화 형식 및 유형 시스템을 지정하는 데 사용됩니다. use="encoded"이고 encodingStyle 속성의 값이 "http://schemas.xmlsoap.org/soap/encoding/"이면 프로그래밍을 정의하는 SOAP 사양 섹션 5의 인코딩이 사용됨을 의미합니다. 언어 형식이 XML에 매핑되는 기본 메커니즘입니다. use="literal"이면 외부에서 제공되는 유형 시스템을 사용하고 encodingStyle 속성을 통해 스키마를 지정할 수도 있지만 일반적으로 XML 스키마는 SOAP 메시지를 인코딩하는 데 사용됩니다.

    그 이유는 SOAP 사양이 XML 스키마 사양을 채택하기 전에 작성되었기 때문입니다. 따라서 원래의 SOAP 사양은 인코딩 유형 정보를 나타내는 방법을 제공해야 했습니다. 그러나 XML 스키마를 채택한 이후로 대부분의 언어는 XML 스키마에서 프로그래밍 언어 유형으로 자체 매핑(또는 직렬화 규칙)을 사용하므로 SOAP 인코딩이 더 이상 사용되지 않습니다. 따라서 SOAP 인코딩을 사용하지 않고 XML Schema 문서(일반적으로 WSDL 문서 형식)에 의해 매핑이 외부적으로 지정되는 Literal 인코딩을 사용하는 것이 좋습니다.

==================================================== ======================

8. SOAP 메시지 구성

style 속성과 use 속성은 모두 두 가지 값을 가지며, 이들을 서로 다른 조합을 통해 rpc-literal, rpc-encoded, document-literal 및 document-encoded의 네 가지 바인딩 스타일을 생성할 수 있습니다. 문서 바인딩 스타일이 RPC 바인딩 스타일 호출을 지원하도록 하기 위해 문서 스타일의 사용만 제한하는 래핑(Wrapped) 스타일이 추가되었습니다. 이렇게 해서 document-literal-wrapped와 document-encoded-wrapped의 바인딩 스타일이 2개 더 추가되어 총 6개의 바인딩 스타일이 있습니다. 다음은 다른 바인딩 스타일에서 SOAP 메시지 구조를 설명하기 위해 추가 서비스를 예로 사용합니다. 서비스 정의는 다음과 같습니다.

입력 작업의 작업 이름이 add이고 type a와 b의 두 가지 입력 매개 변수가 있음을 서비스 정의에서 알 수 있습니다. WSDL 사양에 따르면 반환 작업의 작업 이름은 addResponse여야 하며 반환 이름이 지정된 정수 유형의 출력 매개 변수가 있습니다.

작업 직렬화에는 네임스페이스 자격이 필요합니다. RPC 호출인 경우 네임스페이스는 soap:body의 네임스페이스 속성 값이고, 문서 호출인 경우 네임스페이스는 입력 메시지에서 참조하는 스키마의 targetNamespace 속성 값입니다. 매개변수의 직렬화에 네임스페이스 자격이 필요한지 여부는 스키마가 정의될 ​​때 elementFormDefault 속성의 값에 따라 다릅니다. 값이 "qualified"이면 정규화되어야 함을 의미하고 네임스페이스는 Schema의 targetNamespace 속성 값이고, 값이 "unqualified"이면 정규화될 필요가 없음을 의미합니다. 기본값은 "무자격"입니다. 연산의 직렬화 요소는 SOAP 메시지 본문의 하위 요소이며, 각 매개변수의 직렬화 요소는 연산 요소의 하위 요소이며, 배열 순서는 연산의 매개변수 정의 순서와 동일하다. .   

    A. use= "encoded"이면 encodingStyle의 값은 "http://schemas.xmlsoap.org/soap/encoding/"이고 use= "literal"이면 "http://www.w3.org/"를 사용합니다. 2001 /XMLSchema" 인코딩.

    B. style=”rpc”인 경우 wsdl:part 부분의 type 참조는 type 속성을 사용하고 style=”document”인 경우 element 속성을 사용합니다.

8.1  rpc 리터럴 바인딩 스타일

<wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
   xmlns:ns="http://act.buaa.edu.cn/add" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://act.buaa.edu.cn/add">
<wsdl:message name=”addRequest”>
 <wsdl:part name=”a” type=”xsd:int”/>
    <wsdl:part name=”b” type=”xsd:int ”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
    <wsdl:part name=”return” type=”xsd:int”/>
</wsdl:message>
<!--Just assume it's rpc-literal. -->
......

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
       <a>12</a>
<b>45</b>
     </op: add >
   </env:Body>
</env:Envelope>]

 장점: WSDL 설명 및 SOAP 메시지는 기본적으로 가능한 한 간단하고 이해하기 쉬운 요구 사항을 충족하며 서비스의 작업 이름이 SOAP 메시지 본문에 나타나 수신자가 메시지를 메서드 구현에 쉽게 보낼 수 있습니다. ; 유형 인코딩이 없으므로 처리량이 향상되고 처리 오버헤드가 줄어듭니다.

    단점: RPC 모델에서 XML은 메소드의 정보를 기술하는 데만 사용되며 비즈니스 문서를 기술하고 검증하는 데 XML의 기능을 충분히 활용할 수 없다. 매개변수 a 및 b는 스키마에 정의된 콘텐츠이고 나머지 env:body 콘텐츠(예: 추가 요소)는 WSDL 정의에서 가져옵니다. 매개변수의 유형 정보는 메시지에서 직접 얻을 수 없습니다. RPC 스타일은 요청/응답 메시지의 모드를 묶음으로 서비스와 클라이언트 간의 연결을 만듭니다. Inter-coupling이 증가하고 메서드가 변경되면 클라이언트가 해당 변경을 수행해야 합니다. RPC 스타일은 일반적으로 동기식입니다.

8.2 rpc 인코딩 바인딩 스타일

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
       xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” >
  <env:Body>
     <op: add xmlns:op=“http://act.buaa.edu.cn/add”>
        < a  xsi:type=”xsd:int”>12</a>
<b  xsi:type=”xsd:int”>45</b>
     </op: add >
   </env:Body>
</env:Envelope>

 rpc-literal 바인딩 스타일과의 유일한 차이점은 요청 메시지의 매개변수 부분이 다르게 인코딩된다는 것입니다. 메시지의 각 매개변수에는 유형 코드(예: <a xsi:type="int">12</a>)가 있으며 매개변수의 데이터 유형은 메시지에서 직접 알 수 있습니다. 그러나 이러한 유형의 메시지는 메시지 처리의 처리량과 성능을 저하시킵니다. 특히 빅 데이터의 경우 성능 오버헤드가 명백합니다.

 rpc로 인코딩된 바인딩 스타일은 주로 오버로드, 데이터 그래픽 및 다형성의 경우에 사용됩니다. WSDL은 오버로드된 작업을 허용하지만 매개변수의 수가 동일한 경우 리터럴 인코딩 방법에는 유형 정보가 없고 메서드를 찾을 수 없기 때문에 rpc-literal은 이러한 오버로드를 지원하지 않습니다. 데이터 그래픽의 표준 방식은 rpc 스타일로 인코딩된 href 태그를 사용하는 것입니다. 다형성에 의해 생성된 SOAP 메시지는 유형 인코딩 정보를 포함해야 수신 터미널이 수신 중인 상위 클래스의 확장을 알 수 있습니다.

8.3  문서/리터럴 바인딩 스타일

<wsdl:definitions xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
xmlns:ns="http://act.buaa.edu.cn/add" targetNamespace=" http://act.buaa.edu.cn/add ">
<wsdl :types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/add" xmlns:xs="http://www.w3.org/2001/XMLSchema" >  
       <xs:element name="a"  type="xs:int " />
       <xs:element name="b"  type="xs:int " />
       <xs:element name="return"  type="xs:int " />
</xs :schema>
</wsdl :types>
<wsdl:message name=”addRequest”>
     <wsdl:part  name=”parameter1” element=”ns:a”/>
<wsdl:part  name=”parameter2” element=”ns:b”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
     <wsdl:part name=”parameter” element=”ns:return”/>
</wsdl:message>
<!--Just assume it's  document-literal. -->
……

================================================================
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:op=“http://act.buaa.edu.cn/add”>
<env:Body>
    <op:a>12</op:a>
<op:b>45</op:b>
</env:Body>
</env:Envelope>

요청 메시지의 매개변수 요소에는 입력 메시지가 WSDL 문서의 스키마와 스키마의 elementFormDefault="qualified"에 정의되어 있으므로 네임스페이스 자격이 추가되었습니다. 즉, 매개변수 요소는 스키마의 네임스페이스 "http://act.buaa.edu.cn/add"로 한정되어야 합니다.

 장점: 작업 및 유형 인코딩 정보가 없으므로 메시지의 데이터 볼륨을 줄이고 메시지 처리 성능을 향상시킵니다. 메시지.

 단점: WSDL 문서는 더 복잡해집니다. 이는 WSDL이 사람이 읽을 수 있도록 설계되지 않았기 때문에 매우 작은 단점일 뿐입니다. 서비스 작업의 이름이 SOAP 메시지에 제공되지 않으며 메시지를 배포할 때 일부 특정 프로그램 코드가 사용될 수 있습니다. 복잡해지고 때로는 불가능해집니다. HTTP가 기본 전송 프로토콜로 사용되는 경우 SOAPAction 특성을 사용하여 작업 이름을 바인딩하여 메시지 배포 문제를 해결할 수 있습니다. HTTP는 대부분의 경우 SOAP 메시지를 전송하는 데 사용되지만 이 방법은 기본 전송 프로토콜을 바인딩하고 다른 전송 프로토콜의 사용을 제한합니다.

8.4  문서/인코딩된 바인딩 스타일

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance”
       xmlns:op=“http://act.buaa.edu.cn/add”>
   <env:Body>
       <op:a  xsi:type=”xsd:int”>12</op:a>
<op:b  xsi:type=”xsd:int”>45</op:b>
   </env:Body>
</env:Envelope>

 문서 리터럴 바인딩 스타일과 유일한 차이점은 요청 메시지의 매개 변수 부분이 다르게 인코딩된다는 것입니다. 유형 인코딩이 도입되어 메시지 처리의 처리량과 성능이 감소했습니다. 이 스타일의 바인딩은 대부분의 웹 서비스 구현 플랫폼에서 지원되지 않습니다.

8.5   문서 리터럴 래핑 바인딩 스타일

<wsdl:definitions  xmlns:wsdl= " http://schemas.xmlsoap.org/wsdl/"
xmlns:ns="http://act.buaa.edu.cn/add"  targetNamespace=" http://act.buaa.edu.cn/add ">
<wsdl :types>
<xs:schema elementFormDefault="qualified" targetNamespace="http://act.buaa.edu.cn/xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema" >  
       <xs:element name="add">
          <xs:complexType>
            <xs:sequence>
               <xs:element name="a"  type="xs:int " />
               <xs:element name="b"  type="xs:int " />
            </xs:sequence>
          </xs:complexType>
       </xs:element>
       <xs:element name="addResponse">
          <xs:complexType>
            <xs:sequence>
               <xs:element name="return"  type="xs:int " />
            </xs:sequence>
         </xs:complexType>
       </xs:element>
</xs :schema>
</wsdl :types>
<wsdl:message name=”addRequest”>
    <wsdl:part  name=”parameter” element=”ns:add”/>
</wsdl:message>
<wsdl:message name=”addReponse”>
    <wsdl:part name=”parameter” element=”ns:addResponse”/>
</wsdl:message>
<!--Just assume it's  document-literal-wrapped. -->
……
=====================================================================
<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
       <op:a>12</op:a>
<op:b>45</op:b>
     </op: add >
  </env:Body>
</env:Envelope>

이때 SOAP Body의 첫 번째 요소의 이름은 오퍼레이션의 이름이 아니라 Schema의 요소 이름이다. 스키마에 있는 요소의 이름은 오퍼레이션 이름과 같을 수도 있고 다를 수도 있습니다. 동일한 작업 이름을 SOAP 메시지에 입력하는 영리한 방법입니다.

  이 SOAP 메시지는 rpc-literal의 SOAP 메시지와 정확히 동일하게 보이지만(네임스페이스 자격을 고려하지 않은 경우) 두 메시지 사이에는 미묘한 차이가 있습니다. rpc 리터럴 SOAP 메시지에서 <env:Body> 아래의 <op:add> 루트 요소는 작업의 이름입니다. 문서 리터럴 래핑된 SOAP 메시지에서 <op:add> 요소는 단일 입력 메시지의 구성 요소가 참조하는 요소의 이름입니다.

 document-literal-wrapped 스타일은 Document 바인딩 작업의 입력 메시지와 출력 메시지 모두 wsdl:part 부분이 하나만 있음을 규정합니다. 이 부분은 element 속성을 사용하여 요소를 참조합니다. 속성 없음, 요소의 이름과 오퍼레이션의 이름은 동일해야 합니다.

 장점: 패키징 동작은 RPC 스타일의 중요한 이점을 흡수합니다. 즉, RPC 스타일의 SOAP 메시지 본문은 연관된 서비스 작업 이름으로 직접 이름을 지정할 수 있으며 동시에 RPC 스타일의 단점을 버립니다. ; WSDL 문서 유형 부분을 사용할 수 있음 스키마 문서는 SOAP 메시지 본문을 직접 확인함 스키마에 명확한 데이터 구조가 정의되어 있는 한 SOAP 메시지 본문을 구성하는 방법에 큰 유연성이 있음 비즈니스 데이터가 자체 포함된 문서 모델이 비동기 처리에 더 도움이 된다는 것은 분명합니다.

 단점: WSDL은 더 복잡하지만 여전히 매우 작은 단점입니다. 이는 특히 API 수준에서 서비스 호출의 복잡성을 증가시킵니다. 프로그램 개발자에게 래핑된 문서 바인딩 스타일 서비스를 기반으로 클라이언트 코드를 작성하는 것은 매우 어려운 작업이 될 수 있습니다. SOAP 메시지 본문의 XML 래퍼 요소에 서비스 작업 이름이 있어야 래퍼 버전이 오버로드된 서비스 작업을 지원하지 않습니다. 실제로 지정된 요소 이름에 대해 하나의 서비스 작업만 있을 수 있습니다.

8.6  문서 인코딩 래핑 바인딩 스타일

<env:Envelope  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi=” http://www.w3.org/2001/XMLSchema-instance” >
  <env:Body>
     <op: add  xmlns:op=“http://act.buaa.edu.cn/add”>
        <op:a  xsi:type=”xsd:int”>12</op:a>
<op:b  xsi:type=”xsd:int”>45</op:b>
     </op: add >
   </env:Body>
</env:Envelope>

document-literal-wrapped 바인딩 스타일과의 유일한 차이점은 요청 메시지의 매개변수 부분이 다르게 인코딩된다는 것입니다. 유형 인코딩이 도입되어 메시지 처리의 처리량과 성능이 감소했습니다.

==================================================== ======================

9. SOAP  첨부 파일

실제 응용 프로그램에서는 다양한 첨부 파일(예: 이미지, 사진, xml 문서 등)과 함께 SOAP 메시지를 보내는 것이 필요합니다. 첨부 데이터는 일반적으로 특수한 이진 형식입니다. SOAP with Attachments 사양은 "MIME multipart/related" 미디어 유형 및 URI 체계를 사용하여 MIME 부분 참조를 지정합니다. 모든 웹 서비스 툴킷이 SOAP 첨부 지원을 제공하는 것은 아닙니다. Microsoft는 또 다른 DIME 기반 첨부 솔루션을 제안합니다.

9.1 SOAP 메시지 패키지

첨부 파일이 있는 SOAP 메시지 패키지는 다음과 같으며, SOAP 메시지 패키지에는 XML 형식의 주요 SOAP 메시지와 SOAP Envelope에 정의되지 않은 모든 데이터 형식(gif, jpg, xml 등)의 다른 엔터티가 포함되어 있습니다. 메시지 관련.

SOAP 메시지 패키지는 MIME의 Multipart/관련 미디어 유형을 사용하여 구성되며 각 부분은 MIME 경계(Context-Type 헤더에 정의됨) 내에 포함됩니다. 각 MIME 부분에는 이 MIME 부분에 포함된 데이터 유형을 지정하는 Context-Type, Content Transfer-encoding(이 MIME 부분에 사용되는 인코딩 지정), Content-ID 또는 Content-Location(예: 이러한 식별자를 참조하는 패키지의 모든 위치에 있는 MIME). MIME 메시지의 루트 부분에는 SOAP 엔벨로프가 포함되며 Content-Type은 text/xml로 설정됩니다.

9.2 첨부 파일에 대한 SOAP 참조

SOAP 헤더와 SOAP 메시지 본문은 모두 메시지 패킷의 다른 엔터티를 참조할 수 있습니다. SOAP 1.1 인코딩 규칙에 따라 SOAP의 "href" 속성을 사용하여 모든 리소스를 참조할 수 있습니다. Content-ID 또는 Content-Location을 사용하여 모든 리소스를 참조할 수 있습니다. Content-ID가 식별자로 사용되는 경우 스키마 속성(예: href)은 URL 스키마 CID를 사용해야 합니다. Content-Location이 식별자로 사용되는 경우 SOAP with Attachments 사양에 지정된 규칙에 따라 확인해야 합니다. 여기서 확인은 다음 요소 중 하나를 기반으로 합니다.

절대 URI 참조 - 절대 URI는 SOAP Envelope의 Content-Location 및 "href" 속성에 지정됩니다. 상대 URI 참조 - 기본(base) URI는 MIME 메시지의 기본 헤더의 Content-Location에 지정되며 모든 상대 URL은 이 기본 URL을 사용하여 참조됩니다. 기본 URI가 없는 상대 URI - 기본 URI의 Content-Location 헤더 기본 URI는 에 지정되지 않았지만 메시지의 기본 URL이 사용되며 모든 상대 URL은 이 기본 URL을 사용하여 참조됩니다.

일반적으로 URI를 구문 분석해야 하는지 여부를 결정하는 것은 SOAP 프로세서에 달려 있습니다. 또한 메시지 패킷에는 SOAP 봉투의 URI에서 참조하지 않는 첨부 파일이 있을 수 있습니다.

9.3 HTTP 바인딩

SOAP에서 HTTP 바인딩을 사용하여 첨부 파일을 보내는 경우 SOAP MIME 패킷 헤더의 Content-Type 정보를 포함하도록 HTTP 헤더를 수정해야 합니다. MIME 패킷 헤더의 다른 헤더 정보는 HTTP 헤더에 포함되지 않습니다. Apache는 Content-Transfer-Encoding 및 MIME 버전과 같은 헤더 정보를 무시합니다. 모든 MIME 부분에는 SOAP 엔벨로프 부분과 HTTP 본문을 구성하는 기타 첨부 파일이 포함됩니다. 반면에 SMTP 바인딩의 경우 모든 멀티파트 MIME 헤더는 SMTP 헤더의 일부로 저장됩니다. 따라서 SOAP 프로세서와 애플리케이션은 다른 종류의 SOAP 바인딩과 이러한 헤더의 비호환성을 인식해야 합니다.

9.4  WSDL 지원

WSDL은 첨부 파일이 있는 웹 서비스 설명을 지원합니다.

<binding name="DocManagementService_Binding"  ... />
  <operation  name="SubmitArrayOfDocuments">
    <soap:operation soapAction="http://www.DocManagementService.com/SubmitArrayOfData"/>
    <input>
      <mime:multipartRelated>
          <mime:part>
            <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    namespace="urn:DocManagement-service"
    parts="SubmitArrayOfDocuments_inType1 SubmitArrayOfDocuments_inType2"
    use="encoded"/>
          </mime:part>
          <mime:part>
            <mime:content part="SubmitArrayOfDocuments_inType3" type="*/*"/>
          </mime:part>
    </mime:multipartRelated>
    </input>
    <output>
      <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    namespace="urn:DocManagement-service" 
    use="encoded"/>
    </output>
  </operation>
</binding>

바인딩 요소의 입력 및 출력 요소는 확장되며 다른 MIME 부분과 관련된 MIME:multipart를 포함합니다. 하나는 SOAP 본문용이고 다른 하나는 첨부 파일용입니다. 첨부 파일이 있는 각 MIME 부분은 콘텐츠 유형도 지정할 수 있습니다.

==================================================== ======================

SOAP 프로토콜 예제

SOAP 1.2 요청 및 응답 예제. 표시된 자리 표시자는 실제 값으로 대체해야 합니다.

//SOAP 1.2 请求
POST /WebServices/WeatherWS.asmx HTTP/1.1
Host: ws.webxml.com.cn
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <getWeather xmlns="http://WebXml.com.cn/">
      <theCityCode>string</theCityCode>
      <theUserID>string</theUserID>
    </getWeather>
  </soap12:Body>
</soap12:Envelope>


//SOAP 1.2 响应
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
  <soap12:Body>
    <getWeatherResponse xmlns="http://WebXml.com.cn/">
      <getWeatherResult>
        <string>string</string>
        <string>string</string>
      </getWeatherResult>
    </getWeatherResponse>
  </soap12:Body>
</soap12:Envelope>

 HTTP GET 요청 및 응답의 예입니다. 표시된 자리 표시자는 실제 값으로 대체해야 합니다.

GET /WebServices/WeatherWS.asmx/getWeather?theCityCode=string&theUserID=string HTTP/1.1
Host: ws.webxml.com.cn
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfString xmlns="http://WebXml.com.cn/">
  <string>string</string>
  <string>string</string>
</ArrayOfString>

 HTTP POST 요청 및 응답의 예입니다. 표시된 자리 표시자는 실제 값으로 대체해야 합니다.

POST /WebServices/WeatherWS.asmx/getWeather HTTP/1.1
Host: ws.webxml.com.cn
Content-Type: application/x-www-form-urlencoded
Content-Length: length

theCityCode=string&theUserID=string
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfString xmlns="http://WebXml.com.cn/">
  <string>string</string>
  <string>string</string>
</ArrayOfString>

 참조 기사

SOAP 프로토콜 분석_tuowsh의 블로그 - CSDN 블로그

 WeatherWS 웹 서비스