Добавлен: 28.03.2023
Просмотров: 103
Скачиваний: 2
СОДЕРЖАНИЕ
глава 1. ОБ ОСНОВАХ стандарта corba
История возникновения стандарта Сorba
глава 2. ОБ обзоре архитектуры и специфики corba
2.1 Архитектура распределенных объектов Corba
2.2. Сервисы CORBA как основные объектные службы
2.3. Универсальные средства CORBA
ГЛАВА 3. О ДОСТОИСТВАХ И НЕДОСТАТКАХ ТЕХНОЛОГИИ
3.1. Минусы и критика в отношении Corba
Под объектным брокером понимается коммуникационный прозрачный механизм, посредством которого осуществляется обмен сообщениями между объектами вне зависимости от их места расположения.
Существующие в Corba брокеры объектных запросов играют в ОМА основную роль и реализуются одним из способов, при этом, для клиента и серванта средства реализации совершенно не имеют никакого значения:
- в виде библиотек – используется клиентом;
- в виде процессов-демонов – используется сервером.
Концепции Corba касаются объектных адаптеров (объектов), располагающихся между клиентом и сервером, для управления доступом к распределенному объекту. Объектным адаптером до появления Corba 3.0 являлся базовый объектный адаптер (Basic Object Adapter – BOA), который упрощал соединение клиента и сервера. С появлением Corba 3.0 был определен адаптер РОА – переносимый объектный адаптер, заменивший предыдущий ВОА, который не соответствовал основным требованиям, которые предъявляются к Интернет-приложениям.
Изначально архитектура CORBA допускала передачу при вызове удаленных методов только примитивных типов данных или удаленных ссылок. Теперь же IDL-определение включает в себя предложения Objects-by-Value («объект по значению»), благодаря чему можно передавать состояние объектов и поведение так, как это делается с помощью RMI. Активное использование этой возможности и поддержки соответствия Java-to-IDL позволяет Java-программистам разрабатывать приложения на базе CORBA, даже не изучая IDL. Разработчик может указать интерфейсы средствами Java.
Новый компилятор rmic, включенный в состав JDK 1.3, может создавать суррогаты, скелетоны и связи CORBA непосредственно из определений интерфейса в терминах Java. Кроме того, чтобы создать службы или клиенов на других языках программирования, можно генерировать IDL-определение автоматически и использовать его как входную информацию для других компиляторов [4, стр. 1].
2.2. Сервисы CORBA как основные объектные службы
Сервисы CORBA (CORBA services) – являются базовыми сервисами, которые доступны всем объектам, подключенным к коммуникационной шине данного брокера объектных запросов. Так как брокер объектных запросов — это ядро системы Corba, то его наличие может требоваться сервисам для правильного функционирования.
Всего существует шестнадцать сервисов:
- сервис имен (Naming Service);
- сервис управления событиями (Event Management Service);
- сервис жизненных циклов (Life Cycle Service);
- сервис устойчивых состояний (Persistent State Service);
- сервис транзакций (Transaction Service);
- сервис параллельного исполнения (Concurrency Service);
- сервис взаимоотношений (Relationship Service);
- сервис экспорта (Externalization Service);
- сервис запросов (Query Service);
- сервис лицензирования (Licensing Service);
- сервис управления ресурсами (Property Service);
- сервис времени (Time Service);
- сервис безопасности (Security Service);
- сервис уведомлений (Notification Service);
- сервис трейдинга (Trader Service);
- сервис коллекций (Collections Service).
Трехуровневая архитектура информационных систем, согласно спецификациям OMG, включает в себя системы управления данными, сети взаимодействующих Corba-объектов и пользовательские интерфейсы для представления данных [5, стр.25].
В книге «Основы Corba» известного американского автора Роберта Орфали в полной мере описываются все сервисы.
Благодаря сервису Жизненного Цикла (Life Cycle Service) определяются операции создания, копирования, перемещения и удаления компонентов на шине.
Сервис Именования (Naming service) дает возможность для управления и хранения ссылок на объекты Corba. Его основной задачей является организация организовать соединение объектов друг с другом универсальным образом, при этом служба имен представляет собой хранилище объектных ссылок. Обращение к этому сервису выполняется для получения нужной объектной ссылки, идентифицируемой по читаемому (понятному разработчику) имени объекта [5, стр. 27].
Сервисом Событий (Event service) обеспечивается поддержка асинхронного взаимодействия приложений.
Сервис Долговременного Хранения (Persistence service) предоставляется как набор универсальных интерфейсов, который дает возможность сохранения экземпляров объектов в долговременной памяти. Сервис разработан так, что его реализация возможна на основе объектной базы данных.
Сервис Транзакций (Transaction service) поддерживает множество моделей транзакций, включая вложенные транзакции. Сервис транзакций необходим для корректной работы приложений в многопользовательском режиме [5, стр.28].
Сервис Отношений (Relationship service) реализует логические связи между объектами Corba. Сервис определяет два дополнительных типа объектов: связь и роль. Роль представляет собой Corba-объект, отражающий характер связи, а связь характеризует зависимости объектов прикладной области.
Сервис Контроля Совместного Доступа (Concurrency control service) позволяет клиентам координировать свои действия при использовании разделяемых ресурсов. Управление разделяемыми ресурсами осуществляется с помощью блокировок. Каждая блокировка ассоциируется с единственным ресурсом и единственным клиентом. Сервис определяет также несколько режимов блокировок, которые соответствуют различным способам доступа.
Сервис Внешнего Представления (Externalization service) формирует копию CORBA-объекта в виде некоторого внешнего представления - файла, элемента базы данных и т. д. [5, стр. 28].
Сервис Запросов (Query Sevice) обеспечивает поддержку запросов для объектов. Он представляет собой надмножество SQL и основан на расширенных спецификациях SQL3 и языке объектных запросов (Object Query Language - OQL).
Сервис Лицензирования (Licensing Service) предоставляет операции для отслеживания использования компонентов, чтобы обеспечить законную компенсацию их использования. Данный сервис поддерживает некоторую модель использования компонента в любой точке его жизненного цикла.
Сервис Свойств (Properties Service) предоставляет операции, которые позволяют вам ассоциировать именованные величины (или свойства) с любым компонентом.
Сервис Времени (Time Service) предоставляет интерфейс для синхронизации времени в среде распределенных объектов. Кроме того, предусматривает операции для определения и управления событиями, ориентированными на определенное время.
Сервис Безопасности (Security Sercice) предоставляет полную инфраструктуру для обеспечения безопасности распределенных объектов. Он поддерживает аутентификацию, списки контроля доступа, конфиденциальность, безотказность и делегирования прав доступа между объектами.
Сервис Коммерции (Trade Service) обеспечивает «Желтые страницы» для объектов; это дает возможность объектам оповещать о своих сервисах и выставлять заявки о себе на «рынок труда».
Сервис Контейнеров (Collection Service) предоставляет интерфейсы CORBA для создания и поддержки общедоступных контейнеров [5, стр. 27].
Известным фактом является то, что службы OMG не являются независимыми друг от друга. Часть этих служб создается на базе иных служб.
2.3. Универсальные средства CORBA
Универсальные средства разделяются на два типа: горизонтальные и вертикальные, их назначение - предоставление поддержки интерфейсов высокого уровня.
Горизонтальные универсальные средства определяют интерфейсы, которые не зависят от предметной области. В данное горизонтальные универсальные средства разделяются по спецификации и состоят из следующих разделов:
1) Средства пользовательского интерфейса, покрывающие аспекты, которые касаются предоставления информации и включают в себя инструменты, позволяющие производить разработку интерфейсов. Кроме того, они состоят из средств для автоматизации этой работы, спецификации на рабочий стол (desktop) пользователя и т.д.
2) Средства управления информацией, представляющие операции, при помощи которой существует возможность моделирования, описывания, сохранения, выбора, перемещения и обмена информацией. Считается, что этот набор должен состоять из некоторого количества спецификаций:
а) информационное моделирование (определяет правила, по которым осуществляется структуризация и доступ к информации),
б) хранение и выборка информации (определяет использование баз данных и систем каталогов),
в) информационный обмен,
г) стандарты перекодировки и представления, поддерживающие обмен информацией через разделяемые ресурсы, сетевые протоколы или программные интерфейсы.
3) Средства управления системой, задающие множество утилит, которые реализуют функции системного администрирования, то есть определяют интерфейсы основных операций, отвечающих за управление, мониторинг, безопасность, конфигурирование и т. д.
4) Средства управления задачами. Предполагается, что данный набор будет представлен четырьмя спецификациями: службы управления потоками работ (workflow facility), службы программных агентов (agent facility), службы управления правилами (rule management facility), службы автоматизации (automation facility).
Вертикальные средства предназначены для поддержки конкретных областей рынка: финансовой деятельности, промышленного производства, медицины и т. д. Разрабатываются спецификации следующих средств:
1) Средств обработки изображений. Специфицируют доступ и обмен графическими данными. Роль этой службы заключается в поддержке приложений конечного пользователя по проверке, обработке, визуализации и сохранению графических данных.
2) Средств поддержки информационной супермагистрали (superhighway facility). Специфицируется множество сетей, протоколов и правил их использования, а также множество репозитариев информации и набор средств, обеспечивающих пользователям и приложениям доступ к этой информации.
3) Средств интегрированного автоматизированного производства. Обеспечивают интеграцию производственных функций предприятия с помощью компьютеров. В число объединяемых функций могут входить также управление процессами разработки, контроль качества, финансовые и маркетинговые операции.
4) Средства эмуляции распределенных процессов. Службы этой спецификации должны обеспечить базис, на основе которого возможно быстрое построение и функционирование эмулируемой модели.
5) Средства информатизации в газовой и нефтяной промышленности. Эта предметная область характеризуется большим количеством данных и высокой сложностью алгоритмов.
6) Средства финансовых коммуникаций (accounting facility), включающие в себя все формы коммерческих транзакций, таких как: обмен валют, управление платежами, продажи и т.п.
7) Средства поддержки разработки приложений, обслуживающие выбор, разработку, построение и эволюцию приложений, составляющих корпоративную информационную систему. Эти спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы [5].
ГЛАВА 3. О ДОСТОИСТВАХ И НЕДОСТАТКАХ ТЕХНОЛОГИИ
3.1. Минусы и критика в отношении Corba
Несмотря на то, что Corba давала большое количество обещаний в отношении кодирования и сборки программного обеспечения, она в результате подвергается большому количеству критики.
Некоторые из сбоев связаны с процессом внедрения, которые возникли в связи с бизнес-политикой при внедрении стандартизированного программного обеспечения, которые в дальнейшем привели к отказу от использования Corba в новых проектах и областях.
Следующая из проблем заключалась с тем, что исходная спецификация определяла только IDL, а не взаимодействовала с другими языками. В дальнейшем эта проблема была решена.
Одним из источников критики являлась прозрачность, которая была связана с тем фактором, что объекты, которые находятся в одном и том же адресном пространстве и доступны посредством простого вызова функции, рассматриваются как объекты, находящиеся в любом месте распределенной системы. Это делало локальный доступ сложным.
Недостатки в дизайне также предавались критическому анализу. Спецификация считалась очень сложной, дорогой в реализации и зачастую неоднозначной.
На протяжении многих лет спецификация Corba страдала от недостатков в реализации, которые включали в себя критические элементы спецификаций, а существующие реализации были неполными и недостаточными.