비누.

SOAP
이 기사는 컴퓨터 네트워크 프로토콜에 대한 것입니다.세척에 사용되는 계면활성제는 비누를 참조하십시오.기타 용도는 비누(동음이의)를 참조하십시오.
비누.
Webservice xrpc.png
가족메시징 프로토콜
설계자Dave Winer, Don Box, Bob Atkinson 및 Mohsen Al-Ghosein
처음 등장한1998년 6월에 XML-RPC로 처음 출시되었으며, 24년 전(1998년 6월)
안정된 릴리스
1.2 / 2007년 4월 27일; 15년 전 (2007-04-27)

SOAP(이전의 Simple Object Access Protocol용 백로닉)는 컴퓨터 네트워크에서 웹 서비스를 구현할 때 구조화된 정보를 교환하기 위한 메시징 프로토콜 규격입니다.메시지 형식에 XML Information Set을 사용하며, 일부 레거시 시스템은 SMTP(Simple Mail Transfer Protocol)를 통해 통신하지만 대부분의 경우 HTTP(Hypertext Transfer Protocol)라는 애플리케이션 계층 프로토콜에 의존합니다.

SOAP을 사용하면 개발자는 서로 다른 운영 체제(Windows, MacOS, Linux 등)에서 실행되는 프로세스를 호출하여 Extensible Markup Language(XML)를 사용하여 인증, 인가 및 통신할 수 있습니다.HTTP와 같은 웹 프로토콜은 거의 모든 운영 체제에서 설치되고 실행되므로 SOAP을 통해 클라이언트가 웹 서비스를 호출하고 언어와 플랫폼에 관계없이 응답을 받을 수 있습니다.

특성.

SOAP은 웹 서비스용 웹 서비스 프로토콜 스택의 메시징 프로토콜 계층을 제공합니다.이 프로토콜은 다음 세 부분으로 구성된 XML 기반 프로토콜입니다.

  • 메시지[1] 구조와 처리 방법을 정의하는 봉투
  • 응용 프로그램 정의 데이터 유형의 인스턴스를 표현하기 위한 부호화 규칙 세트
  • 절차 호출과 응답을 나타내는 규칙

SOAP에는 다음 3가지 주요 특징이 있습니다.

  1. 확장성(보안과 WS-Addressing은 개발 중인 확장 기능 중 하나)
  2. 중립성(SOAP은 HTTP, SMTP, TCP, UDP 등의 모든 프로토콜로 동작 가능)
  3. 독립성(SOAP은 모든 프로그래밍 모델을 허용합니다)

SOAP 프로시저가 무엇을 할 수 있는지를 나타내는 예로서 어플리케이션은 검색 파라미터를 사용하여 SOAP 요구를 부동산 가격 데이터베이스 등의 웹 서비스가 유효한 서버에 송신할 수 있습니다.그런 다음 서버는 SOAP 응답(예: 가격, 위치, 기능)을 반환합니다.생성된 데이터는 표준화된 머신 퍼서블 형식으로 제공되므로 요청 애플리케이션은 데이터를 직접 통합할 수 있습니다.

SOAP 아키텍처는 다음 사양의 여러 레이어로 구성됩니다.

  • 메시지 형식
  • 메시지 교환 패턴(MEP)
  • 기본 전송 프로토콜 바인딩
  • 메시지 처리 모델
  • 프로토콜 확장성

SOAP는 XML-RPC의 후계자로서 진화했습니다만, 그 트랜스포트나[2] 인터랙션의 중립성은 Web Service Addressing으로부터, 엔벨로프/헤더/바디는 다른 곳(아마 [citation needed]WDDX로부터)으로부터 차용하고 있습니다.

역사

SOAP은 객체 액세스 프로토콜로 설계되어 1998년 6월에 Atkinson과 Al-Ghosein이 [3]근무하던 Microsoft용 Dave Winer, Don Box, Bob Atkinson 및 Mohsen Al-Ghosein에 의해 Frontier 5.1의 일부로 XML-RPC로 출시되었습니다.이 사양은 1999년 [4][5]9월 13일에 IETF에 제출될 때까지 사용할 수 없었습니다.Don Box에 따르면,[6] 이것은 마이크로소프트 내부의 정치 때문이다.마이크로소프트의 망설임 때문에 [7]Dave Winer는 1998년에 XML-RPC를 출시했습니다.

