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

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

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

Наши заботы обоснованы? Если да, то что мы должны опасаться?

Изменить

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

Edit2

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

Edit3

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

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

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

Ответ 1

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

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

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

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

Несколько старых советов.

Наконец, неверно, что вы не можете использовать XML-код in-code для генерируемых классов. С частичными классами С# вы можете написать отдельный код из сгенерированных классов с нужным документом in-code. Даже если вы перегенерируете код, ваш неполный код класса останется неизменным. EDIT: При компиляции документ будет отображаться в классах.

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

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

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 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 поддерживает коллекции и Enums просто отлично, Axis 1.4 любит массивы и ручные строки в стиле Java 1.4. Из этого WSDL вы создадите скелет на стороне сервера, используя WSDL2Java, в котором единственное, что вам нужно сделать, это реализовать свою бизнес-логику.