Как вы * используете * XML в мире веб-приложений?

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

Мне нужно как можно больше реальных примеров использования XML, чтобы:


  • Я полностью понимаю, что использует XML, когда хост A взаимодействует с хостом B, и я, конечно, могу представить, как должен / может использоваться XML. Реальность может быть совсем другой.
     
  • проводить тесты на реальных, а не гипотетических данных.
    То, как XML работает по сравнению с технологией X на наборах реальных данных, имеет такое же значение, как сравнение XML с технологией X на произвольном наборе данных.
     
  • определить и измерить любые шаблоны использования XML,
     например, только элементы, элементы плюс некоторые атрибуты или минимальные элементы и интенсивное использование атрибутов

Вопрос

Как вы используете XML в мире веб-приложений?

Когда Хост B возвращает XML-структурированные данные Хосту A через HTTP, что возвращается? Это может быть сервер, возвращающий данные в среде AJAX, или один сервер, сопоставляющий данные с одного или нескольких других серверов.

Идеальные ответы будут включать:

  • Реальный пример XML внутри ответа HTTP
  • URL, где это уместно, чтобы запросить выше
  • Объяснение, если необходимо, того, что представляют данные
  • Объяснение, если не очевидное, того, почему такие сообщения обмениваются (например, для выполнения пользовательского запроса; узел X возвращает отчет о состоянии работоспособности узлу Y)

Я бы предпочел примеры из приложений / сервисов, которые вы создали, разработали или работали, хотя любые примеры приветствуются. Все, от 5-строчного XML-документа до 10000-строчного монстра, было бы замечательно.

Ваше собственное мнение об использовании XML в вашем примере также было бы замечательно (например, мы реализовали XML-структурированные ответы из-за требования X / Person Y, хотя я думал, что JSON был бы лучше, потому что ...; или мы используем XML для сделайте это, потому что [действительно хорошая причина], и это просто лучший выбор для работы).

Обновление
Я очень ценю все ответы по теме XML в целом, однако то, что я действительно ищу, это реальные примеры тел ответов HTTP, содержащих XML .

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

Что могло бы принести большую пользу, так это впечатление о том, как в настоящее время используется XML для обмена данными между узлами HTTP, независимо от того, является ли текущее использование правильным или подходящим. Примеры случаев неправильного применения XML так же ценны, как и случаи, когда XML применяется правильно.

13.12.2008 22:33:15
10 ОТВЕТОВ

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

1
13.12.2008 23:04:04
Я сравниваю XML с буферами JSON, YAML и Google Protocol. В настоящее время я просто пытаюсь собрать данные об использовании XML.
Jon Cram 14.12.2008 00:07:15
Я работаю над продуктом, известным как Semotus HipLink, и мы широко используем JSON для вызовов AJAX.
fasih.rana 15.12.2008 19:21:02

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

2
13.12.2008 23:07:48
Наоборот, лучший ответ пока.
Jon Cram 14.12.2008 00:26:05
Если XML сложный, что просто? ASN.1 BER +?
bortzmeyer 15.12.2008 09:11:28
Предположим, у меня есть четыре поля данных, если они отправляются в формате XML, как будет выглядеть код синтаксического анализа ?? сложный обход дерева, чтобы получить пару значений. JSON намного лучше для этого.
hasen 24.12.2008 05:58:21

Eucaris - это веб-приложение для получения данных о регистрации автомобиля. Серверная часть использует данные XML типа XSD для сообщений с запросами и ответами.

0
13.12.2008 23:36:48

К сожалению, я не могу предоставить вам реальные данные по деловым / юридическим причинам.

По моему опыту, xml был стандартным форматом для более чем 90% серверных коммуникаций, над которыми я работал в последние годы, исключительно из-за преобладания инструментов для работы с ним и того факта, что большинство разработчиков имеют некоторый опыт с этим.

Что-то вроде буферов протокола google может быть более эффективным для многих задач, но удобство и безопасность формата, который большинство программистов с опытом «предприятия» уже знают, как использовать, трудно обосновать.

Если вы продаете услугу внешнему миру, гораздо проще продать, если вы предлагаете интерфейс на основе xml, CIO читает «веб-сервис на основе xml», CIO говорит: «Хорошо, моя команда знает, что ...»

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

1
13.12.2008 23:45:02

Мой совет - пропустить XML и взглянуть на что-то более простое, например JSON. XML предоставляет только две вещи:

1) «стандартизированный» способ сериализации сложных данных 2) способ проверки (через DTD) правильности вышеуказанной сериализации

Обратите внимание, что «стандартизировано» в кавычках. Единственное, что стандартизировано - это способ форматирования тегов. То, что означают теги, совсем не стандартно. В конце концов, единственное, что дает вам XML - это хороший анализатор, который вам не нужно писать самостоятельно.

Если данные, которые вы передаете, могут быть представлены в виде простой строки, массива или ассоциативного массива (или хеша), XML является излишним.

2
13.12.2008 23:46:56
Да, это касается того, что я изучаю. XML считается излишним. В каких / точных / и / измеримых / отношениях лучше альтернативы (JSON / YAML)? Они предлагают повышение производительности? Каким образом такие выгоды могут быть отражены в бизнес-терминах?
Jon Cram 14.12.2008 00:28:09
Я согласен, но я бы не стал недооценивать ценность наличия хорошего парсера. По моему опыту, большинство людей не могут писать хорошие парсеры, в итоге они становятся очень хрупкими.
user10892 14.12.2008 03:44:17

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

Однако, если клиент и сервер реализованы одной и той же командой, то нет смысла переводить их между собой в удобочитаемой форме, и почти всегда есть более быстрая, более дешевая (с точки зрения обработки) альтернатива, даже если технологии клиента и сервера разные.

Сосредоточив свои замечания на протоколах передачи, еще до того, как XML пришел в «плохие» старые времена клиент / сервер, когда пропускная способность и вычислительная мощность были ценными, архитекторы должны были бы разработать протокол (обычно двоичный) с единственной задачей: эффективность и скорость, где размер пакета будет минимизирован. Очевидным ограничением является то, что рукопожатие было очень конкретным, а бинарный диалект был непонятным, если он не был опубликован. Положительным моментом было то, что он был чрезвычайно эффективным и мог быть высоко оптимизирован для применения под рукой. Очень часто бинарные форматы публиковались (вы видели старую спецификацию Excel BIFF - не протокол, а пример публикации бинарного формата).

XML в HTTP, то есть SOAP, сломал это. Обоснование было очень вменяемым, иметь универсально понятный протокол для рукопожатия, своего рода компьютерный эсперанто , чтобы вы могли разделить архитектуру своего клиента и сервера и совершенно независимо определять их темпы разработки и внутренние компоненты. Более того, защищайте себя от возможных требований клиента, обещая, что переключение клиентов - это всего лишь вопрос внедрения нового. Более того, позвольте любому Joe с анализатором XML использовать ваш API. Все отличные вещи и привели к образованию грибов очень хорошо обозначенных архитектур - что вполне хорошо.

Таким образом, в значительной степени сила этого предложения была проявлена ​​и есть явные преимущества, однако я думаю, что а) это требование часто завышено и б) протоколы XML часто реализуются очень небрежно и со скудным учетом стоимости обработки, которую они подразумевают. Более того, изначально здравомыслящие рассуждения уступили место случаям экстремистской религии (держу пари, что за меня проголосовали), и я видел код, передающий XML между вызовами функций в одних и тех же классах , используя именно обоснование будущего и аргументы функционального разделения, которые это явно помешанный.

Поэтому моя мантра - сделать общение эффективным и действенным. Если это означает предоставление обобщенного API и протокола для произвольных и неизвестных потребителей, то XML является очень хорошим выбором. Если это означает создание молниеносной, масштабируемой клиент-серверной (т. Е. Веб-) архитектуры, тогда я пытаюсь использовать двоичный протокол, часто использующий мой собственный.

