Файл: Учебное пособие 2 3 содержание введение.pdf

62
сунка Paint в документ Word, вставка электронной таблицы Excel в документ Word.
На рисунке 11 показана схема OLE-взаимодействия приложений.
Рис. 11. Схема OLE-взаимодействия приложений.
В рамках технологии OLE базовым является понятие «документ».
Документ – это «базовый» объект, с которым происходит связывание или в который происходит внедрение других объектов.
Связывание объекта (Linking) – действие, при котором объект не переходит к клиенту, а последний хранит о нем визуальное представ- ление и его адрес в сервере. Если в сервере объект изменился, то и клиент будет его иметь в изменённом виде.
Внедрение объекта (Embedding) – действие, при котором объект переходит к клиенту, а последний запоминает сервер и при необходи- мости редактировать объект он обращается к серверу для проведения этого действия;
Копирование объекта – одномоментное действие, при котором объект теряет связь с сервером и переходит к клиенту;
OLE-объект – это часть данных, которая совместно используется несколькими приложениями.
OLE-контейнер – приложение, в которое может быть встроен
OLE-объект.
OLE-сервер – приложение, которое способно создавать и обслу- живать OLE-объекты.
В настоящее время OLE функционирует на базе использования
COM-технологии. Современная версия OLE, основанная на COM, на- зывается OLE 2.0.
Особенности OLE 2.0:
- наличие идентификаторов (уникальных номеров) объектов;

63
- возможность объединения функциональных возможностей приложений (слияние панелей инструментов и меню).
К достоинствам OLE относятся:
- стандартность;
- открытость;
- более высокое, по сравнению с DDE, быстродействие;
- более высокая надёжность.
Последние достоинства обусловлены непосредственным контак- том между взаимодействующими приложениями.
Недостатки OLE:
- нет принципиальных ограничений на действия встраиваемых объектов;
- отсутствуют стандартные механизмы информирования о со- бытиях.
Очевидно, что в процессе взаимодействия приложений между со- бой они могут играть различные роли. Одно приложение, например
OLE-сервер, предоставляет реализованные в нем данные и методы их обработки, другое приложение, например OLE-контейнер, использует предоставляемые ему возможности. Разделение ролей между прило- жениями (или между частями одного приложения) получило свое раз- витие и привело к появлению архитектуры приложений типа «клиент- сервер».
7.3. Приложения типа «клиент-сервер»
Словосочетание «клиент-сервер» с некоторых пор стало привыч- ным, особенно в контексте доступа к базам данных. Точнее, «для ши- рокой публики» оно стало означать «клиент - сервер базы данных».
На самом деле концепция «клиент-сервер» значительно мощнее, чем принято об этом думать. Идея данной концепции основана на по- нятии «сервиса» - некоторого действия, совершить которое зачем-либо требуется стороне A, и которое она сама выполнять не умеет. Зато сто- роне B совершение этого действия не нужно, но как раз она-то и умеет его совершать. В таком случае сторона A каким-то образом вынуждает сторону B совершить это действие и предоставить стороне А резуль- тат. В таком взаимодействии сторона, которая умеет совершать дейст- вие, но не имеет никакой инициативы его совершения, называется
«сервером», а сторона, которая состоит только из инициативы - назы- вается «клиентом». В этом взаимодействии «клиент» запрашивает, а
«сервер» предоставляет «сервис».
Многие привычные случаи программного взаимодействия можно переосмыслить под этим углом, например, внутри обычной программы

