Использование Microsoft Transaction Server для работы с компонентами распределенных приложений

Сегодня для создания Web-приложений на серверах Windows 2000 и Windows NT 4.0 необходимо знать Microsoft Windows DNA. Windows DNA - архитектура, применявшаяся для построения прикладных программ Web и Win32 до появления инициативы .NET. На базовой странице Microsoft Windows DNA приводится перечень программ и технологий, ставших частью платформы Microsoft .NET и .NET Enterprise Servers. В список вошли такие серверы, как SQL Server и Exchange Server, такие инструменты программирования, как Visual C++ (VC++), и службы, в частности, COM+ для Windows 2000 и Microsoft Transaction Services (MTS) для NT 4.0.

Чтобы создавать приложения с помощью инструментов Windows DNA или .NET, необходимо построить COM-компоненты на таких языках, как Visual Basic (VB) или VC++, и соединить их сценариями или программным кодом. Управлять компонентами COM в среде NT 4.0 можно с использованием MTS (COM+ в Windows 2000). MTS известен уже довольно давно, но многие организации только начинают использовать его в своих приложениях. В данной статье рассматриваются основные приемы установки и управления компонентами COM с использованием MTS в NT 4.0.

ХРАНЕНИЕ КОМПОНЕНТОВ

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

Более удачный подход - разместить DLL на промежуточном сервере-распределителе, и в удобное время скопировать их на каждый рабочий сервер. Данный метод обеспечивает избыточность приложений и позволяет обновлять компоненты с промежуточного сервера на одном или нескольких серверах за один раз, а не на всех одновременно.

Далее я подробнее остановлюсь на копировании DLL и пакетов MTS с промежуточного сервера на рабочие. Но сначала необходимо поместить компоненты на сервер-распределитель. Чтобы организовать хранение компонентов на таком сервере, можно создать каталог компонентов с подкаталогом для каждого пакета MTS или каждого проекта. Структура каталогов показана на Рисунке 1. В целях экономии времени рекомендуется составить командный файл для создания каталогов на сервере-распределителе. Такой командный файл показан в Листинге 1.

ДОБАВЛЕНИЕ КОМПОНЕНТОВ К MTS

Завершив организацию структуры каталогов и скопировав библиотеки в соответствующие подкаталоги, можно установить компоненты в MTS на промежуточном сервере. Компоненты, установленные в MTS, могут работать внутри пакета MTS. Пакет MTS, или контейнер компонентов, идентифицирован в NT 4.0 и по умолчанию создает процесс для себя и своих компонентов.

Чтобы создать новый пакет MTS, следует открыть MTS Explorer из папки NT 4.0 Option Pack в меню Programs. Окно MTS Explorer показано на Рисунке 2. Раскрыв папку Microsoft Transaction Server, папку Computers и папку My Computer, нужно выбрать пункт My Computer. Щелкнув правой кнопкой мыши на папке Packages Installed, следует выбрать New, а затем Package. После этого необходимо щелкнуть на пиктограмме Create Empty Package. Указав имя (например, Components) пакета, следует щелкнуть на кнопке Next, чтобы вывести на экран окно Set Package Identity, показанное на Рисунке 3.

Пакет с принимаемым по умолчанию идентификатором Interactive User работает от имени учетной записи текущего пользователя. Принадлежность пакета следует изменить, указав конкретную учетную запись с необходимыми правами. На Рисунке 3 показана принадлежность пакета к пользовательской учетной записи WininNTPackageUser.

Можно изменить еще один параметр пакета. По умолчанию свойство Activation (активизация) имеет значение Server. В результате данный пакет работает в собственном серверном процессе под управлением mtx.exe. Это значение можно изменить на Library, после чего пакет будет выполняться в процессе вызывающей прикладной программы. Например, если программа ASP выполняет метод класса в пакете со свойством Activation - Library, то вместо mtx.exe пакет работает в процессе Inetinfo сервера Microsoft IIS. Приложение с параметром Library выполняется быстро, но может вызвать сбой из-за ошибки в пакете. Серверные пакеты также подвержены фатальным сбоям, но это не ведет к сбою Inetinfo. Кроме того, если назначить пакету свойство Library, то для замены компонентов пакета необходимо будет выполнить дополнительные операции. В случае с приложением ASP придется закрыть всю систему IIS. Обычно я тестирую приложения с параметром Server. Затем я провожу эксплуатационные испытания программы, и если это необходимо для повышения быстродействия, изменяю параметр рабочей версии приложения на Library. Чтобы изменить параметр Activation пакета, следует щелкнуть правой кнопкой мыши на его имени, выбрать пункт Properties, щелкнуть на закладке Activation и выбрать значение Library или Server.

В созданный пакет Components можно добавить один или несколько компонентов, перемещая файлы компонента (то есть DLL-файлы) мышью из Windows Explorer в пакет MTS Explorer. Добавив к пакету компонент, можно открыть страницы свойств класса компонента и установить свойства класса, такие как Transaction Type (тип транзакции), которые определяют, когда и как класс участвует в транзакции.

РАСПРЕДЕЛЕНИЕ ПАКЕТОВ ПО ДРУГИМ СЕРВЕРАМ

