Разработка совместимых веб-сервисов

Question

Я разрабатываю набор веб-сервисов, позволяющих нашим клиентам подключаться из своих приложений к одной из наших систем. Наши клиенты имеют свои приложения, разработанные во всех видах фреймворков (.NET, Java, PHP, Python и даже иногда все приложения JS), поэтому, очевидно, WS - это путь.

Изучая немного о действительно взаимодействующем WS, я обнаружил, что нужно сначала разработать WSDL и XSD и извлечь из них реализации.

Что я действительно ищу, так это руководство, если это действительно путь. Я читал, что WCF создает совместимый WS, но я не фанат MS, создающей что-то стандартное.

Должен ли я использовать WCF или есть хороший набор инструментов для разработки WSDL и XSD без боли, которую я ожидаю.

Заранее спасибо

Answer 1

Если вы хотите взаимодействовать с JavaScript, лучше использовать API в стиле REST. Это в основном просто стандартные HTTP-вызовы, так что вы можете взаимодействовать с самого начала. Однако вы указали, что хотите использовать SOAP, поэтому ...

Если вы собираетесь использовать SOAP / WSDL, я бы определенно рекомендовал использовать серверную платформу - да, даже .NET - для генерации WSDL, а затем просто проверить, что используемые вами опции дают хорошую, интероплируемую WSDL.

Я разработчик Java с историей PHP и Perl, и я взаимодействовал с .Net в ряде проектов WS с обеих сторон медали (как сервера, так и клиента). Там обычно нет серьезных проблем - просто будьте осторожны с парой вещей:

• определенные фирменные элементы, которые MS смешивается с открытыми стандартами. За Например, они могут предложить стиль NTLM аутентификация, которая на самом деле не необходимо в большинстве случаев использования, особенно когда вы используете SSL сертификаты.
• Мыло заняло несколько разные формы на протяжении многих лет (Документ / Литерал, RPC / Кодированный, ...) вы, вероятно, найдете, что вам не нужно беспокоиться об этом, так как RPC / Encoded умер вместе со старыми рамками, и большинство современных рамок имеют тенденцию к Документ / Литерал
• SOAP предлагает несколько Стандарты болтовых креплений (например, MTOM и DIME для вложений и SOAP-WS для аутентификация). Старайтесь избегать тех, болты, как разные платформы реализовать различные подмножества.
• В целях безопасности я бы посоветовал использовать SSL для доверие и конфиденциальность, а затем либо базовая аутентификация HTTP, либо просто пользовательская строковые токены в вашем определении мыльного запроса.

Просто держите WSDL как можно меньше, попробуйте взаимодействовать довольно рано, и у вас не должно быть слишком много проблем

Answer 2

Вы можете использовать WCF и контрактную разработку.

Если совместимость является основной проблемой, то я бы порекомендовал использовать WCF для обеспечения реализации службы, но вместо того, чтобы полагаться на WCF для создания интерфейса службы и использовать разработку на основе контракта для моделирования интерфейса.

Действительно хорошая статья о том, как разработать этот способ, - Разработка на основе схем с помощью Windows Communication Foundation .

Если вы собираетесь создавать свои собственные WSDL и схемы, вам, вероятно, понадобится редактор, такой как XmlSpy или LiquidXml. Мне нравится цена LiquidXML (бесплатно!), Но я не могу вспомнить, если вам придется платить за функции веб-службы.

Еще один интересный инструмент для первоочередной разработки с использованием Visual Studio и WCF - WSCF.blue . Я не использовал его, но, похоже, он активно разрабатывается на основе WCSF.blue дорожной карты .

Answer 3

Я не уверен, что вы имеете в виду, когда спрашиваете "должен ли я использовать WCF"? WCF - это текущий механизм разработки веб-сервисов (и других видов коммуникационных сервисов) в .NET. Нет другого действующего механизма. Другие устарели или считаются «устаревшей технологией».

Answer 4

WSDL и XSD не зависят от языка, вам просто необходим какой-то механизм для общения с использованием других языков. Хорошая вещь для вас - проектирование данных ядра IMHO, поэтому вам не нужно будет столько XSD для одних и тех же объектов данных.