Технология com и ее бизнес

Евгений Марков, Генеральная Сервисная Компания (Санкт-Петербург)
Источник: IT News

Для распределенных приложений большое значение имеют вопросы обеспечения надежности, производительности, масштабируемости. Технология COM+ (старое название Microsoft Transaction Server, MTS) входит в состав серверных операционных систем Microsoft и предназначена для поддержки систем обработки транзакций.

COM+ может устанавливаться и работать на компьютерах с операционными системами Windows 95/98, Windows NT, Windows XP, Windows 2000, Windows 2003. Однако необходимо отметить, что система безопасности транзакций не реализована для операционных систем Windows 95/98 вследствие объективных ограничений, накладываемых этими системами.

• управление транзакциями;
• безопасность;
• пулинг ресурсов;
• пулинг объектов.

• Координатор распределенных транзакций (Distributed Transaction Coordinator, DTC) представляет собой службу, управляющую транзакциями на низком уровне с использованием протокола двухфазной фиксации транзакций.
• Административное приложение MTS Explorer позволяет настраивать параметры среды COM+, хранимые в системном реестре; управлять пакетами и ролями COM+.
• Утилиты COM+ для работы в командной строке или batch-файле.
• Исполняемый файл MTX.EXE, который реализует автоматические транзакции, безопасность и активизацию (Just-In-Time, JIT).

Как работает COM+

• Программное обеспечение промежуточного уровня, обеспечивающее функционирование объектов транзакций во время выполнения.
• Утилита MTS Explorer, позволяющая управлять объектами транзакций.
• Интерфейсы прикладного программирования.
• Средства управления ресурсами.

Разработчики, использующие COM+ в своих приложениях, создают объекты бизнес-логики, удовлетворяющие требованиям к объектам COM+; затем компилируют их и устанавливают в среде COM+ при помощи пакетов. Пакет COM+ представляет собой контейнер, обеспечивающий группировку объектов в целях защиты данных, улучшения управления ресурсами и увеличения производительности. Управление пакетами осуществляется при помощи утилиты MTS Explorer.

Цифровые продукты и технологии. Бизнес-интервью. Как создать и продвигать.

Объект COM+

• объект должен быть реализован в составе внутреннего сервера (динамическая библиотека);
• объект должен содержать ссылку на библиотеку типов COM+;
• объект должен использовать только стандартный механизм маршаллинга COM;
• объект должен имплементировать интерфейс IobjectControl .

• statefull (с сохранением информации о состоянии объекта);
• stateless (без сохранения информации о состоянии объекта).

Сохранение состояния объекта требует, чтобы тот оставался активным и сохранял такие ценные ресурсы как, например, соединение с базой данных. На практике это означает не что иное, как работу с глобальными переменными, потому что именно в них хранится промежуточное состояние объекта.

Искусственный интеллект GPT и роботы // Новости и достижения высоких технологий

Если объект не может сохранять свое промежуточное состояние, то он относится к типу stateless. Объекты этого типа более эффективны. Когда транзакция успешно завершена или прервана, все объекты, вовлеченные в транзакцию, деактивируются и, соответственно, теряют информацию о своем состоянии, приобретенную во время транзакции. Это помогает убедиться в изоляции транзакции и согласованности базы данных, а также освобождает ресурсы сервера для использования другими транзакциями. Завершение транзакции позволяет COM+ деактивировать объект и обновить ресурсы.

Транзакции

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

• на этапе разработки;
• с помощью редактора библиотеки типов;
• в среде MTS Explorer.

Контекст объекта COM+

Для каждого объекта транзакции сервер транзакций автоматически создает специальный объект, который носит название объект контекста транзакции или контекст объекта COM+. Функциональность контекста обеспечивается интерфейсом IobjectContext .

Два метода интерфейса определяют способ выхода объекта из транзакции.

Метод SetComplete сообщает транзакции, что он готов к завершению своей работы в транзакции.

Использование метода SetAbort означает, что исполнение кода объекта привело к возникновению обстоятельств, препятствующих успешному завершению транзакции.

После использования любого из этих двух методов объект завершает свое участие в транзакции.

Методы EnableCommit и DisableCommit сообщают о текущем состоянии объекта. Метод EnableCommit сообщает, что объект позволяет завершить транзакцию, хотя его функционирование еще не завершено.

Рис. 1. Роль контекста объекта COM+

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

При помощи перечисленных методов объект контекста обеспечивает среду COM+ информацией о состоянии объекта транзакции.

