Опубликован: 24.11.2006 | Доступ: свободный | Студентов: 716 / 33 | Оценка: 4.46 / 4.54 | Длительность: 17:18:00
Лекция 1:

Программирование для интернета с использованием COM

Лекция 1: 12345678910 || Лекция 2 >

Общие сведения об архитектуре Windows и приложениях служб компонентов

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

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

Стремясь к сокращению системных ресурсов, связанных с запуском и работой процессов, программисты разрабатывают программное обеспечение для загрузки в память под существующим процессом вместо создания нового процесса. Сравнение веб-приложений Common Gateway Interface (CGI) и веб-приложений ASP показывает различие, о котором идет речь. Если на веб-странице, требующей работы приложения CGI, наблюдается 10 посещений в минуту, то независимо от сложности этой работы серверу придется запускать исполняемый файл CGI 10 раз в минуту, т.е. 600 раз в час.

Если страница ASP выполняет те же задачи, что и исполняемый файл CGI, то через один и тот же интервал времени запускаются нулевые процессы. На самом деле запускается лишь один процесс, и это происходит при старте сервера; этот процесс – IIS. Расширение ISAPI ASP.DLL работает в пространстве процесса IIS. Раньше службы IIS останавливались без видимых причин после продолжительного периода времени. Подобные ошибки возникали из-за повреждения процесса IIS и его дестабилизации исключением, утечкой памяти или невыпущенными указателями. Причиной этому была загрузка библиотеки DLL с дефектами в пространство процесса IIS. Эта унаследованная особенность (или ошибка) в архитектуре Windows привела к тому, что IIS воспринимается как ненадежная система в сравнении с другими, менее сложными системами, использующими CGI.

Для повышения надежности без потерь производительности (что возможно при работе программного обеспечения в собственном независимом процессе) был разработан сервер Microsoft Transaction Server (MTS) для Windows NT 4. MTS превратился в службы приложений (или COM+) на платформе Windows 2000. На каждой новой платформе у служб компонентов появлялись новые возможности. Основным достоинством служб является то, что они выступают в роли сервера DLL. Библиотеку DLL объекта COM можно загрузить в приложение COM+, и она будет выполняться в своем собственном процессе или в процессе программы-потребителя. Приложение сервера COM+ выполняется в собственном процессе, а приложение библиотеки – в процессе программы-потребителя. Если используемые библиотеки DLL надежны и не требуют частого изменения и обновления, то их следует размещать в приложении библиотеки, так как среднестатистическое программное решение использует меньше ресурсов сервера и функционирует с большей производительностью. Если библиотеки DLL созданы недавно, ненадежны или требуют частого обновления, то их следует располагать в приложении сервера. Это исключит сбои в обычной программе при возникновении ошибки в компоненте, и для обновления не потребуется полная остановка этой программы.

Добавление нового компонента в приложение COM+ в службы компонентов

Цель создания приложения COM+ – дать возможность службам компонентов обслуживать экземпляры классов в ConfigSeat.dll. Следующим шагом по установке ConfigSeat.dll на несущем сервере является добавление ConfigSeat.dll в только что созданное приложение COM+ New ConfigSeatWeb.

  1. В консоли управления Component Services (Службы компонентов) щелкните правой кнопкой мыши на папке Component (Компонент) под пунктом приложения COM+ New ConfigSeatWeb и выберите команду New\Component (Создать\Компонент) (см. рис. 1.15).

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

    увеличить изображение
    Рис. 1.15. Запуск мастера установки компонентов COM+
  2. В окне приветствия мастера установки компонентов COM+ (COM+ Component Install Wizard) нажмите на кнопку Next (Далее) для продолжения работы.
  3. В окне Import Or Install A Component (Импорт или установка компонента) нажмите на кнопку Install New Components (Установка новых компонентов).
  4. В диалоговом окне выбора файла выберите ConfigSeat.dll и нажмите на кнопку Open (Открыть).
  5. В окне Install New Components (Установка новых компонентов) приведен список компонентов, добавляемых в новое приложение COM+ (см. рис. 1.16 ).


    Рис. 1.16.

    Данное окно предназначено для открытия библиотек COM DLL, загрузки их в приложение COM+ и отображения выбранных элементов. Нажмите на кнопку Add (Добавить) для открытия диалогового окна выбора файла (см. шаг 4). Выбор других библиотек COM DLL добавит их в списки файлов и компонентов, отображаемые в этом окне. Нажмите на кнопку Next (Далее).

  6. Нажмите на кнопку Finish (Готово). Мастер установки компонента COM+ завершит свою работу, и библиотека ConfigSeat.dll будет добавлена в приложение COM+ New ConfigSeatWeb.
Использование служб компонентов для ролевого доступа

Службы компонентов разрешают ролевой доступ к любому компоненту, загруженному в приложение COM+. Учетные записи пользователей Windows приписываются к роли, и запросы компонента выполняются с помощью аутентификационных данных этих учетных записей. Если эти роли связаны с запрашиваемой частью компонента, то программа-потребитель будет функционировать должным образом; в противном случае она не сможет осуществить доступ к компоненту. Роли связываются с компонентом, загруженным в приложение COM+, на следующих уровнях:

  • приложение COM+ – все компоненты располагаются в приложении COM+;
  • компонент – конкретный объект COM, загруженный в приложение COM+;
  • коллективные интерфейсы компонента – все методы объекта COM загружаются в приложение COM+;M
  • метод компонента – конкретный метод в конкретном объекте COM, загруженном в приложение COM+.

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

  1. Включите проверку доступа уровня компонента для приложения COM+.
  2. Включите проверку доступа уровня компонента для компонента.
  3. Присвойте роль (роли) любой из частей компонента:
    • сам компонент;
    • метод компонента;
    • все методы компонента.

Чтобы включить проверку доступа уровня компонента для приложения COM+, выполните следующие шаги.

  1. В консоли управления Component Services (Службы компонентов) щелкните правой кнопкой мыши на пункте COM+ Application (Приложение COM+) и выберите Properties (Свойства).
  2. В окне свойств откройте вкладку Security (Безопасность).
  3. Отметьте опцию Enforce Component-Level Access Checks (Обязательная проверка доступа уровня компонента).
  4. Нажмите на кнопку OK.

Для включения проверки доступа для компонента нужно включить проверку доступа для приложения COM+ и после этого выполнить следующие шаги.

  1. В консоли управления Component Services (Службы компонентов) щелкните правой кнопкой мыши на пункте COM+ Application (Приложение COM+) и выберите Properties (Свойства).
  2. В окне свойств откройте вкладку Security (Безопасность).
  3. Для присвоения роли компоненту в целом отметьте роль в списке Roles Explicitly Set For Selected Item(s) (Роли, установленные для выделенных элементов). Все методы компонента унаследуют данную роль.

    Для присвоения роли определенным методам внутри компонента отметьте опцию Enforce Component-Level Access Checks (Обязательная проверка доступа на уровне компонента), что позволит в дальнейшем присваивать роли методам компонента.

  4. Нажмите на кнопку OK.

Для компонента ConfigSeat.clsChair, добавленного в приложение COM+ New ConfigSeatWeb, ролевой доступ не требуется, поэтому обязательные проверки доступа уровня компонента не включены. Приложение COM+ New ConfigSeatWeb, тем не менее, настроено на обязательную проверку доступа, поэтому проверки доступа компонентного уровня включены. Если система IIS функционировала под учетной записью по умолчанию, созданной Windows (например, IUSR_имя_компьютера ), то ASP-программа, создающая объект ConfigSeat.clsChair, вызовет ошибку, поскольку гостевая учетная запись интернета не имеет доступа к компоненту ConfigSeat.clsChair. После смены ее на другую учетную запись с доступом к указанному компоненту код ASP будет функционировать должным образом. Для использования кодом ASP компонента ConfigSeat.clsChair веб-сайт или виртуальный каталог в IIS настроен на работу с использованием аутентификационных данных учетной записи webuser.

Для настройки доступа выполните следующие шаги.

  1. Откройте окно свойств веб-сайта или виртуального каталога и выберите вкладку Directory Security (Безопасность каталога).
  2. Нажмите на кнопку Edit (Изменить) в области Authentication And Access Control (Контроль аутентификации и доступа) для открытия соответствующего окна.
  3. По умолчанию опция Enable Anonymous Access (Разрешить анонимный доступ) включена; аутентификационные данные гостевой учетной записи пользователя располагаются в полях User Name (Имя пользователя) и Password (Пароль). Введите webuser в текстовое поле User Name (Имя пользователя) и пароль – в текстовое поле Password (Пароль).
  4. Нажмите на кнопку OK несколько раз для закрытия всех окон.

Теперь страницы ASP будут выполняться под учетной записью webuser. При создании страницами ASP компонента ConfigSeat.clsChair аутентификационные данные учетной записи webuser представляются для запроса в службы компонентов. Службы компонентов проверяют разрешения учетной записи webuser на создание и использование компонента, и ASP реализует функции в компоненте ConfigSeat.clsChair.

Лекция 1: 12345678910 || Лекция 2 >