Файл: Технология CORBA.pdf

• первый тип: заглушка IDL – это статический интерфейс к сервисам, объявленным в интерфейсах IDL, для клиента при этом все вызовы кажутся локальными. Он выступает при этом в качестве прокси удаленного объекта, который вызывает удалённые методы, включая в себя сериализацию, прием ответов и десериализацию. Количество заглушек может быть ограничено только количеством интерфейсов IDL. Генерация интерфейса происходит из IDL на языке программирования клиента (C, C ++, Java, Smalltalk, Ada и др) компилятором IDL.
• скелет IDL – это статический представитель клиента на сервере. При этом для сервера все звонки кажутся локальными. Этот тип генерируется из IDL компилятором IDL и выполняет десериализацию вызовов клиента.

Ниже представлен пример IDL для объекта, который выполняет HELLO WORLD. В одностороннем порядке указывается, что связь является однонаправленной и, соответственно, ответ метода не ожидается:

module HelloApp {

interface Hello {

string sayHello();

oneway void shutdown();

}

}

Java-CORBA как мощное средство решения проблемы объединения систем на основе технологии WWW

Как уже говорилось ранее, у технологии Corba наблюдались проблемы, связанные со Всемирной паутиной. Решением данной проблемы является язык Java, который позволил связать технологию Corba и WWW. Для реализации этой связи использовались программные продукты: OrbixWeb, Visibroker.

Java-технология основана на том, что при обнаружении тега <APPLET>, броузер через сеть загружает к себе необходимые для этого апплета Java-классы и запускает его. При этом на машине пользователя запускается Java Virtual Machine (JVM), внутри которой и выполняется загруженный апплет [7, стр. 1].

Рисунок 4. Java-CORBA

Java-апплет, который является Corba-клиентом, устанавливает все необходимые соединения с другими (серверными) приложениями системы и именно через него к пользователю идет вся информация. Апплет играет роль пользовательского интерфейса для данной распределенной системы. Количество выполняемых апплетов ничем не ограничено -- вопрос лишь в достаточных вычислительных ресурсах системы [7, стр. 2].

У Java-CORBA существуют достоинства и недостатки.

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

• это платформенно-независимый язык, все апплеты которого выполняются одинаково на любой системе;
• у этого языка существует возможность создания сложных пользовательских интерфейсов;
• апплеты языка выполняют роль и клиента, и сервера;
• при одновременной работе нескольких пользователей не возникает проблем;
• по сравнению с CGI (от англ. Common Gateway Interface — «общий интерфейс шлюза») нет необходимости снова загружать апплет.

Недостатки Java:

• для эффективного выполнения Java-приложений, система пользователя должна обладать достаточно мощными вычислительными ресурсами, что особенно важно для сложных (насыщенных) пользовательских интерфейсов;
• не все браузеры могут поддерживать Java или ее обновленные версии.

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

У технологии Corba существуют механизмы передачи сообщений, которые называются PUSH и PULL (рисунок 5):

Задачи механизма Pull: запрашивание у сервера на наличие новых сообщений при необходимости клиентом обработки сообщений, при их отсутствии клиентом операция повторяется через некоторое количество времени. При этом взаимодействие клиента и сервера может быть синхронным или асинхронным.

Задачи механизма Push: в каком-то смысле противоположны Pull. В данном случае от сервера поступает информация клиенту о появлении новых сообщений, при этом клиенты сами становятся серверами. При этом взаимодействие клиента и сервера аналогично механизму Pull и являются синхронными и асинхронными.

Рисунок 5. Описание механизмов PUSH и PULL

При использовании механизма PULL, для обработки каждого из запросов клиента сервер расходует свои системные ресурсы, что при наличии большого числа клиентов, регулярно опрашивающих его, заметно снижает его производительность. Многое также зависит и от того, сколь часто клиенты опрашивают сервер. При большом количестве клиентов-ожидателей и коротком времени между двумя запросами к серверу, производительность сервера снижается еще больше [7, стр. 2].

В модели PUSH сервер сообщений гораздо менее загружен. Сервер освобожден от необходимости регулярно реагировать на вызовы клиентов-ожидателей. Наоборот, теперь он имеет дело с клиентами-слушателями. "Вталкивание" сообщений клиенту применяется особенно в тех случаях, когда сообщения, появившиеся на сервере сообщений, должны быть немедленно обработаны клиентом (клиентами). Да и при наличии некачественной связи между узлами, механизм PUSH гораздо более рентабелен, чем PULL -- он использует информационный канал лишь один раз для каждого клиента [7, стр. 3].

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

У пользовательского клиента (апплета), который заинтересован в сообщении, создается специальный слушатель, который запускается основным пользовательским клиентом в отдельном процессе, при этом используется механизм Threads (нить) – виртуальный процессор, который имеет свой собственный регистр, аналогичный регистрам настоящего центрального процессора, в языке Java. При его запуске слушатель, который реализует IDL-интерфейс, специфичный для данного типа сообщений, информирует сервер сообщений о том, что он заинтересован в приеме сообщений этого типа, после чего переходит в режим ожидания. При получении сообщения происходит взаимодействие класса - слушатель и класса – клиент.

