어떤 본문이 문서 스타일과 RPC 스타일 웹 서비스의 차이점을 설명 할 수 있습니까?
WSDL 바인딩을 SOAP 메시지 본문으로 변환하는 데 사용되는 두 가지 통신 스타일 모델이 있습니다. 그들은 다음과 같습니다 :
문서 및 RPC
문서 스타일 모델 사용 의 장점은 SOAP 메시지 본문의 내용이 임의의 XML 인스턴스 인 한 원하는 방식으로 SOAP 본문을 구조화 할 수 있다는 것입니다. 문서 스타일은 메시지 지향 스타일 이라고도합니다 .
그러나 RPC 스타일 모델 에서는 SOAP 요청 본문의 구조에 작업 이름과 메서드 매개 변수 집합이 모두 포함되어야합니다. RPC 스타일 모델은 메시지 본문에 포함 된 XML 인스턴스에 대한 특정 구조를 가정합니다 .
또한 WSDL 바인딩을 SOAP 메시지로 변환하는 데 사용되는 두 가지 인코딩 사용 모델이 있습니다. 그들은 : 리터럴 및 인코딩
리터럴 사용 모델을 사용하는 경우 본문 내용은 사용자 정의 XML 스키마 (XSD) 구조를 따라야합니다 . 장점은 두 가지입니다. 우선 사용자 정의 XML 스키마를 사용하여 메시지 본문의 유효성을 검사 할 수 있으며 XSLT와 같은 변환 언어를 사용하여 메시지를 변환 할 수도 있습니다.
(SOAP) 인코딩 된 사용 모델 을 사용하는 경우 메시지는 XSD 데이터 유형을 사용해야하지만 메시지 구조는 사용자 정의 XML 스키마를 준수 할 필요가 없습니다. 이로 인해 메시지 본문의 유효성을 검사하거나 메시지 본문에서 XSLT 기반 변환을 사용하기가 어렵습니다.
다른 스타일과 사용 모델의 조합은 WSDL 바인딩을 SOAP 메시지로 변환하는 네 가지 방법을 제공합니다.
Document/literal
Document/encoded
RPC/literal
RPC/encoded
어떤 스타일의 WSDL을 사용해야합니까? 라는 제목의이 기사를 읽어 보는 것이 좋습니다 . 러셀 부텍 (Russell Butek)은 WSDL 바인딩을 SOAP 메시지로 변환하는 모델을 사용하여 다양한 스타일에 대해 잘 설명하고 있으며 상대적인 강점과 약점을 설명합니다.
아티팩트가 수신되면 두 가지 유형의 통신 모두에서 포트에서 메소드를 호출합니다. 이제 이것은 RPC 스타일과 문서 스타일에서 다르지 않습니다. 그렇다면 차이점은 무엇이며 그 차이점은 어디에 있습니까?
차이점을 찾을 수있는 곳은 "응답"입니다!
RPC 스타일 :
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.RPC)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
두 번째 작업에 대한 SOAP 메시지는 빈 출력을 가지며 다음과 같이 표시됩니다.
RPC 스타일 응답 :
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
문서 스타일 :
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
위의 SEI에 대해 클라이언트를 실행하면 출력은 다음과 같습니다.
123 [123, 456]
이 출력은 ArrayList 요소가 웹 서비스와 클라이언트간에 교환되고 있음을 보여줍니다. 이 변경은 SOAPBinding 주석의 스타일 속성을 변경함으로써 만 수행되었습니다. 더 풍부한 데이터 유형을 가진 두 번째 메소드에 대한 SOAP 메시지는 참조를 위해 아래에 표시됩니다.
문서 스타일 응답 :
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
결론
- 두 SOAP 응답 메시지에서 알 수 있듯이 DOCUMENT 스타일의 경우 SOAP 응답 메시지의 유효성을 검사 할 수 있지만 RPC 스타일 웹 서비스에서는 확인할 수 없습니다.
- RPC 스타일을 사용할 때 의 기본적인 단점은 더 풍부한 데이터 유형을 지원하지 않는다는 것이고 문서 스타일을 사용하는 것의 단점은 더 풍부한 데이터 유형을 정의하기 위해 XSD의 형태로 약간의 복잡성을 가져온다는 것입니다.
- 이 중 하나를 사용하는 선택은 작업 / 방법 요구 사항 및 예상되는 클라이언트에 따라 다릅니다.
마찬가지로 SOAP over HTTP와 XML over HTTP는 어떤 점에서 다릅니 까? 결국 SOAP는 SOAP 네임 스페이스가있는 XML 문서이기도합니다. 그렇다면 여기서 차이점은 무엇입니까?
SOAP와 같은 표준이 필요한 이유는 무엇입니까? HTTP를 통해 XML 문서를 교환함으로써 두 프로그램은 SOAP와 같은 추가 표준을 도입하지 않고도 풍부하고 구조화 된 정보를 교환하여 메시지 봉투 형식을 명시 적으로 설명하고 구조화 된 콘텐츠를 인코딩 할 수 있습니다.
SOAP는 표준을 제공하므로 개발자는 제공하려는 모든 서비스에 대해 사용자 정의 XML 메시지 형식을 만들 필요가 없습니다. 호출 할 서비스 메서드의 서명이 주어지면 SOAP 사양은 명확한 XML 메시지 형식을 규정합니다. 임의의 프로그래밍 언어로 작업하는 SOAP 사양에 익숙한 개발자는 특정 서비스에 대한 올바른 SOAP XML 요청을 공식화하고 다음 서비스 세부 정보를 얻어 서비스의 응답을 이해할 수 있습니다.
- 작업 명
- 서비스에 의해 구현 된 메서드 이름
- 각 메서드의 메서드 서명
- 서비스 구현 주소 (URI로 표시됨)
SOAP를 사용하면 서비스의 메서드 서명이 요청과 응답 모두에 사용되는 XML 문서 구조를 식별하므로 기존 소프트웨어 구성 요소를 웹 서비스로 노출하는 프로세스가 간소화됩니다.