Базовые объектные архитектуры распределенных систем. Технологии .NET, (D)COM+, CORBA, EJB.

Базовые технологии. Сравнение на понятийном уровне.

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

В обеих технологиях взаимодействие между клиентским процессом и сервером объекта, то есть процессом, который порождает и обслуживает экземпляры объекта, осуществляется за счет вызова удаленных процедур (RPC, remote procedure call). Механизм RPC реализует схему передачи сообщений, в соответствии с которой в распределенном клиент-серверном приложении процедура-клиент передает специальное сообщение с параметрами вызова по сети в удаленную серверную процедуру, а результаты ее выполнения возвращаются в другом сообщении клиентскому процессу.
Для этого на стороне клиента и на стороне сервера поддерживаются специальные компоненты, носящие название клиентский и серверный суррогаты (client stub и server stub). Для вызова метода объекта клиент обращается к клиентскому суррогату, который упаковывает аргументы в сообщение-запрос и передает их на транспортный уровень соединения. Серверный суррогат распаковывает полученное сообщение и в соответствии с переданными аргументами вызывает нужный метод объекта. В СОМ клиентский суррогат называется proxy, а серверный - stub. В CORBA клиентский суррогат не имеет специального названия, а серверный обозначают термином skeleton.
Параметры вызова могут формироваться в отличной от серверной языковой и операционной среде, поэтому на клиентский и серверный суррогаты возлагаются функции преобразования аргументов и результатов в универсальное, не зависящее от конкретной архитектуры представление. Тем самым достигается возможность взаимодействия клиента и сервера на различных платформах.

h4 Понятие о технологии (D)COM(+).
(D)COM(+): COM, DCOM, COM+. COM (Component Object Model) - Объектно-Компонентная Модель (1993). D - distributed (1996).+ - 1998.
В СОМ объект характеризуется своим классом. Класс - это реализация некоторого множества интерфейсов. Множественное наследование интерфейсов не поддерживается, вместо этого объект может иметь несколько интерфейсов одновременно. В СОМ интерфейс может определяться путем наследования другого интерфейса. Для всех интерфейсов существует базовый интерфейс - IUknown. Для того чтобы перейти от интерфейса базового типа к унаследованному интерфейсу или от одного из интерфейсов объекта к другому, клиент должен вызывать метод QueryInterface, определенный в базовом интерфейсе IUknown.
Для идентификации классов и интерфейсов СОМ используются те же универсальные уникальные идентификаторы (UUID), которые приняты для идентификации интерфейсов в спецификации DCE RPC. Можно применять и символьные обозначения интерфейса, но затем они должны быть транслированы в надлежащий идентификатор UUID. Объект в СОМ - это экземпляр класса. Клиент получает доступ к объекту с помощью указателя на один из его интерфейсов (interface pointer). Идентификатор класса ссылается на конкретную реализацию, и фактический набор интерфейсов для данной реализации становится окончательно известен только на стадии выполнения. СОМ реализует интеграцию объектов на уровне двоичных кодов.
Microsoft IDL (MIDL) - лишь один из возможных способов определения интерфейсов объекта. В спецификации СОМ подчеркивается, что эта модель реализует интеграцию на двоичном уровне, поэтому все спецификации и стандарты, относящиеся к уровню исходных текстов компонентов рассматриваются как вспомогательные и не могут оказывать решающего влияния на общую архитектуру системы.
COM поддерживает интерфейс динамического вызова (когда интерфейс объекта не известен клиенту на этапе компиляции).
В COM для идентификации объектов используется механизм moniker, который обеспечивает преобразование символьного имени объекта в указатель интерфейса. Этот механизм действует для тех объектов, которые сохраняются в долговременной памяти. Два же активных объекта считаются идентичными, если для них совпадают указатели на интерфейс IUknown. Для долговременного хранения в СОМ поддерживаются две модели. Первая и изначальная модель предоставляет клиенту возможность управлять хранением объекта. По второй модели Microsoft Transaction Server (MTS) обеспечивает управление хранением со стороны сервера.
В СОМ предусмотрены такие общие службы, как защита (security), управление жизненным циклом (lifecycle managemеnt), информация о типах (type information), именование (naming), доступ к базам данных (database access), передача данных (data transfer), регистрация (registry) и асинхронное взаимодействие.

Понятие о технологии CORBA.

