Содержание


Изменения в форматах сообщений WebSphere MQ во время их передачи и в очередях

IBM® WebSphere® MQ – это отмеченное наградами промежуточное ПО IBM для коммерческих систем передачи сообщений и управления очередями. Очередь сообщений – это способ установления связи между программами, при котором приложения обмениваются специфическими данными через механизм очереди, без необходимости создания специального защищенного логического соединения. Сообщение – это просто последовательность байтов, которая имеет смысл для использующего его приложения, а очередь – это контейнер для сообщений.

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

Эволюция формата сообщений WebSphere MQ

Сообщения WebSphere MQ имеют типичный формат "заголовок-тело". В разных версиях WebSphere MQ заголовок и тело различаются по смыслу и содержанию. Однако с первой версии WebSphere MQ до версии V6 (далее просто V6) формат сообщений изменился мало. В WebSphere MQ V7 (далее V7) в формат сообщений были внесены существенные изменения для обеспечения лучшей совместимости приложений Message Service (JMS) с Java™.

Формат сообщений до версии WebSphere MQ V6 включительно

Вплоть до V6 сообщения WebSphere MQ состояли из двух компонентов:

  • дескриптора сообщения (заголовок сообщения);
  • данных приложения (тело сообщения).

На рисунке 1 показан формат сообщений по версии V6.

Рисунок 1. Формат сообщений по версию V6
Формат сообщений по версии V6
Формат сообщений по версии V6

Дескриптор сообщения связан с каждым сообщением, которое стоит в очереди в диспетчере очереди. Он идентифицирует сообщение и содержит информацию управления, такую как тип сообщения и его приоритет, присвоенный отправившим его приложением. Раздел данных приложения содержит все актуальные данные сообщения (полезная нагрузка) и любые дополнительные заголовки, такие как заголовок передачи или информационный заголовок IMS. WebSphere MQ не налагает никаких ограничений на содержание данных приложения, за исключением максимальной длины, которая в зависимости от версии WebSphere MQ колеблется от 4 до 100 МБ. Максимальная длина сообщения может определяться также диспетчером очереди, каналом передачи данных или конкретной очередью.

В разных версиях до V6 включительно сообщения имеют одну и ту же структуру, за следующими исключениями:

  • начиная с V5, изменился дескриптор атрибутов сообщения – подробнее см. ниже;
  • обогатились типы данных дополнительных заголовков, предшествующих сообщению. Например, начиная с V5б добавилось расширение дескриптора сообщений (MQMDE), а начиная с V6 – заголовок Embedded PCF (MQEPH).

1. Дескриптор сообщения

Дескриптор сообщения определяется структурой MQMD, которая содержит ряд полей с информацией о сообщении. В следующих разделах подробно описываются два таких атрибута.

  • Version

    Есть две версии дескриптора сообщения. Начиная с V5, сообщения могут быть сегментированными или сгруппированными. Для этой новой функции понадобились дополнительные поля дескриптора сообщения для сведений о сегментации и группировании. Эта расширенная структура представляет собой версию 2, которая является текущей версией дескриптора сообщения. V2 дескриптора сообщения отличается от V1 только дополнительными полями, определяемыми структурой MQMDE: GroupId, MsgSeqNumber, Offset, MsgFlags и OriginalLength.

    Другие диспетчеры очереди, которые не поддерживают эти функции (так называемые диспетчеры очереди V1) рассматривают дополнительную информацию как данные. Дескриптор сообщения V2, как правило, эквивалентен использованию дескриптора сообщения V1 с добавлением перед ним структуры MQMDE. Диспетчеры очереди, которые поддерживают сегментацию и группирование сообщений, называются диспетчерами очереди V2. На рисунке 2 показана связь между MQMD V1 и V2.

    Рисунок 2. Взаимосвязь между MQMD V1 и V2
    Взаимосвязь между MQMD V1 и V2
    Взаимосвязь между MQMD V1 и V2
  • Format

    Формат – это имя, которое отправитель сообщения использует для указания получателю характера данных, содержащихся в сообщении. У диспетчера очереди есть ряд встроенных форматов с именами, начинающимися с MQ, такими как MQFMT_STRING. Формат можно использовать также для того, чтобы показать, что существует дополнительный заголовок (расширение). Например, если в поле Format дескриптора сообщения содержится MQFMT_CICS, это означает, что данные сообщения начинаются с информационного заголовка CICS MQCIH, за которым следуют основные данные. На характер данных нагрузки указывает поле Format заголовка MQCIH. Такое использование поля Format иллюстрируется на рисунке 3.

    Рисунок 3. Использование поля Format для указания вида данных в сообщении
    Использование поля Format для указания вида данных в сообщении
    Использование поля Format для указания вида данных в сообщении

