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

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

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

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

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


Rambler's Top100

  

Как использовать потенциал архитектур распределенных объектов

Дон Маквитти

Лучший способ предотвратить хаос распределенных объектов -- заранее спланировать их архитектуру, что обеспечит возможность повторного использования объектов, их масштабируемость и интероперабельность. Хорошо спланированная архитектура распределенных объектов позволит вам развернуть отдельные компоненты ваших приложений на удаленных серверах, что позволит централизованно обновлять коды и снимет часть нагрузки с корпоративных настольных систем и конечных серверов.

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

Сегодня получили распространение три архитектуры распределенных объектов: DCOM (Distributed Component Object Model) компании Microsoft, CORBA (Common Object Request Broker Architecture) группы OMG и EJB (Enterprise JavaBeans) компании Sun Microsystems. Каждая из них реализует собственный подход к взаимодействию объекта с настольной системой. Архитектура DCOM предполагает, что настольная система "знает обо всем"; CORBA, в свою очередь, позволяет центральному серверу назначить настольную систему любому объекту; технология EJB оставляет этот вопрос на откуп разработчику. Компания Sun дает определение служб именования для EJB, но не навязывает поставщикам EJB-средств конкретных стандартов или технологий при реализации этих служб. Для всех трех платформ уже имеются средства взаимодействия, но они довольно дороги и еще недостаточно проработаны. При этом их использование существенно замедляет обработку данных.

DCOM и COM+

Модель DCOM компании Microsoft была представлена как проект стандарта для Интернет в январе 1998 г. Сейчас она уже работает на множестве предприятий. Модель COM+ является новой версией DCOM, в которой объединены собственно DCOM, сервер Microsoft Transaction Server (MTS) и средства изменения сетевой конфигурации.

DCOM позволяет разрабатывать три различные модели серверов: DLL-модель, исполняемую модель и DLL-модель для MTS. Каждая из этих моделей окажет характерное для нее влияние на ваш сервер, сеть и клиентов. В модели COM+ компания Microsoft попыталась создать единый для стандарта DCOM тип сервера: библиотеки DLL загружаются в MTS и доступ к ним большинства приложений осуществляется исключительно через MTS.

Модель DCOM имеет ряд серьезных конфигурационных сложностей, особенно при работе под управлением Microsoft Windows 95. На конфигурирование эффективно работающей сетевой и серверной среды могут уйти недели. Наибольшую трудность представляет конфигурирование средств сетевой безопасности. Вам придется задать параметры защиты на клиенте, сервере, в DCOM на вашем сервере, на первичном контроллере домена (PDC -- Primary Domain Controller) и на MTS.

Сейчас серверы DCOM доступны только на платформах Windows. Шли разговоры о их Unix-версии, но ее пока нет. А разработчики решений на базе COM+ даже и не пытаются взяться за проблему настоящей интероперабельности. В принципе из продуктов, произведенных не Microsoft, извлечь данные можно, но ввести их в системы на базе Windows весьма проблематично. По словам представителей Microsoft, на решение этой проблемы нацелена ее инициатива .Net (см.: Сети и системы связи. 2001. № 6. С.128).

CORBA

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

Серверы CORBA поддерживают Windows NT/2000, большинство вариантов Unix и IBM OS/390. Средства сред разработчика, использующие языки Си/Си++, COBOL, Java, Pascal, PL/I и Smalltalk, существуют как раз для этих платформ. Заметьте, что некоторые поставщики требуют, чтобы ПО устанавливалось на каждую настольную систему со службами CORBA. При столь широкой языковой поддержке настоящий CORBA-поставщик может привести вас прямо в нирвану распределенных объектов. Установка и конфигурирование сервера потребуют времени, а ваши разработчики должны будут пройти курс обучения языку описания интерфейсов CORBA IDL (Interface Definition Language), однако, если вам действительно нужно межплатформенное взаимодействие, то обратите внимание на CORBA.

Enterprise JavaBeans

Появление технологий EJB компании Sun -- это интересный поворот во всей истории развития компонентных архитектур. Она обеспечивает базовые функции распределенных объектов, но центральным моментом в ее подходе к проблеме является использование языка. Для компонентов EJB требуется сервер приложений, поддерживающий Java, а все обращающиеся к EJB приложения ранее должны были быть написаны на Java. Однако компания Sun и группа OMG объединили свои усилия для разработки альтернативного решения. Уже существует способ отображения интерфейсов OMG IDL на EJB IDL, в результате языки, поддерживающие CORBA, получат доступ к EJB, как если бы это был объект CORBA.

Хотя EJB обеспечивает межплатформенное взаимодействие и масштабируемость, вы ограничены единственным языком реализации -- Java. На рынке у EJB самый скромный из всех набор полезных средств, так как EJB самое новое из этих трех решений. Становым хребтом для EJB служит CORBA, но EJB позволяет Java-программистам разрабатывать распределенные объекты, не вникая в тонкости технологий CORBA или COM+. Разумеется, сетевые и системные инженеры по-прежнему должны знать CORBA, чтобы устанавливать эти службы.

Результирующее влияние

Так же как в CORBA и EJB, в архитектуре DCOM используется механизм удаленного вызова процедур (Remote Procedure Call -- RPC) для установления взаимодействия между клиентом и сервером. Чтобы сервер мог отвечать на запросы доступа к вашим объектам, интерфейс RPC сервера должен быть активен, а чтобы найти объекты и позволить вашим программам их инициализировать, процедура Dcomcnfg должна быть запущена на каждой рабочей станции для каждого DCOM-объекта, который будет реализован. Помимо прочего, Dcomcnfg создаст на вашей настольной системе запись в реестре, указывающую сервер, на котором вы развернули ваш объект.

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

Архитектура COM+ (и версии DCOM для Windows 98) чуть проще в управлении в плане обеспечения безопасности. Вы должны установить компонент COM+ на сервере, на котором работают службы COM+, и сконфигурировать рабочую станцию. Однако обеспечением безопасности доступа к объектам могут заниматься и пользователи, а ее параметры могут быть сконфигурированы на вашей настольной системе, когда объект конфигурируется на клиентском ПК. Настраивая COM+ для использования зарегистрированных пользователей, вы задаете права доступа для каждого пользователя или предоставляете групповой доступ к компоненту, а затем добавляете к этой группе пользователей, которым необходим такой доступ.

Архитектура CORBA использует целый ряд технологий для реализации служб имен и справочника. Этот стандарт определяет, какой должен использоваться интерфейс, но не предписывает, как именно он должен быть реализован. Используя CORBA IDL, вы можете генерировать объект и не нагружая его функциональным наполнением, просто инсталлировав "заглушку" (stub) -- небольшую стандартную подпрограмму. (Заглушка встраивается в вызывающее приложение, при этом у каждого клиента устанавливается только один интерфейс.) Это увеличивает трафик по сравнению с тем, какой генерирует DCOM, но рост его может быть минимизирован при помощи тщательного конфигурирования ORB (Object Request Broker).

Подобно организации служб именования и справочника, взаимодействие с удаленными объектами CORBA осуществляется несколькими способами. Наиболее распространенными из них являются RPC и IIOP (Internet Inter-ORB Protocol). Использование этих средств и поддержание оптимальной конфигурации клиента приводит к тому, что CORBA выполняет больше вызовов по инициализации объектов, чем DCOM. Но CORBA сэкономит время вашему персоналу на работе по конфигурированию. В зависимости от реализации сетевой защиты CORBA (а обычно здесь используется справочник LDAP) вам, по-видимому, придется иметь дело с проблемами безопасности. Самой распространенной является общая для всех трех архитектур проблема: в какой-то момент вашему серверу CORBA обязательно понадобится узнать, какие права имеют клиенты на доступ к тем или иным объектам, к которым обращаются их приложения.

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

В случае с EJB все взаимодействие осуществляется на Java. EJB -- это программные объекты, написанные главным образом на языке Java, хранящиеся на удаленных системах. Небольшие по размеру коды -- те же самые заглушки, только для Java -- описывают доступные в данном компоненте EJB классы, которые могут использоваться разработчиками для взаимодействия с EJB во время выполнения программы. Вся обработка данных для EJB осуществляется на удаленном сервере. Для установления соединения между клиентом и EJB используется коммуникационная технология CORBA. А это значит, что многих из тех трудностей, с которыми вы сталкиваетесь при конфигурировании CORBA, вам не избежать и при конфигурировании EJB.