64
«вызывающая процедура» очевидно, является клиентом, а «вызывае- мая» - сервером. Просто о них не принято думать в таких терминах, хотя ничего некорректного в этом нет. И во взаимодействии каких- либо машин, программ, объектов, когда один запрашивает у другого совершить какое-либо действие запрашивающий - всегда клиент, а исполняющий – всегда сервер.
Понятия клиента и сервера - динамические понятия. В диалоге объектов, т.е. когда они вызывают друг друга попеременно, в разном взаимодействии каждый из них попеременно будет и клиентом и сер- вером. Таким образом, термин никоим образом не означает иной спе- циализации, чем это требуется для самого взаимодействия.
Клиент-приложение– в клиент-серверной архитектуре означает приложение, имеющее минимум собственного исполняемого кода, основная функциональная часть которого осуществляется на сервере.
Клиент часто служит для обеспечения взаимодействия пользователя и сервера. Соединение клиента с сервером происходит либо по локаль- ной сети, либо по сети Интернет. В отдельных случаях клиентская и серверная часть приложения могут быть расположены на одном ком- пьютере.
Сервер-приложение– в клиент-серверной архитектуре означает приложение, предоставляющее заложенные в нем функциональные возможности (сервисы) приложению-клиенту. Как правило, приложе- ние-сервер не предназначено для общения с пользователем.
Остаётся открытым вопрос о том, каким же образом осуществля- ется связь между клиентом и сервером. В случае использования опера- ционной системы Windows (начиная с версии Windows 98) в качестве механизмов взаимодействия приложений используются технологии
COM и DCOM.
Таким образом, в операционной системе Windows под клиент- серверным приложением можно понимать распределённое приложе- ние, реализованное в виде совокупности компонентов, связанных при помощи технологий COM и/или DCOM (не нужно путать с коммуни- кационным интерфейсом RS-232, который тоже часто называют COM- интерфейсом или COM-портом).

7.4. Описание технологии – COM/DCOM
COM (Component Object Model – модель многокомпонентных
объектов) - технология.Для инструментальных систем и систем управления, реализованных на платформе Windows, фирмой Microsoft предложена архитектура компонентных объектов.

65
Компонент – это готовый к использованию двоичный код, со- держащийся либо в динамической библиотеке (DLL), либо в EXE- файле, который может быть при необходимости загружен в память и стандартным образом динамически подключён к приложению. Две основные черты компонентов:
- динамическое связывание – означает, что связь компонента и приложения (т.е. связь между вызовом функции в приложении и ее кодом в теле компонента) осуществляется не на этапе компоновки приложения, а непосредственно во время его выполнения;
- скрытая внутренняя реализация (инкапсуляция) – означает, что для приложения не важно, и приложение не знает, как именно реа- лизован компонент внутри, а только знает, как вызывать его функции.
Традиционно приложение состояло из отдельных файлов, моду- лей или классов, которые компилировались и компоновались вместе.
Разработка приложений из компонентов - так называемых приложений компонентной архитектуры - происходит иначе. Компонент подобен мини-приложению, он поставляется пользователю как двоичный код, скомпилированный, скомпонованный и готовый к использованию.
Модификация или расширение приложения сводится к замене одного из составляющих его компонентов новой версией.
Один из наиболее многообещающих аспектов компонентной ар- хитектуры - это быстрая разработка и развитие приложений. Из накап- ливаемого набора компонентов в библиотеках можно будет собирать, как из деталей конструктора, требуемые цельные приложения.
Распределённые компоненты.С возрастанием производительно- сти и общего значения сетей потребность в приложениях, распреде- лённых по различным узлам сети/сетей, будет обостряться. Компо- нентная архитектура позволяет упростить процесс разработки подоб- ных распределённых приложений. Приложения клиент-сервер - это шаг в сторону компонентной архитектуры, поскольку они разделены на две части, клиентскую и серверную.
Создать из обычного приложения распределённое, безусловно, легче, если это приложение состоит из компонентов. Во-первых, оно уже разделено на функциональные части, которые могут располагаться вдали друг от друга. Во-вторых, поскольку компоненты заменяемы, вместо некоторого компонента можно подставить другой, единствен- ной задачей которого будет обеспечивать связь с удалённым компо- нентом. Так, если некоторые компоненты А и В переносятся с локаль- ной машины на удалённые, то на локальной вместо компонентов А и В появляются переадресовщики, которые перенаправляют запросы к данным компонентам по сети. При наличии подходящих переадре-

