4.1.11 Распределенная com (dcom)

СОМ разрабатывалась с учетом обеспечения поддержки распределенных сред, т.е. способности клиента создавать объекты на других машинах и вызывать их методы по сети. Эти планы стали реальностью в 1996 году после выпуска распределенной СОМ (Distributed СОМ — DCOM). DCOM позволяет клиенту создавать и использовать объекты как на удаленных системах, так и на локальной. Более того, клиент может даже не осознавать различия между этими двумя случаями. Подобно тому как клиенты СОМ имеют прозрачный доступ к объектам в динамических библиотеках и локальных процессах, DCOM обеспечивает прозрачный доступ к объектам в удаленных процессах. Фактически самое трудное в достижении подобной прозрачности — это обеспечить взаимодействие объектов, исполняющихся в разных процессах независимо от того, выполняются эти процессы на одной машине или нет. В этом смысле, с точки зрения проектирования, DCOM — довольно незначительное расширение оригинальной СОМ.

Возможность запускать удаленные объекты и вызывать их методы — важное достижение, но требуется большее. В частности, нужен способ контроля за тем, кто имеет право создавать объекты на данной машине, и обеспечение безопасного доступа к этим объектам по сети, которая может быть наполнена потенциальными врагами. С этой целью в основу DCOM положен набор сервисов контроля доступа. Приложения (включая программы, созданные до DCOM) могут использовать DCOM и работать вполне безопасно без добавления какого-либо кода, связанного с защитой. С другой стороны, приложения, знающие о новых средствах DCOM контроля доступа, могут задействовать их явно. Несмотря на отдельные сложные моменты, DCOM вообще проста для понимания. Она добавляет к знакомым основам СОМ всего 3 основных элемента:

• способ создания удаленного объекта;

• протокол вызова методов этого объекта;

• механизмы обеспечения безопасного доступа к нему.

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

4.1.12 Dcom и службы nt

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

Службы исполняются независимо от того, вошел кто-либо в систему или нет. Каждая служба входит в систему и выдает себя за определенного пользователя. Обычно при запуске системы службы начинают исполняться автоматически; но можно задать для службы запуск вручную. Служба должна быть зарегистрирована и связана с диспетчером SCM, отвечающим за управление конфигурацией, запуск и остановку служб. Но как служба связывается с диспетчером SCM? Диспетчер SCM (Service Control Manager - диспетчер управления службами) обеспечивает управление службами Windows NT. Не следует путать диспетчер SCM с диспетчером COM SCM, который отвечает за определение местонахождения и создание экземпляров служб СОМ.