© 1995-2021 Компания «Инфосистемы Джет»
Объектные технологии построения распределенных информационных систем
Программное обеспечение

Программное обеспечение Тема номера

Объектные технологии построения распределенных информационных систем

18.12.1997

Посетителей: 264

Просмотров: 240

Время просмотра: 4.5 мин.

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

 

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

 

Основные принципы структурного подхода

 

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

 

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

 

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

 

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

 

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

 

Концепции и принципы объектного подхода

 

Классы и объекты

 

Основные понятия объектно-ориентированного подхода - объект, класс и экземпляр.

 

Объект — это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Объект представляет собой типичный неопределенный элемент такого множества. Экземпляр объекта — это конкретный определенный элемент множества. Например, в банковском деле объектом является некоторый лицевой счет, а экземпляром этого объекта — лицевой счет №123.

 

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

 

Таким образом, объект — это типичный представитель класса, а термины экземпляр объекта и элемент класса равнозначны.

 

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

 

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

 

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

 

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

 

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

 

Особенности применения объектного подхода

 

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

 

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

 

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

 

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

 

 

Рисунок 1. Отношение между классами, объектами и предметами реального мира.

Объектные распределенные технологии на основе спецификаций консорциума OMG

 

Две рассмотренные выше концепции — объектно-ориентированный способ разработки и распределенные вычисления — стали основными предметами внимания для созданного в апреле 1989 года консорциума Object Management Group (OMG), членами которого сейчас являются более 500 ведущих компьютерных компаний, таких как Sun, DEC, IBM, HP, Motorola и др. Задачей консорциума является разработка спецификаций и стандартов, позволяющих строить распределенные объектные системы в разнородных средах. Основополагающими стали спецификации, получившие название Object Management Architecture (OMA) [1].

 

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

 

  • архитектура брокера запросов объектов (CORBA — Common Object Request Broker Architecture) определяет механизмы взаимодействия объектов в разнородной сети [2];
  • сервисы объектов (Object services) являются основными системными сервисами, используемыми разработчиками для создания приложений [3];
  • универсальные средства (Common Facilities) являются высокоуровневыми системными сервисами, ориентированными на поддержку пользовательских приложений, таких как электронная почта, средства печати и т.д.;
  • прикладные объекты (Application Objects) предназначены для решения конкретных прикладных задач.

 

Рисунок 2. Аржитектура управления объектами (OMA).

 

 

OMG CORBA

 

Спецификация Common Object Request Broker Architecture (CORBA) лежит в основе всех стандартов, разработанных OMG. CORBA определяет механизм, обеспечивающий взаимодействие приложений в распределенной системе [2].

 

Главными компонентами стандарта CORBA являются:

 

  • объектный брокер запросов (Object Request Broker);
  • язык определения интерфейсов (Interface Definition Language).

 

В спецификацию CORBA включено также несколько дополнительных, но очень важных сервисов:

 

  • сервис динамического формирования запросов (DII);
  • сервис репозитория интерфейсов (IR);
  • сервис динамической обработки запросов (DSI);
  • личных брокеров запросов (GIOP).

 

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

 

Концептуально спецификация CORBA относится к двум верхним уровням семиуровневой модели взаимодействия открытых систем [4]. Характерные особенности проведения разработок в технологии CORBA заключаются в следующем:

 

Язык описания интерфейсов OMG IDL позволяет определить интерфейс, независимый от языка реализации.

 

Высокий уровень абстракции CORBA в семиуровневой модели OSI избавляет программиста от работы с низкоуровневыми сетевыми протоколами.

 

Программисту не требуется информация о месте сервера в сетевой ИС и способе его активации.

 

Разработка клиентской программы не зависит от серверной операционной системы и аппаратной платформы.

 

Объектная модель CORBA

 

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

 

Объектный брокер запросов (ORB)

 

Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем. На Рис. 3 показано место главного компонента спецификации — брокера объектных запросов.

 

Рисунок 3. Место брокера объектных запросов.

 

 

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

 

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

 