Например, распределитель ресурсов может использовать контекст объекта COM+ для обеспечения сервисов на основе транзакций. Пусть объект выполняется внутри транзакции, которая зарезервировала соединение с базой данных, используя провайдер ADO. Это соединение автоматически организует транзакцию. Все изменения в базе данных, использующие такое соединение, становятся частью транзакции и затем либо принимаются, либо откатываются. Дополнительно разработчики могут использовать несколько вспомогательных методов интерфейса IobjectContext .

Безопасность данных

• декларативная защита данных;
• программная защита данных.

Декларативная защита данных

Декларативная защита данных создается на этапе настройки среды COM+ и выполняется средствами утилиты MTS Explorer. Она заключается в ограничении доступа к тому или иному объекту или пакету для пользователей и групп, являющихся членами тех или иных ролей.

По умолчанию в среде COM+ настроен пакет System Package, для которого предопределены две роли: администратора (Administrator) и читателя (Reader). Перед началом работы необходимо связать роль администратора с хотя бы одной учетной записью.

Программная защита данных

Программная защита данных обеспечивается объектом контекста (см. выше) и методами IsSecurityEnabled и IsCallerInRole интерфейса IobjectContext этого объекта. Программная защита данных проектируется на этапе разработки приложения и исполняется при функционировании приложения, использующего данный объект COM+.

Когда приложение пытается использовать некоторый объект COM+, необходимо применить метод IsCallerInRole . В качестве параметра метода передается роль, исполняемая приложением. Если объект или пакет COM+ разрешен для роли, его использование разрешается и метод возвращает значение True.

Если же несколько объектов MTS используются в рамках одного процесса, метод IsCallerInRole возвращает True всегда. В этом случае для более точной идентификации применяется метод IsSecurityEnabled .

Ресурсы

• активизация Just-in-time;
• пулинг ресурсов (Resource pooling);
• пулинг объектов (Object pooling).

Активизация Just-in-time

Способность объекта быть деактивированным и повторно активированным, пока клиент сохраняет ссылку на него, называется активизацией Just-in-time.

В процессе работы приложения часто бывает необходимо использовать один экземпляр объекта COM+ несколько раз через определенные промежутки времени. При обращении к объекту он активизируется, а некоторое время после прекращения использования приложение удерживает ссылку на неиспользуемый объект.

Когда создается объект как часть среды COM+, также создается соответствующий контекст объекта. Этот контекст объекта существует в течение всего времени жизни соответствующего объекта COM+, через один или несколько циклов. COM+ использует контекст объекта для сохранения информации о нем при деактивизации.

Объект создается в неактивном состоянии и становится активным только после запроса клиента.

Когда объект становится неактивным, среда уничтожает все ресурсы объекта, в том числе, например, соединение к базе данных.

• Вызов методов SetComplete или SetAbort интерфейса IobjectContext . Если объект вызывает метод SetComplete , когда он успешно завершил свою работу и нет необходимости сохранять внутреннее состояние объекта для следующего вызова клиента. Если объект вызывает SetAbort , указывая на невозможность успешного завершения своей работы и отсутствие необходимости сохранения состояния объекта. После чего объект возвращается в состояние предшествующее этой транзакции. При нормальной реализации stateless-объекта деактивизация происходит после вызова каждого метода.
• Транзакция сохраняется либо прерывается. Затем объект также деактивизируется. Среди этих объектов могут продолжить свое существование только те, что имеют ссылку на клиентов за пределами данной транзакции. Последующий вызов этих объектов повторно активирует их и служит причиной для выполнения в следующей транзакции.
• Последний клиент освобождает объект. При этом объект деактивизируется и контекст объекта тоже освобождается.

Пулинг ресурсов

После освобождения ресурсов при деактивизации объекта COM+ они становятся доступными для других серверных объектов. Этот процесс называется пулингом ресурсов .

Рассмотрим, например, соединение с базой данных через провайдер ADO. Известно, что выделение ресурсов, открытие и закрытие соединения с базой данных занимает довольно много времени. Частое повторение этой операции различными объектами COM+ применительно к одной базе данных вызовет повышенный расход ресурсов.

Именно в таких случаях и используется пулинг ресурсов. Соединение с базой данных, больше не используемое одним серверным объектом, может быть использовано другим объектом.

Для выполнения задач пулинга ресурсов COM+ использует распределитель ресурсов.

Освобождение ресурсов