제출된 인터넷 초안은 RFC 상태에 도달하지 못했기 때문에 "웹 표준"으로 간주되지 않습니다.사양 버전 1.1은 2000년 [8]5월 8일에 W3C 노트로 발행되었습니다.버전 1.1은 W3C 권장 상태에 도달하지 않았기 때문에 "Web 표준"으로 간주할 수도 없습니다.단, 이 사양의 버전 1.2는 2003년 6월 24일에 W3C 권장사항이 되었습니다.

SOAP 사양은[9] World Wide Web Consortium의 XML Protocol Working[10] Group이 2009년 7월 10일 폐쇄될 때까지 유지되었습니다.SOAP은 원래 "Simple Object Access Protocol"의 약자였지만 표준 버전 1.2에서는 이 [11]약자를 삭제했습니다.

SOAP가 처음 도입된 후 WSDL, XSD 및 UDDI에 기반한 보다 복잡한 웹 서비스 세트의 기본 계층이 되었습니다.이러한 다양한 서비스, 특히 UDDI는 관심이 훨씬 적다는 것이 입증되었지만, 이러한 서비스의 진화를 통해 실제로 웹 서비스가 어떻게 발전해왔는지에 비해 SOAP의 기대되는 역할을 완전히 이해할 수 있습니다.

SOAP 용어

SOAP 사양은 프로토콜 개념, 캡슐화 개념 및 네트워크 [12]개념의 세 가지 개념 컴포넌트로 구성되도록 광범위하게 정의할 수 있습니다.

프로토콜 개념

비누.
이것은 SOAP 송신자와 SOAP 수신자 간에 교환되는 정보의 형식 및 처리 규칙을 공식화하고 관리하는 규칙 세트입니다.
SOAP 노드
이들은 SOAP 메시지를 전송/전송, 수신 및 처리하는 데 사용되는 처리 장치가 있는 물리/논리 머신입니다.이것들은 네트워크의 노드와 비슷합니다.
SOAP 역할
SOAP 메시지의 경로를 통해 모든 노드가 특정 역할을 수행합니다.노드의 역할은 노드가 수신한 메시지에 대해 수행할 액션을 정의합니다.예를 들어, 역할 "none"은 어떤 노드도 SOAP 헤더를 처리하지 않고 단순히 해당 경로를 따라 메시지를 전송하지 않음을 의미합니다.
SOAP 프로토콜 바인딩
SOAP 메시지는 네트워크를 통해 전송되는 다른 프로토콜과 함께 작동해야 합니다.예를 들어 SOAP 메시지는 메시지를 전송하기 위한 하위 계층 프로토콜로 TCP를 사용할 수 있습니다.이러한 바인딩은 SOAP 프로토콜 바인딩 [13]프레임워크에서 정의됩니다.
SOAP 기능
SOAP은 메시징 프레임워크만 제공합니다.다만, 신뢰성, 시큐러티등의 기능을 추가하도록 확장할 수 있습니다.SOAP 프레임워크에 기능을 추가할 때 따라야 할 규칙이 있습니다.
SOAP 모듈
SOAP 헤더의 의미론에 관한 사양의 집합.SOAP 상에서 확장되는 새로운 기능을 기술합니다.모듈은 0개 이상의 기능을 실현해야 합니다.SOAP에서는 모듈이 소정의 [14]규칙을 준수해야 합니다.

데이터 캡슐화 개념

