Л.Е. Карпов - Системы программирования (1119429), страница 30
Текст из файла (страница 30)
Этакомпиляция формирует три файла:•••файл-заголовок (например, "interface.h")файл клиентского переходникафайл серверного переходникаВ файл-заголовок из исходного описания на IDL передаются уникальныйидентификатор интерфейса, определения типов, констант и описания функций(прототипы). Клиентский переходник содержит те процедуры, которые будетнепосредственно вызывать клиентская программа. Эти процедуры непосредственноотвечают за подбор параметров и их упаковку в исходящие сообщения споследующими обращениями к системе для их отправки. Переходник также занимаетсяраспаковкой ответов, приходящих от сервера, и передачей значений, содержащихся вэтих ответах, клиенту.
Серверный переходник организован также, но по отношению ксерверу.Следующий шаг – написание реальных программ клиента и сервера. После ихкомпиляции и компоновки (с библиотечными добавками) формируются обеисполняемые программы – клиентская и серверная.В целом, DCE – это попытка стандартизовать понятие удаленного вызовапроцедуры. Впоследствии, когда широко распространились принципы и приемыобъектно-ориентированного программирования, система DCE также была расширена идополнена объектно-ориентированными языками.5.2. Технологии COM/DCOMТехнология COM (Component Object Model) и ее вариант для распределенныхсистем DCOM (Distributed COM) была разработана компанией Microsoft.
DCOMявляется расширением технологии СОМ и включает в себя среду распределенныхвычислений DCE и механизм удаленного вызова процедур.Общий подход при использовании той или технологии таков: клиентскаяпрограмма использует объекты своего программного сервера так, как если бы этиобъекты являлись частью клиентской программы. Основную роль, как и во всехсистемах клиент/сервер, играет интерфейс объектов, формируемый при помощинекоторого языка IDL, в данном случае – объектно-ориентированного. Клиент знает обиспользуемых объектах только их интерфейсы. Сервер предназначен для реализацииобъектов, он представляет собой программу, содержащую, кроме всего прочего, ещеодин или несколько объектов, построенных в соответствии с моделью СОМ.107Реализации объектов создаются на основе нескольких классов, каждый из которыхпредставляет различные варианты поведения объекта.Переходкобъектно-ориентированномувзаимодействиюпривелксущественному пересмотру модели удаленного вызова процедуры и появлению моделиудаленного обращения к методу.
Эта модель основана на объектно-ориентированномрасширении понятия вызова процедуры и понятии о распределенном объекте. Методывспомогательных объектов, включаемых в состав клиентского и серверногопереходников, которые строятся для реализации удаленного обращения к методу,имеют интерфейсы в точности соответствующие интерфейсам реальных удаленныхобъектов.
Их реализации позволяют скрытым от пользователей образом организоватьмаршалинг и сериализацию параметров и возвращаемых значений методов. Как и прииспользовании "классического" удаленного вызова процедуры, при удаленномобращении к методу не только клиент не знает о том, что взаимодействует с удаленнымсервером, но и сервер не знает, что обращение к нему осуществлено со стороны.Система автоматически строит взаимодействия клиента и сервера, независимоот того, как клиент и сервер распределены по компьютерам: они могут исполняться•••на одном компьютере в рамках единого процесса, при этом взаимодействиемежду клиентом и сервером происходит при помощи интерфейса объекта ведином адресном пространстве с использованием динамических библиотек.на одной машине в рамках разных процессов, при этом между клиентом исервером возникают два промежуточных звена, а схема взаимодействиястановится похожей на сокращенную схему удаленного обращения к методу(с переходниками, маршалингом и демаршалингом, но без обращения ксети).на различных (вообще говоря, несовместимых друг с другом аппаратно иимеющих разные операционные системы) компьютерах в рамкахинформационной сети (технология DCOM), использующих модельудаленного обращения к методу полностью, включая сериализацию иобработку сообщений.Система СОМ не является системой программирования в классическомзначении этого термина.
Это, скорее, система библиотек компонентов и правил ихиспользования. Однако система COM содержит все элементы, необходимые дляпостроения распределенной системы, в частности, компонентную модель, библиотекиклассов, которые могут быть импортированы для анализа структуры серверов СОМ,универсальный протокол обмена между клиентами и серверами и другие.ТехнологиюСОМмогутподдерживатьсамыеразличные языкипрограммирования.
В настоящий момент наиболее широко используются Visual Basic,Си++ и Delphi. Однако разработчик системы (компания Microsoft) объявила этутехнологию устаревшей и активно продвигает другой подход – технологию .NET.Основной недостаток технологии COM, который и привел к отказу от нее, этосерьезные ограничения в организации взаимодействия между разными платформами,которые постоянно возникают в глобальных сетях. Определенными недостатками иограничениями обладает и выбранный для систем COM язык Microsoft IDL, в которомнедостаточно развиты средства объявления типов данных, из которых строитсяпрограмма.
В целом, технологию COM/DCOM обычно используют для построениянебольших распределенных систем, имеющих не очень большое число узлов.1085.3. Брокеры объектов CORBAБолее адекватно соответствующим принципам построения распределенныхсистем, чем системы "клиент-сервер", надо признать системы не двухуровневые, аимеющие, по крайней мере, еще один "промежуточный" уровень, позволяющийразделить решаемые задачи на "клиентские" и "серверные" части. В двухуровневыхсистемах клиентские части чаще всего связаны с отображением данных в виде,адекватно соответствующем конкретной прикладной области, назначение серверныхчастей – выполнять основные прикладные программы и программы системнойподдержки.
Наличие промежуточного уровня (для обозначения которого частоиспользуется англоязычный термин middleware) существенно расширяет возможностираспределенных систем. Системы "клиент-сервер" в качестве одной из самых своихсерьезных проблем имеют ограниченность возможностей сервера по связи со многимиклиентами одновременно. Двухъярусные архитектуры не справились с требованиями,предложенными разработчиками локальных информационных сетей. Их появлениезаставило разработчиков предпринять меры по интеграции серверов, а для размещенияпрограмм, ответственных за эту интеграцию, наилучшим образом подходилпромежуточный уровень трехуровневых систем.
Однако простой интеграциейпреимущества новых систем не ограничиваются. Трехуровневые системы обладаютсвойством масштабируемости в значительно большей степени. Если системы "клиентсервер" привели к стандартизации интерфейсов прикладного слоя, то их развитиепозволило стандартизовать интерфейсы слоя управления ресурсами, а это привело квозможности интеграции в рамках одной системы самых разнородныхинформационных ресурсов.
Возникли даже попытки стандартизовать глобальныесвойства и интерфейсы между разными системными платформами на основе объектноориентированного подхода. Одним из примеров такой стандартизации являетсястандарт брокера объектов CORBA (Common Object Request Broker Architecture).Брокером объектов называют распределенные системы программного обеспечения,основанные на использовании понятия распределенного объекта и модели удаленногообращения к методам этого объекта, являющейся объектно-ориентированнымрасширением модели удаленного вызова процедуры.Стандарт CORBA – это спецификация для создания и управления объектноориентированными приложениями, распределенными в вычислительной сети. Внастоящее время выработано несколько версий стандарта CORBA, первая из которыхбыла разработана в начале 90-х годов консорциумом Open Management Group,включавшим более 800 компаний. Все эти стандарты описывают только интерфейсы ине содержат никакой реализации.Всякая система, подчиняющаяся спецификации CORBA, состоит из трехосновных частей:••брокер запросов объектов, содержащий базовые функции взаимодействияобъектов.службы CORBA.
Набор служб, известный под этим собирательным именем,доступен с помощью стандартизованного прикладного программногоинтерфейса.Службыпредоставляютфункциональность,обычнонеобходимую большинству объектов, например, сохранность, управлениежизненным циклом и безопасность.109•средства CORBA.
Набор средств и инструментов, известный под этимсобирательным именем, предоставляет службы верхнего уровня,необходимые приложениям, а не индивидуальным объектам. Сюда входятуправление документами, интернационализация, поддержка мобильныхагентов. Средства CORBA могут также включать службы, специфичные дляотраслевых рынков, например, образования, здравоохранения илитранспортных перевозок.Чтобы к объекту можно было обратиться через брокер объектов, этот объектдолжен сначала объявить свой интерфейс, из чего клиенты узнают о методах, которыеон предоставляет. Интерфейсы описываются на языке описания интерфейсов IDL(стандарт CORBA предлагает свой собственный вариант такого языка).
СпецификацииIDL транслируются в скелетоны на стороне сервера и в переходники на сторонеклиента.interface Purchasing {float getQuote (in long productId);float purchaseGoods (in long productId,in long quantity)}IDL поставщикаслужбыкомпилятор IDL(клиентская сторона)прикладной объект(клиент)компилятор IDL(серверная сторона)прикладной объект(клиент)прикладной объект(поставщик службы)переходникскелетонинтерфейс динамического обращенияброкер запросов объектов (ORB)репозиторий интерфейсовВ дополнение к описанию методов, в отличие от систем на базе удаленноговызова процедур, язык IDL спецификации CORBA поддерживает множество объектноориентированных концепций, например, наследование и полиморфизм.
Спецификации,написанные на IDL CORBA, могут быть переданы компилятору с этого языка, которыйформирует заместителя объекта и скелетон. Заместитель объекта – это переходник,ответственный за сокрытие распределенности. Программа заместителя содержит в себеописание методов, предоставляемых реализацией объекта. Для получения готовогоклиентского приложения, она должна быть загружена вместе с программой клиента. Сдругой стороны скелетон защищает от проблем распределенности сервер, поэтому110сервер может разрабатываться так, как если бы вызовы к нему поступали из локальногоокружения.
Как заместитель, так и скелетон могут быть написаны на любом из техязыков, которые поддерживаются компилятором с языка IDL CORBA, на которые текстIDL может быть оттранслирован. Например, спецификация CORBA 3 поддерживаеттрансляцию с IDL на Си, Си++, Java, Smalltalk, Аду, Кобол, Лисп, PL/1, Python иIDLScript.Из-за различных способов употребления и различных способов реализацииссылок на объекты в языке Си++, эти ссылки при трансляции отображаются в два типаСи++. Константы IDL отображаются непосредственно в определения констант Си++.Базовые типы данных IDL имеют естественное отображение в типы данных Си++.Структурированные типы данных class, struct, union, sequence отображаютсяв структуры или классы Си++.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
