Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Cвязующее ПО: на сцене статисты

Энтони Фрей

Долгое время играя второстепенные роли на сцене сетевых технологий и оставаясь в тени славы таких компьютерных фаворитов, как базы данных и бизнес-приложения, разнообразные продукты из семейства связующего ПО виртуозно справляются с задачами, поставленными им требовательным режиссером: управлением очередями, мониторингом транзакций, унифицированным доступом к данным. Мог бы состояться хоть один стоящий "спектакль" без многогранного таланта этих простых "тружеников сетевых подмостков"? Не настало ли время и им отвести место главных героев в сценарии распределенных вычислений?

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

Судя по сегодняшним отзывам о технологиях DCOM (Distributed Common Object Model) фирмы Microsoft и Java фирмы Sun Microsystems, последние имеют все задатки стать настоящими звездами. Однако, если этого так и не случится, грядущая консолидация в области разработки связующего ПО среди таких производителей, как BEA Systems и IBM, гарантирует создание сильной "труппы".

Распределение ролей

В настоящее время рынок связующего ПО делится, грубо говоря, на пять основных секторов: ПО доступа к данным; удаленный вызов процедур (Remote Procedure Call — RPC); связующее ПО, ориентированное на обмен сообщениями (Message Oriented Middleware — MOM); мониторы распределенной обработки транзакций (Distributed Transaction Processing — DTP) и распределенная объектная технология, представленная посредниками объектных запросов (Object Request Broker — ORB). Такое условное разделение способствует упорядочению слабоструктурированного рынка связующего ПО, но в то же время затрудняет задачу выработки единой платформы, объединяющей все эти технологии.

Поскольку интегрированной платформы связующего ПО еще просто не существует, мы решили собрать ее из отдельных компонент, исходя из потребностей работающих в нашей сети приложений. Доступ к данным в такой платформе будет занимать от 60 до 70% объема всех решаемых задач. Пожалуй, это первое, в чем нуждаются двухуровневые приложения клиент—сервер. Связующее ПО для доступа к данным в общем случае строится на основе механизма RPC, зачастую отличающегося от уже реализованного в операционной системе.

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

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

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

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

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

Довольно монологов

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

Понимая, что на рынке связующего ПО отдельные компоненты все больше падают в цене, производители начинают формировать свои стратегии по объединению испытанных технологий связующего ПО. Интеграция последнего может идти по пути заимствования решений из конкретных прикладных областей, таких, как базы данных, использующих специфические API обмена сообщениями. Но очень часто такие решения ориентированы больше на поддержку существующих пользовательских баз, чем на обеспечение оптимального решения. Нередко такие приложения построены на компонентах связующего ПО, использующих, в свою очередь, другой тип связующего ПО. И если приложение напрямую зависит от "первичного" связующего ПО, то общая его производительность может быть снижена из-за недостаточной пропускной способности "вторичного" связующего ПО.

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

Аналогично благодаря правильному выбору компонентов связующего ПО для конкретных сетевых задач снижается острота вопроса производительности. Например, трехуровневая информационная система может задействовать связующее ПО RPC (как это сделано в SQL*Net фирмы Oracle) между прикладным уровнем и СУБД, в то же время используя приложение, организующее очередь сообщений между прикладным уровнем и клиентом. Такая схема обеспечивает быструю связь типа запрос—ответ в сетевой среде с асинхронными коммуникациями для клиентов с потенциально высокими задержками отклика.

Даже посредники объектных запросов на основе архитектуры CORBA (Common Object Request Broker Architecture) продемонстрировали достаточно высокую производительность для приложений типа запрос—ответ в локальных сетях. Надо помнить, что посредники ORB на основе CORBA взаимодействуют через частные механизмы RPC, порождая при этом повышенную вычислительную нагрузку.

Другие опции связующего ПО позволяют справляться с конкретными проблемами производительности — например, использование служб справочника (directory services) поможет в обеспечении выравнивания нагрузки и отказоустойчивости. К сожалению, очень немногие пакеты связующего ПО поддерживают все стандартные службы справочника. Эта проблема будет решаться по мере того, как протокол LDAP получит более широкое распространение.

За кулисами

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

Говоря более определенно, мы видим три силы, способные оказать большое влияние на изменение рынка связующего ПО: консолидирование технологий, активная позиция Microsoft и технология Java.

Консолидирование технологий

Как в любой развивающейся отрасли, производители связующего ПО будут "выстраивать" унифицированную линию продуктов путем последовательной покупки технологий, отвечающих их стратегии. Например, фирма BEA Systems для дальнейшего укрепления своей мощи как основного игрока в области связующего ПО недавно приобрела три ключевых продукта у корпорации Digital. Теперь вдобавок к своей основной линии продукта TUXEDO она предлагает ObjectBroker 3.0, BEAmessageQ и ObjectBroker Desktop Connection (мост ActiveX — ObjectBroker).

Хотя BEA собрала внушительный набор продуктов связующего ПО, сама она не разработала ни одного из них (TUXEDO тоже был куплен у Novell). Однако остается открытым вопрос о том, обладает ли фирма BEA достаточным опытом для успешной унификации линий своих продуктов, не говоря уже о том, чтобы их интегрировать.

В свою очередь, фирме IBM, несмотря на то что большинство ее технологий были разработаны самостоятельно, необходимо пройти тот же этап интеграции продуктов, поскольку все они "пришли" из разных областей. Тем не менее ввиду отработанности "накопленных" технологий MQSeries, Distributed System Object Model (DSOM), Encina и CICS, а также благодаря широкому охвату рынка у IBM есть серьезное преимущество перед другими фирмами в отношении формирования будущего связующего ПО.

Microsoft

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

В основе связующего ПО Microsoft лежит архитектура DCOM. По своей сути она является разновидностью технологии ORB, конкурирующей с CORBA. На сетевом же уровне DCOM использует версию механизма RPC для DCE (Distributed Computing Environment); в архитектуре CORBA в этих целях применяется протокол IIOP. Два других продукта Microsoft — монитор транзакций Microsoft Transaction Server и средство организации очередей сообщений Falcon — будут тесно интегрированы с технологией DCOM.

Наряду с выпуском интерфейса API для ADSI (Active Directory Services Interface) фирма Microsoft стремится обеспечить поддержку других стандартизованных служб справочника, без которой невозможна полноценная работа платформ связующего ПО. Однако для интерфейса ADSI характерны те же трудности в управлении, что и для ODBC (Open Database Connectivity). ADSI требует управления со стороны как клиентского драйвера ADSI, так и серверного ПО службы справочника каждого типа.

Таким образом, архитектура связующего ПО Microsoft составит мощную конкуренцию другим производителям. Например, благодаря продукту Transaction Server компоненты DCOM взаимодействуют между собой как единая система и работают в едином же пространстве обработки. Но Microsoft еще предстоит продемонстрировать способность эффективно управлять этими распределенными службами.

Хотя Microsoft и новичок в технологиях связующего ПО, она находится в потенциально выгодном положении, если говорить о ее интегрированной платформе на основе собственных компонентов. Слабая сторона ее подхода — ограниченный набор поддерживаемых программных платформ.

Java

Программный интерфейс JDBC (Java Database Connectivity), интерфейс вызова удаленных методов RMI (Remote Method Invocation), служба сообщений JMS (Java Messaging Service), интерфейс именования и справочника JNDI (Java Naming and Directory Interface), стандарт JavaBeans — все это связующее ПО. Каждый из этих интерфейсов прикладного программирования для Java может быть перенесен на традиционные технологии связующего ПО. То, на что традиционному рынку связующего ПО для архитектуры клиент—сервер понадобились годы, фирма Sun реализует за какие-то несколько месяцев.

Java также находит все большее применение для создания клиентов CORBA при их использовании в Интернет. Применяя ПО VisiBroker фирмы Visigenic Software, включенное в последнюю версию Web-браузера Navigator фирмы Netscape Communications, разработчики Java могут обеспечить взаимодействие с посредниками объектных запросов, работающими на вычислительных платформах с ограниченной поддержкой Java. Более того, теперь, когда будущее объектной технологии OpenDoc не вполне ясно, JavaBeans имеет шанс вытеснить ее на клиентской стороне CORBA.

Но все-таки пока имеет смысл соблюдать осторожность и не бросаться сломя голову в объятия технологии Java. Возьмем, например, JDBC — функциональность и алгоритмы взаимодействия в сети этой службы Java пока не испытаны. Хотя в отношении управления клиентами и обеспечения гибкости транспортной архитектуры интерфейс JDBC продуман лучше, чем ODBC, в нем тоже отсутствуют некоторые средства эффективного доступа к данным, например "прокручиваемые" курсоры (scrollable cursors). Вопрос о готовности Java для создания бизнес-приложений остается открытым, и, учитывая разнообразие стандартов формата компонентов и способов их взаимодействия, нельзя гарантировать, что среда Java будет выбрана в качестве основы для построения платформы связующего ПО.

Занавес!

Разумеется, некоторые продукты претендуют на роль унифицированной и интегрированной платформы связующего ПО. Хорошие тому примеры — программные пакеты NetEssential фирмы Seer Technologies и Entera фирмы OpenEnvironments. Они, как правило, имеют ряд преимуществ перед другими, например унифицированную процедуру авторизации пользователей. Однако, с другой стороны, они, как правило, ограничиваются использованием интерфейса RPC. Исключением является программный пакет NetEssential, но и он поддерживает только средство организации очередей сообщений MQSeries.

Существует еще один вероятный сценарий выработки единой платформы — встраивание компонентов связующего ПО в средства разработок таких фирм, как Forte и Powersoft. Но вряд ли в долговременной перспективе ориентированные на узкие сферы применения платформы выдержат конкуренцию со стороны крупных производителей связующего ПО.

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





  
11 '1997
СОДЕРЖАНИЕ

колонка редактора

• Нарушитель конвенции

локальные сети

• Коннектор - "узкое" место кабельной системы

• Коммутируемый Ethernet или разделяемый Fast Ethernet

• Когда не помогает хороший пинок

• Волоконно-оптический кабель - что это и зачем он нужен

• Удаленная загрузка - ваша "палочка-выручалочка"

корпоративные сети

• IP-коммутация: сражение за сетевые высоты

• Надоедливый "писк"

• Связующее ПО: на сцене статисты

• Качество обслуживания, или Как добиться неравенства в мире равноправия

• Системы управления уровня рабочей группы

• Грядет РИФ'98...

услуги сетей связи

• Услуги цифровой связи E1

• Рефлектометры для медных кабелей

• Телефонные гарнитуры: в серьезном бизнесе нет мелочей

• Технологии доступа. Делайте ваши ставки

• Руководство покупателя модемов формата Pc Card

интернет и интрасети

• Интернет для среднего офиса

• Мультимедиа в Интернет

защита данных

• Реальные системы для виртуальных коммутируемых частных сетей

новые продукты

• Три новинки Lucent Technologies, Парад новинок от HP, Что нам стоит сеть построить..., Быстрый и многофункциональный коммутатор от 3Com

только на сервере

• Интернет от... IBM

• Фирменное ПО управления сетевыми устройствами

• Исследуем производительность JDBC - интерфейсов

• В поисках унифицированной почтовой архитектуры



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх