WSDL SOAP 바인딩


  Last Modified 2008/04/22
  by ides
 
http://tequiero35.egloos.com/



WSDL SOAP 바인딩 : 서비스가 SOAP 메시징 프로토콜로 바인딩 되는 방식을 설명한다.

RPC 스타일 or Document 스타일이 있고, SOAP 바인딩은 인코딩되어 사용되거나 리터럴이 있다.


 

RPC

 

특징
 
tightly-coupled 요청/응답 기반 동기식 통신 지원

: 클라이언트 요청 서버의 응답 받을 때까지 다른 오퍼레이션 수행X
 
SOAP 엔진이 모두 처리(인코딩, 디코딩, 데이터 타입)하고,

단순히 파라미터를 통해 원격 객체를 호출만 하면 된다.
 
SOAP 통신을 위한 전송 프로토콜로 HTTP 사용할 경우, RPC 호출모델이 적합하다
.
     
모델의 전형적인 SOAP 인코딩 타입은 'RPC/Encoded'이다
.
 
직렬화된 데이터 형식이 XML 의해 표현되는 , SOAP 인코딩 규칙이 적용된다는

것을 제외하면 기존의 CORBA or RMI 기반 통신과 유사하다

 

1. RPC/encoded

 

장점

WSDL 단순

메서드 명이 메시지에 나타나므로, 수신자가 메시지를 이용해 구현하기 쉽다

단점

SOAP 메시지에 유형 인코딩 정보 (xsi:type="xsd:int") 표기되어 성능에 영향 미치는 오버헤드들이 존재.
WSDL
규격을 준수해도 WS-I[1] 규격을 준수하지 않으므로 WS-I 준수하는 웹서비스와의 연동에 어려움.

 

SOAP

<soap:body>

<opName>

<partName xsi:type="xsd:int">5</partName>

<partName2 xsi:type="xsd:int">5.0</partName2>

</opName>

<soap:body>

WSDL

<message name="Req">

    <part name="partName" type="xsd:int"/>

    <part name="partName2" type="xsd:float"/>

</message>

 

<portType name="PT">

    <operation name="opName">

        <input message="Req"/>

    </operation>

</portType>

 

 

2. RPC/literal

 

장점

WSDL 단순
메서드 명이 메시지에 나타나므로, 수신자가 메시지를 이용해 구현하기 쉽다.
SOAP
메시지 상의 파라미터 타입 인코딩 정보가 제거되어 오버헤드 감소
.
WS-I
규격을 준수하므로 WS-I 지원 서비스들과 연동에 문제 없다.

단점

SOAP 메시지 상에 서비스에 대한 파라미터 타입 정보들이 XML 스키마에 정의된 것을 포함하므로, 서비스 구현시 파라미터들에 대한 타입 정보를 알아내는 부수 작업이 필요.

 

SOAP

<soap:body>

<opName>

<partName>5</partName>

<partName2>5.0</partName2>

</opName>

</soap:body>

WSDL

<message name="Req">

    <part name="partName" type="xsd:int"/>

    <part name="partName2" type="xsd:float"/>

</message>

 

<portType name="PT">

    <operation name="opName">

        <input message="Req"/>

    </operation>

</portType>

 


 

Document


특징

 
문서 중심의 비동기식 통신 지원
(loosely coupled) 
      :
클라이언트가 SOAP 요청 메시지에 대한 리턴값을 요구하지 않을 수도 있다
.
 
서비스 개발자가 모든 것을 핸들링. SOAP Body 마샬링/언마샬링 기능 직접

구현해야 한다.
 
 일련의 파라미터를 보내는 대신 전체 문서를 보낸다
.
     
서비스 제공자는 문서를 전달받아 처리한 , 메시지의 반환 유무 결정
.
 
SOAP 요청/응답 메시지 내의 SOAP Body 내용을 사전에 정의된 하나의 XML

문서로 구성.
 
Document/Literal 방식은 서비스 메서드의 입력 파라미터를 하나만 허용한다
.
      So,
입력 파라미터가 2 이상일 경우 파라미터를 모두 포함하는 형식(ex. 자바빈)

으로 만들어 1개의 파라미터로 바꿔야 한다.

 

3. Document/literal

 

장점

SOAP 메시지 상에 유형 인코딩 정보가 기술되지 않으므로 오버헤드 없다.
XML
유효성 검증기로 메시지를 최종 확인. SOAP Body 내의 모든 것이 스키마에서 정의된다
.
Document/Literal
WS-I 순응이지만 제한이 없다.