SOAP 메시지
2개의 SOAP 노드 간에 교환되는 정보를 나타냅니다.
SOAP 봉투
이것은 SOAP 메시지로 식별되는 XML 메시지의 둘러싸는 요소입니다.
SOAP 헤더 블록
SOAP 헤더에는 이러한 블록 중 여러 개를 포함할 수 있습니다.각 블록은 헤더 내의 개별 계산 블록입니다.일반적으로 SOAP 역할 정보는 경로상의 노드를 대상으로 사용됩니다.헤더 블록의 SOAP 역할이 SOAP 노드가 동작하는 역할의 이름일 경우, 헤더 블록은 SOAP 노드를 대상으로 한다고 불립니다.(예: 역할 속성이 ultimateReceiver인SOAP 헤더블록은 이 역할을 가진 수신처 노드만을 대상으로 합니다.다음에 롤 속성을 가지는 헤더는, 행선지 노드 뿐만이 아니라, 각 중간 노드도 대상으로 합니다).
SOAP 헤더
각 SOAP 리시버를 대상으로 하는1개 또는 복수의 헤더블록의 집합.
SOAP 본체
SOAP 리시버 앞으로 메시지 본문을 포함합니다.SOAP 본문의 해석과 처리는 헤더블록에 의해 정의됩니다.
SOAP 장애
SOAP 노드가 SOAP 메시지를 처리하지 못한 경우 장애 정보를 SOAP 장애 요소에 추가합니다.이 요소는 SOAP 본문 내에 자 요소로 포함되어 있습니다.

메시지 발신자 및 수신자 개념

SOAP 송신기
SOAP 메시지를 전송하는 노드.
SOAP 수신기
SOAP 메시지를 수신하는 노드.(중간 노드 또는 수신처 노드일 수 있습니다).
SOAP 메시지 경로
SOAP 메시지가 수신인 노드에 도달하기 위해 통과한 모든 노드로 구성된 경로.
초기 SOAP 송신자
이것은 송신하다SOAP 메시지를 발신한 노드입니다.이것은 SOAP 메시지 경로의 루트입니다.
SOAP 매개체
SOAP 발신기지와 목적의 SOAP 수신처 사이에 있는 모든 노드.타깃 SOAP 헤더블록을 처리하여 SOAP 메시지를 최종 SOAP 리시버로 전송합니다.
Ultimate SOAP 수신기
SOAP 메시지의 수신처 수신인.이 노드는 메시지 본문과 메시지 본문을 대상으로 하는 헤더블록을 처리합니다.

사양

SOAP 구조

SOAP 사양에서는 메시징 프레임워크를 정의하고 있습니다.메시징 프레임워크는 다음과 같이 구성됩니다.

  • SOAP[15] 메시지 처리 규칙을 정의하는 SOAP 처리 모델
  • SOAP 기능과 SOAP[15] 모듈의 개념을 정의하는 SOAP 확장성 모델
  • SOAP[15] 노드 간에 SOAP 메시지를 교환하는 데 사용할 수 있는 기본 프로토콜에 대한 바인딩을 정의하는 규칙을 설명하는 SOAP 기본 프로토콜 바인딩 프레임워크
  • SOAP[15] 메시지의 구조를 정의하는 SOAP 메시지 구성

SOAP 구성 요소

SOAP 메시지는 다음 요소를 포함하는 일반적인 XML 문서입니다.

요소 묘사 필수의
봉투 XML 문서를 SOAP 메시지로 식별합니다. 네.
헤더 헤더 정보가 포함됩니다. 아니요.
몸 콜 및 응답 정보가 포함됩니다. 네.
결함. 메시지 처리 중 발생한 오류에 대한 정보를 제공합니다. 아니요.

수송 방법

SMTP와 HTTP는 모두 SOAP 전송에 사용되는 유효한 애플리케이션 계층 프로토콜이지만 HTTP는 오늘날의 인터넷 인프라와 잘 작동하기 때문에 널리 받아들여지고 있습니다. 특히 HTTP는 네트워크 방화벽과 잘 작동합니다.SOAP은 HTTPS(애플리케이션레벨에서는 HTTP와 같은 프로토콜이지만 그 아래에서는 암호화된 트랜스포트 프로토콜을 사용)를 통해서도 사용할 수 있습니다.이것은 WS-I Basic Profile 1.1에서 설명한 바와 같이 웹 서비스 보안을 제공하기 위해 권장되는 WS-I 방식입니다.