CORBA (Common Object Request Broker Architecture) - общая архитектура объектных брокеров (общая архитектура посредников передачи запросов объектам). Термином CORBA обозначают технологию, архитектуру и набор спецификаций и стандартов промежуточного программного обеспечения (middleware) объектного типа для создания распределенных программных приложений. Автором архитектуры CORBA является консорциум Object Management Group.
CORBA состоит из 4 основных частей.

  • Object Request Broker - брокер (посредник) объектных запросов, является ядром архитектуры CORBA. Это объектная шина, по которой происходит взаимодействие локальных и удаленных объектов. Помимо самого вызова метода удаленного объекта, ORB отвечает за поиск реализации объекта, его подготовку к получению и обработке запроса, передачу запроса и доставку результатов клиенту.
  • Object Services - объектные сервисы, реализации объектов, предоставляющие общие для объектно-ориентированной среды возможности: служба имен, служба событий, служба сохранения в долговременной памяти, служба транзакций и так далее.
  • Common Facilities - общие средства, это реализации объектов, необходимые для большого числа приложений, например, поддержка составных документов, потоков заданий и так далее.
  • Application и Domain Interfaces - прикладные и отраслевые интерфейсы. Прикладные объекты представляют собой реализации объектов для конкретных пользовательских приложений. В CORBA есть также понятие домена. Реализации объектов домена (CORBA domains) предназначены для приложений с вертикальной организацией.

В CORBA интерфейс объекта задается с помощью языка описания интерфейсов (Interface Definition Language, IDL). Тип объекта - это тип его интерфейса. Интерфейс идентифицируется именем, представленным цепочкой символов. В модели CORBA определен базовый тип для всех объектов - CORBA::Object. Объект поддерживает тип своего непосредственного интерфейса и по принципу наследования все его базовые типы.
CORBA IDL задает определения, которые могут отображаться в множество различных языков, не требуя при этом никаких изменений от целевого языка. Эти отображения реализуются компилятором IDL.
CORBA вводит понятие объектной ссылки (object reference), которая уникальным образом идентифицирует объект в сети.
Механизм долговременного хранения, то есть сохранения состояния объекта в долговременной памяти для дальнейшей его реактивации, в CORBA абсолютно прозрачен для клиента.
Наиболее распространенные службы CORBA - службы именования, управления жизненным циклом и событиями.
CORBA поддерживает интерфейс динамического вызова DII (Dynamic Invocation Interface).
В CORBA изначально была заложена многоплатформенность и поддержка множества популярных языков программирования без необходимости каких-либо изменений в них.

Объектная архитектура распределенных систем. Понятие о технологии EJB.

Свойства архитекутуры Enterprise JavaBeans.

  • Является стандартной компонентной архитектурой для построения распределённых объектно-ориентированных бизнес-приложений на языке Java.
  • Построение распределённых приложений путём комбинирования компонентов, разработанных для различных платформ и операционных систем.
  • Скрытие деталей реализации: разработчикам нет необходимости знать и понимать нижние уровни системы.
  • Отражает все аспекты жизненного цикла программного обеспечения.
  • Совместима с CORBA-протоколами

    Компоненты EJB (The Enterprise JavaBeans component) выполняются внутри EJB-контейнера (The Enterprise JavaBeans container), который, в свою очередь, выполняется внутри EJB-сервера. Любой сервер, который в состоянии поддерживать EJB-контейнеры и предоставлять им необходимые сервисы, может быть EJB-сервером. EJB-компонент представляет из себя Java-класс, который реализует некую бизнес-логику. Все остальные классы в EJB-системе либо реализуют поддержку клиент / сервер взаимодействий между компонентами, либо реализуют некие сервисы для компонентов.
    Компонент EJB определяется как комбинация трёх составных элементов и описания его установки и применения:
  • home-интерфейс, home-объект,
  • remote-интерфейс, объект EJB - реализация remote-интерфейса (EJBObject),
  • Непосредственно реализация Enterprise Bean - это код реализации бизнес-логики.
  • Описание установки EJB и его применения.
    EJB-контейнер реализует для находящихся в нем компонентов такие сервисы, как транзакции (transaction), управление ресурсами, управление версиями компонентов, их мобильностью, настраиваемостью, мобильностью, жизненным циклом. Разработчик EJB-компонента может просто вызывать соответствующие методы у контейнера.
    Клиентские приложения вызывают методы на удаленных EJB-компонентах через EJB-объект (EJB-object). EJB-объект реализует "удаленный интерфейс" (remote interface) EJB-компонента на сервере. EJB-объект реализует лишь бизнес-интерфейс для EJB-компонента, являясь, в некотором смысле, "промежуточным" звеном между клиентом и EJB-компонентом.
    EJB-объекты и EJB-компоненты представляют собой разные классы. Хотя они реализуют один и тот же интерфейс (интерфейс, описанный для EJB-компонента), но при этом они выполняют совершенно разные функции. EJB-компонент выполняется на сервере, внутри EJB-контейнера и реализует бизнес-логику, в то время как EJB-объект выполняется у клиента и удаленно вызывает методы у EJB-компонента.

