
- •Api как средство интеграции приложений
- •Сигнатура функции
- •Семантика функции
- •Api операционных систем. Проблемы, связанные с многообразием api
- •Наиболее известные api
- •История com
- •[Править]Путаница в названиях
- •Принципы работы com
- •Технологии, основанные на стандарте com
- •Net и будущее com
- •Dcom через интернет и решение проблемы xp sp2
- •Критика
- •Литература
- •Назначение corba
- •Общий обзор
- •Ключевые понятия технологии Объекты по значению
- •Компонентная модель corba (ccm)
- •Общий протокол межброкерного взаимодействия (giop)
- •Ссылка на объект (Corba Location)
- •Список брокеров (corba orBs)
- •Объектный rpc
- •Технология
- •См. Также
- •Стандарты
- •Назначение
- •Инструментарий
- •Уровни управления
- •Возможные области применения opc-серверов в асу предприятия
- •Состояние дел
- •Перспективы
- •Заключение
- •Список популярных opc-серверов
Литература
Роберт Дж. Оберг Технология COM+. Основы и программирование = Understanding and Programming COM+: A Practical Guide to Windows 2000 First Edition. — М.: «Вильямс», 2000. — С. 480. — ISBN 0-13-023114-2
4.CORBA – Common Object Request Broker Architecture
CORBA (обычно произносится [ко́рба], иногда жарг. [ко́бра]; англ. Common Object Request Broker Architecture — общая архитектура брокера объектных запросов) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология.
Назначение corba
Технология CORBA создана для поддержки разработки и развёртывания сложных объектно-ориентированных прикладных систем.
CORBA является механизмом в программном обеспечении для осуществления интеграции изолированных систем, который даёт возможность программам, написанным на разныхязыках программирования, работающих в разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса.
Общий обзор
Спецификация CORBA предписывает объединение программного кода в объект, который должен содержать информацию о функциональности кода и интерфейсах доступа. Готовые объекты могут вызываться из других программ (или объектов спецификации CORBA), расположенных в сети.
Спецификация CORBA использует язык описания интерфейсов (OMG IDL) для определения интерфейсов взаимодействия объектов с внешним миром, она описывает правила отображения из IDL в язык, используемый разработчиком CORBA-объекта.
Стандартизованы отображения для Ада, Си, C++, Лисп, Smalltalk, Java, Кобол, Object Pascal, ПЛ/1 и Python. Также существуют нестандартные отображения на языки Perl, Visual Basic,Ruby и Tcl, реализованные средствами ORB, написанными для этих языков.
Ключевые понятия технологии Объекты по значению
Помимо удалённых объектов в CORBA 3.0 определено понятие объект по значению. Код методов таких объектов по умолчанию выполняется локально. Если объект по значению был получен с удалённой стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base — список URL, откуда может быть загружен код.
У объекта по значению могут также быть и удалённые методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь также могут быть такими объектами, формируя таким образом списки, деревья или произвольные графы. Объекты по значению могут иметь иерархию классов, включая абстрактные и множественное наследование.
Компонентная модель corba (ccm)
Компонентная модель CORBA (CCM) — недавнее дополнение к семейству определений CORBA.
CCM была введена начиная с CORBA 3.0 и описывает стандартный каркас приложения для компонент CORBA. CCM построено под сильным влиянием Enterprise JavaBeans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы, порты.
Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.