Проблемы сериализации WCF с файлом WSDL, созданным инструментами Java

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

Тем не менее, мы пытаемся использовать WCF / .NET 4.0 для генерации файлов классов прокси .NET, которые нам нужны на стороне клиента. Процесс создания файла прокси-класса клиента выполняется без проблем.

Проблема заключается в том, что мы пытаемся использовать файл прокси-класса в клиентском приложении. С помощью инструмента веб-трассировки Fiddler я убедился, что необработанный запрос сообщения SOAP не может быть отправлен по сети на сервер.

Конкретный. Message=XmlSerializer attribute System.Xml.Serialization.XmlAttributeAttribute is not valid in baseLanguage. Only XmlElement, XmlArray, XmlArrayItem, XmlAnyAttribute and XmlAnyElement attributes are supported when IsWrapped is true. Source = System.ServiceModel

Когда я исследую файл автоматически сгенерированного .NET прокси-класса, Reference.cs, я заметил, что сообщения запроса и ответа для моего метода веб-службы выглядят примерно так:

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.MessageContractAttribute(WrapperName="QueryPBOT_MXWO_OS", WrapperNamespace="http://www.ibm.com/maximo", IsWrapped=true)]
public partial class QueryPBOT_MXWO_OSRequest {

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=0)]
    public ConsoleApplication7.wsMaximo.PBOT_MXWO_OSQueryType PBOT_MXWO_OSQuery;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=1)]
    [System.Xml.Serialization.XmlAttributeAttribute()]
    public string baseLanguage;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=2)]
    [System.Xml.Serialization.XmlAttributeAttribute()]
    public string transLanguage;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=3)]
    [System.Xml.Serialization.XmlAttributeAttribute()]
    public string messageID;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=4)]
    [System.Xml.Serialization.XmlAttributeAttribute()]
    public string maximoVersion;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=5)]
    [System.Xml.Serialization.XmlAttributeAttribute()]
    [System.ComponentModel.DefaultValueAttribute(false)]
    public bool uniqueResult;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=6)]
    [System.Xml.Serialization.XmlAttributeAttribute(DataType="positiveInteger")]
    public string maxItems;

    [System.ServiceModel.MessageBodyMemberAttribute(Namespace="http://www.ibm.com/maximo", Order=7)]
    [System.Xml.Serialization.XmlAttributeAttribute(DataType="integer")]
    [System.ComponentModel.DefaultValueAttribute("0")]
    public string rsStart;

    public QueryPBOT_MXWO_OSRequest() {
    }

    public QueryPBOT_MXWO_OSRequest(ConsoleApplication7.wsMaximo.PBOT_MXWO_OSQueryType PBOT_MXWO_OSQuery, string baseLanguage, string transLanguage, string messageID, string maximoVersion, bool uniqueResult, string maxItems, string rsStart) {
        this.PBOT_MXWO_OSQuery = PBOT_MXWO_OSQuery;
        this.baseLanguage = baseLanguage;
        this.transLanguage = transLanguage;
        this.messageID = messageID;
        this.maximoVersion = maximoVersion;
        this.uniqueResult = uniqueResult;
        this.maxItems = maxItems;
        this.rsStart = rsStart;
    }
}

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

Я надеюсь, что автоматически сгенерированный прокси-файл клиента и исключение .NET помогут распознать эту проблему сериализации WCF.

Мы подтвердили от нашего поставщика Java, что стиль WSDL, который они генерируют, является doc-literal. После некоторого исследования в Интернете выяснилось, что по умолчанию WCF. переводит файлы WSDL в оболочку doc-literal, и это может объяснить, по крайней мере частично, почему мы

[System.Xml.Serialization.XmlAttributeAttribute ()]

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

Это исправление лучше, чем ничего, но я бы предпочел решение, которое не требует от меня или кого-либо из моей команды постоянно настраивать эти автоматически сгенерированные .NET прокси. файлы классов.

Я хотел бы знать, могу ли я что-то сделать с помощью различных инструментов WCF или путем изменения файла WSDL, что предотвращает применение этого [System.Xml.Serialization.XmlAttributeAttribute ()] к мои свойства объекта запроса и ответа?

Или, по крайней мере, высокоуровневое описание ПОЧЕМУ мы наблюдаем такое поведение сериализации в.NET с файлом Java WSDL?

заранее спасибо, 8s fetch, 24s query!

SELECT eventId, txtProperty2
FROM Warehouse
WHERE accountId IN (10, 8, 13, 9, 7, 6, 12, 11)
  AND scenarioId IS NULL
  AND insertDate BETWEEN DATE '2002-01-01' AND DATE '2011-12-31'
ORDER BY insertDate;

Эти два столбца практически идентичны по типу данных, которые они содержат: в основном ненулевые, и ни один из них не индексируется (в любом случае, это не должно иметь значения). Чтобы убедиться, что сама таблица исправна, я провел анализ / оптимизацию для нее.

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

EDIT - Больше точек данных

SELECT * фактически превосходит txtProperty2 - запрос 0,8 с, выборка 8,4 с. Жаль, что я не могу его использовать, потому что время выборки (как и ожидалось) слишком велико.