Обучающие курсы:

Обучение программированию на C# + стажировка
Обучение программированию на Python + стажировка


Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Стандарты для C++
Уроки по C#
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей



  • Укладка

    Недорогая укладка штучного паркета. Профессиональные паркетчики в Москве.

    parket-doctor.ru

  • Активатор windows 7

    Активатор windows 7

    weblifeplus.ru


Разбираем ActiveX

Любому разработчику программного обеспечения в своей повседневной практике постоянно приходится сталкиваться с двумя основополагающими технологиями, без которых сегодня не обходится ни одна инструментальная среда разработки, будь то Delphi, Oracle Developer или MS Visual Studio. Одна из этих технологий носит обобщенное название ActiveX/DCOM и распространена на Intel-платформах с семейством операционных систем Windows, а другая параллельная технология называется JavaBeans/Corba и не зависит ни от платформы, ни от операционных систем.

ActiveX/DCOM — это корпоративная технология с фирменным знаком Microsoft. Главное ее предназначение — облегчение написания сетевых распределенных объектно-ориентированных приложений. В сущности, ActiveX — это ни что иное, как обычный набор библиотек, значительно облегчающих процесс кодирования. Иногда спрашивают, в чем разница между OLE и его составными механизмами (OLE Automation, OLE Documents, OLE Controls) и элементами ActiveX?

Ответ очень прост. OLE-механизмы основаны на компонентной объектной модели (COM, Component Object Model), которая позволяет создавать объектно-ориентированные приложения на одной машине в рамках функционирующей на ней операционной системы Windows, а ActiveX использует DCOM (Distributed Component Object Model) — распределенную компонентную объектную модель, которую реализуют библиотеки ActiveX, являющиеся по объему гораздо меньше, чем библиотеки OLE, а по скорости — быстрее.

Другими словами, библиотеки OLE переписаны так, чтобы обеспечивать функциональность, достаточную для написания сетевых приложений. Сохранилась и совместимость — любой программный компонент OLE будет работать с библиотеками ActiveX. Модели СОМ и DCOM опираются на базовые сетевые протоколы, такие как TCP/IP, и входят в состав операционной системы Windows 98/2000, а для более старых реализаций всегда существует возможность инсталлировать эти компоненты из самоустанавливающегося архива (DCOM95.EXE).

Что такое СОМ и DCOM
COM (Component Object Model) расшифровывается просто — компонентная объектная модель. DCOM (Distributed Component Object Model) — это, соответственно, распределенная компонентная объектная модель.

Microsoft разрабатывает и поддерживает DCOM исключительно для создания серверов приложений и управления распределенными программными объектами. В противовес Microsoft, два других компьютерных гиганта — Sun и IBM — опираются на международный стандарт CORBA. При желании можно совместно использовать обе эти технологии.

DCOM просто расширяет возможности СОМ в части регистрации удаленных объектов, поэтому его иногда называют "СОМ с удлиненным проводом".

Прикладные интерфейсы COM API — это все те же, всем известные OLE-интерфейсы, ведущие свое происхождение от DDE (Dynamic Data Exchange) — динамического обмена данными, позволяющего единственным способом в Windows осуществлять обмен информацией между процессами.

По сути своей СОМ является простым объектным расширением OLE-технологии, когда в локальной модели средств автоматизации OLE команды от клиента проходят через модуль-инициализатор (proxy), а сообщение — в модуль-переходник (stub), где оно разбирается, анализируется и откуда посылается команда на сервер, как показано на рис 1




рис 1: Схема работы OLE Automation

Более наглядно эта же схема, но уже в спецификации СОМ, представлена на рис.2




рис 2: локальная схема взаимодействия объектов COM

Модель СОМ значительно проще с точки зрения программистов и ее гораздо удобнее использовать в небольших локальных сетях.

В дистанционной модели, которая теперь вместо СОМ получила название DCOM, инициализатор и переходник стали совершенно другими, теперь в них используются процедуры дистанционного вызова (RPC) для передачи запросов клиента по сети к модулю Remote Server Process, функционирующему на сервере. Клиентская часть DCOM, аналогичная прежнему механизму Automation Manager, передает данные клиента указанному OLE-серверу и ответные данные по сети к программе-клиенту, как показано на рис. 3.




рис 3: Схема взаимодействия для локального и удаленного вариантов

Как можно видеть из приведенных рисунков, замечательным свойством DCOM является его прозрачность как для пользователя, так и для программиста. Можно создать и запустить на своей машине сервер OLE, а потом приспособить его для работы в дистанционном режиме простым перенесением OLE-сервера на удаленный ПК, на котором работает модуль-администратор автоматизированного управления DCOM. Затем нужно просто зарегистрировать новое местоположение OLE-сервера с помощью обычной утилиты (например, из арсенала средств Visual Basic). Программисту не приходится менять ни одной строки текста программы, чтобы использовать разработанный OLE-сервер на удалении. Сейчас почти в любой RAD-системе имеются шаблоны для создания OLE-серверов, методы и объекты которых доступны при работе в дистанционном режиме. И, поскольку регистрацию удаленного сервера легко включить в процедуру установки программ-клиента, не приходится предпринимать каких-либо дополнительных действий, чтобы воспользоваться новыми возможностями.

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

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

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




Рис. 4: Трехзвенная архитектура бизнес-приложений

Однако в фирменной документации Microsoft, посвященной OLE-объектам утверждается: "Чаще всего размещение сервер-объектов доступа к данным на той машине, где находится база данных, может существенно сократить загрузку сети и увеличить общую скорость передачи данных". Имеются примеры реализации трехзвенных клиент-серверных приложений, трехзвенных баз данных, где результаты превосходят все ожидания. Производительность сети практически перестает влиять на время обработки транзакций, и своеобразное распиливание монолитных программных блоков на мобильные OLE-сегменты приводит к значительному повышению эффективности работы приложения в целом. Более того, трафик в сети существенно уменьшается и становится более предсказуемым.

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

Чтобы лучше понять возможности распределенной архитектуры, рассмотрим пример из реальной жизни. Предположим, имеется большая транспортная компания M-Trans, которая обеспечивает своих клиентов специальной программой для отслеживания пути прохождения груза. Когда вы отправляете груз из Москвы в Дели, вам дается специальный транспортный номер.

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

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

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

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

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

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

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru