Обучающие курсы:

Обучение профессии "Разработчик C#" + стажировка в Mail.ru
Обучение профессии "Разработчик Python" + трудоустройство
Обучение профессии "Веб-разработчик" + стажировка в Mail.ru


Главная страница
Библиотека (скачать книги)
Скачать софт
Введение в программирование
Стандарты для C++
Уроки по C#
Уроки по Python
HTML
Веб-дизайн
Ассемблер в среде Windows
ActiveX
Javascript
Общее о Линукс
Линукс - подробно
Линукс - новое
Delphi
Паскаль для начинающих
Турбопаскаль
Новости
Партнеры
Наши предложения
Архив новостей





Возможности Microsoft Transaction Server

MS Transaction Server поддерживает структуру многоуровневых приложений и компоненты. Клиенты первого уровня обеспечивают пользовательский интерфейс и некоторое количество логики приложения. Серверы приложений среднего звена берут на себя большую часть логики приложения. Они работают под управлением Transaction Server. Базы данных конечного звена занимаются хранением информации для приложения.

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

 

СОМ и ActiveX

Transaction Server поддерживает Microsoft Common Object Model (COM) и технологию ActiveX. Модель COM обеспечивает "соединяемость" и определяет интерфейсы и протоколы внутри и между компонентами приложения. Разработчики проектируют взаимодействие составных частей приложения на основе ActiveX-модулей. Таким образом, упрощенно можно представлять Transaction Server как законченную двухуровневую серверную среду для ActiveX.

Когда пользователь или программа ссылается на интерфейс компонента ActiveX посылая сообщение или событие, СОМ определяет компонент и перенаправляет ему данное сообщение или событие. Компонент, на который происходит ссылка, может быть локальным или находиться на удаленном компьютере. Локальная соединяемость обеспечивается механизмами межпроцессорного взаимодействия самой операционной системы. Удаленная соединяемость обеспечивается протоколом TCP/IP.

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

Transaction Server задействует механизмы безопасности Windows NT. Windows NT обеспечивает вход в систему через пользовательский ID и пароль, а также управление доступом к ресурсам с помощью администрирования пользователей и групп пользователей. Transaction Server расширяет эти возможности за счет управления доступом к индивидуальным компонентам приложения. Контроль может выполняться как с помощью административных функций Windows NT по отношению к пользователям и группам, так и программным путем внутри компонентов приложения.

Службы каталогов обеспечиваются в Transaction Server и СОМ через реестр Windows (Registry), который содержит информацию о пользователях, группах, приложениях, именах и интерфейсах ActiveX. Он предоставляет все необходимое для поддержки многоуровневых приложений в Microsoft Windows. Создание и поддержка реестра является административной функцией, разработчики избавлены от необходимости следить за этим.

Разработчики своих приложениях просто пишут код на SQL для получения информации.
Transaction Server имеет монитор транзакций, который контролирует доступ транзакций к менеджерам ресурсов. Транзакции могут обращаться к единственному менеджеру ресурсов, или через поддержку протокола Microsoft Distributed Transaction Coordinator (DTC) транзакции могут согласовывать и синхронизировать свой доступ к нескольким менеджерам ресурсов. В начальной версии Transaction Server в роли менеджеров ресурсов могут выступать Microsoft SQL Server и базы данных, поддерживающие интерфейс ODBC. Новые версии будут поддерживать протоколы ХА, SNA LU6.2 и TIP (Transaction Internet Protocol) и, следовательно, будут расширены понятия участвующих в транзакциях менеджеров ресурсов и среды обработки.

 

Программистские усилия по поддержке транзакций сводятся к минимуму. Пишущим код не нужно вставлять в программу операторы Begin transaction, End transaction ИЛИ Abort transaction. Транзакции определяются путем задания свойства компонента приложения.

Если компонент помечен как "transactional", Transaction Server будет управлять транзакциями во время всего периода его выполнения. Все компоненты, на которые она ссылается, автоматически принимают участие в транзакции. Если компоненты помечены как транзакционные, то все их выполнение будет заключено внутри единой транзакции. Shared Property Manager (менеджер разделенных свойств) в составе Transaction Server предоставляет механизм разделения доступа к глобальной информации между серверными процессами. Разработчики могут его использовать для широкого круга вопросов, включая мониторинг и управление исполнением, чередование процессов и т. д. Shared Property Manager выполняет все необходимые действия по разделению информации между приложениями.

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

 

Почти два года тому назад, 26 июня 1998 года было объявлено, что MTS 1.1 становится атрибутом операционной системы Windows NT 4.0. Тогда же были внесены соответствующие изменения в текст лицензионного соглашения для пользователей Windows NT 4.0 и BackOffice 2.5.
Лицензированные пользователи получили возможность "скачать" MTS 1.1 с Web-сайта Microsoft. Версия 1.1, по сути, представляет собой базовую версию 1.0, объединенную с кумулятивным сервисным пакетом 2.0а, который содержал в основном интерфейсные исправления типа "при нажатии клавиши <F1> в MTS

 

