Инструменты управления SQL-сервером

Для анализа функционирования сервера Sybase предоставляет компоненту SQL Monitor,
представляющую на любом компьютере-клиенте в графическом виде данные по загрузке сервера,
вводу/выводу, интенсивности транзакций, использованию памяти сервером.

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

Интеграция приложений

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

Интеграция приложений в SQL Windows на основе современных технологий и стандартов

Л.Бродский, Элко Технологии
SQL Windows представляет собой объектно - ориентированную систему, предназначенную для
профессионального разработчика.

Объектный подход, заложенный в самом ядре системы в самых первых версиях, направлен на решение
двух основных задач, встающих на стадии разработки любой информационной системы:


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

С этой точки зрения SQL Windows представляет пользователям удобные и простые средства описания
и разработки новых классов, обеспечивающих как единичное, в том числе многоуровневое, так и
множественное наследование. В состав старшей версии продукта SQL Windows Corporate Edition
входит система управления разработкой проектов Team Windows, тесно интегрированная со средой
программирования.

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

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

С этой точки зрения важное место занимает поддержка современных стандартов.
В версии SQL
Windows 5.0. 2 обеспечена поддержка технологии OLE 2.0. Это позволяет встраивать в приложения
динамические объекты, обработка которых поддерживается внешними OLE 2.0. серверами, такими
как Microsoft Excel, Word или Paint Brush. Эта технология позволяет разработчику создавать сложные
документы и формы, содержащие в себе информацию из реляционных БД, электронные таблицы,
текстовую информацию из разных источников, звуковые и видеоклипы. И все эти компоненты могут
одновременно поддерживаться внутри единого рабочего пространства пользователя, без
переключения между разными задачами.

Указанные OLE объекты могут сохраняться, например в собственной БД, обеспечивая их
последовательный просмотр и редактирование пользователем во время скролинга результирующего
набора данных.

Для обеспечения создания OLE 2.0 контейнеров в составе SQL Windows поставляется c QuickOL20
класс, который позволяет разработчику с помощью удобного графического интерфейса создавать
OLE 2.0 контейнеры на своем рабочем пространстве.

Обеспечивается также поддержка автоматных контроллеров OLE в среде SQL Windows. Автоматные
контроллеры обеспечивают управление объектами - автоматами через посредство автоматного
сервера. Автоматные объекты представляют собой OLE объекты с программируемым интерфейсом. В
этом случае разработчик может сочетать функциональность заложенную в автоматном сервере, с той
необходимой ему специфичной функциональностью объекта, которую он сам разрабатывает.

SQL Windows дополнен редактором OLE классов, позволяющем определять и создавать
функциональные классы SAL (языка программирования SQL Windows), которые также называются
автоклассами. Функциональные классы создаются на основе библиотек типов.

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


SQL
Windows использует описательную информацию для создания собственных функциональных классов,
которые управляют объектом соответствующего типа. Эти классы называются также быстрыми OLE
классами, так как не содержат реального кода автоматного объекта, а содержат только необходимые
ссылки. Автоматный сервер обеспечивает поддержку создаваемых автоматных объектов во время
выполнения.

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

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

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

Другим важным механизмом интеграции различных программных средств внутри приложения,
реализованном в еще более ранних версиях SQL Windows, является динамический обмен данными
DDE. Технология этого протокола основана на взаимодействии нескольких различных задач внутри
приложения путем организации сессии между ними и выделении соответствующего логического
канала сессии. Сессия в DDE инициируется DDE-клиентом и реализуется путем направления
необходимых запросов и команд к DDE-серверу. При установлении сессии DDE-клиент указывает имя
необходимого DDE-сервера и тему (topic) сессии. Если DDE-сервер поддерживает указанную тему,
сессия устанавливается и логический канал выделяется.


После установления сессии имя DDE-сервера и
тема изменены быть не могут.

В процессе сессии клиент и сервер могут обмениваться информацией, относящейся к одному или
нескольким пунктам (item). Пункт должен ссылаться на данные, распознаваемые DDE-сервером.

Программа, разработанная в SQL Windows, может выступать как в роли DDE-клиента, так и в роли
DDE-сервера. Особое внимание заслуживает использование программ на SQL Windows в качестве
DDE клиента, обеспечивающего взаимодействие с такими DDE серверами как Microsoft Word и Excel
для формирования и обработки текстовой информации и электронных таблиц на основе информации
из реляционных баз данных.

Кроме поддержки этих технологий среда разработки в SQL Windows является открытой для
поддержки различных компонент, реализованных сторонними разработчиками. В SQL Windows
поддерживается механизм внешних библиотек, обеспечивающих возможность использования в SAL
API, предоставляемых разработчиками этих систем. Так для создания интегрированных деловых
систем, где необходима работа с большими потоками внешних документов, может быть использована
и встроена в приложение система Fine Reader, обеспечивающая сканирование текстов и их
распознавание. Причем указанные возможности становятся неотъемлемой частью пользовательского
интерфейса, который сочетает различные этапы обработки информации и различные программные
средства внутри единого приложения.

SQL Windows поддерживает также при разработке такие популярные механизмы, как Drag and Drop, а
также появившиеся в версии 5.0.2 закладки, позволяющие разработчику определять на едином
рабочем пространстве информационные элементы, связанные с различными режимами работы
пользователя, и привязывать их к разным закладкам, причем сам процесс определения закладок и
соответствующих им информационных элементов реализован в виде удобного для разработчика
графического интерфейса.

[]
[]
[]

Интеграция с внешними приложениями - открытые интерфейсы

Как следствие возможности обмена информацией с IDE, реальным кажется и интеграция среды
разработки Delphi с внешними инструментальными средствами - системами контроля версий,
мониторами транзакций, CASE-системами и т.п.

Интеграция со средствами разработки 4GL

S-Designor поддерживает широкий спектр средств разработки 4GL. Поддержка средств
разработки 4GL заключается в том, что на этапе проектирования модели данных обеспечивается
возможность проектировать отображение элементов объектов, связанных с базой данных. Данную
возможность проиллюстрируем на примере интеграции S-Designor со средством разработки
приложений PowerBuilder фирмы PowerSoft .

При создании окон данных (DataWindow) в PowerBuilder элементы окна отображаются
согласно расширенным атрибутам, назначенным этим элементам. Либо действуют установки по
умолчанию, если элементам окна расширенные атрибуты не назначены. Таким образом, расширенные
атрибуты - это спецификации, которые управляют изображением DataWindow при его
конструировании. Поэтому, использование расширенных атрибутов на этапе проектирования модели
данных позволяет значительно ускорить разработку отдельных объектов в приложении, например,
подготовку окон данных и стандартизовать пользовательский интерфейс.

Расширенные атрибуты хранятся в репозитории средств разработки. Для PowerBuilder
репозиторий представлен пятью таблицами, которые создает PowerBuilder в целевой БД при
первом подключении к ней.

Это таблицы:

PBCatTbl - содержит управляющую информацию, связанную с
общим оформлением DataWindow (общие форматы отображения данных,
заголовки колонок таблицы и так далее).
PBCatCol - содержит управляющую информацию, связанную с
оформлением отдельных колонок DataWindow. Здесь же содержатся ссылки на
форматы отображения, стили редактирования и правила.
PBCatFmt - содержит форматы отображения данных.
PBCatVld - содержит правила, которые должны выполняться при
редактировании данных.
PBCatEdt - содержит стили редактирования данных.
В S-Designor имеются возможности как импорта расширенных атрибутов в репозиторий
целевого средства разработки, так и экспорта из репозитория в модель. Расширенные атрибуты
можно сохранять в файлах и впоследствии при разработке новой модели данных загружать
спроектированные ранее расширенные атрибуты в новую модель.


В качестве расширенных атрибутов можно использовать выпадающие списки (окна данных типа Drop
Down DataWindow). Можно создать ряд окон данных, например, для словарей. После этого
необходимым колонкам таблиц в модели данных назначить стиль редактирования - Drop Down
DataWindow, где этими окнами данных будут спроектированные ранее окна данных для словарей.
После этого всегда, когда будет проектироваться основное DataWindow, в котором какие-либо
колонки должны быть представлены в виде выпадающих списков, содержащих данные словарей, - это
будет делаться автоматически.

Значительно ускорить разработку приложений позволяет использование доменов. В терминах
модели данных домен - именованный набор атрибутов объекта, который можно назначить колонке
таблицы. Набор атрибутов домена логически делится на две части. Первую часть
составляют расширенные атрибуты. Они используются при разработке приложений. Вторую -
правила и ограничения, связанные с физической структурой таблиц БД. Можно определить,
например, домен My_Date_Code для типа данных date и назначить его на колонки
таблиц, имеющие такой тип данных. Таким образом, один раз сконструировав необходимый
именованный набор атрибутов его можно многократно использовать и централизованно
редактировать. При импорте расширенных атрибутов в репозиторий средств разработки S-
Designor разложит "сам" эти атрибуты для тех колонок, на которые назначен домен
My_Date_Code. Пример конструирования домена My_Date_Code. приведен на pис.5

Интегрированная среда проектирования (Developer Designed)

Полностью интегрированное окружение
Быстрая итеративная разработка
Поддержка Windows 3.X, Windows 95, Windows NT, работа под Unix, Macintosh
Мощный язык 4GL управления данными PowerScript
Пространная справочная система
PowerBuilder предоставляет полностью интегрированную среду для разработчика. Все компоненты
приложения, такие как окна, меню, логика бизнеса, доступ к базам данных, создание баз данных,
графика и отчеты, можно разрабатывать полностью в рамках PowerBuilder, при этом нет
необходимости постоянно покидать среду и возвращаться в нее для выполнения каких-то
операций.

PowerBuilder - это быстрая итеративная среда разработки. Так как PowerBuilder имеет возможности
независимой компиляции, интегрированной отладки и тестирования, можно создать и отладить
приложение, не выходя из среды разработки.

PowerBuilder полностью поддерживает Microsoft Windows, включая все сообщения Windows, элементы
управления, многооконные приложения MDI (Multiple Document Interface), связывание и встраивание
объектов OLE (Object Linking and Embedding), динамический обмен данными DDE (Dynamic Data
Exchange) и вызовы динамически связываемых библиотек DLL (Dynamic Link Library) для интеграции
с существующими приложениями на PC. Графический интерфейс пользователя GUI (Graphical User
Interface) может быть создан разработчиком приложения без необходимости программировать на
низком уровне, например, на языке C, или использовать комплект разработчика программ Windows
SDK (Software Development Kit).

PowerBuilder содержит PowerScript - мощный, похожий на Basic, язык управления данными 4GL,
позволяющий разработчику легко включать простую и сложную деловую логику в приложения. Этот
язык состоит более чем из 100 функций для манипулирования объектами, числами и текстом, функций
обработки дат и времени, функций ввода/вывода, а также функций для полной поддержки OLE и DDE
как в качестве клиента, так и в качестве сервера. Инструмент, входящий в состав PowerBuilder, -
Художник функций (Function painter), позволяет разработчику легко расширять командный язык,
добавляя к нему определяемые пользователем функции. Внешние функции можно декларировать,
после чего они становятся доступными в приложениях PowerBuilder так же, как и встроенные функции,
что позволяет взаимодействовать с внешними процедурами на 3GL, которые работают на сервере или
клиенте.

PowerBuilder снабжен подробной контекстно-зависимой оперативной подсказкой (Online Help),
предоставляющей информацию из справочных руководств по PowerBuilder.

Интеллектуальный SQL (SQL Smart)

Поддержка множества СУБД
Интеллектуальный объект Окно данных (DataWindow), управляющий
взаимодействием с базами данных
Богатые возможности создания отчетов с использованием деловой графики
Мощные средства управления базами данных
Возможности SQL Smart, входящего в состав PowerBuilder, обеспечивают тесную интеграцию с
основной базой данных. PowerBuilder поддерживает широкий спектр систем управления
реляционными базами данных и полностью использует специфические особенности каждой из них.
Разработчики могут использовать встроенную высокопроизводительную реляционную базу данных
WATCOM SQL для создания автономных приложений, а также для обеспечения работы приложений
вне сервера.

Только PowerBuilder имеет объект Окно данных (DataWindow). Интеллектуальный объект
Окно данных позволяет манипулировать данными из реляционных баз данных без
программирования на SQL. С помощью Окна данных можно извлекать, обновлять, добавлять,
удалять, просматривать, печатать и сохранять данные в любом из 10 форматов файлов. Окно данных
непосредственно управляет взаимодействием и манипуляциями с базой данных.

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

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

InterBase, NEXUS & Java

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


InterBase: 4.1-4.5 -> replication. Возможности репликации в SQL-сервере
InterBase 4.5.
InterBase InterClient. Возможность удаленного доступа к таблицам InterBase
через новый протокол доступа.
InterBase: NS API, CGI. Интерфейс InterBase с наиболее
распространенными стандартами Web-серверов.
InterBase: UDF on Java. Возможность разработки и выполнения функций,
линкуемых к ядру сервера, написанных на языке Java.
NEXUS: application server. Появление сервера приложений в многозвенной
N-Tier системе.
NEXUS: business rules. Определение бизнес-правил на сервере
приложений.
NEXUS: several SQL-servers. Сервер приложений может работать с
несколькими источниками данных.
3-Tier -> N-Tier. Естественное преобразование архитектуры клиент-сервер
в N-Tier архитектуру.

Пример: система торгов на бирже.


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

Архитектура системы - слабый клиент, Web-сервер, сервер приложений, InterBase 4.0 для AIX -
стандартное решение для Intranet. Вся система может работать как в Internet, так и в закрытой
внутренней сети. Производительность системы удивила даже разработчиков - никто не ожидал
таких результатов, имея опыт разработки клиент-серверных систем.
Безопасность - в модели
реализовано кодирование передаваемых данных алгоритмом RSA, который всегда можно
поменять на другой; данные передаются по сети в зашифрованном виде. Количество одновременно
работающих клиентов может достигать, в зависимости от типа аппаратуры до нескольких тысяч
подключений одновременно. Место администратора торгов сделано по классической клиент-
серверной схеме, минуя многозвенную цепочку. Клиентское место администратора разработано на
Delphi, сервер приложений представляет из себя расширение Web-сервера, написанное на C и
комплект UDF для InterBase, написанный также на С. Разработка заняла 2 месяца.

Почему InterBase.

Естественный вопрос, который может возникнуть у специалистов, почему выбран InterBase в
качестве основы для такой разработки. Ведь в последнее время появилось достаточно много Web-
расширений известнейших SQL-серверов - например, Oracle, Sybase, Informix и др. Фактически,
причин было несколько:


перспективность работы в этом направлении. Как уже рассказывалось
выше, Borland предприняло ряд шагов по обеспечению разработчиков в Intranet
инструментарием, применение которого кажется нам целесообразным.
многоплатформенность InterBase. InterBase реализован для более чем 20
платформ, список этот постоянно расширяется, поэтому разработчики не
скованы необходимостью использования платформы прототипа системы.
беспрецедентная открытость InterBase, как инструмента. Именно
возможность подключения функций, написанных на С разработчиками,
позволяет обеспечить высокую производительность системы в целом.
самонастраиваемость сервера.

Технические особенности InterBase 4.0.

Вкратце перечислим основные особенности InterBase 4.0:


многоплатформенность: - NetWare, Windows NT, SCO UNIX, AIX, IRIX,
Solaris, HP/UX, open VMS, NextStep и др. (более 20 платформ)
архитектура множественных поколений записи - возможность
безблокировочной работы и быстрого восстановления после сбоев.
Возможность работы с "моментальным снимком" базы и поддержка DSS.


триггеры и хранимые процедуры
декларативная ссылочная целостность
поддержка online complex processing
соответствие стандарту SQL89 и драфт-стандарту SQL III
определяемые пользователем функции
сигнализаторы событий
поддержка 2 Phase Commit
поддержка больших двоичных объектов и массивов (размерность - до16)
интеграция с широко распространенными инструментами разработчика -
Delphi, Paradox, BC++, Visual dBase, CASE-средства третьих фирм.

Инициативы Borland в отношении Internet

Процитируем несколько строчек из пресс-релиза компании Borland:

Borland объявила две фазы реализации решений для Internet.

Первая из них, по словам Пола Гросса, вице-президента компании, заключается в расширении уже
существующих продуктов Borland дополнительными Internet-инструментами. В ближайших планах
реализации такого подхода компании - обеспечение поддержки разработки Java-приложений в
Borland C++ 5.0 и выпуск Visual dBase Internet Tools.

Вторая фаза, как было описано Гроссом, состоит в предоставлении заказчикам Intranet-решений -
внутрикорпоративных сетевых систем на базе стандартов и средств Internet.

" Ядро технологий Delphi, которые позволили достичь огромного успеха на рынке рабочих групп,
также обеспечит наш успех и на рынке Intranet-инструментов", отмечает Пол Гросс. "Мы
убеждены, что Java, как стандарт программирования для Internet, в сочетании с новейшими
инструментальными технологиями, представленными в Delphi, станет платформой для
распределенных вычислений в Intranet."

Borland отмечает, что Borland C++ 5.0, планируемый к выпуску в конце этого квартала, включает
средства разработки и отладки Java-приложений. Среда разработки предоставляет первый
графический отладчик для Java, позволяющий разработчикам находить и исправлять ошибки в
приложениях, написанных на языке Java. Компания, также, объявила о планах и
продемонстрировала "just-in-time" компилятор (транслятор в машинный код) под
названием AppAccelerator, позволяющий увеличить производительность существующих Java-


приложений в 5- 10 раз. Application Accelerator планируется к выпуску в составе Borland
C++ Development Suite 5.0 в конце этого квартала.

Отладчик и AppAccelerator являются первыми компонентами, которые, в дальнейшем,
будут интегрированы в единый инструмент визуальной разработки форм в стиле Delphi для
языка Java. В ноябре 1995 года Borland анонсировала такой продукт под кодовым названием
Latte.

Borland официально объявила о планах создания InterBase InterClient - расширении InterBase,
поддерживающем Java. Этот инструмент принесет большой выигрыш корпоративным
пользователям InterBase. В дальнейшем, Borland также планирует предложить сервер приложений
под кодовым названием "Nexus" для удаленного доступа к базам данных на основе Java. Это
позволит Intranet-разработчикам получить действительно трехуровневое (three-tier) окружение со
всеми преимуществами много-платформенности и соответствующих стандартов протоколов.

С 9 февраля до 31 марта 1996 года разработчики могут свободно получить предварительную
версию графического отладчика Borland для Java-приложений через Web-сервер компании - .

[]
[]
[]

Интерфейс к CASE структурного анализа и дизайна - JAM/CASEi

Интерфейс к CASE структурного анализа и дизайна в некотором отношении подобен интерфейсу к
СУБД. Одной из основных задач CASE является разработка структуры БД. Информация о
структуре БД хранится в репозитории CASE. Модуль JAM/CASEi позволяет осуществить обмен
информацией между Визуальным Репозиторием Объектов JAM и репозиторием CASE
аналогично тому, как структура БД импортируется в Репозиторий

JAM непосредственно из БД. Отличие заключается в том, что в случае интерфейса к CASE этот
обмен является двунаправленным, т.е. информацию из Репозитория JAM можно экспортировать в
репозиторий CASE.

Интерфейс к Мониторам Транзакций - JAM/TPi

Модули JAM/TPi используются при разработке приложения трехзвенной модели "клиент-сервер" с
применением мониторов транзакций.

Рис. 5 представляет схему реализации трехзвенной архитектуры "клиент-сервер" с использованием
JAM, JAM/TPi-Client и JAM/TPi-Server.

При разработке клиентской части трехзвенной модели модуль JAM/TPi-Client позволяет в методах
объектов использовать вызовы сервисов монитора транзакций. Наличие модуля JAM/TPi-Client
расширяет синтаксис JPL командами, ориентированными на работу с мониторами
транзакций.

При разработке сервера приложений модуль JAM/TPi-Server позволяет разрабатывать сервисы
монитора транзакций, используя современную 4GL технологию, а не только традиционный для
мониторов транзакций 3GL интерфейс.

Интерфейс к СУБД - JAM/DBi

JAM ориентирован на работу с реляционными SQL-серверами БД. Средством взаимодействия
JAM-приложений с СУБД является SQL. При разработки приложений БД SQL-запросы являются
составными частями методов объектов приложения. Модуль JAM/DBi осуществляет корректную
передачу SQL запроса соответствующей СУБД и прием и обработку результатов исполнения
запроса (включая и коды аварийного завершения при невыполнении запроса). Аргументами
запросов (т.е. источниками и приемниками информации) могут выступать объекты JAM
(интерфейсные элементы) и переменные JPL. В случае аварийного завершения запроса существует
возможность самостоятельной обработки кода аварийного завершения.

На рис. 3 представлена архитектура взаимодействия JAM и СУБД с помощью модулей
JAM/DBi.

Интерфейс программирования серверов Open Server

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

Технология и библиотеки OpenServer, входящие в состав Sybase System 11, позволяют
разрабатывать собственные приложения, использующие данные от технологического
оборудования. Для приложений клиента такие программы "выглядят" как хранимые процедуры на
Sybase-совместимом сервере базы данных.

Другое применение Open Server - разработка серверных компонент для математической или
криптографической обработки данных. Обработчик Open Server может быть использован как
приложением-клиентом, так и вызван из хранимой процедуры SQL Server.

Примером применения технологии Open Server может служить реализация доступа к электронной
почте из хранимых процедур.

Интерфейсы к СУБД

ERwin поддерживает прямой интерфейс с основными СУБД: DB2 версии 2 и 3, Informix версий 5.1,
6.0, 7.1, Ingres, NetWare SQL, ORACLE версий 6 и 7, Progress, Rdb версий 4 и 6, SQL/400 версий 2 и
3, SQLBase версий 5 и 6, SQL Server версий 4 и 6, Sybase версии 4.2, Sybase System 10 и 11, Watcom
SQL. Отметим, что поддерживаются как самые современные, так и предыдущие версии основных
СУБД (рис.8).

Интерфейсы прикладных программ

Программные интерфейсы ко всем службам, предоставляемым архитектурой Sybase, реализуются
через API Open Client и Open Server. Программные интерфейсы Open Client/Server независимы от
платформы. Среди поддерживаемых платформ DOS, Windows, MVS/CICS, Macintosh, NetWare,
Windows NT, OS/2, UNIX (все главные варианты), VMS и OpenVMS.

При разработке приложений-клиентов на языке 3-го поколения используются библиотеки с Cи-
интерфейсом: DB-Library, CT-Library или ODBC (только под Windows).

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

Интерфейсы программирования клиента:библиотеки DB- Library и CT-Library

DB-Library использовалась в предыдущих версиях Sybase для разработки приложений. Sybase
System 11 обеспечивает обратную совместимость с DB-Library.

CT-Library впервые появилась в Sybase System 10. Она используется в новых приложениях, в том
числе для написания приложений с использованием асинхронной обработки, возможностей
распределенной обработки, одновременным использованием Open Client и Open Server.

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

INTERNET и INTRANET

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

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


TCP/IP

Первое и самое главное - сетевой протокол ТСP/IP фактически реализован для любых типов сетей.
Любая аппаратурная экзотика поддерживает этот протокол.


коннект

Коннект клиентского броузера к WEB-серверу осуществляется исключительно легко. Многие
проблемы, которые были в прежней архитектуре клиент-сервер, когда клиентское приложение
напрямую осуществляет доступ к SQL-серверу, снимаются при использовании технологии Internet.
На сервере требуется меньше памяти, логика коннекта позволяет "удерживать" коннект даже при
физическом обрыве линии. Поскольку взаимодействие интернетовских броузеров с хостом
отлаживалось в самых разных условиях, по-разному передаются различные куски информации.
Так например, в расчете на медленное соединение вначале клиенту передается текстовая
информация, и только потом докачиваются графические или другие большие двоичные объекты.
Пользователь модемной линии может не дожидаться докачки всего изображения и принять
решение о переходе к новой странице информации.


данные: файлы, текст, ссылки, изображение, 3D, звук

Понимание того, что ограниченность типов данных является препятствием к широкому
применению классических реляционных СУБД, привела к расширению типов данных,
используемых современными SQL-серверами. Например, InterBase может оперировать
расширенным типом данных BLOb - большими двоичными объектами. А броузеры Internet могут
воспринимать текстовую информацию, ссылки на ресурсы (URL), изображение, звук, оперировать

присоединенными файлами.


отработанный механизм маршрутизации и логики коннекта

Надежность механизмов маршрутизации Internet позволяет строить сколь угодно сложную и
разветвленную сеть.


меры безопасности

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


многоплатформенность

В свое время Internet так или иначе справился с этой проблемой. И в настоящее время мы можем
пользоваться результатами: стандартные броузеры реализованы для всех мало-мальски значимых
платформ, новые стандарты (например, язык Java) также ориентированы на применение на всем
разнообразии используемой техники и операционных сред.


текущая ситуация

Мы только что обсудили преимущества интернетовской технологии для реализации
внтрикорпоративной системы, и что же, какова ситуация в настоящий момент, насколько
приемлемым кажется использование этой технологий для менеджеров информационных сетей
больших корпораций? Завставляет задуматься тот факт, что, по утверждениям экспертов,
соотношение пользователей внутрикорпоративных сетей к пользователям Internet - 5:1.


отсутствие стандартов

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

INTRANET: информационная система

клиент-сервер.... или... ?

Мы составили себе определенное впечатление об INTRANET, как о системе, каждый клиент
доступается к данным Web-сервера посредством своего броузера. Но является ли такая
архитектура архитектурой клиент-сервер? Ведь в классическом понимании на клиентское
приложение возлагаются некие дополнительные задачи - дополнительная логика. Позволяет ли
стандартный броузер решать такие задачи?

Если иметь в виду широко распространенный броузер Netscape, то почти ничего , за исключением
простейших диалогов и просматривания данных, такой клиент делать не может. Это и заставляет
такого клиента называть "слабым" (thin client), поскольку в большинстве случаев использование
броузера мало чем по возможностям отличается от применения терминала со своей (достаточно
мощной) системой команд.


логика на сервере

Слабость клиента заставляет размещать логику приложения на сервере; фактически, для
реализации не только системы подачи информации (или рекламного гипертекстового сервера)
требуется существенно дописывать функционирование стандартного Web-сервера, превращая (или
дополняя) его в application server.


логика на клиенте

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

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


N-tier ?


