Добавлен: 12.03.2024
Просмотров: 23
Скачиваний: 0
С целью же обеспечения централизованного сбора и управления всевозможной информацией, ORB может быть реализован в виде отдельного приложения. Взаимодействующие приложения устанавливают контакт с ORB-ом посредством нормальных механизмов IPC.
ORB как часть системы.
Для увеличения надежности, защиты данных и достижения лучшей производительности ORB может быть выполнен как часть операционной системы. При этом сами ссылки на объект могут быть сделаны постоянными, следовательно, уменьшая время, необходимое для обработки каждого запроса. При реализации, ORB-а как части операционной системы возможны всевозможные виды оптимизации, такие как избежание кодирования и декодирования данных, если клиент и сервер находятся на одной и той же машине.
ORB, основанный на библиотеках.
Когда код объекта занимает небольшой объем и не требует никаких дополнительных средств, то он может быть выполнен в виде библиотеки. При этом все заглушки в самом деле будут являться настоящими методами. При этом предполагается, что, имея доступ к данным реализации, клиент не разрушит эти данные.
ГЛАВА 2. ТЕХНОЛОГИЯ CORBA
2.1 Объединение компонентов
CORBA достигла замечательных успехов, как технология, которая обеспечивает базовые структуры для взаимодействия разнородных объектов, и это при том, что она представляет собой только часть еще более крупной архитектуры управления объектами (ObjectManagementArchitecture, OMA), которая состоит из следующих компонентов:
CORBA ORB оперирует запросами между объектами; Службы (сервисы) CORBA определяют служебные функции системного уровня, которые предназначены для управления объектами и обеспечения их работы; Средства CORBA определяют функциональные возможности и интерфейсы на уровне прикладной программы; Объекты прикладных программ собственно объекты. Как уже говорилось, брокер объектных запросов управляет обменом запросами между объектами. Но как же все остальные кусочки этого разнообразия сложить воедино. Для этого рассмотрим службы, средства и объекты CORBA.
2.2 Службы объектов CORBA
Содействие в организации управления и обеспечения работоспособности объектов на протяжении их жизненных циклов именно этим заняты службы CORBA. Интерфейсы этих служб пригодятся вам для создания объектов обеспечения их безопасности, определения местоположения объектов и управления объектами на уровне классов. А так как это службы системного, а не прикладного уровня, то их можно реализовать для всего предприятия, то есть сэкономить свое время и облегчить согласованность в масштабах предприятия.
Есть 16 объектных служб, это такие как:
Collection Properties
Сoncurrency Сontrol
Query Eventnoti fication
Nships Externalization Security
Licensing Startup
Lifecycle Time
Naming Trader
Persistence Transactions
Реальные объекты, образующие ядро совместимой с CORBA прикладной программы, называются бизнес-объектами. Бизнес-объект - это такой способ описания понятий, который не зависит от прикладной программы, типа покупатель, заказ или платеж. Для подготовки прикладной программы нам будет необходим набор бизнес-объектов. В отличие от объектов системного уровня, которые исполняют такие задачи, как поддержание устойчивости, бизнес-объекты имеют дело с процессами, которые характерны для реального делового мира. Хотя типичный бизнес-объект несет ответственность только за одну задачу (например, обработку предварительных заказов, работу с покупателями или складом), а наборы бизнес-объектов можно применять и для управления всем бизнес-процессом, таким, как продажа билетов и обработка предварительных заказов на авиарейсы. Поскольку бизнес-объекты доставляются в готовом к работе виде, разработчик может, объединив их, составить прикладную программу, которая соответствует требованиям заказчика. Для управления сложной прикладной программой с распределенными бизнес-объектами у последних есть информация только лишь о том, какие сервисные функции выполняют другие объекты, но не о том, как эти функции реализуются на самом деле. Благодаря бизнес-объектам мы освобождены от сложностей реализации внутренней обработки, так как сможем сконцентрировать внимание на интерфейсах.
Компонент - это набор бизнес-объектов, с помощью которых осуществляется обработка, инкапсулируются данные и обеспечиваются необходимые интерфейсы пользователя. Для взаимодействия объектов в рамках компонента используется ORB. Кроме того, с помощью ORB объекты обмениваются информацией о себе, в результате чего объекты "узнают" о существовании других объектов во время исполнения программы. Следовательно, в компоненте имеется все необходимое для вывода на экран представления объекта и взаимодействия с ним. Типичный бизнес-компонент мог бы применяться, к примеру сказать, для вывода на экран распределения мест на 11-часовом рейсе до Чикаго, а другой для регистрации сведений о бронировании мест на этот же рейс. Возможности компонентов можно расширить и за счет добавления служебных функций системного уровня. Функция Persistence пригодится, для того чтобы поддерживать состояние объектов в рамках компонента.
Ибо эти сервисные функции встроены в CORBA, то их можно применять для создания "интеллектуальных" (smart) компонентов, и при этом нет необходимости программировать их с нуля. Хотя и в DCOM имеется реестр компонентов и справочная служба, зато там нет способа поддерживать состояние объектов DCOM в перерыве между соединениями. Из-за этого недостатка DCOM уступает CORBA. На уровне прикладной программы, где устанавливаются границы инфраструктуры компонентов, с помощью базовых структур программ определяются способы реализации совместной деятельности независимых компонентов. Благодаря четко определенным границам все компоненты вместе функционируют как единый комплекс, так что создается впечатление единства прикладной программы. Именно вот такое единство и позволяет прикладным программам, использующим распределенные в гетерогенных средах объекты, "прозрачно" сопрягаться друг с другом. "Прозрачная" интеграция означает, что пользователи воспринимают прикладную программу как единое целое, а не как сложный набор разобщенных модулей. Инфраструктуру компонента одной прикладной программы можно увеличить до инфраструктуры компонента нескольких программ. В таком случае CORBA несет ответственность за обмен информацией между множеством различных прикладных программ в рамках корпоративной системы. Для несовместимых с CORBA программ, к примеру, доставшихся в наследство приложений, можно создать оболочки (wrappers), которые придают им сходство объектов CORBA. Оболочка выполняет роль интерфейса, необходимого для доступа к конкретным функциям старой программы. Если мы с помощью CORBA интегрировали унаследованные программы с процессами клиента и сервера, у нас есть все составляющие многоуровневой модели клиент сервер. Один уровень - это визуальные объекты, в частности интерфейсы, размещаемые на клиентских ПК. Другой уровень объекты сервера, предусматривающие бизнес-функции. Еще один уровень составляют унаследованные прикладные программы, в частности, СУБД на большой ЭВМ.
Чтобы показать, почему CORBA ORB так хороши для ППО архитектуры клиент сервер, мы приводим вытекающий «краткий» список замечательных свойств, присущих всем ORB:
Статические и динамические вызовы методов. CORBA ORB позволяет статически определять вызовы ваших методов во время компиляции или находить их динамически во время выполнения. Следственно, нам предоставляется выбор: строгий контроль типов на стадии компиляции или максимальная гибкость при отложенном (на этапе выполнения) связывании.
Связывание с языком высокого уровня. CORBA ORB дозволяет вызывать методы серверного объекта с помощью выбранного нами языка высокого уровня. При этом не имеет значения на каком языке написаны серверные объекты. CORBA отделяет интерфейс от его реализации и предоставляет независимые от языка типы данных, что дает возможность вызывать объекты из любого языка и для любой операционной системы. Напротив, другие типы промежуточного программного обеспечения обычно предоставляют низко-уровневые API-библиотеки для определенного языка. Кроме того, они не отделяют реализацию от спецификации и, как следствие, API тесно связан с реализацией, что делает интерфейс очень чувствительным к изменениям.
2.3 Универсальные средства CORBA
Универсальные средства предоставляют поддержку интерфейсов высокого уровня и разделяются на два типа: горизонтальные и вертикальные.
Горизонтальные универсальные средства определяют интерфейсы, которые не зависят от предметной области. В наше время существует предварительная спецификация горизонтальных универсальных средств, которая состоит из следующих разделов:
Средств пользовательского интерфейса. Они покрывают аспекты, которые касаются представления информации, и включают инструменты для разработки интерфейса, и средства для автоматизации этой работы, и спецификации на рабочий стол (desktop) пользователя и т. д.
Средств управления информацией. Они предоставляют такие операции, с помощью которых можно моделировать, описывать, сохранять, выбирать, перемещать информацию и обмениваться ею. Планируется, что данный набор должен состоять из следующих спецификаций:
а) информационное моделирование, т.е. определяет правила, по которым осуществляется структуризация и доступ к информации,
б) хранение и выборка информации, т.е. определяет использование баз данных и систем каталогов,
в) информационный обмен,
г) стандарты перекодировки и представления, которые поддерживают обмен информацией через разделяемые ресурсы, сетевые протоколы или программные интерфейсы.
Средств управления системой. При помощи которых задают множество утилит, реализующих функции системного администрирования, то есть они определяют интерфейсы основных операций, отвечающих за управление, мониторинг, безопасность, конфигурирование и т. д.
Средств управления задачами. Предполагается, что данный набор будет представлен четырьмя спецификациями: службы управления потоками работ (workflow facility), службы программных агентов (agent facility), службы управления правилами (rule management facility), службы автоматизации (automation facility).
Вертикальные средства предназначены уже для поддержки конкретных областей рынка: финансовой деятельности, промышленного производства, медицины и т. д.
Разрабатываются спецификации следующих средств:
Средств обработки изображений. Специфицируют доступ и обмен графическими данными. Работа этой службы заключается в поддержке приложений конечного пользователя по проверке, обработке, визуализации и сохранению графических данных.
Средств поддержки информационной супермагистрали (superhighway facility). Специфицируется множество сетей, протоколов и правил их использования, а также множество репозитариев информации и набор средств, которые обеспечивают пользователям и приложениям доступ к этой информации.
Средств интегрированного автоматизированного производства. Обеспечивают интеграцию производственных функций предприятия при помощи компьютеров. В число объединяемых функций могут входить также управление процессами разработки, контроль качества, финансовые и маркетинговые операции.
Средств эмуляции распределенных процессов. Службы этой спецификации должны обеспечить базис, на основе которого возможно быстрое построение и функционирование эмулируемой модели.
Средств информатизации в газовой и нефтяной промышленности. Эта предметная область характеризуется большим количеством данных и высокой сложностью этапов последовательности.
Средств финансовых коммуникаций (accounting facility). Включают все формы коммерческих транзакций: обмен валюты, управление платежами, продажами и т.п.
Средств поддержки разработки приложений. Обслуживают выбор, разработку, построение и эволюцию приложений, которые составляют корпоративную информационную систему. Данные спецификации включают средства анализа, проектирования, реализации, тестирования и поддержки системы [10].
ЗАКЛЮЧЕНИЕ
В работе дан обзор информационной архитектуры систем на основе объектной технологии и принципов интероперабельности компонентов, развиваемых OMG. CORBA нечто большее, чем повальное увлечение, охватившее рынок. CORBA превосходит традиционную трехуровневую модель клиент сервер благодаря тому, что это полностью масштабируемая и исключительно гибкая архитектура.