2. Данные приложения

Раздел данных приложения содержит фактические данные, передаваемые из одной программы в другую, а его содержание и структура определяются приложением, которое его использует. Как правило, данные приложения содержат только значимую для приложений информацию, поскольку для управления достаточно информации, содержащейся в дескрипторе сообщения. Но в некоторых случаях требуется больше информации управления, и полезные данные предваряются дополнительными заголовками, как показано на рисунке 1. Дополнительные заголовки могут добавляться приложением в конкретных целях, например, для добавления к данным приложения информации заголовка IMS (MQIIH) при передаче сообщения в мост IMS. Кроме того, иногда заголовки добавляются самим WebSphere MQ, как описано ниже.

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

Таблица 1. Структуры дополнительных заголовков, определяемых WebSphere MQ
ЗаголовокОписание заголовкаИмя формата
MQCIHИнформационный заголовок CICSMQFMT_CICS
MQDLHЗаголовок недоставленного письмаMQFMT_DEAD_LETTER_HEADER
MQDHЗаголовок списка рассылкиMQFMT_DIST_HEADER
MQEPHЗаголовок встроенного PCFMQFMT_EMBEDDED_PCF
MQIIHИнформационный заголовок IMSMQFMT_IMS
MQMDEРасширение дескриптора сообщенияMQFMT_MD_EXTENSION
MQCFHЗаголовок PCFMQFMT_ADMIN / MQFMT_EVENT / MQFMT_PCF
MQRMHЗаголовок справочного сообщенияMQFMT_REF_MSG_HEADER
MQRFHЗаголовок форматированияMQFMT_RF_HEADER
MQRFH2Правила и форматирование версии 2 headerMQFMT_RF_HEADER_2
MQWIHРабочий информационный заголовокMQFMT_WORK_INFO_HEADER
MQXQHЗаголовок очереди передачиMQFMT_XMIT_Q_HEADER

Дополнительные заголовки могут сцепляться, т. е. данные приложения могут дополнительно содержать один или более заголовков, предшествующих основным данным. Рассмотрим в качестве примера сообщения для приложений публикации/подписки до версии WebSphere MQ V7 – данные сообщения могут начинаться с последовательных заголовков MQRFH1 и MQRFH2. Если основным данным предшествуют несколько заголовков, они сцепляются посредством поля Format, как показано на рисунке 3.

Формат сообщений в версии WebSphere MQ V7

А WebSphere MQ V7 (далее V7) появилось понятие свойств сообщений (из JMS), так что компонентов сообщения WebSphere MQ стало два:

  • свойства сообщения (заголовок сообщения);
  • данные приложения (тело сообщения).

На рисунке 4 показан формат сообщения V7, а также соответствие между свойствами сообщения и дескриптором сообщения.

Рисунок 4. Формат сообщения, начиная с V7
Формат сообщения, начиная с V7
Формат сообщения, начиная с V7

1. Свойства сообщения

Свойства сообщения – новшество V7 в рамках интерфейса очереди сообщений (Message Queue Interface – MQI). Вызовы новой функции MQI используются для установки, выяснения и удаления свойств сообщения (MQSETMP, MQINQMP и MQDLTMP). Свойства сообщения можно использовать также для включения бизнес-данных или информации о состоянии без необходимости хранить их в данных приложения. Использование свойств сообщения в WebSphere MQ аналогично использованию свойств в JMS, что позволяет установить свойства в приложении JMS и извлекать их в процедурном приложении WebSphere MQ, или наоборот.

Свойства сообщения следуют за любым сообщением в диспетчере очереди WebSphere MQ, причем каждое из них состоит из текстового имени и значения того или иного типа. Размер свойств сообщения не может превышать значения MaxPropertiesLength диспетчера очереди. Свойства сообщения не учитываются в длине сообщения для очереди и диспетчера очереди, но учитываются в длине свойств с точки зрения диспетчера очереди. Существует предельная длина свойств каждого сообщения в 100 МБ, исключая дескриптор сообщения и его расширение.

2. Свойства сообщения, представленные в виде MQRFH2

Свойства сообщения могут быть представлены как элементы MQRFH2. Рисунок 5 иллюстрирует структуру заголовка MQRFH2.

Рисунок 5. Структура заголовка MQRFH2
Структура заголовка MQRFH2
Структура заголовка MQRFH2

