ИТ. Лекция 1_Информационные технологии. Оглавление введение в информационные технологии 2Понятие информационной технологии 2Составляющие информационных технологий
 Скачать 1.19 Mb.
|
|
Технологии распределенной обработки данных Одной из важнейших сетевых технологий является распределенная обработка дан- ных, позволяющая повысить эффективность удовлетворения информационной потребно- сти пользователя и, обеспечить гибкость и оперативность принимаемых им решений. Суть распределенной обработки данных заключается в том, что в решении задачи задействова- ны ресурсы множества компьютеров сети. При этом эти ресурсы могут быть распределе- ны по отдельным функциональным сферам деятельности, а обработка данных децентра- лизована. Распределение предполагает разбиение компонентов на мелкие части и по- следующее разнесение этих частей по системе. Хорошим примером распределения является система доменных имен Интернета — DNS (рис. 4.2.). Пространство DNS-имен организовано иерархически, в виде дерева доме- нов, которые разбиты на неперекрывающиеся зоны,. Имена каждой зоны обрабатываются одним сервером имен. Чтобы получить IP-адрес хоста, имеющего доменное имя www.zil.mnt.ru , сначала происходит обращение к серверу имен зоны .ru, который возвра- щает адрес сервера имен зоны .mnt.ru, который, в свою очередь, вернет адрес zil.mnt.ru. Этот сервер способен обработать последнюю часть имени и вернуть адрес соответствую- щего хоста. 63 Рис. 4.2. Доменная система имен Распределенная база данных — это БД, разделенная на логически связанные фраг- менты, которые размещены на различных узлах сети. Фрагменты распределенной БД могут реплицироваться, т.е. копии одного фрагмента хранятся на нескольких узлах, с тем, чтобы обеспечить целостность БД даже если один из узлов выйдет из строя. При этом возникает проблема согласованности (т.е. одновременно- го обновления) фрагментов. Работа с распределенной БД может осуществляться как с тех же самых компьюте- рах, где хранятся ее фрагменты, так и с любого другого узла сети — посредством распре- деленной (сетевой) СУБД. Распределенная СУБД — это СУБД, способная обрабатывать распределенные запросы (транзакции), затрагивающие несколько баз данных на различ- ных узлах. Распределенные СУБД подразделяются на однородные и разнородные. В однород- ных системах все узлы используют один и тот же тип СУБД. В разнородных системах на узлах могут функционировать различные типы СУБД, использующие разные модели дан- ных. Однородные системы значительно проще проектировать и сопровождать, добавляя новые узлы к уже существующей распределенной системе и повышая производительность системы за счет параллельной обработки информации. Разнородные системы обычно воз- никают в тех случаях, когда узлы, уже эксплуатирующие свои собственные системы с БД, со временем интегрируются в распределенную систему. Основные условия и требования к распределенной обработке данных: 1. Прозрачность относительно расположения данных. Предполагает использование в прикладных программах такого интерфейса с сервером БД, который позволяет перено- сить данные в сети с одного узла на другой, не требуя модификации текста программы. Если база данных находится на удаленном компьютере, то для того, чтобы локаль- ная программа могла получить доступ к ней, необходимо указать кроме имени БД имя удаленного узла. Если использовать жестко фиксированное имя узла, программа стано- вится зависимой от расположения БД. Одно из возможных решений состоит в ис- 64 пользовании виртуальных имен узлов. Управление ими обеспечивается специальным про- граммным компонентом СУБД — сервером имен. 2. Гетерогенность системы. СУБД должна работать с данными, которые хранятся в системах с различной архитектурой и производительностью. 3. Прозрачность относительно сети. Программное обеспечение должно одинаково работать в условиях разнородных сетей независимо как от сетевого аппаратного обеспе- чения, так и от протоколов сетевого обмена. 4. Поддержка распределенных запросов. Пользователь должен иметь возможность объединять данные из любых баз, даже если они размещены в разных системах. 5. Поддержка распределенных изменений. Пользователь должен иметь возможность изменять данные в любых базах, на доступ к которым у него есть права, даже если эти ба- зы размещены в разных системах. 6. Поддержка распределенных транзакций. СУБД должна выполнять транзакции, выходящие за рамки одной вычислительной системы, и поддерживать целостность рас- пределенной БД даже при возникновении отказов как в отдельных системах, так и в сети. 7. Безопасность. Защита всей системы от несанкционированного доступа. 8. Универсальность доступа. СУБД должна обеспечивать единую методику доступа ко всем данным. Следует отметить, что распределенная обработка данных не обязательно выполняет- ся в распределенной системе в полном смысле этого слова (т.е. требование сокрытия сете- вой природы системы не является обязательным). Технология клиент-сервер Практически все модели организации удаленного взаимодействия пользователя с БД построены на основе модели «клиент-сервер». Это технология взаимодействия двух про- грамм (или ЭВМ), каждая из которых имеет свое назначение и выполняет свою опреде- ленную роль. Сервер — это компьютер, управляющий тем или иным ресурсом или про- грамма, предоставляющая доступ к этому ресурсу. Клиент — это программа (или ЭВМ), запрашивающая у сервера требуемый ресурс. В распределенных системах функции при- кладной программы разбиваются на две части. Одна часть реализуется в программе- клиенте, а другая — в программе-сервере и для их взаимодействия определяется некото- рый протокол. Рассмотрим эти функции. Один из основных принципов технологии клиент-сервер заключается в разделении функций стандартного интерактивного приложения на три группы, имеющие различную природу. Первая группа — функции, с помощью которых пользователь взаимодействует с приложением (в основном — функции ввода и отображения данных). Вторая группа — объединяет чисто прикладные функции, характерные для данной предметной области (для банковской системы — открытие счета, перевод денег с одного счета на другой и т.д.). 65 Третья группа — фундаментальные функции хранения и управления информацион- но-вычислительными ресурсами (базами данных, файловыми системами и т.д.). Четвертая группа — служебные функции, осуществляющие связь между функция- ми первых трех групп. В соответствии с этим в любом приложении выделяются следующие компоненты: компонент представления (функции первой группы), прикладной компонент, (функции второй группы) и компонент доступа к данным (функции третьей группы), а также вво- дятся соглашения о способах их взаимодействия (т.е., разрабатывается протокол взаимо- действия). Различия в реализации технологии клиент-сервер определяются: — видами ПО, в которые интегрирован каждый из этих компонентов; — механизмами ПО, используемыми для реализации функций всех трех групп; — способом распределения логических компонентов между компьютерами в сети; — механизмами, используемыми для связи компонентов между собой. Выделяются четыре основных подхода, реализованные в следующих моделях: 1. Модель файлового сервера. (FS) Один из узлов сети считается файловым сервером и предоставляет другим компью- терам услуги по доступу к файлам, хранящимся на этом узле. Серверная часть программы содержит только компонент доступа к данным (файлам). На других ПК в сети функцио- нирует приложение-клиент, совмещающий компонент представления и прикладной ком- понент . Протокол обмена представляет собой набор вызовов, обеспечивающих приложе- нию доступ к файловой системе на файл-сервере (рис. 4.3). Рис. 4.3. Модель файлового сервера К недостаткам данной модели относят высокий сетевой трафик (передача множества файлов, необходимых приложению), небольшое количество операций манипуляции с данными (файлами), отсутствие адекватных средств безопасности доступа к данным (за- щита только на уровне файловой системы) и т.д. 2. Модель доступа к удаленным данным (RDA) В RDA-модели сервер и клиент имеют структуру, аналогичную модели файлового сервера: компонент представления и прикладной компонент выполняются на клиенте, а сервер содержит компонент доступа к данным. Однако данные хранятся на сервере в базе данных (а не в виде файлов), а доступ к ним обеспечивается посредством стандартного языка запросов SQL. Т.е. клиент (прикладной компонент) отправляет серверу SQL- запросы и получает в ответ совокупность данных, представленных в виде таблицы (кото- 66 рые потом обрабатываются на клиенте). Часто, говоря о модели «клиент-сервер», подра- зумевают именно эту разновидность (рис. 4.4). Рис. 4.4. Модель доступа к удаленным данным Основное достоинство модели заключается в унификации интерфейса клиент-сервер в виде языка SQL и широком выборе средств разработки приложений. К недостаткам можно отнести существенную загрузку сети при взаимодействии клиента и сервера по- средством SQL-запросов (т.к. по сети передаются избыточные блоки данных). Однако мо- дель является оптимальной для ситуации высокопроизводительных клиентов и относи- тельно низкопроизводительного сервера. 3. Модель сервера баз данных (DBS) В основе модели лежит механизм хранимых процедур. Хранимая процедура опери- рует данными, содержащимися в БД, и возвращает результат их обработки. В модели DBS прикладной компонент представляет собой набор хранимых процедур, которые хранятся и выполняются непосредственно на сервере, а клиентское приложение (по сути содержа- щее лишь компонент представления) вызывает эти процедуры, передавая по сети их иден- тификаторы и параметры (рис. 4.5). Рис. 4.5. Модель сервера баз данных Достоинства DBS-модели: возможность централизованного администрирования прикладных функций; снижение трафика (вместо SQL-запросов по сети направляются вы- зовы хранимых процедур, а вместо таблиц с «сырыми» данными — только результаты их обработки); возможность разделения процедуры между несколькими приложениями; эко- номия ресурсов компьютера за счет использования единожды созданного плана выполне- ния процедуры. К недостаткам относится ограниченность средств написания хранимых процедур, представляющих собой разнообразные процедурные расширения SQL, которые уступают по изобразительным средствам и функциональным возможностям в сравнении с высоко- уровневыми языками программирования. Сфера их использования ограничена конкретной СУБД из-за отсутствия возможности отладки и тестирования разнообразных хранимых процедур. На практике чаще используются смешанные модели, когда целостность базы данных и некоторые простейшие прикладные функции обеспечиваются хранимыми про- 67 цедурами (DBS-модель), а более сложные функции реализуются непосредственно в при- кладной программе, которая выполняется на компьютере-клиенте (RDA-модель). 4. Модель сервера приложений (AS) В модели сервера приложений (рис. 4.6) компоненты приложения разнесены на три части. Клиентская часть содержит компонент представления. Серверная часть выполнена аналогично модели доступа к удаленным данным RDA (выполняет SQL-запросы к БД, расположенной на сервере). Третья часть — промежуточная — выступает в роли клиента и сервера одновременно, содержит прикладной компонент и называется сервером прило- жений. Сервер приложений организован как группа процедур (процессов), выполняющих определенные прикладные функции. Клиент обращается к серверу приложений через API (то есть, посылает идентификатор интересующей его процедуры и набор параметров и ждет получения результата). Функционирующие на сервере приложений процедуры, в свою очередь, обращаются к серверу баз данных (причем, могут использоваться разные сервера). Трехзвенная архитектура позволяет добиться максимальной гибкости при проек- тировании приложений клиент-сервер. Рис. 4.6. Модель сервера приложений Объектно-ориентированные технологии распределенной обработки Сегодня наибольшее применение для разработок приложений распределенной обра- ботки находят две объектно-ориентированные (компонентные) модели— DCOM и COR- BA. Эти технологии реализуют трехуровневую архитектуру модели «клиент-сервер». В основе их лежит модель сервера приложений, которому делегированы полномочия орга- низации взаимодействия клиента и сервера, что обеспечивает возможность интеграции объектов, размешенных на машинах разных платформ и под управлением разных ОС. Обе модели распространяют принципы вызова удаленных процедур на объектные распределенные приложения и обеспечивают прозрачность реализации и физического размещения серверного объекта для клиентской части приложения; поддерживают воз- можность взаимодействия объектов, созданных на различных объектно-ориентированных языках и скрывают от приложения детали сетевого взаимодействия. COM (Component Object Model — объектная модель компонентов) — это техноло- гический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов (COM-компонентов), каждый из которых может использоваться во многих программах одновременно. Технология DCOM (Distributed COM — распределённая COM) позволяет COM-компонентам взаимодейство- вать друг с другом по сети. 68 В DCOM-технологии (рис. 4.7) взаимодействие между клиентом и сервером осуще- ствляется через двух посредников. Посредник, работающий на стороне клиента называет- ся заместитель (proxy), а посредник, работающий на стороне сервера — заглушка (stub). Объект, с которым работает приложение, размещается на сервере. Заместитель объекта поддерживает точно такой же интерфейс (т.е. имеет одинаковый с ним набор методов). Приложение вместо метода самого объекта вызывает метод заместителя, который, упако- вывает его параметры в так называемый COM-пакет и передает его заглушке. Заглушка, в свою очередь, распаковывает параметры и иницииирует вызов метода «настоящего» объ- екта. Точно так же в обратном направлении передается значение, возвращаемое методом. Объект должен быть предварительно зарегистрирован на локальной машине, чтобы кли- ент с помощью распределенной службы имен (в качестве которой Microsoft предлагает Active Directory) мог его отыскать по глобальному уникальному идентификатору (GUID). Рис. 4.7. Взаимодействие с удаленным объектом в технологии DCOM CORBA (Common Object Request Broker Architecture — общая архитектура брокера объектных запросов) — технологический стандарт написания распределённых приложе- ний, продвигаемый консорциумом OMG. Задача CORBA — осуществить интеграцию изо- лированных систем, дать возможность программам, написанным на разных языках, рабо- тающим на разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса. Основой технологии CORBA является ORB (Object Request Broker, брокер объект- ных запросов), позволяющий передавать сообщения от одного объекта к другому. Брокер может быть реализован в виде библиотеки, специального сетевого сервиса, объектно- ориентированной СУБД или уже быть включенным в операционную систему. ORB дает возможность не задумываться объектам, которых он обслуживает, о том, где находятся другие объекты, которым передаются сообщения. Кроме того, он скрывает все детали реализации объектов, оставляя снаружи только их интерфейсы. Схема взаимодействия удаленный объектов CORBA похожа на схему DCOM (рис. 15), но включает промежуточное звено (Smart agent), представляющее собой сетевой ката- лог известных ему серверов объектов. Регистрация объектов сервера в каталоге одного или нескольких Smart agent'oв происходит автоматически при создании сервера. 69 Рис. 4.8. Обращение к удаленному объекту в технологии CORBA На машине клиента создаются два объекта-посредника: заглушка (Stab) брокер ORB. Клиентское приложение вместо самого объекта обращается к заглушке (имеющей тот же интерфейс). Заглушка обращается к брокеру, который посылает широковещательное со- общение в сеть. Smart agent, получив сообщение, отыскивает сетевой адрес сервера данно- го объекта и передает запрос брокеру, размещенному на машине сервера. Вызов требуе- мого объекта производится через специальный базовый объектный адаптер (BOA). При этом параметры метода в стек пространства вызываемого объекта помещает особый объ- ект сервера — каркас (Skeleton), который вызывается адаптером. CORBA имеет два механизма реализации запросов к объектам: — статический, предполагающий использование заглушек и каркасов, интерфейсы которых были сгенерированы при создании объекта; — динамический вызов с помощью интерфейса динамического вызова (DII), позво- ляющего определять объекты и их интерфейсы во время выполнения, а затем формиро- вать заглушки. Аналогично, на стороне сервера может использоваться динамический ин- терфейс каркасов (DSI), что позволяет обращаться к реализации объекта, для которого на этапе создания не был сформирован каркас. Ключевым компонентом архитектуры CORBA является язык описания интерфейсов IDL, на уровне которого поддерживаются «контрактные» отношения между клиентом и сервером и обеспечивается независимость от конкретного объектно-ориентированного языка. CORBA IDL поддерживает основные понятия объектно-ориентированной парадиг- мы (инкапсуляцию, полиморфизм и наследование). При этом CORBA-объекты могут быть преобразованы в объекты языков программирования (например, Java, C++), т. е. будут сформированы файлы: — исходного клиентского кода, содержащего интерфейсные заглушки; — исходного серверного кода, содержащего каркасы; — заголовков, которые включаются в клиентскую и серверную программы. В модели DCOM также может использоваться разработанный Microsoft IDL-язык, который, однако, играет вспомогательную роль и используется в основном для удобства описания объектов. Реальная интеграция объектов в DCOM происходит не на уровне аб- страктных интерфейсов, а на уровне бинарных кодов, и это одно из основных различий этих двух объектных моделей. 70 |