В большинстве случаев используется так называемое "сквозное проигрывание" (playthrough), что дает возможность начать просмотр мультимедийного издания еще до того, как оно полностью загружено на сервер доставки. Например, сервер MediaCenter фирмы Sun позволяет начать воспроизведение аудио– или видеоданных уже через 5 секунд после начала загрузки. Сквозное проигрывание необходимо для приложений с быстрым и непрерывным обновлением содержания. Режим playthrough развивает метод оперативной загрузки, который заключается в способности сервера одновременно загружать один и воспроизводить другой документ.
На уровне операционной системы видеоматериалы представляются взаимосвязанной совокупностью файлов. Таким образом, для фильма в цифровой форме хранятся файлы одного или нескольких видеопотоков и файл для аудиопотока. В дополнение к файлам содержания существуют вспомогательные файлы, которые поддерживают распределение первичного файла по разным дискам (striping), синхронизацию между отображением видео и звучанием аудио, обеспечивают различные режимы воспроизведения.
Браузер, как уже отмечалось в предыдущей главе, представляет собой основной интерфейс пользователя для доступа и просмотра электронных изданий. Отделение браузера от уровня клиентских сервисов подчеркивает тот факт, что он может быть реализован с помощью любого стандартного Webбраузера, что дает множество преимуществ, например, независимость от платформы. Наращивание функциональных возможностей может происходить путем добавления сервисов в рамках задаваемой браузером общей организации просмотра и редактирования.
Браузер обеспечивает интерфейс с сервисом запросов и должен выполнять следующие функции:
✓ иерархический доступ к каталогам и файлам, аналогичный менеджеру файлов;
✓ интерфейсы для поиска;
✓ просмотр списка ответов, включающего миниатюры;
✓ навигацию по связям между документами.
Если данный клиент обладает правами доступа к хранилищу изданий, он может, выбрав одну из миниатюр, сформировать запрос к хранилищу изданий на получение необходимого документа. После определенного времени ожидания, связанного с выбором соответствующего информационного носителя в хранилище, сервер доставки начнет передачу клиенту запрошенной информации. Второй главный компонент браузера – средства просмотра для мультимедийных изданий. Для этого компонента существенно, чтобы медиа-документы были представлены в распространенных форматах либо легко преобразовывались в них. Браузер, однако, должен быть способен получать документы в их родных форматах и активизировать соответствующие приложения обработки, например, чтобы пользователь мог редактировать документы.
Работа с медиа-информацией предполагает несколько различных способов доступа к объектам хранения. Довольно часто медиа-документы бывают организованы так, что имеют простую иерархическую структуру. В этом случае доступ к ним может быть реализован через аппарат файловой системы сервера. Большие сложности вызывают запросы по атрибутам и запросы по ключевым словам, описывающим содержание. Оба эти параметра входят в метаданные, которыми документы дополняются при загрузке в хранилище. Для составных документов хороший способ состоит в том, чтобы не хранить их целиком, а включать в них навигационные связи с вложенными объектами. Например, если в системе хранится журнал, то должны быть связи между его страницами и отдельными объектами, которые содержат статьи, фото, рекламу.
Система хранения обязана обеспечивать несколько видов представления документов. Каждый документ должен иметь уменьшенную копию – миниатюру (thumbnail), которая компактно представляет его и возвращается пользователю в списке результатов запроса. Такое представление может быть заголовком или титульной страницей (для текстовых объектов), уменьшенным изображением (для графики), пятисекундным отрывком аудио– или видеоклипа.
Различные формы взаимодействия могут применяться и при доступе к самому изданию. В частности, представление "только для просмотра" дает пользователю возможность изучения содержания издания без права редактировать его. Примеры такого представления – формат Adobe Acrobat PDF, представление изображений в формате экрана (viewer), цифрового видео – в формате QuickTime и пр.
Сейчас для хранения информации преимущественно используются реляционные БД, обладающие мощным потенциалом, масштабируемостью, стандартным языком запросов по атрибутам SQL (Structured Query Language).
Однако они не проектировались для хранения исходных, полных документов, а тем более – мультимедийных. Для работы с полными документами более пригодными представляются объектно-ориентированные БД, в которые могут быть включены различные индексные структуры и методы доступа для объектов определенного типа. В них же проще создать иерархию типов, отражающую специфическую семантику. Сказанное представляется особенно важным для медиа-объектов различных типов и форматов. Возможно также создание комбинированных объектно-реляционных БД.
Для работы с медиа-документами больше подходят объектно-ориентированные БД (ООБД). В ООБД можно разработать индексные структуры и методы доступа специально для объектов определенного типа. Кроме атрибутов для объектов можно определить семантику, формализованную в операциях над ними, и создать иерархию типов, которая будет отражать все более и более специфическую семантику.
Например, система, построенная на ООБД, может иметь тип данных content-object с операцией play. На следующих уровнях иерархии могут быть подтипы для объектов со специфическим содержанием: audio-object, video-object, animation-object, и подтипы для специфических форматов: WAVaudio-object, MPEG2-video-object. Независимо можно ввести тип text-index, определив для него операции автоматической индексации и выполнения запросов. В ООБД в число атрибутов могут включаться указатели на индивидуальные объекты, что позволяет легко реализовать упомянутые выше отношения вхождения документов.
Резюмируя, можно сказать, что ООБД сами по себе имеют потенциал, чтобы стать законченным решением для системы на серверной стороне. Считается, что ООБД уступают реляционным системам в надежности, работоспособности и возможностях передачи данных, т. е. характеристиках, существенных для масштабируемости. Ожидается, однако, что Universal Server компании Informix, в котором объединены "объектно-реляционные" средства Illustra с масштабируемостью самой системы Informix, сможет преодолеть эти недостатки. Программное обеспечение DataBlade, входящее в Informix Universal Server, хорошо согласуется с предлагаемой архитектурой издательской системы. Помимо того, в DataBlade имеется возможность определять семантику новых типов данных непосредственно в БД.
Информационное хранилище издательства опирается на файловую систему сервера. Чтобы реализовать стратегию хранения данных, от файловой системы требуется поддержка управления томами и иерархического управления памятью (Hierarсhical Stirage Management – HSM). HSM, грубо говоря, – это примерно то же самое, что виртуальная память для физической ОП: она позволяет рассматривать различные уровни памяти (в частности, жесткие и оптические диски, магнитную ленту, если она используется) как одну большую файловую систему.
Если пользователь или приложение открывает файл, то он либо уже находится на жестком диске, либо HSM считывает его с автоматически текущего оптического диска из многотомной дисковой системы, либо извещает оператора о необходимости найти нужный том. Последний может находиться внутри специального блока для смены дисков ("чейнджера") или его следует найти внутри библиотеки на полке. В последнем случае для поиска тома с нужным номером и установки его в дисковод требуется помощь оператора, в результате чего полное время обращения многократно возрастает.
Схема HSM несомненно полезна, но, к сожалению, требует определенного развития. Например, когда пользователь пытается извлечь изображение высокого разрешения, а его размер может достигать десятков мегабайт, или же фрагмент цифрового видеофильма, то было бы полезно, чтобы система формировала специальное сообщение для пользователя, каково будет время ожидания. Последнее, кроме размера файла, зависит также от степени доступности объекта.
Выбор стратегии размещения данных зависит, конечно, от объема данных в медиа-изданиях, но, кроме того, – и от требований по скорости доступа к ним, т. е. оттого какие данные должны быть доступны немедленно, а какие могут стать доступными через секунды или минуты. Например, редактор книги, у которого процесс производства длится несколько недель или месяцев, может счесть для себя приемлемым подождать десять минут и даже больше, пока оператор найдет и поставит нужный диск. Редактор же ежедневной газеты вряд ли согласится ждать, пока будет получена цифровая фотография больше нескольких минут, т. е. его данные должны храниться в многотомной системе на оптических дисках с автоматическим поиском и установкой компакт-диска. Видеоклипы, распространяемые по каналам кабельного телевидения, должны быть доступны практически мгновенно.
