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

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

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

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

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


Rambler's Top100

  

Связующее ПО. "Вождение" приложений по сети

Брюс Робертсон

Связующее ПО (middleware) в значительной мере определяет работу сетевых приложений. Однако мало кто разбирается в вопросах, касающихся специфики конкретного связующего ПО и его работы в реальных условиях. Разработчики приложений оценивают связующее ПО "сверху вниз". Часто программист действует как автолюбитель, не представляющий принципы работы автомобиля и его обслуживания. У такого автолюбителя есть лишь желание водить машину: крутить руль и нажимать на педали.

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

Взгляд с места водителя

По существу, программисты определяют связующее ПО посредством его интерфейса прикладных программ (API — Application Programming Interface). Они хотят знать лишь одно: как пользоваться этим интерфейсом. Такое рассмотрение связующего ПО, "сверху вниз", дает представление о том, как с ним общаться, но необязательно приводит к пониманию принципов его работы (см. диаграмму "Функциональные возможности связующего ПО. Взгляд со стороны API"). Из того, что у одного автомобиля автоматическое переключение скоростей, а у другого — ручное, не стоит делать вывод об их серьезном отличии. Ведь возможно сходство на более низком уровне. Тем не менее, при оценке по схеме "сверху вниз" выделяются следующие категории связующего ПО:

· ПО, ориентированное на передачу сообщений (Message-Oriented Middleware — MOM);

· ПО, основанное на вызовах удаленных процедур (Remote Procedure Call — RPC);

· ПО доступа к данным;

· мониторы обработки распределенных транзакций (Distributed Transaction Processing — DTP), или мониторы транзакций;

· посредники объектных запросов (Object Request Broker — ORB).

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

Обычно продукты MOM предлагают довольно ограниченный набор команд для связи по сети — часто всего лишь команды SEND и RECEIVE (рис. 1). Здесь мы не имеем в виду обмен сообщениями электронной почты. Продукты МOM позволяют одним программам посылать данные другим программам в реальном времени (или медленнее), в то время как инфраструктуры электронной почты до сих пор используются в основном для обмена в режиме накопления (store-and-forward) текстовыми сообщениями между людьми.

Продукты MOM можно сравнить с автомобилем с ручным переключением передач. Разработчики прикладных программ создают специализированные функции или подпрограммы исходя из базовых функций обмена сообщениями продуктов МОМ. Программировать для интерфейсов API такого связующего ПО даже проще, чем программировать для транспортных интерфейсов API, скажем гнезд TCP/IP. Существует множество продуктов, ориентированных на передачу сообщений, таких как Covia Communications Integrator (CI), Pipes фирмы PeerLogic, XIPC/Message Express фирмы Momentum, MQSeries фирмы IBM, DECmessageQ и NetWeave фирмы Digital. Производители систем управления реляционными базами данных (СУРБД) также предлагают подобные продукты: например фирмы Oracle и Sybase предлагают продукты Oracle Mobile Agents и EMS соответственно.

Продукты, основанные на RPC, больше ориентированы на использование функций. Разработчики определяют специализированные для конкретного приложения функции с помощью языка описания интерфейса IDL (Interface Definition Language) и затем компилируют их в код заглушки (stub) клиентской и серверной систем. Заглушки фактически и обеспечивают взаимодействие по сети (рис. 2). Приложение выполняет лишь обычный вызов функций. По существу, разработчики создают собственные интерфейсы API. Многие продукты RPC могут генерировать заглушки функций, написанных лишь на языках программирования третьего поколения (3GL), но некоторые продукты, такие как PowerBuilder, поддерживают языки программирования четвертого поколения (4GL). Несмотря на то, что большинство инструментальных средств, использующих языки 4GL, могут обращаться к функциям языка Cи, более удобно, если эти функции специально созданы для таких средств. Когда вы распределяете по нескольким сетевым узлам существующие многопользовательские приложения, подход, основанный на RPC, довольно интуитивен: каждая из имеющихся функций может разбиваться на части и распределяться по сети необходимым образом. Продукты RPC в боўльшей степени автоматизируют труд программиста по сравнению с продуктами МОМ.

Системы, основанные на RPC, поставляются многими фирмами: производителями продуктов, поддерживающих стандарты среды распределенных вычислений (Distributed Computing Environment — DCE), такими как фирмы IBM, Digital, Hewlett-Packard и др.; а также компаниями Gradient, Open Horizons и т. д. На многих платформах Unix реализованы ONC RPC фирмы Sun.

