Александр Крейнес


Прикладные интерфейсы
Процедурные языки
Генераторы приложений
Заключение
Литература

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

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

Прикладные интерфейсы

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

В качестве конкретного примера того, насколько разнообразными могут быть API для систем компьютерной телефонии, рассмотрим интерфейсы прикладного программирования, рассчитанные на работу с оборудованием производства компании Dialogic. Аппаратура для компьютерной телефонии производства Dialogic представляет собой набор специализированных плат расширения для персонального компьютера, рассчитанных на выполнения определенных функций [1].

Наиболее развитым и обширным является семейство API Dialogic 4.x, в которое входят интерфейсы прикладного программирования для Windows, Windows 95 и NT, различных версий UNIX, OS/2 и MS-DOS. Пример программной архитектуры прикладной системы можно найти на рис. 1.

Picture 1 (1x1)

Рисунок 1.
Схема обмена информацией между приложением компьютерной телефонии и системными ресурсами в ОС Windows NT.

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

При использовании прикладных интерфейсов для работы с многоканальными платами компьютерной телефонии неизбежно возникает проблема одновременной обработки нескольких вызовов. Способ решения этой проблемы зависит от того, какая операционная система используется для работы с данным приложением. В операционных системах, где многозадачность поддерживается самой системой: Windows, UNIX, OS/2 можно использовать многопоточное программирование. При поступлении звонка по одному из обслуживаемых каналов порождается программная нить, которая существует до тех пор, пока не произойдет разъединение по данному каналу. Взаимодействие между нитями и разделение системных ресурсов компьютера между разными голосовыми каналами производится средствами самой ОС. Здесь надо заметить, что используемые в данном случае операционные системы обычно допускают одновременное существование лишь относительно небольшого числа нитей - около полутора десятков. Поскольку суммарное число каналов в системе может составлять несколько сотен, то при необходимости реализовать приложение с большим числом каналов приходится использовать технику программирования для однозадачных ОС.

Совершенно по-иному обстоят дела при работе с MS-DOS, где многозадачный режим не поддерживается. Здесь используется специальная техника программирования под названием "машина состояний" (state machine). Под состояниями здесь понимаются элементы блок-схемы приложения, а переход из одного состояния в другое происходит при осуществлении событий. В качестве состояний могут выступать: ожидание звонка, ожидание цифры, воспроизведение сообщения и т.д., а в качестве событий: поступление звонка, поступление цифры и т.д. Управление переходами из одного состояния в другое выполняется при помощи таблицы состояний. Ясно, что каждый из каналов может находиться в определенном состоянии; идентификаторы этих состояний запоминаются в специальном массиве и обновляются по мере перехода каналов из одного состояния в другое. Общая структура программы представляет собой бесконечный цикл, в начале каждой итерации которого проверяется, какие события произошли в системе. Затем по таблице состояний определяется, какие действия следует произвести при возникновении данного события в данном состоянии. После выполнения необходимых действий, соответствующему элементу массива присваивается значение, характеризующее новое состояние данного канала. На этом очередная итерация завершается и программа возвращается к ожиданию событий. Хотя на словах данная техника программирования выглядит достаточно просто, разработка больших разветвленных приложений с помощью машины состояний может представлять определенные сложности.

Семейство интерфейсов Dialogic 4.x предполагает, что все аппаратные ресурсы системы сосредоточены в пределах одного компьютера. Обращение к внешним ресурсам возможно только на уровне самого приложения. Существенно более глубокий подход применяется в разработанном компанией Dialogic новом стандарте систем компьютерной телефонии SCSA, в состав которого входит новый интерфейс прикладного программирования - SCSA API. Данный интерфейс является частью общего стандарта программирования в рамках SCSA, имеющего название SCSA Telephony Application Objects (TAO) Framework. Главная цель нового стандарта - обеспечение единого подхода к программированию различных компонентов систем компьютерной телефонии, например, факс-сервера и системы голосовой почты. Помимо обеспечения стандартного API для осуществления собственно программирования, SCSA TAO Framework помогает организовывать взаимодействие между различными компонентами систем компьютерной телефонии. Идеология SCSA TAO Framework предполагает наличие системных функций, реализующих архитектуру клиент-сервер в системе компьютерной телефонии. Благодаря таким функциям конкретное приложение может не заниматься вопросами выбора системного ресурса, необходимого для выполнения задания или установкой соединения и маршрутизацией телефонного вызова. Новый стандарт программирования определяет также протокол обмена информацией между приложениями и ресурсами телефонной системы, что обеспечивает аппаратную независимость прикладной программы от конкретного оборудования. Единственным требованием является лишь поддержка стандарта SCSA. Следует отметить, что SCSA TAO Framework появился совсем недавно, и используется еще не слишком широко, однако, о поддержке этого стандарта заявили уже около 200 производителей оборудования для компьютерной телефонии.

Более широкое распространение получили два других интерфейса: TAPI и TSAPI, определяющие способ встраивания систем компьютерной телефонии в локальную информационную сеть организации. В первую очередь, порядок взаимодействия системы компьютерной телефонии с установленным в организации коммутационным оборудованием. TAPI был предложен компаниями Microsoft и Intel как интерфейс прикладного программирования в системе Windows для разработки приложений, ориентированных на сетевую рабочую станцию. Этот интерфейс полностью интегрирован в Windows 95, где он получил название Windows Telephony. В TAPI аппаратные средства компьютерной телефонии рассматриваются как разновидность системных ресурсов, а взаимодействие с ними строится на основе модели WOSA (Windows Open Services Architecture). Идея этой модели состоит в том, что взаимодействие между приложением и аппаратными ресурсами осуществляется через два программных интерфейса: аппаратно-независимый API, отвечающий за обмен информацией между приложением и ядром операционной системы, и независимый от приложения SPI (Services Programming Interface), поддерживающий информационный обмен между ядром операционной системы и аппаратной базой.

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

