А О С Т С
ТЕХНОЛОГИЯ РАСПРЕДЕЛЕННОЙ УДАЛЕННОЙ ОБРАБОТКИ
КОММЕРЧЕСКИХ ДАННЫХ
1994
УСЛОВИЯ ПРИМЕНЕНИЯ
Зачем это и кому это может быть нужно?
Попробуем обозначить условия бизнеса, которые эта технология обеспечивает.
1. Вложены большие деньги в APPLICATIONs, основанные на Xbase - DBase,
FoxBase, Clipper, короче, "плоские файлы" типа DBF или DAT.
2. Нет сил или средств на приобретение HARDWARE и SOFTWARE для реляционных
SQL-серверов под Windows, UNIX, VMS, MVS и/или на разработку приложений
для таких систем.
3. Объекты бизнеса рассредоточены в пределах города, страны или мира.
На каждом объекте требуется ввод определенной части общей информации
для использования ее затем в пределах всей информационной системы,
и получение определенной части информации из всей системы.
4. Нет практической необходимости или экономической целесообразности
в поддержании ON-LINE связи между узлами системы во время оперативной
работы, как того требуют архитектуры CLIENT-SERVER и HOST.
Например, данные, вносимые в базу в Миннесоте, потребуются в Нью-Йорке
только на следующий день, и нет нужды "висеть" на "сервере" или "хосте"
в ON-LINE, а можно передать все изменения "за один раз". Или - много
точек обработки данных требуют большого количества линий связи и
процессов "сервера" или "хоста", хотя обработка не настолько интенсивная,
чтобы держать эти линии все занятыми а центральный компьютер загруженным.
5. Требуется независимая от центральной базы данных или других баз
системы локальная обработка данных в пределах конкретного узла(объекта)
обработки. Например - для проверки достоверности данных перед передачей
их в систему, или локализация в пределах объекта тех или иных данных
из соображений секретности.
6. Необходимо распространять те или иные данные, измененные в "узлах"
в пределах всей информационной системы - в центральный репозиторий
и на другие узлы обработки. При этом необходимо "на лету" переопределять,
какая информация и как будет приниматься с каждого конкретного узла,
и какая информация и как будет поступать на каждый узел с других
точек обработки или из центрального репозитория.
7. Необходимо гибкое управление "оперативностью" передачи и получения
измененной информации. Например, информация о наступлении события,
определенного в страховом контракте должна обрабатываться немедленно,
а данные о новых заключенных страховых контрактов могут обрабатываться
в течении всего дня. Короче, требуется сочетание обработки ON-LINE и
OFF-LINE, с возможностью изменения этого сочетания в процессе работы.
8. Требуется интеграция различных APPLICATIONS, разработанных в различных
системах разработки, в единую распределенную информационную систему,
поддерживающую логическую целостность данных.
ПРИМЕР ИСПОЛЬЗОВАНИЯ
Приведем конкретный пример того бизнеса, для которого на данный момент
описываемая технология отработана. Рамкой в нижней части схемы обведена
оригинальная часть, разработанная АО СТС. Соединение всех из вышепере-
численных обстоятельств заставило принимать оригинальные решения.
1. Требовалось утилизация старых программ, чтобы не тратить время
на разработку новых.
2. Требовалось использование компьютеров не только 386-x но и 286-x
и даже XT - для обеспечения работы на точках продажи. Не было
денег на закупку серверов под Oracle, Sybase или другой SQL-сервер.
3. В каждом из объектов типа "точка продажи", "учет и регистрация",
"клиент", "торговая компания", "банк" необходимо хранение специфической
информации, ненужной для других объектов.
4. Информация по продажам с BANKING CARD должна обрабатываться ON-LINE,
CREDIT-CARD требуют только ежедневной передачи OFF-LINE обработанных
данных, а "электронные отчеты" клиентам могут передаваться раз в месяц.
5. При отсутствии ON-LINE связи, работа на объектах должна нормально
идти OFF-LINE с использованием "локальных" баз данных, которые
содержат только необходимую для оперативной работы информацию.
6. Оперативные данные, поступающие с "точек продаж", должны обрабатываться
и распространяются на другие объекты. При этом, на каждый из объектов
должны передаваться только предназначенные для него данные.
7. Необходимо в процессе работы "на ходу" переопределять, какие именно
данные, в каком объеме, и с какой частотой должны поступать с того
или иного объекта и передаваться на него.
8. Базовые программы для RETAIL STORES и банков разработаны на FoxBase,
программы для GAS STATIONS и аналитическое SOFTWARE - с использованием
Clipper. Структуры баз данных в разных приложениях отличались -
требовалось объединить обработку этой разнородной информации в
рамках одной системы.
Cash and Cards Processing Hardware
|
HARDWARE DEVICE DRIVERS (Assembler)
| |
| |
POINT-OF-SALE END SOFTWARE (Clipper,FoxBase) |
| |
| REGISTRATION AND ACCOUNTING SOFTWARE (Clipper,FoxBase)
| |
| | CUSTOMER END SOFTWARE (Clipper,FoxBase)
| | |
| | | TRADE COMPANY END SOFTWARE (Clipper,FoxBase)
| | | |
| | | | BANK END SOFTWARE (Clipper,FoxBase)
| | | | |
| | | | |
+==========================================================================+
| | | | | | |
| CLIENT-END TELE-COMMUNICATION SOFTWARE (C,Assembler) |
| | |
| Tele-communication Hardware (Modems,Networks,R/Stations) |
| | |
| SERVER-END TELE-COMMUNICATION SOFTWARE (C,Assembler) |
| | |
| X-BASED DISTRIBUTED DATABASE TRANSACTIONS PROCESSOR (Clipper,Novell,C) |
| | |
+==========================================================================+
|
CENTRAL DATABASE ADMINISTRATION CONTROL SOFTWARE (Clipper,FoxBase)
ОСНОВОПОЛАГАЮЩИЕ КОНЦЕПЦИИ
Теперь - о концепциях, положенных в основу системы.
В основном, здесь переплетаются принципы, используемые в системах
электронной почты, теле-конференций, распределенных базах данных
и существующих серверов реляционных DBMS.
ОСНОВНЫЕ ПРИНЦИПЫ
- На каждом узле обработки определено, какие таблицы (файлы) из
локальной базы данных (LOCAL DATABASE) являются подмножествами
соответствующих глобальных таблиц (GLOBAL DATA). Все прочие таблицы
(файлы) считаются локальными (LOCAL DATA).
- APPLICATION на каждом узле работает всегда только со своей
LOCAL DATABASE, которая обычно является неполным подмножеством
GLOBAL DATABASE, существующей в пределах всей системы.
- Все изменения в пределах системы производятся посредством
передаваемых с одного узла обработки на другой DISTRIBUTED
TRANSACTION FILES (DT-FILES). Каждый такой файл - это совокупность
записей или строк, именованная по той глобальной распределенной
таблице, изменения в которой он отражает. Каждая запись в файле -
это информация о необходимой операции SELECT/INSERT/DELETE/UPDATE
над глобальной таблицей с соответствующими значениями полей/колонок.
- С каждого узла обработки данные (DT-FILES) могут быть переданы на один
или более других узлов. Каждый узел может принять данные также
с одного или многих узлов.
- Обмен данными (DT-FILES) может происходить по инициативе конкретного
узла - в этом случае он выступает по отношению к другому узлу, как
клиент. Также узел может сам отвечать на запрос другого узла, выступая
при этом в качестве сервера.
- Обработка глобальных данных ведется на двух уровнях.
Спецификации доступа и изменений в GLOBAL DATA, списки узлов
для рассылки изменений с характеристиками этих узлов определяются
в DISTRIBUTED PROCESSING LIST (DP-LIST) для каждого узла.
Функции обеих уровней работают строго в соответствии с этими
спецификациями. Сам DP-LIST может быть изменен "ON FLY" средствами
самой системы распределенной обработки.
- Первый уровень обеспечивается встроенным в APPLICATION, работающее на
узле, DISTRIBUTED PROCESSING ENGINE (DP-ENGINE). Функции данного
уровня отражают все оперативные изменения в GLOBAL DATA, формируя
соответствующие записи в DT-FILES. Эти - же функции производят
обработку данных, полученных с других узлов посредством функций
второго уровня.
- Функции второго уровня активизируются в момент обмена данных,
происходящего по инициативе конкретного узла или другого узла,
давшего запрос конкретному узлу. Эти функции обеспечиваются
REMOTE PROCESSOR, который обеспечивает базовые коммуникационные
задачи - ПЕРЕДАЧА ИЗМЕНЕНИЙ, ПРИЕМ ИЗМЕНЕНИЙ, ВЫЗОВ УДАЛЕННОГО
ПРОЦЕССА С ОЖИДАНИЕМ, ОТЛОЖЕННЫЙ ВЫЗОВ УДАЛЕННОГО ПРОЦЕССА.
Здесь же отрабатываются функции установки соединения, входа
в систему по USER-ID и PASSWORD, управления ходом транзакции.
- Если функции второго уровня вызываются из APPLICATION узла
для обеспечения конкретных BUSINESS FUNCTIONS, данный узел
работает, как в режиме ON-LINE, каждый раз получая "свежую"
информацию из GLOBAL DATABASE. В остальных случаях обработка
ведется OFF-LINE, на основе текущей LOCAL DATABASE.
- Если большинство узлов выступают только инициаторами обмена
изменениями с каким-то одним узлом, то система приобретает
конфигурацию (топологию) неоднородной сети с центральными
"серверами". Если большинство узлов также выступают инициаторами
обмена данными, система приобретает топологию одно-ранговой
сети со множественными серверами.
Также возможен третий вариант, когда обработка на большинстве узлов
ведется исключительно OFF-LINE, но эти узлы одновременно выступают в
качестве серверов. При этом один или несколько "центральных"
узлов периодически инициируют связь, как клиенты, с остальными -
"подкармливая" их, по необходимости, свежей информацией.
Возможно гибкое сочетание трех "крайностей" и изменений топологии
системы "ON FLY".
- Известно, что не существует 100% надежности подтверждения
завершения транзакции и 100% надежности отката при аборте транзакции.
TWO-PHASE COMMIT только снижает на порядок вероятность нарушения
данных в распределенной системе. Поэтому, при отсутствие уверенности
в завершении транзакции или выполнении процедуры "отката" требует
ПОВТОРНОГО выполнения транзакции в любом из этих двух случаев.
Это должен обеспечивать механизм контроля повторяющихся транзакций.
- Данные принципы применимы не только к DISTRIBUTED DATABASES на
основе X-BASED SYSTEMS (DBase,Clipper,FoxBase), но и к любым DBMS,
использующим распределенную обработку. Реализация данных принципов
возможна в рамках любого системного (AS/400, UNIX, Windows, MS-DOS)
и коммуникационного (E-Mail systems, Network Messages Passing Systems,
Tele-Communications) окружений.
В заключение приведем функциональную схему узла распределенной обработки.
EACH APPLICATION NODE
APPLICATION .
/|\ /|\ .
| |GLOBAL .
| |DATA .
| |WAY .
LOCAL| \|/ . OTHER
DATA| DP-ENGINE------->REMOTE PROCESSOR<------->APPLICATIONS
WAY| /|\ /|\ /|\ /|\ . NODES
| | | | | .
| +-+-----------+ | | .
| | | | | | .
\|/ \|/ | \|/\|/ | .
LOCAL DATABASE | DT-FILES | .
| | .
+--------+--------+ .
|
DP-LIST
Антон Колонин
АО СТС, г.Чита