이는 보통 방화벽에 의해 필터링되는 GIOP/IIOP 또는 DCOM과 같은 다른 분산 프로토콜에 비해 큰 이점입니다.SOAP over AMQP는 일부 구현에서 지원되는 또 다른 가능성입니다.또, SOAP 는 DCOM 에 비해, 송신 노드와 수신 노드의 양쪽 모두에 관한 지식이 필요한 머신에 설정되어 있는 시큐러티 권한의 영향을 받지 않는 이점이 있습니다.이것에 의해, SOAP는 DCOM에서는 불가능한 방법으로 느슨하게 결합할 수 있습니다.SOAP-over-UDP OASIS 규격도 있습니다.

메시지 형식

XML Information Set이 표준 메시지 형식으로 채택된 것은 주요 기업에서 널리 사용되고 오픈 소스 개발 노력 때문입니다.일반적으로 XML 정보 세트는 XML로 일련화됩니다. 자유롭게 사용할 수 있는 다양한 도구를 사용하면 SOAP 기반 구현으로 쉽게 전환할 수 있습니다.XML의 구문이 다소 길면 장점과 단점이 모두 될 수 있습니다.인간의 가독성을 촉진하고 오류 검출을 용이하게 하며 바이트 순서(엔디안니스) 등의 상호 운용성 문제를 회피하지만 처리 속도가 느려 번거로울 수 있습니다.예를 들어 CORBA, GIOP, ICE 및 DCOM에서는 훨씬 더 짧은 바이너리메시지 형식을 사용합니다.한편, 하드웨어 어플라이언스는 XML 메시지의 [16][17]처리를 고속화할 수 있습니다.바이너리 XML은 XML의 throughput 요건을 합리화하기 위한 수단으로서도 검토되고 있습니다.XML 메시지의 자체 문서화 성질상 오버헤드는 일반적으로 메시지 전체의 오버헤드가 비교적 적었던 이전의 프로토콜에 비해 실제 데이터보다 많은 오버헤드(헤더, 중첩 태그, 구분자 등)를 가집니다.

금융 메시지에서 SOAP는 이전 프로토콜인 FIX(금융 정보 교환) 및 CDR(공통 데이터 표현)[18]보다 2-4배 더 큰 메시지를 발생시키는 것으로 나타났습니다.

XML 정보 세트를 XML로 시리얼화할 필요는 없습니다.예를 들어 CSV 및 JSON XML-infoset 표현 등이 있습니다.범용 변환 프레임워크를 지정할 필요도 없습니다.SOAP 바인딩의 개념에서는 특정 응용 프로그램의 특정 바인딩을 허용합니다.단점은 송신측과 수신측 모두 새로 정의된 바인딩을 지원해야 한다는 것입니다.

메시지 예시(HTTP로 캡슐화)

아래 메시지는 AT&T(스톡 티커 기호 "T")의 주가를 요청하는 메시지입니다. 

POST / InStock HTTP/1.1 호스트: www.example.org Content-Type: application/content+xml; charset=utf-8 Content-Length: 299 SOAPAction:"http://www.w3.org/2003/05/soap-envelope" <?xml version="1.0"?> <http://www.w3.org/2003/05/soap-envelope:엔벨로프 xmlns:filength="http://www.w3.org/2003/05/soap-envelope" xmlns:m="http://www.example.org"> <filength:Header > </soap:헤더> <soap:본문> <m:Get Stock Price > <m:Stock Name >T </m: StockName> </m:Get Stock Price > </soap:본문> </soap:봉투 >

테크니컬 비평

이점

  • SOAP의 중립성 특성은 모든 전송 프로토콜에서 사용하기에 적합합니다.구현에서는 종종 HTTP를 전송 프로토콜로 사용하지만 다른 일반적인 전송 프로토콜을 사용할 수 있습니다.예를 들어 SOAP은 SMTP[19][20], JMS 및 메시지큐에서도 사용할 수 있습니다.
  • SOAP는 HTTP 포스트/리스폰스 교환과 결합하면 기존 방화벽과 프록시를 통해 쉽게 터널링되므로 HTTP 포스트/리스폰스 교환 처리를 위해 존재하는 광범위한 컴퓨팅 및 통신 인프라스트럭처를 변경할 필요가 없습니다.
  • SOAP은 XML 네임스페이스를 통한 쉬운 국제화 및 확장성 등 XML의 모든 기능을 이용할 수 있습니다.