Возможность исполнения логики приложения c использованием одного и того же языка как на
клиенте, так и на сервере, позволяет использовать единый цикл разработки как для сервера, так и
для клиента. Быть может, суждено сбыться мечтам разработчиков о прозрачном перемещении
логики приложения с клиента на сервер... или даже серверы? Возможно, наиболее элегантным
решением задачи построения сложной корпоративной системы в будущем станет реализация ее в
виде цепочки серверов приложений, причем в момент разработки логика приложения может
свободно мигрировать, обеспечивая максимальную производительность и ясность всей
системы.


связь с БД

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


формирование страниц "на лету"

Фактически основным требованием является обеспечить Web-сервером формирование
гипертекстовых страничек для клиентского броузера, исходя из результатов запроса к SQL-серверу
и шаблона такой странички.

О создании инструментов создания таких систем объявили практически все ведущие компании:
Oracle, Informix, Sybase, Borland, Microsoft, IBM..., но, раз уж статья посвящена технологиям
компании Borland, остановимся на особенностях решений компании Borland.


Visual dBase Internet Tools

Реализовать логику Web-сервера можно по-разному, и один из новых инструментов компании
Borland предназначен для значительного количества приверженцев Visual dBase.


Visual dBase
Internet Tools позволяет реализовывать, с одной стороны, как клиентское приложение,
получающее доступ к Internet, так и серверную логику для Web-сервера, работающего под
управлением Windows NT.


Delphi components

Такой расширяемый инструмент, как Delphi, естественно не мог остаться без внимания как
Borland, так и третьих фирм, специализирующихся на написании компонент. Сейчас существует
уже целый спектр работоспособных решений для Delphi, от компонент для создания собственных
броузеров до компонент, позволяющих создавать application server в многоярусной (N-Tier)
архитектуре информационной системы Internet/Intranet.


Paradox & CGI

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


InterBase InterClient

Планируется выпуск специального дополнительного линка для SQL-сервера компании Borland,
позволяющего обращаться за данными к серверу непосредственно из интернетовского
клиента.

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


NEXUS

В ближайшее время планируется выпуск сервера приложений, где возможно будет размещать
бизнес-правила системы. При этом клиентское приложение может абстрагироваться от того, где и
в каком виде лежат данные. Nexus позволит объединять данные с нескольких серверов БД,
возможно, находящихся на физически разных серверах.


JAVA и LATTE

Что же такого привлекательного имеется в новом языке программирования Java?

Java - это язык, во многом похожий на C++, однако имеющий несколько весьма неожиданных
черт. Строгая типизация, как в языке Паскаль, отсутствие множественного наследования и строгое
определение интерфейса объектов, поддержка многопотоковости на уровне языка, ввод-вывод в
парадигме сокетов - вот основные особенности Java. При загрузке броузером приложения (applet -
буквально "приложеньица") на языке Java происходит его верификация интерпретатором Java, а
затем и исполнение. Такой способ исполнения позволяет избежать заражения системы
вирусом.

Базовый интерпретатор Java занимает совсем немного места - для Windows 95 он составляет всего
145 Кб - поэтому перенос всей системы для новой операционной и аппаратной платформы не
составляет труда, и это чувствуется - все новые и новые компании объявляют о своей поддержке
этого языка.

Инвертированные индексы

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

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

Использование электронной почты для доступа к ресурсам сервера

Набор расширенных хранимых процедур SQL Server включает процедуры работы с почтовыми
ящиками. Сервер может получить указание прочесть текущую почту и обработать ее (лучше всего
это задание оформить как периодически выполняемую задачу). В сообщении размещается вызов
хранимой процедуры или набор команд T-SQL. Сервер читает текст сообщения и выполняет
размещенные в нем команды. Результат исполнения присоединяется к письму, посылаемому в
ответ, в виде текстового файла или файла в формате CSV (поля, разделенные запятыми), который
можно непосредственно "взять" в электронную таблицу или импортировать в базу данных.
Естественно, возникает вопрос о предохранении данных от несанкционированного доступа.
Ограничение числа лиц, которые могут получать таким образом информацию, может быть
организовано различным образом, и тут необходимо позаботиться о защите доступа как со
стороны SQL Server, так и со стороны ПО, занимающегося отправкой почты. Для каждого
пользователя, который посылает запросы на сервер, можно завести соответствующий набор прав,
которые смогут эффективно ограничить диапазон действий, позволительных для него.

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

SQL Server способен "понять", кто пишет письмо. Можно также ограничить обрабатываемую
почту только письмами, которые имеют определенный текст в разделе Subject. Все это вместе
взятое позволяет утверждать, что если в организации четко соблюдается дисциплина хранения и
назначения паролей, то риск несанкционированного доступа к конфиденциальной информации
может быть сведен до минимума. Кроме того, на электронную почту можно возложить
обязанности по получению/передаче только безобидной информации, доступ к которой не
нуждается в серьезной защите.

Использование наследования

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

Источники информации:

Материалы 6-й Ежегодной Конференции Разработчиков Borland.
Периодические издания (1995 год): Delphi Informant, Delphi Developer, Microsoft System
Journal, Dr. Dobb Journal, Компьютерр-Пресс и др.
WWW-серверы: Borland, Miller Friman, Turbo Power, ProtoView, Popkin Software, InterSolv,
AOL и др.
"Delphi Developers Guide", S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS.
Каталоги программных продуктов "Delphi Only Tools" ZAC Catalog, "Delphi
Power Tools" Informant Communications Group.


[]
[]
[]

Ядро системы

Ядро системы включает в себя следующие основные компоненты:


Редактор Экранов. В состав Редактора Экранов входят:
Среда разработки экранов;
Визуальный Репозиторий Объектов;
Собственная СУБД JAM - JDB;
Менеджер Транзакций;
Отладчик;
Редактор Стилей;
Редактор Меню;
Набор вспомогательных отдельных утилит;
Средства изготовления промышленного релиза приложения;


Общая схема взаимодействия компонент ядра JAM представлена на рис 1.

JAM7 - инструмент разработки переносимых приложений архитектуры "клиент-сервер"

Ю.Петров, Компания Аргуссофт
Инструментарий разработки приложений JAM разработан и распространяется фирмой JYACC
(США) и название продукта расшифровывается как JYACC's Application Manager. Фирма JYACC
является частной и была создана в 1978 году. С 1978 по 1985 год фирма занималась консалтингом в
области информационных технологий. В 1985 году была выпущена первая версия JAM. На
сегодняшний день поставляется 7-я версия пакета. Вместе с тем JYACC не прекращает и
деятельности в консалтинговой сфере.

Язык четвертого поколения 4GL PROGRESS

Язык Четвертого Поколения PROGRESS (4GL) является функционально полным
высокоуровневым , объектно-ориентированным языком разработки приложений, который
позволяет удовлетворять всем требованиям, предъявляемым к современным приложениям, в тоже
время уменьшая сложность и повышая производительность их разработки.

4GL содержит все необходимые программные конструкции для решения самых различных
аспектов программирования сложных приложений без необходимости прибегать к менее
эффективным и менее переносимым языкам третьего поколения. Кроме этого, 4GL обеспечивает
поддержку и переход между тремя основными принципами программирования:
структурированным, событийно-управляемым и объектно-ориентированным, - от Вас не требуется
осваивать новые принципы программирования для того, чтобы успешно работать с PROGRESS.
Для завершения процесса разработки промышленного приложения Вам потребуются средства
разработки не только логики взаимодействия с пользователем, но также потребуются средства для
решения таких важных задач, как:

Автоматический контроль транзакций и блокирование записей
Получение и обработка информации из баз данных
Сложные вычисления и обработка данных
Пакетная обработка
Генерация отчетов
Целостность базы данных и требования безопасности
Поддержка двухбайтовых кодировок
Язык 4GL содержит все функции и операторы, необходимые для удовлетворения
вышеперечисленных требований. Но, в отличие от остальных инструментальных средств, менее
ориентированных на разработку приложения в архитектуре клиент/сервер, PROGRESS не требует
от Вас использования различных языков программирования для отдельного программирования
обработки данных на клиенте, серверных процессов и пакетной обработки на сервере. Все это
уменьшает стоимость затрат по изучению языка и продолжению разработки. Кроме этого Вы
можете интегрировать другие приложения и Си-код в PROGRESS, используя интерфейсы DDE,
DLL и именованные каналы, так же, в том числе наш собственный интерфейс Вызова Внешних

Процедур ( Host Language Interface) для использования внешних процедур на языке Си.

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

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

PROGRESS 4GL является первым объектно-ориентированным языком четвертого поколения,
который вводит понятие инкапсулированных процедурных объектов. Это позволяет Вам
использовать высокопроизводительную среду 4GL для разработки и дальнейшей модификации
многократно используемых объектов пользовательского интерфейса и объектов данных, не
затрачивая дополнительных сил и средств на изучение объектно-ориентированных языков
третьего поколения, таких как Cи++ и SmallTalk.

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

Как и все остальные средства Среды Разработки Приложений PROGRESS, язык 4GL наследует все
центрально хранимые в Словаре Данных умолчания (такие, как проверка правильности ввода,
форматы отображения и правила целостности данных). Наследование этих установок уменьшает
стоимость разработки приложения и снижает затраты по его поддержке в дальнейшем).

PROGRESS 4GL включает полный набор языковых средств для управления объектами,
построения циклов и логических условий, обработки всех типов данных, а также имеет полный
набор операторов для обработки реакции пользователя при разработке событийно-управляемых
приложений.

Если вы знакомы с такими языками, как COBOL, BASIC или С, то изучение PROGRESS 4GL не
составит для Вас труда. Также Вам должны понравиться системы высокоуровневых умолчаний и
операторы, присущие среде 4GL.

Если Ваши приложения ориентированы на использование во всем мире, то PROGRESS 4GL
предоставит Вам в распоряжение средства поддержки самых разнообразных кодировок, включая
двухбайтные, используемые в странах Азии.

JPL - внутренний процедурный язык программирования JAM

В состав Редактора Экранов входит JPL - процедурный интерпретируемый язык
программирования с синтаксисом, похожим на синтаксис C. В JPL доступны следующие
возможности:
Скалярные переменные и одно- и двумерные массивы;
Управляющие конструкции - if, else, for, while, break и next;
Передача параметров в функции и возврат значений.
Все JPL-функции оформляются в виде JPL-модулей. JPL-модуль является набором нескольких
именованных функций и не более одной неименованной функции. Неименованная функция есть
JPL-код от начала модуля до первой именованной процедуры и, очевидно, может отсутствовать в
модуле, если он начинается сразу с именованной процедуры. Из неименованной процедура
доступны именованные. JPL-модули могут быть трех типов:
Модуль экранного объекта (vidget module). Хранится вместе с
объектом. Неименованная процедура исполняется при возникновении события
validation для данного момента;
Экранный модуль (screen module). Хранится вместе с экраном.
Неименованная процедура исполняется при загрузке экрана, именованные
процедуры могут являться обработчиками событий всех объектов данного
экрана;
Внешний модуль (external module). Хранится в отдельном файле.
Загружается в память или принудительно, или при вызове процедуры с именем
этого файла. Возможна принудительная выгрузка. Неименованная процедура
исполняется при загрузке модуля. Внешние модули целесообразно
использовать для хранения универсальных процедур.
Экранные модули и модули объектов хранятся как в текстовом, так и в прекомпилированном (в
некоторый промежуточный код) виде. Доступны для редактирования в Редакторе Экранов.
Внешние модули хранятся в виде текстовых файлов. С помощью специальной утилиты текстовые
внешние модули могут быть прекомпилированы. Прекомпилированные внешние модули могут
храниться в библиотеках экранов.

Визуальный Репозиторий Объектов

Реализация принципов объектно-оpиентиpованного программирования осуществлена в JAM
следующим образом. Каждый элемент приложения с определенными свойствами и методами (в

качестве которых выступают обработчики событий) является объектом. Одной из составных частей
ядра JAM является Визуальный Репозиторий Объектов, в котором можно сохранять созданные
объекты. Визуальный Репозиторий Объектов является специальным типом библиотеки экранов и
соответствующим образом организован. Т.е. Репозиторий состоит из так называемых входов
(entries). которые выглядят как экраны с базовыми объектами на них. Текущая установка свойств и
методов является базовой. Для использования какого-либо базового объекта достаточно перенести
его мышью с входа Репозитория на проектируемый экран. При изменении свойств и/или методов
базового объекта эти изменения распространяются на всех потомков данного объекта. Реализован
механизм управляемого наследования свойств и методов, при котором можно запретить
наследование части или всех свойств/методов. Вся работа с Репозиторием осуществляется в
Редакторе.

Поддержка групповой разработки

Ядро JAM имеет встроенный интерфейс к системам управления многоверсионными проектами и
групповой разработки (PVCS на платформе Windows и SCCS на платформе UNIX). При этом под
управление этих систем передаются библиотеки экранов и/или Репозитории. При отсутствии таких
систем JAM самостоятельно реализует часть функций поддержки групповой разработки.

Редактор Меню

Позволяет разрабатывать и отлаживать системы меню. Реализована возможность построения
пиктографических меню (так называемые toolbar). Меню могут сохраняться как в отдельных
файлах, так и в экранных библиотеках. В одном файле может быть несколько поименованных
меню. Назначение каждого конкретного меню тому или иному объекту приложения
осуществляется в Редакторе Экранов.

Собственная СУБД JAM - JDB

В ядро JAM встроена однопользовательская реляционная СУБД JDB. Основным назначением JDB
является прототипирование приложений в тех случаях, когда работа со штатным сервером БД
недоступна или нецелесообразна. В JDB реализован необходимый минимум возможностей
реляционных SQL-серверов БД за исключением индексов, внешних слияний таблиц (outer joins),


хранимых процедур, триггеров и так называемых view. В результате с помощью JDB можно
построить БД, идентичную целевой БД (с точностью до отсутствующих в JDB возможностей) и
разработать значительную часть приложения не загружая сеть и сервер. В состав JAM входит
утилита интерактивного SQL для JDB.

Отладчик

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

Набор вспомогательных отдельных утилит

Утилиты JAM представляют три группы:

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

Средства изготовления промышленного релиза приложения

Приложения, разработанные с использованием JAM, не требуют так называемых run-time систем и
могут быть изготовлены в виде исполняемых модулей. Для этого разработчик должен иметь
компилятор C и редактор связей. Для изготовления промышленного релиза в состав JAM входит
файл сборки (makefile), исходные тексты (на языке C) ряда модулей приложения и необходимые
библиотеки.

Классификация информационных систем

По масштабам применения современные АС подразделяются на три основные класса:
Настольные - для работы одного человека. К ним следует отнести Автоматизированное
Рабочее Место (АРМ) бухгалтера малого предприятия, АРМ кассира, АРМ расчетчика
заработной платы и.т.д. Внедрение таких программ не вызывает особых трудностей и для
хороших систем может исчисляться днями.

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

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

Рассмотрим корпоративные системы, которые только в настоящее время стали появляться на
нашем рынке, и в скором времени неизбежно станут столь же популярны, как и на Западе. Может
показаться, что корпоративные системы нужны только крупным предприятиям. На самом деле те
проблемы, которые в них решаются, актуальны для любой фирмы.
Ниже приводятся отличительные черты современных корпоративных систем.

Классификация продуктов Oracle

Все многообразие продуктов фирмы Oracle можно разделить на следующие группы (смотри
таблицу):


Oracle7 Server - ядро СУБД и дополнительные компоненты ядра
(опции). Они необходимы для хранения, поиска, извлечения, обработки и
администрирования данных;
инструментальные средства разработки приложений. Это, в первую
очередь, набор средств разработчика Developer/2000, а также
прекомпиляторы с языков 3GL и библиотека CALL-интерфейса;
средства автоматизации проектирования и разработки (CASE-средства) -
Designer/2000;
средства для конечных пользователей. Это набор средств
Descoverer/2000, офисная система Oracle Office, средства хранения и
обработки текстов Text Server (c Context и CoAutor);
средства для анализа данных и создания OLAP (online analyse processing)
приложений - Express - продукты;
средства для обеспечения работы продуктов Oracle в компьютерной сети.
Это SQL*Net с драйверами различных сетевых протоколов, средства
управления сетью, кодирования данных, преобразования протоколов;
средства для взаимодействия с пакетами других фирм. Это шлюзы по
данным (Transparent Gateway) к различным СУБД и процедурные шлюзы;
ODBC драйвер, Oracle Objects for OLE, универсальный пакет связи Oracle Glue;
продукты для рабочих групп - Workgroup/2000. К этой группе относится
нерасширяемое ядро Oracle для персональных компьютеров,
однопользовательский персональный Oracle, средства разработки небольших
приложений-Oracle Power Objects. Продукты для рабочих групп отличаются
компактностью, простотой установки и использования, а так же низкими
ценами;
готовые прикладные системы - Oracle Applications. Среди них наиболее
известными являются: Oracle Financial - финансовые, Oracle Manufacturing -
управление производством, Oracle Human Resources - кадры, бухгалтерия;
новые направления. К этой группе можно отнести продукты для работы с
мультимедиа (Media Server, Media Net, Media Objects), средства для работы с
БД по медленным и ненадежным сетям (радиомодемы, телефоны, сотовая
связь) - Oracle Mobile Agents, средства для работы с БД по Internet (WWW
Viewer и WWW сервер).

Коллективная разработка(Enterprise Enabled)

Менеджер общей библиотеки объектов
Центральный репозиторий дизайна приложений
Интерфейсы к широкому спектру продуктов других фирм.
Уникальный графический подход PowerBuilder к разработке поддерживает большие коллективы
разработчиков информационных систем при помощи менеджера общей библиотеки объектов
(Common Object Library Manager) и центрального репозитория дизайна приложений (Central
Application Design Repository). Менеджер библиотеки осуществляет проверку при выдаче и возврате
(check-in/check-out) для предотвращения одновременного обновления одного объекта несколькими
разработчиками, предоставляет возможности поиска в библиотеках, анализирует взаимосвязи, а также
создает подробные отчеты для разработчиков по библиотекам и их компонентам. Менеджер
библиотеки может быть расширен для интеграции с инструментами лидеров CASE-индустрии
популярными системами контроля версий других фирм, таких как PVCS фирмы Intersolv Corporation,
позволяя разработчикам использовать уже сделанные инвестиции в эти продукты.

PowerBuilder также имеет центральный репозиторий дизайна приложений (Central Application Design
Repository), который доступен всему коллективу разработчиков и позволяет им определять
расширенные атрибуты таблиц и столбцов, такие как заголовки и метки. Центральный репозиторий
дизайна позволяет стандартизировать и ускорять процесс разработки приложений.

PowerBuilder - открытая среда разработки, включающая интерфейсы с лучшими представителями
технологии программного обеспечения в среде клиент/сервер. Средства CASE, системы контроля
версий, инструменты соединения узлов, мультимедиа, обработка образов, перьевой ввод, DCE и
многие другие технологии полностью интегрируются при помощи открытого интерфейса API к
библиотекам, разработанным компанией Powersoft.

Компиляторы

Продукт Informix-NewEra содержит два типа компиляторов и, соответственно, два способа сборки
приложений:

Модули NewEra -> файлы с интерпретируемым кодом -> объединенный
файл с интерпретируемым кодом
Модули NewEra -> модули на языке С -> объектные модули ->
выполняемая программа
В ходе разработки и отладки приложений используется первый способ, поскольку компиляция в
интерпретируемый код выполняется быстрее и с ним может работать отладчик. Для изготовления
производственных версий применяется второй способ.

Компоненты диаграммы ERwin и основные виды представлений диаграммы

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

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

Режим "сущности" - внутри прямоугольников отображается имя
сущности (для логической модели) или имя таблицы (для физического
представления модели); служит для удобства обзора большой диаграммы или
размещения прямоугольников сущностей на диаграмме.
Режим "определение сущности" служит для презентации диаграммы другим
людям.
Режим "атрибуты". При переходе от предметной области к модели
требуется вводить информацию о том, что составляет сущность. Эта
информация вводится путем задания атрибутов (на физическом уровне -
колонок таблиц). В этом режиме прямоугольник-сущность делится линией на
две части - в верхней части отображаются атрибуты (колонки), составляющие
первичный ключ, а в нижней - остальные атрибуты. Этот режим является
основным при проектировании на логическом и физическом уровнях.
Режим "первичные ключи" - внутри прямоугольников - сущностей
показываются только атрибуты/колонки, составляющие первичный ключ.
Режим "пиктограммы". Для презентационных целей каждой таблице может
быть поставлена в соответствие пиктограмма (bitmap).
Режим "показ глагольной фразы". На дугах связей показываются
глагольные фразы, связывающие сущности (для логического уровня) или
имена внешних ключей (для физического уровня).
Диаграмма может занимать более чем один экран и более чем один лист при печати. Для обзора
модели предусмотрены, кроме прокруток экрана, режимы уменьшения/увеличения изображения,
отображение всей модели, отображение выделенной части модели.

Концепции INTERNET и INTRANET для создания корпоративных приложений в архитектуре клиент- сервер

Инструментарий компании Borland

Александр Сергеев, Демоцентр клиент-серверных технологий

Концепции построения и реализации информационных систем, ориентированных на анализ данных

А. Сахаров, Oracle

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

Именно на разрешение этого противоречия - отсутствие информации при наличии и даже избытке и нацелена концепция Хранилищ Данных (Data Warehouse). В основе концепции Хранилищ Данных лежат две основополагающие идеи:
Интеграция ранее разъединенных детализированных данных:

-исторические архивы,

-данные из традиционных СОД,

-данные из внешних источников в едином Хранилище Данных, их согласование и возможно агрегация.

Разделение наборов данных используемых для операционной обработки и наборов данных используемых для решения задач анализа.

Автором концепции Хранилищ Данных (Data Warehouse) является Б.Инмон, который определил Хранилища Данных, как: "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины" обеспечивающего менеджеров и аналитиков достоверной информацией необходимой для оперативного анализа и принятия решений.

Наиболее распространённой на сегодня ошибкой, является попытка найти в концепции Хранилищ Данных некий законченный рецепт реализации информационной аналитической системы. Тем более, это не некий готовый программный продукт или некое готовое универсальное решение. Цель концепции Хранилищ Данных - прояснить отличия в характеристиках данных в операционных и аналитических системах, определить требования к данным помещаемым в целевую БД Хранилища Данных, определить общие принципы и этапы её построения, основные источники данных, дать рекомендации по решению потенциальных проблем возникающих при их выгрузке, очистке, согласовании, транспортировке и загрузке в целевую БД.

Предметом концепции Хранилищ Данных являются сами данные.
После того как традиционная СОД реализована и начинает функционировать, она становится ровно таким же самостоятельным объектом реального мира, как и любое, производственный процесс. А данные, которые являются одним из конечных продуктов такого производства, обладают ровно теми же свойствами и характеристиками, что и любой промышленный продукт: сроком годности, местом складирования (хранения), совместимостью с данными из других производств (СОД), рыночной стоимостью, транспортабельностью, комплектностью, ремонтопригодностью и т.д.

И именно с этой точки зрения рассматриваются данные в Хранилищах Данных. То есть, её предметом являются не способы описания и отображения объектов предметной области, а собственно данные, как самостоятельный объект предметной области, порожденной в результате функционирования ранее созданных информационной систем.

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

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



Очевидно, что для определённых классов приложений, это решение вполне корректно. Но следует заранее понимать все ограничения им накладываемые.

Кроме единого справочника метаданных, средств выгрузки, агрегации и согласования данных, концепция Хранилищ Данных подразумевает: интегрированность, не изменчивость, поддержку хронологии и согласованность данных. И если, два первых свойства (интегрированность и не изменчивость) влияют на режимы анализа данных (как будет показано ниже, без интегрированной базы данных, в которой используются специализированные методы хранения и доступа, по крайней мере, сегодня, трудно говорить о реализации интерактивного динамического анализа), то последние два (поддержка хронологии и согласованность), существенно сужают список решаемых аналитических задач.

Без поддержки хронологии (наличия исторических данных) нельзя говорить о решении задач прогнозирования и анализа тенденций. Но наиболее критичными и болезненными, оказываются вопросы, связанные с согласованием данных.

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

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



Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что её реализация практически невозможна без разрешения таких вопросов как:
Неоднородность программной среды.
Распределенность.
Защиты данных от несанкционированного доступа.
Построения и ведения многоуровневых справочников метаданных.
Эффективное хранение и обработка очень больших объемов данных.

Основополагающим отличием Хранилищ Данных от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И практически всегда, конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем) .

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

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



Хранилища Данных уже по своей природе являются распределенным решением.

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

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

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

Наличие развитых средства защиты и ограничения прав доступа.

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


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

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

В таких системах, часто оказывается недостаточно защиты обеспечиваемой в стандартных конфигурациях коммерческих СУБД (обычно уровень защиты по классу "C2 Orange Book".) Региональный менеджер должен видеть только те данные, которые относятся к его региону, а менеджер подразделения не должен видеть данные, относящиеся ко всей фирме. Но, для повышения эффективности доступа к данным, в целевой БД Хранилища Данных, все эти данные, как правило, хранятся в виде единой фактологической таблицы. Следствием этого, является то, что средства реализации должны поддерживать ограничения доступа не только на уровне отдельных таблиц и их колонок, но и отдельных строк в таблице (класс "B1 Orange Book").

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

В заключение хотелось бы остановиться на двух моментах. Во первых, не следует искать в концепции Хранилищ Данных что-то совершенно принципиально новое, о чём не говорилось и не писалось ранее и чему нельзя найти аналогий в прошлом. Её реальное значение состоит в том, что Концепция Хранилищ Данных, составляет: "часть ответа со стороны информационных технологий на вопрос: "Что мы делаем дальше?". И подобно многим новациям в технологиях, этот термин используется для того, чтобы описать обезоруживающую по своей простоте концепцию, которая имеет потенциал развиться со временем во что-то более сложное и значительное ".


И как было показано выше, уже сегодня можно говорить о том, что появление этой концепции послужило серьёзным стимулом для развития внутренней архитектуры современных СУБД, их программного окружения, инструментальных средств конечного пользователя, различных межкорпоративных стандартов.

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

Эффект от правильной организации, стратегического и оперативного планирования развития бизнеса трудно заранее оценить в цифрах, но очевидно, что он в десятки и даже сотни раз может превзойти затраты на реализацию таких систем. Однако не следует и заблуждаться. Эффект обеспечивает не сама система, а люди с ней работающие. Поэтому не совсем корректны декларации типа:система Хранилищ Данных будет помогать менеджеру принимать правильные решения". Cовременные аналитические системы не являются системами искусственного интеллекта и они не могут ни помочь, ни помешать в принятии решения. Их цель своевременно обеспечить менеджера всей информацией необходимой для принятия решения. А какая информация будет запрошена и какое решение будет принято на её основе, зависит только от конкретного человека.

[]
[]
[]

Концептуальное описание предметной области

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

В качестве стандартного средства информационного моделирования в современных CASE-
методологиях используется в том или ином виде аппарат моделей "сущность-связь" или ER-
моделей (Entity Relationship Model). Этот формализм позволяет представлять информационные
потребности в виде, наглядном и удобном для восприятия, что делает их хорошим средством
коммуникации между проектировщиками и пользователями в процессе уточнения постановки
задач.

Теоретической основой этого подхода является известная модель "сущность-связь", введенная
Ченом в 1976 году и получившая широкое развитие и распространение в
качестве средств концептуального проектирования баз данных. В основе модели Чена лежит
представление о том, что предметная область состоит из отдельных объектов, находящихся друг с
другом в определенных связях. Объекты описываются различными параметрами или атрибутами;
однотипные объекты описываются одним и тем же набором параметров и объединяются в
множества или классы; такие классы называются сущностями. Конкретные объекты, составляющие
класс , называются экземплярами соответствующей сущности. Между сущностями
специфицируются взаимосвязи различного вида: один к одному, один ко многим и др.

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

Для наглядного представления общей структуры предметной области все такие спецификации

изображаются в графическом виде - в виде ER-диаграммы. На этой диаграмме объекты
изображаются прямоугольниками, а связи - линиями, соединяющими соответствующие
прямоугольники. Задание типа связи ("один к одному", "многие к одному" и т.д.) означает
введение некоторого семантического ограничения. На диаграмме для каждого типа взаимосвязи
используется свое графическое изображение: если любой экземпляр сущности A может быть связан
с несколькими экземплярами сущности B, то со стороны прямоугольника-сущности A линия,
выражающая взаимосвязь, дополняется специальным символом (рис. 9). Кроме того, для связи
можно указать, является ли она обязательной для входящих в нее сущностей. Если любой
экземпляр сущности A обязательно должен быть связан с каким-либо экземпляром сущности B, то
прилегающая к прямоугольнику "A" половина линии - сплошная, в противном случае она -
пунктирная.

Конфигурации программно-технических средств

Программно-технические средства для реализации распределенных клиент-серверных
приложений, поддерживаемых продуктами Software AG, могут включать в себя следующие
компоненты:


главные ЭВМ (ГЭВМ) верхнего уровня системы (типа IBM mainframe, UNIX-
суперсерверы);
серверные ЭВМ (CЭВМ) среднего и малого классов (UNIX-серверы, OS/2,
Windows NT);
блоковые (типа IBM 3270) и символьные (типа VT 100 или ASCII)
терминалы;
низкопроизводительные ПЭВМ (типа IBM PC/XT/286/386-MS DOS);
высокопроизводительные ПЭВМ (типа IBM PC/486/Pentium-MS Windows,
OS/2);
опорную сеть и протоколы (FDDI/Ethernet и/или TCP/IP, SPX/IPX и др.);
программные продукты других фирм для доступа к базам данных,
обработки и коммуникации, поддерживающие общепризнанные протоколы
межпрограммного взаимодействия и связные протоколы (ORACLE, INFORMIX,
SYBASE, NOVELL, IBM, MICROSOFT и др.).

Корпоративные сети и базы данных

Виктор Олифер, Центр Информационных Технологий
Эпитет "корпоративный" часто используется для характеристики продуктов вычислительных
систем. Корпоративными могут быть названы почти все типы элементов вычислительной системы,
от концентраторов и маршрутизаторов до серверов и операционных систем - разве что сетевые
адаптеры редко удостаиваются такой чести. Эта характеристика также применяется и к системам
управления базами данных : Oracle, Informix, Sybase, DB2 - все это примеры СУБД, которые часто
называются корпоративными. Среди специалистов и производителей существуют различные
толкования этого термина (равно, как и любого другого), поэтому иногда бывает трудно понять,
почему производитель называет свое детище корпоративным, а продукцию конкурентов - нет.
Интуитивно с прилагательным "корпоративный" связывается образ чего-то крупного, мощного,
производительного и надежного. Тем не менее, хочется иметь более твердую почву под ногами, и
основания для этого есть. Имеется несколько устоявшихся признаков корпоративности, и их
можно применять универсально, как к аппаратуре, так и к программным продуктам, в том числе и
базам данных. Наличие этих признаков гарантирует хорошую работу продуктов в корпоративной
сети. Эти признаки тесно связаны с особенностями и спецификой корпоративных сетей, поэтому
для четкого формулирования требований к корпоративным базам данных необходимо ясное
понимание особенностей корпоративных сетей.

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

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

Многие СУБД для достижения высоких эксплуатационных показателей могут подменять и
"исправлять" существующие операционные системы. Например, создавать на свободном разделе
диска файловую систему такой структуры, при которой достигается высокая скорость
специфических для базы данных операций поиска и сортировки записей небольших размеров.
Ускорение достигается за счет специализации функций файловой или операционной систем на
операциях определенного вида.

Аналогичным образом некоторые СУБД поступают и с коммуникационными функциями
операционных систем. Примерами здесь могут служить такие компоненты баз данных как Oracle
SQL*Net или Ingres Net, в которых реализованы популярные транспортные протоколы. Понятно,
что дублирование транспортных функций ОС дополнительными компонентами СУБД происходит
не от хорошей жизни, а от ограниченности сетевых возможностей универсальных операционных
систем: отсутствия тех или иных протоколов или низкоскоростной их реализации.

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

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


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

Итак, что же такое корпоративные сети? В англоязычной литературе этот вид сетей чаще
называется "enterprise-wide networks" (дословно - сеть масштаба предприятия), а в нашей стране
прижился другой термин иностранного происхождения - корпоративные сети, что, на наш взгляд,
больше соответствует самой сути таких сетей. Термин "корпоративная" отражает с одной стороны
величину сети, так как корпорация - это крупное, большое предприятие. С другой стороны, этот
термин несет в себе смысл объединения, то есть корпоративная сеть - это сеть, получившаяся в
результате объединения нескольких, как правило, разнородных сетей. Кроме того, дух
корпоративности - это дух некоего единства, общности, и в этом смысле корпоративные сети - это
сети, в которых неоднородные компоненты живут в счастливом согласии.

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

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


приложений.

Превышение количественными изменениями некоторой критической массы и породило новое
качество - корпоративную сеть.

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

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


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

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


(сегменты). Даже когда сети отделов соединены в корпоративную сеть, большая часть трафика
локализуется в сети отдела, потому что именно в ней выполняется большая часть работы. Как
правило, пользователи в 80% случаев обращаются к локальным ресурсам, а в 20% случаев - к
удаленным ресурсам.

Сети рабочих групп и отделов обычно создаются на основе какой либо одной сетевой технологии -
Ethernet, Token Ring, или, если в рабочей группе происходит обмен большими объемами
информации (например, мультимедийными файлами), то высокоскоростные протоколы, такие как
FDDI, Fast Ethernet или 100VG-AnyLAN.

Такая сеть обычно использует одну или максимум две сетевые ОС. Чаще всего это сеть с
выделенным сервером NetWare 3.x или Windows NT, или же одноранговая сеть, например сеть
Windows for Workgroups. Все пользователи рабочей группы или отдела пользуются СУБД одного
типа, чаще всего настольными СУБД типа dBase, Paradox или FoxPro, пользующимися файловым
сервером для хранения разделяемых данных.

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



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

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

Итак, следующим шагом в эволюции сетей является объединение локальных сетей нескольких
отделов в единую сеть здания или группы зданий. Такие сети называют сетями кампусов. Сети
кампусов могут простираться на несколько километров, но при этом глобальные соединения не
требуются. Сети кампусов имеют позвоночник (backbone) или главную сеть, и подсети,
подобные ребрам. Для повышения производительности предприятия иногда используют
маршрутизаторы, однако чаще подсети присоединяются к позвоночнику с помощью мостов или
быстродействующих многопортовых мостов нового поколения - коммутирующих концентраторов
(switching hubs).

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

Именно на уровне сети кампуса начинаются проблемы интеграции.


В общем случае, отделы уже
выбрали для себя компьютеры и приложения (а, следовательно, и сеть), которые подходят им
наилучшим образом. Однако, то, что подходит отделу продаж, может не подойти, например,
отделу разработчиков. Типы компьютеров, сетевых операционных систем, сетевого аппаратного
обеспечения могут отличаться в каждом отделе. Например, инженерный отдел может использовать
операционную систему UNIX и сетевое оборудование Ethernet, отдел продаж может использовать
операционные среды DOS/Novell и оборудование Token Ring. Очень часто сеть кампуса соединяет
разнородные компьютерные системы, в то время как сети отделов используют однотипные
компьютеры. Часто сети кампусов оказываются соединенными случайным образом. Например, два
отдела, которые работают вместе, могут соединить свои компьютерные системы, а уже затем к ним
захочет присоединиться третий отдел. Отсюда вытекают сложности управления сетями кампусов.
Администраторы должны быть в этом случае более квалифицированными, их нужно специально
обучать. В случае сбоев и отказов администратору уже недостаточно проверить надежность
соединения разъема. Нужны более изощренные средства оперативного управления сетью.

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

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

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


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

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

Важное значение приобретает время реакции приложений в корпоративной сети - при динамичном
рынке для успешной борьбы с конкурентами решения необходимо принимать в реальном
масштабе времени, что требует соответствующей организации корпоративной сети и ее
приложений, в том числе СУБД, способной оперативно отрабатывать запросы к данным
(поддержка режима On Line Transaction Processing, OLTP). В то же время в большой
корпоративной сети обеспечить хорошее время реакции особенно сложно - этому мешает высокая
интенсивность потока запросов, создаваемых сотнями и тысячами сотрудников корпорации,
необходимость производить поиск данных в базах колоссальных размеров, невысокая скорость
глобальных линий связи между отделениями корпорации, замедление скорости взаимодействия в
шлюзах, согласующих неоднородные компоненты различных подсетей. В корпоративных системах
предыдущих поколений с таким положением вещей мирились - особенно крупные базы данных
хранились централизованно на мейнфреймах и обеспечивали доступ к данным в пакетном режиме,
не дающем быстрой реакции на запрос. Теперь же требования работы в реальном времени стали
для корпораций насущной необходимостью и одним из основных требований, предъявляемых к


корпоративным сетям и корпоративным приложениям.

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


масштабируемость, то есть способность одинаково хорошо работать в
большом диапазоне различных количественных характеристик сети,
совместимость с другими продуктами, то есть способность работать в
сложной гетерогенной среде интерсети в режиме plug-and-play.

Очевидно, в корпоративной сети могут использоваться не только продукты класса
корпоративных, но и продукты уровня отделов и рабочих групп. Корпоративные продукты
используются на магистрали сети, там, где они организуют разделение ресурсов между большим
количеством пользователей, в пределе - между всеми пользователями корпорации. Продукты же
рабочих групп предоставляют свои ресурсы в основном только членам своей рабочей группы,
поэтому их производительность, надежность и другие свойства могут быть гораздо более
скромными, чем у корпоративных продуктов. Поэтому в одной и той же сети успешно справляются
со своими обязанностями и СУБД Access компании Micosoft, работающая на 486-х персоналках и
СУБД Oracle, работающая на суперсерверах компаний Digital, Hewlett-Packard или Tricord. Access
обеспечивает, например, разделение данных только для 12 сотрудников небольшого
вспомогательного отдела, а Oracle предоставляет доступ к жизненно важной для корпорации
информации (о выпускаемых ею продуктах, объемах продаж, производственных планах и т.п.) для
всех сотрудников корпорации, в том и для упомянутых сотрудников вспомогательного отдела.
Oracle может выполнить эту задачу, так как является корпоративным продуктом, а Access с ней бы
не справился, так как это продукт уровня рабочей группы, он и не разрабатывался для поддержки
большого числа пользователей и больших массивов данных. Соответственно возможностям
различаются и цены корпоративных продуктов и продуктов рабочих групп.



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

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

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


Но за эти
удобства приходится расплачиваться решением проблем распределенности, репликации и
синхронизации.

В идеале сетевая справочная информация должна быть реализована в виде единой базы данных, а
не представлять собой набор баз данных, специализирующихся на хранении информации того или
иного вида, как это часто бывает в реальных операционных системах. Например, в Windows NT
имеется по крайней мере пять различных типов справочных баз данных. Главный справочник
домена (NT Domain Directory Service) хранит информацию о пользователях, которая используется
при организации их логического входа в сеть. Данные о тех же пользователях могут содержаться и
в другом справочнике, используемом электронной почтой Microsoft Mail. Еще три базы данных
поддерживают разрешение низкоуровневых адресов: WINS - устанавливает соответствие Netbios-
имен IP-адресам, справочник DNS - сервер имен домена - оказывается полезным при подключении
NT-сети к Internet, и наконец, справочник протокола DHCP используется для автоматического
назначения IP-адресов компьютерам сети. Ближе к идеалу находятся справочные службы,
поставляемые фирмой Banyan (продукт Streettalk III) и фирмой Novell (NetWare Directory Services),
предлагающие единый справочник для всех сетевых приложений.

Справочная служба Streettalk уже давно выпускается компанией Banyan и является наиболее
отработанным продуктом этого типа. Многие третьи фирмы купили у компании Banyan лицензию
и используют службу Streettalk в своих системах.

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


