3줄 요약:
MS기반의 WebService 프레임웍에서는 MIME mutipartRelated protocol 을 지원하지 않는다.
국세청 전자세금계산서에는 MIME mutipartRelated protocol 을 사용하는 웹서비스로 구성되어 있다.
국세청 전자세금계산서 전송은 MS 기반의 Framework 상으로 웹서비스 구현 불능.
국세청 전자세금계산서는 EDI 의 서명된 XML 문서를 전송하고,
응답받는 프로토콜로 그 전송 방식을 WebService 방식으로 적용한 것으로 보인다.
: CMS 프로토콜에서 널리 사용되던 100개씩 보내기를 사용하는 것으로 보아
CMS 프로토콜과 연관이 되어 있는 것으로 보인다.
사용기술 요소는 아래와 같다.
1. XML 정규화 및 전자서명
2. WebService Server Side Tech.
3. WebService Client Side Tech.
4. WSDL2 code(such as C#, java etc.)
5. SOAP Communication Protocol Tech.
(5)에서 치명적인 문제가 발견되었다.
전문의 설계과정에서
범용적인 방법이 아닌 관리가 편한 방식으로 설계하여, 특정 플랫폼에서만 동작하는 프로토콜이 정의되었다.
다시 말해서, 주관사에서 쓰기 편한 방식으로 설계했다는 것이다.
WebService는 일반적으로 soap(Simple Object Access Protocol) 방식으로 통신하는데,
그 기반에는 object <-> xml 간의 serialize 을 기반으로 하고 있다.
즉, object의 인스턴스를 xml로 변환하여 전송하고, 받는 쪽에서는 xml을 받아 object 로 변환하여 처리한다.
설계과정에서 메시지를 통신수준과 데이터수준을 서로 구분하여 전송하도록 하였다.
여기서 문제가 통신 수준과 데이터 수준의 두 개의 파트르 새로운 object 로 연결하여,
하나의 soap literal 로 해주었으면 좋았을 것을 설계편의성을 위해
데이터 수준을 첨부파일로 처리했다는 것이다.
(5)Communication Protocol Tech. 레벨에서 첨부파일 처리를 위해서
Soap서 처리할 수 있는 방식이 아닌 MIME을 선택한 것은 치명적인 실수로 보인다.
WebService에서 MIME은 현재 범용적으로 사용되는 binary 전송을 위한 표준이 아니다.
Base64 Binary나 HexString Binary 형식이 제안되어 있지만, 크기가 1.33 배, 2 배로 커지는 약점이 있어
현재는 MIME을 확장한 MTOM 이라는 방식이 표준으로 제안되어 있다.
따라서, 기존의 벤더들 중에서 MIME을 지원하지 않던 벤더는 MTOM을 지원하는 것으로
binary를 1:1 로 전송할 수 있게 되므로 MIME을 추가 지원할 필요성을 느끼지 못하는 것이다.
MIME이라는 것이 워낙 광범위한 스펙이고,(당신이 아는 MIME의 Content-Type 만 해도 10가지는 넘는다)
스스로 확장하는 스펙이다 보니(application/TopChul 이라고 만들어 놓고 우기면, 이것도 MIME이다.)
결국 모든 MIME Content-Type 에 대해서 대응하는 객체를 논리적으로 제공할 수 없기 때문에.
MIME의 한 Content-type으로 MTOM 을 재정의하고,
MIME의 subset 인 MTOM 을 제공하는 것으로 MIME 지원을 마무리 지은 것이다.
결국 여기에서 벤더(개발사)에 대한 문제가 붉어져 나왔다.
java 진영에서는 axis에서 mime을 지원한다. octet-stream 형식은 일단 지원하는 것 같다.
MS 진영에서는 MIME을 지원하지 않는다. - 앞으로도 계획이 없을 듯 싶다.(MTOM이 있으니까.)
결론 wsdl에 binding/operation 에 <mime:multipartRelated> 가 있는 웹서비스를
Framework 상으로 MS에서 프락시 생성(wsdl.exe wse3wsdl.exe svcutil.exe)이 불가능하다.
이것이 MS에 케이스까지 열면서 얻은 결론이고,
플랫폼 종속적인 업체가 표준을 제안함으로 인해서 발생하는 문제다.
참 길게 미움을 표현했는데, 무지의 무지에 의한 무지를 위한 표준
이것은 횡포다.
