WSDL 베스트 프랙티스

Question

제 3 자와 통합되는 SOAP 애플리케이션을 개발 중입니다. 이 제 3 자의 WSDL은 매우 이상하다고 생각합니다. 나는 SOAP을 처음 사용하기 때문에 깨지지 않는 경우 수정하도록 요청하고 싶지 않습니다. 다음은 기술적 인면에서 틀림없이 올바른 문서 일 것이라고 확신하지만 (필자가 제목에 "우수 사례"를 쓴 이유) 잘못된 점을 생각해 보았습니다. 또한 gSOAP을 SOAP 라이브러리로 사용하고 있는데, 이러한 것들 중 일부는 이상하다고 생각할 수 있습니다. (나는 일반적으로 SOAP보다 gSOAP에 더 익숙합니다.)

1. 동일한 WSDL에서 SOAP 1.1 및 SOAP 1.2에 대해 지정된 인터페이스가 있습니다. 이로 인해 gSOAP은 필요한만큼 두 배의 클래스를 생성합니다. 1.2를 사용하기 때문에.

2. 모든 이름 공간은 http://tempuri.org입니다. 그건 그렇게해서는 안된다. 그렇지?

3. RPC 호출을 정의하더라도 WSDL은 문서 형식을 사용합니다. gSOAP은 C++ 형식의 문서 형식 매개 변수를 사용하는 메서드를 생성하지 않으므로 RPC 형식으로 전환하도록 요청하고 있습니다. 대신 모든 API 함수의 입력 및 응답 데이터에 대한 새 클래스를 만듭니다. 내가 고칠 수없는 경우 gSOAP 물건 주위에 다른 API를 제공하기 위해 다른 레이어를 작성해야 할 것이다. 또한, AFAICT, 앞뒤로 이동하는 XML은 RPC로 전환 한 경우와 정확히 동일하므로 어려울 것이라고 생각하지 않습니다.

4. 요소가 minOccurs = 0인데 아직 요청하지 않고 요청을 제출할 때 오류가 반환되어 필요하다는 것을 나타냅니다 (때때로 null 포인터 예외의 흔적을 스택하는 경우조차도). 필요한 경우 minOccurs = 1로 지정해야합니다. 맞습니까?

5. 거의 모든 웹 서비스 함수는 성공 (실제로는 부울)과 오류 메시지 문자열을 나타내는 정수를 포함하는 응답을 지정합니다. 그들이 SOAP 결함을 사용해야합니까? gSOAP을 사용하면 오류 메시지를 쉽게 알아낼 수 있기 때문에 (오류 메시지를 간단하게 인쇄 할 수 있습니다) 응용 프로그램에서 처리하는 것이 더 쉬울 것이라고 생각합니다.

물론 제 3 자 회사가 WSDL을 변경하게 될 것이라는 희망은 없습니다. 적어도 뭔가를 배울거야 ... 내가 아는 한 모두, 이것들 중 어느 것도 틀리거나 의문의 여지가 없다. 당신의 도움을 주셔서 감사합니다.

Answer 1

1 - 아마도이 기능을 고려해야합니다. :-)

2 - 그건 끔찍한 일입니다.

3 - 많은 사람들이 이것을 권장합니다. 포장 된 형식이라고합니다.

4 - 정확합니다.

5 - 이에 따라 다릅니다. 이론적으로는 정확할 수도 있지만 실제로 많은 SOAP 툴킷은 SOAP 결함을 제대로 지원하지 않으므로 의도적으로 예외를 사용하지 않기로 선택했을 수 있습니다.

Answer 2

웹 서비스를 만들 때 일반적인 타사의 게으름이 발생했습니다. 나는 당신이 그들과 논쟁하려고 노력하지 않을 것이라고 생각하지만, 1.1 정의를 제거하기 위해 WSDL을 편집 할 수있다.

Answer 3

웹 서비스를 알지 못하는 제 3 자와 같이 나에게 소리가납니다.

사용자의 설명을 보면, Microsoft ASP.NET 웹 서비스 구현의 전형적인 모습을 보였습니다. 제 3자가 제공하는 인터페이스에 약간의 VB 또는 C#을 작성하고이를 ASP.NET 서버에 푸시하고 호출합니다 ASP.NET 엔진에 따라 요청에 따라 WSDL을 자동으로 생성합니다.

당신은 SOAP 1.1 정의를 제공하지 말 것을 요청할 수 있지만, 어떻게 해야할지 모르기 때문에 그들이 당신을 도울 것이라고는 생각하지 않습니다. 네임 스페이스가 tempuri.org 인 이유를 물어볼 수 있습니다. 응답이 "우리가 살펴 봐야 할 것"이라고 말할 수있을 것입니다. 정말로 말할 때 "It is ??"라고 말하면됩니다. 이유도 모르기 때문입니다.