Обычно освобождение ресурсов объекта делается при помощи вызова методов SetComplete и SetAbort после обслуживания запроса клиента. Эти методы освобождают ресурсы, зарезервированные распределителем ресурсов COM+.

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

Пулинг объектов

COM+ реализует не только пулинг ресурсов, но и пулинг объектов. Правда, эта возможность доступна только в рамках технологии COM+, работающей под управлением операционных систем Windows 2000 и Windows 2003. В COM+ более старых версий пулинг объектов лишь декларирован для будущего использования.

Рис. 2. Схема пулинга объектов COM+

Суть этого механизма проста.

При выполнении приложений в среде COM+ создается специальный пул объектов.

Для управления пулом и размещения в нем объектов используется интерфейс IobjectControl . Если объект предназначен для использования в пулинге, то метод CanBePooled -интерфейса должен возвращать значение True. После деактивизации такого объекта сервер COM+ помещает его в пул. Объекты внутри пула доступны для немедленного использования любыми другими запросами клиентов. В случае если объект запрошен, но пул объектов пуст, MTS автоматически создает новый экземпляр объекта.

Тестирование и установка компонентов COM+

При настройке среды COM+ среди многих параметров администратор может задавать время пребывания объекта транзакции в активном состоянии без вызовов со стороны клиентов. Это параметр transaction timeout. По умолчанию это время равно 60 секундам.

При отладке объектов COM+ необходимо отключить этот параметр (присвоить значение, равное нулю), иначе объект может быть выгружен средой, пока вы работаете с исходным кодом или значениями переменных в процессе отладки.

В стадии разработки компонент нельзя перекомпилировать, пока он находится в памяти. В этом случае появится сообщение об ошибке «Cannot write to DLL while executable is loaded.». Для устранения такой ситуации необходимо с использованием MTS Explorer установить в свойствах пакета параметр shut down after being idle for 3 minutes, изменив соответственно время.

1. В MTS Explorer щелкнуть правой кнопкой мыши на пакете, в котором инсталлирован интересующий объект транзакции и из всплывающего меню выбрать пункт Properties.
2. В появившемся диалоге выбрать закладку Advanced.
3. Изменить время ожидания на 0.
4. Нажать кнопку OK для сохранения параметров и вернутся в среду MTS Explorer.

Оптимизация работы с COM+

Разработать приложение, использующее COM+, формально просто. Более сложной задачей является проектирование приложения таким образом, когда оно не только работает, но и приносит максимальный эффект от своей работы, воплощая все возможности используемой технологии. Для этого надо хорошо представлять механизм работы объектов COM и принципы работы с транзакциями.

Блокировка транзакций

Одним из основных принципов грамотного управления транзакциями является их изоляция. Для достижения этого используются различные механизмы блокировок влияния транзакций друг на друга. COM+ реализует систему изоляции транзакций на высоком уровне. Пока данные в одной транзакции не будут обработаны, они не видны в другой транзакции.

Таким образом, снижается производительность системы. Для решения проблемы необходимо свести время работы каждой транзакции к минимуму и не забывать о правильном использовании таких методов, как SetComplete и SetAbort интерфейса IobjectContext (см. выше).

Действия COM+

Кроме этого, одним из наиболее важных и фундаментальных аспектов программирования для COM+ является такое понятие, как «действие» (activity). Очень часто на правильное использование действий не обращают серьезного внимания, хотя именно из-за неправильной работы с действиями возникают некоторые проблемы и трудности.

Действие — это совокупность объектов, которые действуют сообща в интересах единственного клиента. Действие может содержать объекты из разных пакетов. Каждый объект COM+ существует только в одном действии, хотя действие может содержать несколько объектов. Каждая транзакция существует только в одном действии, хотя действие может содержать несколько транзакций.

Программирование для COM+ подразумевает, что объекты COM+ не должны разделяться между действиями. Параллельное использование объектов внутри действия очень опасно, поскольку возможна ситуация, когда объект, работающий в интересах одного потока, может попытаться принять транзакцию, пока объект, работающий в интересах второго потока, находится в процессе выполнения работы внутри той же транзакции. Если транзакция была действительно принята, это привело бы к фиксации частично выполненной транзакции.

Источник: citforum.ru

Технология COM

Только сегодня: 300 рублей в подарок на первый заказ.
Какую работу нужно написать?

Другую работу

Помощник Анна

