Наше знакомство с так называемым промежуточным обеспечением мы, пожалуй, начнем с того, что это программное, а не аппаратное обеспечение. Что еще можно о нем сказать? Некоторые авторы описывают промежуточное обеспечение как «дефис в архитектуре клиент-сервер». Умно, но не очень понятно. Другие же характеризуют его как «программные средства, располагающиеся посередине, связывая вместе разнородные (и обычно уже существующие) программы».

Если исходить из этих определений, то неужели коммуникационное программное обеспечение, сетевые операционные системы, браузеры Web, Internetwork Operating System (IOS) компании Cisco Systems и т. д. — все это промежуточное программное обеспечение? С точки зрения логики так оно и есть, но это мало поможет нам в попытках расшифровать рекламные проспекты производителей. Поэтому вместо того, чтобы пытаться дать точное определение промежуточному обеспечению, мы рассмотрим, когда возникает потребность в такого рода ПО, и познакомимся с имеющимися решениями.

До середины 80-х распределенных вычислений как таковых не существовало. Если несколько пользователей и подключались одновременно, то к центральному мэйнфрейму или мини-компьютеру. Пользовательские терминалы представляли собой простые «стеклянные телетайпы», не выполняющие никакой локальной обработки, поэтому потребность в промежуточном обеспечении в том виде, в каком оно существует сейчас, отсутствовала. Такие среды на базе хоста получили название однозвенных вычислений.

С распространением микрокомпьютеров и локальных сетей файлы данных стало возможно совместно использовать с помощью многопользовательских версий баз данных для автономных ПК (в середине 80-х на рынке доминировала dBase III). При условии блокировки файлов и записей эти продукты рассматривали файловые серверы локальной сети просто как разделяемый жесткий диск. В результате по сети часто приходилось передавать огромное количество записей или даже всю базу данных целиком.

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

Клиент и сервер взаимодействовали друг с другом с помощью языка структурированных запросов (Structured Query Language, SQL), который можно рассматривать в качестве первого промежуточного обеспечения. Поставщики баз данных могли использовать собственные каналы для связи клиентов и серверов, однако SQL доказал свою способность точно выбирать записи данных, значительно сокращая таким образом сетевой трафик. Но еще более важно то, что этот открытый стандарт на промежуточное обеспечение позволял без труда менять пользовательский интерфейс с базой данных.

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

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

Звено за звеном. Переход от двухзвенных вычислений (вверху) к трехзвенной архитектуре (внизу) позволяет повысить общую производительность, упростить модификацию логики приложения и обеспечить поддержку разнородных клиентов. Благодаря промежуточному обеспечению на базе компонентов трехзвенная архитектура с легкостью превращается в n-звенную.

Решение вскоре нашлось в виде трехзвенной архитектуры (см. Рисунок). В такой конфигурации логика приложения переносится с клиента или сервера базы данных на еще один сервер. Данный подход имеет множество преимуществ: он повышает производительность базы данных; облегчает изменение и усовершенствование логики, так как не затрагивает клиентов; упрощает поддержку разнообразных клиентских устройств (ПК, Macintosh, PDA), потому что программное обеспечение для них должно содержать только пользовательский интерфейс.

В современных средах номинальная трехзвенная архитектура запросто превращается в n-звенную архитектуру, в которой для выполнения запроса один или несколько серверов приложений обращаются к нескольким серверам баз данных. Каналы между серверами приложений и баз данных могут по-прежнему реализоваться с помощью SQL. Однако каналы между серверами приложений и их клиентами чаще принадлежат к одному из более новых типов промежуточного обеспечения.

Вызовы удаленных процедур (Remote Procedure Call, RPC) представляют собой примитивную форму промежуточного обеспечения и ведут свое начало из мира UNIX. Они делают более-менее то, что следует из их названия: посредством вызова функции из одной программы ее автор может активизировать процесс на удаленной машине.

