Обучение и набор персонала

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

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

Результаты опроса, проведенного журналом DataCommunications среди посетителей Web-узла журнала, дали следующие результаты.

На вопрос "Испытываете ли вы сложности при подборе специалистов для построения и обслуживания вашей сети" 26% опрошенных ответило "Нет" и 74% ответило "Да". На вопрос "Что вы делаете для решения проблемы со специалистами" были получены следующие ответы:

22% - нанимаем новых сотрудников;

50% - переобучаем своих сотрудников;

34% - обращаемся к внешним консультантам;

25% - нанимаем внешних специалистов на временную работу.

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

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

Обзор перспективных технологий глобальных сетей и сервисов

3.1.1. Технология SONET/SDH - основа для построения высокоскоростных масштабируемых глобальный сетей

3.1.1.1. Особенности технологии SONET/SDH

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

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

Таким решением являются первичные сети коммутаторов цифровых каналов T1/E1 и T3/E3. Эти сети могут создать долговременное соединение между любыми двумя абонентами, подключенными к мультиплексорам сети. Для этого оператор сети должен с помощью соответствующей системы управления запрограммировать коммутаторы сети, которые могут направлять элементарные цифровые потоки данных, имеющие скорость 64 Кб/c, на другие коммутаторы или в канал подключения конечного абонента (рис. 3.3).

Первичные сети этого типа могут образовывать каналы с иерархией скоростей:

64 Кб/с - 1.544 Мб/с (T1) - 45 Мб/с (T3) в Америке и

64 Кб/с - 2.048 Мб/с (E1) - 34 Мб/с (E3) в Европе.

Рис. 3.3. Первичная сеть для образования цифровых выделенных каналов

На базе сетей плезиохронной иерархии можно строить сети более высокого уровня, например, сети с коммутацией пакетов. Так, долгое время магистраль Internet в Америке работала на основе каналов T3 со скоростью 45 Мб/с. Эти же каналы можно использовать для построения цифровой телефонной сети.

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


Для доступа мелких абонентов можно использовать каналы 64 Кб/c, доступ более крупных абонентов организовать по каналам E1, а магистраль сети строить на каналах E3.

Однако, технология плезиохронной иерархии обладает рядом ограничений и недостатков. Поэтому сегодня наиболее перспективной для построения первичной сети является технология синхронной цифровой иерархии, стандартизованная ANSI под названием SONET (SynchronousOpticalNETwork). Очень близкий к SONET стандарт ITU-T имеет название SDH (SynchronousDigitalHierarchy, SDH). Далее, для простоты, будет упоминаться только технология SDH, но все это в равной степени относится и к технологии SONET.

Технология SDH улучшает технологию плезиохронной цифровой иерархии во многих отношениях:

Расширение иерархии скоростей в гигабитный диапазон. Начальная скорость сетей SDH - 155 Мб/с (SONET - 51.5 Мб/c). Эта скорость соответствует спецификации STM-1, а остальные скорости сетей SDH кратны скорости STM-1. Сегодня стандартизованы скорости STM-4 - 622 Мб/с и STM-16 - 2.48 Мб/c. Основной вид носителя сетей SDH - оптоволокно, в территориальных сетях в основном - одномодовое. Гибкая система мультиплексирования низкоскоростных потоков в высокоскоростной. Технология SDH обратно совместима с плезиохронной технологией и может передавать элементарные потоки 64 Кб/c, а также потоки E1 и E3 в своих высокоскоростных каналах, причем для их выделения и коммутации не требуется полного расщепления высокоскоростного канала на его элементарные составляющие. Каналы 64 Кб/c и каналы E1 часто используются как каналы доступа к сетям SDH. Отказоустойчивость на уровне технологии. Отказоустойчивая конфигурация строится на основе двойных оптоволоконных колец (рис. 3.4).

Рис. 3.4. Сети Sonet/SDH

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


Похожий способ применяется в сетях FDDI.

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

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

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

На основе первичной сети SDH можно строить сети с коммутацией пакетов например, frame или ATM, или же сети с коммутацией каналов, например, ISDN. Технология АТМ облегчила эту задачу, приняв стандарты SDH в качестве основного варианта физического уровня. Поэтому, при существовании инфраструктуры SDH для образования сети АТМ достаточно соединить АТМ-коммутаторы жестко сконфигурированными в сети SDH каналами.

3.1.1.2. Использование цифровых выделенных каналов

Выделенные низкоскоростные цифровые каналы 64 Кб/с даже большой протяженности сейчас доступны (в стоимостном отношении) для большинства средних и крупных предприятий.


В качестве подтверждения приведем тарифы месячной платы за аренду такого канала из региона Ближнего Востока в США:

Страна	Месячная плата в $US
Израиль	4 417
Объединенные Арабские Эмираты	8 128
Марокко	8 711
Катар	7 891
Оман	9 312
Кувейт	9 917
Бахрейн	9 947
Саудовская Аравия	10 878
Египет	12 000

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

Так, канал E1 с пропускной способностью 2 Мб/с стоит в большинстве европейских стран на расстоянии 25 км от $2000 до $4000 в месяц (без стоимости инсталляции), а на расстоянии 250 км - от $4000 до $8000 в месяц.

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

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

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

В следующих двух таблицах представлены основные характеристики сервисов выделенных цифровых каналов высокой степени готовности различных внутренних и международных провайдеров. Данные были опубликованы в журнале DataCommunications, June 1997, стр. 40D - 40E.



Таблица 3.1. Характеристики сервисов выделенных каналов внутренних провайдеров некоторых европейских стран.

Провайдер	Сервис	Терри- тория	SDH для конечных точек	Дубли- рование каналов/ точек доступа	Гарантии времени простоев	Гарантии времени ремонта	Финан- совые штрафы	Превышение стоимости обычных каналов
Bayer- werkNetkom, Munich, Germany	Mana gedBand width	Бавария- Тюрингия	Да	Да/Да	9.64 ч в год (без линий доступа)	4 часа	До 10% месячной платы	30%
British Telecommunica- tionsPLC, London	Mega streamGenus	Лондон и болшин- ство крупных городов	Да	Да/Да	4.38 ч в год	5 часов	25% годовой платы при каждом простое свыше 5 часов	10%
Deutsche Telecom, Bonn	LeasedLink (DDV)	Германия	Нет	Да/Нет	87.6 ч в год	8 часов	Нет	179%
Energis Communications, London	National PrivateCircuits	Лондон и болшин-ство крупных городов	Да	Да/Да	13.14 ч в год	5 часов	До 100% ежегод-ной оплаты	10% - 15%
FranceTelecom, Paris	Reliable NetworkAccess	Франция	Да	Да/Да	1.05 ч в год, 30 мин ежеме-сячно	2 часа	До 2 месяцев бесплатной аренды	Инсталляция - 667%, ежемесячная плата - 80%
HelsinkiTelecom, Helsinki	Digilink	Финлян-дия	Нет	Да/Да	22 - 26 мин в месяц	не опреде-лено	До 10% месячной аренды	20% - 50%
TelecomFinland, Helsinki	Fastnet	Финлян-дия	Да	Да/Да	4.38 ч в год, 4 ч в месяц	4 часа (только рабочие часы)	Превы-шение месячной гарантии: 1 месяц бесплатно; превыше-ние годичной гарантии: до 10% месячной платы	10%
Telia, Farsta, Sweden	Telia LinkXline	Sweden	Да	Да/Да	4.38 ч (в год)	не опреде-лено	25% месячной платы	не объявлено