Общая характеристика технологии COM COM (англ. Component Object Model — объектная модель компонентов;) — это технологический стандарт от компании Microsoft, предназначенный для создания программного обеспечения на основе взаимодействующих компонентов, каждый из которых может использоваться во многих программах одновременно.

Стандарт COM закрепился в основном на операционных системах семейства Microsoft Windows. В современных версиях Windows COM используется очень широко. На основе COM были реализованы технологии: Microsoft OLE Automation, ActiveX, DCOM, COM+, DirectX, а также XPCOM. В технологии COM приложение предоставляет для использования своей службы, применяя для этого объекты COM.

Одно приложение содержит как минимум один объект. Каждый объект имеет один или несколько интерфейсов. Каждый интерфейс объединяет методы объекта, которые обеспечивают доступ к свойствам (данным) и выполнение операций. Обычно в интерфейсе объединяются все методы, выполняющие операции одного типа или работающие с однородными свойствами.

Клиент получает доступ к службам объекта только через интерфейс и его методы. Этот механизм является ключевым. Согласно спецификации COM, уже созданный интерфейс не может быть изменен ни при каких обстоятельствах. Это гарантирует постоянную работоспособность приложений на основе COM, невзирая на любые модернизации.

Объект всегда работает в составе сервера COM, который может быть динамической библиотекой или исполняемым файлом. Объект может иметь собственные свойства и методы или использовать данные и службы сервера.

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

Объект СОМ – это некоторая сущность, имеющая состояние и методы доступа, позволяющие изменять это состояние. СОМ-объекты можно создавать прямым вызовом специальных функций, но напрямую уничтожить его невозможно. Вместо прямого уничтожения используется механизм самоуничтожения, основанный на подсчете ссылок.

Самым близким аналогом в объектно-ориентированных языках программирования является понятие объекта в языке Java. Так, в COM присутствует понятие класса. Класс в COM носит название CoClass. Согласно правилам обозначения объектов COM, базовый интерфейс IUnknown, который имеется у любого объекта, обозначается как кружок, примыкающий к верхней стороне прямоугольника объекта.

Остальные интерфейсы обозначаются справа и слева. Взаимодействие между клиентом и объектом обеспечивается базовыми механизмами COM. При этом от клиента скрыто, где именно расположен объект: в адресном пространстве того же процесса, в другом процессе или на другом компьютере. Механизм обеспечения взаимодействия между удаленными элементами COM называется маршалингом (marshalling).

Рисунок 2.1 – Схема взаимодействия клиента и объекта COM

Любой объект COM является обычным экземпляром некоторого класса, описывающего его свойства и методы. Информация обо всех зарегистрированных и доступных в данной ОС классах COM собрана в специальной библиотеке COM, которая используется для запуска экземпляра класса – объекта.

Сначала объект обращается к библиотеке COM, передавая ей имя требуемого класса и необходимого в первую очередь интерфейса. Библиотека находит нужный класс и сначала запускает сервер, который затем создает объект – экземпляр класса. После этого библиотека возвращает клиенту указатели на объект и интерфейс.

В последующей работе клиент может обращаться непосредственно к объекту и его интерфейсам. После создания наступает очередь инициализации – объект должен загрузить необходимые данные, считать настройки из системного реестра и т.д. За это отвечают специальные объекты COM, которые называются моникерами (monikers). Они работают скрытно от клиента.

Обычно моникер создается вместе с классом. Довольно реальной представляется ситуация, когда одновременно несколько клиентов обращаются к одному объекту. При соответствующих настройках для каждого клиента создается отдельный экземпляр класса. За выполнение этой операции отвечает специальный объект COM, который называется фабрикой класса.

Объект COM Центральным элементом COM является объект. Приложения, поддерживающие COM, имеют в своем составе один или несколько объектов COM. Каждый объект представляет собой экземпляр соответствующего класса и содержит один или несколько интерфейсов. Любой объект является экземпляром некоторого класса, т.е. представляет собой переменную объектного типа.

Поэтому объект обладает набором свойств и методов, которые работают с этими свойствами. К объектам применимы три основные характеристики: инкапсуляция (Инкапсуляция (encapsulation) — это механизм, который объединяет данные и код, манипулирующий зтими данными, а также защищает и то, и другое от внешнего вмешательства или неправильного использования.

В объектно-ориентированном программировании код и данные могут быть объединены вместе; в этом случае говорят, что создаётся так называемый «чёрный ящик». Когда коды и данные объединяются таким способом, создаётся объект (object).

Другими словами, объект — это то, что поддерживает инкапсуляцию.), наследование ( это процесс, посредством которого один объект может приобретать свойства другого) и полиморфизм (в языках программирования полиморфизм — возможность объектов с одинаковой спецификацией иметь различную реализацию.). Объекты COM всем этим требованиям удовлетворяют.

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