Explorer не вызывалась справочная система Help". В MTS добавились функции интеграции с мониторами транзакций на мэйнфреймах IBM (проект Cedar) и улучшенные возможности работы с кластерами MSCS.

 

MTS обеспечивает плотную целостность распределенных транзакций по протоколу двухфазной фиксации. Тем не менее существуют ситуации, когда более выгодно работать асинхронно. К ним относятся приложения, в которых инициатор транзакции должен продолжать работу, не дожидаясь результатов обработки запроса. Приложения, обменивающиеся сообщениями, могут не быть постоянно в режиме on-line. Наконец, требования асинхронной коммуникации могут диктоваться плохими каналами связи, мобильными пользователями и т. д. Во всех этих случаях для обеспечения асинхронного взаимодействия необходимо иметь некий механизм промежуточного хранения и диспетчеризации пересылки (store and forward).

 

К преимуществам подобного подхода следует отнести гарантированную доставку, возможность маршрутизации сообщений и назначения им приоритетов и известную независимость от качества каналов связи. Такой механизм разрабатывался в Microsoft под кодовым названием Falcon и вошел в Windows NT 4.0 Enterprise Edition как сервер очередей сообщений — Microsoft Message Queue Server (MSMQ 1.0). Под сообщением MSMQ понимается запрос произвольной природы (или ответ на запрос), самодостаточный в плане координат отправителя/получателя и содержания.

Сообщения, запрашивающие участие менеджера ресурсов в транзакции, попадают в очереди MSMQ. Очереди сообщений схожи с почтовыми ящиками сервера электронной почты. Менеджер очередей MSMQ также работает подобно серверу электронной почты, решая, кому, когда и как доставить сообщение. Топология MSMQ напоминает структуру Microsoft Exchange Server: единая распределенная база данных на Primary Enterprise Controller (PEC) предоставляет в общее пользование информацию о доступе к сообщениям для всех компьютеров, на которых запущен MSMQ.

 

Под узлами (sites) MSMQ понимаются группы компьютеров, соединенных надежными линиями связи (т. е., как правило, объединенных в локальную сеть). Внутри каждого узла выделяются Primary Site Controller (PSC) и Backup Site Controller (BSC). Таким образом, Windows NT PEC соответствует Primary Domain Controller, a PSC и BSC — Backup Domain Controller. Узлы могут быть связаны друг с другом по линиям ATM, Frame Relay, ISDN и т. д. Каждому ненадежному соединению назначается условная стоимость, например, исходя из времени задержки доставки сообщения. Внутри узлов стоимость полагается равной нулю. MSMQ Enterprise определяет минимальный по стоимости маршрут доставки, а в случае его выхода из строя находит обходные пути.

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

Несмотря на достаточно близкие аналогии с электронной почтой, MSMQ имеет несколько существенных отличий. Он разрабатывался специально для взаимодействий "приложение-приложение", содержание сообщения имеет значение только для его отправителя и получателя, существует возможность настройки гарантии доставки (экспресс, гарантированная и транзакционная), наконец, MSMQ является более простым, компактным, быстрым (и, как следствие, более дешевым), чем традиционный почтовый сервер. Технология очередей сообщений может служить шлюзом к серверам баз данных, работающим на других операционных системах, обеспечивая многоплат- формные распределенные транзакции. Поддержка MSMQ API на платформах IBM MVS и CICS, Sun Solaris, HP-UNIX, AIX UNIX, OS/2, VMS и AS/400 обеспечивается продуктами Level 8 Systems. Возможно также отображение прикладного интерфейса сервера очередей IBM MQ Series в вызовы MSMQ API.

 

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

Аналогично получатель открывает очередь, читает сообщения и т. д. Одну очередь могут читать и модифицировать при наличии соответствующих прав несколько приложений, при этом можно читать и изменять как свои, так и удаленные очереди. MSMQ имеет дополнительные интерфейсы в Microsoft Exchange Server, MAPI и RPC. MTS рассматривает MSMQ как менеджер ресурсов, что дает возможность включать операции над сообщениями серверов очередей в контекст единой распределенной транзакции.
MSMQ API поддерживается всеми тремя конфигурациями сервера очередей: MSMQ Server, MSMQ Workstation и MSMQ Client. Наиболее полной, естественно, является серверная конфигурация, куда, помимо API, входят службы маршрутизации, каталогов, менеджер очередей и среда MSMQ Explorer.

MSMQ Client, напротив, является наименее мощной конфигурацией: в него не входят локальное хранилище и менеджер очередей, он пользуется этими службами у MSMQ Server, который должен быть постоянно для него доступен. Таким образом, MSMQ Client позиционируется как сетевой клиент. Рабочая станция MSMQ (MSMQ Workstation) представляет собой промежуточный вариант: у нее отсутствует поддержка маршрутизации, зато она может обслуживать локальные очереди сообщений и работать при отсутствии связи с сервером. MSMQ Workstation позиционируется как мобильный клиент.

     
 

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru