ГОСТ Р 56952-2016 Телевидение вещательное цифровое. Система TV-Anytime. Передача метаданных по двунаправленной сети. Основные параметры

ГОСТ Р 56952-2016

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ТЕЛЕВИДЕНИЕ ВЕЩАТЕЛЬНОЕ ЦИФРОВОЕ

Система TV-Anytime
Передача метаданных по двунаправленной сети

Основные параметры

Digital Video Broadcasting. System TV-Anytime. Delivery of metadata over a bi-directional network. Basic parameters

ОКС 33.170

ОКП 657400

Дата введения 2017-06-01

Предисловие

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием ордена Трудового Красного Знамени научно-исследовательским институтом радио, Самарский филиал "Самарское отделение научно-исследовательского института радио" (филиал ФГУП НИИР - СОНИИР)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 480 "Связь"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 июня 2016 г. N 545-ст

4 Настоящий стандарт разработан с учетом основных нормативных положений стандарта Европейского института по стандартизации в области телекоммуникаций (ETSI) ЕТСИ ТС 102 822-6-2 V1.3.1 (2006-01)* "Телевидение вещательное цифровое. Службы вещания и интерактивные: Поиск, выбор и законное использование контента на персональных системах хранения ("TV-Anytime"); Часть 6: Доставка метаданных через двунаправленную сеть; субчасть 2: этап 1 - Поиск службы" [ETSI TS 102 822-6-2 V1.3.1 (2006-01) "Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional network; Subpart 2: Phase 1 - Service discovery", NEQ]

________________

* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - .

5 ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомления и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

1 Область применения

Настоящий стандарт устанавливает основные параметры процессов передачи метаданных по двунаправленной сети с целью обнаружения служб метаданных и получения описания возможностей служб метаданных.

2 Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие стандарты:

ГОСТ Р 52210-2004 Телевидение вещательное цифровое. Термины и определения

ГОСТ Р 52591-2006 Система передачи данных пользователя в цифровом телевизионном формате. Основные параметры

ГОСТ Р 53528-2009 Телевидение вещательное цифровое. Требования к реализации протокола высокоскоростной передачи информации DSM-CC. Основные параметры

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

3 Термины, определения, сокращения и обозначения

3.1 В настоящем стандарте применены термины по ГОСТ Р 52210, ГОСТ Р 52591, ГОСТ Р 53528, а также следующие термины с соответствующими определениями:

3.1.1 жанр (genre): Наименование технической модели, находящейся в структуре бизнес-реестра UDDI и определенной спецификацией UDDI.

3.1.2 агрегатор (aggregator): В контексте настоящего стандарта - объект (организация), собирающий и агрегирующий информацию о контенте, службах и их поставщиках.

3.1.3 бизнес-реестр UDDI (UDDI Business Registry): Общедоступный реестр UDDI. Веб-службы, предлагаемые узлами бизнес-реестра UDDI, нормируются спецификацией UDDI.

3.1.4 вещатель (broadcaster): Объект, который агрегирует и распространяет контент аудио/видео.

3.1.5 двунаправленная сеть (bi-directional network): Сеть, поддерживающая доставку данных по двум направлениям при топологиях точка - точка, один ко многим, многие ко многим.

Примечание - Интернет является примером такой сети. Персональный цифровой рекордер (Personal Digital Recorder; PDR) может получить доступ к двунаправленной сети, используя обратный канал.

3.1.6 идентификатор ссылки контента (Content Reference Identifier; CRID): Идентификатор контента, который не зависит от его местоположения.

3.1.7 контент (content): Видео- и аудиофайлы, к которым пользователь хотел бы получить доступ и которые могут быть сохранены на PDR.

3.1.8 местоположение (локатор) (locator): Время и место, в котором элемент контента может быть приобретен.

3.1.9 метаданные (metadata): Данные о контенте, например, название, жанр и резюме телевизионной программы.

Примечание - В контексте TV-Anytime метаданные также включают данные профиля и истории потребителя.

3.1.10 метод GET (GET method): Название запроса протокола передачи гипертекста (HyperText Transfer Protocol; HTTP).

3.1.11 "мировая паутина" (веб, сеть Интернет) (World-Wide Web; WWW): Система сетевых интерфейсов для передачи данных по сети Интернет.

3.1.12 обратный канал (return path): Канал в двунаправленной системе от пользователя до сервера провайдера службы.

3.1.13 орган (authority): Организация, которая создает CRID.

