Телевидение. CAS и middleware

В этой статье я расскажу как установить бесплатную IPTV/OTT Middleware с открытым исходным кодом от компании Инфомир, зачем она нужна и какие возможности предоставляет пользователям и администраторам.

Статья будет полезна небольшим операторам и даже пользователям. Можно «поднять» у себя дома Stalker и использовать его для просмотра* бесплатных IPTV и интернет каналов на приставке. Самому организовать EPG и запись телеканалов.

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

▍Что такое Middleware?

В Википедии есть хорошее и краткое определение:

Middleware — промежуточное программное обеспечение для управления комплексом IPTV.

Это основной компонент IPTV решения, так как он, в конечном итоге, и определяет набор услуг, доступный абоненту, пользовательский интерфейс, логику переходов и алгоритм управления. На Middleware возлагается роль координатора в процессе взаимодействия практически всех компонентов комплекса.

Я полностью согласен с этим определением. Построить IPTV/OTT сервис без Middleware невозможно. Разработчиков на рынке много, у каждой Middleware свои особенности: список поддерживаемых устройств, список поддерживаемых CAS-систем, пользовательский интерфейс, список поддерживаемых видеосерверов, разные API для биллинга, стоимость и поддержка.

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

У нас на сайте есть хорошая статья про Middleware.

▍Почему Stalker?

В первую очередь Stalker интересен тем, что он бесплатный. Правда бесплатный, без пробных периодов и ограничения функционала. Исходный код можно скачать на GitHub.

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

Не каждый оператор готов вкладывать деньги в покупку Middleware, потому что сразу не понятно зачем она вообще нужна. Вот спутниковые приемники принимают телеканалы, CAS-система защищает контент, приставки показывают видео, биллинг деньги считает. А что делает Middleware? Список каналов и погоду показывает?

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

▍Установка

У Инфомира есть небольшая документация и образ VirtualBox

Образ VirtualBox

Запуск образа VirtualBox дело не сложное, но опишу кратко как это делается:

  1. Установить VirtualBox. Сайт: www.virtualbox.org
  2. Скачать и распаковать zip-архив с образом. Актуальная ссылка на странице: http://wiki.infomir.eu/doku.php/stalker:start
  3. Запускаем VirtualBox, меню «Машина», нажимаем «Добавить» (Ctrl+A) и выбираем файл VmVirtualBox_Ubuntu14.04.4.x64_MW.Stalker.Demo
  4. Запускаем виртуальную машину, авторизуемся (test/test), смотрим IP-адрес машины и открываем в браузере административный интерфейс.
  5. В админ интерфейсе «Хранилища» изменить IP-адрес хранилища на IP интерфейса виртуальной машины

▍Docker контейнер

Давайте установим Stalker в Docker контейнер. Это быстро и удобно. Если вы не знаете что такое Docker и никогда с ним не работали, почитайте статью habrahabr.ru/post/310460. Она даст полное представление о работе контейнеров. Но сейчас эти знания не понадобятся.

Разработчики настоятельно рекомендуют использовать Ubuntu Server LTS, при этом 16.04 не поддерживают пока, а 12.04 уже мало кем используется. Docker позволит запустить Stalker на вашем любимом дистрибутиве.

Для продолжения, нам потребуется сам Docker и Docker-compose. Пример установки для большинства дистрибутивов:

Создадим рабочую папку, в которой будет у нас жить Stalker и скачаем docker-compose файл:
Запускаем Stalker:
Запускаем утилиту, которая скачает последнюю версию Stalker и заполнит нам базу данных:
Ждем, пока скрипт выполнится. У меня это занимает около 4-х минут (что ж там за это время происходит?). Готово, админ панель Сталкера доступна по адресу: http://ip/stalker_portal/
Заходим по стандартному логину/паролю: admin/1.

Еще раз все вместе, чтобы показать как все просто, буквально 3 команды:

Ролик «Установка Stalker Middleware за 2 минуты»:

▍Установка без виртуализации и контейнеров

Можно установить и по старинке, просто установить необходимые пакеты и отредактировать несколько файлов вручную. Этот способ самый долгий и трудоемкий, но отлично подойдет, если вы собираетесь запустить сервер в Production.

Если у вас уже есть сервер с nginx+apache2+php5, то вам повезло, возможно Stalker запустится и без установки дополнительных пакетов. Но, насколько я знаю, nginx+apache2 уже редко используются вместе, nginx+php-fpm куда удобнее.