Клиент может запрашивать выполнение операций с помощью ORB несколькими способами. На Рис. 4 показаны возможные варианты взаимодействия объектов.

 

 

Рисунок 4. Статоческий и динамический способы взаимодействия объектов с использованием ORB.

 

 

 

Вызов операций разделяемого объекта-сервера может быть статическим, через IDL-суррогат, или динамическим (Dynamic Invocation Interface). В случае статического вызова описания интерфейсов на IDL отображаются в программный код на языках С, С++, Smalltalk и др. При использовании динамического интерфейса запросы формируются специальным образом, без отображения интерфейса объекта в исходный код разрабатываемого приложения.

 

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

 

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

 

Базовый объектный адаптер BOA

 

Основная функция объектного адаптера, используемого для реализации CORBA-объекта, — обеспечение доступа к сервисам брокера объектных запросов. Объектный адаптер предоставляет все низкоуровневые средства для связи объекта с его клиентами [2][5]. В число этих средств входят:

 

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

 

Спецификация OMG CORBA определяет базовый объектный адаптер, который должен быть реализован во всех брокерах запросов. Basic Object Adapter (BOA) — это набор интерфейсов для создания ссылок на удаленные объекты, регистрации объектов, авторизации запросов и активизации приложений.

 

Роль базового объектного адаптера в архитектуре CORBA иллюстрирует Рис. 5.

 

 

Рисунок 5. Схема получения запроса.

 

 

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

 

IDL — язык описания интерфейсов

 

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

 

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

 

Описание интерфейса на IDL состоит из заголовка и тела. Заголовок содержит название интерфейса и указывает наследуемые интерфейсы. Тело состоит из объявлений констант, типов, исключительных ситуаций, атрибутов и операций. IDL — не полный язык программирования. Он является языком, описывающим интерфейс. Для конкретной реализации объекта генерируется его отображение в один из полных языков, таких как С++, C, ADA, Smalltalk. Отображение также является предметом стандартизации OMG. В настоящее время описаны отображения в С++, С, Smalltalk. Ведется работа по спецификации отображения IDL в язык Java.

 

В качестве примера приведем фрагмент описания интерфейса на языке IDL.

 

 

Листинг 1

 

 

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

 

Динамический интерфейс вызова (DII)

 

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

 

Репозиторий интерфейсов (Interface Repository)

 

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

 

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

 

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

 

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

 

Протоколы взаимодействия различных объектных брокеров (GIOP, IIOP)

 

Основной задачей спецификации CORBA является обеспечение взаимодействия объектов, распределенных по разнородной сети и использующих в общем случае различные брокеры запросов. Для связи между брокерами был разработан протокол General Inter ORB Protocol (GIOP), стандартизующий низкоуровневое представление данных и множество форматов сообщений.

 

Internet Inter ORB Protocol (IIOP) определяет обмен сообщениями в формате GIOP через TCP/IP-соединения. В последнее время протоколу IIOP уделяется все больше внимания со стороны крупнейших производителей программного обеспечения. IIOP становится признанным стандартом для вызова удаленных объектов в Интернет.

 

При необходимости протокол GIOP может быть реализован на основе других транспортных протоколов, например, IPX/SPX. На Рис. 6 показана иерархия спецификаций взаимодействия брокеров запросов по стандарту CORBA.

 

 

Рисунок 6. Иерархия спецификаций протоколов взаимодействия брокеров запросов.

 

Основные объектные сервисы стандарта CORBA


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

 

 

Рисунок 7. Трехуровневая архитектура информационных систем.

 

 

Очевидно, что в большинстве ИС необходимо некоторое множество системных объектных сервисов, которые не зависят от предметной области и обеспечивают базовую функциональность для управления распределенными объектами. С целью облегчения создания распределенных приложений консорциум OMG стандартизовал наиболее часто употребляемые сервисы (спецификация CORBAservices 1.0) [3]. Мы кратко рассмотрим характеристики основных сервисов архитектуры CORBA.

 

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

 

Сервис событий (Event service) обеспечивает поддержку асинхронного взаимодействия приложений.

 

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

 

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

 

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

 