Если клиент пытается воспользоваться EJB, он ищет нужный компонент Bean с помощью интерфейса JNDI (Java Naming and Directory Interface) -- стандарта, позволяющего практически любому пакету службы справочника обеспечить поиск объектов и сетевую безопасность. Взаимодействие с объектами осуществляется посредством Java IIOP-RMI, т. е. спецификации совместимого с CORBA удаленного Java-интерфейса.

Так как стандарт CORBA основополагающий для интерфейсов EJB, то упоминавшееся ранее отображение между OMG IDL и EJB IDL позволит клиентам, совместимым с CORBA версией 2.3 и более поздними, получить доступ к EJB. Написание этого стандарта позволило практически ликвидировать самое слабое место EJB -- то, что им требуется Java. Компоненты EJB не привязаны ни к какой ОС -- необходимо только, чтобы обращающееся к ним приложение было написано на Java. Однако, имея способ отображения CORBA IDL в EJB, вы можете писать свои объекты в виде EJB-компонентов (т. е. на Java), а обращаться к ним через любой поддерживающий CORBA язык.

Вопросы управления

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

И еще. Вам нужно сконфигурировать сервер, который управлял бы DCOM-объектом. Вы должны задать права доступа, определить, когда будет запускаться приложение, обслуживающее этот объект, и найти способ раздельного хранения экземпляров одного объекта. При использовании COM+ требуется больше усилий для конфигурирования способа запуска обслуживающего объект приложения, однако значительно проще осуществляется конфигурирование параметров защиты. Вместо того чтобы задавать стандарт, с которым могут работать разработчики, вы можете сконфигурировать ваш объект таким образом, чтобы разрешить доступ для определенной группы NT.

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

Для поддержки EJB требуется сервер приложений EJB. Большинство таких серверов совместимы с CORBA версии 2.3 и более поздними. Шли какие-то разговоры об отображении между EJB IDL и DCOM IDL. Однако не стоит ждать скорого появления EJB-решения на базе DCOM. Все задачи конфигурирования для EJB выполняются на серверах. Серверы служб имен и справочника должны располагать информацией о каждом удаленно инициализируемом экземпляре объекта, а сервер, на котором объект хранится, должен быть сконфигурирован так, чтобы отвечать на такие запросы.

Интернет-ресурсы по компонентным архитектурам

· CORBA: www.corba.org
· DCOM: www.microsoft.com/com/default.asp
· EJB: java.sun.com/products/ejb
· OBJECT MANAGEMENT GROUP: www.omg.org





  
10 '2001
СОДЕРЖАНИЕ

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

• Свобода или безопасность

бизнес

• Как успешно пройти собеседование, или Советы карьеристу

• Системные интеграторы перестраиваются

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

• Испытанные средства для решения проблем

• Измерение оптических потерь и протяженности оптического волокна - насколько это актуально?

• Объединяя сетевые адаптеры

• ПО резервного копирования: руководство для покупателя

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

• Концентраторы доступа АТМ: шире возможности - труднее выбор

• Модули PMC - "кирпичики" коммуникационной аппаратуры

• Коммутаторы для аппаратной этажа здания

• iPlanet - лучший Web-сервер для Lunix

• Одиссея порталов

• Использование метасправочника для интеграции сетевых служб и приложений автоматизации предприятия

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

• Когда не хватает скорости

• Ускорение доступа и оптимизация работы в Интернет

• Оптимизация сетевого трафика

• Мобильный интернет - новый стиль жизни, создающий информационное общество будущего

• Развитие систем сотовой связи

• Akamai: жизнь на краю

системы учрежденческой связи

• Новый лакомый кусочек

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

• Построение многоуровневой системы безопасности

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

• Как использовать потенциал архитектур распределенных объектов

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

• Новые решения для доступа в Интернет от компании ZyXEL

• КАЛЕЙДОСКОП



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