Объект COM может иметь любое число интерфейсов (если это число больше нуля), причем, каждый интерфейс обладает собственным указателем. Это первое отличие объектов COM от обычных. У объектов COM имеется особенность еще в одном объектом механизме – наследовании. Вообще различают два способа наследования.

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

Тем не менее, просто так выбросить наследование реализации нельзя. Вместо нее объекты COM используют механизм включения, т.е. при необходимости потомок вызывает нужный метод родителя. Также применяется механизм агрегирования, когда один или несколько интерфейсов одного объекта на время включаются в другой объект путем передачи указателей. 3

Источник: studfile.net

Что такое «технология COM» и как с ней бороться? №42

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

Из прошлого выпуска должно быть понятно, что физически, на уровне команд собственной программы случаи вызова внутрипроцессного (inproc) и локального (local) сервера — отличаются как день и ночь, при организации этих вызовов не то, что сильно отличается объём действий, а и сами-то действия абсолютно никак не сопоставимы. И. этого никак допустить нельзя.

Нельзя потому, что нарушается один из основных принципов COM — интерфейс объекта всегда должен оставаться неизменным, не зависеть от того кто кого и каким образом вызывает. Т.е., высказывая это же на «машинном языке» — команды вызова метода объекта в клиенте должны быть одними и теми же, расположен ли сервер локально или внутри собственного процесса.

Аналогичное можно сказать и про сервер. Налицо — противоречие, которое на стороне именно клиента и именно сервера решить невозможно. Но у нас между клиентом и сервером есть ещё и промежуточный слой — сама среда COM на которую можно попытаться возложить эту задачу. Остаётся только понять, что именно нужно ей поручить.

Последовательное изучение — благодарное занятие, поскольку всегда можно обратиться к предыдущему изученному. И сейчас мы к нему обратимся — вспомним самые-самые основы, самый простейший случай — вызов метода inproc-сервера.

Физически это делается просто, как мы знаем это не что иное, как локальный вызов метода vtbl, т.е. по своей сути — вызов локальной процедуры, расположенной в DLL. Клиент подготавливает список параметров в стеке, извлекает по известному смещению в vtbl адрес начала процедуры и делает call dword ptr . Команда call помещает адрес возврата в стек, так что когда метод, завершаясь, исполнит команду ret управление в клиенте будет передано туда, куда следует — на следующую за call команду. Напоминать как должен происходить «вызов процедуры» между двумя разными потоками, я надеюсь, излишне — это изложено в прошлом выпуске. Но вот вопрос, который хочется задать — а нельзя ли как-нибудь совместить первое и второе? И — каким образом?

Для того, чтобы компонент не терял способности взаимодействовать inproc-способом он, очевидно, ни в коем случае не должен отказываться от механизма вызова локальной процедуры по адресу из vtbl, как и изображено на рис. 10, на котором показан сервер (объект сервера)экспонирующий один интерфейс — vtbl, и клиент, ссылающийся на метод этого интерфейса:

рис 10. Клиент-серверное inproc-взаимодействие

А для того, чтобы компонент мог взаимодействовать local-способом он должен в своём процессе выполнять совсем другие действия. Только вот «в своём процессе» это не совсем то же самое, что «в своём модуле», поскольку вынесение всей функциональности манипуляции потоками в отдельную DLL никаких основ не нарушает — её ведь заведомо можно оформить «с другой стороны» как inproc-сервер?

В самом деле, пусть у нас первоначально было inproc-взаимодействие. Есть клиент, сервер, определён интерфейс. Затем мы разделяем эти компоненты, помещая каждый в свой собственный процесс.

При этом, чтобы для клиента «ничего не изменилось» мы должны будем обеспечить ему очень своеобразный inproc-сервер, который просто будет манипулировать потоками так, как описано в прошлом выпуске. А на стороне сервера, мы, естественно, должны будем обеспечить своеобразного inproc-клиента, который, принимая команды манипуляции потоками, транслирует их в inproc-вызовы методов. И ни «исходный сервер», ни «исходный клиент» в даном случае никакого изменения не претерпят — если их снова поместить в один процесс, то они как взаимодействовали, так и будут взаимодействовать. Существо проделанной операции изображено на рис. 11:

