Главная
Каталог
Библиотека
Избранное
Порталы
Библиотеки вузов
Отзывы
Новости
 
12+
 
Предварительный просмотр документа

Распределенные системы обработки информации: Учебно-методическое пособие

Автор/создатель: Телков А.Ю.
Год: 2007 
В данном пособии рассматриваются технологии создания распределенных систем RMI, CORBA и DCOM. Анализируются особенности объединения информационных систем с помощью технологии CORBA и WWW. Приводятся составляющие моделей взаимодействия клиентов и серверов в рассматриваемых технологиях. Даются сравнительные характеристики систем с точки зрения функциональной полноты и возможности работы на различных программно-аппаратных платформах. Приводятся выводы относительно влияния систем создания распределенных объектов на развитие всемирной сети Интернет.
Показать полное описание документа
РЕЙТИНГ

Оценка пользователей: 5.0
Количество голосов: 2
Оцените ресурс:
5 4 3 2 1

ОТЗЫВЫ


Популярные ресурсы по теме

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра. Изображения (картинки, формулы, графики) отсутствуют.
11 торые не были определены в IDL Skeleton. Object Adapter: осуществляет коммуникационное взаимодействие между объектом и ORB. Вот небольшой список достоинств и недостатков использования тех- нологии CORBA. К основным достоинствам CORBA можно отнести межязыковую и межплатформенную поддержку. Хотя CORBA-сервисы и отнесены к дос- тоинствам технологии CORBA, их в равной степени можно одновременно отнести и к недостаткам CORBA, ввиду практически полного отсутствия их реализации. Более подробное описание этих свойств можно найти в [1,3,5]. Таблица №2 Достоинства Недостатки Платформенная независимость Нет передачи параметров «по значе- нию» Языковая независимость Нет именования через URL Динамические вызовы Динамическое обнаружение объектов Масштабируемость CORBA – сервисы Широкая индустриальная поддержка Почему CORBA является наиболее эффективной, современной, при- годной для крупных проектов технологией распределенных объектов? По- тому что, хотя обе технологии — и CORBA, и DCOM чрезвычайно схожи по своей функциональности и своим возможностям (многоязыковая под- держка, динамический вызов, масштабируемость и др.), у DCOM отсутст- вует важный критический элемент — мультиплатформная поддержка. Од- ного факта, что в настоящий момент DCOM не поддерживает целиком межплатформенную переносимость, вполне достаточно, чтобы не рассмат- ривать его как полноценное, законченное решение. Кроме того, в то время как в состав OMG уже сейчас входят более 700 членов (компаний- производителей программных продуктов, компьютеров, телекоммуника- ционных систем, разработчиков прикладных систем и конечных пользова- телей), и практически любая спецификация, разработанная этим консор- 12 циумом, фактически становится стандартом, DCOM лишь недавно стал пе- реходить из рук Microsoft в руки аналогичной OMG организации — группе TOG (The Open Group). И еще один плюс технологии CORBA: круг производителей продук- тов, поддерживающих данную технологию, значительно шире, чем анало- гичный круг для DCOM. Таким образом, оказывается, что именно CORBA — технология, полностью предназначенная для промышленных, откры- тых, распределенных объектных систем. В конце 1980-х и начале 1990-х годов многие ведущие фирмы- разработчики были заняты поиском технологий, которые принесли бы ощутимую пользу на все более изменчивом рынке компьютерных разрабо- ток. В качестве такой технологии была определена область распределен- ных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использова- ние и интеграцию кода, что было особенно важно для разработчиков. Цена за повторное использование кода и интеграцию кода была высока, но ни кто из разработчиков в одиночку не мог воплотить в реальность мечту о широко используемом, языково-независимом стандарте, включающем в себя поддержку сложных многосвязных приложений. Поэтому в мае 1989 была сформирована OMG (Object Managment Group). Как уже отмечалось, сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft). Задачей консорциума OMG является определение набора специфи- каций, позволяющих строить интероперабельные информационные систе- мы. Спецификация OMG — The Common Object Request Broker Architec- ture (CORBA) является индустриальным стандартом, описывающим высо- коуровневые средства поддерживания взаимодействия объектов в распре- деленных гетерогенных средах. 13 Рисунок 4. CORBA – IDL отображения в модели Клиент/Сервер. С помощью IDL можно описать и атрибуты компоненты, и роди- тельские классы которые, она наследует, и вызываемые исключения, и, на- конец, методы, определяющие интерфейс, причем с описанием входных и выходных параметров. Структура CORBA IDL файла выглядит следующим образом: module <identifier> { <type declarations>; <constant declarations>; <exception declarations>; interface <identifier> [:<inheritance>] { <type declarations>; <constant declarations>; <attribute declarations>; <exception declarations>; [<op_type>]<identifier>(<parameters>) [raises exception] [context] [<op_type>]<identifier>(<parameters>) [raises exception] [context] } interface <identifier> [:<inheritance>] } Репозитарий Интерфейсов (Interface Repository), содержащий опре- деления интерфейсов на IDL, позволяет видеть интерфейсы доступных серверов в сети и программировать их использование в программах- клиентах. 14 Рисунок 5. OMG's Object Management Architecture Осенью 1990 года OMG впервые опубликовала документ Object Management Architecture Guide (ОМА Guide). Он был подкорректирован в сентябре 1992. Детали Common Facilities (Общие средства) были добавле- ны в январе 1995. Следующий рисунок показывает четыре основных эле- мента этой архитектуры: 1. Object Request Broker определяет объектную шину CORBA. 2. Common Object Services представляют собой коллекцию служб, снабженных объектными интерфейсами и обеспечивающих поддержку ба- зовых функций объектов [5]. 3. Common Facilities образуют набор классов и объектов, поддержи- вающих полезные во многих прикладных системах функции. Прикладные объекты представляют прикладные системы конечных пользователей и обеспечивают функции, уникальные для данной прикладной системы [5]. 4. Application Objects — это прикладные бизнес-объекты и приложе- ния, которые являются основными потребителями всей CORBA инфра- структуры. ORB (Object Request Broker, то есть брокер объектных запросов) — это объектная шина. Она позволяет объектам напрямую производить и от- вечать на запросы других объектов, расположенных как локально (на од- ном компьютере, но в разных процессах), так и удаленно. Клиента не ин- тересуют коммуникационные и другие механизмы, с помощью которых происходит взаимодействие между объектами, вызов и хранение сервер- 15 ных компонент. CORBA-спецификации затрагивают лишь IDL, отображе- ние в другие языки, APIs для взаимодействия с ORB и сервисы, предостав- ляемые ORB. CORBA ORB предоставляет широкий набор распределенных mid- dleware услуг. Шина ORB позволяет объектам находить друг друга прямо в процессе работы и вызывать друг у друга различные службы. Она является гораздо более тонкой системой, чем другие клиент/сервер middleware- системы, такие как RPC (Remote Procedure Calls) или MOM (Message- Oriented Middleware). Чем механизм вызовов CORBA отличается от механизма RPC? Да, эти механизмы похожи, но тем не менее между ними есть серьезные раз- личия [5]. С помощью RPC можно вызвать определенную функцию. А с помощью ORB можно вызвать метод у определенного объекта. Разные объекты классов могут по-разному отвечать на вызов одного и того же ме- тода. Так как каждый объект управляет свой собственной (в добавок лич- ной) информацией, то метод будет вызван на сугубо конкретных данных. В случае RPC, будет выполнен лишь какой-то конкретный кусок ко- да сервера, который и взаимодействует с данными сервера. Все функции с одинаковыми именами будут выполнены абсолютно одинаково. В RPC от- сутствует конкретизация вызовов, в том смысле, в каком это происходит в ORB. В ORB все вызовы функций происходят к конкретным объектам, тем самым, результаты этих функций могут быть совершенно различны. Вызо- вы функций обрабатываются в специфичной для каждого отдельного объ- екта форме. В теории, CORBA представляется как лучшая клиент/сервер middle- ware-система, но на практике она хороша лишь настолько, насколько хо- роши продукты, ее реализующие. К основным коммерческим ORB отно- сятся: Orbix от фирмы IONA Technologies; DSOM от IBM; ObjectBroker от Digital; JOE от Sun; Visibroker от Visigenic и Netscape; ORB+ от HP. Небольшой список тех выгод, которыми обладает каждая CORBA ORB [5]. • Статические и динамические вызовы методов. CORBA ORB пре- доставляет возможность либо статически определить вызовы методов пря- мо во время компиляции, либо находить их динамически, но уже во время работы программы. 16 • Отображение в языки высокого уровня. CORBA ORB позволяет вызывать методы у серверных компонент, используя любой из некоторого списка языков высокого уровня — С, C++, SmallTalk, Java и Ada. Совер- шенно неважно, на каком языке написаны объекты. CORBA отделяет ин- терфейсы от реализации и предоставляет языково-независимые типы дан- ных, что позволяет осуществлять вызов методов, минуя границы какого-то конкретного языка программирования и конкретной операционной систе- мы. • Само-описывающаяся система. С помощью своих метаданных, CORBA позволяет описывать интерфейс любого сервера, известного сис- теме. Каждая CORBA ORB должна поддерживать Репозитарий Интерфей- сов, который хранит необходимую информацию, описывающую синтаксис интерфейсов, поддерживаемых серверами. В своей работе клиенты ис- пользуют эти метаданные для осуществления вызовов к серверам. • Прозрачность. ORB может выполняться как сам по себе (например на портативном компьютере), так и в окружении целого мира других ORB, с которыми она взаимодействует путем CORBA 2.0 ПОР (Internet Inter- ORB Protocol) протокола. ORB может осуществлять меж-объектное взаи- модействие и для одного процесса, и для нескольких процессов, выпол- няющихся на одной машине, и для процессов, чье выполнение происходит в сети, под разными операционными системами. Реализация этих взаимо- действий, однако, нисколько не затрагивает сами объекты. В общих чер- тах, при использовании технологии CORBA, разработчик не должен бес- покоиться ни о таких вещах как расположение серверов, запуск (активиро- вание) объектов, выравнивание размера переменных в зависимости от платформы и операционной системы, ни и о том, как осуществляется пере- дача сообщений. Решение всех этих задач берет на себя продукт, поддер- живающий стандарт CORBA. • Встроенная безопасность. Все свои запросы ORB дополняет неко- торой контекстной информацией, которая обеспечивает сохранность дан- ных. • Полиморфизм при вызове методов. Как уже говорилось, ORB не просто вызывает удаленный метод — ORB вызывает метод на удаленном объекте. То есть выполнение одних и тех же функций на разных объектах будет приводить к различным действиям, в зависимости от типа объекта. 17 CORBA Object Services представляет собой набор сервисов систем- ного уровня, представляемых в виде компонент с некоторыми определен- ными IDL-интерфейсами. Эти компоненты, в некотором смысле, дополня- ют функциональность ORB. Их можно использовать для создания, имено- вания компонент и многого другого. На сегодняшний день OMG опреде- лил четырнадцать стандартных сервисов. К сожалению, практически все коммерческие ORB не поддерживают ни один из сервисов, и лишь немногие (Visibroker) — один, два. Common Facilities (общие средства) заполняют пространство между ORB и объектными службами с одной стороны, и прикладными службами, с другой. Таким образом, ORB обеспечивает базовую инфраструктуру, Ob- ject Services — фундаментальные объектные интерфейсы, а задача Common Facilities — поддержка интерфейсов сервисов высокого уровня, которые, впрочем, могут включать специализацию Object Services. Таким образом, операции, представляемые Common Facilities, предназначены, в частности, для использования Object Services и прикладными объектами. Реализуется это посредством наследования стандартных Интерфейсов [5]. Общие средства делятся на горизонтальные и вертикальные. К гори- зонтальным сервисам относятся такие общие сервисы, как, например, управление информацией, задачами, всей системой, то есть средства, не зависящие от конкретных прикладных систем. К вертикальным же отно- сятся сервисы, специфичные для какой-либо деятельности — например, медицина, финансы. Объекты, если они участвуют в обмене с ORB, должны определяться с помощью IDL. Обычно приложения состоят из нескольких взаимодейст- вующих бизнес-объектов. И, как правило, приложения-объекты строятся поверх предоставляемых ORB, Common Facilities и Object Facilities серви- сов. Суть для заказчиков (или системных интеграторов) заключается в том, чтобы собрать разные бизнес-объекты в одну систему, при том, вне зави- симости от производителя. 2.3. CORBA и объединение информационных систем в Интернет Ответ на поставленный во Введении вопрос — как объединить ин- формационные системы, основанные на технологии WWW, с другими (в том числе и распределенными) информационными системами? — заклю- 18 чается в следующем: необходимо связать технологию распределенных объектов (то есть технологию CORBA) с технологией WWW. Было выделено два различных решения поставленной задачи. Первое решение строится на применении технологии CGI, а второе — на приме- нении технологии Java. В рамках проделанной работы было исследовано практическое применение этих технологий, с использованием продуктов Orbix и OrbixWeb от IONA Technologies. В чистом виде, технология CGI состоит в следующем: для формиро- вания HTML-страницы Web-сервер запускает некий CGI-скрипт. При этом CGI-скрипт может реализовывать довольно сложную функциональную ло- гику и обращаться, например, к базе данных. CGI-скрипт представляет со- бой отдельное исполняемое приложение. Язык, на котором написан скрипт, не играет большой роли. Решение CORBA-CGI основывается на том, что исполняемый CGI- скрипт является одновременно и одной из компонент распределенной сис- темы. Главное отличие от технологии CGI заключается в том, что CGI- скрипт является не просто исполняемым модулем, а он является одновре- менно и CORBA-клиентом. В некотором смысле, скрипт служит точкой входа и выхода в распределенной системе, внутри которой могут проте- кать различные процессы. Рисунок 6. CORBA-CGI 19 К преимуществам этой технологии можно отнести практически все преимущества использования CORBA. Кроме того, пользователь работает с привычными для него HTML-страницами, что особенно важно при рабо- те с объемной текстовой информацией. Теперь о недостатках этой технологии. Практика показывает, что, во- первых — эффективность системы невысока. Каждый раз при перезагрузке страницы необходимо заново выполнять CGI-скрипт, заново устанавливать соединения с другими компонентами системы. Это не эффективно, что особенно сильно проявляется, когда система одновременно используется несколькими пользователями. Во-вторых, не жертвуя эффективностью, не- возможно своевременно уведомлять пользователя об изменениях, произо- шедших в просматриваемой им информации. Они будут видны лишь при перезагрузке страницы. То есть пользователь участвует в системе исклю- чительно в роли клиента. Частным решением проблемы эффективности выполнения CGI- запросов (особенно в многопользовательской системе), может быть рас- ширение функциональности используемого Web-сервера, путем добавле- ния в него соответствующих функций. В этой области была проделана ра- бота по встраиванию в Web-сервер Apache (платформы SunOS, Win- dows NT) поддержки обращения к Orbix ORB. Сложности также возникают при создании сложных, ветвистых пользовательских интерфейсов. Дело в том, что системе, при выполнении запросов помимо имеющейся в окне броузера информации, необходима дополнительная, скрытая от пользователя и характеризующая текущее со- стояние системы информация. Вся интерфейсная часть системы привязана к окну броузера, а выводимая на экран информация создается динамически в зависимости от параметров запроса и внутреннего состояния информа- ционной системы на некоторый момент времени. Вследствие этого, если пользователь производит неконтролируемую навигацию вперед-назад по просматриваемым страницам, повышается риск десинхронизации про- сматриваемой пользователем и хранимой на сервере информации, что не- допустимо. Второе решение проблемы связывания технологий CORBА и WWW — язык Java. Дело в том, что OMG стандартизировала отображение из IDL в Java. Имеются программные продукты, реализующие связь CORBA и 20 Java — например, OrbixWeb, Visibroker. Java-технология основана на том, что при обнаружении тега <APPLET>, броузер через сеть загружает к себе необходимые для этого апплета Java-классы и запускает его. При этом на машине пользователя запускается Java Virtual Machine (JVM), внутри ко- торой и выполняется загруженный апплет. Java-апплет, являющийся CORBA-клиентом, устанавливает все не- обходимые соединения с другими (серверными) приложениями системы и именно через него к пользователю идет вся информация. Апплет играет роль пользовательского интерфейса для данной распределенной системы. Количество выполняемых апплетов ничем не ограничено — вопрос лишь в достаточных вычислительных ресурсах системы. Рисунок 7. Java и CORBA. Такие встроенные в Java средства, как многопоточность, позволяют легко реализовывать и синхронное, и асинхронное взаимодействие аппле- тов с другими приложениями. У технологии Java-CORBA практически нет слабых мест. Единственная проблема, которая может возникнуть — необ- ходимость наличия мощных вычислительных ресурсов на стороне пользо- вателя. Это, конечно, серьезный недостаток, но он, скорее, является недос- татком языка Java. Как уже отмечалось, при использовании технологии Java-CORBA, Java-апплеты могут играть роль и клиентов, и серверов. Это позволяет соз- дание "живых" страниц, то есть страниц, информация на которых меняется практически постоянно. Например, если апплет представляет собой ото- бражение состояния некоторого устройства, то при переходе устройства из одного состояния в другое, информация в апплете практически мгновенно
Яндекс цитирования