При всей своей концептуальной простоте и доступности в средах Windows и даже DOS, вызовы удаленных процедур обладают множеством недостатков. Из-за того, что они функционируют на низком уровне абстракции, программистам чрезвычайно неудобно работать с RPC. Далее типичный вызов удаленной процедуры может потребовать выполнения 24 различных шагов, нескольких обращений по сети и намного большей вычислительной мощности, чем вызов локальной процедуры. К тому же RPC не масштабируются на глобальные сети.

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

В отличие от другого промежуточного обеспечения, RPC не продаются в виде отдельных пакетов.

Базы данных — это не единственное место в системе, где может использоваться промежуточное обеспечение, но без сомнения наиболее важное. Транзакция обычно состоит из серии команд, причем они успешно или неудачно завершаются все вместе.

Качества, которыми транзакция должна обладать, суммируются акронимом ACID (Atomicity, Consistency, Isolation, Durability — т. е. «атомарность», «непротиворечивость», «изолированность» и «живучесть»). «Атомарность» означает, что транзакция должна быть выполнена полностью или не выполняться вообще, т. е. никакие частичные результаты не допускаются. «Непротиворечивость» означает, что транзакция переводит базу данных из одного непротиворечивого состояния в другое. «Изолированность» означает, что всякая транзакция изолирована от промежуточных результатов, которые могут быть порождены другими, выполняющимися с ней одновременно. «Живучесть» означает, что, когда транзакция завершена, ее результаты не будут потеряны из-за сбоя системы или памяти.

Мониторы выполнения транзакций (Transaction Processing, TP) представляют собой программные процессы, призванные обеспечить соблюдение этих качеств. Одним из первых мониторов TP на базе мэйнфрейма была Customer Information Control System (CICS) компании IBM. Используемая до сих пор, она функционирует теперь на множестве платформ. Среди других мониторов — Transaction Server (MTS) компании Microsoft, Top End компании NCR и Tuxedo компании BEA.

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

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

Как следует из его названия, ориентированное на сообщения промежуточное ПО (Message-Oriented Middleware, MOM) обеспечивает связь между приложениями с помощью обмена сообщениями. MOM вовсе не обязательно должно стандартизировать форматы сообщений или допускать использование разнородных клиентов, но так или иначе оно организует общекорпоративный обмен данными. Оно следит за тем, чтобы сообщения доставлялись нужному адресату, причем только один раз. Двумя основными функциональными моделями MOM являются «очереди сообщений» и «публикация и подписка».

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

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

Объектно-ориентированное программирование в моде уже больше десятка лет — и почти столько же времени оно вызывает лишь зевоту у непрограммистов. Хорошо, конечно, знать, что объекты — это «многократно используемые крупные двоичные объекты программного интеллекта», но какой от этого прок большинству из нас? После того как программа откомпилирована, мало кого интересует, как она написана, если она работает.

Однако в случае n-звенных вычислений даже те, кто никогда не намеривался быть программистом, оказываются вынуждены принимать участие в разработке программного обеспечения. Здесь и приходят на помощь распределенные объекты. Потенциально эти программные компоненты могут находиться в любом месте сети, обмениваться друг с другом сообщениями прозрачным образом и взаимодействовать между собой, даже если они приобретены у разных поставщиков.

В отношении программных компонентов компьютерный мир делится на два лагеря: Microsoft и «все остальные» (т. е. свыше 800 членов Object Management Group, OMG). Конкурирующими стандартами на компоненты для настольных систем являются ActiveX и JavaBeans; для серверов — Component Object Model (COM), Enterprise JavaBeans (EJB) и вспомогательные Common Object Request Broker Architecture (CORBA) Beans.

Microsoft шла по пути эволюции. Давние пользователи Windows могут вспомнить появление динамического обмена данными (DDE), с помощью которого различные программы могли обмениваться данными друг с другом, пусть даже медленно и неуклюже.

Последующие связывание и внедрение объектов (Object Linking and Embedding, OLE) позволили создавать составные документы, например документы Word, содержащие полностью редактируемые электронные таблицы Excel. Затем OLE 2 получило в свое распоряжение технологию инкапсуляции объектов под названием COM.