Программные продукты для доступа к данным имеют интерфейсы API, ориентированные на работу с данными, которые располагаются в таблицах. Используя стандартный интерфейс API — Open DataBase Connectivity (ODBС), прикладные программы получают удаленные данные с помощью языка SQL (рис. 3). Однако большинство производителей СУРБД имеют в дополнение к ODBС собственные интерфейсы API, которые позволяют производителям предоставлять пользователям уникальные функциональные возможности своих СУРБД. Если прикладная программа предназначена лишь для обмена распределенными данными с серверами баз данных, то для этой цели рассматриваемая категория связующего ПО отлично подходит. Многие инструментальные средства уже поддерживают интерфейсы API такого связующего ПО. В этом случае на сервере баз данных не требуется программирования под конкретное приложение, следовательно, расширяются возможности для разработки прикладных программ.

Несмотря на то, что связующее ПО для доступа к данным обеспечивает лишь доступ к данным, при его использовании фрагменты прикладной программы могут распределяться по сети для работы на разных узлах. Хотя более поздние разработки хранимых процедур обеспечивают некоторые дополнительные возможности для распределенных по сети программ, пока речь может идти лишь о манипулировании данными средствами языка SQL, причем в форме, специфической для СУРБД. Кроме крупных производителей СУРБД, таких как Oracle (продукт SQL*Net), Sybase (Open Client/Open Server), Microsoft (DB-Library) и т. д., другие фирмы, например IBI, TechGnosis (недавно приобретена компанией Intersolv), Cross Access, NetWise (недавно приобретена компанией Microsoft), Neon Systems, предлагают независимые от конкретной СУРБД продукты доступа к данным.

Мониторы транзакций предоставляют среду связующего ПО, ориентированную на выполнение транзакций. Такое ПО, как правило, добавляет к командам SEND и RECEIVE команды BEGIN и END TRANSACTION (рис. 4). Если прикладная программа использует службу обработки распределенных транзакций, то ей (программе) необязательно содержать логическую схему, гарантирующую целостность транзакций.

Мониторы транзакций часто встраиваются (сверху) в системы, ориентированные на передачу сообщений или основанные на RPC, значительно расширяя их функциональные возможности. Большинство производителей мониторов транзакций работают над реализацией новых стандартных интерфейсов X/Open API, но пока почти все имеют собственный интерфейс API. Рассматриваемый вид связующего ПО взаимодействует с ресурсами баз данных посредством стандартных интерфейсов X/A, поддерживаемых большинством производителей СУРБД. К такому ПО относится Tuxedo фирмы Novell, Encina фирмы Transarc, Top End производства AT&T GIS и CICS корпорации IBM. Продолжая сравнение с автомобилем, можно сказать, что мониторы транзакций предлагают ручное переключение передач, однако число передач увеличено и имеются воздушные мешки для обеспечения максимальной безопасности пассажиров.

Продукты ORB поддерживают взаимодействие распределенных по сети частей прикладной программы, но используют иной интерфейс API, основанный на объектах (рис. 5). Когда программист приступает к работе с объектно-ориентированным инструментарием (таким как языки 3GL, Cи++ или 4GL), простейшее связующее ПО должно прямо передавать в сеть объекты, созданные с помощью этого инструментария. ORB дает возможность разработчику приложения, содержащего множество объектов, легко распределить эти объекты по разным узлам сети. Этот подход аналогичен подходу, основанному на RPC, за исключением того, что используются инструментальные средства, ориентированные на объекты, а не на функции.

Если разработчик объектно-ориентированного приложения не использует ORB, то программирование усложняется из-за необходимости создания связей между объектами и функциями или интерфейсами API, предлагаемыми другим связующим ПО. В мире ORB имеется множество стандартов: Common Object Request Broker Architecture (CORBA) группы Object Management Group, стандарты де-факто, такие как технология связывания и внедрения объектов (OLE) компании Microsoft (которая будет наделена распределенными функциональными возможностями лишь после появления Cairo) и OpenDoc. Значительная часть стандарта CORBA определяет интерфейсы API, хотя более поздние версии CORBA окончательно предоставят службы, доступные через API, и даже ряд факультативных возможностей взаимодействия. Продукты ORB предлагаются производителями больших систем: IBM, HP, Digital, NEC, AT&T GIS и многими другими фирмами, включая Iona (продукт Orbix), Expersoft (PowerBroker), PostModern (ORBeline) и NeXT.

