Эта книга написана для профессиональных программистов. Читателю понадобится хорошее знание Visual C++ и определенный опыт работы с COM. Поскольку основным направлением книги является работа с базами данных, использование SQL Server описано в пошаговых инструкциях, но необходимо хорошее понимание принципов управления базами данных. MTS и MSMQ являются относительно новыми добавлениями к программистской среде COM, поэтому рассмотрению этих тем уделено повышенное внимание. Тем не менее предполагается, что у читателя уже есть определенное представление о том, как рабо
тать с двумя этими продуктами на уровне пользователя.
СОДЕРЖАНИЕ
Об авторе
Благодарности
Введение
О чем эта книга
Для кого эта книга
Что вам понадобится
Используемые в книге условные обозначения
Значки
Вставки
Обзор Hungarian Notation (венгерской системы обозначений)
Правило 1: Задание префиксов переменной
Правило 2: Идентифицирующее состояние переменной
Правило 3: Использование стандартного классификатора
Правило 4: Добавление описательного текста
Правило 5: Создание нескольких переменных
О компакт-диске
От издательства
Глава 1. COM+ - последнее достижение в компонентной технологии
COM+ - что это такое?
Отличие COM+
COM+ и соединение
COM+ и пользователь
COM+ и пользовательский интерфейс
COM+ и программист
Взгляд крупным планом
Как сравнивать COM+ и COM
Цели создания COM
Транзакции и COM+
Сообщения и COM
Службы COM+
Отличия MTS
Описание службы MTS
Роль объединения ресурсов COM+
Где использовать MSMQ?
Глава 2. Основы COM - краткая версия
Создание объекта
Внутрипроцесснные серверы
Внепроцессные серверы
Типичные внепроцессные соединения
Подробное описание сетевого протокола DCOM
Разность значений сетевых имен
Многократное использование компонента
Вызов метода интерфейса
Понимание IUknown
Интерфейсы ActiveX
Использование интерфейсов ActiveX
Подсчет ссылок
Требования системного реестра
Работа с распределениями и потоками
Типы потоков
Потоки-исполнители
Потоки UI
Типы распределений и присваиваний
Маршалинг запросов
Глава 3. Уникальные возможности COM+
COM+ и автоматизация
Динамичная активация
Транзакционная обработка
Контекст COM+
Распределители ресурсов.
Диспетчер компенсирующих ресурсов
Приемник событий COM+
Каталог COM+
Накапливание объектов
Защита на основе ролевого имени
Стандартная защита Windows
Дыры защиты
Обзор стандартов защиты
Обеспечение безопасной работы Windows 2000
Встроенные функции защиты
Отличия защиты на основе ролевых имен
Преимущества защиты на основе ролевого имени
Действия с идентификацией и ролевыми именами
Интерфейс ISecurityCallContext
Компонентное выравнивание нагрузки (CBL)
Цели выравнивания нагрузки
Как работает выравнивание нагрузки?
Порядок действий с поврежденными серверами и маршрутизаторами
Глава 4. Обзор MTS
Что такое транзакция?
Транзакции
MTS и COM+
Цели MTS и COM+
Внесение компонента в контекст
Работа со службами MTS и COM+
Последовательность транзакций
Обзор объектов MTS
Определение транзакционных событий
Дистанционное выполнение
Выравнивание нагрузки MTS
Надежность приложения COM+
Вопросы COM/DCOM
Транзакции и базы данных
Диверсификация обработки данных
Особенности баз данных MTS
Программирование баз данных с помощью MTS
MTS и COM+
Защита
Координатор распределенных транзакций Microsoft
MS-DTC в действии
Распределенная часть MS-DTC
Глава 5. Обзор MSMQ
Обзор асинхронной передачи для MSMQ
Маршрутизация
Типы доступа к диску
Гарантии доставки
Защита
MSMQ и MTS
Обзор очередей сообщений
Типы очередей сообщений
Очереди сообщений для отсоединенных приложений
Серверное представление передачи сообщений
Части сообщения
COM представление сообщения и управления очередью
Обработка ошибок MSMQ
Базы данных Active Directory/MQIS
Требования к инсталляции базы данных и задание размеров
Хостинг
MSMQ 1.0 в сравнении с MSMQ 2.0
Вопросы производительности
Внутренние проблемы производительности MSMQ
Ограничения обработки, влияющие на производительность приложения
Глава 6. Типы приложений
Отличия приложений COM+
Компоненты на основе сервера
Преимущества COM+
Атрибуты, контекст и состояние
Четыре уровня изменения компонента
Вопросы программирования
Производительность
Защита
Типы приложений COM+
Приложения сервера
Приложения библиотеки
Прокси-приложения
Предустановленные приложения
Автономный режим приложения
Работа с MTS и MSMQ по отдельности
Глава 7. Транзакция, запускающая приложение
Инсталляция SQL Server 6.5 Developer Edition
Создание SQL Server удаленного развертывания и помощь в диагностике
Определение приложения
Обзор задач приложения
Обзор баз данных
Всестороннее представление отдельных таблиц
Создание базы данных и связанных таблиц
N-ярусное представление проекта
Создание компонентов со стороны сервера
Создание оболочки компонента
Добавление кода компонента
Регистрация и инсталляция компонента на сервер
Создание компонента на стороне клиента
Создание оболочки компонента
Добавление кода компонента
Создание отдельного каталога тестируемого приложения
Создание тестового приложения
Создание оболочки приложения
Определение пользовательского интерфейса
Добавление кода приложения
Тестирование приложения COM+
Глава 8. Сбои транзакций
Сценарии сбоев
Подсоединенный режим
Отсоединенный режим
Методы восстановления работы после ошибки
Обнаружение источника ошибки
Использование очереди ответов
Работа с системными сообщениями
Работа с очередью зависших сообщений
Техники программирования
Интерпретация кодов с ошибками
Работа с ошибочной перегрузкой
Порядок восстановления
Глава 9. Отправка сообщений и COM объекты
Общее представление сценария коммуникации
Два программных интерфейса приложения
Определение типа сообщения
Создание приложения приемник/проигрыватель
Создание оболочки приемник/проигрыватель
Создание диалоговой формы
Добавление кода считывания
Создание тестового приложения
Создание оболочки тестового приложения
Конструирование диалоговой формы тестового приложения
Добавление тестового кода
Тестирование приложения
Подтверждение сообщения
Визуализация сообщения на выходе
Вопросы администрирования MSMQ
Основы управления очередями
Очередь зависших сообщений
Проверка программы просмотра событий
Глава 10. Работа в отсоединенном режиме
Вопросы безопасности при работе с Интернетом в отсоединенном режиме
Определение приложения
Рабочий стол в сравнении с распределенной разработкой
Записывающее устройство, приемник и проигрыватель COM+ по умолчанию
Обзор потока данных приложения
Создание и инсталляция компонента
Создание оболочки компонента
Добавление кода компонента
Инсталляция компонента
Создание тестового приложения
Создание оболочки приложения
Задание формы диалога
Добавление кода приложения
Тестирование в подсоединенном режиме
Тестирование в отсоединенном режиме
Глоссарий
Алфавитный указатель
ОТРЫВОК
Глава 6Типы приложений
Отличия приложений COM+
Компоненты на основе сервера
Преимущества COM+
Атрибуты, контекст и состояние
Четыре уровня изменения компонента
Вопросы программирования
Производительность
Защита
Типы приложений COM+
Приложения сервера
Приложения библиотеки
Прокси-приложения
Предустановленные приложения
Автономный режим приложения
Работа с MTS и MSMQ по отдельности
COM сильно изменилась за последнее время. Обычно COM обеспечивала доступ к двум очень разным видам приложений, и области применения этих приложений были ясны. Однако по мере того как Microsoft разрабатывала COM, число и типы COM-приложений также увеличивались. Это разнообразие началось с ActiveX. Двумя самыми общими технологиями ActiveX являются приложения ActiveX Components и ActiveX Document. Однако многие из нас уже работали с Active Accessibility, Active Channel, Active Desktop, Active Input, Active Link, Active Script и Active Server. (Из-за того, что сегодня есть так много технологий Active, Microsoft отступила от того, чтобы делать ActiveX синонимом COM - это только вносило бы путаницу в последующие выпуски.) Список продолжает расти, но вы получили представление, - COM больше не ограничивается одним типом приложения - сегодня он фигурирует в каждом аспекте программирования Windows.
Поскольку разрастание COM на рабочем столе уже не новость, происходит обновление компонентной технологии Microsoft. COM+ представляет собой расширение использования COM от рабочего стола и локальных сетей до всего предприятия, включая Интернет. Так как COM+ обеспечивает значительно больше в на- правлении поддержки приложения, важно разбираться в новых типах приложений и усовершенствованиях текущих приложений. Конечно, для создания COM+ это также означает рассмотрение новых или обновленных технологий, которые уже были включены в COM. Самые важные из этих технологий - это Очередь сообщений Microsoft (Microsoft Message Queue, MQMS), Сервер транзакций Microsoft (Microsoft Transaction Server, MTS) и Распределенная модель компонентных объектов (Distributed Component Object Model, DCOM). Некоторые новейшие технологии включают Active Directory (еще одна из "Active" технологий, введенная Microsoft). Есть также технологии, которые отличаются от старых технологий только названием. Например, Queued Components предста
вляет собой не что иное, как расширенную часть MSMQ. В этом случае Microsoft не вводит реальной новой технологии; она добавляет новое имя к расширению существующей технологии.
ПРИМЕЧАНИЕ Мы уже обсуждали две обновленные технологии Microsoft. В Главе 4 мы подробно обсудили MTS, в Главе 5 мы обсудили MSMQ. Важно понимать, что в прошлом эти технологии существовали как отдельные продукты. Все, что сделала Microsoft - упаковала эти продукты как часть COM+ и добавила к ним специфичную для COM функциональность. Например, MSMQ первоначально была создана для оперирования сообщениями, сейчас она также может оперировать объектами. Обязательно прочтите о различиях между первоначальными версиями MSMQ и MTS и их сестрой и братом в COM+. Понимание того, почему эти добавления работают именно так, очень важно в контексте этой главы.
В этой главе мы посмотрим на различные виды приложений, которые вы можете создавать, используя COM+ множеством способов. В первом разделе мы посмотрим на части, составляющие приложение COM+. Затем мы рассмотрим вопросы программирования, о которых вам следует позаботиться, такие как производительность, масштабируемость, защита и доступность. Следующие пять разделов содержат сущность сегодняшней разработки приложения COM в форме моделей приложений, которые вы можете относительно просто создать, используя существующие инструменты программирования и специальные SDKs. В следующем разделе мы посмотрим на новые функции Windows 2000, которые работают совместно с отсоединенными приложениями, для гарантирования того, что необходимо для пользователей, работающих не на линии: базу данных в памяти. Наконец, в двух последних разделах главы мы рассмотрим две автономные технологии, влияющие на разработку вашего приложения COM+: MSMQ и MTS. Несмотря на то, что можно было бы поспорить, что эти две технологии уже относятся
к COM+, тот факт, что они управляются отдельно, могут иметь доступ отдельно от приложения, и даже могут быть установлены отдельно, говорит совсем о другом.
Отличия приложений COM+
Приложения COM+ выполняются на рабочем столе. DCOM может до некоторой степени расширить эту область COM, позволяя вам также выполнять часть приложения на другой машине. Однако фактом остается то, что COM и DCOM по существу начинают с рабочего стола, частично расширяясь в LAN, и не более того. Сегодня компания не может остановиться на LAN; она шагает по всему миру. (Возможно завтра, даже мир покажется слишком маленьким для того, чтобы удовлетворить приложения, выполняемые на уровне галактик, но это всего лишь предположение о будущем.)
Одна из главных причин, по которой Microsoft создала COM+, состоит в расширении информационной деятельности компаний до WAN и Интернета. Другими словами, COM+ представляет собой отчасти расширенную функциональность, и отчасти расширенную область. Есть еще одна причина, по которой вам стоит использовать COM+, помимо новых добавлений к технологии, которую обеспечила Microsoft - например объединения MTS и MSMQ. Этой причиной является расширенная область, - теперь вы можете создавать приложения, не привязанные к рабочему столу или LAN. Дело заключается в том, что приложение на уровне предприятия больше не ограничивается только LAN. Компании партнеров хотят иметь доступ к вашим данным, что означает необходимость обеспечения их защищенным доступом к базам данных вашей компании через виртуальную частную сеть (VPN). Это такое же соединение, которое позволяет работникам, находящимся в дороге, получать доступ к корпоративной сети. Сегодня у нас есть все ресурсы для выполнения приложений, независимо от того, где мы
находимся - одно из таких решений и представляет собой COM+.
Приложения COM подразделяются на две категории: внутрипроцессный сервер и внепроцессный сервер. Компоненты используют комбинацию интерфейсов, содержащих методы, свойства и события, для того чтобы работать с приложениями, которые они поддерживают. На самом низком уровне, COM+ обеспечивает ту же структуру, что и COM. Вы по-прежнему используете методы для получения доступа к функциональным возможностям компонента. Поведение компонента по-прежнему изменяется через использование методов, изменяющих значения свойств. Наконец, компонент по-прежнему отвечает пользователю или другим стимулам приложения через использование событий, на которые, в свою очередь, может реагировать ваше приложение. Коротко говоря, COM+ это не что-то новое - это расширение существующей технологии.
Самый простой способ для того, чтобы дать определение COM+, заключается в том, чтобы представить его как смесь COM с MTS, MSMQ и DCOM, и добавить несколько новых компонентов, для того чтобы описание перехода был полным. Коротко говоря, COM+ - это технология, которая дает возможность разработчику поддерживать приложения на уровне предприятия без ограничений, свойственных предыдущей работе с COM, подобно DCOM. В результате, COM+ поддерживает все те же самые элементы, которые обеспечивает COM.
В этом разделе главы мы не будем обсуждать элементы, специфичные для COM. Мы рассмотрим различия между COM и COM+. Что делает приложение COM+ особенным? Насколько приложение COM+ уникально при сравнении его с приложением COM? Ответы на эти вопросы очень важны, потому что вы должны знать, какие новые элементы COM+ привносит в стол программиста.
ПРИМЕЧАНИЕ Пуристы скажут вам, что COM+ на самом деле представляет собой супернабор COM, и они будут правы. COM+ предлагает то же самое, что предлагает COM, плюс возможность эффективно работать на уровне предприятия. В этом разделе главы мы позволим себе некоторую свободу с обычными определениями COM+ для того чтобы выяснить, что делает COM+ уникальной. Обычно при изучении новой технологии хороший подход заключается в том, чтобы посмотреть, чем она отличается от той технологии, которую вы уже знаете, и затем подробно изучить эти отличия. Итак, важно читать этот раздел с точки зрения того, что делает COM+ уникальной, и это лучше, чем изучать COM+ целиком.
Соотношение возможной и воспринимаемой мощности компьютерной техники
Кто-то заметил, что, несмотря на то, что мощность обработки данных наших машин увеличивается, реальная вычислительная мощность остается прежней. Поначалу это представление кажется нелепым, потому что мощность обработки и в самом деле увеличивается с астрономической скоростью. Однако после более глубокого ознакомления с последними записями групп новостей, становится очевидным, что вычислительная мощность оставалась относительно постоянной, начиная с середины и до конца 1980-х годов. Причина проста: пользовательский интерфейс вырос так, что поглотил почти все новые возможности процессорных циклов.
Сегодня пользовательский интерфейс в приложениях работает лучше и может больше помочь пользователю в выполнении работы, но мощность бизнес-логики, стоящей за этим приложением, по существу остается неизменной. Действительно, на нескольких семинарах Microsoft это было общим предметом обсуждения. Представление, что вы можете использовать новую технологию пользовательского интерфейса, не меняя код для вашей бизнес-логики, является общим. 10-15 последних лет мы фокусировались на создании приложений, которые были бы автома- тическими и уменьшали ошибки пользователя. Учитывая этот момент, многие функции пользовательских интерфейсов, которые мы воспринимаем как должное, подобны блокам орфографического контроля, которые проверяют орфографию в фоновом режиме, в то время как мы печатаем. Крупноформатные таблицы и другие общие приложения включают в себя "мастеров" и обилие автоматической обработки, - по существу уменьшая необходимость для пользователя задумываться над задачей.
Есть ли что-нибудь неправильное в улучшении пользовательского интерфейса, если учесть, что при этом неизбежны некоторые издержки бизнес-логики? Теоретически, нет, - улучшение пользовательского интерфейса делает пользователей более производительными, уменьшая стоимость бизнеса и для обучения, и для времени обработки каждой операции. Показателем является то, что сегодня довольно много циклов обработки используется для создания пользовательского интерфейса - циклов обработки, которые могли бы быть использованы для бизнес-логики. COM+ означает больше, чем появление новых технологий - она дает разработчику возможность решать, когда пользователь нужен, а когда нет.
Исключение пользователя из цикла обработки данных там, где это возможно, позволяет вам более производительно использовать новые возможности, обеспечиваемые COM+. Есть реальный пример улучшенной обработки данных в вашем местном универсаме. Сегодня магазины используют UPC-код и сканеры, потому что пользователи слишком медленно вводят данных вручную. Компьютеры обрабатывают данные намного быстрее, если участие пользователя сводится к минимуму. Электронная коммерция сделала следующий шаг, исключив всех продавцов и позволив покупателю оплачивать расходы для получения отдельных товаров при считывании на кассовом аппарате. Коротко говоря, розничная торговля уже нашла способ исключить из цепочки пользователя.
Это ставит точку во всем обсуждении. Сегодня есть несоответствие между мощностью обработки, используемой для реальных нужд бизнеса, и пользовательским интерфейсом. Давайте посмотрим на пользовательские интерфейсы в зависимости от количества бизнес-обработки (в общем). В середине 1980-х, около 50 процентов 8MГц вычислительной мощности компьютера использовалась для пользовательского интерфейса. Используя процессор 266 MГц в качестве примера, и полагая, что мы по-прежнему используем те же 4МГц для обработки бизнес-логики, около 98,5 процентов процессора вовлекается в работу для пользователя или операционной системы - всего лишь 1,5 процента вовлекаются в выполнение реальной бизнес-обработки. Подумайте, что вы могли бы сделать для продуктивности своей компании, если бы вы исключили частично или полностью участие пользователя в конкретных задачах обработки. COM+ обеспечивает вас инструментами, которые необходимы для того чтобы производить бизнес-обработку без какого-либо участия пользователя - вам нужно только
обеспечить выполнение необходимых решений.
Компоненты на основе сервера
Первоначально COM была разработана для работы на рабочем столе как метод для создания приложений с предварительно построенным кодом в пакетах, называемых компонентами. Эта технология получила расширение в сети через DCOM, но по-прежнему, по существу, вы выражаете представление клиента о компоненте, обрабатывающем данные посредством DCOM. Приложения COM+ представляют собой внепроцессные серверы.
Как вы видели в Главах 4 и 5, методы, используемые приложением для получения доступа к серверу, когда один-единственный раз вы включаете в общую картину MTS и MSMQ, почти не ограничены. У вас есть возможности не только прямого соединения, которые предлагают технологии, подобные DCOM, через использование RPCs, но теперь у вас также есть возможности обмена сообщениями различного сорта посредством использования MSMQ. Например, в отличие от DCOM, когда вы не могли быть абсолютно уверены в том, что данные посылаются тогда, когда вы их посылаете и одним куском, добавление MSMQ и DCOM вместе в COM+ позволяет вам сделать это предположение. Данные, которые вы посылаете от клиента к серверу, будут получены в их месте назначения, и наоборот. Коротко говоря, представление о том, что значит сервер на самом деле, изменилось. Да, компонент, к которому получает доступ ваше приложение, все еще принадлежит отдельному процессу (в большинстве случаев на отдельной машине), но взаимодействие с этим компонентом теперь будет раз
личаться в зависимости от способа, которым запрограммировано приложение.
Преимущества COM+
COM+ также вносит изменения в назначение и терминологию COM. COM используется для создания того, что Microsoft называет клиентскими компонентами. Клиентский компонент все время взаимодействует с отдельным клиентом - подобно кнопкам и другим объектам, используемым для создания приложений Windows. Да, вы можете создавать серверные компоненты посредством COM, к которым клиент может получить доступ через DCOM, но это действие имеет слабое отношение к тому, что обеспечивают компоненты COM+.
COM+ используется для создания исключительно серверных компонентов. По большей части эти серверные компоненты предлагают определенный тип служб - в самом общем виде это службы, которые оставляют нетронутыми установленные вами бизнес правила. Эти компоненты во многом отличаются от компонентов COM, но три самых важных отличия включают в себя местоположение, масштабируемость и надежность.
Элементом местоположения COM+ является сервер. Располагая вашу бизнес-логику на сервере, что лучше, чем часть приложения на клиентской машине, вы уменьшаете количество сетевого трафика, необходимое для завершения каждой транзакции. Кроме того, бизнес-логика теперь защищается на сервере, что лучше, чем когда она открыта случайному взгляду на клиенте. Это означает, что улучшается защита вашего бизнеса в целом. COM+ представляет собой тот редкий случай, когда улучшение защиты также означает улучшение во всех областях сервера, сети и производительности клиента. (Понятно, что это предполагает, что вы написали компонент COM+, использующий возможности COM+, самым лучшим образом - любая технология может оказаться неэффективной в плохих руках.)
Размещение компонента на сервере также означает, что ваш компонент лучше масштабируется. Клиенту не нужно знать, где выполняется компонент, достаточно того, что компонент существует где-то в сети. Это означает, что у вас может быть один и тот же компонент, бегающий на множестве серверов. Ваше приложение может масштабироваться в соответствии с текущими потребностями пользователя. Конечно, этот элемент картины COM+ на самом деле не будет полным до тех пор, пока Microsoft не выполняет выравнивание компонентной нагрузки (Component Load Balancing, CLB), которое должно появиться ко времени, когда вы читаете эту книгу.
Возможность произвести защиту вашего компонента, гарантирование того, что данные достигают своего пункта назначения, и работа нескольких серверов в одно и то же время в итоге ведут к надежности. Клиент даже не будет знать о простое из-за поломки, если у вас есть множество серверов, потому что другие серверы в кластере возьмут на себя дополнительную нагрузку в случае поломки одного из серверов. Коротко говоря, COM+ добавляет фактор надежности, который не обеспечивала COM.
Атрибуты, контекст и состояние
Комбинация COM и MTS означает, что теперь у ваших компонентов есть три новых функции и один дополнительный уровень доступа. При работе только с COM, у вас есть доступ к компоненту как целому, классу компонента и отдельным интерфейсам, которые содержит компонент. Эти три уровня доступа прекрасно работают для компонентов на рабочем столе, потому что вы можете отдельно конфигурировать каждый компонент, - но они не работают во многих ситуациях для предприятия, потому что они ограничиваются тем, что вы можете делать с компонентом в отношении конфигурации внешним образом. Эта ограниченная гибкость означает, что, например, при работе с COM вы не можете установить защиту иначе, чем на уровне компонента. С другой стороны, COM+ позволяет вам получить доступ к компоненту на уровне метода. COM+ дает вам лучший контроль над способом работы изнутри компонента без добавления довольно большого дополнительного кодирования и обеспечивает возможность перекомпиляции компонента в дальнейшем. Вместе с новым уровнем доступа, ко
мпонент COM+ включает понятия состояния, контекста и атрибутов. Атрибуты сообщают серверу о том, как должен работать компонент или каким способом он должен конфигурироваться. Например, есть атрибут, который сообщает серверу, что ваш компонент должен работать в транзакции, а другой атрибут сообщает серверу, что нужно использовать синхронизацию. Параметры конфигурации могут включать список людей, которым разрешается использовать этот компонент.
Контекст представляет собой комбинацию атрибутов, присвоенных компоненту, и информации, полученной клиентской машиной через запрос клиента (информация о клиентской машине может включать метод, использованный клиентом для создания соединения с сервером). Как вы помните из нашего рассмотрения защиты на основе ролевых имен в Главе 3, контекст очень важен для понимания того, кто назначает ваш компонент и каким способом. Контекст используется не только для защиты, вы также можете использовать его для выбора способа взаимодействия компонента с LAN пользователя. Вы можете выбирать назначение компонента через Интернет. Действительно, одинаковые пользователи могут получать разную трактовку роли в зависимости от того, где они получили доступ к компоненту. Коротко говоря, контекст обеспечивает безопасную среду для компонента, для того чтобы доводить его работу до конца. Компонент знает все, что ему необходимо знать для безопасного и эффективного выполнения.
Понятие контекста также применимо к компонентам. Если текущий объект запрашивает службы другого компонента, то тогда он может сделать запрос сервера, где находится этот компонент. Сервер создает копию этого компонента для создания нового объекта, который может использовать первоначальный объект. Контекст для нового объекта создается из комбинации атрибутов нового объекта и информации, передаваемой о запрашивающем объекте - в действительности ничего не меняется в способе производства контекста.
MTS относится к среде, не использующей информацию о состоянии, и он формируется с традиционной точки зрения COM. Однако, информация о состоянии включается посредством COM+. Компонент в некотором роде должен сохранять информацию о состоянии. Большое отличие от COM+ состоит в том, где хранится информация о состоянии. Вы можете хранить информацию о состоянии компонента COM+ любым из следующих способов:
управляемую клиентом;
на объекте;
в совместно используемом переходном состоянии;
в состоянии долговременного хранения.
Используемый компонентом параметр сохранения состояния очень важен. Например, вы не можете использовать схему сохранения состояния на объекте для транзакционных компонентов, потому что состояние не может сохраняться при пересечении границ транзакции. Причина этого ограничения заключается в том, что вы не хотите, чтобы различные компоненты в транзакции видели друг друга. Транзакция должна обеспечивать очень ясное установление границ, так чтобы когда происходит ошибка, MTS мог прокручивать транзакцию назад относительно легко, и вам не нужно было бы беспокоиться о неожиданных результатах, которые могли бы получиться, если бы границы транзакций были бы размытыми, а не четкими. Данные, просачивающиеся между транзакциями, могут не позволить вам провести полное восстановление, необходимое при возникновении сбоя.
Здесь вы, возможно, подумаете, что управление состоянием посредством объекта для COM+ является совершенно некорректным. Но это не совсем так. Вы можете сохранять информацию о состоянии на объектной основе, используя экземпляры переменных при работе с классами Visual C++. Разница между COM и COM+ состоит в том, что вы не можете располагать информацией о состоянии внутри тех экземпляров переменных, которые будут сохраняться при пересечении транзакционных границ, - фактически, вы должны предполагать, что любые экземпляры переменных поддерживают информацию о состоянии при изменении границ транзакции. Коротко говоря, если время жизни объекта меньше, чем время жизни транзакции, то тогда сохранение информации о состоянии внутри экземпляров переменных обычно прекрасно работает. Единственный раз, когда вы сталкиваетесь с затруднением, происходит, если объект продолжает существовать дольше, чем транзакция - в этом случае лучше использовать другие средства для сохранения информации о состоянии, чтобы избежать просач
ивания данных.
Один из способов избежать проблем, возникающих в связи с управлением состояния на объекте, заключается в использовании состояний, управляемых клиентом. В этом сценарии вы сохраняете информацию о состоянии у клиента, а не у компонента. Когда Windows 2000 создает новый объект для клиентского пользования, информация о состоянии переходит вместе с другой информацией о клиенте к форме контекста для введения объекта. Понятно, что результат использования состояния, управляемого клиентом, является таким же, как механизм состояния на объекте; единственное, что меняется, это то, где сохраняется информация о состоянии.
Иногда вам нужно сохранять информацию о состоянии объекта при пересечении границ транзакции, но по некоторым причинам цена перемещения этой информации от клиента к серверу слишком высока. В другом сценарии вам может понадобиться сохранить одну и ту же информацию о состоянии объекта на множестве клиентов. В обоих случаях, решение заключается в совместно используемом переходном состоянии. Теперь это служба, обеспечиваемая Windows 2000 в форме менеджера свойств совместного использования (Shared Property Manager). Менеджер свойств совместного использования используется на области жесткого диска сервера для сохранения информации о состоянии объекта, которая становится коллективной при развитии транзакции. Информация о состоянии сохраняется под особенным ключом - точно таким же, как те ключи, которые используются менеджерами баз данных. Клиент или объект проходят этот ключ к менеджеру свойств совместного использования для регистрации информации о состоянии для конкретного объекта.
Бывают случаи, когда существующие решения могут использоваться для ответа на вопросы, поставленные новыми технологиями. Наиболее гибкий и масштабируемый метод для сохранения информации о состоянии представляет собой долговременное хранение, подобное базам данных. Использование баз данных является более гибким, чем любой другой метод сохранения информации о состоянии, потому что у вас есть общее управление над тем, каким образом сохраняется информация о состоянии и в каком виде это происходит. Используя централизованную базу данных, вы перемещаете информацию о состоянии объекта от одного сервера, и делаете ее доступной множеству серверов. Это означает, что объекты, которые должны использовать одну и ту же информацию о состоянии, имеют доступ к этой информации независимо от того, на каком из серверов они работают. В этом месте вступает в игру фактор масштабируемости, - информация о состоянии может храниться в определенном хранилище и использоваться множеством серверов так же легко, как если бы она использов
алась одним сервером.
Четыре уровня изменения компонента
В следующих разделах мы рассмотрим четыре уровня новых или обновленных элементов приложения COM+: приложение, компонент, интерфейс и метод. Вы должны признать, что эти же элементы обсуждаются в компонентах COM. Мы обсудим их в свете вопросов местонахождения, масштабируемости и надежности. Кроме того, мы рассмотрим понятия состояния, контекста и атрибутов, которые влияют на эти четыре элемента. Цель этих четырех тем для обсуждения состоит в том, чтобы помочь вам понять, чем COM+ отличается от COM; эти разделы не служат тому, чтобы понять как работает COM или COM+.
Приложение
Microsoft приложила большие усилия, чтобы гарантировать, что приложение, написанное вами вчера, будет продолжать работать с COM+. Действительно, используя усовершенствованные элементы регистрации, для сохранения компонентов на сервере вы теоретически могли бы переписать приложение только со стороны клиента. Основные преимущества такого подхода перечисляются далее:
Защита. Расположение компонентов на сервере делает их более защищенными. Вы можете лучше управлять защитой на сервере. Понятно, что поддержание компонента защищенным имеет преимущество в защите вашей бизнес-логики, которая обычно включает в себя информацию, чувствительную к способу, которым вы ведете бизнес, и выполняет определенные задачи (такие как оценка стоимости служб). Одно из видимых преимуществ такой защиты заключается в том, что окончательные данные остаются в сети. Если кто-то наблюдал вашу сеть, лучшее, что они могли бы надеяться получить, это сырые, необработанные данные. Коротко говоря, расположение компонента на сервере лучше, чем удержание компонента на клиенте, если вы хотите поддерживать максимальную защиту.
Производительность приложения. У запуска приложения исключительно на клиенте есть определенные недостатки. Если вы рассматриваете мощность обработки сети как отдельный элемент, тогда работа с отдельными компонентами на каждом клиенте является ненужной тратой общей мощности обработки. Более производительно запускать элементы непользовательского интерфейса (компоненты) на сервере, где возможность накопления объектов и другие новые функции Windows 2000 могут оптимизировать использование объектных ресурсов.
Скорость выполнения (быстродействие). С точки зрения пользователя, хорошо написанное приложение должно выполняться быстро и не вынуждать пользователя ждать. Удержание всего приложения на клиенте отвечает за всю обработку. Это замечательно, если клиент находится на современной машине, но у большинства работников корпорации, вводящих данные, нет современных машин. В этом случае, с точки зрения пользователя, передача определенных задач бизнес-обработки на другую машину может действительно сделать приложение работающим быстрее. Для пользователя время ожидания, необходимое для обработки запроса к серверу, в большинстве случаев гораздо меньше времени ожидания при локальной обработке данных.
Надежность приложения. Мы уже довольно много говорили о том, как COM+ делает стратегию приложения на основе компонентов более надежной. Переписывание существующих приложений для использования этих функций COM+ увеличивает в этом случае надежность всюду, где только можно.
Уменьшение сетевого трафика. Сегодня большинство приложений пишутся таким образом, чтобы они могли производить множество запросов к серверу, особенно если это приложение выполняет какую-либо форму обработки базы данных. Рассмотрим простое действие отыскания имени пользователя в базе данных сервера. Приложение, которое использует все локальные компоненты, должно соединиться с базой данных, получить доступ к нужному набору записей, определить, существует ли этот пользователь, получить одну или несколько записей, согласующихся с критерием поиска, и, наконец, выбрать отдельную запись, в соответствии с выбором пользователя. Коротко говоря, это потребует минимум пяти передач и подтверждений для выполнения поиска имени пользователя, используя обычные методы. Использование подхода COM+ позволяет вам уменьшить число передач и подтверждений до трех: произвести запрос поиска, выбрать пользователя из записей, соответствующих критерию поиска и получить одну запись, которую пользователь выбрал для проведения этой частной т
ранзакции.
Масштабируемость. Как уже упоминалось, размещение компонента на сервере позволяет вам масштабировать приложение в соответствии с нуждами многих пользователей по мере роста вашей компании. Пользователю необязательно знать (или даже проявлять интерес), какой именно сервер отвечает на его запрос, что означает, что COM+ может динамически выбрать наименее загруженный сервер. Конечно, мы должны подождать до тех пор, пока Microsoft реализует CLB (или как там они его назовут) перед тем, как это преимущество станет реальностью.
Удобство сопровождения. Это самая лучшая часть всей картины и с точки зрения сетевого администратора, и с точки зрения разработчика. Гораздо легче обновить один компонент на сервере, чем устанавливать множество компонентов на отдельных машинах пользователя. Производство приложения, которое легко удерживать, означает, что более вероятно, что обновления будут производиться своевременно и уменьшает как требования поддержки помощи на рабочем столе, так и трудности для администратора.
Создание приложений на основе использования COM+ только повышает преимущества, перечисленные в этом разделе. Однако для проектировщика приложения есть нечто большее, что можно ожидать от уровня приложения. Вам нужно проектировать приложение, используя COM+ в качестве основания для создания приложения, работающего в отсоединенном режиме. Более того, высоконадежное приложение, позволяющее вам использовать транзакции для гарантии надежности данных, требует подхода к проектированию от основания.
Компонент
Создание более надежных, более быстрых и более производительных приложений представляет собой замечательную цель, но на самом деле нереальную для самого разработчика. Улучшения на уровне приложения, обеспечиваемые COM+, предназначены для всех администраторов сетей и пользователей - разработчик не получает от них ничего особенного. Однако есть многочисленные улучшения для возможностей программирования компонентов, которые разработчик получает от COM+. По мере развития темы этой книги они еще будут подробно описываться, но следующий список даст вам некоторое представление о том, какие улучшения вносит COM+ с точки зрения разработчика:
компоненты, выстроенные в очередь (Queued Components, QC);
слабосвязанные события;
базы данных в памяти (In-Memory Database, IMDB);
транзакционный менеджер совместно используемых свойств (Transactional Shared Property Manager, TSPM);
накапливание объектов;
выравнивание компонентной нагрузки (CLB).
ПРИМЕЧАНИЕ Хотя Windows 2000 не вводит возможность IMBD, Microsoft планирует выпустить продукт с по-добными возможностями. Считайте IMBD "заполнителем" для технологии, которую Microsoft выпустит в будущем. По существу, эта новая технология позволит вам создавать статистические базы данных, которые находятся в памяти вместо того, чтобы быть на диске. Удержание баз данных в памяти сильно улучшает как производительность сервера, так и время отклика приложения. Понятно, что разработчики должны будут использовать эту новую возможность с осторожностью, - вы будете ее использов
ать для маленьких баз данных, а не для стандартных баз данных с возможностью больших изменений в них.
В добавление ко всем этим новым особенностям программирования, существующие технологии, такие как MTS, содержат довольно много новых функций, которые разработчик сможет использовать для создания компонентов, которые будут надежными, хорошо масштабируемыми и все-таки требующими небольшого количества времени для построения. Теоретически, количество времени, необходимое для создания большинства компонентов, должно уменьшиться на 20-30 процентов. Это предполагает, что вы в настоящее время добавляете такие вещи, как защита, вручную. (Для более детального
ознакомления с тем, как защита на основе ролевых имен будет влиять на стратегию программирования ваших приложений, обратитесь к разделу "Защита на основе ролевого имени" в Главе 3.)
ПРИМЕЧАНИЕ Компонентное выравнивание нагрузки представляет собой еще одну технологию, которая не выпущена с Windows 2000, но она должна появиться к тому времени, как вы будете читать эту книгу. Microsoft находится в процессе бета-тестирования CLB, поэтому вы увидите ее выпуск как отдельного продукта. CLB является существенно технологией COM+, поэтому вы действительно должны добавить ее к каждой создаваемой вами установке сервера. Она представляет собой часть COM+, которая позволяет вам запускать компоненты на одном или нескольких серверах и динамически назначать поль
зователей серверам на основе такого критерия, как текущий уровень серверной нагрузки или уровень приоритета пользователя. Понятно, что Microsoft может рас-ширить роль CLB или изменить ее функции в то время, как вы читаете эту книгу, поэтому убедитесь, что вы прочли всю документацию Microsoft, для того чтобы подробно изучить CLB.
Здесь вы, возможно, озаботитесь тем, что написание компонентов COM+ потребует совершенно другой методологии программирования. Вы будете приятно удивлены, когда обнаружите, что создание компонента и методология получения доступа остаются точно такими же. Клиентские приложения по-прежнему должны запрашивать сервер для создания копии компонента в форме объекта. Все получения доступа по-прежнему полагаются на методы, которые связываются в интерфейсы. Вы по-прежнему используете IUnknown для запроса компонента и для того чтобы узнать, какие службы он предлаг
ает. Все эти элементы остаются точно такими же. Изменяться будет внутреннее кодирование самого компонента, которое является невидимым для всех во внешнем мире. Поскольку это относится ко всем, кроме разработчика, для них все остается точно таким же, как и раньше.
Можно сказать, что использованию COM+ нет цены. Есть некоторые вещи, которые вы не можете сделать никаким другим способом. Например, вы не можете надежно использовать библиотеку базовых классов Microsoft (Microsoft Foundation Classes, MFC), мастера компонентов (Component Wizard) для создания компонентов COM+. Microsoft сконцентрировала все свои усилия на методе создания компонентов посредством библиотеки активных шаблонов (Active Template Library, ATL). Это означает, что те разработчики, которые предпочли простоту MFC гибкости ATL, теперь должны изучать ATL и те сложности, которые она в себя включает. К сч
астью, вы можете добавить поддержку MFC к компоненту ATL, что означает, что вам не придется создавать все с нуля.
Для работы с COM+ вам также понадобятся новые инструменты. Visual C++ в настоящее время требует инсталляции Service Pack 3 для обеспечения сервисных средств отладки под Windows 2000. В добавление к обновленной редакции Visual C++, вам нужно установить Windows 2000 Platform SDK для получения доступа к новым возможностям COM+, и возможно также потребуется поддержка другого SDK. Например, более чем вероятно, вам понадобится специальный SDK для получения доступа к CLB функциям COM+, которые будут выпущены в отдельном пакете. Коротко говоря, не стоит надеяться на использование COM+ без определенной д
ополнительной установки инструментов на вашей машине, предназначенной для разработки с использованием всех возможностей COM+. Новые компоненты COM+ требуют поддержки, которую Microsoft не включила в Visual C++ 6.0. Будем надеяться, что вам не понадобится вся эта дополнительная поддержка при следующем обновлении Visual C++.
Тот факт, что Microsoft выбрала для выпуска Windows 2000 и без CLB, и без IMDB, вероятно, означает, что вы встретитесь с некоторой дополнительной сложностью в создании компонентов COM+, которые используют эти функции. К несчастью, мы не можем заглянуть в будущее и поэтому не можем представить себе, с какими дополнительными сложностями нам придется встретиться.
Интерфейс
С точки зрения кодирования, сегодня работа с интерфейсами в COM+ является точно такой же, какой она была с COM. Тем не менее, есть некоторые отличия в способах, которыми управляются интерфейсы, и которые обязательно влияют на ваш способ кодирования интерфейса. На рисунке 6.1 показано, как выглядит компонент COM+ в Component Service, встраиваемом модуле MMC, используемом для конфигурации различных типов компонентов под Windows 2000.
Заметим, что вам больше не нужно ломать голову над тем, какие интерфейсы поддерживает компонент, - они перечислены как часть отображенных данных Component Service. Windows 2000 обеспечивает вас довольно большим количеством информации о компонентах, которые инсталлированы на машине. Вы получаете иерархическое отображение данных каждого компонента, интерфейсы, которые он обеспечивает (по крайней мере, те из них, которые являются уникальными для этого компонента) и методы, обеспечиваемые этими интерфейсами.
Windows 2000 также позволяет вам конфигурировать интерфейсы. Напомним, что атрибуты этих интерфейсов влияют на контекст компонента. Вы можете изменить работу компонента, используя внешние атрибуты, вместо внутреннего кодирования. Обычно, интерфейсы обеспечивают доступ, по крайней мере, к трем атрибутам: общая информация о компоненте (включая описание), находится ли компонент в очереди, и какой уровень защиты на основе ролевых имен обеспечивает этот интерфейс.
В рассматриваемом частном случае мы смотрим на параметры защиты на основе ролевого имени для интерфейса IGetAppData. Заметим, что вы можете изменить доступ именно к этому интерфейсу, отмечая или не отмечая параметры защиты на основе ролевого имени. Тот факт, что вы можете подвергать различные атрибуты для администратора изменению, означает, что, несмотря на то, что метод получения доступа тот же самый (поэтому вам не нужно изменять ваш клиентский код), параметры для кодирования самого компонента изменились. Теперь вы можете обеспечить гораздо больший урове
нь гибкости при кодировании компонента, что означает, что компонент сможет лучше выполнять свою работу.
Вот так выглядит стандартное диалоговое окно Interface Properties.
Метод
Это одно из самых важных изменений, как для разработчика, так и для администратора. Раньше разработчик был вынужден соперничать с работой компонента как целого. Да, вы могли получить доступ к отдельному интерфейсу, но даже выполнение этой задачи требовало специального программирования. Конечно, выполнение чего-либо еще, отличного от вызовов методов различных интерфейсов, с помощью полученного вами указателя, полностью выходило за рамки этого вопроса. COM+ все это изменил. Теперь вы можете видоизменять атрибуты метода, используя интегрированный модуль
MMC Component Service, показанный на рис. 6.1.
Обычно методы предлагают только две закладки информации о конфигурации. Закладка General позволяет вам присваивать описание методу. Кроме того, есть управляющий элемент, который позволяет вам деактивировать объект, когда возвращается вызов метода. Вторая закладка, Security, позволяет получить доступ к защите на основе ролевых имен.
В приведенной далее частной иллюстрации отражены важные изменения. Администратор установил ролевое имя Reader для получения доступа к интерфейсу, связанному с этим методом. Заметим, что ролевое имя Reader представлено как унаследованное от уровня метода. Вы не можете отменить те привилегии, которые есть у ролевого имени Reader - любое получение доступа, предоставляемое на высшем уровне, автоматически снижается к более низкому уровню. Если вы хотите для ролевого имени Reader предоставить доступ только к определенным методам интерфейса IGetAppData, то вы должны предос
тавить доступ на уровне метода, вместо уровня интерфейса. Важно помнить об этой проблеме защиты на основе ролевых имен, так как вы обеспечиваете инструкции по конфигурации для администратора сети.
Вопросы программирования
Каждый раз при изменении метода, используемого для создания приложений для вашей компании возникают вопросы, связанные с программированием. Например, вам нужно рассмотреть, является ли экономия времени, связанная с усовершенствованием, более ценной, чем изменения в том, как пользователь работает с приложением. В определенных случаях, вам нужно учитывать это изменение, так как независимо от того, что вы делаете, отличие новой технологии может быть заметно со стороны пользователя. Многие компоненты COM+ (кусочки приложений) не влияют на то, как пользователь воспринимает приложение - в остальных случаях, таких как MSMQ, может быть полная неопределенность. В качестве части перехода от COM к COM+, вам нужно рассмотреть, будет ли изменение взаимодействия с пользователем положительным или нет.
Также нужно учесть стоимость, невидимую для разработчика и компании. Например, по данным последних статей в периодических изданиях, стоимость модернизации Windows 2000 колеблется от $500 на машину до $1,700. Вне зависимости от того, на какую цифру вы ориентируетесь, если вы хотите использовать COM+, то потребуются средства в размере стоимости замены программного обеспечения на новую версию Windows 2000. Эти затраты на новую версию программного обеспечения больше всего будут влиять на то, как вы будете писать приложения в ближайшем будущем. В некоторых случаях у вас может быть возможность сделать готовый компонент Windows 2000, но вы не сможете использовать данный компонент до тех пор, пока не замените программное обеспечение компании в целом.
Не стоит слишком рассчитывать на то, что COM+ будет бесплатным обновлением программного обеспечения, хотя Microsoft, возможно, хочет, чтобы вы считали именно так. COM+ придет со множеством приятных сюрпризов в виде уменьшения времени разработки, увеличения продуктивности пользователя и улучшения производительности и надежности приложения. Однако эти приятные сюрпризы придут с бирками с указанием цен для компании, разработчика и пользователя. Следующие разделы помогут вам лучше осознать некоторые соображения о программировании при работе с COM+. Мы подробно рассмотрим вопрос "Сколько это стоит?"
ПРИМЕЧАНИЕ Если вы работаете в большой компании, то тогда вполне вероятно, что вы работаете не с одной, а с несколькими компонентными технологиями. COM может быть только одним из решений, с которыми вам приходится иметь дело ежедневно. Единственная проблема до недавнего времени заключалась в том, что взаимодействие компонентов различных технологий друг с другом было очень затруднено, если не сказать невозможно. Многие компании обращаются к языку XML (Extensible Markup Language) для решения своих проблем совместимости. Больше общей инфор-мации об XML вы найдете у World Wide Web Consortium (W3C) на страничке http://www.w3.org/. Только XML обеспечивает стандартизованный метод для разметки документов. Все-таки должно быть что-то для определения того, какое содержание документа имеет значение. Это то место, где вступает в игру протокол Microsoft доступа к простому объекту (Microsoft's Simple Object Access Protocol, SOAP). SOAP обеспечивает средства для обмена данными между COM и другими компонентными технологиями,
такими как технология распределенных объектных приложений (обобщенная архитектура обработчика объектных запросов, Common Object Request Broker Architecture, CORBA), использующая XML в качестве посредника. Microsoft планирует выпустить обновление к Visual Studio в следующем году, что позволит разработчику получить доступ непосредственно к SOAP. Дополнительную информацию о SOAP вы найдете по адресу http://www.msdn.microsoft.com/workshop/xml/general/soaptemplate.asp. Если вы хотите посмотреть рекламные спецификации для SOAP с необходимыми комментариями, обратитесь по адресу http://www.iepg.org/docset/ids/draft-box-http-soap-00.txt.
Производительность
Нет никаких сомнений в том, что у COM+ есть потенциал для увеличения общей эффективности приложения с помощью различных средств, таких как организация пула объектов. Однако производительность измеряется не только тем, сколько времени необходимо пользователю для того, чтобы выполнить задачу или как долго программисту нужно разрабатывать приложение. Измерения производительности также могут варьироваться в широкой области других направлений.
Рассмотрим, к примеру, сколько стоит каждая транзакция. Когда вы пишите приложение, используя COM+ вместо COM, видите ли вы уменьшение стоимости каждой транзакции на сервере? Ответ на этот вопрос неоднозначен. Да, в долгосрочном плане вы увидите некоторое уменьшение в стоимости каждой транзакции до тех пор, пока приложение, которое вы разрабатываете, правильно использует возможности COM+ и пока Microsoft внедряет весь спектр возможностей, которые она обещала для COM+.
Однако в краткосрочном плане стоимость на одну транзакцию будет расти по ряду причин. Во-первых, у вас будет уходить больше времени на разработку приложения, потому что кривая обучения COM+ более крутая. Также будет расти стоимость оборудования. Машина с 64 Мбайт оперативной памяти (RAM) больше ничего не сможет сделать. Организация объектного пула, выстраивание сообщений в очередь, обработка транзакций и расширенные возможности защиты COM+ - все это стоит и процессорных циклов, и большого количества памяти. Даже Microsoft озабочена тем, как используется память, и прилагает усилия для того, чтобы помочь обучить разработчиков эффективному использованию памяти в среде COM+. Пользователи должны будут переобучиться, потому что обилие процедур, которые они использовали раньше для ввода данных, теперь может быть уменьшено до одной.
Получение достаточной пропускной способности сети представляет собой постоянную проблему для многих компаний. Кажется, всего несколько месяцев назад мегабитные сети были последним криком моды - сегодня гигабитные сети, возможно, считаются слишком медленными. Голос, видео и различные формы мультимедиа - у всех есть своя плата на рациональное использование пропускной способности сети. Это одна из областей, где блистает COM+. Вы можете создавать компоненты на стороне сервера, что может сильно уменьшить сетевой трафик. В некоторых случаях автору удавалось уменьшить трафик до 70 процентов - огромное уменьшение. Однако это преимущество также означает, что вам придется развивать исключительно COM+ и что вы должны создавать набор компонентов, которые сконструированы так, чтобы для выполнения своей работы они коммутировали с клиентом как можно меньше. (Мы рассмотрим пример типичной базы данных в Главе 7, там же вы увидите, что включается в типичное приложение предприятия.)
Производительность представляет собой один из "безвыигрышных" сценариев для разработчика. Всякий раз, когда производительность увеличивается в одной области, с этим связано увеличение стоимости в другой. Таким образом, один из первых вопросов программирования, который вам нужно рассмотреть в COM+, это то, какова цена воплощения этой новой технологии. Выгоды, которые вы видите, могут быть большими, но стоить это будет очень дорого. Вопрос, на который вы должны ответить, состоит в том, равна ли ценность полного воплощения COM+ его стоимости. Во многих случаях, заботы о производительности будут обуславливать поэтапный подход к воплощению COM+; до некоторой степени это не только допустимо, но продвигается по частям самой Microsoft.
Защита
Защита - это единственная область, где комбинация Windows 2000 и COM+ представляет самое лучшее, что сегодня может предложить Microsoft. При работе с Windows 2000 у вас есть доступ к новым технологиям защиты, таким как Kerberos и инфраструктура открытого ключа (PKI). COM+ добавляет в общую картину защиту на основе ролевых имен. (В Главе 3 приводится подробное обсуждение защиты на основе ролевых имен.)
Все эти параметры защиты могут добавить путаницу в дополнение к улучшению ваших возможностей по защите данных компании. Например, вам, возможно, придется взвесить, обновлять ли текущие приложения, которые полагаются на методологию защиты Windows NT Challenge/Response, которая, в свою очередь, полагается на защиту Windows NT LAN Manager (NTLM). Во многих случаях старые методы защиты прекрасно работают для приложений, основанных на LAN, но в мире Интернета вам уже понадобиться нечто большее. Решение об обновлении должно основываться на том, где вы собираетесь запускать приложение.
Несмотря на то, что защищать от вторжения ваши сети относительно легко, есть и другие соображения, связанные с программированием, когда дело касается защиты. Фактически есть четыре уровня защиты для типичного приложения COM+, написанного для сегодняшнего рынка. В следующем списке приводятся основные положения для всех четырех уровней:
Сервер. Сервер представляет собой самую простую часть приложения для защиты. Вам нужно лишь нажать правую кнопку мыши для большинства объектов в Windows 2000, выбрать, хотите ли вы распределять ресурсы или нет, затем назначить пользователей к этому ресурсу. Это является частью уравнения, в которой у очень немногих администраторов есть трудности в понимании.
Сеть. Создание защищенного пути коммуникации является важным соображением программирования. Некоторые разработчики, возможно, думают, что Windows 2000 обеспечивает новый и более эффективный метод защиты сети самой по себе, но в самой основе всего находится распределенная модель компонентных объектов (DCOM) и протокол удаленного вызова процедуры (RPC). Ни один из этих двух компонентов не является защищенным - для того, чтобы гарантировать, что сеть защищена, вы должны оп- ределенным образом ее сконфигурировать и добавить элементы программирования для компонента. Вы всегда должны защищать линии коммуникации для приложения глобальной сети (WAN) или Интернета.
Компонент. Создаваемый вами компонент должен полагаться на определенный вид передачи данных, для того чтобы иметь связь с клиентом. Защита сети делает трудным перехват сообщений, но ничего не делает для самих данных. Обычно при проектировании приложения для Интернета вы хотите добавить определенный вид шифрования данных и для данных, и для связанного с ними открытого ключа. Возможно, это также будет важным соображением для WANs, которые воплощаются путем использования технологий на основе Интернета, таких как виртуальные частные сети (VPNs).
Пользователь. Любой создаваемый вами план защиты должен включать защиту пользователя. Пользователь представляет самую большую щель в вашей броне защиты, и любые меры безопасности, применяемые вами без учета пользователя, являются пустой тратой времени. Излишне говорить, что эта часть плана защиты должна включать комбинацию физической и прикладной защиты. Если данные, управляемые создаваемым вами приложением, являются засекреченными, то вам нужно сделать такие вещи, как идентификация пользователя, имеющего доступ к информации, содержащейся в контроллере домена. Понятно, что каждый уровень защиты пользователя также включает обучение, но этот вопрос уже выходит за рамки книги.
Типы приложений COM+
В отличие от толкования COM, в COM+ используется понятие точного типа приложения. Тип приложения в этом случае не то же самое, что типы приложения, о которых вы думали на клиентской машине. Например, когда мы говорим о COM+, то есть типы приложений, не относящиеся к базам данных или крупноформатным таблицам. Вот список четырех типов приложений COM+:
Библиотека
Сервер
Прокси
Предварительно установленный
ПРИМЕЧАНИЕ Microsoft медленно надстраивает помощь для разработчиков, создающих полностью инте-грированные приложения распределенной внутрисетевой архитектуры (DNA). В частности, они учредили Microsoft Visual Studio Interoperability Studio, где можно изучать новые продукты и загружать дополнения, облегчающие процесс разработки. Практически, этот сайт сводит вместе все указатели к другим Web-сайтам Microsoft, которые обычно вы должны были бы собирать сами. На этом Web-сайте приводятся примеры (примеры заказчиков), инструменты и другие ресурсы, обеспечивающие возможность взаимодействия сетей. Этот сайт находится по адресу http://www.msdn.microsoft.com/vstudio/centers/interop/default.asp.
Отчасти причиной этого нового направления является то, что COM+ оперирует каждым видом приложения по-разному. Например, защита для приложения библиотеки управляется иначе, чем защита для приложения сервера. При работе с приложением библиотеки объект обрабатывается в клиентском процессе и для объекта используется контекст защиты клиента. С другой стороны, приложение сервера обрабатывается внепроцессно. Контекст защиты устанавливается посредством использования комбинации атрибутов компонента и клиентской информации, обеспечиваемой как часть запроса компонента.
Следующие разделы помогут вам лучше разобраться в том, чем различаются эти четыре типа. О различных типах приложений COM+ важно знать, потому что вам нужно определить, какой тип приложения разрабатывать.
Приложения сервера
Приложение сервера является внепроцессным сервером. Оно обрабатывается в своем собственном процессе и создает свой собственный контекст. Используя приложение сервера, вы можете получить доступ ко всем службам COM+, и все ресурсы главной машины находятся в вашем распоряжении (по крайней мере, в границах, установленных защитой).
Вам придется создавать приложение сервера чаще, чем любой другой тип приложения COM+, так как это самая универсальная форма приложения. Понятно, что этот вид приложения обрабатывается на сервере и порождает минимальное количество сетевого трафика (если вы оптимизируете его в этом направлении).
Приложения библиотеки
Приложение библиотеки представляют собой новейший способ для интеграции компонентов в приложении. Приложение библиотеки выполняется в клиентском процессе. Это означает, что, несмотря на то, что файл приложения библиотеки физически постоянно хранится на сервере и должен запрашиваться от сервера, он фактически выполняется на клиентской машине. Клиент загружает приложение библиотеки с сервера и использует его локально.
Из-за способа, которым выполняется приложение библиотеки, существуют определенные ограничения в способах вашей работы с ним и службами COM+, посредством которых вы можете получить доступ. Эти ограничения имеют смысл, когда вы думаете об ориентации клиента приложения библиотеки. Вот список этих ограничений:
нет поддержки удаленного получения доступа;
невозможно использование CLB;
невозможно использование компонентов, выстроенных в очередь.
Приложения библиотеки могут использовать защиту на основе ролевого имени. Однако уровень доступа для приложения библиотеки ограничивается доступом клиентского приложения. Другими словами, вы не можете создать компонент, который обеспечит клиентское приложение большим доступом, чем оно имеет обычно с его стандартными установками защиты. Это ограничение не позволяет инородному компоненту повредить систему или заглянуть в некоторые области сер- вера тем пользователям, которые не имеют права их видеть.
Итак, какие же есть преимущества у приложений библиотеки по сравнению со стандартными компонентами на стороне клиента? Вы получаете те же самые преимущества, которые дает приложение COM+, но со стороны клиента. Например, вы делаете обновления компонента на сервере, а не на клиентской машине. Доступ к компоненту защищается сервером, а не клиентом. Действительно, клиент фактически не видит копию компонента на диске, - она располагается на сервере и загружается в память клиента. Коротко говоря, использование приложений библиотеки позволяет вам получить самые большие выгоды компонентов со стороны клиента без множества проблем, которые стоят перед компонентами со стороны клиента.
Прокси-приложения
При работе с DCOM вы должны были либо использовать утилиту DCOMCnfg для конфигурирования машины клиента, чтобы обеспечить доступ к удаленному приложению, либо найти какой-то метод для добавления необходимых элементов регистрации через удаленное приложение. Этот процесс был не только трудным и чреватым ошибками, но он также требовал определенного количества времени администратора для каждого нового клиента и каждой новой версии компонента. Коротко говоря, с точки зрения приложения, старая методология отнимала много времени и почти всегда была ненадежной.
COM+ обеспечивает приложение прокси. Это не компонент, но заместитель для компонента, который регистрируется на сервере. Приложение прокси работает на клиентской машине и автоматически добавляет информацию в системный реестр о настоящем компоненте, который расположен на сервере. Эта информация о компоненте включает идентификацию класса (CLSIDs), идентификацию программы (ProgIDs), имя удаленного сервера (RemoteServerName) и информацию о компоновке с объектами, расположенными на других машинах. Эта комбинация элементов позволяет клиенту получить доступ к компоненту на сервере, без какого бы то ни было вмешательства администратора или разработчика. Коротко говоря, Microsoft в COM+ автоматизировала то, что в других обстоятельствах стало бы задачей, требующей много времени и подверженной ошибкам.
Предустановленные приложения
COM+ пришла с группой предустановленных приложений. Некоторые разработчики могут подумать, что такие приложения используются только для COM+ - многие службы Windows раньше работали в точности так же. С COM+ верно и обратное; теперь вы содействуете использованию этих предустановленных компонентов для того чтобы облегчить вашу собственную работу по программированию.
Вы найдете все приложения COM+ в папке COM+ Application интегрируемого модуля Component Services MMC. Ряд приложений, которые вы увидите, отчасти зависит от того, какие дополнительные службы вы устанавливаете. Например, внутри этой папки есть компоненты, относящиеся к Queued Components. Здесь приводится список возможных элементов папки COM+ Application:
COM+ QC Dead Letter Queue Listener;
COM+ Utilities;
IIS In-Process Applications;
IIS Out-Of-Process Pooled Applications;
IIS System Application;
IIS Utilities;
System Application;
Visual Studio APE Package.
Заметим, что здесь добавлен один элемент, который не является специфичным для Windows 2000. Visual Studio APE (Application Performance Explorer) Package инсталлируется только в том случае, когда у вас на главном компьютере установлен Visual Studio. (Понятно, что вам также придется инсталлировать этот компонент как часть инсталляции Visual Studio.) Вы найдете, что папка COM+ Components интегрируемого модуля Component Services MMC может содержать широкий спектр компонентов, с которыми вы, возможно, не имели дела в прошлом. Настоящая цель размещения компонентов в этом месте состоит в том, чтобы сделать их для вас более доступными. Вы обнаружите, что использование интегрируемого модуля Component Services MMC даст вам новое понимание того, как COM работает в целом, и обеспечит гибкость, которой у вас никогда не было раньше.
Автономный режим приложения
Приложения в автономном режиме или отсоединенные приложения предлагают новые возможности для обслуживания нужд пользователей, находящихся в дороге. Использование автономной коммуникации означает, что пользователю больше не нужно соединение с компанией для создания заказов или выполнения других задач, которые не требуют прямого соединения, за исключением фактически обновляемых данных компании. Многие из этих вопросов мы обсуждали на протяжении Главы 5.
Есть и другие места, где автономное приложение могло бы быть полезным, которые мы не обсуждали в Главе 5. С точки зрения чистой теории, каждое приложение можно было бы считать автономным приложением. Использование техники построения автономного приложения позволяет каждому пользователю работать даже в том случае, если по каким-либо причинам локальный сервер прекратил работу. Конечно, является ли это практичным способом для построения приложения или нет, зависит от того, сколько вы готовы заплатить в единицах производительности системы, для того чтобы получить надежность, обеспечиваемую автономным приложением.
Автономное приложение всегда представляет один и тот же пользовательский интерфейс, даже когда нет соединения с сервером. В качестве контрапункта, автономное приложение уменьшает эффективность вашего приложения, из-за того, что каждая коммуникация упаковывается как сообщение. Кроме того, вам нужна машина, которая может работать как независимый клиент, что увеличивает требования к оборудованию для работы приложения. Коротко говоря, автономное приложение подойдет не для каждого.
Всегда есть компромиссные ситуации, которые также нужно рассматривать. Например, вы, возможно, не захотите конфигурировать клиентов, имеющих прямое соединение с сервером (внутри одного и того же здания или группы зданий) как независимых клиентов, из-за того, что вероятность трудного соединения относительно мала. Если вы используете множество серверов, то тогда вероятность простоя из-за аварийного отказа отдельного сервера незначительна, и потеря эффективности в этом случае была бы слишком высокой ценой. Однако вы должны принять во внимание конфигурирование офисов в других городах как независимых клиентов, - особенно если расстояние до такого офиса является таким, что разрыв соединения с сервером мог бы вызвать большое число потенциальных проблем, даже если нет повреждения оборудования компании. Использование такого подхода позволило бы вам получить максимальную выгоду от автономных приложений и при этом сохранило бы максимальную эффективность приложения.
Тем не менее, есть проблемы даже при таком двойном подходе к установке приложения. Например, при этом вы специально должны писать две версии одного и того же приложения. Первое не может выстраивать сообщения в очередь, а второе может. Суть всего этого заключается в том, что в COM+ не существует никаких магических пуль, особенно когда она переходит к работе с новыми функциями, такими как MSMQ и MTS. Вам нужно найти решение, которое будет работать наилучшим образом для текущей установки вашей компании. Иногда это может означать принятие риска, что пользователи не смогут работать в случае разрыва соединения с компанией.
Усовершенствования портативного компьютера позволяют использовать отсоединенные приложения
Есть новшества в области портативных компьютеров, делающие отсоединенные приложения не только желательным, но и особенным инструментом для определенного класса приложений. Первое новшество, делающее реальностью отсоединенные локальные приложения состоит в непрерывных улучшениях потребляемой мощности и срока службы батарей. В прошлом многие пользователи полагались на машины на рабочих столах, несмотря на то, что такие машины были неудобны для мобильных нужд.
Приложения ввода данных вряд ли потребляет всю пропускную способность 10 Мбит/с даже младшей модели Ethernet, - по крайней мере, не на уровне отдельной машины. Intel и другие компании в настоящий момент заканчивают спецификацию Bluetooth, которая позволит использовать беспроводные сетевые связи посредством технологии 2.45 ГГц радиосвязи при скорости передачи данных 1 Мбит/с. Это означает, что администратор сети сможет перемещаться из одной области компании в другую и совершенно не заботиться о переключении компьютеров. Перемещение из одного здания в другое означало бы, что любые приложения, с которыми имеет дело администратор, должны работать в отсоединенном режиме, потому что администратор работает вне здания. Как только администратор войдет в другое здание, все данные обновляются в фоновом режиме, и приложение снова работает в подсоединенном режиме. Бесконтактная природа Bluetooth делает все это возможным, потому что пользователю больше не нужно заботиться о создании физического соединения с системой.
Теперь у вас есть приложение, работающее даже без сетевого соединения, и пользователь, которому не нужно заботиться о создании физического соединения с сетью. При таком высоком уровне автоматизации нужно позаботиться о безопасности. Здесь вступают в игру самые новые технологии. Intel также работает над новой технологией, названной предзагрузочной службой аутентификации (Preboot Authentication Service, PAS). Эта технология позволит компьютерам laptop/notebook проверять идентификацию пользователя перед загрузкой операционной системы. Проверка может происходить с помощью различных типов технологий, не использующих пароль, таких как считывающее устройство отпечатков пальцев. Другие компании, такие как Veridicon, Inc., сообщают о похожих подходах. Veridicom BIOS eXtension(VBX) разрабатывает набор, включающий BIOS-обновление, программное обеспечение защиты и специальное считывающее устройство отпечатка пальца, что позволит компьютерам laptop/notebook проверять идентификацию пользователя перед загрузкой операцио
нной системы. В результате технология, которая делает отсоединенное приложение частью сценария каждого пред- приятия, а не только пользователя, находящегося в дороге, быстро становится реальностью.
Работа с MTS и MSMQ по отдельности
На протяжении всей главы мы рассматривали, что такого вы можете сделать с COM+, чего не можете сделать с COM. Изменения в компонентной стратегии Microsoft для Windows 2000 являются очень важными. Для большинства разработчиков понимание преимуществ использования COM+ намного перевешивает трудности изучения того, каким образом использовать ее в первый раз. (Данное текущее состояние инструментов Microsoft, таких как Visual C++, недостаток документации, и проблемы с объединением функций; кривая обучения для среднего разработчика действительно выглядит впечатляюще.)
Многие разработчики не могут понять, что MTS и MSMQ все же отдельные элементы, хотя может казаться, что они теперь объединяются с опорой на COM+. Вы можете писать приложения, использующие эти продукты, и старые приложения, которые вы создали раньше, будут работать, как и прежде. При написании нового приложения у вас есть доступ ко всем новым возможностям MTS и MSMQ, которые мы обсуждали в этой главе. Для вас как для разработчика это означает, что вы можете создавать более трудоемкие, чем MTS и MSMQ функции, и не использовать новую компонентную технологию.
Другое представление для многих программистов заключается в том, что Windows NT 4 не включала установку поддержки ни MTS, ни MSMQ. Для того чтобы получить необходимую поддержку, вам нужно установить сервисный пакет, по этой причине разработчик не может быть абсолютно уверен, что у целевой машины установлен или MTS, или MSMQ. Эти оба продукта пришли как часть пакета Windows 2000 по умолчанию, что означает, что вам не нужно делать никаких предположений для целевой машины. Вы всегда можете обуславливаться Windows 2000, для того чтобы иметь необходимую поддержку (или, по крайней мере, иметь возможность попросить администратора установить поддержку, используя стандартные диски Windows 2000).
COM+ также вынуждает вас принимать решение о том, как внутри вашего приложения получать доступ к MTS и MSMQ. Теперь у вас есть выбор между использованием метода получения доступа COM или организацией доступа непосредственно к MTS и MSMQ APIs. В чем отличие этих решений? Подумайте об этом как о выборе между гибкостью и скоростью разработки. Используя COM+, вы можете очень быстро добавить к компоненту функциональность MSMQ. Кроме того, вам не нужно изучать новые способы, как это сделать, потому что кривая обучения очень мала. Однако это достигается ценой скорости разработки, из-за того, что программисты Microsoft выбрали за вас общую структуру сообщения, когда вы используете подход COM+. К счастью, в большинстве случаев, общий подход к сообщению прекрасно работает, и вам не стоит беспокоиться об этом вопросе. Тем не менее, бывают случаи, когда приложение предполагает специфический формат сообщения. В этом случае вам нужно использовать непосредственно MSMQ API, потому что это единственный способ, когда вы можете выбрать специфический формат сообщения. Коротко говоря, при работе с COM+ вам необходимо заблаговременно решить, какие функции вам нужны, и от чего вы готовы отказаться, для того чтобы увеличить скорость разработки.
В конечном счете, Microsoft не дала вам какого-то одного нового инструмента в форме COM+. Они дали вам множество новых инструментов, которые могут выполнять широкий спектр новых задач. Как разработчик Windows 2000, вы не можете позволить себе смотреть только на поверхность поддержки приложения, которую обеспечивает этот продукт. Вы должны посмотреть на лежащую в основе технологию. Теперь Windows 2000 предлагает разработчику приложений больше, чем имела какая-либо другая версия Windows в прошлом.
Технология COM+: библиотека программиста (+CD). / Дж. Мюллер - СПб: Питер, 2001. - 464 с.
|