검수요청.png검수요청.png

"SOAP"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
(등장배경)
(단점)
40번째 줄: 40번째 줄:
 
* [[XML]]을 근간으로 하여 태그 형태로 메세지를 보내기 때문에 다른 기술들에 비교해서 상대적으로 느리다.
 
* [[XML]]을 근간으로 하여 태그 형태로 메세지를 보내기 때문에 다른 기술들에 비교해서 상대적으로 느리다.
 
* 중량급 아키텍처의 경우 중량 프로토콜이다.
 
* 중량급 아키텍처의 경우 중량 프로토콜이다.
 +
* 서로 다른 인프라를 바탕으로 컴포넌트를 연결하는 표준이 필요하다.{상호 운영성(Interoperability)}
  
 
===XLM===
 
===XLM===

2019년 7월 24일 (수) 12:57 판

SOAP(Simple Object Access Protocol)는 XML(Extensible Markup Language)을 근간으로 메세지를 네트워크상에서 주고받으며 웹서비스가 통신할 수 있게 해주는 프로토콜이다. 한국어로 , 소웁 또는 에스오에이피라고 읽는다.

개요

SOAP(Simple Object Access Protocol)는 웹서비스를 이용하기 위해 정해 놓은 프로토콜이다. 기업을 위한 비즈니스 응용에서부터 출발하였으며 IBM, 오라클 등을 선두로 하는 웹서버 벤더에서 주창한다. 보통 RPC(Remote Procedure Call) 패턴으로, 웹 서비스 클라이언트에서 웹 서비스 서버 쪽으로 메시지를 요청하고, 서버는 그 메시지에 반응하게 된다. SOAP의 강점은 많은 '표준'에서 나온다. SOAP의 표준을 지키면서 서비스를 구현한다면 다른 세세한 체제는 필요 없이 다른 언어, 다른 플랫폼에서도 서비스를 구현할 수 있다. 사용 가능한 트랜스포트 프로토콜은HTTP, HTTPS, SMTP가 있으며 XML을 근간으로 하는 프로토콜이다. 레스트풀(RESTful)보다 상대적으로 개발이 어렵고 Tool이 필요한 경우가 많아서 서로 비교 대상으로 자주 오른다.[1]

구성

  • SOAP(SOAP Envelope)
  • SOAP Header
  • SOAP Body
  • SOAP Encoding Rule
  • SOAP RPC Representation

등장배경

과거에도 DCOM이나 CORBA와 같은 방법으로 RPC를 사용해 인터넷 상에서 의사소통을 할 수 있었지만, 호환성과 보안의 문제로 일반적인 방화벽은 이런 종류의 트래픽을 차단하기 때문에 문제였다. HTTP는 모든 인터넷 브라우저와 서버에 의해 지원되기 때문에 응용 프로그램간에 통신이 더 용이하고 HTTP의 이 점을 활용하기 위해 만들어졌다.[2] HTTP는 모든 인터넷 브라우저 및 서버에서 지원되므로 응용 프로그램간에 통신하는 가장 좋은 방법은 HTTP를 통한 것이다.

동작 방식

SOAP 웹 서비스에서는 웹 서비스 제공자와 요청자 간에 SOAP 프로토콜로 메시지를 주고받는 방식으로 서비스를 이용한다. 웹 서비스 요청자가 요청을 SOAP으로 서비스 제공자에게 전달하면, 서비스 제공자는 이를 적절한 서비스 로직을 통하여 결과를 얻고, 그 결과를 다시 서비스 요청자에게 반환한다.[3]

구문 규칙

SOAP의 중요한 몇가지 구문규칙으로는

  1. SOAP 메시지는 XML을 사용하여 인코딩되어야한다.
  2. SOAP 메시지는 SOAP Envelope 네임 스페이스를 사용한다.
  3. SOAP 메시지는 SOAP 인코딩 네임 스페이스를 사용한다.
  4. SOAP 메시지에는 DTD 참조가 없어야 한다.
  5. SOAP 메시지에는 XML 처리 지침이 포함되면 안된다.