단점들

  • 표준 구현 및 기본 SOAP/HTTP 바인딩을 사용하는 경우 XML infoset은 XML로 시리얼화됩니다.내장 바이너리 오브젝트를 사용하는 XML의 특수한 경우 성능을 향상시키기 위해 메시지 전송 최적화 메커니즘이 도입되었습니다.
  • HTTP를 전송 프로토콜로 사용하고 웹 서비스 주소 지정이나 Enterprise Service Bus를 사용하지 않을 경우 대화 당사자의 역할은 고정됩니다.한쪽(클라이언트)만이 다른 한쪽의 서비스를 사용할 수 있습니다.
  • SOAP은 이름보다 덜 단순합니다.프로토콜의 장황함, XML의 느린 구문 분석 속도, 표준화된 상호 작용 모델의 부족으로 인해 HTTP 프로토콜을 보다 직접적으로 사용하는 서비스가 우세하게 되었습니다.예를 들어 REST를 참조하십시오.
  • SOAP은 프로토콜에 구애받지 않기 때문에 REST의 Uniform Interface 또는 캐싱과 같은 프로토콜별 기능 및 최적화를 활용할 수 없습니다. 대신 WS-Addressing과 같이 이러한 기능을 다시 구현해야 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Hirsch, Frederick; Kemp, John; Ilkka, Jani (2007-01-11). Mobile Web Services: Architecture and Implementation. John Wiley & Sons (published 2007). p. 27. ISBN 9780470032596. Retrieved 2014-09-15. Simple Object Access Protocol (SOAP) defines a messaging envelope structure designed to carry application payload in one portion of the envelope (the message body) and control information in another (the message header).
  2. ^ "Web Services Addressing (WS-Addressing)". www.w3.org. Retrieved 2016-09-15.
  3. ^ "Exclusive .NET Developer's Journal "Indigo" Interview with Microsoft's Don Box". Dotnet.sys-con.com. Retrieved 2012-10-04.
  4. ^ "XML Cover Pages on the history of SOAP". Coverpages.org. Retrieved 2003-07-22.
  5. ^ "SOAP: Simple Object Access Protocol". September 1999.
  6. ^ "Don Box on the history of SOAP". XML.com. 2001-04-04.
  7. ^ "XML-RPC for Newbies". 1998-07-14. Archived from the original on October 12, 1999.
  8. ^ "W3C Note on Simple Object Access Protocol (SOAP) 1.1". W3C. 2000-05-08.
  9. ^ "SOAP Specifications". W3C. Retrieved 2014-03-29.
  10. ^ "W3C XML Protocol Working Group". W3C. Retrieved 2014-03-29.
  11. ^ "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". W3C. April 27, 2007. Retrieved 2012-06-15. Note: In previous versions of this specification the SOAP name was an acronym. This is no longer the case. (Underneath section 1. Introduction)
  12. ^ "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". www.w3.org. Retrieved 2016-09-14.
  13. ^ "Binding Framework Proposal". www.w3.org. Retrieved 2016-09-14.
  14. ^ "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". www.w3.org. Retrieved 2016-09-14.
  15. ^ a b c d "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)". www.w3.org.
  16. ^ "IBM Datapower". 306.ibm.com. 2011-11-30. Archived from the original on 2008-06-22. Retrieved 2012-10-04.
  17. ^ "IBM Zurich XML Accelerator Engine" (PDF). Archived from the original (PDF) on 2012-09-30. Retrieved 2012-10-04.
  18. ^ "Evaluating SOAP for High Performance Business Applications: Real-Time Trading Systems". Tenermerx Pty Ltd University of Technology, Sydney. 2011-11-30. Retrieved 2013-03-14.
  19. ^ "SOAP over JMS protocol". IBM. Retrieved March 22, 2020.
  20. ^ "SOAP-JMS FAQ". SOAP-JMS Binding Working Group. Retrieved March 22, 2020.

추가 정보

외부 링크