Объектная архитектура распределенных систем. Понятие о технологии .NET.

Итак, под платформой Microsoft.NET следует понимать интегрированную систему (инфраструктуру) средств разработки, развертывания и выполнения сложных, распределенных программных систем.

  • Операционные системы корпорации Microsoft - Windows 2000/XP/ME/CE, представляют собой базовый уровень платформы MS.Net.
  • .Net Enterprise Servers являются программными продуктами, использование которых позволяет снизить сложность разработки сложных программных систем (SQL Server).
  • .Net Building Block Services) представляют собой готовые "строительные блоки" сложных программных систем, которые могут быть использованы через Интернет как сервисные услуги. Набор таких сервисов MS.Net планируется последовательно расширять.
  • Интегрированная среда разработки приложений Visual Studio.NET (VS.Net) - верхний уровень MS.Net - обеспечивает возможность создания сложного ПО на основе платформы Windows.
  • MS.NET Framework является ядром платформы MS.Net, обеспечивая возможность построения и исполнения .Net приложений.


Здесь набор базовых классов обеспечивает, например, работу со строками, ввод-вывод данных, многопоточность. Набор классов для работы с данными предоставляют возможность использования SQL-запросов, ADO.Net и обработки XML данных и так далее.
Общеязыковая среда выполнения (Common Language Runtime, CLR) активизирует исполняемый код, выполняет для него проверку безопасности, располагает этот код в памяти и исполняет его, обеспечивает сборку мусора. Для обеспечения возможности многоязыковой разработки ПО программный код, получаемого после компиляции программы на одном из алгоритмических языков платформы MS.Net, представляется на общем промежуточном языке (Common Intermediate Language или CIL). Сборки (файлы на CIL) перед своим исполнением с помощью JIT-компилятора (Just-In-Time compilers) переводятся с программного кода на промежуточном языке (CIL-кода) в машинный (native) код платформы исполнения.

Объектная архитектура распределенных систем. Общие черты технологий CORBA и (D)COM(+).

  • Предназначены для разработки сложных распределенных систем.
  • Независимость от физического размещения объектов.
  • Независимость от платформы (ОС).
  • Независимость от языка программирования.
  • COM и CORBA реализованы на базе абстрактного интерфейса, то есть языка, который реализует доступ к узлу.
  • Объекты взаимодействуют друг с другом с помощью вызовов удаленных процедур (RPC, remote procedure call).
  • Используются объекты, расположенные в адресных пространствах клиента и сервера и обменивающиеся данными между собой.
  • Клиент и сервер взаимодействуют между собой с помощью marshalling, представляющего собой обмен данными (передаваемые данные упаковываются в так называемый marshalling packet и распаковываются после передачи в другое адресное пространство) и передачу указателей на интерфейсы и аргументы функций между этими объектами.

Объектные модели CORBA и COM. Основные различия.

  • Тип объектов CORBA - типы его интерфейсов. В COM объект - это экземпляр класса. Базовый тип CORBA - CORBA::Object. Базовый тип COM - IUnknown.
  • CORBA поддерживает множественное наследование. Один объект может иметь несколько интерфейсов. В COM каждый объект может иметь один интерфейс. В COM+ введено множественное наследование.
  • В CORBA используется идентификация, в COM нет явной идентификации.
  • В CORBA активация, сохранение и деактивация осуществляются неявно. В COM эти операции нужно выполнять явно.
  • Язык описания интерфейса. В CORBA используется IDL (Interface Definition Language, язык описания интерфейсов). IDL - языковая среда без детальной реализации, напоминает C++, является компилируемым языком, поддерживает связь по данным с Delphi, Ada, Java, C++, Cobol и так далее. IDL базируется на динамических вызовах удаленных процедур. В COM используется MIDL (Microsoft IDL). Язык MIDL привязан к платформе, является компилируемым языком, осуществляет поддержку связей c MJava, Visual C / C++, VB, используется в DLL.
  • Отличаются структурой внутренних объектов (служб). CORBA: жизненный цикл, сохранение, контроль за доступом, защита, служба коллекции, импорт, экспорт, программируемые транзакции. COM: жизненный цикл, защита, информация о типах, передача данных, регистрация, асинхронное взаимодействие, битые пакеты не анализируются. СОМ-объекты можно создавать прямым вызовом специальных функций, но напрямую уничтожить его невозможно. Вместо прямого уничтожения используется механизм самоуничтожения, основанный на подсчете ссылок. В COM используется сервер транзакций.
  • Платформы CORBA: DOS, Windows 3.11, Windows 98, Windows NT, OS / 2, Unix, Solaris. Платформы COM: Windows 2000, Windows XP, Windows 9x и Windows NT, OpenVMS, Solaris.

