첨부 파일, SOAP 첨부 파일 및 MTOM간에 다소 혼란스러워 보입니다.
SOAP 첨부는 처음에 December 2000 as a W3C note (사양 아님)에 도입되었으며 SOAP 1.1에 정의 된 전송 바인딩 메커니즘의 확장을 정의했습니다. 특히,이 노트는 다음과 같이 정의된다 :
SOAP 1.1 메시지 처리 규칙이 보존되는 방식으로 MIME 다중 파트/관련 메시지 내에서 전달되는 SOAP 1.1 메시지 바인딩. MIME 멀티 파트 메커니즘 복합 문서의 캡슐화는 첨부와 같은 SOAP 1.1 메시지와 관련된 엔티티를 묶는 데 사용될 수 있습니다.
간단히 말해서, 전송을 위해 멀티 파트 MIME 구조를 사용하여 고유 형식으로 SOAP 메시지와 연결되는 여러 문서 (첨부 파일)에 대한 메커니즘을 정의했습니다. 이것은 combination of "Content-Location" and "Content-ID" headers과 함께 "Content-Location"헤더에 의해 참조 된 URI를 해석하기 위해 set of rules을 사용하여 이루어졌습니다.
이 형식의 SOAP 메시지는 다음과 같이 시각화 할 수 있습니다 (다중/MIME로 캡슐화) : 이것은
당신이 SAAJ를 사용할 때 함께 일한 수있는 형식도 있지만입니다 레거시 코드로 작업하지 않는 한 더 이상 권장되지 않습니다. W3C 메모는 나중에 SOAP 1.2와 함께 2004 년 "기능"수준으로 개정되었으며 SOAP MTOM 메커니즘에 따라 eventually superseded이었습니다.
SOAP 메시지 전송 최적화 메커니즘 (MTOM)이 공식적으로하지 하나로 정의
하지만 기능 제공하기 위해 함께 작동
three separate features :
"Abstract SOAP Transmission Optimization Feature"는 전송 및/또는 와이어 형식을 최적화하기위한 추상 기능에 대해 설명 SOAP 메시지의 일부를 선택적으로 인코딩하는 동시에 SOAP 정보에 XML 정보 집합을 제공함으로써 SOAP 메시지의
"An optimized MIME Multipart/Related serialization of SOAP Messages"은 바인딩 독립적 인 방식으로 추상 SOAP 전송 최적화 기능을 구현하는 SOAP 메시지의 최적화 된 MIME Multipart/Related Serialization을 설명합니다.
"HTTP SOAP Transmission Optimization Feature"은 SOAP 1.2 HTTP 바인딩을위한 추상 전송 최적화 기능의 구현을 설명합니다.
두 번째 문서를 읽을 경우 "첨부 파일"XML binary optimized "packages" 또는 XOP로 대체되었다는 것을 알게 될 것이다.
XOP 패키지는 확장 가능한 패키징 형식 (예 : MIME Multipart/Related, [RFC 2387] 참조) 내에 XML Infoset의 직렬화를 배치하여 만들어집니다. 그런 다음, base64로 인코딩 된 이진 데이터 인 컨텐츠의 선택된 부분이 추출되어 다시 인코딩됩니다 (즉, 데이터가 base64에서 디코딩 됨). 선택한 부분의 위치는 URI를 사용하여 패키지 된 데이터에 링크되는 특수 요소로 XML에 표시됩니다.
간단히 말해서 multipart/mime 메시지에서 데이터를 "첨부 파일"로 캡슐화하는 대신 데이터가 이제 "포인터"또는 링크로 참조됩니다. 다음 다이어그램 이해에 도움이 될 수 :
을 이제 우리는 배경을 가지고, 우리는 당신의 질문에 돌아올 수 있습니다.
서비스는 요청/응답의 MTOM 첨부 파일로 바이너리 데이터를 받아들이거나 서비스한다는 것을 어떻게 분명히합니까? 그렇지 않습니다. MTOM과의 첨부 개념은 없으므로 서버는 첨부 파일을 수락한다는 것을 선언 할 수 없습니다.
클라이언트는 주어진 서비스에 MTOM 첨부 파일을 사용하여 이진 데이터를 보내거나받을 수 있다는 것을 어떻게 올바르게 인식합니까? 위에서 말했듯이 "첨부 파일"이 지원되지 않으므로 클라이언트가이를 수행 할 방법이 없습니다.
xmime:contentType 정보 항목 속성이 허용하는 웹 서비스 응용 프로그램을 바이너리 요소에 의해 정의 된 바이너리 데이터의 처리를 최적화 할
은 상태 XML media types 다른 W3C 사양은 아직있다, 그런 말로 미루어 보아, 정보 항목이며 메타 데이터로 간주되어야합니다. xmime : contentType 속성의 존재는 요소 내용의 값을 변경하지 않습니다.
당신이 xmime:contentType 및 xmime:expectedContentTypes="application/octet-stream (* should not be used)를 사용하여 MTOM을 사용하면, 생성 된 WSDL이 같은 항목이됩니다
<element name="myImage" xmime:contentType="xsd:base64Binary" xmime:expectedContentTypes="application/octet-stream"/> 을이 그것이 XML 바이너리 최적화 된 패키지를받을 수 있음을 선언하는 서버의 방법은 (이다 이것은 multipart MIME 메시지로 나눌 수 있습니다). 클라이언트가 위의 내용을 볼 때
클라이언트는 서버가 XML 바이너리 최적화 된 패키지를 받아 들일 수 있습니다 알고 정의 Identifying XOP Documents 적절한 HTTP 요청을 생성로 식별됩니다
XOP 문서, MIME 같은 시스템에 사용, 원래 XML 직렬화의 관련 내용 유형을 전달하는 필수 "type"매개 변수가있는 "application/xop + xml"미디어 유형.
희망 하시겠습니까?