Сервис управления разделяемыми ресурсами (Concurrency control) service позволяет клиентам координировать свои действия при использовании разделяемых ресурсов. Управление разделяемыми ресурсами осуществляется с помощью блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.

 

Сервис внешнего представления (Externalization service) формирует копию CORBA-объекта в виде некоторого внешнего представления — файла, элемента базы данных и т.д.

 

Универсальные средства (Common Facilities)

 

Универсальные средства обеспечивают поддержку интерфейсов высокого уровня и делятся на два типа: горизонтальные и вертикальные [5].

 

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

 

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

 

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

 

  • Средства управления системой. Они включают множество утилит, реализующих функции системного администрирования, то есть определяют интерфейсы основных операций, обеспечивающих управление, мониторинг, безопасность, конфигурирование и т.д.
  • Средства управления задачами. Предполагается, что данный набор будет представлен четырьмя спецификациями: средства управления потоками работ (workflow facility), средства программных агентов (agent facility), средства управления правилами (rule management facility), средства автоматизации (automation facility).

 

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

 

  • Средства обработки изображений. Специфицируют доступ к графическими данными и обмен ими. Роль этого средства заключается в поддержке приложений, выполняющих проверку, обработку, визуализацию и сохранение графических данных.
  • Средства поддержки информационной супермагистрали (superhighway facility). Специфицируется множество топологий сетей, протоколов и правил их использования, а также множество репозиториев информации и набор средств, обеспечивающих пользователям и приложениям доступ к этой информации.
  • Средства интегрированного автоматизированного производства. Обеспечивают интеграцию производственных функций предприятия, в том числе управление процессами разработки, контроль качества, финансовые и маркетинговые операции.
  • Средства эмуляции распределенных процессов. Они обеспечивают базис, на основе которого возможно быстрое построение и функционирование эмулируемой модели.
  • Средства информатизации в газовой и нефтяной промышленности. Эта предметная область характеризуется большим количеством данных и высокой сложностью алгоритмов.
  • Средства финансовых коммуникаций (accounting facility). Включают все формы коммерческих транзакций: обмен валюты, управление платежами, продажами и т.п.
  • Средства разработки приложений. Обслуживают выбор, разработку, построение и эволюцию приложений, составляющих корпоративную информационную систему. Данные спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы.

 

ODMG — разработка стандартов для объектных баз данных

 

Object Database Management Group (ODMG) была сформирована для выработки стандартов объектных баз данных. В отличие от OMG, фокусирующей свою деятельность на обеспечении интероперабельности приложений, ODMG стремится к обеспечению мобильности исходных текстов программ. Это подразумевает, что должны быть стандартизированы языки доступа к базам данных (но не внутренняя реализация программных продуктов). Разработанный стандарт ODMG 93 определяет общую объектную модель и общий язык для баз данных [6]. Эти меры призваны обеспечить необходимый уровень переносимости приложений.

 

Объектная модель данных ОDBMS

 

Объектная модель, предложенная группой ODMG, расширяет модель консорциума OMG, добавляя ряд новых концепций:

 

  • Связи между объектами. ODMG/OM определяет представление этих связей, управление ими и их использование.
  • Типы, определяющие множество свойств объекта. Свойства могут иметь форму атрибутов и связей.
  • Специальный тип "транзакции", определяющий механизм поддержки свойств атомарности, целостности, долговременности и согласованности при выполнении запросов к базе данных.
  • Специальный тип "база данных", позволяющий представлять БД как объект в объектной модели данных.

 

Рисунок 8. Расширение модели ODMG/OM в объектной модели ODMG.

 

Архитектура ODA


В соответствии со спецификацией CORBA для интеграции системы управления объектной базой данных в архитектуру ORB был разработан объектный адаптер базы данных (ODA), который отображает множество объектов из базы данных в среду брокера запросов [5]. В этой архитектуре СУБД обращается к брокеру запросов с помощью объектного адаптера. Содержащиеся в базе данных объекты не регистрируются брокером запросов по отдельности, а управляются внутренними средствами БД. Объектный адаптер позволяет СУБД регистрировать в системе множества объектов, а брокер запросов оперирует затем таким множеством, обеспечивая его связь с внешней средой.

 

 