66
сующих компонентов приложение может совершенно игнорировать фактическое местоположение своих частей.
Приложение, использующее компонент, называется клиентом для данного компонента. Таким образом, компонентная модель имеет ана- логию с клиент-серверной архитектурой. Компонент подключается к приложению через интерфейс, единый для приложения-клиента и компонента. Отметим, что, для того, чтобы подключить к приложению компонент, важно знать, какой интерфейс он использует.
Если компонент изменяется без изменения интерфейса, то изме- нений в клиенте не требуется. Аналогично, если сам клиент изменится без изменения интерфейса, все созданные ранее компоненты можно будет продолжать подключать. Таким образом, достигается одно из важных преимуществ технологии COM – возможность раздельной разработки приложения, а также лёгкость его модифицирования.
Таким образом, COM - это спецификация, указывающая, как соз- давать динамически взаимозаменяемые компоненты. COM определяет стандарт, которому должны следовать компоненты и клиенты, чтобы гарантировать возможность совместной работы. Компоненты COM состоят из исполняемого кода, распространяемого в виде динамически компонуемых библиотек (DLL) или EXE-файлов Win32. Но сама по себе динамическая компоновка не обеспечивает компонентной архи- тектуры. Компоненты COM объявляют о своём присутствии стандарт- ным способом. Используя схему объявлений COM, клиенты могут ди- намически находить нужные компоненты. Отметим, что реализация этой возможности возложена на операционную систему.
Интерфейс COM включает в себя набор функций, которые реали- зуются компонентами и используются клиентами. Интерфейсом в
COM является определённая структура в памяти, содержащая массив указателей на функции, как показано на рисунке 12.
Рис. 12. Интерфейс COM.

67
Сегодня можно с большой уверенностью говорить о том, что со- временный процесс генерации конечного приложения всё более напо- минает не традиционный процесс разработки прикладного программ- ного обеспечения, а процесс компонентной сборки. Соответственно качественно меняется характер труда прикладного программиста.
DCOM (Distributed Component Object Model – модель распреде-
лённых компонентных объектов)- программная архитектура, разрабо- танная компанией Microsoft для распределения приложений между несколькими компьютерами в сети. Программный компонент на одной из машин может использовать DCOM для передачи сообщения (его называют удалённым вызовом процедуры) компоненту на другой ма- шине. DCOM автоматически устанавливает соединение, передаёт со- общение и возвращает ответ удалённого компонента. В принципе, в случае использования технологии DCOM не важно, находятся клиент- ская часть приложения и компонент (сервер), на разных ЭВМ или на одной. На рисунке 13 показана схема взаимодействия приложения и компонента при помощи интерфейса DCOM.
Приложение
(клиент)
Интерфейс
COM
Интерфейс
COM
Компонент
(сервер)
Интерфейс DCOM
Локальная вычислительная сеть
Рис. 13. Взаимодействие через интерфейс DCOM.
Распределённая компонентная архитектура DCOM поддерживает множество распространённых сетевых протоколов: TCP/IP, UDP,
IPX/SPX, NetBIOS и др., поэтому программы, использующие техноло- гию DCOM, могут работать в различных типах сетей.
7.5. Описание компонентной объектной архитектуры -
CORBA
Конкурентом модели COM/DCOM фирмы Microsoft, использую- щим аналогичную компонентную сборку программ, является архитек- тура CORBA -Common Object Request Broker Architecture (общая архи-
тектура брокеров объектных запросов), разработанная и развиваемая консорциумом OMG, куда входят более 800 компаний и среди них такие гиганты как IBM, HP, DEC.

