www.dbmsmag.com
Next-Generation Middleware
David S. Linthicum, senior manager with Ernst & Young's Center for Technology Enablement in Vienna, Virginia
Сергей Кузнецов, Центр Информационных Технологий
Программное обеспечение промежуточного уровня (middleware; далее для краткости мы будем использовать термин "промежуточное ПО") во многих отношениях представляет собой "клей", скрепляющий серверные и клиентские части приложений. Но одновременно это и эффективное инструментальное средство, позволяющее разработчикам приложений не беспокоиться о технических деталях. Промежуточное ПО - это слой, лежащий между приложением и используемым сетевым ПО, операционной системой и серверами ресурсов (например, серверами баз данных). Промежуточное ПО сглаживает различия аппаратно-программных платформ и при правильном использовании позволяет сэкономить время и деньги при разработки систем с архитектурами "клиент-сервер" и Internet/intranet.
Однако промежуточное ПО меняется. В областях, где раньше применялись механизмы RPC (Remote Procedure Calls - удаленные вызовы процедур) и средства управления базами данных, промежуточное ПО нового поколения дает возможность связать вместе распределенные обрабатывающие объекты и привязать приложения к серверам ресурсов. Если раньше приложения, взаимодействующие внутри корпоративной системы, основывались на использовании IPC (InterProcess Communications - межпроцессные взаимодействия), то новое промежуточное ПО позволяет связать аналогичные объекты, расположенные в разных системах. При использовании распространенных многозвенных архитектур "клиент-сервер" промежуточное ПО позволяет перенести логику приложения в централизованный сервер. Наконец, Web-технология принесла в промежуточное ПО новую парадигму и новые продукты. Для нового поколения основанных на Web Internet/intranet-приложений требуются средства связывания серверов приложений и серверов баз данных.
Для правильной ориентации в растущем и усложняющемся рынке промежуточного ПО требуется, во-первых, понимание действующих стандартов. Во-вторых, нужно разобраться с категориями существующего промежуточного ПО и понять назначение продуктов каждой категории. Наконец, полезно познакомиться с существующими продуктами и правильно отнести их к соответствующей категории.
Если говорить по-простому, промежуточное ПО обеспечивает простой для использования API (Application Programming Interface - интерфейс прикладного программирования) между приложением и требуемыми для него ресурсами. Например, если производится Java-апплет, для работы которого требуются внешние данные, можно использовать классы пакета JDBC (Java Database Connectivity) для доступа к информации из любого числа баз данных. Классы JDBC скрывают от разработчика сложности целевой базы данных и позволяют использовать любую базу данных без потребности понимания ее специфических особенностей. Аналогичные возможности обеспечивает ODBC (Open Database Connectivity) для приложений "клиент-сервер", работающих в среде Windows, и средства, подобные Borland Database Engine (BDE).
Возможности промежуточного ПО не ограничиваются обеспечением доступа к базам данных. Продукты этого рода также дают возможность прозрачного доступа на уровне API к другим системам и их сервисам без потребности знать, что из себя представляют эти системы. Слой промежуточного ПО может найти систему, используя какой-либо вид сервиса именования, вызвать удаленный процесс и возвратить ответ вызывающему процессу. К соответствующей категории промежуточного ПО относятся Distributed Computing Environment (DCE) компании Open Software Foundation, продукты, основанные на распределенной объектной технологии CORBA (Common Object Request Broker Architecture - общая архитектура брокера объектных заявок), и большинство продуктов промежуточного ПО, основанных на передаче сообщений (Message-Oriented Middleware - MOM).
Одной из тенденций в мире современного промежуточного ПО является движение к стандартам, включая не только те, которые разрабатываются комитетами по стандартизации (например, CORBA), но и стандарты, предлагаемые мощными компаниями-производителями. В прошлом продукты промежуточного ПО основывались на частных предложениях, которые не предполагали возможности интероперабельности. Сегодня компании, производящие промежуточное ПО, учатся использовать стандарты, такие как CORBA или DCOM (Distributed Component Object Model) в качестве базовой модели продуктов.
DCOM служит стандартной базой в однородной среде Windows. Опора на DCOM позволяет приложениям, написанным на Visual Basic, Delphi и PowerBuilder, связываться по сети с аналогичными приложениями и использовать их сервисы с использованием механизма RPC. Таким образом, DCOM может использоваться либо как примитивный уровень промежуточного ПО, либо как инфраструктура для других продуктов. Продукты промежуточного ПО, использующие DCOM, включают монитор обработки транзакций Microsoft Transaction Server и Microsoft Message Queue Server (MSMQ). В MS Transaction Server для определения транзакций используется ActiveX, а взаимодействия с приложениями и серверами ресурсов основаны на DCOM. Основанным на DCOM MOM-продутом является Falcon. Компания Borland производит продукт Multitier Distributed Application Services Suite, многозвенный продукт промежуточного ПО, позволяющий строить распределенные приложения с использованием основанных на DCOM брокеров объектных заявок.
Но DCOM - это не единственный и не первый механизм, поддерживающий ORB. CORBA также обеспечивает инфраструктуру для продуктов промежуточного ПО на основе естественной для CORBA возможности межброкерных взаимодействий в однородных или разнородных распределенных системах с применением общего интерфейса и протокола. CORBA позволяет связать системы и обеспечить единую виртуальную среду для разработчиков приложений. На модели CORBA основаны продукты VisiBroker компании Visigenic Software Inc. и Orbix компании Iona Technologies Inc.. Оба продукта обеспечивают связывание с Java, что позволяет отнести их и к категории промежуточного ПО с Web-возможностями. Межброкерные взаимодействия основываются на протоколе IIOP (Internet InterORB Protocol), который рассматривается производителями программного обеспечения для работы в Internet (в частности, Netscape Communications Corp.) в качестве кандидата для замены используемого в настоящее время для взаимодействия клиентских и пользовательских частей Web протокола HTTP.
Предлагается деление продуктов промежуточного ПО на пять категорий: продукты, ориентированные на базы данных; виртуальные системы; промежуточное звено (middle-tier); шлюзы; продукты, ориентированные на Web.
К этой категории относятся продукты, позволяющие приложениям производить доступ к локальным или удаленным базам данных. Идея заключается в том, чтобы создать API для доступа к базам данных с использованием слоя промежуточного ПО, скрывающего от клиента особенности операционной системы и сети. Во многих случаях от разработчика скрыт даже и API, а доступны только функции средства разработки. Например, в мире систем "клиент-сервер" ориентированное на базы данных промежуточное ПО является встроенным. При использовании PowerBuilder можно применять собственные связи продукта, существующие для большинства популярных СУБД, а можно работать с ODBC. Почти во все средства разработки компании Borland встроен BDE со своими собственными средствами доступа к базам данных, но также поддерживается и ODBC.
Наиболее существенным новым стандартом ориентированного на базы данных промежуточного ПО является JDBC. В JDBC определен интерфейс уровня вызовов (Call-Level Interface - CLI) для использования в среде Java. JDBC не входит в последний вариант JDK (Java Development Kit), поставляемый подразделением JavaSoft компании Sun Microsystems Inc.. На самом деле, JDBC - это набор классов Java для доступа к конкретным базам данных, архитектурно очень близкий к ODBC.
OLE-DB обеспечивает единую точку доступа к нескольким базам данных. Задача разработки OLE-DB состояла в обеспечении автоматизированного средствами OLE доступа к любому числу баз данных за счет добавления слоя COM между приложением и базой данных.
Имеются и независимые от средств разработки ориентированные на базы данных продукты промежуточного ПО. Например, продукт DB Tools.h++ компании Rogue Wave Software позволяет связать с базами данных большинство приложений, написанных на языке Си++. DB Tools.h++ дает возможность представить реляционные таблицы и атрибуты как собственные объекты Си++. Для тех, кому ближе язык Java, Rogue Wave предлагает Java-версию продукта под названием JDBTools, обеспечивающую доступ к базам данных непосредственно из Java-апплетов и приложений. Аналогичный продукт Persistence компании Persistence Software Inc. позволяет создавать оболочку реляционной базы данных, создающую ее объектное представление, которое может использоваться в объектно-ориентированной среде разработки.
Если требуется доступ к унаследованным данным или к данным, хранящимся на нескольких машинах, следует обратить внимание на такие продукты переднего края как EDA/SQL компании Information Builders Inc. (IBI). Подход, положенный в основу EDA/SQL, состоит в том, чтобы поддерживать максимально возможное число операционных систем, сетей и баз данных. Например, можно получить доступ к информации из базы данных, управляемой Rdb на платформе DEC, и к базе данных, управляемой DB2 на мейнфрейме, используя один драйвер ODBC на стороне клиента. Подобного рода продукты полезны для организаций, желающих перейти к использованию архитектуры "клиент-сервер" без отказа от использования критичных для бизнеса унаследованных систем.
Промежуточное ПО категории виртуальных систем позволяет разработчикам иметь дело со многими различными системами так, как если бы это была одна система, с использованием общего слоя промежуточного ПО и набора API. На каждой системе устанавливается соответствующая версия промежуточного ПО и конфигурируется служба именования. После этого сервисы разнородной распределенной системы становятся доступными всем приложениям в сети. Из одного клиентского приложения с использованием API можно запустить процесс на мейнфрейме, обновить базу данных и затребовать сервис на UNIX-системе.
Хорошим примером промежуточного ПО этой категории является продукт DCE, в котором поддерживается основанный на RPC доступ к разнообразным системам, для которых поддерживается DCE. Помимо прочего, DCE обеспечивает собственные службы безопасности и именования и позволяет взаимодействовать с любым числом серверов ресурсов с использованием шлюзов и интерфейсов. Однако DCE не может удовлетворить требования эффективности разработчиков клиент-серверных систем, для которых важна высокая загрузка серверов и сети. Более того, применяемый механизм синхронных RPC требует, чтобы для выполнения операции все участвующие системы были активны. Обычно выполнение удаленного вызова должно быть полностью завершено перед тем, как приложение сможет продолжить свое выполнение. DCE продается компаниями Transarc Corp. (подразделение IBM) и IBM Corp..
Продукты класса MOM в состоянии обойти некоторые ограничения, необходимо присутствующие в системах, основанных на синхронных RPC, за счет предоставления асинхронного механизма обмена сообщениями. Это означает, что целевой сервер может не быть активным, но тем не менее API MOM не заблокирует приложение. Еще более существенно то, что для реализации MOM не требуется высокая пропускная способность сети, и можно восстанавливаться после сбоев системы и/или сети за счет журнализации транзакций во внешней памяти. Примерами MOM-продуктов являются MessageQ компании Digital Equipment Corp., MQSeries компании IBM, Pipes компании PeerLogic Inc. , MSMQ компании Microsoft.
В конце 1997 г. на рынке MOM-продуктов ожидается сражение между IBM и Microsoft. Обе компании летом готовились к битве в связи с выпуском новых версий MOM-продуктов. IBM выпустит новую версию MQSeries под названием Armada, в которой будут поддерживаться дружественный пользователю интерфейс, улучшенные средства конфигурирования и управления, повышенная производительность, возможность использования Java, развитые средства безопасности и интеграция с DCE. Кроме того, IBM планирует снизить цены. В новой версии MSMQ будет использоваться технология COM, и она будет работать на платформах Windows NT и Windows 95 в сетях TCP/IP и IPX/SPX. Первый выпуск MSMQ будет входить в состав сервера NT и Transaction Server. Партнер Microsoft компания Level8 предоставит шлюзы для связи MSMQ с MQSeries и производимыми не Microsoft операционными системами. Компании Software AG и DEC ожидают получить кросс-платформенные реализации MSMQ в конце этого года.
При всех своих достоинствах подход MOM страдает отсутствием стандартов и отсутствием поддержки производителей популярных средств разработки. При использовании MOM в сочетании с традиционными средствами разработки для среды "клиент-сервер" потребуется использовать различные DLL, средства ActiveX или производить интеграцию с библиотекой классов средства разработки. Из-за этого разработчикам приходится отказываться от традиционной парадигмы основанной на репозитарии разработки при использовании таких инструментальных средств как PowerBuilder компании PowerSoft (подразделение компании Sybase Inc.) или Developer/2000 компании Oracle. Не очень быстро, но появляются средства, подобные Allegris компании Intersolve, поддерживающие взаимодействия прикладных объектов внутри системы.
Компания TIBCO Inc. недавно объявила о выпуске MOM-продукта TIB/Rendezvous 3.0. В этом продукте обеспечивается интеграция ActiveX и Java, удостоверяемая доставка сообщений, устойчивость к сбоям за счет использования механизма подписного широковещания. Основанный на технологии ORB TID/Rendezvous представляет наибольшую значимость для финансовых приложений, в которых требуется доставка объемной информации сразу многим клиентам. При использовании технологии подписки и доставки каждое сообщение передается по сети только один раз при том, что его получает каждый подписчик.
Мониторы обработки транзакций (Transaction Monitors - TP-мониторы) представляют собой сложные продукты промежуточного ПО, обеспечивающие одновременно выбор местоположения для прикладной обработки и механизм взаимодействий. TP-мониторы дают возможность разработчикам определить конкретные транзакционные службы в пределах среды монитора, такие как учет продаж или удаление заказчика. TP-монитор располагается между клиентом и сервером баз данных и основывается на использовании трехзвенной архитектуры "клиент-сервер". Клиент инициирует транзакцию в мониторе с использованием механизма транзакционного RPC (TRPC), а TP-монитор при необходимости запускает транзакции баз данных. Ответ, если он существует, отправляется клиенту. Семейство популярных мониторов транзакций включает Tuxedo компании BEA Systems Inc., основанный на DCE продукт Encina компании Transarc, Transaction Server компании Microsoft.
Мощность TP-мониторов заключается в том, что они позволяют разработчикам оформить части приложения в виде транзакции. У транзакции имеются четкие точки начала и завершения. Если при выполнении транзакции возникает сбойная ситуация, монитор может выполнить откат этой транзакции, не оставляя систему в нестабильном или несогласованном состоянии. Кроме того, мониторы транзакций в состоянии мультипликсировать запросы к базам данных. Поскольку клиент вызывает транзакции и не связан напрямую с базой данных, монитор транзакций в состоянии пропускать разные запросы через одно подключение к базе данных. Например, для 100 клиентов может понадобиться только 10 активных подключений к базе данных. Тем самым удаляется ограничение, свойственное двухзвенным организациям "клиент-сервер", когда для каждого клиента требуется отдельное подключение к базе данных. В дополнение к этому, TP-мониторы в пределах одной транзакции могут выбирать и обновлять данные в разнородных базах данных и даже поддерживать их совместную целостность. Например, одна транзакция может удалить запись из базы данных, управляемой Oracle в среде Unix, и обновить запись в базе данных DB2 на мейнфрейме. Тем самым, TP-мониторы полезны для связывания различных унаследованных систем и баз данных в общую виртуальную систему.
Основанное на ORB промежуточное ПО включает простые брокеры объектных заявок, существующие на нескольких машинах и взаимодействующие на основе общего протокола, такого как IIOP. Разработчики могут встраивать ORB'ы или программы, дающие доступ к ORB, в свои приложения и взаимодействовать через общий интерфейс с ORB'ами (приложениями), существующими в других системах. К коммерческим ORB, базирующимся на CORBA, относятся Orbix компании Iona и VisiBroker компании Visigenic. Сила этого подхода состоит в строгой поддержке межплатформенных взаимодействий. Однако строить такие распределенные приложения сложно, и лишь немногие инструментальные средства напрямую поддерживают такие разработки. Кроме того, ORB'ы не обеспечивают средств балансировки загрузки и восстановления после сбоев.
В дополнение к использованию промежуточного ПО для простых
взаимодействий точка-точка или клиент-сервер существует тенденция
к созданию промежуточного ПО, позволяющего выбрать место для
проведения прикладной обработки. Выше уже обсуждались
соответствующие возможности TP-мониторов, но имеются и другие
варианты. Например, наряду с обеспечением коммуникационных
возможностей ORB позволяет выбрать место для прикладной
обработки. Аналогично модели TP-мониторов, но в несколько более
распределенной и неоднородной среде ORB'ы могут существовать на
любом числе платформ и могут быть запрограммированы для
выполнения некоторых прикладных функций. Приложения со встроенным
ORB могут вызывать методы локального или удаленного ORB через
протокол IIOP. Идея состоит в создании единого приложения с
объектами, существующими в нескольких узлах сети. Но ORB'ы и
TP-мониторы не заполняют весь рынок промежуточного ПО среднего
звена. Имеется много других фирменных решений. Например, Midas
компании Borland будет работать с большинством инструментальных
средств Borland (в настоящее время
поддерживается только Delphi 3.0) и позволит разработчикам
размещать прикладные объекты с использованием собственного
механизма ORB продукта Midas. Инфраструктура Midas основана на
DCOM. Более старое промежуточное ПО среднего звена можно вообще не
считать промежуточным ПО. Компании Fort Software Inc. и Dynasty
Technologies Inc. имеют собственные решения ORB, поддерживающие
их средства разделения приложений. Разработчики строят
приложение на одной машине, а затем объекты автоматически
мигрируют на другие серверы. Для общения объектов используется
механизм передачи сообщений. В продукте Dynasty служба транзакций
реализована с использованием Tuxedo. Оба продукта поддерживают
связи с открытыми продуктами промежуточного ПО, основанными на
CORBA и MOM. В продукте Cactus компании Что же будет дальше в мире промежуточного ПО? Коротко говоря,
Web, распределенные объекты, Web, Java и снова Web. Появление
Web-технологии применительно и к Internet, и к intranet дало
новую жизнь бизнесу промежуточного ПО. В то время, как компании
начинают связывать свои базы данных и другие ресурсы с Web,
производители промежуточного ПО получают удачную возможность
создать продукты, облегчающие этот процесс. Ирония ситуации
состоит в том, что использование браузера в качестве общей
платформы приложений "клиент-сервер" и HTTP в качестве общего
промежуточного ПО снижает интерес к промежуточному ПО на стороне
клиента. Анализируя возможности Web-технологии, нужно понимать,
что наибольшая выгода от промежуточного ПО может быть получена на
стороне сервера.
Популярные продукты промежуточного ПО, основанные на Web, можно
разделить на две категории - серверные и клиентские. Серверные
продукты обеспечивают связь между Web-сервером и сервером баз
данных с передачей данных клиенту на основе использования HTTP и
HTML. Часто встречается промежуточное ПО, поддерживающее и
разработки приложений, обеспечивая, например, возможность
отображения атрибутов базы данных на Web-страницы. Категория
серверных Web-продуктов промежуточного ПО включает, в частности,
WebDBC компании StormCloud Development Corp. и Internet Database Connector (IDC), входящий теперь в состав
Microsoft Internet Information Server. Обычно такие продукты
легко устанавливаются и просто используются, обеспечивая
Web-мастеров и разработчиков приложений визуальной средой
разработки публикации данных из баз данных. На переднем крае
можно найти такие продукты как ActiveWeb компании Active Software Inc., программная коммуникационная система,
дающая разработчикам доступ к приложениям, базам данных и
браузерам, поддерживающим Java, для обмена информацией через Web.
Конечно, и другие серверные продукты промежуточного ПО
обеспечивают разработчикам простой доступ к серверам приложений и
даже к унаследованным системам.
Криком моды являются клиентские Web-продукты промежуточного ПО.
Эти продукты позволяют разработчикам связывать с удаленными
базами данных выполняемые на стороне клиента Java-апплеты и
программные компоненты ActiveX. Среди первых на рынке появился
продукт JETConnect компании XDB Systems Inc. JETConnect дает
возможность разработчикам подключаться к удаленным серверам баз
данных на основе использования входящей в состав продукта
библиотеки классов. С появлением JDBC разработчики, применяющие
Java, получили стандартный механизм, дающий те же возможности,
что и JETConnect. Сегодня JDBC-драйверы имеются для большинства
популярных баз данных. Возможности JDBC встраиваются в средства
разработки; примером такого продукта является JBuilder компании
Borland. Во многих отношениях JDBC похож на
ODBC, и те компании, которые создавали драйверы ODBC, найдут свою
нишу на новом рынке драйверов JDBC. В некоторых отношениях мир
Java будет выглядеть и функционировать очень похоже на то, что
сегодня представляет собой мир традиционного двухзвенного
клиент-серверного промежуточного ПО.
Производители промежуточного ПО вносят свой вклад и в развитие
технологии Web-разработок. Например, компания Open Horison Inc. только что объявила о выпуске продукта
Ambrosia, представляющего собой управляемую событиями систему для
разработки бизнес-приложений в Internet. В системе используется
собственная реализация Java с гарантированной доставкой
сообщений, исчерпывающей безопасностью и транзакционными
возможностями.
Появляющиеся технологии