2011년 5월 24일 화요일

WSDL 1.1 Spec의 바인딩 스타일

WSDL 1.1 명세는 다음과 같이 두 가지 다른 바인딩 스타일을 구분한다.
  • RPC 스타일: 이 스타일은 <soap:body> 가 호출되는 서비스 메소드의 이름을 가진 요소(래퍼 요소)를 포함하고 있음을 설명한다. <soap:body> 안의 이 요소는 각 매개변수의 엔트리와 이 메소드의 리턴값을 포함하고 있다.
  • Document 스타일: 이 스타일에서는 래퍼 요소가 없다. 대신, <soap:body> 요소 밑에 메시지 부분이 곧장 나타난다. <soap:body>가 무엇을 포함하는가에 대한 SOAP 포맷팅 법칙은 없다. <soap:body>는 발신인과 수신인이 동의한 내용을 XML 문서형식으로 담고 있다.


이 스타일들의 범위 내에서 부호나 상수도 쓸 수 있다.:
  • Encoded: 이 용도에서는 각 메시지 부분은 타입 속성을 사용하여 추상적인 타입을 참조한다. 메시지는 인코딩스타일 속성으로 상술된 인코딩을 사용하여 산출된다. 가장 자주 사용되는 인코딩은 SOAP 인코딩으로, 이는 SOAP 1.1에서 정의된 일련의 규칙이다. 그 규칙들은 오브젝터, 구조, 배열, 목적 그래프가 어떻게 나열되어야 할 지를 상술한다. 일반적으로, SOAP 인코딩을 사용하는 어플리케이션은 원격 procedure call에 집중하며, RPC 메시지 스타일을 사용한다.
  • 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 표시를 지원하지 않는다. 그 이유는 네트워크 대역폭 수요를 줄이고, 사용자 시간을 절약하고 바이트당 부담을 제한하기 위함이다.

댓글 없음:

댓글 쓰기

ETL 솔루션 환경

ETL 솔루션 환경 하둡은 대용량 데이터를 값싸고 빠르게 분석할 수 있는 길을 만들어줬다. 통계분석 엔진인 “R”역시 하둡 못지 않게 관심을 받고 있다. 빅데이터 역시 데이터라는 점을 볼때 분산처리와 분석 그 이전에 데이터 품질 등 데이...