<--  | Домой  | Карта  | Индекс  | Поиск

автор Bob Smith <bob/at/linuxtoys.org> Об авторе: Bob является Линукс-программистом и радиолюбителем. Вы можете найти его последний проект на www.runtimeaccess.com и его домашнюю страницу на www.linuxtoys.org. Перевод на Русский: Peter Demidov <p_demidov/at/rambler.ru> Содержание: Десятисекундный обзор Много пользовательских интерфейсов -- один сервис Интерфейс базы данных Определение таблиц Табличный редактор Две команды Скачивание и сборка Преимущества RTA Итог Страница отзывов

Разговаривая с работающим процессом Резюме: Run Time Access - это библиотека, которая позволяет вам смотреть структуры данных в вашей программе как таблицы базы данных PosgreSQL или как файлы в виртуальной файловой системе (такой же, что и /proc). Использование RTA упрощает выдачу вашему демону или сервису некоторых типов управляющих интерфейсов, таких, как web, shell, SNMP, или framebuffer. _________________ _________________ _________________

Десятисекундный обзор

Скажем, у вас есть программа с данными в массиве структур. Структура и массив объявлены так:

struct mydata { char note[20]; int count; } struct mydata mytable[] = { { "Sticky note", 100 }, { "Music note", 200 }, { "No note", 300 }, };

Если вы создаете свою программу с библиотекой Run Time Access, вы сможете проверять и устанавливать внутренние данные программы из командной строки или из другой программы. Ваши данные будут выглядеть так, как если бы они были в базе данных PostgreSQL. Следующее иллюстрирует то, как вы можете использовать Bash и psql, инструмент PostgreSQL для командной строки, чтобы устанавливать и читать данные в вашей программе.

# myprogram  &

# psql -c "UPDATE mytable SET note = 'A note' LIMIT 1"
UPDATE 1

# psql -c "SELECT * FROM mytable"
   note     | count
------------+-------
 A note     | 100
 Music note | 200
 No note    | 300
#

Эта статья объясняет зачем RTA нужна, как использовать библиотеку RTA и какие преимущества вы можете ожидать от использования RTA.

Много пользовательских интерфейсов -- один сервис

Традиционный UNIX сообщен с сервисом посредством помещения его конфигурационных данных в /etc/application.conf, а его аккумулированного вывода - в /var/log/application.log. Этот принятый подход, вероятно, неправильный для сегодняшних сервисов, которые работают на оборудовании и сконфигурированы относительно неподготовленным сисадмином. Традиционный подход терпит неудачу, потому что теперь нам нужны несколько типов одновременных пользовательских интерфейсов, и мы хотим через каждый из этих интерфейсов обмениваться конфигурацией, состоянием и статистикой с сервисом во время его работы. То что необходимо - это доступ во время исполнения.

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

Типы пользовательского интерфейса включают web, командную строку, framebuffer, SNMP, клавиатуру и LCD, LDAP, родной Windows, и другие интерфейсы по выбору. Несомненно общий API и протокол для всех пользовательских интерфейсов был бы хорошей идеей. Но какой API и протокол?

Интерфейс базы данных

RTA выбирает для использования базу данных PostgreSQL как общий API и протокол. Конфигурация, состояние и статистика помещены в массивы структур, которые предстают в API, как таблицы в БД PostgreSQL. Программы пользовательского интерфейса написаны, как клиенты, подключающиеся к БД PostgreSQL. Этот подход имеет два больших преимущества:

• Клиенты пользовательского интерфейса используют хорошо известный, хорошо документированный и хорошо отлаженный API. Использование PostgreSQL существенно уменьшает время разработки. Также PostgreSQL имеет связь с C, Java, PHP, Perl и почти всеми другими популярными языками, так, что вы можете программировать ПИ на языке, правильным для работы.
• Парадигма таблицы в БД довольно хорошо совпадает с тем, как большинство из нас пишет программы, которые обеспечивают сервис. Мы используем структуры данных в качестве строк и массивы или связные списки в качестветаблиц.

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

Здесь мы называем это management interface, так как он предназначен для состояния, статистики и конфигурации. Несмотря на то, что показан только один интерфейс, вы должны помнить, что вы можете иметь много интерфейсов для вашего приложения, и они все одновременно могут иметь доступ к приложению.

PostgreSQL использует TCP в качестве транспортного протокола, поэтоиу необходимо, чтобы ваше приложение могло связываться с TCP портом и принимать соединения от различных пользовательских интерфейсов. Все байты, полученные от принятого соединения передаются в RTA при помощи подпрограммы dbcommand(). Любые данные, предназначенные для возврата клиенту, находятся в буфере, возвращаемом из dbcommand().

Как RTA узнает, какие таблицы доступны? Вы должны сказать ей.

Определение таблиц

Вы говорите RTA о ваших таблицах со структурами данных вызовом подпрограммы rta_add_table(). Сруктура TBLDEF описывает таблицу, а структура COLDEF описывает столбец. Вот пример, который показывает как добавить таблицу к интерфейсу RTA.