Переделав эту технологию для Internet, в 1996 году Microsoft представила ActiveX — по сути, переименованную и упрощенную версию OLE. (Фактически Microsoft применяет ActiveX в качестве объединяющего названия для OLE, сценариев и загружаемых элементов управления, расширяющих функциональность Windows.) Кроме того, Microsoft выпустила Distrubuted COM, сокращенно DCOM. Последняя версия, доступная только для Windows 2000, известна как COM+.

Как бы мы к ней ни относились, технология Microsoft призвана упростить распределенные вычисления — естественно, в среде Windows. Бизнес-логика может быть воплощена в компонентах COM, они автоматически загружаются в клиентские приложения и «знают», какие сервисы им потребуются для выполнения своей работы. COM+ также содержит монитор выполнения транзакций MTS и компоненты для публикации и подписки и для организации очередей сообщений.

Этот раздел для любителей акронимов. CORBA, конкурент COM+, была разработана OMG, крупнейшим в мире консорциумом программистских фирм.

CORBA — это архитектура и спецификация для создания программных компонентов (объектов), способных обнаруживать друг друга и затем взаимодействовать по «объектной шине».

Важнейшей концепцией CORBA является брокер объектных запросов (Object Request Broker, ORB), обрабатывающий запросы программ к компонентам и компонентов друг к другу. Для получения сервисов нет необходимости знать, где находится сервер и как выглядит интерфейс с серверной программой.

CORBA позволяет компонентам стандартным образом указать, какие данные они ожидают получить, и передать заказанное в ответ. Язык определения интерфейса (Interface Definition Language, IDL) устанавливает соответствия для различных языков программирования.

Другой важной частью CORBA является общий межброкерный протокол (General Inter-ORB Protocol, GIOP). Он стандартизирует взаимодействие между различными ORB. Internet Inter-ORB Protocol (IIOP) определяет, как сообщения GIOP передаются по TCP/IP.

CORBA ORB предлагаются многими поставщиками и выполняются на нескольких десятках платформ. С помощью «конвертов» они могут инкапсулировать предшествующие разновидности промежуточного обеспечения, такие, как мониторы TP, благодаря чему CORBA ORB могут быть без труда интегрированы в общее решение.

Компоненты JavaBeans могут быть реализованы на любой платформе Java. Они могут использоваться для создания апплетов Java или быть объединены в более крупное приложение, так называемый контейнер. JavaBeans взаимодействуют друг с другом, благодаря чему Java получает OLE-подобные функции составных документов. Они также обладают инерционностью, т. е. способны сохранять свое состояние, например введенные пользователем данные, на диске.

Enterprise JavaBeans (EJB) — специализированные, не визуальные компоненты, предназначенные для выполнения на сервере. Наконец, CORBA Beans, также известные как компоненты CORBA, должны стать частью спецификации CORBA 3.0. CORBA Beans являются надмножеством EJB и не предполагают обязательного использования Java. Помимо других преимуществ они будут иметь стандартный формат распространения программного обеспечения и инструментарий конфигурирования на базе расширяемого языка разметки (Extensible Markup Language, XML). CORBA Beans должны сделать «бизнес-объекты» более легко доступными и широко применимыми.

В начале статьи говорилось о том, что браузеры Web можно рассматривать в качестве промежуточного обеспечения. С появлением XML это замечание не выглядит далеким от истины.

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

Джонатан Эйнджел — старший редактор Network Magazine. С ним можно связаться по адресу: jangel@mfi.com.

Эта статья во многом обязана своим появлением прекрасному описанию промежуточного программного обеспечения в отчете PricewaterhouseCoopers Technology Forecast за 1999 год. О том, как получить эту публикацию, вы можете узнать на http://www.pwcglobal.com/tech-centre/.

Введение в CORBA и информацию о версии 3.0 можно найти на http://www.omg.org.

Общие сведения об Extensible Markup Language Remote Procedure Call (XML RPC) можно найти на http://www.xmlrpc.com.