2009-12-05 4 views
1

WSDL 파일에서 WCF 프록시를 생성했지만 프록시 메서드를 호출하면 null을 반환합니다. 메시지 로깅을 활성화했으며 서버의 메시지가 올바르게 반환되었는지 확인할 수 있습니다.WSDL에서 생성 된 WCF 프록시, 프록시 메서드가 null을 반환합니다.

나는 this 질문의 답을 확인했지만 적어도 내 경우에는 반환 된 개체의 이름이 메시지와 WSDL에서 동일했다. 여전히 "? wsdl"URL (제 3 자 웹 서비스)을 통해 일반적인 방법으로 가져 오지 않기 때문에 문제가 WSDL 파일과 관련이 있다고 생각하지만 별도로 제공되었습니다.

메서드의 반환 형식은 문자열입니다.

비슷한 문제가있는 사람이 있습니까? 해당 솔루션은 무엇입니까? 문제의 가장 큰 원인은 무엇입니까?

다시 편집 :

그것은 RPC/인코딩 된 웹 서비스입니다. 작성된대로 메시지 로깅을 통해 SOAP 응답을 볼 수 있지만 WCF는 정보를 구문 분석 할 수없는 것 같습니다.

서비스 응답의 메시지 부분은 다음과 같습니다 : 내 클라이언트에서 보내는 메시지를 검사 할 때

<ns1:ServiceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace"> 
    <ns1:ReturnValue xsi:type="xsd:string"> 

을하지만, 그것은 다르다 :

<ns1:ServiceRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace"> 
    <RequestValue xsi:type="xsd:string" xmlns=""> 

그래서 어쩌면 프록시는 예상 응답은 동일한 네임 스페이스 구조를 가지므로 구문 분석에 실패합니다.

은 내가 WSDL 메시지 정의에 elementtype 속성을 변경하려고하고 WSDL 정의의 types 부분에 새로운 요소를 추가,하지만 프록시를 생성 할 때 다음는 svcutil은 충돌이 있다고 불평, 초크했습니다 유추 된 스타일 문서와 지정된 스타일 rpc 사이. WSDL specification 가입일

섹션 3.5

사용 인 경우는

부호화는 각 메시지 부분은 속성을 사용하여 추상 타입을 참조한다.

그러나이 글에서는 문제가되지 않았으므로 약간 혼란 스럽습니다. question. 유사한 변경을하기 위해 RPC/인코딩 된 서비스라는 제한이 필요한 것은 무엇입니까?

+0

WSDL을 어떻게 생성 했습니까? svcutil 명령을 사용 했습니까? 아니면 VSS에 서비스를 추가 했습니까? 응답의 형식 (텍스트, MTOM?) 및 어떤 종류의 웹 서비스인지 알고 있습니까? – K2so

+0

올바른 : WSDL에서 클래스를 어떻게 생성 했습니까? – K2so

답변

0

Java 웹 서비스의 WSDL에 대해 WCF 클라이언트를 사용할 때 비슷한 점이 있습니다.

우리의 문제는 서비스에서 돌아 오는 데이터를 볼 수 없었기 때문에 데이터가 누락 된 것처럼 보였습니다.

그러나 전선에서 진행된 작업을 살펴보면 데이터가있었습니다.

문제는 WSDL에 다른 유형에서 상속 된 여러 유형이 있다는 것입니다. 기본적으로 기본 유형의 정보 만 볼 수 있습니다.

해결 방법은 예상했던 유형으로 개체를 캐스팅하는 것이 었습니다. 그러면 모든 필드가 나타납니다.

+0

예, 이것은 내가 찾는 답변의 종류입니다. 그러나 실제로이 경우에는 그렇지 않습니다. 왜냐하면 저는 basetype을 다루기 때문에 전체 객체 (문자열)가 null이되고 일부만이 아닌 것입니다. –

2

이 문제를 해결하려면 Java 서비스에 대해 자세히 설명해야합니다. 그러나 Java 서비스가 type 속성으로 정의 된 메시지 파트를 사용하고있는 것으로 의심됩니다. 이는 WS-I Basic Profile 1을 따르지 않는다. 왜냐하면 메시지의 요소에 어떤 네임 스페이스를 사용해야하는지 모호하기 때문이다. 일부 서비스는 유형의 네임 스페이스를 사용하지만 다른 서비스는 웹 서비스 자체의 네임 스페이스를 (올바르게) 사용합니다.

element 특성을 사용하면 모호성이 제거되므로 바람직합니다.

문제가있는 메시지가 포함 된 WSDL 스 니펫을 게시하십시오. 그런 다음 메시지의 정의를 유선에 표시된 내용과 비교 한 다음 메시지를 사용하려는 프록시 클래스의 세부 정보와 비교하면 내 의미를 알 수 있습니다. 프록시 클래스는 하나의 네임 스페이스를 예상하지만, 전선에서 다른 네임 스페이스가 사용되고 있습니다.

+0

그렇습니다. wsdl 부분은 type 속성으로 정의됩니다. 나는 할 수있을 때 이것을 시도 할 것이고, 나는 또한 예를 들어 줄 것이다. –

+0

요소를 추가하려고했지만 경고 메시지가 나타납니다. "작업 서비스의 메시지에서 추론 된 스타일 문서가 바인딩을 통해 지정된 예상 된 Rpc와 일치하지 않습니다." 그래서 나는 그 요소를 적절한 장소에 추가하지 않았다고 생각합니다. 이제 wsdl : types> 스키마에서 으로 추가했습니다. 그리고 메시지에서 element = "tns : ReturnValue"로 참조됩니다. –

관련 문제