Файл: Технология построения распределенных информационных систем (Преимущества и недостатки использования распределённых информационных систем).pdf

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

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

.

DCOM предоставляет множество способов совместить реальный сетевой протокол с сетевым траффиком без изменения взаимодействия клиента с компонентом: кэширование со стороны клиента, переадресация ссылок и замена сетевого транспорта при необходимости – лишь часть возможных способов.

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

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

Распределенная платформа должна предусматривать наличие framework, отвечающего за безопасность для того, чтобы была обеспечена возможность различать отдельных клиентов и отдельные группы клиентов. Тогда система или приложение будут иметь возможность определять, кто пытается начать работать с компонентом. DCOM использует framework повышенной безопасности, предлагаемый Windows NT. Windows NT предусматривает серьезный набор встроенных провайдеров безопасности, поддерживающий многочисленные механизмы идентификации и аутентификации, от традиционных моделей доменов доверия (trusted-domain) до нецентрализованно управляемых, хорошо масштабируемых механизмов безопасности. Центральной частью framework, отвечающего за безопасность, является каталог пользователя, который содержит информацию, необходимую для подтверждения прав пользователя (имя пользователя, пароль). Большинство DCOM-реализаций на отличных от Windows NT платформах предусматривают такой же или подобный механизм, какой бы провайдер безопасности ни был доступен для данной платформы. Большая часть UNIX-реализаций DCOM будут включать Windows NT-совместимый провайдер безопасности.

Перед тем, как ближе ознакомиться с Windows NT-провайдерами каталогов и безопасности, давайте обсудим, как DCOM использует этот общий framework безопасности для облегчения создания защищенных приложений.

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

DCOM достигает подобной прозрачности в безопасности, позволяя разработчикам и администраторам конфигурировать установки защищенности для каждого компонента. Точно так же, как файловая система Windows NT позволяет администратору установить списки управления доступом (ACL) для файлов и каталогов, DCOM содержит списки управления доступом для компонентов. Эти списки показывают, какие пользователи или группы пользователей имеют право доступа к компонентам определенного класса. Эти списки могут легко конфигурироваться инструментом конфигурирования DCOM (DCOMCNFG) или программироваться с помощью реестра Windows NT и функций обеспечения безопасности Win32.

Когда бы клиент ни вызвал метод или создал пример компонента, DCOM получает текущее пользовательское имя клиента, связанного с текущим процессом (на самом деле – текущий исполняемый поток). Windows NT гарантирует, что данный пользовательский идентификатор аутентичен. После этого DCOM передает имя пользователя машине или процессу, где работает этот компонент. На машине компонента DCOM снова проверяет имя пользователя, используя аутентификационный механизм, и проверяет список управления доступом для данного компонента (на самом деле — для первого компонента, работающего в процессе, содержащего интересующий компонент. Более детально это описано в Белых Страницах “Архитектура DCOM”.) Если имя клиента не включено в этот список (прямо или косвенно – в качестве члена группы пользователей), DCOM просто отклоняет этот вызов еще до того, как компонент вовлекся в работу. Этот обычный механизм безопасности полностью прозрачен как для клиента, так и для компонента и оптимизирован. Он базируется на framework безопасности Windows NT, который является наиболее интенсивно используемой (и оптимизированной!) частью операционной системы Windows NT: при каждом доступе к файлу или даже к такому примитиву синхронизации потоков, как сигнализация или событие, Windows NT выполняет идентичную проверку доступа. Тот факт, что Windows NT по-прежнему может неплохо конкурировать в быстродействии с другими операционными системами и сетевыми операционными системами, показывает, насколько эффективен этот механизм безопасности (рис.24).

DCOM предлагает чрезвычайно эффективный механизм обеспечения безопасности, который позволяет разработчику создавать распределенные приложения, не опасаясь за его защищенность. Любой провайдер безопасности, поддерживаемый Windows NT, может использоваться механизмом безопасности DCOM.

3.2 Технология COBRA

В конце 1980-х и начале 1990-х годов многие ведущие фирмы-разработчики были заняты поиском технологий, которые принесли бы ощутимую пользу на все более изменчивом рынке компьютерных разработок. В качестве такой технологии была определена область распределенных компьютерных систем. Необходимо было разработать единообразную архитектуру, которая позволяла бы осуществлять повторное использование и интеграцию кода, что было особенно важно для разработчиков. Цена за повторное использование кода и интеграцию кода была высока, но ни кто из разработчиков в одиночку не мог воплотить в реальность мечту о широко используемом, языково-независимом стандарте, включающем в себя поддержку сложных многосвязных приложений. Поэтому в мае 1989 была сформирована OMG (Object Managment Group). Как уже отмечалось, сегодня OMG насчитывает более 700 членов (в OMG входят практически все крупнейшие производители ПО, за исключением Microsoft).