В противоположность TAPI, стандарт программирования TSAPI, предложенный компанией Novell совместно c AT&T и рассчитанный на использование в рамках ОС NetWare, реализует архитектуру клиент-сервер и рассчитан на полную интеграцию офисного коммутационного оборудования в систему компьютерной телефонии. Серверная часть прикладной системы, выполненная в виде загружаемого модуля NetWare (NetWare Loadable Module, NLM), отвечает за прием входящих и инициализацию исходящих звонков. NLM обменивается информацией с офисным коммутатором или PBX: выдает команды на выполнение соединения или организацию конференций, воспринимает от коммутатора служебную информацию, сопровождающую телефонный вызов, например, автоматическое определение номера. Помимо этого, серверная часть приложения запрашивает корпоративную базу данных для получения информации, необходимой для инициализации исходящего или приема входящего звонка. Клиентская часть приложения обеспечивает интерфейс с пользователем, сообщает ему всю необходимую информацию о входящем звонке и инициализирует исходящие звонки.

Архитектура клиент-сервер реализована и в продукте CT-Connect (рис. 2), разработанном компанией Dialogic для систем компьютерной телефонии, работающих под Windows NT. Данный продукт представляет собой сервер, обеспечивающий обмен информацией между стандартным коммутационным оборудованием и различными техническими средствами компьютерной телефонии. По существу, CT-Connect можно рассматривать как средство доступа к коммуникационному оборудованию для систем, разработанных под TAPI. В состав системы, разработанной под CT-Connect должны входить: программное обеспечение сервера и ряд клиентских модулей, которые и предоставляют интерфейс прикладного программирования для разработки приложений.

Picture 2 (1x1)

Рисунок 2.
Пример конфигурации системы на базе СТ-Connect

Процедурные языки

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

В качестве примера возьмем один из наиболее развитых на данный момент языков VOS, предложенный компанией Parity Software. VOS обеспечивает разработку приложений под MS-DOS, UNIX, Windows NT и Windows 95. Данный язык имеет не только средства взаимодействия с телефонными линиями, но и поддерживает работу с несколькими телефонными каналами, что, является одной из главных проблем при работе с универсальными языками программирования. В VOS предусмотрена функция spawn(), позволяющая одновременно запускать несколько процессов, имитируя многозадачную среду. Каждый из запускаемых процессов программируется независимо, а взаимодействие между процессами и разделение системных ресурсов поддерживается средствами самого языка VOS. Именно это свойство и позволило создателям данного языка заявить о разработке специализированной операционной системы для приложений компьютерной телефонии. Собственно говоря, само название VOS расшифровывается как Voice Operating System. Запустив один и тот же процесс для разных входных каналов можно получить систему голосового ответа, работающую одинаково для всех каналов. После запуска все эти процессы начинают жить своей жизнью, а их текущее состояние определяется состоянием соответствующего канала. Если при работе с машиной состояний программист должен вручную отслеживать все события на всех каналах, то в данном случае состояние каналов отслеживается автоматически.

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

Генераторы приложений

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

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

В качестве примера генератора приложений на базе таблиц можно привести продукт EASE производства компании Expert Systems. Разработка приложений с использованием данной системы состоит из девяти этапов: определение параметров телефона, задание значений параметров по умолчанию, разработка сценария, генерация кода, пробный прогон и отладка. На стадии разработки сценария программист определяет содержание голосовой подсказки или голосовых меню, задает возможные события и определяет, какие действия следует осуществить при возникновении того или иного события. Помимо стандартных действий, связанных с установлением телефонного соединения, воспроизведения голосовых сообщений и распознавания ответов абонента в виде DTMF-набора, EASE также обеспечивает доступ к базам данных и поддерживает работу со средствами факсимильной связи: генерация и отсылка факса по тексту, факс по требованию, факсимильная рассылка. Кроме этого данный продукт можно применять в приложениях, использующих преобразование текст-речь и комплексы распознавания речи. Максимальное число каналов, обслуживаемых приложением на базе EASE составляет 48, в то время как предел емкости системы при использовании шины PEB составляет 128, а при работе с шиной SCSA-2048 каналов. Отсюда видны ограничения возможностей системы по сравнению с применением подхода, связанного с программированием на языке высокого уровня или использованием процедурного языка.

В качестве примера генератора приложений на базе графического интерфейса пользователя можно привести продукт Visual Voice, предлагаемый компанией Stylus Innovation. Однако, разработка приложений на базе графического интерфейса далеко не единственное средство, предлагаемое Visual Voice. В действительности, Visual Voice - это нечто среднее между процедурным языком и генератором приложений на базе графического интерфейса. Опытные программисты могут использовать библиотеку Visual Voice для языка Visual Basic, получив в результате процедурный язык для программирования прикладных систем. Начинающим же разработчикам будет удобнее использовать средства графического интерфейса, предлагаемые данным продуктом. Visual Voice поддерживает доступ к базам данных и работу в локальной сети, выполнение ряда телефонных функций: коммутация вызовов, организация конференций, работа с цифровыми линиями, осуществление факсимильной связи, а также распознавание речи и преобразование текст-речь. Однако имеются и существенные ограничения - общее число входных каналов не может превышать 24.

Заключение

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

Литература

[1]. А.Крейнес. Железное сердце компьютерной телефонии. Открытые системы, N 4, 1996.