3.1.14 орган разрешения (resolving authority): Организация, которая предоставляет разрешение местоположения.

3.1.15 приложение (application): Специфический набор функций, работающих на PDR.

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

3.1.16 провайдер контента (content provider): Объект, который действует в качестве агента и является главным эксплуататором контента.

3.1.17 провайдер службы (service provider): Агрегатор и поставщик контента, который может выполнять функции управления и шлюза.

3.1.18 программа (programme): Отредактированная, логически целостная (связанная) часть контента.

Примечание - Как правило, программа принимается PDR в целом.

3.1.19 простой протокол доступа к объектам (Simple Object Access Protocol; SOAP): Протокол обмена структурированными сообщениями в распределенной вычислительной среде.

3.1.20 процесс поиска контента по ссылке (content referencing): Процесс ассоциирования маркера с частью контента, который отображает его местоположение (локацию), в котором контент может быть приобретен.

3.1.21 разрешение местоположения (location resolution): Процесс установления адреса (местонахождения и времени) конкретного экземпляра контента по его CRID.

3.1.22 служба метаданных: Служба, которая предоставляет данные TV-Anytime, используя сервер на двунаправленной сети.

Примечание - Форматы данных и протоколы, используемые для доставки, определяются настоящим стандартом.

3.1.23 ссылка контента (content reference): Указатель конкретного элемента контента.

3.1.24 схема метаданных (metadata schema): Идентификатор, ассоциированный с набором схем расширяемого языка разметки (Extensible Markup Language; XML), который глобально идентифицирует эти схемы.

Примечание - Глобальное уникальное пространство имен гарантирует, что имена типов определяемых схем в этом пространстве имен не конфликтуют с такими же именами в других местах.

3.1.25 таксономия (taxonomy): Иерархическая классификация объектов.

3.1.26 телевидение вещательное цифровое (Digital Video Broadcasting; DVB): Совокупность стандартов, применяемых для цифрового телевизионного вещания в Европе.

3.1.27 транзакция (transaction): Передача коротких сообщений в диалоговом режиме.

3.1.28 техническая модель: Модель, находящаяся в структуре бизнес-реестра UDDI, определенной спецификацией UDDI.

3.1.29 универсальное описание, обнаружение и интеграция (Universal Description Discovery and Integration; UDDI): Спецификация структуры, независимой от платформы, функционирующей как каталог и предоставляющей возможность регистрировать и обнаруживать веб-службы в сети Интернет.

3.1.30 электронный гид по программам (Electronic Programme Guide; EPG): Средство представления доступного контента для потребителя, позволяющее выбирать требуемый контент.

3.2 В настоящем стандарте применены следующие сокращения:

API - программный интерфейс приложения (интерфейс прикладных программ, прикладной программный интерфейс) (Application Programming Interface);

ARIB - ассоциация радиопромышленности и бизнеса (Association of Radio Industries and Businesses);

ATSC - комитет передовых телевизионных систем (Advanced Television Systems Committee).

Примечание - Американская организация по стандартизации для создания технических стандартов для передовых телевизионных систем, в том числе цифрового телевидения высокой четкости;

CRID - идентификатор ссылки контента (Content Reference Identifier);

DNS - система доменных имен (Domain Name System);

DSM-CC - система команд и управления для средств цифровой записи (Digital Storage Media - Command and Control);

DVB - телевидение вещательное цифровое (Digital Video Broadcasting);

EPG - электронный гид по программам (Electronic Programme Guide);

ETSI - Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute);

HTTP - протокол передачи гипертекста (HyperText Transfer Protocol);

IP - Интернет протокол (Internet Protocol).

Примечание - Общее наименование сетевых протоколов, применяемых в сети Интернет;

Java - объектно-ориентированный язык программирования;

PDR - персональный цифровой рекордер (Personal Digital Recorder);

SOAP - простой протокол доступа к объектам (Simple Object Access Protocol);

TCP - протокол управления передачей (Transmission Control Protocol);

UDDI - универсальное описание, обнаружение и интеграция (Universal Description Discovery and Integration);

URL - универсальный указатель (определитель местоположения) ресурса (Uniform Resource Locator);

URN - унифицированное имя ресурса (Uniform Resource Names);

UUID - уникальный ключ идентификатора (Unique Universal Identifier);

W3C - консорциум веб (World Wide Web Consortium);

WSDL - язык описания веб-служб (Web Services Description Language);

WS-lnspection - система поиска веб-служб (Web Services Inspection language);