Таблица 3.2. Характеристики сервисов выделенных каналов международных провайдеров

Провайдер	Сервис	Дублирова- ние каналов/точек доступа	Гарантии времени простоев	Гарантии времени ремонта	Финансовые штрафы	Превышение стоимо-сти обыч-ных каналов
AT&TUnisource CommunicationServices Hoofddorp, theNetherlands	ManagedBandwidth Service	Да/Да	8.76 ч в год	не определено	Нет	75%
Cable & WirelessPLC London	GlobalManaged PrivateLine (GMPL)	Да/Да	44 мин в месяц	не определено	До 35% месячной платы после 6 часов простоя	не объявлено
Concert Communications (BT + MCI) Reston, US	PremiumLinks	Да/Да	13 мин в месяц	3 часа	До 10% месячной платы при простое от 3 до 10 часов в месяц	30% - 60%
Worldcom	International BusinessLink	Да/Да	4.38 ч в год	2 часа	При простое более 15 мин	Не объявлено

<


3.1.1.3. Примеры сетей SDH

Примером российских сетей SDH могут служить сети "Макомнет", "Метроком" и "Раском" совместных предприятий с американской компании AndrewCorporation.

Сеть "Макомнет"

Начало создания сети "Макомнет" относится к 1991 году, когда был образовано совместное предприятие, учредителями которого выступили Московский метрополитен и компания Andrew (США).

Транспортной средой сети стали одномодовые 32-, 16- и 8-ми жильные волоконно-оптические кабели фирмы Pirelli, проложенные в туннелях метрополитена. В метро было уложено более 350 км кабеля. Постоянно расширяясь, сегодня кабельная система "Макомнет" с учетом соединений "последней мили" составляет уже более 1000 километров.

Изначально в сети "Макомнет" использовалось оборудование SDH только 1 уровня (155 Мбит/с) - мультиплексоры TN-1X фирмы NorthernTelecom (Nortel), обладающие функциями коммутации 63 каналов E1 по 2 Мб/c каждый. Из данных мультиплексоров было организовано две кольцевые топологии "Восточная" и "Западная" (они разделили кольцевую линию метрополитена на два полукольца вдоль Сокольнической линии) и несколько отрезков "точка-точка", протянувшихся к ряду клиентов, абонировавших сравнительно большие емкости сети. Эти кольца образовали магистраль сети, от которой ответвлялись связи с абонентами.

Растущие день ото дня потребности заказчиков заставляли создавать новые топологии и переконфигурировать старые. В течение двух лет "Макомнет" решал задачу увеличения пропускной способности за счет прокладки новых кабелей и установкой нового оборудования, позволивших утроить количество топологий по кольцевой линии. Число узлов коммутации возросло до семидесяти. Но настал момент, когда остро встал вопрос о количестве резервных оптических волокон на некоторых участках сети, и с учетом прогнозов на развитие было принято решение о построении нового, 4-го уровня SDH (622 Мбит/с).

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


В качестве оборудования 4 уровня (622 Мбит/с) "Макомнет" установила мультиплексоры TN-4X фирмы Nortel. Вместе с новым оборудованием была приобретена принципиально новая высокоинтеллектуальная система управления NRM (NetworkResourceManager). Эта система является надстройкой над системами управления оборудования 1 и 4 уровней. Она обладает не только всеми функциями контроля оборудования, присущими каждой из систем, но и рядом дополнительных возможностей: автоматической прокладки канала по сети, когда оператору требуется лишь указать начальную и конечную точки; функциями инвентаризации каналов, обеспечивающих их быстрый поиск в системе и рядом других.

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

Сегодня количество адресов размещения оборудования превысило 500, а персонал службы эксплуатации составляет девятнадцать человек. Время устранения аварии по внутренним нормативным документам варьируется от 30 минут до 2 часов, в зависимости от удаленности места аварии от Центра управления.

"Макомнет" предлагает заказчикам выделенные линии следующих уровней передачи данных:

канал от 64 Кбит/с до Nx64 (где N=1..31);

канал E1 - 2,048 Мбит/с.

Сегодняшняя топология сети "Макомнет" выглядит следующим образом:



Рис.3.5.

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

Компания, осваивая новые направления, строит сеть низкоскоростного доступа. "Макомнет" уже давно предоставляет пользователю низкоскоростные услуги (Nx64 Кбит/с), но ввод в строй современного низкоскоростного оборудования даст возможность не только сократить загрузку сети SDH, но и значительно расширить спектр предлагаемых клиентам услуг.


К концу 1997 года планируется ввести в действие единую сеть, обеспечивающую подключение пользователей с помощью протоколов V.24, V.35, X.21, X.25, а также framerelay. Данная сеть будет иметь централизованное управление и обладать возможностями резервирования каналов по схеме 1+1.

Сеть "Раском"

Сеть совместного предприятия "Раском" была создана в 1994 году для передачи телефонного и компьютерного трафика между Москвой и Санкт-Петербургом, а также между городами, расположенными вдоль трассы железной дороги "Москва - Санкт-Петербург". Сеть построена на основе оптоволоконного кабеля компании Pirelli (28 одномодовых жил), проложенного на опорах вдоль железной дороги. Сеть использует технологию SDH для коммутации элементарных цифровых каналов абонентов. Первая очередь сети включала два кольца SDH на коммутаторах TN-1X компании Nortel. Кольца работали на начальной скорости технологии SDH - STM-1 155 Мб/с. Первое кольцо, названное "Express", соединяло мультиплексор TN-1X, расположенный в Москве, с аналогичным мультиплексором в Санкт-Петербурге, и передавало трафик абонентов, расположенных в этих городах, без промежуточной коммутации, используя только 26 промежуточных регенераторов сигналов. Второе кольцо под названием "Drop & Insert", было предназначено для передачи трафика между промежуточными городами, поэтому имело кроме 2-х оконечных еще 17 промежуточных мультиплексоров для ответвления и приема трафика в точках, соединяющих кольцо с городскими сетями.

Совместное предприятие "Раском" было образовано американской компанией AndrewCorporation, Октябрьской железной дорогой и РАО ВСМ. Компания AndrewCorporation несколько ранее уже образовала с российскими соучредителями два совместных предприятия, которые стали операторами крупных высокоскоростных сетей по технологии SDH масштаба города - сети "Макомнет" в Москве и сети "Метроком" в Санкт-Петербурге, так что вложение средств в сеть, соединяющую эти города - логичное продолжение долговременной стратегической линии.



Сеть "Раском" достаточно быстро развивалась за счет включения в нее новых подсетей ISDN таких городов как Новгород и Тверь.

К лету 1997 года в основном завершился этап модернизации сети "Раском", связанный с повышением пропускной способности ее магистрали за счет применения основных мультиплексоров TN-16X компании Nortel, поддерживающих скорость на магистральной кольце STM-16 2.56 Гб/с. Кроме модулей STM-16 в мультиплексорах и коммутаторах будут использовать модули STM-1 и STM-4, с помощью которых будет осуществляться ответвление трафика для конечных абонентов.

