웹 서비스를 자주 다루다보니 이젠 SOAP에 익숙해질 법도 하다. 그런데 여전히 SOAP의 정의가 Simple Object Access Protocol이란 점을 생각하면 웃음만 나온다.
SOAP이 어딜 봐서 간단하다는건지. SOAP의 근간을 이루고 있는 XML Schema해도 벌써 골이 아플 지경이다. 솔직히 VS.NET 같은 훌륭한 지원 도구가 없다면 접근하기조차 쉽지 않다. 프로젝트를 진행하면서 유효성 테스트도 통과 못하는 엉터리 XML Schema도 많이 봤다. 아마도 그들은 VS.NET과 같은 도구의 도움조차 받지 못했을 것이다.
결론적으로 SOAP이 쉽다는 것은 이 프로토콜을 홍보하는 벤더 직원이나 하는 말이다.
P.S. 그렇다고 해서 SOAP이 쓸모없는 고철 덩어리에 지나지 않다는 말은 절대 아니다. 어지간히 복잡한 객체도 표현해 낼 수 있는 확장성 때문에 주요 벤더들이 SOAP을 지원하는 것이다.
Author Details
Kubernetes, DevSecOps, AWS, 클라우드 보안, 클라우드 비용관리, SaaS 의 활용과 내재화 등 소프트웨어 개발 전반에 도움이 필요하다면 도움을 요청하세요. 지인이라면 가볍게 도와드리겠습니다. 전문적인 도움이 필요하다면 저의 현업에 방해가 되지 않는 선에서 협의가능합니다.
일종의 낚시랄까요? ^^
SOAP is simple?
SOAP is simple?
SOAP이 쉽다는 것은 이 프로토콜을 홍보하는 벤더 직원이나 하는 말이다.
110% 동감!
…
풋, 다들 동감하시는군요. 처음에는 유효성 통과도 못하는 SOAP 포맷을 내미는 업체를 보고 어이없다고 생각했는데, 시간이 지날수록 이해가 되더라구요.
http://www.w3.org/TR/soap/의 권고 문서들을 보시면 SOAP 1.1은 Simple Object Access Prtocol이라고 명시하지만, 1.2는 그냥 SOAP 1.2라고 되어있습니다. 이는 이미 1.2 저자들이 SOAP은 Simple…이 아니라고 하면서 시작해서 그렇습니다. 아마 권고 문서내에도 약자를 풀어쓴 부분은 없을 것입니다.
XML Schema는 이미 전문가 사이에도 XML 표준 중에서 가장 복잡한 표준으로 자리매김을 했습니다. 너무 복잡해서 만든 사람들조차 표준의 Mismatch가 왜 그렇게 되어버렸는지 모를 정도로 말이죠.
아하, 말씀하신 내용은 처음 들었습니다. 재미있네요. 하지만 SOAP으로 구글링해보면 Simple Object Access Protocol이 최상단에 제시되니 1.2에 참여한 사람들도 뻘쭘하겠습니다.
엄밀히 이야기하면 풀어쓰는 것을 그만 둔 것은 표준을 쓰는 중간이었습니다. 그래서 섞여 있을 수 있겠죠. 반면 “Simple Object Access Protocol”이라고 치면 1.2의 내용은 첫페이지에 거의 안나옵니다. 이전에 그 내용을 어떤 메일링 리스트에서 봤는데 찾지 못했는데, 그냥 Wikipedia에서 보니까 설명이 되어있네요.
At the time of the creation of the standard, SOAP was an acronym for “Simple Object Access Protocol”. Version 1.2 of the standard, which became a W3C Recommendation on June 24, 2003, dropped this acronym as it was considered to be misleading. (http://en.wikipedia.org/wiki/SOAP)
Wikipedia 만쉐이~ ㅎㅎㅎ
아주 상세히 알고 계시네요. 결과적으로는 전혀 Simple하지 않게 됐습니다만, 복잡한 비즈니스 로직도 구현할 수 있어서 불만은 없습니다. 그런데 제발 유효성 테스트를 통과도 못하는 포맷은 자제해주었으면 하네요. 4, 5개 업체(8곳 정도로 계산해야 할지도…)와 XML 웹 서비스를 구축해봤는데, 마이크로소프트를 제외하곤 엉망이었습니다. -_-
데이비드 채팰의 세미나에서 한말은
벤더가 표준을 만들었다는 것외에
ㅋㅋ
다분이 정치적이죠!
거기에 프로토콜이 텍스트니까. 길필요가 없는 것도 길어지는 *_*
하여튼 벤더끼리 합의 했다는 것에 무게 두는 발언을 했지요!
세미나라는 것이 기업IT예산의 70%는 통합에 소요라는 기사에서 언급된 강연을 말씀하시는 건가요? "앞으로는 대부분의 새로운 엔터프라이즈 소프트웨어의 기본적인 아키텍처로 SOA가 채택될 것"라는 말에는 저도 동의합니다. SOAP이 복잡하긴 해도 장점도 많으니까요. 무엇보다 벤더 간의 합의가 이뤄졌기 때문에 시스템 통합이란 면에서 유리하고, 복잡하다는 면을 희석시켜 줄 자동화 도구가 개발되고 있다는 점을 무시할 수 없겠죠.
http://jrcho.com/blog/317
그리고 SOA와 SOAP은 다른 것으로 알고 있습니다.
SOAP만으로 구현할 수 있은 시스템은 없을 것
같습니다.
흔히 말하는 레가시 시스템은 어떻게 할지는 ㅋㅋ
SOAP와 SOA는 물론 다르죠. 하지만 데이비드 채팰이 SOA를 언급할 땐 분명히 XML 웹서비스를 염두에 둔 것 같습니다. SOA 구현에 사용하는 프로토콜이 SOAP만 있는 것은 아니지만, 그런 의미에서 드린 말씀이었습니다.
국내의 블로그 서비스 중에 RSS 규격도 잘 못지키는 곳들이 넘치는데, SOAP 정도면 더 하겠죠. 표준 문서가 공개되어 있는데도 그걸 지키지 못하더군요. 한 마디로 남의 구현 보고 베끼기는 잘 하지만 문서 찾아보는 건 게으르다는 것을 의미합니다.
솔직히 SOAP의 스펙이 워낙 복잡해서 문서를 봐도 제대로 개발하기 쉽지 않을 것 같습니다. 하지만 유효성 검사 도구로 테스트는 해 봤어야 한다고 생각합니다. 구하기 어렵지도 않은데 말이죠. 그런 면에선 게으르다는 비난을 피하기 힘들겠네요.