Гарантия того, что служба .NET WCF может использоваться клиентом Java

Question

Я создаю службу WCF, которая будет использоваться клиентскими приложениями .NET и Java.

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

Наше беспокойство обосновано? Если так, то с чем нам следует опасаться?

Редактировать

Одним из примеров беспокойства является то, представлено ли значение .NET DateTime в интерфейсе службы способом, который может быть правильно понят клиентом Java.

Edit2

Вторым примером проблемы является использование любых типов значений, допускающих значение null (bool?, int? и т. Д.).

Edit3

В настоящее время некоторые из наших команд разработчиков пишут файлы .xsd для определения различных объектов, которые методы интерфейса WCF будут принимать в качестве аргументов и возвращать в качестве возвращаемых значений. Затем они используют xsd.exe для автоматической генерации классов C # из них.

Смысл этого в том, что он гарантирует, что сгенерированные классы не будут содержать ничего специфичного для .NET.

Недостатком является то, что это увеличивает нагрузку на разработку, а также не позволяет нам документировать эти классы с помощью тегов <summary> (.NET-эквивалент комментариев javadoc).

Answer 1

Рекомендуется начать с XSD. Это не гарантирует совместимость с каждой стороны, поскольку XML-схема действительно велика, и ни один стек веб-служб не поддерживает все это. (Пример: списки).

Итак, начните с XSD, но ограничитесь основными типами. Примитивы, сложные типы, состоящие из примитивов, массивов одного и того же. Вы можете смело вкладывать сложные типы и массивы. (массивы сложных типов, сложные типы, которые содержат массивы или сложные типы и т. д.).

Держитесь подальше от ограничений, групп замещения, списков, дериваций и любой другой XSD-эзотерики. Следует избегать даже перечислений XSD.

О дате и времени: Недостаточно использовать обнуляемую дату и время. Также есть проблемы с форматированием. .NET DateTime - это более высокое разрешение по сравнению с календарем Java, в результате чего отправка времени .NET на Java может привести к исключениям десериализации на стороне Java. ( РЕДАКТИРОВАТЬ: используя декоратор DataType = "dateTime" в атрибуте XmlElement на стороне .NET может убедиться, что вы сериализованы правильно)

Несколько старых советов по этому вопросу.

Наконец, неверно, что вы не можете использовать встроенный XML-документ в генерируемых классах. С частичными классами C # вы можете написать отдельный код из сгенерированных классов с нужным вам документом в коде. Даже если вы перегенерируете код, ваш частичный код класса останется неизменным. РЕДАКТИРОВАТЬ: Когда вы скомпилируете, документация появится в классах.

РЕДАКТИРОВАТЬ: Кто-то спросил, если использование XSD-first недостаточно для обеспечения взаимодействия, зачем его использовать? Мой ответ: это не гарантия, но хороший шаг, это помогает. Он удерживает вас от разработки интерфейсов в коде (либо Java, либо C #, либо VB и т. Д.), Который раскрывает специфичные для платформы вещи, такие как .NET DataSets, универсальные словари, Java ResultSets и т. Д., И все это создает проблемы взаимодействия. В более маргинальных частях XSD все еще есть подводные камни, но обычно их можно избежать с продуманным дизайном.

Я должен был упомянуть в своем первоначальном ответе, что вы можете применить итеративный процесс к разработке интерфейса. Спроектируйте в XSD, затем сгенерируйте (клиентский) заглушку и (серверный) код скелета из XSD + WSDL, затем настройте и сделайте это снова.

Answer 2

Использование basicHttpBinding конечной точки гарантирует, что любой SOAP 1.1-совместимый клиент сможет использовать ваш сервис.

Answer 3

Использовать DateTime ?, то есть обнуляемую структуру. В Java нет понятия сложных типов значений (то есть структур). Я полагаю, что в WSDL есть способы указать недопустимые значения NULL, но я думаю, что WCF не делает этого «из коробки».

Используйте массивы вместо коллекций. Если я правильно помню, типы коллекций не очень хорошо транслируются по SOAP, но типы массивов работают довольно хорошо.

Вы должны получить копию Eclispe или Netbeans. После создания прототипа службы WCF запустите мастер веб-службы, чтобы создать прокси-серверы. Проверьте объектную модель на наличие серьезных дефектов с особым акцентом на сложные объекты или непримитивные типы (трактуйте строку как примитив).

Кривая обучения для работы с Netbeans или Eclipse довольно плоская, поэтому это не огромная нагрузка.

Редактировать: другие потенциальные проблемы с привязками. Если вы придерживаетесь HTTP (S), вам следует хорошо ... начать переходить на альтернативы, такие как TCP или MSMQ, вам придется проделать большую работу в Java. Кроме того, некоторые функции безопасности не взаимодействуют во всех случаях, например при использовании токенов NTLM ... Используйте итеративный подход. Начните с простого связывания HTTP с SOAP без обеспечения безопасности и перейдите оттуда.

Answer 4

Предоставляет ли WCF стандартные интерфейсы SOAP? Если это произойдет, то, чтобы заставить Java общаться с ним, должно быть пустяком.

Re: Edit1: WSDL / XSD будет использовать стандартный формат даты и времени (Календарь в конце Java, отформатированная строка даты и времени в SOAP, DateTime в .NET), или вы можете принудительно преобразовать его в строковый формат вашего собственный выбор.

Ознакомьтесь с документацией Apache Axis (1.4 и 2.0) для веб-сервисов Java. Его очень просто использовать для настройки клиента веб-службы Java с помощью wsdl / xsd, предоставляемого вашей веб-службой.

Edit3: в Java вы определяете модель Java (со всей вашей любимой документацией), затем запускаете Java2WSDL (желательно как задачу ANT / Maven) для создания WSDL (однако я обнаружил, что вам нужно изменить порядок полей) в этом). Axis 2 поддерживает коллекции и перечисления просто отлично, Axis 1.4 любит массивы и перечисления вручную в стиле Java 1.4. Из этого WSDL вы создадите серверный скелет с использованием WSDL2Java, в котором единственное, что вам нужно сделать, это реализовать свою бизнес-логику.