Строка, помещаемая в поле NameValueData, состоит из одной папки, содержащей ноль или более свойств. Содержимое папки рассматривается как свойства сообщения, если в начальный тег папки включен элемент content=properties. Если каждая папка в заголовке содержит свойства, сами поля заголовка MQRFH2 добавляются к длине свойств сообщения и относятся к разделу свойств сообщения. В противном случае поля заголовка относятся к длине сообщения и являются частью данных приложения. Таким образом, если буфер включает в себя свойства, приложение может поместить сообщение в буфер большей длины, чем значение MaxMsgLength.

3. Поля дескриптора сообщения как свойства

Большинство полей дескриптора сообщений, за исключением StructId и Version, можно рассматривать как свойства. Имя свойства образуется с помощью добавления префикса к имени поля дескриптора сообщения, как в примере Root.MQMD.Priority. Здесь Priority – это поле в дескрипторе сообщения. Поля дескриптора сообщения никогда не представлены в заголовке MQRFH2, как другие свойства. Если данные сообщения начинаются с MQMDE, то есть обслуживаются диспетчером очереди, то к полям MQMDE можно обращаться с помощью того же синтаксиса, который описан выше. В этом случае, с точки зрения свойств, поля MQMDE логически обрабатываются как часть MQMD.

4. Сообщение, передаваемое в предыдущую версию

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

Рисунок 6. Отношения соответствия между сообщениями в V7 и V6
Отношения соответствия между сообщениями в V7 и V6
Отношения соответствия между сообщениями в V7 и V6

Таким образом, значение атрибута MaxMsgLength каналов, ведущих в системы до V7, должно увеличиваться, чтобы компенсировать дополнительные данные, которые могут содержаться в каждом сообщении.

Изменение сообщений в очереди сообщений

Пока сообщение перемещается через WebSphere MQ из одной программы в другую, в него могут вноситься изменения, призванные направлять его к месту назначения. В этом разделе рассматриваются различные способы изменения сообщения в WebSphere MQ во время его передачи. Изменения вносятся автоматически диспетчерами очереди, агентами канала передачи сообщений или другими инфраструктурами WebSphere MQ и прозрачны для приложений.

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

Добавление дополнительной информации управления

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

Случай 1. Сообщение ставится в удаленную очередь

Когда сообщение ставится в удаленную очередь, перед постановкой сообщения в очередь передачи WebSphere MQ добавляет к нему структуру заголовка передачи (MQXQH). Заголовок передачи содержит имена очереди назначения (RemoteQName) и диспетчера очереди (RemoteQMgrName), т. е. сведения об адресе. Эта информация используется для маршрутизации сообщения в нужное место в сети. В таблице 2 перечислены некоторые основные поля MQXQH.

Таблица 2. Основные поля MQXQH
ПолеОписание
RemoteQNameИмя очереди назначения
RemoteQMgrNameИмя диспетчера очереди назначения
MsgDescДескриптор первоначального сообщения (встроенный)

Кроме информации об адресе, в структуре MQXQH, как часть данных сообщения, хранится встроенный дескриптор сообщения (MsgDesc). Он формируется приложением в самом начале. Другой дескриптор сообщения порождается диспетчером очереди, когда сообщение помещается в очередь передачи, хранится отдельно от данных сообщения и называется отдельным дескриптором сообщения. Таким образом, в очереди на передачу сообщение имеет два дескриптора, как показано на рисунке 7.

Рисунок 7. Структура сообщений в очереди на передачу
Структура сообщений в очереди на передачу
Структура сообщений в очереди на передачу

Встроенный дескриптор сообщения – это всегда структура MQMD V1. Если сообщение, созданное приложением, имеет значения не по умолчанию для одного или нескольких полей V2 в MQMD, за MQXQH следует структура MQMDE, а за ней, в свою очередь, следуют данные приложения сообщения, как показано на рисунке 7.

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

Случай 2. Диспетчер очереди не может доставить сообщение

В этом случае WebSphere MQ добавляет к сообщению структуру заголовка недоставленного письма (MQDLH) и ставит его в очередь недоставленных сообщений. Кроме того, поле Format дескриптора сообщения (MQMD) изменяется таким образом, чтобы показать, что сообщение содержит структуру MQDLH. Эта структура включает в себя имя целевой очереди и причину, по которой сообщение было помещено в очередь недоставленных сообщений. В таблице 3 приведены основные поля в MQDLH.

Таблица 3. Основные поля MQDLH
ПолеОписание
ReasonПричина помещения сообщения в очередь недоставленных сообщений
DestQNameИмя первоначальной очереди назначения
DestQMgrNameИмя диспетчера первоначальной очереди назначения
FormatИмя формата данных, которые следуют за MQDLH
PutApplTypeТип приложения, поставившего сообщение в очередь недоставленных сообщений
PutApplNameИмя приложения, поставившего сообщение в очередь недоставленных сообщений