WWW - "мировая паутина" (веб, сеть Интернет) (World-Wide Web);

XML - расширяемый язык разметки (Extensible Markup Language);

XSD - описание схемы XML (XML Schema Definition).

3.3 В настоящем стандарте применены следующие обозначения:

<businessEntity> - элемент в структуре бизнес-реестра UDDI, содержит информацию, описывающую бизнес, связанный с конкретной веб-службой. Этот элемент может включать наименования на нескольких языках, контактную информацию и информацию о классификации;

<businessService> - элемент в структуре бизнес-реестра UDDI, описывает класс служб, относящихся к определенной отрасли бизнеса или служб. Каждая отрасль бизнеса принадлежит определенному элементу <businessEntity>;

<instanceParms> - дополнительный элемент типа строки, содержит настройки или параметры, связанные с правильным использованием элемента <tModellnstancelnfo>. Предложенный формат квалифицирован в пространстве имен документа XML так, чтобы настройки или параметры могли быть найдены в элементах документов XML и в атрибутах, определенных спецификацией UDDI в соответствии с [1];

<port>, <portType> - один из элементов корневого элемента описания WSDL, описывает веб-службу, называемую пунктом назначения (endpoint) или портом (port) прибытия послания. Элемент <port> определяет адрес интерфейса веб-службы. Элемент <port> представляется как набор служб, называемых операциями. Операции описываются вложенными элементами <operation> для каждой службы: отправка запроса - получение ответа или, наоборот, получение запроса - отправка ответа в соответствии с [2];

<ProgramlnformationTable> - элемент, содержащий таблицу записей информации о программе в соответствии с [3];

<ProgramLocationTable> - элемент, содержащий таблицу записей местоположения программы в соответствии с [3];

<ProgramReviewTable> - элемент, содержащий таблицу записей анализов программы в соответствии с [3];

<technologymodel> - один из элементов структуры бизнес-реестра UDDI;

<tModellnstancelnfo> - элемент структуры бизнес-реестра UDDI, определенный спецификацией UDDI;

get_Data - наименование службы, выполняющей операцию get_Data обнаружения данных в структуре бизнес-реестра UDDI и определенной спецификацией UDDI;

submit_Data - наименование службы, выполняющей операцию submit_Data предоставления данных в структуре бизнес-реестра UDDI;

authorityName - наименование технической модели, находящейся в структуре бизнес-реестра UDDI;

keyValue - атрибут бизнес-реестра UDDI, определенный спецификацией UDDI;

serviceURL - наименование технической модели, находящейся в структуре бизнес-реестра UDDI и определенной спецификацией UDDI;

subscriptionFilter - структура в составе бизнес-реестра UDDI и определенной спецификацией UDDI;

tabletype - наименование технической модели, находящейся в структуре бизнес-реестра UDDI и определенной спецификацией UDDI;

tModel - техническая модель;

UsageHistory - обозначение схемы описания информации об истории использования контента пользователем за длительный период времени;

UserPreferences - обозначение схемы описания информации о предпочтениях пользователя.

4 Общие вопросы обнаружения служб метаданных

4.1 Введение

В контексте настоящего стандарта клиентами системы вещания TV-Anytime могут быть PDR и любые устройства, соединенные с сетью Интернет. Эти устройства могут не иметь возможности отображения или сохранения контента, но могут использовать метаданные TV-Anytime (например, мобильные телефоны, выводящие на экран EPG).

Метаданные программы и информация поиска контента по ссылке могут быть получены при однонаправленной доставке (например, с помощью традиционного вещания или IP групповой передачи) или с помощью двунаправленной сети.

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

- обеспечивается доставка более полного набора метаданных;

- провайдеры TV-Anytime получают возможность поставлять метаданные клиентам, не имеющим доступа к системе вещания;

- провайдеры TV-Anytime получают возможность персонализировать метаданные, которые они предлагают клиентам с учетом их запросов;

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

Персонализированные метаданные, ориентированные на пользователя, могут быть доставлены из PDR в службу метаданных TV-Anytime, только если обратный канал доступен пользователю и авторизован пользователем. Предоставление таких данных пользователя позволяет службе метаданных обеспечить возможность создания служб с повышенной стоимостью услуг, описанных в [3] (6.5).

Настоящий стандарт определяет условия, обеспечивающие выполнение этих транзакций в интероперабельном режиме. Форум TV-Anytime полностью определил протоколы транспортных и сетевых уровней (TCP/IP), необходимые для обеспечения полной интероперабельности. Однонаправленные механизмы передачи определены органами, устанавливающими распространенные стандарты телерадиовещания (например, ARIB, ATSC, DVB).

Последовательность операций, выполняемых клиентом TV-Anytime для использования службы метаданных, показана на рисунке 1.

Рисунок 1 - Последовательность операций, выполняемых клиентом TV-Anytime для использования службы метаданных

Эти операции описаны в 4.1-4.3 настоящего стандарта.

Примечание - Служба метаданных должна предоставлять описание возможностей в соответствии с [4], однако поддержка обнаружения службы метаданных, определяемая настоящим стандартом, является опциональной. Получение описания возможностей обычно выполняется только после обнаружения или обновления службы метаданных.

4.2 Типы и функциональные возможности служб метаданных

Службы метаданных TV-Anytime базируются на принципах, которые показаны на рисунках 2 и 3. Службы метаданных используют принцип запрос-ответ. Топологией сети транзакции всегда является точка-точка (клиент-сервер). Транзакция всегда инициируется клиентом.

Схема выполнения запроса клиентом метаданных от службы метаданных представлена на рисунке 2.

Рисунок 2 - Схема выполнения запроса клиентом метаданных от службы метаданных

Любая сторона, способная к поставке данных, совместимых с TV-Anytime, может выполнять функции службы метаданных. Функции службы метаданных могут выполнять:

- создатели контента;

- провайдеры контента;

- провайдеры служб;

- производители бытового электронного оборудования;

- сторонние службы агрегации.

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

Типы возвращаемых метаданных могут быть любыми из числа не ориентированных на пользователя типами, указанными в [3] (т.е. фрагментами в соответствии с [5] (4.3.1.1)), с информацией поиска контента по ссылке.

Схема предоставления клиентом данных пользовательских предпочтений провайдеру службы метаданных представлена на рисунке 3.

Рисунок 3 - Схема предоставления клиентом данных пользовательских предпочтений провайдеру службы метаданных

Службу метаданных выполняет агрегатор данных пользователя. Любая из сторон, показанных на рисунке 2, или любая другая сторона, способная правильно применять информацию об использовании пользователем TV-Anytime при условии надежной защиты, может обеспечить службу метаданных.

Все данные, ориентированные на пользователя, могут быть определены любым из способов в соответствии с [3] (например, в соответствии со схемами описаний UserPreferences и UsageHistory). Настоящий стандарт допускает представление только анонимных схем описаний типа UsageHistory.

4.2.1 Извлечение метаданных

Извлечение метаданных происходит в тех случаях, когда клиент хочет получить от службы метаданных конкретные метаданные, которые им были обнаружены ранее с описанием возможности. Ниже показаны примеры случаев извлечения метаданных:

- клиент хочет получить отзывы о программе по известному ему идентификатору ссылки контента (Content Reference Identifier; CRID). Клиент отправляет запрос, указывая CRID и тип требуемых метаданных. Служба метаданных отвечает соответствующим элементом <ProgramReviewTable>;

- клиент хочет получить информацию о расписании определенного канала на следующую неделю. Клиент отправляет запрос, определяющий канал, диапазон дат и тип требуемых метаданных. Служба метаданных возвращает элементы <ProgramLocationTable> и <ProgramlnformationTable>, соответствующие программам на необходимом канале;

- клиент хочет найти службу метаданных, которая специализируется на информации о фильме. Клиент посылает запрос, указав тип фильма (например, тип жанра, имя актера и требуемый тип метаданных). Служба метаданных возвращает перечень фильмов, совпадающих с запросом, используя элементы <ProgramlnformationTable> и <ProgramReviewTable>.

4.2.2 Предоставление метаданных, ориентированных на пользователя

Предоставление метаданных, ориентированных на пользователя, может оказаться выгодным как для пользователей, так и для провайдеров служб метаданных. Эти выгоды описаны в [3] (5). Вопросы обеспечения конфиденциальности транзакций при предоставлении метаданных, ориентированных на пользователя, и обеспечения надежности провайдера службы метаданных настоящим стандартом не определяются.

4.3 Описания возможности службы метаданных