네임 스페이스는 코드의 컴파일러 지시문에 의해 제어되며 tempuri.org는 Microsoft 기본값입니다. atm이라는 이름이 무엇인지 기억하지 마십시오. 물론 네임 스페이스의 가치는 실제로 변수 이름 해석을위한 고유 한 문자열 식별자를 제공하기위한 것이기 때문에 별난 것으로 보아서는 안됩니다. 어쩌면 다른 것들도 비슷한 방식으로 제어 될 수 있습니다. 나도 몰라, 웹 서비스 나 ASP.NET 또는 그런 것들을 정말로 알지 못합니다. 기술에 대한 큰 팬이 아닙니다.

Answer 4

아무도 실제로는 도구로 생성 된 WSDL을 쓰지 않습니다. 벤더 도구는 아마도 네임 스페이스에 올바른 URL을 삽입하고 아마도 - V1.0, V1.1, Both라는 라디오 버튼을 가지고 있습니다. 공급 업체는 SOAP 코드가 아닌 기존 코드를 일부 가지고 SOAP 서비스로 래핑하는 데 사용했습니다.

아무도 WSDL을 쓰지 않으므로 읽지 않아야합니다! 적절한 도구 세트를 얻으십시오. SOAPUI와 같은 것이 WSDL을 디코딩하여 머리가 폭발하지 않고도 탐색 할 수있게 해줍니다. Java는 그렇지만 여러분이 코딩하는 언어가 무엇이든지간에 최상의 테스트 도구입니다.

내 SOA 경험은 주로 라이브러리와 도구에 관한 한 당신이 선택의 여지가있는 곳에서 자바로 진행됩니다. C++은 아마이 분야에서 성숙하지는 않지만 WSDL보다는 툴 선택 문제라는 것만 같아 보입니다. 실제 세계에서는 완벽하지 못한 WSDL이 제공되므로 도구가 합리적인 방법으로 WSDL을 처리 할 수 ​​있어야합니다.

Answer 5

내가 좀 더 일반적인 WSDL 생성을위한 모범 사례에 대한 싶습니다 : 나는 계약 - 첫 번째 방법의 사용에 강조 강하게 것 제임스는 대조적으로 개발되어

1. 계약 우선 왜냐하면 개발자가 XML (제한, 패턴, ...)의 모든 기능을 사용할 수 있고 모든 프로그래밍 언어에 대한 코드를 생성하는 것이 매우 쉽기 때문입니다. 또 다른 이유는 < wsdl : types >의 스키마가 서로 이야기하는 두 시스템 간의 계약이라는 것입니다. 개발자가 코드에서 WSDL을 작성하면 특정 프로그래밍 언어에 대한 기술 종속성 (데이터 유형 등)이 도입 될 수 있습니다.

2. 문서/리터럴 스타일 RPC 인코딩 된 SOAP의
검증이 까다로울 수있다, XPATH 쿼리 및 XSLT 변환은 단지 불가능뿐만 아니라이며,이 스타일은 어쨌든되지 않습니다.

RPC/literal은 XML (특정 명명 규칙의 계정)의 유효성을 검사하는 데 문제가 있습니다. 일부 SOAP 엔진은 스키마 정의 된 네임 스페이스를 삭제하므로 유효성 검사가 불가능 해집니다.

Document/literal 스타일을 사용하면 SOAP 본문이 XML 문서로 완전히 처리됩니다.이 문서는 표준 방식으로 유효성 검사, 변환 및 쿼리가 가능합니다.

3.관심 분리
< 가져 오기를 사용하여 스키마 정의를 WSDL 파일과 분리합니다. > 및 <에는 .. > 지시문이 포함됩니다. 이는 스키마의 재사용과 네임 스페이스를 다른 .xsd 파일로 분리하는 것을 촉진하며 파일 크기를 줄입니다.)

Answer 6

바로 지금이 문제에 직면하게되면 접두사를 올바르게 써야합니다. 두 continus 밑줄 'youtns__methodname "

이 실행 soapcpp2 후 2 개 WSDL 파일이 생성됩니다

typedef double xsd_double; 
int ns__add(xsd_double a, xsd_double b, xsd_double &result); 
int ns__sub(xsd_double a, xsd_double b, xsd_double &result); 
int myns__sqrt(xsd_double a, xsd_double &result); 

예 : ns.wsdl 및 myns.wsdl을

그러나 당신이이 같은 당신 방식 (하나의 밑줄)

int ns_add(xsd_double a, xsd_double b, xsd_double &result); // wrong 

spapcpp2 아무것도 생성되지 않습니다를 정의합니다.