Сообщения могут быть включены в очередь недоставленных сообщений диспетчерами очередей, агентами каналов передачи сообщений (message channel agents – МКА) и приложениями. Всем сообщениям из очереди недоставленных сообщений должен предшествовать заголовок MQDLH, и сообщения могут урезаться, если из-за добавления MQDLH они становятся слишком длинными для этой очереди.

Приложениям, которые получают сообщения из очереди недоставленных сообщений, необходимо убедиться, что сообщение начинается со структуры MQDLH. Приложение может определить, присутствует ли структура MQDLH, проверив поле Format дескриптора сообщения. Если в этом поле находится значение MQFMT_DEAD_LETTER_HEADER, данные сообщения начинаются со структуры MQDLH.

Случай 3. Отправка сообщения в несколько очередей

В этом случае WebSphere MQ добавляет в сообщение структуру заголовка распределения (MQDH) и ставит его в соответствующую очередь на передачу. Таким образом, данные приложения сообщения предваряются структурами MQXQH и MQDH. MQDH описывает дополнительные данные, содержащиеся в сообщении, когда это сообщение списка рассылки, хранящееся в очереди на передачу. Сообщение списка рассылки – это сообщение, отправленное в несколько очередей назначения. Дополнительные данные представляют собой структуру MQDH, за которой следуют массив записей MQOR и массив записей MQPMR. В таблице 4 приведены основные поля в MQDH.

Таблица 4. Основные поля MQDH
ПолеОписание
StrucLengthДлина структуры MQDH плюс следующие записи
FormatИмя формата данных, которые следуют за массивом записей MQPMR
PutMsgRecFieldsФлаги, указывающие, какие поля MQPMR присутствуют
RecsPresentКоличество присутствующих записей object
ObjectRecOffsetСмещение первой записи object от начала MQDH
PutMsgRecOffsetСмещение первой записи put-message от начала MQDH

Данные сообщения списка рассылки в очереди сообщений на передачу выстраиваются в следующем порядке:

  • структура MQXQH;
  • структура MQDH плюс массивы записей MQOR и MQPMR;
  • данные сообщения приложения (полезные данные).

Структура сообщения списка рассылки в очереди на передачу показана на рисунке 8.

Рисунок 8. Структура сообщений типа списка рассылки в очереди на передачу
Структура сообщений типа списка рассылки в очереди на передачу
Структура сообщений типа списка рассылки в очереди на передачу

StrucLength – это количество байтов от начала структуры MQDH до начала данных сообщения после записей массивов MQOR и MQPMR. ObjectRecOffset определяет смещение в байтах первой записи в массиве записей объектов MQOR, который содержит имена очередей назначения. PutMsgRecOffset задает смещение в байтах первой записи в массиве записей MQPMR put-message, который содержит свойства сообщения.

Случай 4. Сообщение – это сегмент или сообщение в группе

В этой ситуации WebSphere MQ может добавить структуру расширения дескриптора сообщения (MQMDE).

Сегментация сообщений может быть прозрачной для приложений. Если это допустимо, то диспетчер очереди сегментирует длинное сообщение, если оно не помещается в очередь. Если приложение использует MQMD V1, диспетчер очереди автоматически добавит к данным сообщения структуру MQMDE. Как уже говорилось, структура MQMDE содержит те поля MQMD, в которых хранится информация о сегментации и группировании и которые существуют в MQMD V2, но отсутствуют в MQMD V1.

Изменения в области существующих заголовков

Кроме добавления к сообщению дополнительных заголовков, WebSphere MQ может изменять некоторые поля существующих заголовков сообщений в ходе их перемещения между приложением-отправителем и приложением-получателем.

1. Поле Format во всех предшествующих заголовках

Как уже упоминалось, в определенных обстоятельствах WebSphere MQ добавляет информацию к заголовку сообщения. После добавления дополнительного заголовка WebSphere MQ меняет и поле Format предыдущей структуры заголовка, чтобы указать тип нового заголовка. Например, когда WebSphere MQ добавляет заголовок передачи, за которым следует дескриптор сообщения, поле Format MQMD меняется на MQFMT_XMIT_Q_HEADER.

2. Поля, содержащие адресную информацию заголовка передачи

В процессе взаимодействия (в WebSphere MQ взаимодействие означает отправку сообщения от одного диспетчера очереди другому), когда диспетчер очереди передает сообщение, он может изменить информацию адреса (RemoteQName, RemoteQMgrName) заголовка передачи, передаваемого вместе с сообщением, если используется псевдоним диспетчера очереди.

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