Появление JSON свидетельствует о том, что в XML-фургоне было слишком много уровней. JSON - это попытка сократить структурные элементы при сохранении общности и тем самым получить преимущества меньших пакетов. Протоколы, такие как AMF от Adobe, как правило, гораздо более компактны и почти полностью бинарны.

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

Представьте, что ваш средний клиент / серверный запрос был 1/10 от размера и текст не разбирался ни на одном конце, но вы сохранили общность интерфейса. Я не знаю ни одного разработчика, который бы не принял это.

3
14.12.2008 00:09:30

Как и многие другие, в какой-то момент я экспериментировал с SOAP и XMLRPC, но обнаружил, что поддержка браузера настолько слаба, что мне пришлось «откатываться» на специализированный синтаксический анализатор, когда MSXML преградил ввод. Ранние версии моего приложения netMail раньше использовали XML, а MSIE просто недостаточно быстро разбирал XML. У меня все еще есть реализация XML, если вы действительно заинтересованы в ее просмотре.

Сразу вспоминаются два примера из реальной жизни , с которыми мне приходилось сталкиваться в последние несколько месяцев:

При работе с XML-интерфейсом упорядочения Ingram-Micro сообщения зависят от порядка всех элементов и очень чувствительны к проблемам кодирования. Просто не было возможности использовать стандартные инструменты обработки XML для взаимодействия с ним. Специальное решение было бы лучше, потому что тогда не было бы вопроса, в каком порядке поступали элементы. Обмены выполняются как push, так и pull методами; с нашего сервера POSTing данных в конечную точку IM-XML, а их сервер POSTing данных обратно.

XML-каналы MRIS состоят из строки, такой как <Data Separator = "~">, а затем из ~набора данных с неограниченным количеством данных. Ленты имеют размер в несколько мегабайт, и простой подход, ориентированный на чтение и разделение строк вместо «XML», позволяет выполнять работу с меньшими затратами памяти и быстрее. Данные «XML» периодически загружаются через HTTP GET.

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

Чаще всего я нахожу, что я использую необработанные выражения javascript (часто называемые JSON), когда задействован браузер (просто потому, что evalэто «как можно быстрее»), и S-выражения в противном случае.

Извините, я не могу помочь вам с хорошими примерами XML в Интернете; Я просто не думаю, что они есть.

0
14.12.2008 00:42:14

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

1
14.12.2008 00:50:22

Я использовал XML в веб-приложениях несколько раз. Все время это происходило через веб-сервисы SOAP. Это потому, что я программирую в Visual Studio, которая имеет отличную встроенную поддержку веб-служб SOAP. Он автоматически генерирует оболочки ООП, что позволяет легко использовать его как из AJAX (клиентская часть), так и .NET (серверная часть для межсерверных коммуникаций).

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

1
14.12.2008 00:53:52

Я приведу два примера потребностей, которые мы удовлетворили с помощью XML:

  1. Нам нужно было передать данные, собранные со многих серверов UNIX, о распределении файлов, отправив данные на сервер Windows для анализа. Детали и резюме графически отображаются через веб-приложение.

  2. Нам нужно было хранить несколько форматов ответов формы в одном репозитории для последующего поиска и «воспроизведения». Формы создаются, хранятся, ищутся и воспроизводятся в веб-приложении.

В обоих случаях нам нужна была возможность передавать свободно структурированные данные в самоопределяемом формате. В обоих случаях мы изобрели общую структуру XML, которую было легко генерировать для процесса отправки, чтобы процесс получения мог одновременно хранить (по существу, одну длинную строку), искать и декодировать, и теперь его легко читать и понимать люди. и после того, как мы все давно ушли. Мы могли бы изобрести синтаксис, отличный от XML, но никто не мог придумать ничего лучшего в то время, и это нам хорошо послужило. Я не могу поделиться конкретными примерами, потому что данные считаются частными.

1
14.12.2008 07:04:29