68
Она также определяет стандарт промежуточного уровня про- граммного обеспечения связи компонентов. Архитектура промежуточ- ного уровня базируется на следующих базовых принципах:
- компоненты программ могут находиться в разных исполняе- мых файлах, размещаться в разных технических средствах;
- компоненты могут быть написаны на разных языках про- граммирования и выполняться под разными операционными система- ми.
Реализация указанных принципов в модели CORBA сходна с их реализацией в модели DCOM, однако существует ряд программных различий.
Перечислим некоторые из них, имеющие отношение к сферам использования этих моделей:
-
COM/DCOM разрабатывалась под операционные системы
Microsoft (Windows) и затем уже расширялась на другие операционные системы, тогда как CORBA с самого начала нацелена на разнообраз- ные операционные системы;
-
COM/DCOM по сравнению с CORBA более ограничена в разнообразной языковой поддержке компонентов, тогда как CORBA с самого начала нацелена на гетерогенную среду.
В клиент-серверных системах масштаба отдельного предприятия с типовой операционной системой Windows и с преимущественно на- стольными системами более широкое использование получила модель
DCOM.
В крупных холдингах и целых отраслях с программной и аппа- ратной многоплатформенностью, при необходимости интеграции с унаследованными приложениями на мейнфреймах наибольшее число приложений получила модель CORBA.
Ряд компаний разработали взаимодействие между моделями
DCOM и CORBA, что позволяет сосуществовать в системе объектам как той, так и другой модели.
7.6. Описание взаимодействия на базе архитектуры
ActiveX
ActiveX – это технология Microsoft, предназначенная для написа- ния сетевых приложений. Она предоставляет программистам наборы стандартных библиотек, значительно облегчающих процесс разработ- ки приложений. Если раньше при написании программ использовались механизмы OLE, основанные на компонентной объектной модели
(COM), то теперь библиотеки OLE переписаны так, чтобы обеспечи-

69
вать функциональность, необходимую и достаточную для написания сетевых приложений. Теперь при написании программ используется
DCOM, а реализуют ее библиотеки ActiveX, которые по объему оказа- лись гораздо меньше, чем библиотеки OLE, а по скорости - быстрее.
Сохранилась и совместимость - любой программный компонент OLE будет работать с библиотеками ActiveX. Программы, написанные с использованием технологии ActiveX, находят применение, прежде всего, в интернете. В то же время технология ActiveX имеет значи- тельно более универсальную область использования.
Стандарт ActiveX позволяет программным компонентам взаимо- действовать друг с другом по сети независимо от языка программиро- вания, на котором они написаны. ActiveX обеспечивает некий «скреп- ляющий раствор», с помощью которого отдельные программные ком- поненты на разных компьютерах «склеиваются» в единую распреде- лённую систему.
Технология ActiveX включает в себя клиентские и серверные компоненты, а также библиотеки для разработчика.
Программные элементы ActiveX - это компоненты, работающие на компьютере-клиенте, но загружаемые в первый раз с сервера. Эти программные компоненты могут использоваться в приложениях, напи- санных на любых популярных языках программирования, включая
Java (Visual J++), Visual Basic, Visual C++.
Не нужно ассоциировать ActiveX с интернетом. ActiveX предос- тавляет стандартный открытый метод для расширения возможностей любых приложений.
Приложение, к которому подключается ActiveX-компонент, на- зывается контейнером для данного компонента. В процессе взаимо- действия ActiveX-компонента и контейнера компонент может переда- вать контейнеру данные, методы и события. Отметим, что механизм передачи событий не поддерживается при OLE-взаимодействии.
Существует два основных способа реализации ActiveX- компонентов:
- встроенные в процесс (единое пространство памяти позволя- ет увеличить быстродействие);
- выполняемые в отдельном процессе (возможна организация распределённой архитектуры).
Основными преимуществами использования технологии ActiveX являются следующие.
- ускорение написания программного кода - программирова- ние распределённых приложений становится очень похожим на про- граммирование для отдельного компьютера;