Инструкция от разработчика: wiki.infomir.eu/doku.php/stalker:install_and_configure

▍Настройка

После установки, первым делом хочется открыть портал на ТВ-приставке, чтобы убедится, что установка прошла успешно и оценить интерфейс со стороны пользователя. Но пока рано, там будет совсем скучно, давайте пока добавим немного контента.

По умолчанию, админ интерфейс на английском языке. Переключиться на русский вы можете внизу страницы:

▍Добавление телеканала

Разворачиваем меню «IPTV Каналы», открываем страницу «Каналы». В списке уже будет предустановленный телеканал «Test channel», удалите его и давайте добавим свой канал (кнопка «Add a channel»).

Заполняем основные поля: «Номер канала», «Название канала», загрузим логотип, поставим галочку «Базовый канал».

Нажимаем на кнопку «Добавить ссылку», появляется всплывающее окно с формой добавления URL канала и дополнительными опциями. Как мы видим из подсказки, в эту строку нужно ввести «solution+URL». Solution — это подсказка для плеера приставки, какую библиотеку использовать для воспроизведения. В большинстве случаем достаточно указать «auto» (например, «auto udp://239.255.1.1:5500»). Для HLS рекомендуемый Инфомиром solution — ffmpeg.

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

В результате должно получится:


Пропустим пока настройку программы передач (EPG) и ТВ-архива (DVR). Сохраняем.

▍Добавление фильма

Меню «Видеоклуб» → «Список фильмов».

Процесс добавления фильмов не сильно отличается, но есть приятный бонус: автозаполнение. Достаточно написать название фильма/сериала на оригинальном языке и Stalker сможет получить метаданные из базы данных TMDB или Кинопоиск.

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

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

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

▍Программа передач (EPG)

Без программы передач строить сервис нельзя, людям уже давно не интересно просто щелкать каналы. EPG нужна не только для того, чтобы пользователь мог посмотреть как называется текущая передача и что будет сегодня вечером, а еще для организации видеоархива! Позволяя пользователям смотреть передачи, которые уже прошли (т.н. Catch UP).

Stalker умеет импортировать EPG из формата XMLTV.

XMLTV — популярный формат описания программы передач основанный на XML, поддерживается всеми поставщиками EPG. Содержит подробное описание: название, время начала, время окончания, жанр, описание, картинку, список актеров, возрастной рейтинг и прочую информацию.

Для продолжения настройки, нам надо добыть поставщика EPG.

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

Открываем меню «IPTV каналы» → «EPG». Кнопка «Добавить EPG».

Нам потребуется вставить ссылку на веб-сервер, где лежит xml файл. Из собственного опыта добавлю, что поставщики чаще всего выкладывают на закрытый паролем ftp-сервер, и в добавок еще архивируют, поэтому в Stalker вставляем ссылку на localhost, а в crontab добавляем скрипт, который будет скачивать и распаковывать XMLTV в нужную папку.

После добавления ссылки, нажмите «обновить». Если все сделали правильно, получится:

Теперь переходим в настройки телеканала. Меню «IPTV каналы» → «Каналы», нажимаем редактировать наш телеканал. Нас интересует раздел «EPG», указываем ID нашего телеканала и, при необходимости, корректируем время под наш часовой пояс.

Как узнать XMLTV ID телеканала

Открываем текстовым редактором XMLTV файл и смотрим. В данном примере: «Первый канал» — 1, «Россия 1» — 2, «ТВЦ» — 3.

Для каждого телеканала придется вручную указывать ID. Способа автоматизировать это я пока не знаю.

▍Внешний вид

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

Чтобы активировать его, переходим в меню «Настройки» → «Внешний вид». На этой странице можем ознакомится со всеми доступными темами.

Нажимаем «Применить» под темой «Stalker 5x — graphite».

▍Запускаем портал на приставке

Надеюсь, у вас есть под рукой приставка MAG? С помощью пульта ДУ или USB-клавиатуры, переходим в настройки приставки → «Серверы» → «Порталы» и указываем URL сервера, куда вы установили Stalker.

URL для клиентов:

Сохраняем, перезагружаем приставку и попадаем в нашу Middleware. Никакие логины и пароли не потребуются, по умолчанию авторизация не требуется.

▍Что дальше?

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


Middleware



редактировать страницу

Вы можете запускать код до и после вашего Slim-приложения, чтобы управлять объектами Request and Response по своему усмотрению. Это называется middleware (промежуточным программным обеспечением). Зачем вам это делать? Возможно, вы хотите защитить свое приложение от подделки межсайтовых запросов. Возможно, вы хотите аутентифицировать запросы перед запуском приложения. Middleware идеально подходит для этих сценариев.

Что такое middleware?

Технически говоря, middleware является вызываемым которое принимает три аргумента:

  1. — Объект запроса PSR7
  2. — Объект ответа PSR7
  3. — Следующее middleware (промежуточное программное обеспечение), подлежащее вызову

Он может делать все, что подходит этим объектам. Единственное жесткое требование заключается в том, что промежуточное ПО ДОЛЖНО возвращать экземпляр . Каждое промежуточное ПО СЛЕДУЕТ вызывать следующее промежуточное программное обеспечение и передавать его объектам Request and Response в качестве аргументов.

Как работает промежуточное программное обеспечение (middleware)?

Различные структуры используют промежуточное ПО по-разному. Slim добавляет промежуточное ПО как концентрические слои, окружающие ваше основное приложение. Каждый новый слой промежуточного программного обеспечения окружает любые существующие уровни промежуточного программного обеспечения. Концентрическая структура расширяется наружу, когда добавляются дополнительные слои промежуточного слоя.

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

Когда вы запускаете приложение Slim, объекты Request and Response пересекают структуру промежуточного программного обеспечения извне. Сначала они вводят самое внешнее промежуточное ПО, а затем следующее внешнее самое промежуточное ПО (и т. Д.), пока они в конечном итоге не прибудут к самому Slim-приложению. После того, как приложение Slim отправляет соответствующий маршрут, результирующий объект Response выходит из приложения Slim и пересекает структуру промежуточного программного обеспечения изнутри. В конечном итоге конечный объект Response выходит из самого промежуточного ПО, сериализуется в исходный HTTP-ответ и возвращается клиенту HTTP. Вот диаграмма, иллюстрирующая поток процесса промежуточного программного обеспечения:

Как написать промежуточное программное обеспечение?

Middleware является вызываемым, которое принимает три аргумента: объект Request, объект Response и следующее middleware. Каждое middleware ДОЛЖНО возвращать экземпляр .

Пример замыкание middleware.

Пример middleware замыкания.

Пример вызываемого класса middleware

Это пример middleware вызываемого класс о который реализует магический метод .

Чтобы использовать этот класс в качестве middleware, вы можете использовать цепочку функций после , , или , что в приведенном ниже коде, любой из них, может представлять объект $ subject.

Как добавить middleware?

Вы можете добавить промежуточное программное обеспечение в Slim-приложение, на индивидуальный маршрут Slim или в группу маршрутов. Все сценарии принимают одно и то же middleware и реализуют один и тот же интерфейс middleware.

Application middleware

Для каждого входящего HTTP-запроса вызывается middleware.

Добавьте промежуточное программное обеспечение приложения с помощью метода экземпляра Slim. В этом примере добавляется пример Closure middleware:

Это вывело бы это тело ответа HTTP:

Route middleware

Route middleware вызывается только в том случае, если его маршрут соответствует текущему методу HTTP-запроса и URI. Route middleware указывается сразу же после вызова любого из методов маршрутизации Slim-приложения (например или ). Каждый метод маршрутизации возвращает экземпляр , и этот класс предоставляет тот же интерфейс middleware что и экземпляр приложения Slim.

Добавьте middleware в маршрут с помощью метода экземпляра Route. В этом примере добавляется пример Closure middleware:

Это вывело бы это тело ответа HTTP:

Групповое Middleware

В дополнение к общему приложению и стандартным маршрутам, способным принимать middleware, функция определения нескольких маршрутов, также позволяет индивидуальные маршруты внутри. Маршрутное групповое middleware вызывается только в том случае, если его маршрут соответствует одному из определенных методов HTTP-запроса и URI из группы. Чтобы добавить промежуточное программное обеспечение в обратном вызове и промежуточное ПО всей группы, можно установить путем цепочки после метода.

Пример приложения, используя callback middleware в группе обработчиков URL-адресов

При вызове метода будет выводиться строка, подобная приведенной ниже

посещение будет выводить строку, подобную приведенной ниже

но посещение (domain-root), должно было бы генерировать следующий результат, поскольку не было назначено middleware

Передача переменных из middleware

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

Установка переменной в middleware:

Получение переменной в обратном вызове маршрута:

К средствам middleware (промежуточного, или межплатформного, программного обеспечения) сейчас проявляется большой интерес. Рынок этих средств рос в последнее время экспоненциально, и, по различным оценкам, в ближайшие годы такая тенденция сохранится. В данной статье делается попытка ответить на вопрос "Что такое middleware?", предлагается классификация средств middleware и определение области их применения.

Термин "промежуточное программное обеспечение" (ППО) является довольно устоявшимся, но в то же время его нередко используют для обозначения разных понятий. С самой общей точки зрения ППО является типом программного обеспечения, предоставляющим API между приложением и ресурсами, необходимыми ему для нормального функционирования. Исходя из этого, промежуточным может быть названо любое ПО, позволяющее упростить процесс взаимодействия приложений друг с другом или с ресурсами. Возникает логичный вопрос: а является ли операционная система ППО? В общепринятом смысле — нет, поэтому представляется целесообразным более узкое определение: промежуточным называется программное обеспечение, предоставляющее интерфейсы между приложением и необходимыми ему программными ресурсами (которые также могут являться приложениями).

ППО выполняет две основные функции. Первая — облегчение доступа приложений к ресурсам. Такая функциональность важна прежде всего для разработчиков информационных систем, поскольку позволяет им большую часть времени уделять созданию бизнес-логики, а не разработке механизмов доступа к ресурсам. Вторая функция ППО — ускорение процессов взаимодействия. Действительно, ПО, специально спроектированное для обеспечения взаимодействия, как правило, обладает лучшей производительностью по сравнению с неспециализированным решением, созданным разработчиком.

Классификация middleware

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

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

Первую группу можно разбить на две основные подгруппы: ППО для работы с базами данных и мониторы транзакций.

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

К этому типу ППО относятся средства реализации спецификаций ODBC (Object Database Connectivity), OLE DB, JDBC (Java Object Database Connectivity). Средства ODBC, в частности, дают разработчику некоторый "базовый" набор функций, поддерживаемых различными серверами реляционных баз данных. Программист, использующий этот API, не заботится о том, к какому серверу он обращается, — эти функции переложены на ODBC, что позволяет уделять больше внимания основной логике создаваемого приложения.

Мониторы транзакций. Если ППО доступа к БД решает именно проблему взаимодействия с БД, то мониторы обработки транзакций (в англоязычной спец. литературе — TP-мониторы) оптимизируют работу системы. TP-мониторы располагаются между клиентом и сервером БД и являются вторым уровнем трехзвенной архитектуры. Клиентское приложение инициирует транзакцию в мониторе. Тот, в свою очередь, запускает при необходимости транзакцию базы данных, получает ее результат и перенаправляет его обратно клиентскому приложению.

Основное преимущество транзакций в том, что они позволяют "оформить" часть приложения как транзакцию. Транзакция отличается от простой последовательности команд своей целостностью: если во время ее выполнения возникает та или иная критическая ситуация (например, отказ одного из ресурсов), ТР-монитор может автоматически вернуть систему в исходное состояние (осуществить откат транзакции). Поддержка транзакционности присуща многим системам, а не только ТР-мониторам. Что же заставляет выделять их в отдельную группу ППО? Такой отличительной чертой является способность оптимизации доступа к ресурсам. В частности, поскольку клиенты в трехзвенной архитектуре напрямую к СУБД не подключаются, монитор транзакций может осуществлять мультиплексирование (накопление или смешивание) запросов, направляя целую их пачку в рамках одного подключения к БД. Кроме того, клиентское приложение может инициировать транзакцию, содержащую запросы на изменение информации в нескольких базах данных, не обязательно однородных. Монитор транзакций и в этом случае выполняет функции ППО, предоставляя приложению виртуальный доступ к различным БД.

Наиболее популярными мониторами транзакций являются Microsoft Transaction Server, Tuxedo фирмы BEA Systems, CICS производства IBM, Encina компании Transarc и др.

ППО второго типа

ППО, отнесенное по нашей классификации ко второй группе (middleware, обеспечивающее взаимодействие между активными приложениями), может быть условно разбито на три основных типа: ППО удаленного вызова процедур (RPC, Remots Procedure Call), ППО передачи сообщений (MOM, Message Orientet middleware) и ППО брокеров объектных запросов (ORB, Object Request Broker).

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

До недавнего времени применение RPC было сопряжено с немалыми сложностями, когда приходилось обращаться к приложению, написанному на другом языке программирования или работающему под другой ОС. Современные средства RPC позволяют разработчику действовать на более высоком уровне абстракции, не задумываясь о специфике языка программирования и ОС, — RPC стала удобным механизмом для взаимодействия приложений на различных программно-аппаратных платформах. Распространение Java вызвало к жизни аналог RPC для Java-приложений — RMI (Remote Method Invocation).

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

MOM. Следующим шагом в разработке ППО для взаимодействия между активными приложениями стали системы передачи сообщений. Принцип их построения достаточно прост, но тем не менее они предоставляют огромные возможности по связыванию программ.

В основе систем передачи сообщений лежит технология очередей сообщений: приложения обмениваются информацией не непосредственно друг с другом, а используя специальные буферы (очереди). В случае необходимости обмена данными программа пересылает их в принадлежащую ей очередь и продолжает функционирование. Доставку сообщения по назначению и его хранение обеспечивает специальное ПО — МОМ. При этом MOM, как правило, может работать на разных программно-аппаратных платформах и с использованием различных сетевых протоколов. Многоплатформность достигается за счет минимизации функций, выполняемых клиентской частью, а поддержка различных протоколов — за счет использования внутреннего протокола обмена информацией. Разработчику же предоставляется несложный и высокоуровневый API для работы с очередями сообщений.

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

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

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

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

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

Например, сообщение может передаваться по пути с наименьшей "стоимостью" доставки — при этом "стоимость" участков пути может определяться как в статическом, так и в динамическом режиме.

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

В настоящее время основная доля рынка MOM принадлежит двум компаниям — IBM с ее продуктом IBM MQSeries и Microsoft с MSMQ. IBM MQSeries отличается многоплатформностью, поддержкой различных сетевых протоколов и открытостью интерфейсов, позволяющих легко наращивать функциональность системы. Главное достоинство MSMQ — его тесная интеграция с OC Windows, а также поддержка COM.

ORB. Технология брокеров запросов к объектам является наряду с MOM наиболее бурно развивающимся типом ППО. ORB управляют обменом сообщениями в сети. Подобно "человеческому" брокеру, ORB выполняет функции интеллектуального посредника, т. е. принимает запросы от клиента (клиентского приложения), осуществляет поиск и активизацию удаленных объектов, которые принципиально могут ответить на запрос, и передает ответ объектам запрашивающего приложения. ORB, как и RPC и MOM, скрывает от пользователя процесс доступа к удаленным объектам. Запрашивающий объект должен знать имя активизируемого объекта и передать ему некоторые параметры (как правило, это информация об интерфейсе вызываемого объекта — своего рода API для ORB).

Интерес к ORB подогревается тем, что это middleware поддерживает объектную модель, ставшую де-факто стандартом при разработке больших информационных систем. В настоящее время на рынке конкурируют стандарт CORBA и технология COM корпорации Microsoft.

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

Наиболее часто в разговоре о промежуточном ПО возникает вопрос, какое ППО должно быть применено в тех или иных случаях. Сама постановка этого вопроса показывает, что сомнений в том, применять ППО или нет, остается все меньше и меньше — слово "middleware" прочно вошло в лексикон разработчиков информационных систем. Средства middleware незаменимы, когда надо упростить процесс создания распределенной системы, перенеся основной упор на разработку бизнес-логики, а не на взаимодействие различных приложений и ресурсов.

Но вернемся к вопросу о применении конкретных типов middleware. Здесь можно дать следующие рекомендации. При работе с базами данных одного типа следует применять ППО баз данных. Если необходимо осуществлять работу с различными типами БД или оптимизировать процесс доступа, то целесообразно применение мониторов транзакций. При взаимодействии приложений для обеспечения синхронного соединения можно использовать средства RPC, а для организации совместной работы слабосвязанных приложений, соединение между которыми не всегда надежно, — средства MOM. Вообще, MOM и ORB являются наиболее универсальными средствами middleware и могут применяться в большинстве случаев для организации связи между приложениями.

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

Языки программирования: разное

Добавить комментарий

Закрыть меню