3. ReplyToQ и ReplyToQMgr в дескрипторе сообщения

На самом деле изменения в этих двух полях вносятся приложениями до постановки сообщения в очередь. Если приложение помещает сообщение в очередь, указывая имя очереди отправителя (ReplyToQ) для ответных сообщений, но с пустым именем диспетчера очереди (ReplyToQMgr), локальный диспетчер очереди ответит на пустое имя диспетчера очереди проверкой определения удаленной очереди с тем же именем, что у очереди отправителя (псевдоним очереди отправителя):

  • если ничего не найдено, диспетчер очереди укажет в поле ReplyToQMgr дескриптора сообщения свое собственное имя, оставив ReplyToQ без изменений;
  • если определение существует, диспетчер очереди берет имя очереди и имя диспетчера очереди из определения и помещает их в поля reply-to дескриптора сообщения – т. е. заменит значения ReplyToQ и ReplyToQMgr.

4. Поля Context дескриптора сообщения

Контекст информационного сообщения хранится в поле контекста дескриптора сообщения. Существуют два типа контекста сообщений: контекст происхождения и контекст источника. В V7 к свойствам сообщения добавляется новый тип информации контекста: контекст пользователя. В таблице 5 перечислены поля контекста дескриптора сообщения.

Таблица 5. Поля контекста дескриптора сообщения
Тип контекстаПоля и их описание
Контекст происхождения

UserIdentifier: идентификатор пользователя приложения-источника сообщения.

AccountingToken: жетон учета.

ApplIdentityData: данные приложения, относящиеся к его происхождению.

Контекст источника

PutApplType: тип приложения, поместившего сообщение.

PutApplName: имя приложения, поместившего сообщение.

PutDate: дата размещения сообщения.

PutTime: время размещения сообщения.

ApplOriginData: данные приложения, касающиеся происхождения.

Контекст пользователя

Любые свойства, определенные приложениями как контекст пользователя.

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

  • информация контекста происхождения идентифицирует пользователя приложения, который первым поставил сообщение в очередь. Диспетчер очереди заполняет поля UserIdentifier и AccountingToken в зависимости от среды в которой работает приложение;
  • информация контекста происхождения описывает приложение, поставившее сообщение в очередь, в которой сообщение находится в настоящее время. Следующие поля обычно определяются диспетчером очереди: PutApplType, PutApplName, PutDate, PutTime;
  • контекст пользователя не устанавливается диспетчером очереди автоматически.

5. Поля Segmenting/Grouping дескриптора сообщения (V2)

Если это разрешено, диспетчер очереди делит слишком длинное для передачи сообщение на несколько сообщений меньшего размера. В то же время диспетчер очереди заполняет следующие поля сегментирования/группирования в дескрипторе сообщения V2: GROUPID, MsgSeqNumber, Offset, MsgFlags, OriginalLength. Как отмечалось выше, если это дескриптор сообщения V1, структура MQMDE добавляется диспетчером очереди.

Изменения, вызванные преобразованием данных

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

  • Данные в форматах, определенных WebSphere MQ (встроенные форматы). Форматы, перечисленные в таблице 1, представляют собой подмножество всех встроенных форматов. Данные сообщения в этих форматах могут конвертироваться автоматически диспетчером очереди из одной кодировки в другую при условии, что оба набора символов относятся к одному и тому же языку или группе аналогичных языков.
  • Данные в форматах, определяемых пользователем. Диспетчер очереди не может конвертировать данные в определяемых пользователем форматах. Для таких форматов приложения должны предоставлять уже преобразованные данные.

Таким образом, когда требуется преобразование данных, WebSphere MQ может автоматически конвертировать только данные сообщений встроенных форматов.

Заключение

В этой статье описан формат сообщений WebSphere MQ и те изменения, которые вносятся в формат сообщений в процессе управления очередью WebSphere MQ. В ней показано, что форматы сообщений в различных версиях WebSphere MQ сильно различаются по своей концепции, но сходны по составу: их структура "заголовок-тело" состоит из двух компонентов:

  • дескриптора сообщения и данных приложения (в версиях по V6);
  • свойств сообщения и данных приложения (V7).

Пока сообщение перемещается от одного приложения к другому, WebSphere MQ может изменить его тремя способами:

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

Ресурсы для скачивания


Похожие темы

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=780124
ArticleTitle=Изменения в форматах сообщений WebSphere MQ во время их передачи и в очередях
publish-date=12092011