Рисунок 9. Архитектура объектного адаптера ODA.

 

 

Все объекты БД, тем не менее, доступны для брокера запросов, поэтому возможен их удаленный вызов в распределенной разнородной среде.

 

Как упоминалось выше, каждый объектный адаптер, разработанный для архитектуры с брокером запросов, имеет специальное назначение. Например, в функции рассмотренного ранее базового объектного адаптера BOA входит отображение каждой операции над объектом в удаленный вызов процедуры (RPC). Объектный адаптер баз данных ODA имеет две специальные характеристики:

 

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


Стандартизация языков определения объектов и запросов к базам данных


Поскольку любая развитая БД поддерживает языки определения данных, манипулирования данными и выполнения запросов, стандарт для БД должен определять их семантику и синтаксис. В необъектных базах данных общеупотребимыми названиями для этих языков являются язык определения данных (data definition language), язык манипулирования данными (data manipulation language) и язык запросов (query language). Стандарт ODMG определяет работу с объектами, поэтому названия языков претерпели соответствующие трансформации: в стандарте ODMG 93 специфицируются языки определения объектов (ODL) и объектных запросов (OQL). ODMG не стандартизует язык манипулирования объектами. Вместо этого ODMG определяет, как отобразить необходимые манипуляции со структурами и объектами в обычные объектно-ориентированные языки программирования, такие как C++ и Smalltalk.

 

Язык определения объектов (ODL)


Язык определения объектов (ODL) расширяет язык определения интерфейсов IDL. Он позволяет определить атрибуты, связи, операции и типы данных.

 

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

 

Язык объектных запросов (OQL)


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

 

Реляционные СУБД в объектных системах


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

 

 

Рисунок 10. Интеграция РБД в объектную систему.
Рисунок 11. Отображение объектного проедставления данных в реляционное.

 

 

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

 

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

 

Продукты компании Iona Technologies, поддерживающие спецификацию CORBA

 

Orbix 2.0 — реализация стандарта CORBA 2.0

 

Orbix — это программый продукт компании IONA Technologies, предназначенный для построения и интеграции распределенных приложений. Orbix позволяет определять программные интерфейсы объектов, используя стандартный язык. Доступ к этим объектам разрешен из любого узла распределенной системы, что является одной из главных особенностей данного продукта [12] [13].

 

Orbix 2.0 — полная реализация стандарта OMG Common Object Request Broker Architecture 2.0, поддерживающая отображение языка IDL в С++, а также несколько дополнительных средств разработки, не описанных в спецификации.

 

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

 

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

 

Определение интерфейсов

 

В распределенной системе возможна реализация объектов с применением различных языков программирования. Orbix позволяет использовать язык C++, анонсированы реализации продукта для языков ADA и Smalltalk. В случае применения С++ каждый IDL-интерфейс реализуется в виде класса C++. Этот класс должен содержать все методы и параметры, которые соответствуют IDL-операциям и атрибутам. Для каждого IDL-интерфейса возможно реализовать более чем один С++ класс. Это позволяет иметь различные реализации объектов-серверов для одного интерфейса, что может потребоваться в многоплатформных системах.

 

Клиенты и серверы

 

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

 

Механизмы реализации IDL-интерфейса

 

Orbix поддерживает два механизма соотнесения IDL-интерфейса с реализующим его С++ классом:

 

  • BOA-механизм. Класс реализации интерфейса является наследником класса BOAImpl, с помощью которого предоставляется доступ к методам базового объектного адаптера BOA.
  • TIE-механизм. Программист должен явно указать, что класс относится к данному IDL-интерфейсу.

 

Средства разработки распределенных приложений, реализованные в Orbix

 

Основные средства

 

Репозиторий интерфейсов (Interface Repository)

 

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

 

Dynamic Invocation Interface

 

Orbix поддерживает сервис Dynamic Invocation Interface, который позволяет приложению формировать запросы к интерфейсу, неизвестному на стадии компиляции. Такие динамические запросы формируются путем указания во время выполнения имени объекта, реализующего интерфейс, имени операции и параметров вызова.

 

IIOP протокол

 

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

 

Дополнительные средства

 

Фильтры (Filters)

 

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

 

Загрузчики (Loaders)

 

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

 

Локаторы (Locators)

 

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

 

Smart Proxy

 

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

 

OrbixOTS — сервис управления распределенными транзакциями

 

Продукт OrbixOTS — это реализация сервиса распределенных транзакций в соответствии со спецификацией OMG CORBAservices 1.0. Продукт разработан совместно компаниями Iona Technologies и Transarc. В его основу положена архитектура известного монитора транзакций Encina, что гарантирует высокие показатели надежности и производительности.

 

Сценарий работы сервиса распределенных транзакций можно проиллюстрировать следующим примером (см. Рис. 12).

 

 

Рисунок 12. Использование сервиса распределенных транзакций.

 

 

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

 

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

 

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

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

 

Приложение В модифицирует БД, снова оставляя задачу завершения транзакции сервису транзакций. Управление возвращается приложению А.

 

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

 

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

 

OrbixWeb — CORBA-совместимый брокер объектных запросов с поддержкой языка Java


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

 

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

 

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

 

Реализация сервиса именования объектов — OrbixNames


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

 

Рисунок 13. Дерево контекстов сервиса именования.

 

 

Рисунок 14. Архитектура сервиса Orbix Talk.

 

 

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

 

Объектный адаптер Orbix+Versant Adapter

 

Orbix+Versant Adapter (OVA) интегрирует Orbix с объектно-ориентированной базой данных компании Versant Object Technology. С помощью интеграции этих двух продуктов достигаются следующие цели:

 

для Orbix-приложений обеспечивается хранение объектов в долговременной памяти;

объекты, хранимые в объектной БД Versant, становятся доступными для удаленного вызова из других CORBA-приложений.

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

 

Orbix+Isis — отказоустойчивый брокер объектных запросов

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

 

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

 

Программный интерфейс Orbix+Isis представляет собой множество C++ классов, реализующих распределенные вычисления, отказоустойчивость и балансировку загрузки. Приложения разрабатываются с использованием языка IDL, описания которого компилируются в С++. В Orbix+Isis сохранены все возможности стандартного продукта Orbix, в том числе такие, как фильтры и интеллектуальные клиенты (smart proxy). Приложения-клиенты Orbix-серверов остаются неизменными в случае их использования с серверами Orbix+Isis. Серверные приложения требуют минимальных модификаций, добавляющих свойства надежной обработки данных.

 

Процесс разработки распределенных приложений с помощью продуктов Iona Technologies

В данном разделе кратко описан процесс разработки распределенных приложений на основе продуктов Orbix.

 

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

 

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

 

Предположим, что IDL-интерфейс имеет приведенный ниже вид и помещается в файл account.idl.

 

 

Листинг 2

 

 

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

 

Компилятором IDL генерируются несколько файлов:

 

  • заголовочный файл account.hh, в котором описываются все необходимые С++ объекты;
  • файл для серверного приложения accountS.cc;
  • файл для клиентского приложения accountC.cc.


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

 

Листинг 3

 

Реализация методов, описанных в заголовочном файле, и является реализацией операций IDL-интерфейса, доступных для удаленного вызова.

 

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

 

Этапы разработки распределенного приложения приведены на Рис. 15.

 

Рисунок 15. Последовательность разработки распределенных приложений.

 

 

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

 

Приведем фрагмент кода для вызова серверного объекта.

 

Листинг 4

 

 

После инициализации объектной ссылки (accRef) все операции с ее использованием осуществляются аналогично операциям с обычной переменной, являющейся указателем на локальный объект языка С++.

 

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

 

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

 

Мы описали процесс разработки распределенных приложений на примере продукта Orbix, где языком реализации является С++. Разработка приложений с помощью продукта OrbixWeb полностью аналогична, за исключением того, что в роли языка реализации выступает Java. Использование продуктов OrbixNames, OrbixOTS, OrbixTalk состоит в разработке клиентских приложений, применяющих предоставляемые сервисы. Все упомянутые продукты и другие объектные сервисы реализованы в виде CORBA-серверов, имеющих строго определенные IDL-интерфейсы.

 

Заключение

 

Наиболее бурно развивающимся направлением в области информационных технологий в последние годы стала разработка программного обеспечения, связанного с сетью Интернет и системами Интранет, опирающегося на Web-технологию и язык Java. Объектные, распределенные технологии консорциумов OMG и ODMG соответствуют общим тенденциям, расширяя и обобщая их. Примечательно, что все ведущие производители систем Интернет/Интранет, включая Sun, IBM, Netscape, Microsoft, встраивают в свои продукты поддержку CORBA-совместимых протоколов.

 

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

 

Литература

 

  1. Object Management Group -- Object Management Architecture Guide , 1992
  2. Object Management Group -- The Common Object Request Broker: Architecture and Specification , 1995
  3. Object Management Group -- CORBAservices: Common Object Services Specification , 1995
  4. T.J. Mowbray , R. Zahavi -- The Essential CORBA: Systems Integration Using Distributed Objects
  5. R. Ben-Natan -- CORBA - A guide to the Common Object Request Broker Architecture
  6. Object Database Management Group -- The Object Database Standard: ODMG-93 , 1994
  7. A. Carmichael -- Object Development Methods. - SIGS BOOKS, 1994
  8. N. Ganti -- The Transition of Legacy Systems to a Distributed Architecture -- John Wiley & Sons, 1995
  9. Б. Страуструп -- Язык программирования С++
  10. Д. Брюхов , Л. Калиниченко -- Интероперабельные информационные системы: архитектуры и технологии -- СУБД, 4, 1995
  11. Л. Калиниченко -- Стандарт систем управления объектными базами данных ODMG 93: краткий обзор и оценка состояния -- СУБД, 1, 1996
  12. Iona Technologies -- Orbix 2, Reference guide , 1996
  13. Iona Technologies -- Orbix 2, Programmers guide , 1996

 

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

 

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

 

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

 

Есть ряд прописных истин и жизненных уложений, которые потеряли свою справедливость:

 

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

 

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

 

Волны

 

Ныне в моде серфинг на волне World-Wide Web. Однако многие другие волны, такие как Тоффлеровская "Third Wave", сбивают с ног представителей нашей профессии, одного за другим. Мы должны удержаться не только на гребне Web, но и на этих волнах. Некоторые из них мы создали сами. Другие появились благодаря существенным изменениям в экономике и в обществе в целом. Мы ответственны за большинство общих изменений, и они затрагивают нас — косвенно, но совершенно определенно. Мы не можем провозглашать, что живем в информационном обществе, и ощущать себя посторонними.

 

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

 

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

 

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

 

Поколения

 

Трудно советовать, как удержаться на волнах, если не ясна их природа. Мы можем дать несколько полезных рекомендаций, ориентируясь на возраст человека и его квалификацию, точнее, на стаж производственной или научной деятельности. Как на инструктаже по серфингу, когда людям в возрасте 10, 20, 30, 40 и 50 лет нужны разные рекомендации, мы разделим компьютерных профессионалов на 5 групп в зависимости от стажа и назовем эти группы поколениями. Каждое поколение формировалось под воздействием эпохальных нововведений в области информационных технологий, отсюда и выбранные нами названия:

 

  • поколение Фортрана, Кобола, перфокарт;
  • поколение мэйнфреймов, OS-360, PL/1;
  • поколение миникомпьютеров, Unix, C;
  • поколение MS-DOS, Windows, ПК;
  • поколение Интернет, электронной почты, Web.

 

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

 

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

 

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

 

Поколение Фортрана, Кобола, перфокарт

 

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

 

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

 

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

 

