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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На ум приходят два реальных примера немедленно, с которыми мне приходилось иметь дело в последние несколько месяцев:

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

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

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

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

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

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

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

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

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

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

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

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