Некоторые инструментальные средства содержат лишь компоненты связующего ПО и могут быть приспособлены к использованию внешних систем связующего ПО.

Заглянем под капот

Скрывая детали своего функционирования от разработчиков, связующее ПО заботится о вещах, которые необходимы разработчику для создания приложения. Такое ПО располагает соответствующими службами и тем самым сокращает объем работы, время и затраты, необходимые для реализации приложения (см. диаграмму "Функциональные возможности связующего ПО. Взгляд со стороны служб").

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

Каждое связующее ПО может предоставлять услуги различных сетевых служб, но даже если программисты обратят на них внимание, они могут воспринять их как возможности интерфейса API, а не как нечто, нуждающееся в развертывании и сопровождении. Рассмотрим, например, службу имен: боўльшая часть связующего ПО для доступа к данным предоставляет список всех серверов СУРБД, к которым пользователи имеют доступ, и может преобразовать выбранное пользователем имя сервера в соответствующий сетевой адрес, скажем в адрес IP. Этого вполне достаточно для программиста — пользователь будет видеть имена.

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

Кроме того, каждый продукт представляет уникальное сочетание интерфейсов API и служб, наиболее подходящих для определенной среды приложений. Некоторые продукты поддерживают даже различные типы API. К примеру, NetWeave и ISIS поддерживают и подход, ориентированный на передачу сообщений, и подход, ориентированный на доступ к данным.

Связующее ПО может размещаться послойно, одно над другим. Многие продукты, основанные на RPC среды DCE, используют службы этой среды (такие как службы справочников и безопасности). Продукт компании Open Horizons предоставляет доступ к данным в среде DCE, в то время как пакет Encina фирмы Transarc — монитор транзакций в среде DCE. Пакет Orbix ORB работает поверх другого связующего ПО — ISIS. Корпорация IBM объявила, что она создаст интерфейс API поставщика услуг для SOM/DSOM, так что другое связующее ПО, скажем Pipes, сможет функционировать под этим интерфейсом.

Транспортные услуги

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

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

Боўльшая часть связующего ПО, ориентированного на использование RPC и на доступ к данным, построена по модели "запрос—ответ" (эта модель применяется и сетевым транспортом, таким как TCP/IP): задайте вопрос и ждите ответа на него. Это синхронное блокирующее поведение подходит процедурным приложениям, где все происходит в логически обусловленном порядке, под управлением одной базовой программы, выполняемой обычно на клиентском узле. Связующее ПО гарантирует доставку запросов и ответов на них. Часто оно лишь передает сообщение прямо TCP/IP или другому транспортному стеку протоколов для надежной, ориентированной на соединение доставки. Устанавливаются соединения, происходит обмен данными, затем соединения завершаются. Подобный механизм работы наиболее эффективен, если серверы не перегружены и клиент в каждый момент времени ведет диалог лишь с одним сервером.

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

Асинхронная связь осуществима с помощью механизма многопоточных RPC (скажем, в среде DCE многопоточность предусмотрена), но такая связь оказывается более простой при использовании связующего ПО, ориентированного на передачу сообщений. Боўльшая часть такого ПО реализует асинхронный режим или посредством многопоточности соответствующей операционной системы, или обеспечивая внутреннюю многопоточность, если операционные системы, по существу, не являются многозадачными (скажем Windows 3.x). Программные продукты для передачи сообщений, такие как NetWeave и Covia CI, предоставляют и синхронный, и асинхронный режимы.

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

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

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

Когда взаимодействие, основанное на передаче сообщений, комбинируется с механизмом очередей, для приложения отпадает необходимость находиться в режиме on-line (подобное преимущество имеют электронная и голосовая почты). Клиенты и серверы могут выстраивать друг для друга очереди сообщений, которые будут доставлены при установлении соединения. Ряд продуктов MOM работает с очередями, организованными в памяти, для повышения производительности, в то время как другие поддерживают очереди на дисках, повышая надежность. Некоторые продукты, такие как NetWeave, используют одну очередь (для боўльшей производительности с минимальным временем ожидания), другие же, скажем MQSeries, используют две очереди (для обеспечения боўльшей готовности и надежности). Благодаря передаче сообщений с механизмом очередей приложения могут нормально работать через низкоскоростные или беспроводные каналы связи, так же как и с сильно перегруженными серверами (механизм очередей поддерживает короткие и насыщенные сеансы связи, а также пакетную обработку, что типично для систем больших ЭВМ).

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

