Использование языка XML для сообщений
Использование языка XML для работы с сообщениями системы представляет меньше связанных с проектированием проблем, чем использование его для постоянных данных. Это связано с тем, что каждое сообщение обычно бывает сравнительно автономным, и вопрос о том, что в него включить, естественным образом выпадает из модели обработки.
Разумеется, термин "сообщение" мы используем в широком смысле. Эти сообщения могут быть составлены в стиле электронного обмена данными. Или это могут быть данные, которыми обмениваются подсистемы в форме сообщения XML. Кроме того, сообщение может быть предназначено для отображения на экране. В таком случае, ответ на запрос вернется из базы данных в виде сообщения XML, но клиентская система (или браузер) преобразует его в видимую страницу с помощью соответствующей таблицы стилей.
Существуют некоторые общие принципы проектирования, применимые ко всем сообщениям XML, независимо от их роли:
- Проект сообщения должен отражать содержание информации, а не предполагаемое ее использование.
- Проект должен поддерживать будущие изменения. Составление проекта на языке XML позволяет избежать таких традиционных подводных камней, как фиксированная ширина полей или фиксированный порядок столбцов. Однако проектировщик документа также отвечает за разработку такой структурной информации, которая могла бы предугадать будущие изменения.
- Для сообщений лучше использовать стандартный тип (если он имеется), а не выдумывать новый. В настоящее время доступно большое количество стандартизированных сообщений, например созданных в рамках инициативы BizTalk.
- Кодирование данных должно быть настолько близко к принятым кодировкам, насколько это возможно в рамках существующих ограничений производительности. Не стоит создавать идентификаторы, формирующие внутренние зависимости между сообщением и имеющейся базой данных. Сообщения должны быть автономными.
Надо ли включать ненужную в настоящий момент информацию, которая может потребоваться в дальнейшем? На этот вопрос нет универсального ответа.
С одной стороны, легче включить все свойства проекта, а не выбирать те, в которых заинтересован реципиент. Затем можно передать все эти свойства получателю и дать ему возможность проигнорировать ненужные. С другой стороны, глупо посылать лишние данные, учитывая еще проблемы безопасности или секретности. Принимаемое решение должно диктоваться прагматическими соображениями.
Имеет смысл включить в сообщение некоторую официальную информацию, даже если она дублирует доступную из других систем передачи сообщений. Очевидно, это дата и время, личность отправителя и получателя; с помощью серийного номера можно проконтролировать, что сообщение не было утеряно при передаче или отправлено дважды. Для включения всего этого в сообщения XML существуют две причины: реципиенту проще прочитать информацию из сообщения, а не извлекать ее откуда-то еще с помощью специального интерфейса API; и что более важно при архивировании сообщений для последующего аудита, - всю информацию легче сохранять в одном месте.