Поколение мэйнфреймов, OS-360, PL/1

 

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

 

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

 

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

 

Поколение миникомпьютеров, Unix, C

 

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

 

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

 

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

 

Поколение MS-DOS, Windows, ПК

 

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

 

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

 

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

 

Поколение Интернет, электронной почты, Web

 

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

 

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

 

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

 

Новое поколение

 

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

 

  • Относительность времени. Поскольку мы можем переместиться в прошлое, выполнив запрос к базе видеоданных, или отправиться в будущее, воспользовавшись реалистичными моделями, понятие времени становится очень изменчивым. Мы можем двигаться в любой направлении с любой скоростью.
  • Сосуществование реального и виртуального. Новое качество виртуальных сред делает невозможным проведение грани между реальным и нереальным. Границы устанавливает только богатство воображения.
  • Открытость пространства. Поскольку нас может окружать любая среда и мы можем поместить себя в любое окружение, пространство становится пластичным. Чтобы двигаться и действовать, больше не нужно физического присутствия.
  • Сверхинтерактивность. Исчезают ограничения в скорости, уровне и каналах взаимодействия. Раньше взаимодействие было медленным, статичным, теперь мы ограничены только нашей способностью одновременно поддерживать множество синхронных и асинхронных контактов.
  • Активное присутствие. При большом числе контактов, сопровождающих каждое действие, пассивное присутствие равносильно несуществованию. Будет трудно сохранить свой статус, должность, имидж без агрессивного соучастия.
  • Косвенное управление. Мы можем влиять на явления и управлять ими дистанционно, внешним образом. Однако приятное ощущение полного и непосредственного контроля теряется.

 

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

 

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

 

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

 

Хороший совет

 

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

 

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

 

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

 

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

Уведомления об обновлении тем – в вашей почте

На кого учиться в ИТ: профессиональные тренды на ближайшие 10 лет

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

Системы управления базами данных — коротко о главном. Часть 3

В Разд. Реляционная база данных — основные понятия уже обсуждалось понятие транзакции. Транзакция представляет собой последовательность операторов языка SQL, которая рассматривается как некоторое неделимое действие над базой данных, осмысленное с ...

Корпоративный сайт. Эффективный инструмент бизнеса или нереализованные возможности

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

Методология оценки безопасности информационных технологий по общим критериям

  В 1990 году под эгидой Международной организации по стандартизации (ИСО) и при содействии в дальнейшем государственных организаций США, Канады, Великобритании, Франции, Германии и Нидерландов были развернуты работы по созданию ...

Облачный подход к разработке

Облачные технологии и сервисы меняют подход разработчиков к построению информационных систем

Опыт внедрения Java-технологии в компании Sun Microsystems

Информационная модель Java находит применение во многих различных вычислительных средах — от смарт-карт до суперкомпьютеров. В настоящей статье описывается, как Java и Java-устройства, такие как JavaStation компании SUN Microsystems, могут ...

Оптимизация информационных систем на основе СУБД Oracle

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

Какие профессии в ИТ будут востребованы в 2021 году

Можно сказать однозначно: вакансий для ИТ-специалистов меньше не станет ни в течение нынешнего года, ни в 10-летней и даже более отдаленной перспективе. Материал подготовлен экспертами Trud.com

Типы и структуры данных в INFORMIX® -Universal Server

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

Спасибо!
Вы подписались на обновления наших статей
Предложить
авторский материал





    Спасибо!
    Вы подписались на обновления наших статей
    Подписаться
    на тему







      Спасибо!
      Вы подписались на обновления наших статей
      Оформить
      подписку на журнал







        Спасибо!
        Вы подписались на обновления наших статей
        Оформить
        подписку на новости







          Спасибо!
          Вы подписались на обновления наших статей
          Задать вопрос
          редактору








            Оставить заявку

            Мы всегда рады ответить на любые Ваши вопросы

            * Обязательные поля для заполнения

            Спасибо!

            Благодарим за обращение. Ваша заявка принята

            Наш специалист свяжется с Вами в течение рабочего дня