Система CORBA и средства описания объектов и компонентов

Архитектура CORBA (Common Object Request Broker Architecture) предоставляет распределенный обмен данных с помощью специальных объектов–брокеров ORB (Object Request Broker), применяется для обработки запросов. Эта технология позволяет прикладной программе запрашивать сервисы другой программы, вызывая методы ее удаленных объектов. Для реализации взаимодействия объекта–брокера и программы (клиента и сервиса) используется язык интерфейса IDL (Interface Definition Language). JAVA включает ORB и компилятор idltojava, который генерирует код по IDL спецификациям [8 –10].

Работа в системе CORBA сводится к генерации JAVA файлов на основе IDL файла интерфейса для стороны сервера или для стороны клиента или для обеих. Со стороны клиента требуется специфическая IOR форма (Interoperable Object Reference), которая поддерживает именование сервера. CORBA использует браузер для просмотра имен сервисов, генерации кода и вставки его в файл класса клиента. Со стороны сервера дополняется код, который связывает экземпляры сервентов с именами сервисов. Браузер может сгенерировать этот код и вставить его в файл класса сервера. IDL файл компилируется и полученная программа запускается для выполнения.

В системе CORBA имеются следующие шаблоны интеграции компонентов:

– Client class для вызова метода, который будет выполнен сервером.

– Stub class для конвертации метода, инициирующего работу клиента в Wire формате, используемом при связывании в сети на стороне клиента;

– ORB class управляет методами передачи данных и вызовами методов между процессами;

– Implementation class содержит деловую логику сервера, экземпляр этого класса сервент регистрируется в ORB и может использоваться клиентом для запуска другого процесса;

– Server class создает сервент и ссылку IOR, доступную ему, которую он записывает в стандартный выходной файл;

– Skeleton class конвертирует инициирующий метод с Wire форматом с помощью ORB брокера в формат, который может прочитать экземпляр сервента.

Для реализации ПИК типа CORBA компоненты используют как шаблон, так и мастер создания CORBA компонентов. Система CORBA предлагает шаблоны для создания и реинженерии компонентов.

Шаблон поддержки работы адаптера POA (Portable Object Adapter) является корнем каждой иерархии серверов и доступен разным ORB. Адаптер порождает следующие типы объектов: пустой сервер (Empty), основной класс сервер (ServerMain), класс клиент (ClientMain) и простой Simple (сервер с минимальными инициированными элементами).

При использовании мастера инициализации CORBA компонентов пользователь должен использовать три параметра (value, title, type), каждый из которых задается переменной строкового типа, значения которого понимает мастер. Например:

<server– binding name = ‘Proprietary Binder’ template–tag = ‘SERVER_BINDING’>

<wizard requires–value = ‘/* FFJ_COBRA_TODO_SERVER_NAME*/’

title = ‘Server name:’ type = ‘string’/>

Сервлет – это небольшая программа, которая выполняется на серверной стороне WEB, расширяет функциональные возможности WEB сервера, облегчает доступ к ресурсам и разрешает процессу читать данные из HTTP, запрашивать WEB–сервер и записывать данные из сервера в http, как ответ. Они выполняются в границах адресного пространства WEB–сервера. Сервлеты – альтернатива CGI (Common Gateway Interface), которые базируются на взаимодействии процесса запроса клиента с WEB–сервером. CGI программы разрабатываются на разных ЯП и являются необходимыми при создании отдельного процесса обработки каждого запроса клиента. Сервлеты не требуют больших ресурсов памяти и процессора, описываются на языке JAVA независимо от платформы, размещаются в разных средах и используют библиотеку классов JAVA для получения параметров инициализации, активизации и регистрации событий, а также для доступа к информации и формирования ответа клиенту.

Создание сервлетов в языке Java осуществляется с помощью инструментария Servlet Development Kit (JSDK) с применением следующих шаблонов создания и интеграции:

– WebModule – элемент WEB ресурса, который может разворачиваться в прикладной программе для поддержки функционирования сервлета, использует спецификации сервлетов и серверных страниц. Может содержать в себе файлы с Java классами, которые поддерживают сервлети, beans компоненты с тем же назначением, страницы сервера, статические HTML документы и аплеты;

– WebModuleGroup – шаблон для создания группы взаимодействующих WebModule на WEB сервере и поддержки создания сервлетов.

– Servlet;

– HTML File.

Методы спецификации компонентов. Спецификация – это описание компонента и способа вызова компонентов из другой среды, или из электронной библиотеки, или репозитария. Спецификация включает интерфейс, контракт и нефункциональные свойства.

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

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

Каждый интерфейс состоит из набора операций (сервисов, которые он предлагает или требует). С каждой операцией связанный набор пред–условия и пост–условия, зависящие от состояния, которое получает компонент. Контракты и интерфейс связаны между собою, но наполняются по–разному. Интерфейс отражает функциональные свойства и состоит из набора операций для спецификации сервисов, а контракт отражает семантику и описание поведения компонента, зависящее от взаимодействия с другими компонентами.

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

Наши рекомендации