Подходы типа "один ко многим" могут привести к интересным выводам по организации сетей. Ведь большинство сетей, построенных с помощью маршрутизаторов, не поддерживают передачу широковещательных сообщений между подсетями, а многоадресная передача поддерживается лишь некоторыми сетевыми транспортами. А вот, скажем, пакет Rendezvous Software Bus фирмы Teknekron предоставляет дополнительные функциональные возможности по широковещанию: например, пользователи Microsoft Excel могут анонимно публиковать части электронных таблиц для других пользователей, которые могут независимо подписываться на получение этих таблиц, передаваемых в режиме широковещания через границы подсетей.

Обеспечение прозрачности

Главное преимущество связующего ПО состоит в скрытии различий между средами, в которых развертываются приложения. Рассмотрим вопрос о прозрачном взаимодействии по сети. Дело не только и не столько в том, что интерфейс API связующего ПО проще, чем соответствующий транспортный интерфейс API, а в том, что связующее ПО позволяет приложениям "не замечать" различий между разными транспортными средствами и способствует развертыванию приложений и гибкости их обслуживания.

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

Связующее ПО осуществляет нормализацию форматов данных различных операционных систем. Некоторые продукты при передаче данных по сети используют не зависящее от платформ представление данных, такое как External Data Representation (XDR) в ONC RPC или Abstract Syntax Notation 1 (ASN.1). Большинство же руководствуются правилом, что принимающая сторона должна "понимать" все форматы, следовательно, продукты должны располагать информацией о компьютерах, с которых поступают сообщения. Это позволяет серверам передавать данные в "родном" формате с высокой скоростью.

Кроме того, связующее ПО может скрывать различия между разными системами баз данных (путем поддержки систем различных производителей, как это делается в пакете EDA/SQL фирмы IBI) или между разными унаследованными средами приложений (например, путем обеспечения доступа к существующей логике проведения транзакций системы CICS). При этом все ресурсы будут казаться сходными для приложения, выполняемого на компьютере-клиенте, хотя для интеграции проводимых унаследованными системами транзакций может потребоваться определенная программистская работа.

Для некоторых приложений необходима полная прозрачность самого связующего ПО. В этом случае программисты создают собственный мета-API. Получается трехзвенная схема, причем между разными звеньями используется разное связующее ПО. Например, продукт R/3 фирмы SAP AG для связи между настольными системами и серверами приложений использует обмен сообщениями, а между серверами приложений и серверами баз данных — метод доступа к данным.

Службы справочников

Службы справочников являются существенным фактором, по которому можно различать связующее ПО со сходными интерфейсами API, транспортными службами и службами, делающими различия между средами невидимыми для приложений. Изменение расположения сетевых ресурсов (например, изменение имен серверов или их адресов IP) может вызвать определенные затруднения, если прикладная система развернута на сотнях или тысячах настольных компьютеров.

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

Здесь уместно сравнить механизм RPC, определенный в стандартах среды DCE, с другими реализациями RPC. В то время как большинство RPC делают ставку на службу имен, DCE RPC часто реализуется совместно с такими службами среды DCE, как служба справочников и служба безопасности (по схеме Kerberos). Причем масштабируемые службы среды DCE предоставляют шифрование данных и аутентификацию.

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

Использование связующим ПО внешних служб справочников может зависеть от выбора платформы. Например, в настоящее время СУРБД Oracle 7.2 поддерживает службу NDS, но только когда сервер работает непосредственно на платформе NetWare. При работе с Oracle в среде Unix нельзя произвести аутентификацию через службу NDS.

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

Службы безопасности

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

Система безопасности должна обеспечивать подтверждение подлинности сетевого объекта (аутентификацию), конфиденциальность передаваемой информации (шифрование информации), целостность данных, идентификацию (возможно, с использованием технологии цифровой подписи) и подтверждение получения сообщения (возврат квитанции). Не все продукты связующего ПО имеют встроенную реализацию перечисленных функций, хотя в среде DCE имеются службы справочников и безопасности, которые совместно с механизмом RPC предоставляют эти функции. Лишь недавно фирма Novell объявила, что монитор транзакций Tuxedo будет использовать службу NDS для оказания услуг справочников и безопасности. Однако этот продукт, называемый TransactionLink, работает лишь в NetWare 3.0 и выше.

Систему Kerberos (определенную в документе RFC 1510) можно считать внешней системой безопасности, существующей вне собственных систем безопасности сетевых ОС. Однако лишь недавно, в версии 5, Kerberos обеспечила поддержку алгоритмов шифрования с открытым ключом, таких как RSA. Новый стандартный интерфейс API — Generic Security Services API (RFC 1508) — должен упростить работу связующего ПО, которое не поддерживает стандарты среды DCE, с соответствующими этому API системами безопасности, скажем Kerberos. Приложения, которые не используют механизм DCE RPC, могут напрямую проводить аутентификацию с помощью Kerberos. Так, продукт SuiteDOME ORB фирмы Suite Software ориентирован на передачу сообщений по сети, но поддерживает Kerberos.

Однако Kerberos нельзя считать идеальной системой безопасности. Сама по себе она не защищает от угадывания пароля взломщиком. Также она не поддерживает технологию генерации одноразовых паролей, которая требует специальных аппаратных средств, таких как SecurID фирмы Security Dynamics. В отличие от Kerberos, система сетевой безопасности, организованная в связующем ПО доступа к данным SQL*Net компании Oracle, поддерживает идентификацию пользователя по отпечаткам пальцев.

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

Однако некоторые продукты связующего ПО меняют этот порядок вещей. Приложения, поддерживающие механизм DCE RPC, могут шифровать данные. Новая библиотека DB-Library сервера Microsoft SQL Server 6.0, базирующаяся на механизме DCE RPC, поддерживает как централизованную систему безопасности, так и систему безопасности для каждого узла. Несмотря на то, что SQL Server 6.0 использует службы домена NT, а не службы справочников и безопасности среды DCE, безопасность процесса аутентификации будет гарантирована, если использовать именованные каналы (Named Pipes) или DCE RPC.

Создание приложений, работающих с ресурсами, доступ к которым контролируют разные системы безопасности (среды DCE, СУРБД, сетевой ОС, больших ЭВМ и т. д.), может быть значительно усложнено. Различные системы безопасности должны интегрироваться (или соединяться шлюзом) с помощью приложения или связующего ПО. В противном случае пользователям придется получать доступ раздельно к каждому ресурсу. Продукт SQL*Net/DCE компании Oracle предоставляет единый доступ к ресурсам с помощью служб справочников и безопасности среды DCE при работе по механизму DCE RPC. Аналогично обеспечивает доступ продукт Connection компании Open Horizons, но лишь доступ к базам данных Oracle. Фирма Novell еще не решила, будет ли система безопасности Net2000, базирующаяся на службе NDS, иметь шлюз в службу безопасности среды DCE или доменов NT. Пока только заявлено, что Novell реализует синхронизацию своих справочников со справочниками DCE и доменов NT.

Большинство продуктов связующего ПО все еще оставляют решение проблемы безопасности разработчикам приложений. Контроль безопасности, по-видимому, необходимо рассматривать на нескольких уровнях: на уровне установления диалогов (Kerberos, SSL фирмы Netscape), на уровне документов или сообщений (SHTTP, варианты защищенной электронной почты, такие как S/MIME и PEM) или даже на уровне транзакций (мониторы транзакций, спецификация Electronic Data Interchange). Пока остается множество нерешенных вопросов, которые возникают при переносе сетевых приложений, развернутых в относительно контролируемых частных сетях, в сети общего пользования, налагающие жесткие условия на систему безопасности.

Службы обеспечения отказоустойчивости

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

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

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

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

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


распечатать статью




  
5 '1996
СОДЕРЖАНИЕ

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

• Телефония через Internet: новое поле битвы?

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

• Беспроводные ЛВС: вчера, сегодня и завтра

• Недорогие коммутаторы Ethernet

• Мультимедиа и ЛВС

• Оптические дисковые автоматы

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

• Watchdog кусается

• "Плоды" большого дерева NDS

• Необычные, но невыдуманные истории

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

• Категории служб в сетях АТМ

• Будущее карманных устройств связи

• Передача данных по сетям сотовой связи

• Обзор аппаратуры SDH

• Связные заметки с выставки CeBIT

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

• Мир TCP/IP. Традиционные приложения (часть 2)

• Почтовый пакет компании Демос

• Списки рассылки: артерии информации

• Таблицы на Web

• Ваш след в Web

приложения клиент-сервер

• Связующее ПО. "Вождение" приложений по сети

• Связующее ПО. Смена веры

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

• Управляемые ИБП: защита предприятия

• Системы firewall: можете спать спокойно

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

• Сетевые принтеры: новинки на Comtek’96, Многофункциональность System 5000, Накопители TRAVAN TR-4 фирмы Seagate



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