Идентификация объектов CORBA и COM в сети. Основные различия.

CORBA и СОМ абсолютно по-разному подходят к проблемам идентификации (identity) объектов и их сохранения в долговременной памяти (persistance). CORBA вводит понятие объектной ссылки (object reference), которая уникальным образом идентифицирует объект в сети. Тем самым экземпляру объекта дается право на существование в течение некоторого времени. Объекты могут активироваться, сохраняться в долговременную память, позже вновь реактивироваться и деактивироваться, и при этом объектная ссылка будет указывать все время на одно и то же конкретное воплощение объекта. Для объектов, предназначенных для длительного использования, объектные ссылки могут интегрироваться со службой каталогов или службой имен. Клиент не имеет никаких легальных средств обнаружить, куда и каким образом сохраняется экземпляр объекта. Служба именования Interoperable Naming Service предназначена для прозрачного поиска и вызова объектов, не зависящего от конкретной реализации ORB.
В СОМ понятие объектной ссылки отсутствует. Ближайший аналог - это механизм moniker, обеспечивающий преобразование символьного имени объекта в указатель интерфейса. Этот механизм действует для тех объектов, которые сохраняются в долговременной памяти. Два же активных объекта считаются идентичными, если для них совпадают указатели на интерфейс IUknown.
Для долговременного хранения в СОМ поддерживаются две модели. Первая и изначальная модель предоставляет клиенту возможность управлять хранением объекта. Другой, более поздний вариант сохранения в долговременную память в СОМ предусматривает использование Microsoft Transaction Server (MTS), который обеспечивает управление хранением со стороны сервера.

Языки описания интерфейсов CORBA и COM. Основные свойства.

В CORBA язык описания интерфейсов - важнейшая часть архитектуры, основа схемы интеграции объектов. Все интерфейсы и типы данных определяются на IDL. Различные языки программирования поддерживаются благодаря заданным отображениям между описаниями типов данных на IDL в соответствующие определения на конкретном языке. CORBA IDL задает определения, которые могут отображаться в множество различных языков, не требуя при этом никаких изменений от целевого языка. Эти отображения реализуются компилятором IDL, который генерирует исходные коды на нужном языке. В настоящий момент поддерживается отображение в C, C++, SmallTalk, Ada, Delphi, Visual Basic, Cobol и Java. Сам IDL синтаксически напоминает декларации типов в Си++, но не идентичен этому языку.
В Microsoft IDL (MIDL) - лишь один из возможных способов определения интерфейсов объекта. Технология COM реализует интеграцию на двоичном уровне, поэтому все спецификации и стандарты, относящиеся к уровню исходных текстов компонентов, являются вспомогательными и не оказывают решающего влияния на общую архитектуру системы. Язык MIDL привязан к платформе.
MIDL, являющийся расширением DCE RPC IDL, не определяет общего набора типов данных, доступных различным языкам программирования. На MIDL можно определить интерфейсы и типы данных, которые соответствуют программам на C, C++, Visual Basic, Java.

Основные встроенные объектные службы CORBA и COM.

Службы COM:

  • защита (security),
  • управление жизненным циклом (lifecycle managemеnt),
  • информация о типах (type information),
  • именование (naming),
  • доступ к базам данных (database access),
  • передача данных (data transfer),
  • регистрация (registry),
  • асинхронное взаимодействие.

Службы CORBA (16):

  • именование (naming),
  • события (events),
  • жизненный цикл (life cycle),
  • долговременное хранение объектов (persistent),
  • транзакции (transactions),
  • контроль за доступом к разделяемым ресурсам (concurrency control),
  • отношения (relationsips),
  • импорт / экспорт (externalization),
  • запросы (query),
  • лицензирование (licensing),
  • свойства (property),
  • время (time),
  • защита (security),
  • переговоры между объектами (object trader),
  • сбор объектов (object collections),
  • служба асинхронного обмена сообщениями (asynchronous messaging).

Операционные среды функционирования CORBA и COM. Выводы сравнительного анализа двух технологий.

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