HTTP/SOAP가 "두꺼운"것으로 간주되는 이유

Question

SOAP/HTTP 웹 서비스 호출 스택이 "thick"또는 "heavyweight"라는 의견을 들었지만 그 이유를 정확히 알 수는 없습니다. SOAP envelope과 메시지의 serialization/deserialization 때문에 두꺼운 것으로 간주 될 것인가? 그것은 정말로 무거운 무게 조작인가?

고정 연결을 통한 원시/이진 데이터 전송과 비교했을 때 "두꺼운"것으로 간주됩니까?

아니면 다른 이유가 있습니까? 누구든지 이것에 대해 밝힐 수 있습니까?

Answer 1

SOAP는 HTTP 이외의 다른 전송을 사용할 정도로 충분히 추상적으로 설계되었습니다. 즉, 은이 HTTP의 특정 측면 (URL 및 메소드의 대부분 RESTful 사용, 예 : PUT /customers/1234 또는 GET /customers/1234)을 이용하지 않는다는 것을 의미합니다.

SOAP는 동일한 이유로 트랜스 포트와 무관하게 기존 TCP/IP 메커니즘을 우회합니다. 다시 말하지만, 이는 시퀀스 관리, 흐름 제어, 서비스 발견 (예 : 잘 알려진 포트에서 연결한다는 의미는 서비스가 존재 함을 의미) 등과 같은 전송을 이용할 수 없음을 의미합니다.

SOAP 용도 모든 직렬화에 대한 XML - XML ​​파서만으로 데이터를 "보편적으로 읽을 수 있음"을 의미하는 반면 효율적으로 기능을 발휘하려면 SOAP 파서가 정말 필요한 상용구를 많이 도입합니다. 그리고 그 시점에서 (소프트웨어 소비자로서) 당신은 어쨌든 XML의 이점을 잃었습니다. 당신이 어쨌든 그것을 처리하기 위해서 libSOAP을 필요로한다면 페이로드가 유선처럼 보이는지 신경을 씁니다.

SOAP은 인터페이스를 설명하기 위해 WSDL이 필요합니다. WSDL 자체는 문제가 아니지만 실제보다 훨씬 "동적 인"것으로 광고되는 경향이 있습니다. 대부분의 경우 단일 WSDL이 생성되고 생성자/소비자 코드가 자동 생성되므로 변경되지 않습니다. 전체적으로 보면 원래의 문제 (다른 서버 간 통신 방법)를 실제로 해결하지 않고도 많은 툴을 필요로합니다. 그리고 대부분의 SOAP 서비스는 HTTP를 통해 실행되기 때문에 원래 문제는 이며 이미 대부분은으로 시작되었습니다.

Answer 2

우선 서비스가 구현되는 방식에 따라 달라집니다. 즉, 메소드 서명 방식에주의하여 페이로드를 줄이면됩니다.

즉, 비누 봉투뿐만 아니라 메시지 자체가 유선형 바이너리 형식이 아닌 XML에서 훨씬 부피가 커질 수 있다고합니다. 올바른 클래스와 멤버 이름을 선택하면 많은 것을 줄일 수 있습니다. ...

물건 컬렉션을 반환하는 메소드의 일련 번호가 지정된 메소드 반환의 다음 예제를 고려하십시오. 반복되는 데이터 (예 : 목록/컬렉션/배열)를 반환하는 경우 클래스/래퍼 및 멤버의 올바른 [serialization] 이름을 선택하면 직렬화 된 SOAP 요청/응답의 자세한 표시가 크게 달라질 수 있습니다.

개요/짧은 이름 :

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ShortIDName> 
    <id>0</id> 
    <name>foo 0</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>1</id> 
    <name>foo 1</name> 
    </ShortIDName> 
    <ShortIDName> 
    <id>2</id> 
    <name>foo 2</name> 
    </ShortIDName> 
    ... 
</ArrayOfShortIDName> 

긴 이름 :

<?xml version="1.0" encoding="utf-8"?> 
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/"> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    <ThisClassHasALongClassNameIDName> 
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID> 
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName> 
    </ThisClassHasALongClassNameIDName> 
    ... 
</ArrayOfThisClassHasALongClassNameIDName> 

Answer 3

나는 특히, 그것은 SOAP 봉투는 메시지를 구성 오버 헤드의 많은 양을 추가하는 주로 생각 몇 가지 깊게 구조화 된 매개 변수 만 사용하는 간단한 요청의 공통적 인 경우입니다. 매개 변수가 URL 쿼리에 단순히 포함되는 REST 스타일 웹 서비스와 비교하십시오. 그런 다음

것과 WSDL과 전형적인 "기업"라이브러리 구현의 복잡성을 추가 ...

Answer 4

나는 그 때문에 포장 및 메시지를 풀고과 관련된 비교적 큰 오버 헤드의 "두께"(직렬화 및 역 직렬화 고려).

두 개의 32 비트 정수를 사용하는 Add이라는 웹 메서드를 사용하는 웹 서비스를 생각해보십시오. 호출자는 두 개의 정수를 패키지화하고 응답으로 단일 정수를받습니다. 실제로는 96 비트의 정보 만 전송되는 경우 SOAP 패킷을 추가하면 각 방향으로 약 3,000 개 이상의 추가 비트가 추가됩니다. 30 배 증가합니다.

메시지를 UTF-8 (또는 무엇이든) XML로 serialize 및 deserialize하는 것과 관련된 성능이 상대적으로 느립니다. 틀림없이 요즘은 꽤 빠르지 만 확실히 사소하지는 않습니다.

Answer 5

SOAP의 신호 대 잡음 비율이 너무 낮습니다. 간단한 대화의 경우 데이터 가치가없는 구조적 오버 헤드가 너무 많습니다. 너무 많은 명시 적 구성이 필요합니다 (JSON과 같은 암시 적 구성과 비교할 때).

그런 식으로 시작하지는 않았지만 표준위원회가 참여할 때 좋은 아이디어가 나올 때 포스터 - 아이가되었습니다.

Answer 6

WSDL 사양의 핵심 부분 인 XML 스키마는 실제로 실제로 크고 복잡합니다. 실제로, XML 스키마 맵핑과 같은 일을하는 도구는 XML 스키마 기능의 일부만을 지원합니다.

2 - WS- * 스펙 (예 : WS-Security 및 WS-SecureConversation)은 다시 크고 복잡합니다. Microsoft 또는 IBM이 완전히 구현할 수있는 자원보다 적은 자원을 제공 할 수 있도록 거의 설계되었습니다.

Answer 7

SOAP 및 WSDL은 매우 복잡한 표준으로 다른 표준 하위 집합을 지원하는 많은 구현이 있습니다. SOAP은 XML-RPC과 같은 방식으로 간단한 외부 함수 인터페이스에 잘 매핑되지 않습니다. 대신 올바른 SOAP 메시지를 생성하기 위해 XML 네임 스페이스, 봉투, 헤더, WSDL, XML 스키마 등을 이해해야합니다. XML-RPC 서비스를 호출하기 위해해야 ​​할 일은 정의하고 끝점을 지정하고 메서드를 호출하는 것입니다. 예를 들어, 루비 :

require 'xmlrpc/client' 

server = XMLRPC::Client.new2("http://example.com/api") 
result = server.call("add", 1, 2) 

XML-RPC 이외에도, 같은 일반 XML 또는 HTTP를 통해 JSON으로 훨씬 더 간단하고 경량이 될 수있는 다른 방법이 있다는 것을 암시하지만 (자주 REST이라 특정 다른 설계 고려 사항). HTTP를 통한 XML 또는 JSON과 같은 기능의 이점은 JavaScript 또는 양식 제출이있는 단순한 웹 페이지에서도 쉽게 사용할 수 있다는 것입니다. curl 같은 도구를 사용하여 명령 줄에서 쉽게 스크립팅 할 수도 있습니다. HTTP 라이브러리, XML 라이브러리 및 JSON 라이브러리는 거의 모든 곳에서 사용할 수 있으므로 JSON 파서를 사용할 수없는 경우에도 거의 모든 언어로 작동하므로 사용자가 직접 작성할 수 있습니다.

편집 : 내가 개념적으로 헤비급 SOAP이 얼마나 참조하고 있음을 명확히해야한다, 무거운 무게에 반대는 데이터의 원시 양의 측면에서입니다.데이터의 원시 금액이 덜 중요하다고 생각합니다. (작은 요청을 많이 처리해야하는 경우 빠르게 증가하지만) 개념적으로 헤비급이 얼마나 중요한지, 이는 무언가가 더 많은 곳이 더 많다는 것을 의미하므로 중요합니다. 비 호환성 등이있을 수있는 곳에서 잘못 될 수 있습니다.

Answer 8

첫 번째 포스터에 동의하지만 추가하고 싶습니다. 두껍고 얇은 정의는 상대적입니다. JSON 또는 REST와 같은 전송 기술을 사용하면 새로운 SOAP이 "안녕하세요 세상"의 사례로 무거워 보입니다. SOAP을 무겁게 만들고 WS 2.0을 일반적으로 만드는 것이 엔터프라이즈/강력한 기능이라는 것을 이미 알고있을 것입니다. JSON은 WS 2.0과 동일한 방식으로 안전하지 않습니다. 나는 SOAP가 두껍다고 언급 한 적이 없지만, 많은 XML 견과류는이 스펙을 무겁거나 두껍게 본다. 분명히하기 위해 나는 양쪽을 위해 그들의 장소가있는 것에 따라 어느 쪽이라도를 위해 또는 반대하지 않고있다. XML은보다 장황하고 사람이 읽을 수있어 "두꺼운"것입니다. 마지막 부분은 일부 사람들은 HTTP를 통해 지속되는 연결 프로토콜이 AJAX와 같은 새로운 웹 트렌드가 주어지면 큰 페이지로 제공하기보다는 무겁기 때문이라고 생각합니다. 실제로는 이점이 없으므로 연결 오버 헤드가 큽니다.

요약하면 진짜 이유가 없다면 누군가가 SOAP/HTTP를 두껍게 호출하기를 원한다면, 그것은 모두 상대적입니다. 더 적은 표준이 완벽하고 모든 시나리오에 적합합니다. 내가 똑똑한 웹 개발자가 XML 기술이 어떤 생각이고 어떻게 JSON이 얼마나 뛰어난지를 이야기함으로써 그는 현명하다고 생각할 것입니다. 각각에는 장소가 있습니다.