рис 11. Клиент-серверное local-взаимодействие

Здесь компоненты «заместитель сервера» и «заместитель клиента» — есть DLLи, находящиеся в соответствующем процессе и взаимодействующие между собой каким-нибудь способом — сам способ их взаимодействия к COM не относится и может быть любым, удобным для данной операционной системы.

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

Рассмотрим подробнее, каковы их функции и каким образом компоненты-заместители могут быть реализованы. Для определённости начнём рассмотрение со стороны пользовательского клиента. Служебный компонент, который в процессе клиента пользователя «исполняет обязанности сервера» носит название proxy.

Его функции — принять inproc-вызов клиента и «каким-то образом» передать его (вызов) в процесс сервера пользователя. При этом клиент «добросовестно заблуждается» — он действительно считает proxy «настоящим сервером» — о том, что действительный сервер исполняется в другом потоке клиенту неведомо.

В частности, то, что поток клиента принудительно останавливается — исключительная забота proxy, клиент ничего не знает о том, что есть какие-то синхронизаторы. Но синхронизация — не единственная проблема, решаемая proxy. Клиент «считает», что он вызывает локальный метод, т.е. предоставляет proxy стек, заполненный параметрами, передаваемымим методу.

Забота proxy — извлечь этот список и переместить его каким-то образом на сторону сервера. При этом, хорошо, если передаваемые клиентом параметры — сплошь просто двоичные числа. А если клиент передаёт указатели? Которые заведомо недействительны в другом процессе, каким бы образом ни передавались?

В таком случае proxy должен их преобразовать к такому виду, чтобы на стороне сервера из них можно было восстановить ссылки на те объекты, на которые указатели по своей семантике и указывают. Это явление носит название маршалинга. Сейчас мы его только упоминаем, хотя на самом деле это очень большая и разносторонняя тема, рассмотрению которой мы уделим соответствующее время.

Рассмотрим теперь сторону пользовательского сервера. Служебный компонент, который в процессе сервера «выполняет обязанности клиента» носит название stub. Его функции дополнительны к функциям proxy — он так же синхронизирует вызовы, которые получает от proxy и преобразует их в «вызовы от локального клиента», получает от proxy список параметров, распаковывает его, восстанавливает указатели и помещает список параметров в локальный стек потока сервера. Словом, под управлением stub и сервер заблуждается не менее клиента, т.е. считает stub «настоящим клиентом» не подозревая, что действительный клиент исполняется в другом потоке. Естественно, что и сервер ничего не знает о том, что «его» поток всё свое время проводит в спячке в синхронизаторе stub.

Каким образом реализуется связь между proxy и stub? Корректный ответ на него — посредством системного сервиса RPC (remote procedure call), вызовы которого оба компонента используют. Каким образом реализован сам RPC? А вот это уже — не совсем корректный вопрос.

Это — зависит от обстоятельств, от возможностей конкретной операционной системы, от способов, которые выбраны для передачи сигналов и разделения данных между процессами. Все эти обстоятельства с полным правом можно назвать «системно-зависимыми» и говорить о том, что они реализованы именно так и никак иначе — довольно рискованно.

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

Нужно заметить — описанная выше модель является своего рода столпом COM. Один столп COM мы ранее рассмотрели — это был вызов метода из vtbl, данная модель — второй столп технологии. И понимание этой модели, понимание функций выполняемых всеми действующими его «участниками», исключительно важно для программиста — из неё следует надобность и особенности маршалинга, из неё следуют возможности и ограничения DCOM и т.п. очень интересные в практике вещи. Можно смело сказать, что по своей значимости в COM и CORBA эта модель сродни чему-то, наподобие «основной теоремы алгебры» в математике, поэтому её обязательно нужно понимать очень хорошо.

Сделаем и практическое замечание — создание proxy и stub есть процесс, если не автоматизированный, то в значительной степени механизированный в современной среде компонентной разработки. Что-либо «своё» в этом процессе придумывать приходится исключительно редко, поскольку все стандартные ситуации в системе имеют и стандартные решения. Например, компилятор MIDL, как мы потом увидим — главное «действующее лицо» в организации комплементарных статических структур, обеспечивающих взаимодействие клиента и сервера, генерирует исходные тексты proxy и stub, соответствующих заданному интерфейсу. И для создания proxy/stub нужно только откомпилировать и слинковать сгенерированный им текст.

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

Источник: subscribe.ru