Всего к лету 1997 года сеть "Раском" стала располагать 30 000 элементарных каналов 64 Кб/с.

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

Другим крупным оператором сетей SDH в Москве является компания "Голден Пайн", использующая для коммутации цифровых каналов оборудование компании Newbridge (линия коммутаторов MainStreet). Магистарль "Голден Лайн" также включает оборудование коммутации уровня STM-4 со скоростью 622 Мб/с. "Голден Лайн" также создала на базе своих каналов публичную сеть framerelay, сервисами которой можно пользоваться в пределах Москвы.

Обзор применяемых архитектур современных информационных приложений

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

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

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

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

9.3.1. Информационные системы, использующие серверы приложений

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



Рис. 9.1. Общее представление информационной системы в архитектуре "клиент-сервер"

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

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

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

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



Здесь необходимо сделать еще два замечания:

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

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

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


Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения. При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных. Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения. При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т.д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения. При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т.д.) также могут срабатывать триггеры, т.е., другими словами, может выполняться серверная часть приложения. Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т.д.). Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур.


Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента. При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения.

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



Рис. 9.2. Тонкий клиент и толстый сервер в клиент-серверной архитектуре

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

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


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



Рис. 9.3. Потолстевший клиент и толстый сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов

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



Рис. 9.4. Информационная система в архитектуре "клиент-сервер" с выделенным сервером приложений

Информационные системы в трехзвенном (или многозвенном исполнении) могут создаваться на основе использования промежуточного программного обеспечения мониторов распределенных транзакций, например, Tuxedo компании BEASystems, Inc. или Encina компании TransarcCorp.

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

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

Обзор рынка готовых информационных приложений

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

Вообще, в компьютерном мире понятие стороннего поставщика (third-partycompany) имеет очень большое значение, поскольку значительная часть прикладного программного обеспечения производится именно небольшими независимыми софтверными компаниями.

9.1.1. Информационные приложения, поставляемые крупными компаниями производителями вычислительной техники и СУБД (Oracle, Hewlett-Packard, IBM, Microsoft и т.д.)

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

Начнем с компании Oracle. Представители этой компании любят представлять набор производимых продуктов в виде перевернутой пирамиды с вершиной внизу и основанием наверху. Вершине пирамиды соответствует базовый комплект серверов баз данных, предлагаемых компанией. В середине пирамиды располагаются средства проектирования и разработки баз данных и информационных систем (в частности, Designer/Developer 2000). Наконец, основанию пирамиды соответствуют готовые компоненты информационных приложений и законченные решения. Такая картина правильно отражает соотношения объемов и числа продуктов. Конечно, серверы баз данных - это наиболее сложные и ответственные продукты. Но их число и объем кода не очень велики. Средства проектирования и разработки опираются на использование серверов; эти продукты менее сложны, но более объемны. Наконец, приложения создаются с использованием средств проектирования и разработки; приложений много, и суммарный объем кода очень велик.

Oracle предлагает приложения (естественно, основанные на использовании серверов баз данных Oracle) для использования в следующих предметных областях:

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

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

В частности, имеются решения HP для применения в следующих сферах:

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

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

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

Обзор рынка коммутаторов

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

Настольные коммутаторы:

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

Пример: 3ComLinkSwitch 500

Коммутаторы рабочих групп:

имеют по крайней мере 1 высокоскоростной порт (FDDI, FastEthernet, ATM); транслируют протоколы; как правило, управляемы по SNMP, поддерживают алгоритм SpanningTree; режим коммутации - с буферизацией.

Примеры: семейство 3ComLinkSwitch (кроме модели 500), SMCTigerSwitchXE, BayNetworksEthernetWorkgroupSwitch

Коммутаторы отделов и центров обработки данных:

модульное исполнение; поддержка нескольких протоколов; встроенные средства обеспечения отказоустойчивости: избыточные источники питания; модули hot-swap. пользовательские фильтры; поддержка виртуальных сегментов.

Примеры: 3ComLANplex 2500, SMCES/1, BayNetworksLattisSwitchSystem 28115

Коммутаторы магистралей зданий/кампусов:

те же свойства, что и у коммутаторов отделов; пасси с большим количеством слотов (10 - 14); внутренняя пропускная способность 1 - 10 Гб/с; поддержка 1 - 2 протоколов маршрутизации (локальные интерфейсы) для связи виртуальных сетей. Такие коммутаторы обычно называют коммутаторами 3-го уровня.

Примеры: 3ComLANplex 6000, CabletronMMACPlus, MadgeLANSwitch, CiscoCatalist 5000, BayNetworksSystem 5000

Коммутаторы выпускаются уже достаточно давно, поэтому существует их классификация по поколениям. Приведем точку зрения компании ExtremeNetwork, одного из пионеров коммутации GigabitEthernet:

Первое поколение коммутаторов - все порты одинаковые, по 10 Мб/с. Второе поколение - коммутация Ethernet и одной из высокоскоростных технологий (FDDI, FastEthernet, ATM). Коммутаторы предназначены в основном для решения задачи необходимой пропускной способности для серверов. Появление технологии GigabitEthernet создало предпосылки для появления коммутаторов третьего поколения. Это поколение обладает 4-мя ключевыми свойствами: масштабируемая скорость портов (10-100-1000); масштабируемая пропускная способность коммутатора, не блокирующая производительность со значительным запасом; масштабируемость коммутатора по отношению к размеру сети - поддержка высокоскоростной маршрутизации (как правило, на уровне ASIC); обеспечение требуемого качества обслуживания для различных типов трафика для любых пар конечных абонентов сети (резервирование пропускной способности по RSVP, приоритеты трафика по 802.1p, 802.1q, DVMRP, IGMP).

Рынок коммутаторов FastEthernet

По данным исследовательской компании SageResearch, на рынке коммутаторов FastEthernet в 1996 году лидировали три компании - CiscoSystems, 3Com и BayNetworks. Эти данные были собраны по результатам продаж коммутаторов только в США и учитывают все типы коммутаторов, имеющих порты FastEthernet - как коммутаторы, поддерживающие только один - два порта FastEthernet, а остальные - 10-Мегабитный Ethernet (некоторые специалисты не относят такие коммутаторы к коммутаторам FastEthernet, а считают их коммутаторами Ethernet с портом FastEthernet), так и коммутаторы, поддерживающие коммутацию между большим количеством портов FastEthernet (6, 8 и более).

При учете количества проданных коммутаторов на первое место вышла компания Cisco, получившая 41% рынка, второе место с 19% занимает 3Com, а третье с 17% - BayNetworks:



Рис. 2.7.

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



Рис. 2.8.

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



Еще один интересный вывод, который дало это исследование рынка - коммутаторы, имеющие в своем составе только порты 100 Мб/c, продаются хуже, чем коммутаторы, имеющие порты 10 Мб/c и 100 Мб/с. Это говорит о том, что пользователи пока не торопятся заменять все сегменты своих сетей на технологию FastEthernet, оставляя 10 Мегабитный как более дешевую альтернативу, и ускоряя работу низкоскоростных сегментов за счет применения коммутаторов с портами Ethernet 10 Мб/c.

Рынок гигабитных коммутаторов

