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 표시를 지원하지 않는다. 그 이유는 네트워크 대역폭 수요를 줄이고, 사용자 시간을 절약하고 바이트당 부담을 제한하기 위함이다.

댓글 없음:

댓글 쓰기

블록체인 개요 및 오픈소스 동향

블록체인(block chain) 블록체인은 공공 거래장부이며 가상 화폐로 거래할때 발생할때 발생할 수 있는 해킹을 막는 기술. 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트로서 분산 노드의 운영자에 의한 임의 조작이 불가...