После того, как компонент помещен в каталог и в пакет MTS на промежуточном сервере, как передать его на рабочие серверы, составляющие ферму серверов приложений? В сети, состоящей из различных групп Web-серверов приложений (например, двух серверов, работающих с одним приложением, двух других серверов - со вторым, и еще трех серверов, выполняющих иной набор прикладных программ), обычно имеется распределяющий сервер для каждой группы производственных серверов. Конфигурация распределительного сервера должна быть такой же, как у связанных с ним производственных серверов - с соответствующими параметрами NT, Microsoft Data Access Components (MDAC - компоненты доступа к данным), IIS, MTS и другими - чтобы перед пересылкой новых версий приложений на производственные серверы их можно было проверить на сервере-распределителе.

Переместить компоненты и пакеты с одного сервера на другой можно несколькими способами. Один из методов - обращаться к каждому серверу по отдельности и копировать компоненты, создавать или изменять пакеты, и загружать компоненты в пакеты вручную. Для доступа и управления удаленными компьютерами можно использовать MTS Explorer. Для этого нужно щелкнуть правой кнопкой мыши на значке My Computer, выбрать пункт New, затем Computer, чтобы добавить в MTS Explorer удаленную машину. После того, как MTS успешно установит соединение с новым компьютером, значок компьютера на экране станет зеленого цвета. Теперь пользователи могут просматривать, а при наличии соответствующих прав, и управлять удаленным сервером MTS.

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

Второй метод - использовать командный файл, приведенный в Листинге 1, для построения структуры каталогов на каждом сервере. Можно составить другой командный файл для копирования компонентов на серверы. Однако с помощью командных файлов удается выполнить лишь часть работы; затем необходимо создать пакеты, загрузить в пакеты компоненты и настроить свойства, уровень безопасности и любые другие параметры пакетов. Кроме того, если при использовании командного файла пакетная операция заканчивается неудачей, обнаружить отказавший процесс и исправить ошибку почти невозможно. Однако MTS объявляет методы и свойства через COM, и программист может составить утилиту, автоматизирующую процесс создания и конфигурирования пакета.

Третий вариант дистанционного управления пакетами и компонентами предполагает использование папки Remote Components сервера MTS. Этой папкой можно воспользоваться на каждой машине MTS для перемещения компонентов с одного компьютера на другой. Для работы с Remote Components необходимо установить библиотеки в общем сетевом каталоге, чтобы удаленные серверы могли их найти. Затем с помощью MTS Explorer можно скопировать компонент из общего сетевого каталога в папку Remote Components на удаленном сервере. MTS копирует компонент через сеть, устанавливает его в подкаталог каталога MS install на удаленном сервере и дает папке такое же имя, как у пакета. Использовать Remote Components можно, но это связано с необходимостью работать с каждой машиной. Кроме того, такое решение не обеспечивает полного контроля над структурой каталогов, в которых размещены компоненты.

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

В ходе операции экспорта MTS Explorer создает файл пакета (с расширением .pak), содержащий информацию о компонентах и ролях, или группах безопасности (если таковые имеются), входящих в состав исходного пакета. MTS Explorer копирует компонентные DLL-файлы и библиотеки типов в тот же каталог, в котором создан файл пакета. В экспортированном пакете указаны такие параметры исходного пакета, как Activation и Transaction Type. Чтобы экспортировать пакет, необходимо выполнить следующие операции:


1. Щелкнуть на имени экспортируемого пакета в левом подокне MTS Explorer и выбрать пункт Export из меню Action. Или щелкнуть правой кнопкой мыши на имени пакета и выбрать из меню пункт Export.
2. Ввести имя нового файла пакета, который нужно создать. Чтобы дополнить пакет существующими ролями, следует выставить флажок Save Windows NT user ids associated with roles.
3. Щелкнуть на кнопке Export, чтобы начать процедуру экспорта.

Чтобы изменить свойство пакета или обновить перекомпилированную DLL, необходимо повторно экспортировать пакет, потому что элементы каталога MTS для данного пакета более недействительны. Программистам следует прочитать раздел "Building an MTS Package for Export" в Books Online (BOL), где рассказано, что делать с компонентами, предназначенными для экспорта. В документации BOL приведены указатели на методы конфигурирования компонентов для экспорта.

Чтобы импортировать пакет на другую машину, можно воспользоваться функцией Import меню Action программы MTS Explorer. Другой способ - запустить Windows Explorer, открыть папку Packages Installed и перенести мышью нужный пакет в папку Packages Installed на целевом сервере.

Mtxrepl - еще один инструмент для переноса приложений MTS с одного сервера на другой в рамках кластера NT 4.0 (с использованием Microsoft Cluster Server - MSCS). Я не пробовал использовать Mtxrepl без кластера, но, вероятно, он будет работоспособен. В документации BOL MTS указывается, что прежде чем использовать этот инструмент, необходимо закрыть пакеты на целевой системе, в противном случае результаты операции могут быть непредсказуемы.

ИНТЕРФЕЙС АВТОМАТИЗАЦИИ MTS

Оснастка MTS Explorer открывает доступ к большинству функций MTS. Программисты могут использовать любой OLE Automation-совместимый язык, такой как Visual Basic (VB) или VBScript, для создания программ автоматизации MTS. Более подробно об автоматизации задач MTS рассказывается в разделе «Automating MTS Administration» в BOL.

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


Кен Спенсер - внештатный редактор Windows 2000 Magazine и SQL Server Magazine. Является вице-президентом компании 32X Tech, консультирует и преподает на специализированных курсах по проектированию и хостингу приложений. Его адрес: http://www.32x.com.