Для эффективного использования службы метаданных клиент должен иметь информацию о характере предложенной службы метаданных. Это обусловлено тем, что различные службы метаданных обеспечивают различные типы метаданных и должны запрашиваться с учетом этих различий. Некоторые службы метаданных могут предложить только информацию о поиске контента по ссылке. Другие могут обеспечить метаданные программы, но не дают информации о сегментации. Указанные различия могут проявляться в том, что один сервер может принять запросы на метаданные, основанные только на CRID, другой сервер может предложить ответы на более сложные запросы при сортировке возможностей. Кроме того, различные типы запросов эффективны только в том случае, если клиент при формировании запроса устанавливает существенные значения. Примером этого является запрос на данные планирования (<ProgramLocationTable>). Для запроса информации с целью планирования доставки конкретного контента службой доставки клиент должен знать службы доставки контента, для которых у службы метаданных есть данные.

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

4.4 Варианты обнаружения служб метаданных

Обнаружение служб метаданных является процессом, в котором клиент устанавливает URL, по которому может быть найдена служба метаданных TV-Anytime. Известные методы поиска служб метаданных представлены в 4.4.1, 4.4.2 настоящего стандарта, но нормируется способ, представленный в 4.4.3 настоящего стандарта.

4.4.1 Методы обнаружения при использовании URL

Методы обнаружения при прямом использовании URL могут быть реализованы следующими способами:

- клиент (PDR) может быть предварительно запрограммирован изготовителем с набором URL адресов, относящихся к одной или к нескольким службам метаданных;

- пользователь может вручную ввести URL службы метаданных, которой он интересуется, используя средства ввода текста;

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

4.4.2 Информация обнаружения при однонаправленной доставке

Спецификация системы согласно [6] определяет пути, а спецификация процесса поиска контента по ссылке согласно [7] определяет требования к используемому транспорту, при котором URL двунаправленных метаданных и/или служба поиска контента по ссылке могут быть обнаружены в информации TV-Anytime в однонаправленном потоке. Настоящий стандарт определяет возможности использования клиентом обнаруженной службы с помощью полученного URL в соответствии с 5.1 настоящего стандарта.

4.4.3 Обнаружение службы метаданных при использовании двунаправленной сети

Этот режим обнаружения службы метаданных предусматривает использование двунаправленной сети для получения доступа к справочнику служб метаданных TV-Anytime. Механизм основан на стандартах W3C для открытия веб-служб в соответствии с [1], [2], использование которых стандартизируется Форумом TV-Anytime, согласно правилам, представленным в разделе 5 настоящего стандарта. Поддержка этих методов обнаружения клиентами и серверами является опциональной.

5 Обнаружение служб метаданных

5.1 Операция get_Data получения метаданных органа по его CRID

Спецификация поиска контента по ссылке для обнаружения веб-служб предусматривает использование записей сервера системы доменных имен (Domain Name System; DNS) для получения разрешения местопложения, используя в качестве исходной точки CRID. Настоящий стандарт определяет аналогичный метод для обнаружения служб доставки метаданных выполнением запроса к серверу DNS. Форма строки запроса DNS:

_gmet._tcp.<name_extension segment from CRID authority>.< DNS segment from CRID authority >,

где gmet - сокращение от "get metadata" (получить метаданные).

Результатом запроса DNS является URL, включающий имя хоста (<hostname>) и порта (<port>), которые определяют местонахождение сервера метаданных. Служба get_Data может возвращать не менее одного типа таблицы метаданных, предоставляемой этим URL (//<hostname>:<port>/).

5.2 Обнаружение служб метаданных средствами UDDI

5.2.1 Введение

В соответствии со спецификацией UDDI согласно [1] клиенты TV-Anytime, имеющие возможность работать в сети Интернет, могут обнаруживать службы метаданных TV-Anytime при отсутствии предварительных данных о службе метаданных. Реализация такого поиска обеспечивается в том случае, если провайдеры служб метаданных публикуют детализированную информацию о своих службах в бизнес-реестре UDDI. В этом случае любой клиент TV-Anytime сможет использовать узел бизнес-реестра_UDDI для определения местоположения служб метаданных TV-Anytime.

Для обнаружения веб-служб при использовании бизнес-реестра UDDI клиенты TV-Anytime должны руководствоваться [1].

Описания и категоризация служб TV-Anytime выполнена Форумом TV-Anytime в соответствии с зарегистрированными техническими моделями UDDI, описанными в 5.2.3, 5.2.4 настоящего стандарта. Категоризация служб бизнеса в соответствии с [2].

5.2.2 Общие представления о спецификации UDDI

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

UDDI базируется на элементах четырех типов: <businessEntity>, <businessService>, <bindingTemplate> и <technologymodel>.

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

Элемент <businessService> описывает класс служб, относящихся к определенной отрасли бизнеса или отрасли служб. Каждая отрасль бизнеса (служб) принадлежит определенному элементу <businessEntity>.

Элемент <bindingTemplate> определяет конкретную спецификацию службы. Каждый элемент <bindingTemplate> принадлежит определенному элементу <businessService>.

Элемент <technologymodel> (техническая модель, tModel) определяет веб-службу и содержит ее абстрактное описание.

5.2.3 Технические модели веб-служб TV-Anytime

Технические модели, находящиеся в структуре бизнес-реестра UDDI, применяются в тех случаях, когда бизнес публикует детализированную информацию элемента <bindingTemplate>, вложенного в элемент <businessService>, и являются указателями веб-служб. Элемент <bindingTemplate> содержит информацию о способе получения веб-службы. Таким указателем может быть URL-адрес веб-службы, описание WSDL. Каждый способ получения службы описывается одним вложенным элементом <bindingTemplate> с атрибутом bindingKey, определяющим уникальный ключ UUID указателя.

Элемент <bindingTemplate> содержит ссылку на соответствующий элемент <tModel>, который является технической моделью службы, содержащей детализированное описание службы. Технические модели существуют вне родительско-дочерних отношений между элементами <businessEntity>, <businessService> и <bindingTemplate>. Клиенты TV-Anytime, выпускающие запросы реестру UDDI, могут использовать две технические модели для поиска веб-служб, являющихся службами метаданных TV-Anytime. Они представлены в 5.2.3.1, 5.2.3.2 настоящего стандарта.

Каждая отдельная спецификация транспорта, протокола или пространства имен представляет собой техническую модель. Примеры технических моделей, которые разрешают совместимость веб-служб, включают в себя те, которые основаны на языке WSDL, описании схемы XML (XML Schema Definition; XSD) и других документах, определяющих интерфейс, который веб-служба может выбрать для выполнения. Для описания веб-службы, которая соответствует определенному набору спецификаций, транспорта и протоколов, ссылки на совокупность элементов <tModel>, которые представляют эти понятия, находятся в элементе <bindingTemplate>.

Открывающий тег элемента <tModel> может содержать необязательный атрибут tModelKey, содержащий уникальный ключ UUID. Отсутствие атрибута tModelKey означает, что ключ UUID будет сформирован реестром UDDI.

Технические документы и сопроводительная документация, необходимые для разработчика, использующего веб-службы, не хранятся в самом реестре UDDI. Элемент <tModel> UDDI содержит адреса, по которым документы могут быть найдены. Элемент <tModel> хранит также метаданные о технических документах.

5.2.3.1 Техническая модель порта get_Data TV-Anytime

Техническая модель get_Data представляет порт get_Data. Элемент <port> (<portType>) описывает порт получения данных. Элемент <port> определяет адрес интерфейса веб-службы.

Параметры технической модели порта get_Data представлены в таблице 1.

Таблица 1 - Параметры технической модели порта get_Data

Техническая модель порта get_Data представлена на рисунке 4.

Рисунок 4 - Техническая модель порта get_Data

5.2.3.2 Техническая модель порта submit_Data TV-Anytime

Техническая модель submit_Data представляет порт submit_Data. Элемент <port> (<portType>) описывает пункт назначения или порт предоставления данных. Параметры технической модели порта submit_Data представлены в таблице 2.

Таблица 2 - Параметры технической модели порта submit_Data

Техническая модель порта submit_data представлена на рисунке 5.

Рисунок 5 - Техническая модель порта submit_data

5.2.4 Категоризация технических моделей TV-Anytime

Технические модели позволяют провайдеру служб метаданных категоризировать (классифицировать) свои службы. Провайдер служб метаданных присваивает категории службам метаданных на момент публикации (см. 5.2.3 настоящего стандарта). Это позволяет клиентам повысить точность поиска в UDDI службы метаданных. Категоризируя службу метаданных с максимально возможными подробностями и, следовательно, с максимально возможной точностью, провайдер служб метаданных максимизирует возможность обнаружения службы метаданных при использовании средств UDDI.

Таксономия выполняется опционально. Для многих служб использование некоторых из типов таксономии будет нецелесообразным. Например, служба метаданных, которая не предоставляет информацию о расписании, не сможет использовать таксономию TV-Anytimeorg:serviceURL для перечисления служб, для которых обеспечиваются метаданные.

Провайдеры служб метаданных должны классифицировать свои службы таким образом, чтобы способствовать их обнаружению, не создавая у клиента ложных ожиданий. Это относится к описанию возможностей, которые предоставляют окончательное описание функций, поддерживаемых конкретной операцией. Таким образом, найдя службу метаданных, клиент должен всегда получать описание функциональных возможностей этой службы. В тех случаях, когда описания возможностей включены внутри элемента <bindingTemplate> этой операции, это не предполагает каких-либо дополнительных действий.

Технические модели, представленные в 5.2.4.1-5.2.4.5 настоящего стандарта, являются категоризированными техническими моделями.

5.2.4.1 Система категоризации authorityName TV-Anytime

Техническая модель authorityName используется для представления органов, разрешающих CRID, для которых служба метаданных предоставляет информацию TV-Anytime. Оценка доступности для органа информации поиска контента по ссылке или метаданных выполняется применением технической модели tabletype. Классификация технической модели tabletype представлена в 5.2.4.2 настоящего стандарта. Параметры технической модели authorityName представлены в таблице 3.

Таблица 3 - Параметры технической модели authorityName

Техническая модель authorityName представлена на рисунке 6.

Рисунок 6 - Техническая модель authorityName

5.2.4.2 Система категоризации технической модели tableType TV-Anytime

Техническая модель tableType используется для представления типов таблицы метаданных, которые способны предоставить службу метаданных. Параметры технической модели tableType представлены в таблице 4.

Таблица 4 - Параметры технической модели tableType

Техническая модель tableType представлена на рисунке 7.

Рисунок 7 - Техническая модель tableType

5.2.4.3 Система категоризации технической модели serviceURL TV-Anytime

Техническая модель serviceURL используется для представления служб доставки контента (например, каналов), для которых служба метаданных TV-Anytime предоставляет информацию. Параметры технической модели serviceURL, представляющей службы доставки контента, приведены в таблице 5.

Таблица 5 - Параметры технической модели serviceURL

Техническая модель serviceURL представлена на рисунке 8.

Рисунок 8 - Техническая модель serviceURL

5.2.4.4 Система категоризации технической модели genre (жанр) TV-Anytime

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

Параметры технической модели genre (жанр), представляющей классификацию специальной информации, представлены в таблице 6.

Таблица 6 - Параметры технической модели genre (жанр)

Техническая модель genre (жанр) представлена на рисунке 9.

Рисунок 9 - Техническая модель genre (жанр)

5.2.4.5 Другие категоризации

Бизнес-реестр UDDI обеспечивает и другие категоризации, которые могут быть полезными в описании служб метаданных TV-Anytime. Эти категоризации должны соответствовать присвоенному атрибуту keyValue, который категоризирует область (или области), в которой доступны программы, описанные этой службой метаданных. Для некоторых механизмов распространения контента (например, через сеть Интернет) такая классификация не предназначена.

Категории могут группироваться в соответствии с [1] (приложение F, F.2).

5.2.5 Публикация службы метаданных TV-Anytime

Провайдер служб метаданных TV-Anytime присваивает категории и публикует подробности о своей службе в любом узле бизнес-реестра UDDI. Способ опубликования определяет оператор этого узла (см. [1]).

Пример процесса публикации приведен в приложении A настоящего стандарта.

Элемент <businessService> создается для каждой службы метаданных, которую бизнес регистрирует. Элемент <businessService> содержит элементы <bindingTemplate> для каждой из привязок, предлагаемых этой службой метаданных (например, get_Data или submit_Data).

При публикации операции get_Data рекомендуется использовать элемент <instanceParms>, находящийся внутри элемента <tModellnstancelnfo> и содержащий описание возможностей. Это позволяет клиенту приобрести описание возможностей службы метаданных и определить его полезность, не выдавая запрос describe_X. В связи с тем, что размер элемента <instanceParms> ограничен, размер описания возможности следует ограничивать и, например, выполнять в виде схемы.

5.3 Обнаружение служб метаданных средствами WS-lnspection

Веб-сервер TV-Anytime может объявить о наличии своих служб метаданных средствами системы поиска веб-служб WS-lnspection, представленной в [2]. Это позволяет клиентам обнаруживать описания служб (определений в реализации WSDL) для веб-служб, доступных на этом веб-сайте.

Рекомендуется для каждого элемента описания использовать ссылку расширяемости WSDL следующим образом:

- атрибут endpointPresent должен быть установлен на "истинно" (клиент ищет существующие службы, а не абстрактные определения служб);

- элемент implementedBinding должен быть включен для каждого элемента <portType>, предлагаемого службой TV-Anytime. Таким способом клиент может установить, предлагает ли соответствующая служба фактические порты TV-Anytime и, если предлагает, то какие <portType> присутствуют. Это позволяет не выполнять загрузку и синтаксический анализ описания реализации WSDL.

Примеры описания файла WS-lnspection и описания реализации WSDL приведены в приложении Б настоящего стандарта.

5.3.1 Обнаружение файла WS-lnspection

Для облегчения обнаружения файла (документа) WS-lnspection в соответствии с [2] (6.1) документ по имени inspection.wsil может быть помещен в "общую точку входа" веб-сайта. Термин "общая точка входа" не имеет четкого определения, поэтому TV-Anytime устанавливает следующие правила, облегчающие интегрированным клиентам получение документа WS-lnspection:

- служба метаданных, предоставленная веб-сервером с машинным именем <hostname>, который хочет создать файл WS-lnspection, должна поместить документ в корень его веб-сервера. Таким образом, запрос HTTP при использовании метода GET к //hostname>/inspection.wsil запросит файл, если он существует;

- орган разрешения с именем <domain_name>:<extension_name>, который хочет предоставить файл WS-lnspection, должен поместить документ по адресу //domain_name>/<extension_name>/inspection.wsil. Однако если документ WS-lnspection указывает URL другого сервера, то веб-сервер, имеющий то же самое доменное имя, как и у органа разрешения, может не предоставить службу метаданных.

Приложение А
(рекомендуемое)

Примеры использования UDDI

А.1 Пример процесса публикации операции get_Data

Провайдер служб метаданных регистрирует новую операцию, используя API публикации UDDI save_binding (при условии, что соответствующие родительские структуры (элементы) <businessEntity> и <businessService> были уже зарегистрированы).

Процесс публикации операции get_Data представлен на рисунке А.1.

Рисунок А.1 - Процесс публикации операции get_Data

Структура (элемент) <bindingTemplate> содержит ссылку на tModel для выполнения операции get_Data.

Информация категоризации позволяет клиенту установить следующее:

- метаданные предоставляются на CRID от органа разрешения по имени "barry-norman.com";

- большинство программ, описанных с помощью службы метаданных, относятся к genre (жанр) "кино";

- служба метаданных может возвратить элементы <ContentReferencingTable>, <ProgramlnformationTable> и <ProgramReviewTable>.

А.2 Пример поиска службы метаданных TV-Anytime

В данном примере PDR создает улучшенный EPG. PDR должен отобразить информацию об известном наборе URL служб контента. Для создания EPG служба метаданных должна начать операцию get_Data, которая может доставить <ProgramLocationTable> и <ProgramlnformationTable>. Процесс поиска привязок, необходимых для создания EPG, представлен на рисунке А.2.

Рисунок А.2 - Процесс поиска привязок, необходимых для создания EPG

Структура данных, возвращаемых к PDR, будет содержать список элементов <bindingTemplate>, которые удовлетворяют запросу. Список может быть уточнен пользователем (на основе предпочтений: заводской марки, рекомендаций, используемых языков и т.д.) или PDR в автоматическом режиме (на основе описания функциональных возможностей и других таксономий, представленных в каждом элементе <bindingTemplate>).

Клиенты TV-Anytime могут зарегистрировать на узле свою заинтересованность в определенном виде служб метаданных с использованием API подписки в соответствии с [1] (5.5). В этом случае элемент <find_binding> (рисунок А.2) может быть использован в структуре subscriptionFilter сообщения подписки согласно [1], определяя, таким образом, типы служб, о которых PDR хочет получать уведомления.

Приложение Б
(рекомендуемое)

Примеры описания файла WS-Inspection и описания реализации WSDL

Пример описания файла WS-lnspection, содержащего ссылку на службу метаданных TV-Anytime, предоставляющую порты get_Data и submit_Data, представлен на рисунке Б.1.

Рисунок Б.1 - Пример описания файла WS-lnspection

Местоположение атрибута в приведенном выше описании позволяет клиенту загрузить описание реализации WSDL.

Описание реализации WSDL представлено на рисунке Б.2.

Рисунок Б.2 - Описание реализации WSDL

Определение реализации WSDL по ссылке позволяет клиенту устанавливать URL двух портов TV-Anytime. Техническая версия порта обозначается с помощью пространства имен, полностью определенного связывающим именем.

Библиография

Электронный текст документа
и сверен по:

, 2016