Исходя из практического применения технологии Java-CORBA были сделаны выводы, что она лучше всего подходит для создания WWW Corba-клиентов, которые:

• имеют пользовательский интерфейс нестандартного типа, или не HTML – подобного;
• в течении какого-то времени активно взаимодействуют с различными компонентами информационной системы;
• должны участвовать в роли системы или сервера в информационной системе.

Брандмауэры CORBA

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

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

Подходящими средствами обеспечения соблюдения политик безопасности на границах между доменами безопасности являются брандмауэры. Целью межсетевого экрана CORBA OMG является улучшение доступа к серверам приложений CORBA, когда существует межсетевой экран, отделяющий сервер от клиента. Это облегчает включение и управление связью клиент-брандмауэр-сервер в более широком диапазоне обстоятельств со значительно сниженной административной нагрузкой. Интероперабельная связь CORBA осуществляется через общий протокол Inter-ORB (GIOP), который в Интернете реализуется посредством IIOP (отображение GIOP на транспорт TCP). Поскольку брандмауэры управляют связью по IP-сетям, а ORB обмениваются данными через IIOP, большая часть деятельности CORBA Firewall посвящена различным операциям, связанным с обработкой трафика IIOP через брандмауэр [2, стр. 3].

CORBA (точнее, IIOP) использует соединения TCP / IP для передачи данных. Однако, если клиент находится за очень ограничительным брандмауэром или средой с прозрачным прокси-сервером, которая разрешает только внешние HTTP-соединения через порт 80, связь может оказаться невозможной, если только соответствующий прокси-сервер не разрешает метод HTTP CONNECT или соединения с сокетами. Был момент, когда было трудно заставить реализации использовать один стандартный порт, вместо этого они должны были выбрать несколько портов наугад.

Нынешние ORB не имеют этих недостатков. Из-за этих трудностей некоторые пользователи предпочли использовать веб-службы вместо CORBA. Они взаимодействуют с использованием XML / SOAP через порт 80, который обычно остается открытым или фильтруется через HTTP-прокси в организации для просмотра веб-страниц через HTTP.

Реализации CORBA поддерживают SSL и могут быть легко настроены для работы на одном порту. Большинство самых популярных ORB с открытым исходным кодом, таких как TAO и JacORB, также поддерживают двунаправленный GIOP, что дает CORBA преимущество в том, что он может использовать обратную связь вызова, а не подход опроса функция реализации веб-сервисов. В свою очередь, все больше и больше брандмауэров, которые поддерживают CORBA, без проблем продаются.

Внешние и внутренние маршрутизаторы настроены с точки зрения IP-адресов, портов и бита ACK в заголовках TCP. Более сложные маршрутизаторы могут также проверять трафик для некоторых обычно используемых протоколов приложений (например, HTTP, FTP), чтобы динамически предоставлять некоторые разрешения и отклонять трафик, если протокол приложения не соблюдается правильно.

В транзакционном приложении суть требования заключается в том, что входящие вызовы действуют на оперативные данные и данные, которые должны храниться во внутренней сети. Вызовы могут исходить из различных внешних источников и могут быть направлены на различные хосты во внутренней сети. Требования к приложениям выходят за рамки требований, обычно выполняемых межсетевым экраном, и задача состоит в том, чтобы удовлетворить эти требования без ущерба для безопасности. Еще одно отличие от обычного брандмауэра состоит в том, что CORBA не очень хорошо вписывается в модель, в которой управление основано на заранее известных хостах и номерах портов [2, стр. 5].

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

глава 2. ОБ обзоре архитектуры и специфики corba

2.1 Архитектура распределенных объектов Corba

Основные концепции Corba известны разработчикам, которые имеют достаточные знания для работы с шаблонами проектирования. Два основных типа IDL, заглушки и скелеты, рассмотренные мной в первой главе, являются посредниками или объектами, которые управляют доступом к другим объектам. Кроме того, существуют фабрики – сервисы, возвращающие объект. В данной спецификации фабрики и посредники можно обнаружить повсюду. Классы и объекты, которые применяют шаблоны проектирования (паттерны), скрывают от разработчиков детали их реализации. Шаблоны проектирования дают возможность унифицировать проектные решения и терминологию. Их изучение позволяет разработчикам повторное использование компонентов, проектов, структур и сервисов.

Как уже было сказано ранее, ORB (брокер объектных запросов) является основным компонентом Corba, а, следовательно, все объекты с ним совместимые должны использовать этот брокер между собой и теми, кто к ним обращается (Рисунок 2,3).

Рисунок 2. Путь вызова с точки зрения клиента

Рисунок 3. Путь вызова от клиента к удаленному объекту

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

Развитие аппаратных и программных средств привело к появлению большого количества несовместимых систем, которые в скором времени были решены при помощи системных интеграторов. В этот период консорциумом OMG, совместно с компаниями – производителями, была разработана OMA (Object ManagementArchitecture) – модель архитектуры управления объектами (рисунок 3).

Рисунок 3. Эталонная модель архитектуры управления объектами

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