WSDL 1.1 Spec의 바인딩 스타일

WSDL 1.1 명세는 다음과 같이 두 가지 다른 바인딩 스타일을 구분한다. l        RPC 스타일: 이 스타일은 <soap:body> 가 호출되는 서비스 메소드의 이름을 가진 요소(래퍼 요소)를 포함하고 있음을 설명한다. <soap:body> 안의 이 요소는 각 매개변수의 엔트리와 이 메소드의 리턴값을 포함하고 있다.   l        Document 스타일: 이 스타일에서는 래퍼 요소가 없다. 대신, <soap:body> 요소 밑에 메시지 부분이 곧장 나타난다. <soap:body>가 무엇을 포함하는가에 대한 SOAP 포맷팅 법칙은 없다. <soap:body>는 발신인과 수신인이 동의한 내용을 XML 문서형식으로 담고 있다.   이 스타일들의 범위 내에서 부호나 상수도 쓸 수 있다.: l        Encoded: 이 용도에서는 각 메시지 부분은 타입 속성을 사용하여 추상적인 타입을 참조한다. 메시지는 인코딩스타일 속성으로 상술된 인코딩을 사용하여 산출된다. 가장 자주 사용되는 인코딩은 SOAP 인코딩으로, 이는 SOAP 1.1에서 정의된 일련의 규칙이다. 그 규칙들은 오브젝터, 구조, 배열, 목적 그래프가 어떻게 나열되어야 할 지를 상술한다. 일반적으로, SOAP 인코딩을 사용하는 어플리케이션은 원격 procedure call에 집중하며, RPC 메시지 스타일을 사용한다.   l        Literal: 이 용도에서는 각 부분이 요소나 타입 속성을 사용하여 구체적인 스키마 정의를 참조한다. 즉, 데이터는 주어진 스키마에 따라 나열된다. 실제로, 이 스키마는 보통 W3C XML 스키마를 사용하여 표현된다.   요약하자면, 바인딩 스타일/사용에 대한 조합은 다음과 같다 : 1.        RPC/encoded 2.        RPC/literal 3.        Document/encoded 4.        Document/literal   Document/encoded 조합은 WS-I 관련이 아니며 더 이상 사용되고 있지 않으므로 다루지 않겠다.   JAX-RPC WSDL With RPC/Encoded wscompile 명령어에서 Default Style로 사용된다. wscompile -define -mapping buildmapping.xml -d build    -nd build -classpath build config-interface.xml   생성되는 WSDL 문서 <?xml version="1.0" encoding="UTF-8"?> … <types/> … <binding name="HelloIFBinding" type="tns:HelloIF">          <soap:binding         transport="http://schemas.xmlsoap.org/soap/http"         style="rpc"/>        <operation name="sayHello">         <soap:operation soapAction=""/>            <input>            <soap:body encodingStyle=             "http://schemas.xmlsoap.org/soap/encoding/"             use="encoded" namespace="urn:Foo"/>          </input>            <output>            <soap:body encodingStyle=             "http://schemas.xmlsoap.org/soap/encoding/"             use="encoded" namespace="urn:Foo"/>          </output> …   다음은 메소드를 호출하는 RPC/encoded SOAP 메시지이다. <soap:envelope>        <soap:body>            <sayHello>                <String_1 xsi:type="xsd:string">Duke</String_1>                  <int_2 xsi:type="xsd:int">5</int_2>                <float_3 xsi:type="xsd:float">5.0</float_3>            </sayHello>        </soap:body> </soap:envelope>   WSDL과 SOAP 메시지는 직접적이다. 호출된 서비스 메소드는 <sayHello>로, 고유 요소로서 나타난다. 그 요소 내에 있는 것은 매개 변수들(String, int, float)이다. 각 메시지 부분별로 무엇이 합법적인 값인지 서버가 추론할 수 있으므로 xsi:type 속성은 필요하지 않을 수도 있다. 이는 큰 문제가 아니지만, <sayHello>는 스키마에서 정의되지 않고 대신 WSDL 정의이기 때문에 이 메시지를 입증하기는 어렵다. 게다가, RPC/encoded는 WS-I compliant가 아니다. 이는 다른 종류의 클라이언트들이 WSDL을 읽고 클라이언트 쪽에 적절한 stub을 생성하여 서비스를 연결하는 것을 어렵게 한다.   JAX-RPC WSDL With RPC/Literal wscompile 독립변수에 -f:rpcliteral 옵션을 더한다. wscompile -f:rpcliteral -define -mapping buildmapping.xml    -d build -nd build -classpath build config-interface.xml   WSDL문서 … <types/> … <binding name="HelloIFBinding" type="tns:HelloIF">        <soap:binding         transport="http://schemas.xmlsoap.org/soap/http"         style="rpc"/>          <operation name="sayHello">          <soap:operation soapAction=""/>          <input>            <soap:body use="literal" namespace="urn:Foo"/>          </input>          <output>            <soap:body use="literal" namespace="urn:Foo"/>          </output>        </operation>      </binding> …   메소드를 호출하는 SOAP 메시지는 다음과 같다. <soap:envelope>        <soap:body>            <sayHello>                <String_1>Duke</String_1>                <int_2>5</int_2>                <float_3>5.0</float_3>            </sayHello>        </soap:body>    </soap:envelope>   xsi:type 인코딩 속성이 SOAP에서 제거되었음을 확인하자. 더 중요한 것은, RPC/literal은 WS-I compliant이므로 다른 타입의 클라이언트들이 WSDL을 읽을 수 있고 , 클라이언트쪽에 적절한 stub를 생성하여 서비스를 호출할 수 있다는 것이다. 그러나, <sayHello> 는 스키마가 아니라 WSDL 요소이므로 입증하는 것은 여전히 어렵다.   JAX-RPC WSDL With Document/Literal wscompile툴을 구동하고 -f:documentliteral 옵션을 사용한다. wscompile -f:documentliteral -define    -mapping buildmapping.xml -d build -nd build    -classpath build config-interface.xml   WSDL문서 … <types>        <schema targetNamespace="urn:Foo" xmlns:tns="urn:Foo"         xmlns:soap11-enc=          "http://schemas.xmlsoap.org/soap/encoding/"         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"         xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"         xmlns="http://www.w3.org/2001/XMLSchema">          <complexType name="sayHello">            <sequence>              <element name="String_1"               type="string" nillable="true"/>              <element name="int_2" type="int"/>              <element name="float_3" type="float"/>            </sequence>          </complexType>          <complexType name="sayHelloResponse">            <sequence>              <element name="result" type="string" nillable="true"/>            </sequence>          </complexType>          <element name="sayHello" type="tns:sayHello"/>          <element name="sayHelloResponse"           type="tns:sayHelloResponse"/>        </schema>      </types> …      <binding name="HelloIFBinding" type="tns:HelloIF">        <soap:binding         transport="http://schemas.xmlsoap.org/soap/http"         style="document"/>        <operation name="sayHello">          <soap:operation soapAction=""/>          <input>            <soap:body use="literal"/>          </input>          <output>            <soap:body use="literal"/>          </output>        </operation>      </binding> …   이번에는 WSDL에 있는 <types> 요소가 훨씬 큰 점을 확인하자. 또한 두 <element> 요소들이 하나는 sayHello로, 또 하나는sayHelloResponse로 정의되어 있음을 확인하기 바란다.   메소드를 호출하는 SOAP 메시지는 다음과 같다. <soap:envelope>        <soap:body>            <String_1>Duke</String_1>            <int_2>5</int_2>            <float_3>5.0</float_3>        </soap:body> </soap:envelope>   보다시피 SOAP 메시지는 RPC/literal와 비슷하다. Document/Literal의 SOAP 메시지는 <sayHello> 요소를 포함하지 않음을 확인하자. Document/literal의 주된 특징이자 RPC/literal에 비교했을 때의 중요 이점은 컨텐츠를 설명하는 WSDL 내의 스키마 요소 정의이다. 이는, 간단하게 스키마를 봄으로써 메시지 본문이 무엇을 포함하는지 알 수 있음을 의미한다. 추가적인 규칙은 필요없다. Document/literal 메시지를 설명하는 스키마를 가지고 메시지를 입증(RPC/literal로는 할 수 없음)하는 데에 사용할 수 있다. Document/literal 조합은 JAX-RPC를 사용할 때 큰 이동성을 제공한다. 이는 또한 J2ME 클라이언트에 의해 지원되는 바인딩/사용 조합으로, JSR 172: J2ME Web Services Specification으로 상술된다. JSR 172는 JAX-RPC 1.1의 부분 집합에 기반을 둔 원격 method invocation API를 정의한다. JSR 172는 WS-I Basic Profile을 따른다. JSR-172는 Encoded 표시를 지원하지 않는다. 그 이유는 네트워크 대역폭 수요를 줄이고, 사용자 시간을 절약하고 바이트당 부담을 제한하기 위함이다.  참고 자료 : http://kr.sun.com/developers/techtips/e2005_0823.html