пользователя в нескольких справочниках - например, операционной системы, СУБД и почты, что
неминуемо приводит к путанице и головной боли.

Другим характерным примером специфики корпоративных сетей является подход к построению и
поддержке распределенных приложений.

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

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


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

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

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

Поэтому корпоративные приложения эффективнее строить с применением асинхронной связи


между отдельными частями. В этом случае необходимо иметь дополнительную службу
(относящуюся к так называемому классу middleware), которая принимала бы запросы от
клиентской части приложения, вела бы очередь таких запросов (желательно на диске для
повышения отказоустойчивости) и планировала бы загрузку сервера. Асинхронный способ
взаимодействия предъявляет менее жесткие требования к устойчивости физической связи между
клиентом и сервером, что особенно важно для коммутируемых глобальных каналов, которые в
общем случае всегда могут разделять части приложений в корпоративной сети. Примерами
продуктов, которые поддерживают асинхронную передачу сообщений между клиентами и
серверами, являются системы DECmessage Q от Digital Equipment, Message Express от Momentum
Software и Copernicus от New Paradigm Software.

В корпоративных сетях для связи клиентских и серверных частей приложений кроме используются
и ряд других средств, относящихся к классу middleware, а не только упомянутые средства
асинхронной обработки сообщений (message-oriented midleware, MOM). Широко используемые в
сетевых операционных системах и сетевых утилитах средства удаленного вызова процедур RPC
также относятся к классу middleware. Кроме того, в этот класс входят мониторы обработки
транзакций (transaction processing monitors, TP), осуществляющие прием потока запросов
транзакций от клиентов и осуществляют балансировку этих потоков при передаче их на серверы
баз данных, постановку их в очередь, архивацию и восстановление после сбоев. Перспективным,
но пока еще не нашедшими практического воплощения являются средства брокеров запроса
объектов (object request broker, ORB), которые работают подобно средствам асинхронной
обработки запросов, но только с привлечением концепции объектно-ориентированной
технологии.

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


движения на оживленных городских магистралях.

Важную роль в обеспечении необходимых свойств корпоративной сети играет структура
транспортной системы и ее согласованность.

Транспортная система корпоративной сети должна обеспечивать:


передачу пакетов через разнородные сети с совершенно различными
принципами организации транспортных операций,
многоуровневое иерархическое построение (наличие магистрали сети, к
которой присоединяются транспортные артерии нижних уровней),
хорошую структуризацию за счет разделения сети на подсети небольшого
размера с регулярными связями,
поддержку быстрых протоколов, таких как FDDI, Fast Ethernet и 100VG-
AnyLAN, для устранения узких мест.

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

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

К сожалению, существует большого количество протоколов сетевого уровня, равно как и
протоколов канального уровня. Все они решают одну задачу, но несколько разными способами,
поэтому сетевым интеграторам и администраторам приходится в больших сетях иметь дело
одновременно с несколькими сетевыми протоколами. Очень популярными протоколами сетевого
уровня, использующимся для объединения сетей, входящих в корпоративную сеть, является
протоколы IP и Novell IPX.

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


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

В последнее время роль объединяющего протокола сетевого уровня все чаще выполняет сетевой
протокол IP, ведущий свое происхождение от сети Internet и операционной системы Unix. Для
этого протокола существуют стандарты его использования над всеми основными протоколами
канального уровня локальных сетей, таких как Ethernet, Token Ring, FDDI, Fast Ethernet и 100VG-
AnyLAN, а также над протоколами глобальных сетей - X.25, frame relay, PPP. Уже имеется
спецификация для использования IP над протоколами таких перспективных сетей как АТМ - так
называемая спецификацией Classical IP. Важным достоинством IP является его высокая
эффективность при работе на относительно низкоскоростных глобальных линиях связей.
Протокол IPX фирмы Novell был изначально разработан для объединения небольшого числа
локальных сетей, поэтому он расточительно использует полосу пропускания линий связи и не так
хорошо работает на магистралях корпоративных сетей, как IP, хотя Novell в последнее время
предпринимает немало усилий для улучшения своего стека коммуникационных протоколов.

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

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


Масштабные же системы
нужно особенно тщательно планировать и структурировать, выбирая для каждой сети
соответствующие типы кабельных систем, протоколы и устройства соединения сетей -
повторители, мосты, маршрутизаторы и шлюзы.

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

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


Сегментация уменьшает общий сетевой трафик. При достижении
трафиком границы 30%-40% от полной пропускной способности, пользователи
сети Ethernet начинают чувствовать значительное уменьшение
производительности сети из-за постоянных коллизий. В сетях Token Ring также
при достижении трафиком границы 20%-30% от предельной пропускной
способности, конкуренция за доступ к кольцу начинает приводить к заметным
задержкам.
Пользователи взаимодействуют в основном с пользователями и ресурсами
своего отдела. Здесь применимо правило 80/20 - около 80% трафика является
локальным, а 20% идет в удаленные сегменты. Путем сегментации сети на
подсети отделов можно значительно уменьшить трафик, проходящий через
всю сеть, и тем самым повысить производительность сети.
Подсети увеличивают гибкость сети. При построении сети как
совокупности подсетей каждая подсеть может быть адаптирована к
специфическим потребностям рабочей группы или отдела. При этом эти
подсети могут взаимодействовать.
Подсети повышают безопасность данных. Помещая пользователей


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

Сети должны проектироваться на двух уровнях: физическом и логическом. Логическое
проектирование определяет места расположения ресурсов, приложений и способы доступа
пользователей к ресурсам. Физическое проектирование определяет точное задание типов устройств
(марку и модель), мест прокладки кабеля, типов глобальных сервисов (протокол, тип передающей
среды, типы модемов и т.д.). Соотношение между логическим и физическим уровнями
проектирования в некотором смысле аналогично соотношению между функциональной и
принципиальной электрическими схемами. Например, использование повторителя создает в сетях
стандартов 10Base-T, 10Base-F и Token Ring физические сегменты - отрезки кабеля, соединяющие
по схеме "точка-точка" станции. Однако логически эти отрезки представляют по прежнему один
сегмент, моноканал в случае Ethernet'а и логическое кольцо для сетей Token Ring. Применение же
мостов, маршрутизаторов и шлюзов приводит к появлению логических сегментов, локализующих
трафик внутри себя.

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


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

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

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

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


аппаратуры и данных на всех уровнях: кабельных связей, источников питания, процессоров,
компьютеров, маршрутизаторов, репликация баз данных, кластеризация вычислений.

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

Создать крупномасштабную гетерогенную среду для проверки свойств корпоративности не только
сложно, но и накладно. Поэтому существуют специальные лаборатории, которые занимаются
тестированием и сертификацией продуктов на предмет пригодности их для работы в
корпоративной сети. В частности, такие услуги и потребителям и производителям оказывает
американская фирма The Tolly Group, которая с помощью специального оборудования может
создавать сложную гетерогенную среду, соответствующую требованиям заказчика, и испытывать в
ней новое оборудование или программную систему. Клиентами The Tolly Group являются и
компании-призводители, заинтересованные в получении лого "Enterprise Ready", причем не только
новички, завоевывающие рынок, но и такие гранды как Cisco, IBM, Motorola-Codex, 3Com,
Wellfleet и многие другие.

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

[]
[]
[]

Краткое описание методики и состава работ по предпроектному обследованию

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

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




Проект базы данных корпоративной информационной системы предприятия:





Конфигурация вычислительной сети:

Предложения по набору программно-технических средств:
Операционные системы:
Семейство сетевых ОС корпорации Novell основано на
концепции интегрированной вычислительной архитектуры (NICA - Novell
Integrated Computing Architecture), которая позволяет создать открытую
сетевую среду, интегрирующую ресурсы серверов, настольных компьютеров,
больших и мини- ЭВМ и поддерживающую на рабочих станциях разные
операционные системы: Windows, DOS, OS|2, UNIX, Macintosh;

Microsoft Windows NT характеризуется приоритетной
многозадачностью, встроенной сетевой поддержкой, защищенностью,
многопоточностью, поддержкой широкого спектра компьютерных платформ,
симметричной мультипроцессорной обработки и т.д.;
SCO Open Server обеспечивает возможность работы до 30
процессоров и хорошую отказоустойчивость при выполнении
клиент/серверных приложений.
SCO UnixWare 2.1 основана на самой современной версии
ядра UNIX - System V UNIX, имеет отказоустойчивую файловую систему,
обеспечивает интеграцию с TCP/IP и NetWare рабочими средами.
Средства построения сетей:
сетевое оборудование Cabletron, Bay Networks, 3Com, Chipcom;
высококачественные Brand Name компьютеры фирм Compaq,
Gateway, Tricord для серверов и рабочих станций.
Средства программирования:
Centura Team Developer - мощная среда разработки
приложений, обеспечивающая широкие возможности масштабирования
приложений и интеграцию корпоративных систем с Internet;
Centura Ranger - сервер баз данных, реализующий средства
универсальной репликации данных;
Centura Web Data Publisher - система, обеспечивающая
эффективную и безопасную передачу данных через Internet;
Centura Application Server - система, обеспечивающая
возможности разделения приложенийCentura
Системы управления базами данных:
SQLBase Server - новая версия сервера реляционных баз
данных, включающая средства репликации данных;
семейство Sybase SQL Server - семейство серверов,
ориентированных на задачи, связанные с быстрой обработкой транзакций в
реальном масштабе времени, с системами принятия решений, обслуживанием
большого числа пользователей и т.д.;
Microsoft SQL Server - специально разработан для систем с
распределенной обработкой данных;
Informix Universal Server Engine - поддерживает
разнообразные типы данных и предусматривает возможность расширения,
через интерфейс АPI работает с DataBlade-модулями;
Oracle Server - универсальный сервер, поддерживающий
распределенные базы данных, параллельные системы, а также включающий
новые средства поддержки хранилищ данных.
Предложения по использованию и разработке прикладных программ.
href="../../pictures/it/ofis96/133_13.gif">рис.~300K

Компания ЭЛКО Технологии готова по заказам пользователей выполнить программные
проекты любой степени сложности. Мы принимаем на себя ответственность за выполнение всех
требований заказчика, за эффективное функционирование и развитие систем.

[]
[]
[]

Критерии выбора

Традиционно при обсуждении проблемы выбора СП (в особенности CASE-средств) большое
внимание уделялось особенностям реализации той или иной методологии анализа предметной
области (E-R, IDEF0, IDEF1Х, Gane/Sarson, Yordon, Barker и др.). Безусловно, богатство
изобразительных и описательных средств дает возможность на этапах стратегического
планирования и анализа построить наиболее полную и адекватную модель предметной области. С
другой стороны, если говорить о конечных результатах - базах данных и приложениях, то
обнаруживается, что часть описаний в них практически не отражается, оставаясь чисто
декларативной (на выходе мы в любом случае получим описание БД в табличном представлении с
минимальным набором ограничений целостности и исполнимый код приложений, большую часть
которых составляют экранные формы, не выводимые непосредственно из моделей предметной
области). Опытные аналитики и проектировщики всегда с большими или меньшими
трудозатратами придут к нужному конечному результату независимо от того, какая конкретно
методология или ее разновидность реализована в данном инструменте. Это, конечно, не означает,
что методология не важна, напротив, отсутствие или неполнота описательных средств могут с
самого начала значительно затруднить работу над проектом. Однако, зачастую на первом плане
оказываются другие критерии, невыполнение которых может породить гораздо большие
трудности.

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


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

Поддержка полного жизненного цикла ИС с обеспечением эволюционности ее
развития.

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


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

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

Обеспечение целостности проекта и контроля за его состоянием.

Данное требование означает наличие единой технологической среды создания, сопровождения и


развития ИС, а также целостность базы проектных данных (репозитория). Единая технологическая
среда должна обеспечиваться за счет использования единственной CASE-системы для поддержки
моделей ИС, а также за счет наличия программно-технологических интерфейсов между
отдельными инструментальными средствами, сертифицированных и поддерживаемых фирмами-
разработчиками соответствующих средств. В частности, интерфейс между CASE-системой и
средствами разработки приложений должен выполнять две основные функции: а)
непосредственный переход в рамках единой среды от описания логики приложения,
реализованного CASE-системой, к разработке пользовательского интерфейса (экранных форм); б)
перенос описания БД из репозитория CASE-системы в репозиторий средства разработки
приложений и обратно. Вся информация о проекте должна автоматически помещаться в базу
проектных данных, при этом должны поддерживаться согласованность, непротиворечивость,
полнота и минимальная избыточность проекта, а также корректность операций его
редактирования. Это может быть достигнуто при условии исключения или существенного
ограничения возможности актуализации репозитория различными средствами. Должны также
обеспечиваться возможности для централизованного сбора, хранения и распределения
информации между различными этапами проекта, группами разработчиков и выполняемыми
операциями. Поддержка базы проектных данных может быть реализована собственными
средствами СП или средствами целевой СУБД (второй вариант предпочтительнее, поскольку
упрощается технология ведения репозитория).

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

Независимость от программно-аппаратной платформы и СУБД.

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


различных платформ и драйверов соответствующих сетевых протоколов, менеджеров транзакций
и СУБД.

Один из дополнительных факторов, который при этом следует учитывать - это способ
взаимодействия с СУБД (прямой или через ODBC), поскольку использование ODBC может
заметно ухудшить производительность и надежность интерфейса.

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

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

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

Возможность разработки приложений "клиент-сервер" требуемой конфигурации.

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


эффективность функционирования приложения в целом, а также возможность использования
сервера приложений (менеджера транзакций).

Открытая архитектура и возможности экспорта/импорта.

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

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

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

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

Что касается стоимости, следует учитывать возможность получения бесплатной пробной лицензии
(trial license), стоимость лицензии на одно рабочее место СП, скидки, предоставляемые фирмой в случае приобретения большого количества лицензий, необходимость приобретения run-time версий для эксплуатации приложений и т.д.


В то же время стоимость продукта должна рассматриваться не сама по себе, а с учетом ее соответствия возможностям продукта.

Простота использования.

Учитываются следующие характеристики:


доступность пользовательского интерфейса;
время, необходимое для обучения;
простота инсталляции;
качество документации.

Обеспечение качества проектной документации.

Это требование относится к возможностям СП анализировать и проверять описания и
документацию на полноту и непротиворечивость, а также на соответствие принятым в данной
методологии стандартам и правилам (включая ГОСТ, ЕСПД). В результате анализа должна
формироваться информация, указывающая на имеющиеся противоречия или неполноту в
проектной документации. Должна быть также обеспечена возможность создавать новые формы
документов, определяемые пользователями.

Использование общепринятых, стандартных нотаций и соглашений.

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

В идеальном случае (что, конечно же, далеко не всегда возможно) окончательный выбор может
быть произведен по результатам тестирования в соответствии с заданным планом, которое должно
включать имитацию проектирования реальной БД и разработки приложений и состоять из
следующих шагов:


установка и конфигурирование (ясность и точность инструкций по
установке, наличие подсказок в процессе установки, возможность установки по
выбору и задания многопользовательской конфигурации);
разработка концептуальной схемы БД (понятность и простота


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

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

Курсоры

Контакт клиента с сервером SQLBase является постоянным. Сеанс контакта с базой данных
инициируется клиентом с помощью команды CONNECT и прекращается командой
DISCONNECT. Во время сеанса клиент выпускает одну или несколько транзакций к базе данных.
SQLBase относится СУБД транзакционного типа, основанного на концепции курсоров (cursor) в
отличие от технологии процессов базы данных (db-process).

Курсор в SQLBase имеет много самых разных значений. Прежде всего, курсор - это идентификатор
контакта пользователя с базой данных (или административного контакта с сервером SQLBase).
Далее, с курсором связаны скомпилированные запросы на языке SQL, извлеченные из базы данных
и подготовленные к выполнению хранимые команды и процедуры, а также полученные в
результате выполнения запросов, команд и процедур множества результатов (result sets). Наконец,
курсор также определяет положение (строку) в текущем result set'е, обрабатываемым клиентским
приложением.



В SQLBase, так же как и в Oracle, не существует специальной команды, определяющей начало
транзакции подобно BEGIN WORK или BEGIN TRANSACTION. Транзакция автоматически
начинается с первого запроса к базе данных, последовавшего за окончанием предыдущей
транзакции. Для указания окончания транзакции служат команды, приведенные на рис. 4.

Рис. 4. Команды окончания транзакции SQLBase

Команда
Описание

ROLLBACK	Неудачное окончание транзакции. Изменения не записываются в базу данных. Блокировки, связанные с данной транзакцией сбрасываются.
COMMIT	Удачное окончание транзакции. Изменения записываются в базу данных. Блокировки, связанные с данной транзакцией сбрасываются.
SAVEPOINT	Удачное окончание части длительной транзакции. Частичные изменения записываются в базу данных. Эта команда используется во время длительных транзакций (например, ввода большого количества данных) для фиксации прохождения некоторого этапа. Если при дальнейшей обработке транзакции произойдет ее откат (ROLLBACK), все изменения, сделанные до последней команды SAVEPOINT, останутся в базе данных.

<
SQLBase поддерживает именованные и распределенные транзакции. Именованные транзакции
позволяют объединять несколько курсоров от одного клиента в процесс, изолированный от других
процессов в той же базе данных. Это позволяет организовать работу клиента с базой
одновременно в нескольких режимах. Например, клиент может выделить в своем приложении 2
именованные транзакции "Проводка" и "Баланс". При этом ошибка выполнения запроса по
одному из курсоров транзакции "Проводка" приведет к откату только этой транзакции и не
окажет никакого действия на курсоры транзакции "Баланс".

Описание распределенных курсоров приведено ниже в разделе "Распределенные базы
данных".

Существует также разделение курсоров по объекту контакта.

Курсоры базы данных используются для выполнения запросов к базе данных (предложений
SELECT, INSERT, UPDATE, DELETE), а также выполнения команд конфигурирования базы
данных (CREATE, ALTER, DROP, GRANT, REVOKE и т.д.).

Курсоры сервера применяются для операций, непосредственно связанных с функционированием
сервера SQLBase. К ним относятся процедуры архивирования и восстановления (BACKUP и
RESTORE), команды создания, активизации и удаления баз данных (CREATE DATABASE, DROP
DATABASE, INSTALL DATABASE, DEINSTALL DATABASE), а также команды, изменяющие
параметры и режимы работы SQLBase в целом.

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

Литература

1. Date C.J. 1987. What is distributed database? InfoDB, 2:7

2. Г.М.Ладыженский. Технология "клиент-сервер" и мониторы транзакций. "Открытые



Г. Барон. Параллельные архитектуры серверов баз данных. Jet Info, Вып. 1, 1995.

Н. Вьюкова. Архитектура сервера INFORMIX-OnLine Dynamic Server 7.1 и
коммуникационные средства. Jet Info, Вып. 2, 1995.

Н. Вьюкова. Сервер для кластерных и массово-параллельных архитектур. Открытые системы,
N 4, 1995.



[]
[]
[]






К.Дэйт. Руководство по реляционной СУБД DB2., М.: Финансы и статистика, 1988.
Г.Буч. Объектно-ориентированное проектирование с примерами применения.
М.: Конкорд, 1992.
T.Moynihan. Objects Versus Functions in User-Validation of Requirements: Which Paradigm Works
Best? Proceedings of the International Conference on Object Oriented Information Systems, 1994.
Object Oriented Applications Using Relational Databases/ IBM International Technical Support
Centers, 1994.
IBM White Pare. Object Support and the DB2 Family. Data Management Solutions, 1994/
К.Вон. Технология объектно-ориентированных баз данных. Открытые системы, осень 1994.
Sean Brady. DB2 V2 Technical Overview/ Proceedings of the IDUG 4th Annual Conference, 1995,
V.1, p.145.


[]
[]
[]






Barker, R. (1990). CASE*Method Entity Relationship Modelling. Wokingham, England, Addison-
Wesley.
Barker, R. and Longman, C. (1993). CASE*Method Function and Process Modelling. Wokingham,
England, Addison-Wesley.
Barker, R. et al. (1990). CASE*Method Tasks and Deliverables Modelling. Wokingham, England,
Addison-Wesley.
Barker, R. and Clegg, D. (1994). CASE*Method Fast-Track A RAD Approach. Wokingham,
England, Addison-Wesley.
Hickman, L. and Longman, C. Foreword by Barker, R.(1994). CASE*Method Business Interviewing.
Wokingham, England, Addison-Wesley.
Hammer, M. and Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business
Revolution. Harper Collins, New York.
Chen, P.P. (1976). The Entity-Relationship Model: Toward a Unified View of Data. ACM
Transactions on Database Systems N1


[]
[]
[]





А.Закис, М.Макаров, Н.Приезжий. Применение интегрированной CASE-технологии фирмы
Wesmount для разработки информационных систем. DBMS/RE, #2, 1995.
А.М.Вендров. Один из подходов к выбору средств проектирования баз данных и приложений.
СУБД, #3, 1995.
E. Yourdon & L.L. Constantine. Structure Design, Fundamentals of a Discipline of Computer Program
and System Design. Yourdon Press, Englewood Cliffs, 1979.
P.P. Chen (editor). Entity Relationship Approach to System Analysis and Design. North
Holland Publishing Company, 1980.

[]
[]
[]

Менеджер Переводов (Translation Manager)

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

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

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

Использование Менеджера Переводов - это еще один пример того, как обеспечивается полная
поддержка всех этапов разработки приложений в среде PROGRESS.

Место SQL Anywhere среди СУБД для рабочих групп

Нам было особенно интересно изучить новую версию Watcom SQL после работы с продуктами
фирмы Sybase (система 10) и знакомства с Microsoft SQL 6.0. На наш взгляд, новой версии SQL
Anywhere 5.0 приданы все качества СУБД для рабочих групп, какие существуют на сегодняшний
день у конкурентов, и кое-что еще, делающее этот продукт технически лидером - собственная
система репликации, основанная на механизме передачи сообщений и электронной почте.

С другой стороны, SQL Anywhere подкреплен совместимостью с линией продуктов Sybase System
11, характеристики которой рассматривались недавно в ComputerWorld и PC Week href="#lit">[4].

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

Методологические основы проектирования

Е. Ойхман, О. Евсеев, С. Паронджанов, Компания Аргуссофт (Москва)

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

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

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

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

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

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


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

Подход основан на использовании мощных средств для построения моделей: CASE-средств для построения статических моделей и автоматизации моделирования функций, данных и структуры организации и информационной системы, и интеллектуальных средств для построения динамических моделей организации и информационной системы и проведения динамического моделирования процессов.

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

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

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

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



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

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

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


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

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

Наиболее мощными инструментальными средствами такого типа являются: динамическая интеллектуальная система G2 фирмы Gensym (USA) и ее дочерняя моделирующая система ReThink. Эти средства позволяют преодолеть основные трудности, связанные с размерностью задач моделирования крупномасштабных организаций, и обеспечивают пользователю следующие важные преимущества:

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


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

В качестве методической основы для проектирования динамических интеллектуальных моделей сложных систем используется объектно-ориентированный подход. В докладе рассматривается также пример построения моделей описанного вида для задач моделирования процессов оказания услуг по перевозке грузов клиентам железнодорожного транспорта.

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

Телефоны авторов: 288-24-36, 288-10-90

[]
[]
[]

Методология DATARUN

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

Создание сложной информационной системы невозможно без единого интегрированного подхода к
процессу разработки. Такой подход часто оформляется в виде коммерчески доступной методологии
проектирования. Методология служит двум целям: 1) обеспечивает концептуальную основу для всего
процесса разработки; 2) предоставляет технологию руководства проектом.

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

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

Методология DATARUN ведет заказчика и разработчика информационной системы по всем этапам

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

Методология DATARUN обеспечена средствами автоматизированной поддержки:

Для управления проектной деятельностью имеется система Software
Engineering Companion, позволяющая детально расписывать ведение проекта,
распределять проектные роли среди исполнителей, контролировать выполнение
заданий.
Детальное изложение техник моделирования данных и бизнес-функций,
проектирования баз данных, создания приложений содержится в гипертекстовой
системе Software Engineering Guidelines.
Автоматизация проведения проектных работ обеспечивается CASE-системой
SILVERRUN.
Предоставляемая этими средствами среда проектирования дает возможность руководителю проекта
контролировать выполнение работ. Каждый участник проекта, подключившись к системе, может
уточнить содержание и сроки выполнения порученной ему работы, изучить технику ее выполнения в
гипертексте по технологиям, и вызвать инструмент (модуль SILVERRUN) для реального выполнения
работы.

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

Методология DATARUN и CASE-система SILVERRUN

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

Microsoft SQL Server

Д.Артемов, Microsoft
Подобно тому как Windows NT является базовой операционной системой, на которой работают
приложения BackOffice, Microsoft SQL Server для Windows NT является основным средством
обработки больших объемов информации в масштабе предприятия. Новая версия SQL Server
значительно расширена для повышения производительности СУБД, упрощения
администрирования, повышения надежности и скорости обработки данных.

Microsoft SQL Server Distributed Management Framework (SQL- DMF)

С появлением SQL Server 6.0 Microsoft предложил на рынке сервер с масштабируемой
архитектурой управления, наиболее оптимальным образом подходящей к быстро меняющимся
задачам, которые встают перед системами архитектуры клиент-сервер. Microsoft SQL Server
Distributed Management Framework (SQL-DMF) имеет трехуровневую объектно- ориентированную
архитектуру, которая предоставляет компоненты, сервисы и инструментарий, необходимые для
управления распределенными серверами в масштабе предприятия.(Рис.5)

Middleware: модель сервисов распределенных систем

Г. Ладыженский, Jet Infosystems системы ()

Сообщение подготовлено на основе концепции, изложенной в статье Филиппа Бернштейна (Philip A.Bernstein) "Middleware - A model for Distributed System Services", напечатанной в журнале Communications of the ACM (February 1996 - Volume 39, Number 2), а также собственных соображений и опыта работы автора.













Middleware: основные понятия

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

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

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

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

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

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

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

Другой способ, применяемый производителями для разрешения проблемы разнородности - поддержка стандартных протоколов. Стандартные протоколы делают возможным взаимодействие программ. Говоря о взаимодействии (interoperate), мы имеем в виду, что программа в составе одной системы имеет доступ к программам и данным в составе другой системы.


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

Чтобы помочь потребителям решить проблемы разнородности и распределенности и сделать возможной реализацию информационных служб, производители предлагают сервисы распределенной системы которые обладают стандартными программными интерфейсами и протоколами. Такие сервисы называются сервисами промежуточного (среднего) слоя (middleware services), поскольку располагаются "в середине", занимая промежуточный уровень между операционными системами и сетевым программным обеспечением с одной стороны, и приложениями, ориентированными на конкретную прикладную область - с другой стороны.

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

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

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



Для многих приложений программный интерфейс, предоставляемый ПО промежуточного слоя, фактически определяет вычислительную среду. Например, многие приложения трактуют таким образом языки четвертого поколения (4GL), мониторы обработки транзакций (TP) (IBM CICS, Digital ACMSxp), и офисные интегрированные системы ( Lotus Notes, LinkWorks).

Унаследованные приложения (legacy applications), разработанные еще до того, как мобильное ПО промежуточного слоя стало фактическим стандартом, также могут воспользоваться его сервисами. Можно определить унаследованное приложение как набор функций и воспользоваться коммуникационными сервисами ПО промежуточного слоя для обеспечения удаленного доступа к этим функциям. Для этой цели можно, например, воспользоваться реализацией Common Object Request Broker Architecture (CORBA) консорциума Object Management Group (OMG).

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

Сервисы ПО промежуточного слоя

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

Сервис ПО промежуточного слоя (middleware service) - сервис общего назначения, который располагается между платформами и приложениями ().


Под платформой мы подразумеваем набор низкоуровневых сервисов и элементы обработки, определяемые парой: архитектурой процессора и API операционной системы, например, Intel x86 и Win32, Sun SPARCstation и SunOS, IBM RS/6000 и AIX, Alpha AXP и OpenVMS, или Alpha AXP и Windows NT.

Рис.1. Программное обеспечение промежуточного слоя

Сервис ПО промежуточного слоя определяется интерфейсами прикладного программирования и протоколами, их поддерживающими. Сервис может иметь множество реализаций, соответствующих спецификациями его интерфейса и протокола, как, например, различные реализации DCE RPC и протокола IBM 3270. Как и многие системные категории, ПО промежуточного слоя трудно точно определить в техническом смысле. Тем не менее, компоненты ПО промежуточного слоя обладают рядом свойств, которые, взятые в совокупности, свидетельствуют о том, что данный компонент не является сервисом, специфичным для приложения или платформы. Компоненты ПО промежуточного слоя являются общими для различных приложений и прикладных областей; они функционируют на разных платформах, распределены и поддерживают стандартные интерфейсы и протоколы. Ниже мы опишем каждое из этих свойств.

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

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


Многие программные продукты из семейства реляционных СУБД работают на нескольких платформах. Напротив, файловые системы рассматриваются как специфический сервис платформы.

Если сервис является распределенным, это также усиливает интероперабельность, поскольку приложения на разных платформах могут использовать его для коммуникаций и/или обмена данными. Чтобы охватить как можно больше платформ, сервисы ПО промежуточного слоя разрабатывается как переносимые (portable). Это означает, что их можно перенести (портировать) на другую платформу, предприняв при этом небольшие и заранее предсказуемые действия.

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

В идеале, сервис ПО промежуточного слоя поддерживает стандартный протокол (например, TCP/IP или семейство протоколов ISO OSI), или, по крайней мере, опубликованный протокол (например, SNA LU62 корпорации IBM). Таким образом можно разработать множество реализаций сервиса, и все они будут взаимодействовать между собой. Однако, если сервис ПО промежуточного слоя действительно работает на всех популярных платформах, его можно рассматривать как стандартный, даже если его протоколы не опубликованы. Такое свойство имеет, например, большинство СУБД.

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



Если производитель ПО обеспечивает широкий охват платформ и обладает значительной долей рынка, то поддерживаемый им API и протокол можно рассматривать как фактический стандарт, даже если ни API, ни протокол не поддерживают другие производители. Например, в реляционных СУБД ORACLE и SYBASE поддерживаются собственные диалекты языка SQL, и даже при этом рассматриваются большинством потребителей как фактический стандарт. Аналогично монитор обработки транзакций CICS корпорации IBM использует собственные API и протокол (LU6.2), и, тем не менее, является фактическим стандартом.

Вопрос о том, относится ли данный сервис к ПО промежуточного слоя, со временем решается по-разному. Компонент, который в данный момент рассматривается как часть платформы, может в будущем стать ПО промежуточного слоя. В результате реализация ОС упростится, а сервисы, предоставляемые данным компонентом, станут общедоступными для всех платформ. Например, мы рассматривали традиционную файловую систему как стандартный компонент операционных систем, каковой она несомненно была во всех коммерческих ОС, разработанных до 1980 года. Однако сегодня мы часто рассматриваем файловую систему как ПО промежуточного слоя - имея в виду, например, реализации, соответствующие стандарту API X/Open C-ISAM.

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

Ввиду того значения, которое имеют стандартные интерфейсы для переносимости приложений, а стандартные протоколы - для их взаимодействия, По промежуточного слоя стало объектом усилий по стандартизации. Некоторые из них были предприняты организациями, вырабатывающими стандарты - например, ISO и ANSI, некоторые - консорциумами производителей, такими как X/Open, OSF и OMG, а некоторые спонсировались компаниями, имеющими значительную долю рынка ПО - например, архитектура Windows Open Services Architecture (WOSA) стала результатом усилий корпорации Microsoft.


Иногда отдельный сервис получает гигантское распространение и поэтому становится фактическим стандартом, как, например, PostScript (Adobe), монитор транзакций CICS (IBM) и Network File Service (Sun Microsystems).

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

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

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


Некоторые из них недоступны на многих популярных платформах, что ограничивает потребителя в выборе платформ и сужает его возможности при работе в неоднородных системах. Это замечание относится, например, к реляционным СУБД Rdb корпорации Oracle (ранее система принадлежала DEC) и DB2 (IBM).

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

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

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



Интегрированная среда

Интегрированная среда (framework) - это среда программирования, которая спроектирована с целью упрощения разработки и управления приложениями для домена специализированных приложений (). Интегрированная среда (ИС) определяется интерфейсом прикладного программирования, интерфейсом с пользователем и инструментарием. В дополнение к сервисам ПО промежуточного слоя, которые ИС импортирует из других продуктов, она может также включать собственные сервисы. Приведем примеры ИС. Это - так называемые офисные системы (Lotus Notes, Microsoft Office, DEC LinkWorks), мониторы транзакций (IBM CICS, DEC ACMSxp, BEA Systems Tuxedo, Transarc Encina), языки четвертого поколения (Uniface, Cognos и Focus), системы автоматизированного проектирования (Mentor Graphics Falcon, DEC Powerframe), CASE-системы (HP SoftBench, Texas Instrument Composer, Anderson Consulting Foundation, DEC COHESIONworX), и системы управления распределенными ресурсами (HP OpenView, Tivoli Management Environment, IBM NetView).

Рис.2. Интегрированная среда

ИС - это один из видов ПО промежуточного слоя.

Иногда сервисы ПО промежуточного слоя расширяются до масштабов ИС. Так произошло с инструментарием для работы с реляционными СУБД. Иногда набор сервисов интегрирован в такой степени, чтобы фактически превращается в ИС. Например, в OSF DCE интегрированы сервис RPC, сервис имен, сервис аутентификации, служба времени, сервис идентификации и файловый сервис. Отметим, что в DCE нет как такового обобщенного интерфейса пользователя, и весь интерфейс прикладного программирования DCE - это, собственно, API упомянутых выше сервисов. Тем не менее, DCE поддерживает контекст вызовов (по идентификатору пользователя), и обеспечивает прозрачный вызов сервисов для упрощения некоторых операций.

Поскольку ИС опирается на сервисы ПО промежуточного слоя, постольку ИС является потребителем услуг ПО промежуточного слоя. Точно также приложение, которое опирается на ИС, является ее клиентом, и, опосредовано - потребителем сервисов ПО промежуточного слоя.


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

Один из методов, при помощи которого упрощается API ИС - сохранение контекста вызова различных сервисов. Например, в большинстве ИС вызовы сервисов требуют в качестве параметров идентификатор пользователя (для контроля доступа) и идентификатор устройства (для установления связи). ИС трактует эти идентификаторы как контекст приложения, но не как параметры, упрощая таким образом API. Например, CASE-система COHESIONworX поддерживает контекст, включающий имя пользователя, имя дисплея и рабочую область, содержащую каталоги файлов и указатели на объекты. Поддержка контекста не является уникальным свойством ИС. Сервис тоже может поддерживать контекст, хотя этот контекст обычно бывает локальным по отношению к данному сервису. Например, DCE RPC сохраняет идентификатор пользователя между вызовами RPC.

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

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

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


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

Мониторы обработки транзакций

Для иллюстрации концепции ПО промежуточного слоя, рассмотрим один из видов ИС - мониторы обработки транзакций (Transaction Processing Monitor - TPM). Основная функция TPM - это управление потоком запросов между терминалами или другими устройствами и прикладными программами, которые могут обрабатывать эти запросы. Запрос (request) - это специфическое сообщение, инициирующее выполнение транзакции. Приложение, которое выполняет транзакцию, обычно получает доступ к менеджерам ресурсов, например, к СУБД. Типичный TPM включает функции управления транзакциями, средства для организации межпроцессного взаимодействия, средства управления очередями запросов и средства управления формами и меню ().

Рис. 3. Архитектура монитора обработки транзакций

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

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

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


Менеджер распределенных очередей обеспечивает гарантированную передачу запросов из одной очереди в другую.

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

Делаются попытки стандартизации API и протоколов всех описанных выше сервисов. Так, например, консорциум X/Open работает над стандартами API для управления транзакциями и коммуникациями (стандарт X/Open ATMI - Application - Transaction Management Interface), а ISO - над стандартным протоколом для управления очередями.

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

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

TPM обычно включает инструментарий прикладного программирования. Например, в него может входить словарь данных, используемый менеджером форм, приложениями и СУБД. Digital использует для этой цели собственный словарь данных Common Data Dictionary/Repository (для интеграции TPM ACMS, реляционной СУБД Rdb, менеджера форм DECforms).



TPM также включает средства системного управления и мониторинга. Они позволяют отображать состояние транзакции или запросов, следить за показателями производительности системы и настраивать ее параметры. Функции управления и мониторинга могут быть реализованы в обособленной ИС. Она объединяет средства управления и мониторинга TPM и средства управления платформой и СУБД. Тогда мы имеем единообразный способ мониторинга и контроля за всеми доступными ресурсами.

Интеграция сервисов ПО промежуточного слоя

Один из способов придания дополнительных потребительских качеств сервисам ПО промежуточного слоя - заключается в их интеграции. Интегрированную систему от простой коллекции общесистемных сервисов отличает то, что в ИС они хорошо работают вместе. Деятельность по созданию такой интегрированной системы из независимо разрабатываемых элементов-частей называется системным проектированием (system engineering).

Допустимы самые различные критерии оценки приложений и ПО промежуточного слоя и вообще программных систем. Среди них - удобство в использовании, степень распределенности и интегрируемости, соответствие стандартам, расширяемость, возможности интернационализации, управляемость, производительность, переносимость, надежность, масштабируемость и безопасность. Мы называем эти параметры общими свойствами системы (pervasive attributes), поскольку они применимы ко всей системе в целом, а не только к ее компонентам.

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

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


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

Тенденции

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

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

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

[]
[]
[]

Моделирование, анализ и реорганизация деловой деятельности

Средства анализа деловой деятельности - новый компонент, не имеющий аналогов в предыдущих
версиях CASE - продуктов фирмы ORACLE. Он предназначен для описания и анализа
деятельности организации или компании, визуального представления основных технологических
процессов, способов коммуникации и т.п. Включение этого компонента в общую интегрированную
среду DESIGNER 2000 связано с быстро развивающимся в последние годы новым направлением
менеджмента, известным под названием анализ и реорганизация деловой деятельности (Business
Process Reengineering).

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

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

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

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

базовый процесс; шаг процесса; поток данных; хранилище данных; организационная единица;

Моделирование данных

В процессе первичного анализа данных, собранных из разных источников, необходимо выявить основные
информационные понятия (сущности) и их взаимосвязи. Эта деятельность поддерживается модулем ERX, в
который встроена экспертная система, помогающая реструктурировать "сырую" информацию и привести
ее к виду, допускающему реализацию в реляционной СУБД. На рис. 2 показана структура данных, а нa
рис. 3 - модель "сущность-связь" в третьей нормальной форме, автоматически
построенная модулем ERX из этой структуры и нормализованная в процессе ответов пользователя на
задаваемые системой вопросы.

На рис. 4 показана созданная в ERX модель, перенесенная в модуль
реляционного моделирования RDM и доработанная для непосредственной реализации в реляционной базе
данных. В нижней части символов таблиц показаны действия над записями. В генерируемой мостом схеме
базы данных это будут соответствующие триггеры. А три колонки справа от имен столбцов таблиц
отражают действия, производимые над этими столбцами при операциях считывания, присваивания и
модификации значений. Также можно определять глобальные действия на уровне всей модели (в схеме
базы данных - хранимые процедуры). Таким образом достигается не только определение конструкций
реляционной СУБД, но и объектно-ориентированное расширение реляционной модели.

Data structure
Name : Заказ
Composition :
Заказ Номер
Заказ Дата
Покупатель Имя
Покупатель Адрес
Продукт
Продукт Название
Продукт Цена
Продукт Количество
Продукт Стоимость
Заказ Стоимость
Рис. 2. Структура данных, на основе которой будет строится
ER-модель

---

---