WSDL.exe не туда-обратно? - PullRequest
0 голосов
/ 18 июля 2011

Мой клиент указал файл WSDL в качестве контракта для веб-службы, которую я должен реализовать.(Это действительно должен быть тот файл WSDL, поскольку он уже был сообщен другим партнерам и т. Д., И они также будут реализовывать свои собственные веб-службы и клиенты на основе этого WSDL. Это файл WSDL размером 63 КБ.)

С помощью wsdl.exe я создал прокси-классы для серверной части.Так что я мог бы реализовать веб-сервис.НО: если вы используете wsdl.exe для создания прокси-классов на стороне клиента на основе исходного файла WSDL, это приводит к тому, что клиентское приложение не может обмениваться данными с веб-службой!

INSTEAD: byдобавив «? wsdl» к URL-адресу веб-службы, я получаю другой файл WSDL.При использовании этого второго файла WSDL для создания прокси-классов на стороне клиента это приводит к тому, что клиентские приложения могут отлично взаимодействовать с веб-службой.Странно, что второй файл WSDL имеет размер 288 КБ вместо 63 КБ исходного файла WSDL.

Так что это должно означать, что WSDL не является циклическим… (файл WSDL -> wsdl.exe)создание прокси-классов на стороне сервера -> веб-служба -> добавление «? wsdl» к URL-адресу веб-службы -> приводит к созданию другого файла WSDL в качестве исходного (и, что еще хуже, они не совместимы).)

Можеткто-нибудь объяснит это?(Для моего проекта это важно, потому что другие стороны будут использовать оригинальный файл WSDL, и поэтому они не смогут общаться с моим веб-сервисом…)

Я проводил тесты с C #, а такжес CLI.Это воспроизводимо.Я использую IIS 7.5 и .NET Framework 3.5.

Ответы [ 2 ]

2 голосов
/ 18 июля 2011

Ваш исходный WSDL используется только для генерации заглушек и ничего более.Добавляя ?wsdl к адресу службы, вы указываете службе, что вам нужно получить свой WSDL-документ, но по умолчанию он создает свой собственный.Если вы хотите заставить его вернуть ваш прежний документ, вы должны изменить свой сервис .

В любом случае, если ваш клиент и сервис, сгенерированные из одного и того же WSDL, не могут общаться друг с другом, у вас естьгораздо большая проблема, чем другой WSDL.В этой части мы вряд ли поможем вам, если не будем знать WSDL.

0 голосов
/ 21 июля 2011

После небольшого изменения кода, сгенерированного моим мастером кода (свободно доступный шаблон для веб-служб CLI ASP.NET для Visual Studio 2008, но стандартный шаблон веб-службы C # генерирует такой же код), я получил что-то вроде этого:

// MyWebService.cpp : main project file.
#include "stdafx.h"
#include "Global.asax.h"
#include "HeaderFileGeneratedByWsdlExe.h"

using namespace System;
using namespace System::Web;
using namespace System::Web::Services;

namespace MyWebService {

    [WebService(Namespace = L"http://MyNamespace.org/")]
    [WebServiceBinding(ConformsTo = WsiProfiles::BasicProfile1_1)]
    public ref class MyWebService : public System::Web::Services::WebService
    {
    public:

        [WebMethod(Description = L"myMethod does something")]
        System::Void myMethod(MyClass ^myInstance)
        {
            DoSth(myInstance);
        }
    };
}

"HeaderFileGeneratedByWsdlExe.h" - это, конечно, файл заголовка, который я сгенерировал с помощью wsdl.exe (на основе указанного файла WSDL), указывая режим serverInterface. (В этом заголовочном файле определяется «MyClass».) На этом этапе можно правильно построить веб-сервис и запустить его. Я мог «обнаружить» файл wsdl моего веб-сервиса, сгенерировать для него прокси-классы на стороне клиента и реализовать клиентское приложение, которое могло бы правильно взаимодействовать с моим веб-сервисом. К сожалению, когда я использовал исходный файл WSDL для генерации прокси-классов на стороне клиента, клиентское приложение все еще могло отправлять экземпляр MyClass в веб-службу, но веб-служба не смогла сериализовать этот экземпляр MyClass.

Код необходимо изменить следующим образом:

// MyWebService.cpp : main project file.
#include "stdafx.h"
#include "Global.asax.h"
#include "HeaderFileGeneratedByWsdlExe.h"

using namespace System;
using namespace System::Web;
using namespace System::Web::Services;

namespace MyWebService {

    [WebService(Namespace = L"http://MyNamespace.org/")]
    public ref class MyWebService : public InterfaceFromHeaderFile
    {
    public:

        System::Void myMethod(MyClass ^myInstance)
        {
            DoSth(myInstance);
        }
    };
}

Модификации: - Я удалил атрибут WebServiceBinding. - Я создал класс из абстрактного прокси-класса на стороне сервера в сгенерированном заголовочном файле, а не из «WebService». - Я удалил атрибут WebMethod.

После этих модификаций все работает как положено.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...