Скажем у вас есть структура со строкой длины 20 и целым, и вы хотите экспортировать таблицу с пятью такими структурами. Вы можете определить структуры и таблицу следующим образом:

    struct myrow {
        char    note[20];
        int     count;
    };

    struct myrow mytable[5];

Каждое поле структуры myrow является столбцом в таблице базы данных. Нам необходимо сообщить RTA имя столбца, в какой таблице он находится, его тип данных, его смещение от начала строки и защищен ли он от записи. Мы также можем определить callback-подпрограммы, вызываемые перед чтением столбца и/или после того, как он записан. Для нашего примера мы будем предполагать, что count доступен только для чтения и что мы хотим, чтобы do_note() вызывалась когда происходит запись в поле note. Мы создаем массив из COLDEF, который добавлен в TBLDEF, и имеет по одной COLDEF для каждого члена структуры.

    COLDEF mycols[] = {
        {
            "atable",          // table name for SQL
            "note",            // column name for SQL
            RTA_STR,           // data type of column/field
            20,                // width of column in bytes
            0,                 // offset from start of row
            0,                 // bitwise OR of boolean flags
            (void (*)()) 0,    // called before read
            do_note(),         // called after write
            "The last field of a column definition is a string "
            "to describe the column.  You might want to explain "
            "what the data in the column means and how it is "
            "used."},
        {
            "atable",          // table name for SQL
            "count",           // column name for SQL
            RTA_INT,           // data type of column/field
            sizeof(int),       // width of column in bytes
            offsetof(myrow, count),  // offset from start of row
            RTA_READONLY,      // bitwise OR of boolean flags
            (void (*)()) 0,    // called before read
            (void (*)()) 0,    // called after write
            "If your tables are the interface between the user "
            "interfaces and the service, then the comments in "
            "column and table definitions form the functional "
            "specification for your project and may be the best "
            "documentation available to the developers."
    };

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

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

TBLDEF   mytableDef = {
      "atable",                 // table name
      mytable,                  // address of table
      sizeof(myrow),            // length of each row
      5,                        // number of rows
      (void *) NULL,            // iterator function
      (void *) NULL,            // iterator callback data
      mycols,                   // Column definitions
      sizeof(mycols / sizeof(COLDEF), // # columns
      "",                       // save file name
      "A complete description of the table."
};

Конечно, вы захотите, чтобы имя таблицы, видимой SQL, было таким же, что и ее имя в программе. Пример переключил из mytable в atable только чтобы показать, что имена не должны быть одинаковыми.

Имея весь вышеуказанный код, вы теперь можете сообщить RTA о вашей таблице.

    rta_add_table(&mytableDef);

Это все. Чтобы использовать RTA вам надо научиться использовать две структуры (COLDEFS и TBLDEF) и две подпрограммы (dbcommand() и rta_add_table()).

Вышеуказанный код приведен, чтобы дать вам представление о том, как работает RTA. Это не полное руководство или полностью рабочий пример. Полный рабочий пример, полное описание RTA API и структур данных находится на сайте RTA (www.runtimeaccess.com).

Как только вы определили таблицы для использования в вашем приложении, RTA определяет набор своих внутренних таблиц. Две самые интересные из них - это rta_tables и rta_columns, которые, конечно, являются таблицами для просмотра и описания всех таблиц и столбцов, определенных вами. Это так называемые системные таблицы. Системные таблицы делают то же, что ls делает для файловой системы и getnext() делает для SNMP.

Табличный редактор

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

Конечный вид экрана табличного редактора для шаблонного приложения RTA показан ниже.

Кстати, если все прошло хорошо при публикации этой статьи LinuxFocus, имена таблиц, данные выше должны иметь живые ссылки на шаблонное приложение, работающее на RTA web-сервере в Санта-Клара, Калифорния. Хорошая ссылка - это ссылка на mytable.

Две команды

Run Time Access - это библиотека, которая соединяет управляющие программы или программы пользовательского интерфейса, написанные с библиотекой клиента PostgreSQL (libpq), с вашим приложением или демоном. RTA - это интерфейс, а не база данных. Поэтому ей необходимы только две SQL команды: SELECT и UPDATE.

Синтакис для команды SELECT:

  SELECT column_list FROM table [where_clause] [limit_clause]

column_list - список имен столбцов, разделенных запятыми. where_clause - список сравнений, разделенный словами AND. Операторы сравнения: =, |=, >=, <=, >, и <. limit_clause имеет форму [LIMIT i] [OFFSET j], Где i - максимальное число возвращаемых строк и мы пропускаем j строк перед началом вывода. Некоторые примеры могут помочь разъяснить синтаксис.

  SELECT * FROM rta_tables

  SELECT notes, count FROM atable WHERE count > 0

  SELECT count FROM atable WHERE count > 0 AND notes = "Hi Mom!"

  SELECT count FROM atable LIMIT 1 OFFSET 3

Установка LIMIT в 1 и определение OFFSET - это способ получить специфическую строку. Последний пример эквивалентен коду на C (mytable[3].count).

Синтаксис команды UPDATE:

UPDATE table SET update_list [where_clause] [limit_clause]

  UPDATE atable SET notes = "Not in use" WHERE count = 0

  UPDATE rta_dbg SET trace = 1

  UPDATE ethers SET mask = "255.255.255.0",
                    addr = "192.168.1.10"
                WHERE name = "eth0"

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

Скачивание и сборка

Вы можете скачать RTA с его web-сайта www.runtimeaccess.com (RTA находится под действием LGPL). Будьте осторожны в выборе версии RTA для скачивания. Последняя версия RTA использует новый протокол PostgreSQL, введенный в PostgreSQL версии 7.4. Большинство современных дисрибутивов Linux используют версию 7.3. Пока вы можете использовать старую версию RTA для начальных попыток. Чтобы получить последние исправления и расширения, вы должны использовать последние версии.

После разархивации вы должны получить следующие директории:

  ./doc            # a copy of the RTA web site
  ./empd           # a prototype deamon built with RTA
  ./src            # source files for the RTA library
  ./table_editor   # PHP source for the table editor
  ./test           # source for a sample application
  ./util           # utilities used in writing RTA

Благодаря Graham Phillips, RTA версии 1.0 имеет поддержку autoconf. Graham портировал RTA из Linux на Mac OS X, Windows и Free BSD. Используя релиз 1.0 вы можете собрать RTA обычными

  ./configure
  make
  make install      # (as root)

Инсталяция помещяет librtadb.so и связанные библиотечные файлы в /usr/local/lib. Чтобы использовать RTA вы можете добавить эту директорию в /etc/ld.so.conf и запустив ldconfig, или вы можете добавить эту директорию к пути вашего загрузчика:

  export LD_LIBRARY_PATH=/usr/local/lib

Инсталяция помещает заголовочный файл RTA, rta.h, в /usr/local/include

Make собирает тестовую программу в директории test и вы можете проверить вашу установку, перейдя в директорию test и запустив ./app &. Команда netstat -nat должна показать программу, слушающую порт 8888. Теперь вы можете запустить psql и передать SQL команды вашему тестовому приложению.

  cd test
  ./app &

  psql -h localhost -p 8888
  Welcome to psql 7.4.1, the PostgreSQL interactive terminal.

  Type:  \copyright for distribution terms
         \h for help with SQL commands
         \? for help on internal slash commands
         \g or terminate with semicolon to execute query
         \q to quit

  # select name from rta_tables;
      name
  -------------
   rta_tables
   rta_columns
   rta_dbg
   rta_stat
   mytable
   UIConns
  (6 rows)

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

Преимущества RTA

Преимущества отделения программ пользовательского интерфейса от демона соответствующим образом относятся к широким категориям проектирования, кодирования, отладки и возможностей.

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

Во время кодирования определения таблиц - это то, что создают инженеры демона и то, с чего создают инженеры ПИ. Разделение ПИ и демона подразумевает, что вы можете независимо нанять ПИ-экспертов и демон-экспертов, и они могут кодировать независимо, что может помочь раньше принести продукт на рынок. Т.к. существуют связи Postgres с PHP, Tcl/Tk, Perl и "C", ваши разработчики могут использовать правильный инструмент для работы.

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

Возможность вашего продукта могут быть расширены с RTA. Ваш заказчик действительно оценит возможность видеть детализированную информацию о состоянии и статистику во время работы программы. Отделение ПИ от демона означает, что вы сможете иметь больше программ ПИ: SNMP, командную строку, web, LDAP и список можно продолжать. Эта гибкость будет важна для вас если (когда!) ваши заказчики поптребуют ПИ на заказ.

RTA предлагает нескольок других характеристик, которые вы можете захотеть иметь в пакете:

• Модель данных приложения, отраженная моделью данных API
• Удаленный доступ к приложению
• Использование приложением стандартного и существующего ПО
• Мало новых протоколов и API, чтобы изучить
• Механизмы обнаружения для приложения
• Мало ограничений на приложение
• Блокировка ресурсов
• Эффективность CPU и памяти

Итог

Эта статья представила очень краткое введение в библиотеку RTA и ее возможности. На web-сайте RTA есть FAQ, полное описание API и несколько примеров клиентских программ.

Как RTA может отобразить ваши структуры данных в виде таблиц в базе данных, также она может отобразить их, как файлы в виртуальной файловой системе. ( Использование пакета File System in Userspace (FUSE) by Miklos Szeredi.) На Web-сайте больше информации о том, как использовать интерфейс файловой системы.

Страница отзывов

2004-06-01, generated by lfparser version 2.43

mirror server hosted at Truenetwork, Russian Federation.