특징

  • SOAP은 XML을 기반으로 플랫폼에 독립적 이다. SOAP 에 의미는 S의 imple의 O bject CCESS의 P의 rotocol 로 메시지를 보내고받는 형식에 응용 프로그램 통신 프로토콜 이며, 서로 다른 운영 체제에서 실행되는 응용 프로그램간에 서로 다른 기술과 프로그래밍 언어로 통신하는 방법을 제공한다.[4]
  • 많은 Application Layer Protocol의 경우 TCP또는 UDP포트를 사용하기 때문에 인터넷상에 설치되어 있는 방화벽에 많은 제약을 받게 되지만 SOAP는 HTTP와 같이 프록시 와 방화벽 에 구애 받지않고 통신이 가능하다.

장점

  • HTTP기반으로, HTTP와 같이 프록시방화벽에 구애받지 않고 통신이 가능하다.
  • 독립적이기 때문에 언어나 플랫폼에 의존적이지 않다.
  • 에러 처리에 대한 내용이 기본적으로 내장 되어 있다.
  • 레스트풀 방식에 비하면 복잡하다고 하지만 그래도 간단하며 확장이 용이하다.
  • 다양한 네트워크 프로토콜을 사용 한다.
  • 간단하고 확장 가능하며, (멀티파트 MIME 구조를 사용하여) 첨부를 통합하는 SOAP XML 메시지를 지원한다.

단점

  • XML을 근간으로 하여 태그 형태로 메세지를 보내기 때문에 다른 기술들에 비교해서 상대적으로 느리다.
  • 중량급 아키텍처의 경우 중량 프로토콜이다.
  • 서로 다른 인프라를 바탕으로 컴포넌트를 연결하는 표준이 필요하다.{상호 운영성(Interoperability)}

XLM

XLM은 사람이 읽을 수있는 것으로 대부분 SOAP 메시지를 쉽게 이해할 수 있지만 CORBA (Common Object Request Broker Architecture ) 및 RPC (Remote Procedure Call ) 프로토콜 과 비교하여 메시지가 상대적으로 커진다.확장 가능한 마크업 언어 이며, HTML에서 문서의 내용을 구체적으로 전달할 수 있는 태그를 정의하는 것이 추가된 언어라고 할 수 있다.

SOAP API

  • 데이터를 요청하고 응답을 위한 인터페이스 이다.
  • SOAP는 웹 서비스 / SOA 프레임 워크의 컨텍스트에서 거의 항상 사용되는 프로토콜 이다. 따라서 API (Application Programming Interface )는 일반적으로 SOA 용 상위 인터페이스에 의해 숨겨지고, 거의 모든 최신 프로그래밍 언어에서 사용할 수 있는 SOA API 미들웨어 도구가 있으며 Microsoft는 다양한 NET SOAP / SOA 도구를 제공한다.

레스트풀과 비교

레스트풀(RESTful) 방식보다 상대적으로 개발이 어렵고 툴(tool)이 필요한 경우가 많아서 서로 비교 대상으로 자주 오른다. SOAP 기반의 웹서비스를 사용하고자할 때에는 웹서비스의 위치(바인딩 주소)뿐 아니라 오퍼레이션을 알아야 하는 반면, 레스트풀(RESTful) 웹서비스를 사용하고자 할 때에는 대상 리소스의 URL만 파악하면 된다. 이것은 모든 레스트풀(RESTful) 웹서비스가 HTTP 메소드라는 공통의 인터페이스를 이용하므로 가능한 일이라 하겠다.[1]

평가 와 전망

SOAP은 SOA (Service Oriented Architecture)에서 웹 서비스를 연결하는 데 처음으로 널리 사용되는 프로토콜이었다. 오늘날 분산 응용 프로그램의 거의 모든 현대적인 개발은 RESTful 원칙을 기반으로 한다. SOAP은 거의 항상 레거시 응용 프로그램과 프로젝트에만 국한되어 있으며 시간이 지남에 따라 사용이 감소 할 것이다.[5]

각주

  1. 1.0 1.1 박유미 연구원 외 4명, 〈SOAP 기반 웹서비스와 RESTFUL 웹서비스 기술 비교〉, 《전자통신 동향분석》, 2010-04
  2. Interesting Life♬, 〈SOAP[Simple Object Access Protocol]〉,《티스토리》, 2011.08.08
  3. 개발자의 길, 〈SOAP 동작 방식, soap 통신이란? 〉, 《티스토리》, 2010-02-26
  4. w3스쿨 공식 사이트, 〈XML 비누〉,《w3schools》
  5. Margaret Rouse, 〈SOAP (단순 개체 액세스 프로토콜)〉,《테크타깃》

참고자료

같이 보기


  검수요청.png검수요청.png 이 SOAP 문서는 프로그래밍에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.