Задачей консорциума OMG является определение набора спецификаций, позволяющих строить интероперабельные информационные системы. Спецификация OMG -- The CommonObject Request Broker Architecture (CORBA) является индустриальным стандартом, описывающим высокоуровневые средства поддерживания взаимодействия объектов в распределенных гетерогенных средах.

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

Dynamic Invocation Interface (DII): позволяет клиенту находить сервера и вызывать их методы во время работы системы.

IDL Stubs: определяет, каким образом клиент производит вызов сервера.

ORB Interface: общие как для клиента, так и для сервера сервисы.

IDL Skeleton: обеспечивает статические интерфейсы для объектов определенного типа.

Dynamic Skeleton Interface: общие интерфейсы для объектов, независимо от их типа, которые не были определены в IDL Skeleton.

Object Adapter: осуществляет коммуникационное взаимодействие между объектом и ORB.

Вот небольшой список достоинств и недостатков использования технологии CORBA.

Достоинства:

• Платформенная независимость

• Языковая независимость

• Динамические вызовы

• Динамическое обнаружение объектов

• Масштабируемость

• CORBA-сервисы

• Широкая индустриальная поддержка

Недостатки:

• Нет передачи параметров `по значению'

• Отсутствует динамическая загрузка компонент-переходников

• Нет именования через URL

К основным достоинствам CORBA можно отнести межъязыковую и межплатформенную поддержку. Хотя CORBA-сервисы и отнесены к достоинствам технологии CORBA, их в равной степени можно одновременно отнести и к недостаткам CORBA, ввиду практически полного отсутствия их реализации.

3.3 Технология EJB

Основная идея, лежавшая в разработке технологии Enterprise JavaBeans -- создать такую инфраструктуру для компонент, чтобы они могли бы легко ``вставляться'' (``plug in'') и удаляться из серверов, тем самым увеличивая или снижая функциональность сервера. Технология Enterprise JavaBeans похожа на технологию JavaBeans в том смысле, что она использует ту же самую идею (а именно, создание новой компоненты из уже существующих, готовых и настраиваемых компонент, аналогично RAD-системам), но во всем остальном Enterprise JavaBeans -- совершенно иная технология.

Опубликованная в марте 1998 года EJB-спецификация версии 1.0 (Недавно была опубликована версия 1.1 спецификации) определяет следующие цели:

• Облегчить разработчикам создание приложений, избавив их от необходимости реализовывать с нуля такие сервисы, как транзакции (transactions), нити (threads), загрузка (load balancing) и другие. Разработчики могут сконцентрироваться на описании логики своих приложений, оставляя заботы о хранении, передаче и безопасности данных на EJB-систему. При этом все равно имеется возможность самому контролировать и описывать порученные системе процессы.

• Описать основные структуры EJB-системы, описав при этом интерфейсы взаимодействия (contracts) между ее компонентами.

•EJB преследует цель стать стандартом для разработки клиент/сервер приложений на Java. Таким же образом, как исходные JavaBeans (Delphi, или другие) компоненты от различных производителей можно было составлять вместе с помощью соответствующих RAD-систем, получая в результате работоспособные клиенты, таким же образом серверные компоненты EJB от различных производителей также могут быть использованы вместе. EJB-компоненты, будучи Java-классами, должны без сомнения работать на любом EJB-совместимом сервере даже без перекомпиляции, что практически нереально для других систем.

EJB совместима с Java API, может взаимодействовать с другими (не обязательно Java) приложениями, а также совместима с CORBA.

Разработчику, однако, не нужно самому реализовывать EJB-объект. Этот класс создается специальным кодогенератором, поставляемым вместе в EJB-контейнером. Как уже было сказано, EJB-объект (созданный с помощью сервисов контейнера) и EJB-компонента (созданная разработчиком), реализуют один и тот же интерфейс. В результате, когда приложение-клиент хочет вызвать метод у EJB-компоненты, то сначала вызывается аналогичный (по имени) метод у EJB-объекта, что находится на стороне клиента, а тот, в свою очередь, связывается с удаленной EJB-компонентой и вызывает у нее этот метод (с теми же аргументами).

Существует два различных типа ``бинов''.

Session bean представляет собой EJB-компоненту, связанную с одним клиентом. ``Бины'' этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять ``бин'', который живет в Web-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает Web-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназначение заключается все-таки не в отображении состояния или в работе с ``вечными объектами'', а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.

Entity bean, наоборот, представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, ``выживая'', тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить ``бин'' из базы данных). Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его атрибутами и связями.