단점

WSDL 복잡. 읽을 없다.
SOAP
메시지에 opName 존재하지 않는다
.
WS-I
soap:body 아래에 하나의 엘리먼트만 허용하므로,

Document/literal 방식은 WS-I 순응이 아니다.

 

SOAP

<soap:body>

<elemName >5</elemName>

<elemName2>5.0</elemName2>

</soap:body>

WSDL

<types>

    <schema>

        <element name="elemName" type="xsd:int"/>

        <element name="elemName2" type="xsd:float"/>

    </schema>

</types>

 

<message name="Req">

    <part name="partName" element="elemName"/>

    <part name="partName2" element="elemName2"/>

</message>

 

<portType name="PT">

    <operation name="opName">

        <input message="Req"/>

    </operation>

</portType>

 

 

4. Document/literal wrapped

 

장점

SOAP 메시지 상에 파라미터 타입 인코딩 정보가 기술되지 않는다.
SOAP Body
나타나는 모든 것이 XML 스키마에서 정의된다
.
메서드 명이 메시지에 나타나므로, 수신자가 메시지를 이용해 구현하기 쉽다
.
SOAP Body
하나의 자식을 가져야 하는 WS-I 규격을 준수한다.

단점

WSDL 복잡.

 

SOAP

<soap:body>

  <opName>

<elemName >5</elemName>

<elemName2>5.0</elemName2>

  </opname>

</soap:body>

WSDL

<types>

  <schema>

    <element name="opName">

      <complexType>

        <sequence>

          <element name="elemName" type="xsd:int"/>

          <element name="elemName2" type="xsd:float"/>

        </sequence>

</complexType>

    </element>

  </schema>

</types>

 

<message name="Req">

    <part name="partName" element="opName"/>

</message>

 

<portType name="PT">

    <operation name="opName">

        <input message="Req"/>

    </operation>

</portType>

 

* rpc/literal document/literal wrapped 다른

rpc/literal SOAP body 자식은 operation 엘리먼트의 이름이다.

document/literal wrapped 스키마의 래퍼 엘리먼트의 이름이다.

document/literal wrapped 예제에서처럼 operation 엘리먼트와 스키마의 래퍼 엘리먼트의 이름을 같게 해서 오퍼레이션 이름을 SOAP 메시지에 넣는 방식이다.

 

 



 

SOAP 인코딩별 장단점

 

구분

RPC/Encoded

RPC/Literal

Document/Literal

성능

개발 생산성

파라미터 객체

불필요

불필요

필요

자바-XML 바인딩

불필요

불필요

필요

WS-I 권고

No

Yes

Yes

입력 파라미터

2개 이상 허용

2개 이상 허용

1개만 허용

정 리

개발 easy.

확장성, 퍼포먼스 취약.

XML 파싱 핸들링 포함.

SOAP 규격이 다뤄야 하는 오버헤드 발생.

개발 difficult.

적은 SOAP 오버헤드.

가장 높은 효율의 성능.

 

 




 


<REFERENCE>
Web-Service
통신방식 분석 (지훈)
WSDL
고르기 : http://www-128.ibm.com/developerworks/kr/library/ws-whichwsdl/ (한글문서)

                      http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ (원문) 

 




[1] 다양한 서비스 스펙들은 가끔 일관성이 없고 불분명하다. WS-I 스펙과 관련한 여러 문제들을 명확히 하기 위해 설립되었다. 상호운용 가능한 서비스를 작성하는 방법을 설명하는 많은 프로파일들을 정의한다. 관련 사이트 참조 : http://ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile




by ides | 2007/10/30 10:09 | [P] Web Services | 트랙백 | 덧글(1)

트랙백 주소 : http://tequiero35.egloos.com/tb/1634462
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Commented by 떠돌이 at 2010/08/13 18:22
잘 정리된 정보 감사합니다. 꽤 오래전의 글인데 전 이제서야 보네요 ^^;

헌데 여기서 말하는 RPC versus Document는 WSDL 명세에서의 바인딩에 대한 규칙이 아닌가요?
특징으로 언급하신 동기/ 비동기, 바디 마샬링 등이 실제 적용되는 건지 궁금하네요.. WSDL에 저런 것들까지 명시할 수 있는지 여부가 궁금해서요.

우문현답 부탁드려요~

:         :

:

비공개 덧글

◀ 이전 페이지          다음 페이지 ▶