Пока не так много компаний рискнуло выпускать коммутаторы GigabitEthernet в условиях отсутствия стандарта. На рынке преобладают новые небольшие компании, которые собираются на волне новой технологии завоевать свое место под солнцем, и быть купленными в случае успеха каким-нибудь монстром типа CiscoSystems или BayNetworks. Коммутаторы делятся на коммутаторы FastEthernet с одним или двумя гигабитными портами, и собственно коммутаторы GigabitEthernet, у которых гигабитных портов 4, 8 или более.

Что ждут пользователи от гигабитных коммутаторов? Опрос 130 сетевых администраторов дает некоторые ответы на этот вопрос.



Рис. 2.9.

Наиболее важным свойством пользователи назвали неблокирующую архитектуру коммутатора, то есть его способность обрабатывать все кадры при максимально возможной интенсивности потока кадров по каждому порту. Таким образом, высокая производительность является по прежнему главным достоинством коммутаторов. Поддержка полнодуплексного режима работы портов также связана с требованиями максимального повышения производительности, так как в этом режиме каждый порт обрабатывает в два раза больше данных, чем в полудуплексном. Качество обслуживания также заметно волнует пользователей, а так как только АТМ-коммутаторы реализуют его в полном объеме, то разработчикам коммутаторов Ethernet и других технологий приходится проявлять изобретательность даже при наличии стандартов 802.1q/p.

Обзор современного состояния рынка серверов баз данных

Естественно, мы не можем в этом подразделе достаточно детально представить даже наиболее известных производителей серверных продуктов реляционных баз данных и собственно эти продукты. Это связано и с тем, что по поводу каждой компании можно сказать очень много, и с тем, что серверные продукты управления базами данных являются, по всей видимости наиболее сложными программными продуктами, присутствующими на рынке, и с тем, что компании-производители серверных продуктов очень не любят открывать технические детали реализации (это считается частью "know-how" компании). Мы постараемся охарактеризовать деятельность и продукты ведущей шестерки производителей (компаний Oracle (www.oracle.com), Informix (www.informix.com), Sybase (www.sybase.com), ComputerAssociates (www.cai.com), IBM (www.ibm.com) и Microsoft (www.microsoft.com)), касаясь только особенностей серверов баз данных и не затрагивая возможности громадного числа сопутствующих программных продуктов. Кроме того, мы не будем обсуждать продукты компаний "второго эшелона", хотя зачастую они обладают оригинальными и специфическими возможностями.

8.1.1.1. История и серверные продукты компании Oracle

Первая доступная заказчикам версия СУБД Oracle (OracleV.2) была выпущена компанией RelationalSoftwareInc. в 1979 г. Эта версия была ориентирована на использование в среде ОС RSX-11 для семейства миникомпьютеров PDP-11. Система была написана большей частью на языке ассемблера PDP-11, но включала также тексты на новом для того времени языке Си. СУБД могла функционировать не только в среде ОС RSX-11, но и в других операционных средах, поддерживаемых на PDP-11: IAS, RSTS и UNIX. Тогда же было принято решение о переносе Oracle в 32-разрядную операционную среду VAXVMS, что на долгие годы определило судьбу СУБД Oracle как ведущей системы управления базами данных на миникомпьютерах.

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


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

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

В 1985 г. на рынке появилась СУБД OracleV.5. В этой системе использовалась архитектура "клиент-сервер" и впервые появилась (ограниченная) возможность одновременного использования баз данных, расположенных в разных узлах сети.

Шестая версия системы представляла из себя инструмент построения корпоративных информационных приложений, выполняющихся в режиме OLTP. В системе были реализованы система блокировок на уровне записей (заметим, что хотя этот уровень блокировок кажется наиболее естественным, переход к его использованию происходил и происходит непросто; в частности, в очень развитых последних по времени продуктах компании Sybase до сих пор используются блокировки на уровне страниц), а также механизм непротиворечивых чтений из базы данных без потребности блокировок (это легко реализуемое оригинальное изобретение Oracle пока не воспроизведено в продуктах других компаний и, естественно, не стандартизовано). СУБД OracleV.6 была перенесена на ряд новых платформ, в том числе, OS/2 и Macintosh.

Важными нововведениями шестой версии было появление процедурного языка программирования PL/SQL, который можно было использовать как для определения процедур, хранимых на сервере баз данных, так и для разработки приложений в составе языка четвертого поколения SQL*Forms. Кроме того, в реализованном варианте языка SQL появились средства определения ссылочной целостности (referenceintegrity), одного из наиболее фундаментальных механизмов поддержания целостности в реляционных базах данных.



Седьмой выпуск СУБД Oracle появился на рынке в середине 1994 г. Это один из наиболее серьезных серверных продуктов, предназначенных для управления реляционными базами данных. В OracleV.7 используется ряд новых архитектурных решений, направленных на повышение эффективности сервера, в том числе буферизация откомпилированных SQL-операторов на сервере баз данных, использование общего пула серверных процессов и нитей для выполнения операторов SQL, поступающих от разных транзакций, использование разнообразной статистической информации для оптимизации запросов и т.д. Заметим, что именно в седьмой версии начался переход от использования оптимизатора запросов, управляемого правилами, к применению более прогрессивной техники оптимизации запросов на основе статистических оценок.

Существенно расширены возможности использования языка PL/SQL. В OracleV.7 этот язык можно использовать для определения триггеров, хранимых процедур, вызываемых сервером автоматически при возникновении специфицированных событий (например, выполнении операций модификации таблицы в целом или обновлении конкретной строки таблицы). Функции PL/SQL могут вызываться как обычные встроенные функции в операторах SQL. Заметим, что относительным, но существенным недостатком языка PL/SQL является то, что он не входит в состав международного стандарта SQL, хотя многие его свойства нашли отражение в вышедшем в этом году стандарте языка хранимых модулей, являющемся частью будущего стандарта SQL-3.

В распределенном варианте OracleV.7 поддерживаются возможности репликации данных и имеется возможность асинхронного вызова удаленных процедур.

Летом 1997 г. был объявлен выпуск восьмой версии системы, которая должна обладать целым рядом новых возможностей: встроенными средствами для использования в Internet/Intranet, поддержкой хранения мультимедийной информации, приближением реализованного варианта языка SQL к разрабатываемому стандарту языка SQL-3 и т.д. Поскольку эта версия (Oracle 8.1) является переходной от реляционного к объектно-реляционному подходу.



8.1.1.2. История и серверные продукты компании Informix

24 сентября 1996 г. компания Informix отметила десятилетие своей официальной деятельности. За эти годы компания увеличила объем своих доходов в 33 раза и уверенно занимает второе место на мировом рынке продуктов, связанных с управлением реляционными базами данных. С самого начала своего существования компания ориентировалась на создание серверов баз данных и сопутствующих программных продуктов, функционирующих в среде ОС UNIX. В число основных стратегических партнеров Informix входят компании Sequent, HewlettPaсkard, SunMicrosystems, IBM, SiemensNixdorf, NCR, для продуктов которых в первую очередь обеспечиваются новые работоспособные версии систем Informix. Помимо UNIX-платформ продукты компании Informix могут работать в операционных средах DOS, NetWare, Windows и WindowsNT.

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

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


Связь между клиентами и серверами поддерживается специальным модулем Informix-NET.

Базовым продуктом компании Informix является система Informix-OnLine, выпускаемая ныне в двух основных модификациях - Informix-OnLineDynamicServer и Informix-OnLineExtendedParallelServer. Эти серверы работают напрямую с дисковой памятью, обеспечивают выполнение транзакций в распределенной среде баз данных, поддерживают возможности хранения неструктурированных полей таблиц сверхбольшого размера (BLOBs - BinaryLargeObjects) и т.д.

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

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

В конце 1996 г. компания Informix объявила о выпуске объектно-реляционного сервера InformixUniversalServer. Поскольку этот продукт относится к новому поколению систем управления базами данных, отложим его обсуждение до п.10.1.4.

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

8.1.1.3. Серверные продукты компании Sybase

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


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

До выпуска в 1994 г. полномасштабного серверного продукта SybaseV.10 компания Sybase уверенно зарекомендовала себя в качестве ведущего производителя современных СУБД для применения в средних и малых информационных приложениях. Полностью основанная на архитектуре "клиент-сервер" SybaseV.10 могла использоваться на большинстве аппаратно-программных платформ: Sun, HP, IBMRS/6000, DigitalVAX/VMS, DigitalAlphaOpenVMS и AlphaOSF, NCR, NEC, Sequent, SiliconGraphics, NetWare, WindowsNT, OS/2, SCO и т.д. Архитектура SybaseV.10 обладала следующими характерными чертами:

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



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

В основной состав серверных продуктов SybaseV.11 входит следующее:

Базовый сервер SybaseSQLServer - современная высокопроизводительная СУБД (более подробно по поводу этого продукта см. ниже); SybaseMPP - расширение архитектуры SybaseSQLServer, предназначенного для эффективного использования в массивно параллельных компьютерных архитектурах с поддержкой сверхбольших баз данных (VeryLargeDataBases - VLDB); SybaseIQ - серверное средство построения битовых индексов для высокоскоростного выполнения запросов к большим источникам информации; SybaseSQLAnywhere - полнофункциональная "облегченная" СУБД, приобретенная от компании Watcom и предназначенная для производства индивидуальных и групповых информационных систем на платформах Intel; SybaseReplicationServer - серверный продукт, поддерживающий репликацию данных; SybaseOmniServer - сервер, обеспечивающий "прозрачную" работу клиентов с несколькими серверами баз данных, вообще говоря, различных производителей: Sybase, Oracle, DB2 и т.д.

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



В соответствии с утверждениями представителей компании Sybase, продукт SybaseSQLServer 11 обладает следующими основными возможностями:

1. Масштабируемость и эффективность SQLServer 11 основываются на тщательно проверенной технологии:

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

2. SQLServer 11 обеспечивает надежность хранения и целостность данных:

поддерживаются механизмы триггеров и хранимых процедур, декларативной ссылочной целостности, управления транзакциями и т.д.; как и полагается SQL-ориентированной СУБД, SQLServer 11 поддерживает уровень безопасности данных C2 в соответствии с требованиями Оранжевой Книги Министерства обороны США.

3. Обеспечивается повышенная доступность данных:

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

4. В SQLServer 11 обеспечивается соответствие основным принятым формально или фактически стандартам:

реализованный в системе вариант языка SQL полностью соответствует стандарту SQL-89, а также ядерному уровню (entrylevel) стандарта SQL-92; поддерживается выполнение приложений, выполненных в стандартах ODBC и X/OpenXA; применяются различные сетевые протоколы, что позволяет соединить клиента и сервера практически на любой платформе.

5. Гарантируется простота управления системой и ее поддержки:

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


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

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

В сентябре 1997 г. компания Sybase выпустила на рынок продукт под новым названием - SybaseAdaptiveServer, который на самом деле является пятым выпуском версии 11. В этом продукте еще более развита компонентная организация, улучшены возможности организации распределенных баз данных, внедрены более развитые средства интеграции с технологией Internet и т. д. Пока неизвестны какие-либо планы компании по переходу к объектно-реля- ционным архитектурам.

8.1.1.4. Линия серверных продуктов CA-OpenIngres компании ComputerAssociates

Проект и экспериментальный вариант СУБД Ingres были разработаны в университете Беркли под руководством одного из наиболее известных в мире ученых и специалистов в области баз данных Майкла Стоунбрейкера (MichaelStonebraker). С самого начала СУБД Ingres разрабатывалась как мобильная система, функционирующая в среде ОС UNIX. Первая версия Ingres была рассчитана на 16-разрядные компьютеры и работала главным образом на машинах серии PDP. Это была первая СУБД, распространяемая бесплатно для использования в университетах. Впоследствии группа Стоунбрейкера перенесла Ingres в среду ОС UNIXBSD, которая также была разработана в университете Беркли. Семейство СУБД Ingres из университета Беркли принято называть "университетской Ingres" (соответствующие программные продукты вместе с исходными текстами и документацией до сих пор доступны в секторе publicdomainInternet).

В начале 80-х была образована компания RTI (RelationalTechnologyInc.) для сведения университетских прототипов до уровня коммерческих продуктов. С этого момента стали различать университетскую и коммерческую СУБД Ingres.


В настоящее время коммерческая Ingres поддерживается, развивается и продается компанией ComputerAssociates. Сейчас это одна из наиболее развитых коммерческих реляционных СУБД.

Мы коснемся главным образом особенностей базового серверного продукта компании ComputerAssociates линии CA-OpenIngres - CA-OpenIngres/Server. Сервер базируется на следующих пяти ключевых архитектурных принципах компании ComputerAssociates:

использование многопоточной и мультипроцессорной организации сервера для систем оперативной обработки транзакций (OLTP - OnLineTransactionProcessing); применение более развитых методов обработки данных для систем уровня OLAP (OnLineAnalyticalProcessing); безопасное и надежное управление данными информационных приложений; обеспечение расширенных инструментальных средств администрирования серверной части системы (это вообще конек компании; у них больше всего внимания обращается на администрирование и управление систем); возможность гибкой настройки сервера в соответствии с конкретными потребностями корпорации.

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

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

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


Для особо критических запросов поддерживаются административные способы оптимизации.

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

В CA-OpenIngres поддерживаются стандарты SQL-89 и ядерный уровень языка SQL-92. (Обратите внимание, что никто из ведущих производителей не гарантирует полной совместимости с SQL-92. Это очень плохо, поскольку уже на протяжении более чем 4 лет, ни одна компания не может или не хочет произвести продукт, полностью соответствующий требованиям хорошего международного стандарта. Правда, и стандарт несколько сложноват.)

Очень интересным направлением развития линии CA-OpenIngres явилось приобретение японской объектно-ориентированной СУБД Jasmin. Это оригинальная объектно-ориентированная система, модель данных которой основывается одновременно на идеях Smalltalk и Си++. Компания ComputerAssociates считает, что в принципе невозможно сочетать в одной системе объектно-ориентированный и реляционный подходы (в частности, отметим по-прежнему существующую проблему потери соответствия объектных и реляционных операций, присущую объектно-реляционным системам).

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



В июне 1997 г. компания CA объявила о выпуске новой версии OpenIngres 2.0. Кроме улучшенных возможностей репликации и наличия развитых средств интеграции с Internet, в OpenIngres появились следующие новые возможности:

