Database Programming & Design

       

Виртуальные системы


Промежуточное ПО категории виртуальных систем позволяет

разработчикам иметь дело со многими различными системами так, как

если бы это была одна система, с использованием общего слоя

промежуточного ПО и набора API. На каждой системе устанавливается

соответствующая версия промежуточного ПО и конфигурируется служба

именования. После этого сервисы разнородной распределенной

системы становятся доступными всем приложениям в сети. Из одного

клиентского приложения с использованием API можно запустить

процесс на мейнфрейме, обновить базу данных и затребовать сервис

на UNIX-системе.

Хорошим примером промежуточного ПО этой категории является

продукт DCE, в котором поддерживается основанный на RPC доступ к

разнообразным системам, для которых поддерживается DCE. Помимо

прочего, DCE обеспечивает собственные службы безопасности и

именования и позволяет взаимодействовать с любым числом серверов

ресурсов с использованием шлюзов и интерфейсов. Однако DCE не



может удовлетворить требования эффективности разработчиков

клиент-серверных систем, для которых важна высокая загрузка

серверов и сети. Более того, применяемый механизм синхронных RPC

требует, чтобы для выполнения операции все участвующие системы

были активны. Обычно выполнение удаленного вызова должно быть

полностью завершено перед тем, как приложение сможет продолжить

свое выполнение. DCE продается компаниями (подразделение IBM) и .

Продукты класса MOM в состоянии обойти некоторые ограничения,

необходимо присутствующие в системах, основанных на синхронных

RPC, за счет предоставления асинхронного механизма обмена

сообщениями. Это означает, что целевой сервер может не быть

активным, но тем не менее API MOM не заблокирует приложение.

Еще более существенно то, что для реализации MOM не требуется

высокая пропускная способность сети, и можно восстанавливаться

после сбоев системы и/или сети за счет журнализации транзакций во

внешней памяти. Примерами MOM-продуктов являются MessageQ

компании , MQSeries компании


, Pipes компании

, MSMQ компании .

В конце 1997 г. на рынке MOM-продуктов ожидается сражение между

и . Обе компании летом готовились к битве в связи с выпуском новых версий

MOM-продуктов. выпустит новую версию MQSeries

под названием Armada, в которой будут поддерживаться

дружественный пользователю интерфейс, улучшенные средства

конфигурирования и управления, повышенная производительность,

возможность использования Java, развитые средства безопасности и

интеграция с DCE. Кроме того, планирует снизить

цены. В новой версии MSMQ будет использоваться технология COM, и

она будет работать на платформах Windows NT и Windows 95 в сетях

TCP/IP и IPX/SPX. Первый выпуск MSMQ будет входить в состав

сервера NT и Transaction Server. Партнер

компания Level8 предоставит шлюзы для связи

MSMQ с MQSeries и производимыми не

операционными системами. Компании и

ожидают получить кросс-платформенные реализации

MSMQ в конце этого года.

При всех своих достоинствах подход MOM страдает отсутствием

стандартов и отсутствием поддержки производителей популярных

средств разработки. При использовании MOM в сочетании с

традиционными средствами разработки для среды "клиент-сервер"

потребуется использовать различные DLL, средства ActiveX или

производить интеграцию с библиотекой классов средства разработки.

Из-за этого разработчикам приходится отказываться от традиционной

парадигмы основанной на репозитарии разработки при использовании

таких инструментальных средств как PowerBuilder компании

PowerSoft (подразделение компании )

или Developer/2000 компании . Не очень

быстро, но появляются средства, подобные Allegris компании

Intersolve, поддерживающие взаимодействия прикладных объектов

внутри системы.

Компания недавно объявила о выпуске MOM-продукта TIB/Rendezvous 3.0. В этом продукте обеспечивается

интеграция ActiveX и Java, удостоверяемая доставка сообщений,

устойчивость к сбоям за счет использования механизма подписного

широковещания. Основанный на технологии ORB TID/Rendezvous



представляет наибольшую значимость для финансовых приложений, в

которых требуется доставка объемной информации сразу многим

клиентам. При использовании технологии подписки и доставки каждое

сообщение передается по сети только один раз при том, что его

получает каждый подписчик.

Мониторы обработки транзакций (Transaction Monitors -

TP-мониторы) представляют собой сложные продукты промежуточного

ПО, обеспечивающие одновременно выбор местоположения для

прикладной обработки и механизм взаимодействий. TP-мониторы дают

возможность разработчикам определить конкретные транзакционные

службы в пределах среды монитора, такие как учет продаж или

удаление заказчика. TP-монитор располагается между клиентом и

сервером баз данных и основывается на использовании трехзвенной

архитектуры "клиент-сервер". Клиент инициирует транзакцию в

мониторе с использованием механизма транзакционного RPC (TRPC), а

TP-монитор при необходимости запускает транзакции баз данных.

Ответ, если он существует, отправляется клиенту. Семейство

популярных мониторов транзакций включает Tuxedo компании , основанный на DCE продукт Encina

компании , Transaction Server компании .

Мощность TP-мониторов заключается в том, что они позволяют

разработчикам оформить части приложения в виде транзакции. У

транзакции имеются четкие точки начала и завершения. Если при

выполнении транзакции возникает сбойная ситуация, монитор может

выполнить откат этой транзакции, не оставляя систему в

нестабильном или несогласованном состоянии. Кроме того, мониторы

транзакций в состоянии мультипликсировать запросы к базам данных.

Поскольку клиент вызывает транзакции и не связан напрямую с базой

данных, монитор транзакций в состоянии пропускать разные запросы

через одно подключение к базе данных. Например, для 100 клиентов

может понадобиться только 10 активных подключений к базе данных.

Тем самым удаляется ограничение, свойственное двухзвенным

организациям "клиент-сервер", когда для каждого клиента требуется



отдельное подключение к базе данных. В дополнение к этому,

TP-мониторы в пределах одной транзакции могут выбирать и

обновлять данные в разнородных базах данных и даже поддерживать

их совместную целостность. Например, одна транзакция может

удалить запись из базы данных, управляемой Oracle в среде Unix, и

обновить запись в базе данных DB2 на мейнфрейме. Тем самым,

TP-мониторы полезны для связывания различных унаследованных

систем и баз данных в общую виртуальную систему.

Основанное на ORB промежуточное ПО включает простые брокеры

объектных заявок, существующие на нескольких машинах и

взаимодействующие на основе общего протокола, такого как IIOP.

Разработчики могут встраивать ORB'ы или программы, дающие доступ

к ORB, в свои приложения и взаимодействовать через общий

интерфейс с ORB'ами (приложениями), существующими в других

системах. К коммерческим ORB, базирующимся на CORBA, относятся

Orbix компании и VisiBroker компании

. Сила этого подхода состоит в

строгой поддержке межплатформенных взаимодействий. Однако строить

такие распределенные приложения сложно, и лишь немногие

инструментальные средства напрямую поддерживают такие разработки.

Кроме того, ORB'ы не обеспечивают средств балансировки загрузки и

восстановления после сбоев.


Содержание раздела