использование блокировок на уровне записи с возможностью выбора вида блокировок для указанных таблиц или для указанных пользователей; поддержка правил (триггеров) уровня оператора со срабатыванием правила для данного оператора один раз независимо от числа затрагиваемых им строк; реализация всех четырех уровней изоляции транзакций, специфицированных в стандарте языка SQL (READCOMMITTED, REPEATABLEREAD, SERIALIZABLE и READUNCOMMITTED); наличие средств параллельного копирования базы данных, хранимых на дисковых накопителях с разными контроллерами; улучшенные средства управления пространственными данными, включая индексацию на основе R-деревьев; возможность выбора размера страницы для хранения индивидуальной таблицы; более строгая оптимизация на основе развитой статистической информации, позволяющей, в частности, оценить размер результата соединения таблиц.

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

О конкретных работах, связанных с интеграцией с объектно-ориентированной СУБД Jasmine, пока не сообщается.

8.1.1.5. Серверные продукты линии DB2 компании IBM

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

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


Дейта "Руководство по реляционной СУБД DB2", хотя книга существенно отстала от практики; ее прекрасный перевод на русский язык вышел в свет в 1988 г.). Исключительно важен опыт, приобретенный при разработке этой системы. Практически во всех более поздних реляционных СУБД в той или иной степени используются методы, примененные в SystemR.

На наш взгляд, компания IBM много потеряла, ориентируя DB2 только на использование своих аппаратно-программных платформ. Первый вариант DB2 работал на IBM/370 в операционной среде OS/370. В связи с развитием аппаратуры и программного обеспечения мейнфреймов система была перенесена в операционную среду MVS. Программное обеспечение специализированного аппаратно-программного комплекса AS/400 также во многом основано на DB2. После разработки операционной системы OS/2 появился вариант DB2, пригодный для использования на персональных компьютерах. СУБД DB2 всегда представляла собой развитый программный продукт управления реляционными базами данных. В ней всегда присутствовали, в частности, такие возможности как управление транзакциями, журнализация изменений и восстановление согласованного состояния базы данных после сбоев программного обеспечения и/или аппаратуры. Заметим, что именно IBM выпустила первый корпоративный стандарт языка SQL.

Развитие системы и сферы ее применений ограничивало то, что отсутствовал мобильный текст системы. Ориентируясь на использование DB2 на своих аппаратных платформах, компания IBM исторически использовала для программирования DB2 смесь языка ассемблера и языка PL/1. Прорывом как для DB2, так и для IBM в целом стало появление Unix-ориентированной серии серверов и рабочих станций RS/6000. Именно при создании варианта системы DB2/6000 компания была вынуждена переписать систему на языке Си. После этого появилась очевидная возможность простого переноса СУБД на другие аппаратные платформы. В последнее время IBM объявила выпуск DB2 для аппаратно-программных платформ Sun и HP. По мнению автора курса, этот шаг означает появление на рынке независимых серверных продуктов управления реляционными базами данных очень серьезного и достойного конкурента.


Коротко охарактеризуем основные возможности наиболее распространенной в настоящее время версии DB2 Version 2:

1. Возможности, соответствующие требованиям реляционной модели данных:

Поддерживаются почти соответствующие полному стандарту SQL-92 средства обеспечения ссылочной целостности. Для таблицы-предка можно объявить правила удаления строк Restrict, NoAction, Cascade или SetNulls, в соответствии с которыми будут обрабатываться соответствующие строки таблицы-потомка. (При применении правила Restrict будет запрещено удаление строки таблицы-предка, если на эту строку ссылается хотя бы одна строка таблицы-потомка; задание правила Cascade приводит к автоматическому удалению ссылающихся строк таблицы-потомка; при указании правила SetNulls в поле ссылки ссылающихся строк автоматически устанавливаются неопределенные значения; правило NoAction, которое действует подобно правилу Restricted, но с другим диагностическим сообщением, устанавливается при определении ограничений ссылочной целостности по умолчанию). Возможно определение пользователем значений полей таблицы по умолчанию. Вообще-то эта возможность определена в SQL-92, и ее реализация не доставляет особого труда, но тем не менее в большинстве систем такая возможность отсутствует. Наконец-то реализовано средство, задаваемое фразой WITHCHECKOPTION при определении представления. При указании такого требования становится невозможным занести строку в представляемую таблицу или изменить существующую строку таким образом, чтобы полученная строка не была видима через представление.

2. Объекты базы данных:

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



3. Возможности запросов:

Реализованная версия языка SQL является расширенным множеством ядерного уровня языка SQL-92 и включает ряд конструкций, наличие которых предполагается в SQL-3. Поддерживаются все разновидности соединений, определенные в SQL-92, но синтаксис соответствующих конструкций отличается от стандартного.

4. Поддержка доступа из Internet:

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

IBM активно ведет работу по созданию собственного универсального сервера. С августа 1997 г. доступна бета-версия DB2 UniversalDatabase. Этот продукт относится к категории объектно-реляционных, и мы кратко обсудим его возможности позже.

8.1.1.6. Серверные продукты управления базами данных компании Microsoft

Первые работы компании Microsoft, относящиеся к области баз данных, проводились совместно с компанией Sybase, причем Microsoft поддерживала линию OS/2, а Sybase - UNIX. Так продолжалось до 1992 г., когда компания Microsoft приняла решение о переносе SQL-сервера на платформу WindowsNT. (Заметим, кстати, что недаром серверные продукты Sybase и Microsoft называются SybaseSQLServer и MicrosoftSQLServer соответственно; у этих продуктов общие корни.) Перенос SQL сервера в среду NT сопровождался существенными переделками ядра системы и в основном был выполнен специалистами Microsoft. Первая по-настоящему работоспособная версия сервера (MSSQLServer 4.21) вышла в свет в 1994 г. для использования в среде NT 3.5. Особое внимание обращалось на развитие средств администрирования, внедрение (в час- тности, и для собственного использования) механизма хранимых процедур и т.д. В 1995 г. была выпущена версия 6.0, в которой был внедрен ряд средств, обеспечивающих удобные взаимодействия с другими продуктами Microsoft. Наконец, в 1996 г. появилась наиболее современная версия 6.5.

Перечислим основные возможности MicrosoftSQLServer 6.5:

в ядре сервера может выполняться несколько нитей, что позволяет эффективно использовать симметричные мультипроцессорные компьютеры (SMP - SymmetricMultiprocessorProcessors); поддерживается асинхронное выполнение обменов с несколькими дисковыми устройствами; обеспечивается параллельное выполнение пользовательских транзакций, операций построения индексов и загрузки данных, а также резервного копирования; при оптимизации запросов используется статистическая информация; для синхронизации параллельного доступа применяется механизм блокировок на уровне записи с автоматическим распознаванием и разрешением тупиковых ситуаций; поддерживается автоматическая репликация данных на основе журнальной информации или мгновенных снимков, включая доступность репликации в базы данных, доступные через интерфейс ODBC, и репликации "массивных" данных (типов TEXT и IMAGE); обеспечивается двухфазная фиксация распределенных транзакций; реализованы операции CUBE и ROLLUP для работы с многомерными данными в системах оперативной аналитической обработки (OnLineAnalyticalProcessing - OLAP); доступны средства интеграции с системами электронной почты, в частности, с MicrosoftExchangeServer; имеются средства, обеспечивающие доступ к SQL-серверу из Web-серверов и формирование результатов запросов в формате HTML (WebConnector и WebAssistant); развиты возможности администрирования баз данных: SQLEnterpriseManager позволяет с одного терминала управлять произвольным числом SQL-серверов; дополнительные административные процедуры могут разрабатываться на VisualBasic со встроенным SQL; реализован входной уровень стандарта SQL-92 и важные компоненты промежуточного уровня; можно использовать национальные символы, в том числе символы русского языка.

Microsoft не объявляет о планах перехода к использованию объектно-реляционного подхода. Пока развитие SQL-сервера происходит в рамках все большего внедрения в этот продукт компонентов, основанных на общей объектной архитектуре COM (ComponentObjectArchitecture - компонентная объектная архитектура). Основываясь на спецификациях OLE (ObjectLinkingandEmbedding - связывание и встраивание объектов), которые обеспечивают объектное представление различных сервисов операционной системы, а также развитие OLE - OLEDB, компания Microsoft пытается обеспечить пользователям общую объектную среду компонентов (включая данные, поддерживаемые SQL-сервером, которые могут разнообразным образом комбинироваться).

Оценка и выбор предложений интеграторов Организация тендера

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Организация высокоскоростного

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

Количество сотрудников предприятий, которым нужен регулярный компьютерный доступ к корпоративной сети, с каждым годом увеличивается. Так, по данным нью-йоркской исследовательской компании FIND/SVP, количество телекоммьютеров в 1995 году во всем мире составило 9.1 миллионов человек.

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

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

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

Анализ мирового рынка коммуникационного оборудования и услуг, проведенный редакцией журнала "DataCommunicationsInternational" совместно с ведущими исследовательскими компаниями (IDC, Dell'OroGroup, IDG, YankeyGroup и др.) показал, что в 1996 году рост доходов от продаж оборудования удаленного доступа составил 151% (в абсолютном исчислении доходы этого сектора составили 2.157 миллиарда долларов), что уступает темпам роста только коммутаторов локальных сетей (216%) и высокоскоростных сетевых адаптеров (160%). Прогноз на 1997 год также очень благоприятен - ожидается дальнейший рост продаж аппаратных средств удаленного доступа на 100% при достижении абсолютной цифры доходов в 4.308 миллиардов долларов.

Ввиду массовости клиентов, пользующихся сервисом удаленного доступа, основным видом телекоммуникационного транспорта, подходящего для этих целей остаются телефонные сети - как аналоговые, так и ISDN. Для быстрой передачи данных сети ISDN подходят в гораздо большей степени, чем узкополосные и зашумленные каналы аналоговых сетей. В секторе услуг ISDN также имеется устойчивый рост. В 1996 году он составил 102% (доходы от продажи сервисов ISDNBRI составили 1.230 миллиардов долларов), и прогнозируется рост на 99% в 1997 году.

Чуть меньшие темпы роста зафиксированы в 1996 году в секторе коммерческих услуг Internet - 78% (при абсолютной цифре доходов в 2.395 миллиардов долларов), но в 1997 году ожидается их повышение до 98%.

Сегодня разработчики средств и систем удаленного доступа преследуют следующие стратегические цели:

Повышение скорости доступа для домашних и мобильных пользователей. Скорости модемов, работающих по коммутируемым телефонным каналам, сейчас для многих видов приложений уже оказывается недостаточным. Максимальная скорость модема последнего стандарта V.34+ составляет 33.6 Кб/c и то только в случае очень хорошего качества телефонного канала.


В то же время считается, что такой популярный для удаленного доступа сервис, как WWW, требует в среднем скорости 64 Кб/c или даже 128 Кб/с. Для телекоммьютеров могут потребоваться и более высокие скорости доступа, если они используют корпоративные приложения, перекачивающие к клиенту значительные объемы данных. Поэтому остро стоит проблема доведения высокоскоростных каналов 125 Кб/с - 10 Мб/с до каждого здания и каждой квартиры по крайней мере в крупных городах. Телефонные сети ISDN - хорошее решение этой проблемы, но не долговременное, так как их скорость доступа для массовых абонентов ограничена порогом в 128 Кб/с. Большие надежды специалисты по удаленному доступу возлагают на новые технологии "последней мили", использующие существующую инфраструктуру каналов связи квартир с АТС или центрами кабельного телевидения для несимметричной высокоскоростной передачи компьютерных данных. Создание интегрированных серверов удаленного доступа, способных принимать данные от большого числа пользователей по нескольким высокоскоростным каналам. При большом числе пользователей сервер удаленного доступа, построенный по обычной схеме пула аналоговых модемов становится слишком сложным в обслуживании - слишком большим становится необходимое число модемов, кабелей, кроссовых средств, телефонных номеров и т.п. Интегрированный сервер должен одновременно обслуживать несколько сотен соединений по таким высокоскоростным каналам как T1/E1, ISDNPRI или SONET/SDH. Создание централизованной системы аутентификации удаленных корпоративных пользователей, взаимодействующей с системой аутентификации провайдеров территориальных сетей (POTS, ISDN) и с системами аутентификации и авторизации сетевых ОС - NDS, Kerberos и т.п.

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

|

Основные службы Intranet

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

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

Выбор стандартного программного обеспечения для Web-сервера зависит от предполагаемой интенсивности запросов к нему. Для очень небольших рабочих групп может подойти бесплатный продукт Peer Web Services, предлагаемый компанией Microsoft в составе Windows NT Workstation. Средние по масштабу предприятия могут использовать FastTrack Server компании Netscape Communications или Website Professional компании O'Reilly and Associates. К числу наиболее популярных высококлассных Web-серверов относятся Apache, разработанный для среды Unix, Internet Information Server, поставляемый с Microsoft Windows NT 4.0, Enterprise Server компании Netscape Communications и Web Server, входящий в состав Novell IntranetWare. Ниша клиентов в основном поделена между браузерами компаний Microsoft и Netscape.

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

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

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

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

Особенности архитектур приложений, ориентированных на оперативную аналитическую обработку

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

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

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

Не будем обсуждать базовые механизмы организации Web-ориентированных Intranet-приложений и, в частности, средства их интеграции с другими серверами (включая, естественно, серверы баз данных). Коснемся только языка Java, наиболее популярного на сегодня инструмента Internet/Intranet, и сопоставим особенности реализации и использования Java с языками быстрой разработки, упоминавшимися в предыдущих пунктах этого раздела.

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

Особенности проектирования корпоративных сетей

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

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

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

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


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

10.1.1. Этапы проектирования

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

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

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

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


При этом внимание концентрируется не на компьютерной системе, а на деловой практике.

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

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

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

Тестирование системы. На этом этапе должны проводиться приемочные испытания, оговоренные в контракте с интегратором.

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

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

Пандора (Gaumtlet) компании TIS

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

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

Безопасность обеспечивается при работе через firewall в обоих направлениях в соответствии с политикой безопасности, определенной для данной организации. Продукт доступен в предустановленном виде на Pentium машинах, а также как отдельный пакет для BSD/OS, SunOS4*, HP-UX, IRIX и других UNIX-систем. Открытый продукт фирмы - FWTK - на сегодняшний день является стандартом де-факто для построения firewall на уровне приложений.

Система Gauntlet получила сертификат Национального Агентства Компьютерной Безопасности США и была проверена Агентством Национальной безопасности США (NCSA). Продукт имеет сертификат Гостехкомиссии при президенте РФ номер 73, выдан 16 января 1997 года, действителен 3 года. На основании сертификационных испытаний системе присвоен класс 3Б.

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

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

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

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


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

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

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


В теоретическом плане проблемы преобразования решены, имеются реализации.

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

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

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


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

В базовом документе специфицируется эталонная модель архитектуры (OMA - ObjectManagementArchitecture) распределенной информационной системы (рисунок 9.9). Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB - ObjectRequestBroker). ORB, общие средства (CommonFacilities) и объектные службы (ObjectServices) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории "общие средства" (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.).

Рис. 9.9. Эталонная модель OMA

В основе OMA лежит базовая объектная модель COM (CoreObjectModel), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах.

Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (InterfaceDefinitionLanguage), который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMGAPI брокера объектных заявок.


Правила построения и использования ORB определены в документе OMGCORBA (CommonObjectRequestBrokerArchitecture).

Заметим, что архитектура, предложенная OMG, не является единственно возможной. В частности, альтернативные (и очень популярные) решения предлагает компания Microsoft со своей моделью SOM и продуктами OLE, ActiveX, OLEDB.

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

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

Перспективы использования сетей "голос-данные"

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

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

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

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

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


Каждый пакет заполняется замерами голоса или кадрами изображения, и после полного заполнения отправляется по сети коммутаторов. В коммутаторах этот пакет конкурирует с другими пакетами за право быть переделанным по разделяемым во времени магистральным каналам. К таким сетям относятся сети Х.25, framerelay, TCP/IP. Величины задержек данными типами сетей не гарантируются. Качество обслуживания для синхронного трафика обычно поддерживается за счет приоритетов кадров в коммутаторах или маршрутизаторах сети, но это сервис обслуживания "besteffort". Компьютерный трафик обслуживается лучше - его пульсации передаются без особых задержек и без дополнительной оплаты (Х.25 и TCP/IP), либо за небольшую дополнительную оплату (framerelay).

3.2.1. Совмещение разных типов трафика в сетях ISDN

Первичной целью разработки ISDN было намерение объединить отдельные инфраструктуры для передачи речи и цифровых данных в единую сеть, которая предоставляла бы своим пользователям как транспортные сервисы, так и сервисы более высокого уровня - факс-сервис, телетекст и т.п. Разработчики технологии ISDN не хотели ущемлять компьютерный трафик и, как это следует из рисунка рис. 3.9, предусмотрели в своих планах поддержку всех типов транспортных сервисов - и некоммутируемых, и с коммутацией каналов для голоса, и с коммутацией пакетов для данных. Однако, основы технологии ISDN были заложены давно - первый стандарт вышел в далеком 1984 году. Тогда требования компьютерного трафика к пропускной способности и пульсациям были совсем другие и скорость в 16 Кб/с, а тем более 64 Кб/с казалась вполне достаточной для большинства приложений.

Рис. 3.9. Сервисы сетей ISDN

Поэтому сервис сети с коммутацией пакетов, который реализован в сетях ISDN на управляющих каналах типа D, казалась вполне хорошей возможностью для объединения компьютеров и локальных сетей. Каналы типа D в сети ISDN образуют сеть с классическим для тех времен трехуровнем транспортным стеком (как в сетях Х.25) для передачи по сети запроса на установление соединения основных каналов - каналов B, имеющих скорость либо 2х64 Кб/с для индивидуальных пользователей, либо 30х64 для подключения офисных АТС.


В пакете запроса передается адрес конечного абонента, на основании которого коммутаторы ISDN и маршрутизируют пакет, который по дороге вызывает коммутацию основных каналов в нужном порядке. Идея разработчиков технологии ISDN состояла в том, чтобы передавать по сети каналов D не только служебные пакеты установления соединения, но и компьютерные пакеты от абонента. Скорость канала D для абонентов 2х64 (интерфейс BRI) равна 16 Кб/c, а для более мощных абонентов 30х64 (интерфейс PRI) равна 64 Кб/с.

Уже первый стандарт технологии ISDN предусматривал возможность передачи компьютерных пакетов, принятых телефонной станцией ISDN от абонента по каналу D, в чисто компьютерную сеть с коммутацией пакетов, например, Х.25. При этом телефонная сеть используется как разветвленная сеть доступа к менее географически распространенной и узкоспециализированной сети. Скорость в 16 Кб/с или 64 Кб/с очень хорошо согласовывалась со скоростью доступа сетей Х.25. Проблема совмещения синхронного и асинхронного трафика снимается с повестки дня - голос и данные хотя и передаются по одной сети, но по разным каналам (рис. 3.10).



Рис. 3.10. Доступ к сети Х.25 через D-канал ISDN

Исследование, проведенное недавно журналом DataCommunication (March 1997, N3, стр. 56А) показало, что в Европе некоторые провайдеры предоставляют своим пользователям возможность выхода в сети Х.25 через D-канал. Правда, таких провайдеров немного и этот вид сервиса обнаружить не так то просто, но там, где он есть, он очень приветствуется пользователями. Наиболее качественные услуги предлагает DeutcheTelecom под названием "ISDND-kanal-zugangzuX.25-Netzen". Скорость доступа для компьютерного трафика обычно составляет 9.6 Кб/с (остаток пропускной способности после передачи телефонных вызовов). Плата за инсталляцию составляет $79 при уже имеющемся канале ISDN, плюс $91 за подключение к сети провайдера Х.25. Месячная плата имеет такую структуру:

$54 за первый терминал (до 4-х терминалов, за остальные дешевле); $36 провайдеру сети Х.25; первый мегабайт трафика бесплатно, 2-й и 3-й - по $ 0.00037 за 64 байтовое сообщение, свыше 3 мегабайт - по $ 0.0035 за 64 байтовое сообщение.



Аналогичный сервис предлагают FranceTelecom, PostandTelecomAustria, PTTTelecomB.V. (Нидерланды), SwissTelecomPTT, TelenorA/S (Норвегия).

D-канал представляется в таких случаях как постоянное и дешевое соединение Х.25. Обычно через D-канал пользователю разрешается иметь большое количество постоянных виртуальных соединений - от 20 у SwissTelecom до 4095 у FranceTelecom.

Для использования доступа к сети Х.25 через D-канал абонент должен использовать обычное для терминального оборудования - терминальный адаптер или маршрутизатор с ISDN-портом.

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

Однако, время с момента разработки стандартов ISDN прошло немало и скорость передачи данных в 16 Кб/с достаточна только для доступа индивидуальных пользователей или совсем небольших локальных сетей (и то не для всех современных приложений). Поэтому сети ISDN сейчас и рассматриваются в основном как транспорт удаленного доступа, но не как транспорт магистралей.

Но даже для удаленного доступа скорость 16 Кб/c часто оказывается слишком низкой и для передачи данных пользователи предпочитают использовать основные каналы типа B. В этом случае два канала интерфейса BRI дают скорость 128 Кб/c, а 30 каналов интерфейса PRI - скорость 2 Мб/с. Но в этом случае пользователи получают сервис коммутации каналов, а значит и сеть ISDN будет использоваться только как более скоростная и менее зашумленная обычная телефонная сеть, без качественной интеграции услуг.

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

---

---