Corba имеет способы определения интерфейса объекта

6. CORBA и распределенные системы

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

Технология CORBA является механизмом для интеграции изолированных информационных систем, который даёт возможность программам, написанным на разных языках программирования и работающим на разных узлах сети, взаимодействовать друг с другом, так как если бы они находились в адресном пространстве одного процесса.

Основой технологии CORBA является ORB (Object Request Broker – брокер объектных запросов) – «объектная шина», которая позволяет передавать сообщения от одного объекта к другому. Она может быть реализована в виде библиотеки, специального сетевого сервиса, объектно-ориентированной СУБД или уже быть включенной в операционную систему. ORB дает возможность объектам, которых он обслуживает, не задумываться о том, где находятся объекты, которым передаются сообщения. Кроме того, он скрывает все детали реализации объектов, оставляя видимыми только их интерфейсы.

1 Ключевые понятия технологии CORBA

1.1 Объекты по значению

Помимо удалённых объектов в CORBA 3.0 определено понятие объект по значению. Код методов таких объектов по умолчанию выполняется локально. Если объект по значению был получен с удалённой стороны, то необходимый код должен либо быть заранее известен обеим сторонам, либо быть динамически загружен. Чтобы это было возможно, запись, определяющая такой объект, содержит поле Code Base – список URL, откуда может быть загружен код.

У объекта по значению могут также быть и удалённые методы, поля, которые передаются вместе с самим объектом. Поля, в свою очередь также могут быть такими объектами, формируя таким образом списки, деревья или произвольные графы. Объекты по значению могут иметь иерархию классов, включая абстрактные и множественное наследование.

1.2 Компонентная модель CORBA (CCM)

Компонентная модель CORBA (CCM) — дополнение к семейству определений CORBA.

CCM была введена, начиная с CORBA 3.0, и описывает стандартный каркас приложения для компонент CORBA. CCM построена под сильным влиянием Enterprise JavaBeans (EJB) и фактически является его независимым от языка расширением. CCM предоставляет абстракцию сущностей, которые могут предоставлять и получать сервисы через чётко определённые именованные интерфейсы порты.

Модель CCM предоставляет контейнер компонентов, в котором могут поставляться программные компоненты. Контейнер предоставляет набор служб, которые может использовать компонент. Эти службы включают (но не ограничены) службу уведомления, авторизации, персистентности (способности объекта существовать дольше процесса, создавшего его) и управления транзакциями. Это наиболее часто используемые распределённым приложением службы. Перенося реализацию этих сервисов от необходимости реализации самим приложением в функциональность контейнера приложения, можно значительно снизить сложность реализации собственно компонентов.

1.3 Общий протокол межброкерного взаимодействия (GIOP)

GIOP – абстрактный протокол в стандарте CORBA, обеспечивающий интероперабельность (способность к взаимодействию) брокеров. Стандарты, связанные с протоколом выпускает Object Management Group (OMG). Архитектура GIOP включает несколько конкретных протоколов:

1. Internet InterORB Protocol (IIOP) (Межброкерный протокол для Интернет) — протокол для организации взаимодействия между различными брокерами, опубликованный консорциумом OMG. IIOP используется GIOP в среде интернет, и обеспечивает отображение сообщений между GIOP и слоем TCP/IP.
2. SSL InterORB Protocol (SSLIOP) — IIOP поверх SSL (Secure Sockets Layer — уровень защищённых сокетов), поддерживает шифрование и аутентификацию.
3. HyperText InterORB Protocol (HTIOP) — IIOP поверх протокола HTTP.

1.4 Ссылка на объект (Corba Location)

CorbaLoc (англ. Corba Location) — является строковой ссылкой на объект технологии CORBA, подобной URL.
Все реализации CORBA должны поддерживать как минимум два варианта OMG URL: corbaloc: и corbaname:. Их назначение в том, чтобы предоставить человеку способ читать и редактировать ссылку, посредством которой можно получить ссылку на объект CORBA.
Пример corbaloc:
corbaloc::160.45.110.41:38693/StandardNS/NameServer-POA/_root
Реализация CORBA может предоставлять поддержку форматов «http:», «ftp:» и «file:». Назначение этих форматов в том, чтобы указать способ получить строковое представление ссылки на объект CORBA.

1.5 Список брокеров (CORBA ORBs)

• Borland Enterprise Server, VisiBroker Ed — CORBA 2.6-совместимый коммерческий ORB от Borland, поддерживает Java и C++.
• MICO — свободный (LGPL – GNU Lesser General Public License – Стандартная общественная лицензия ограниченного применения GNU) ORB с поддержкой C++.
• omniORB — свободный (LGPL) ORB для C++ и Python.
• ORBit2 — свободный (LGPL) ORB для C, C++ и Python.
• JacORB — свободный (LGPL) ORB, написан на Java.
• TAO — The ACE (англ. Adaptive Communication Enviroment – адаптивная коммуникационная среда) ORB, открытый ORB для C++.
• Orbacus — коммерческий ORB для C++, Java от IONA Technologies.
• Orbix — коммерческий ORB от IONA Technologies.
• PolyORB — ORB от AdaCore для языка программирования Ada. Есть как свободная, так и коммерческая версии.

2 Создание распределённого приложения на базе CORBA

Процесс разработки распределенного приложения на языке Java с использованием технологии CORBA включает в себя следующие шаги:

• Описание интерфейса удаленного объекта с помощью языка IDL (Interface Definition Langauge – язык описания интерфейсов).
• Обработка описания интерфейса на языке IDL компилятором idlj. В результате будут сгенерированы файлы, содержащие Java-версию описания интерфейса и код классов для программных прослоек, называемых stub на стороне клиента и skeleton (каркас) на стороне сервера. Эти программные прослойки обеспечивают подключение к ORB.
• Программирование сервера. Его код включает в себя сгенерированный компилятором idlj код skeleton’ов, реализацию методов интерфейса, код запуска ORB и ожидания обращений от клиентов.
• Программирование клиента на основе сгенерированного компилятором idlj кода stub’ов. Клиент стартует свой ORB, отыскивает нужный ему сервер, используя службу имен, получает ссылку на удаленный объект и вызывает его методы.
• Запуск приложения путем последовательного старта службы имен, сервера и клиента.

3 Пример простого приложения клиент-сервер

Ниже приведена последовательность действий по разработке клиент-серверного приложения, в котором сервер предоставляет возможность клиенту вывести на экран текстовую строку «Hello, World!» и завершить работу ORB.

3.1 Создание интерфейса на языке IDL

IDL – декларативный язык для формального описания интерфейсов взаимодействия клиентов и серверов в распределенных приложениях. IDL не привязан к какому-либо языку программирования, но для большинства современных языков программирования существуют спецификации, определяющие правила трансляции конструкций IDL в конструкции этих языков.
Ниже приведен пример описания интерфейса для приложения Hello (в файле Hello.idl каталога приложения).

Конструкция module определяет пространство имен, в котором будут существовать включенные в нее интерфейсы. Эта конструкция по своему смыслу близка понятию «пакет» (package) языка Java.

Конструкция interface определяет программный интерфейс, с помощью которого объекты общаются друг с другом. В этом интерфейсы языков IDL и Java аналогичны.

В теле конструкции interface объявляются операции, которые должен быть способен выполнять сервер по запросу клиента. Операции языка IDL соответствуют методам языка Java.

В результате компиляции будет создан пакет с именем HelloApp (имя из конструкции module) в каталоге Hello , содержащий 6 файлов: Hello.java, HelloPOA.java, _HelloStub.java, HelloOperations.java, HelloHelper.java, HelloHolder.java .

• Hello.java содержит код Java-интерфейса Hello, сгенерированный из IDL-интерфейса. Интерфейс Hello расширяет интерфейсы HelloOperations, org.omg.CORBA.Object и org.omg.CORBA.portable.IDLEntity .
• HelloOperations.java содержит код Java-интерфейса HelloOperations , объявляющего два метода sayHello() и shutdown() , соответствующих операциям языка IDL. Интерфейс HelloOperations используется stub’ами клиентов и skeleton’ами серверов.
• HelloPOA.java содержит код абстрактного класса HelloPOA , расширяющего класс org.omg.PortableServer.Servant и реализующего интерфейсы HelloApp.HelloOperations , org.omg.CORBA.portable.InvokeHandler . Класс HelloPOA является skeleton’ом и обеспечивает базовую функциональность CORBA для сервера.
• _HelloStub.java содержит код класса _HelloStub , расширяющего класс org.omg.CORBA.portable.ObjectImpl и реализующего интерфейс HelloApp.Hello . Этот класс играет роль stub’а и обеспечивает базовую функциональность CORBA для клиента.
• HelloHelper.java содержит код класса HelloHelper , обеспечивающего вспомогательную функциональность. Например, метод narrow() этого класса необходим для преобразования объектных ссылок ( object references ) CORBA, используемых для идентификации объектов, к типам, принятым в Java. Этот класс реализует чтение/запись данных различного типа в потоки CORBA.
• HelloHolder.java содержит код финального класса HelloHolder, реализующего интерфейс org.omg.CORBA.portable.Streamable . Этот класс включает открытую переменную типа Hello . Для аргументов типа out и inout операций языка IDL в этом классе выполняются преобразования, соответствующие семантике аргументов методов языка Java. Класс Holder обращается к методам класса Helper для выполнения операций чтения/записи в потоки CORBA.

3.2 Создание серверной части приложения

Серверная часть приложения состоит из двух классов: собственно сервера и серванта ( servant ). Сервант (назовем его HelloImpl ) реализует IDL-интерфейс Hello , при этом каждая сущность IDL-интерфейса Hello реализуется сущностью класса HelloImpl. Сервант является подклассом класса HelloPOA , описание которого сгенерировано компилятором idlj .

Сервант содержит по одному методу для каждой IDL-операции (в нашем примере это методы sayHello() и shutdown()). Методы серванта являются «обычными» методами Java, все вспомогательные операции (общение с ORB, приведение аргументов и результатов и т.п.) выполняются каркасом.
Класс сервера содержит метод main(), который выполняет следующие задачи:

• создание и инициализация экземпляра ORB;
• получение доступа к корневому объекту POA и активизация POAManager;
• создание экземпляра серванта и информирование ORB о нем;
• получение доступа к объекту CORBA в пространстве имен, в котором необходимо зарегистрировать новый объект CORBA;
• получение корневого пространства имен;
• регистрация нового объекта в пространстве имен под именем «Hello»;
• ожидание вызова нового объекта со стороны клиентов.

Ниже представлен пример кода (в файле HelloServer.java каталога Hello ) серверной части приложения.

Далее следуют пояснения отдельных строк кода.

ORB orb = ORB.init(par, null);

Любому серверу CORBA необходим локальный объект ORB. Каждый сервер создает экземпляр ORB и регистрирует в нем свои объекты-серванты, дабы ORB мог найти объекты при получении соответствующих запросов.

Операция activate() делает состояние POAManager’а активным, заставляя ассоциированные с ним POA начать обработку запросов. Каждый объект POA ассоциирован с одним объектом POAManager, но объект POAManager может быть ассоциирован с несколькими объектами POA.

org.omg.CORBA.Object objRef = rb.resolve_initial_references(«NameService»);

Для обеспечения доступа клиентов к операциям серванта сервер использует службу имен под названием Common Object Services (COS). Серверу необходим доступ к службе имен для того, чтобы он мог опубликовать ссылки на объекты, реализующие различные интерфейсы. В настоящее время реализовано 2 типа службы имен: tnameserv (временная) и orbd (временная и постоянная). Наш пример использует orbd. Аргумент в виде «NameService» понимается службами имен обоих типов, при этом для orbd он означает постоянный режим, а для tnameserv — временный. Для приведения orbd во временный режим необходимо использовать «TNameService».

NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);

objRef — «первородный» (исходный) объект CORBA. Для его использования в качестве объекта NamingContextExt необходимо «преобразование типа», выполняемое методом narrow() вспомогательного класса NamingContextExtHelper , сгенерированного компилятором idlj . После этого объект ncRef применяется для доступа к службе имен и регистрации в ней сервера.

3.3 Создание клиентской части приложения

Клиент объекта имеет доступ к объектной ссылке и вызывает операции объекта. Клиент знает только логическую структуру объекта в соответствии с его интерфейсом и может наблюдать за поведением объекта через вызовы методов.

Ниже представлен пример кода (в файле HelloClient.java каталога Hell o) клиентской части приложения.

Прежде чем запустить на выполнение сервер, и затем клиент распределённого приложения, необходимо запустить сервис именования командой orbd из набора jdk 7 (в нашем случае был использован jdk1.7.0_09) с параметрами порта и хоста.

>orbd -ORBInitialPort 2050 -ORBInitialHost localhost

Источник

Corba имеет способы определения интерфейса объекта

Общая Архитектура Брокеров Объектных Запросов — Common Object Request Broker Architecture (CORBA) является наиболее важным (и амбициозным) проектом в области промежуточного программного обеспечения (middleware), который когда-либо выдвигала компьютерная промышленность. CORBA— результат работы консорциума Object Management Group (OMG), который включает более 10 00 компаний, представляющих весь «цвет» компьютерной индустрии,в том числе и Microsoft.Для остальной части компьютерной промышленности следующим поколением middleware является CORBA. Объектная шина (object bus) CORBA определяет структуру «живущих на ней» компонентов, а также способы их взаимодействия. Следовательно, выбирая открытую объектную шину, индустрия тем самым выбирает действительно открытую, ничем не ограниченную область применения компонентов.

Что делает CORBA крайне важной, так это то, что она определяет промежуточное программное обеспечение, которое потенциально связано со всеми другими формами существующих клиент/серверных middleware. Другими словами, CORBA использует объекты как унифицирующую метафору для объединения уже существующих приложений единой шиной взаимодействия. В то же время, она обеспечивает надежный фундамент для построения будущего, основанного на компонентах. Ценность CORBA состоит в том, что вся ее система самоопределяема (самоописываема). Кроме того, спецификация сервиса всегда отделена от его реализации. Это позволяет вам соединять существующие системы с единой шиной.

CORBA спроектирована таким образом, чтобы позволить интеллектуальным компонентам находить друг друга и взаимодействовать посредством объектной шины. Однако, CORBA обеспечивает не только взаимодействие. Она также определяет широкий набор связанных с шиной сервисов для создания и удаления объектов, для доступа к ним по именам, хранения их в долговременной памяти, предоставления информации об их состоянии и задания определенных связей между ними.

CORBA позволяет вам создать простой объект, а затем сделать его транзакционным, защищенным, блокируемым, или сохраняемым, за счет применения множественного наследования от соответствующих сервисов. Это означает, что вы можете сначала спроектировать обычный компонент с требуемой функциональностью, а затем дополнить его средствами промежуточного программного обеспечения, как на стадии его компиляции, так и на стадии выполнения. Так что, добро пожаловать в эпоху гибкого middleware, «сделанного на заказ». В любых других формах клиент/серверных технологий не существует ничего подобного.

Здесь рассказано об объектной шине CORBA и объектных системных сервисах, расширяющих эту шину. Мы начнем с обзора CORBA и с того, что она значит для интеллектуальных компонентов. Затем, мы рассмотрим объектную модель CORBA и архитектуру, которая связывает это все в единое целое. Наконец, мы оценим перспективы хорошо известных технологий клиент/сервер. Как вы увидите, некоторых важных моментов для распределенных объектов все еще не хватает. Далее мы и коснемся того, что готовит OMG в своих новых спецификациях.

Распределённые объекты в стиле CORBA

Возможно, секрет успеха OMG заключается в том, что эта группа дает спецификации интерфейсов, но не код как таковой. Интерфейсы, определенные OMG, всегда основаны на реальных технологиях, разработанных компаниями — членами этой группы. Спецификации написаны на пассивном языке описания интерфейсов IDL (Interface Definition Language), который определяет функциональность компонентов, — т.е. внешние (часто называемые контрактными) интерфейсы с потенциальными клиентами (в программном смысле). Компоненты, написанные на IDL, должны быть доступны независимо от программных языков, инструментальных средств, операционных систем и сетевой инфраструктуры программных компонент. А после принятия в декабре 1994 спецификации CORBA 2.0 эти компоненты будут способны взаимодействовать через объектные брокеры CORBA, созданные разными производителями.

ЧTO такое распределенные объекты CORBA?

Объекты CORBA представляют собой интеллектуальные единицы способные жить в любом месте сети. Они упакованы в виде двоичных компонентов, к которым удаленные кзженты могут обращаться, вызыая их методы. Как язык, так и компилятор, используемые для создания серверных объектов, являются полностью прозрачными для клиентов. Клиент не обязан знать, где располагается распределенный объект или под управлением какой операционной системы он выполняется. Он может находиться в том же процессе или на машине, расположенной где-то в «межгалактической» сети. Кроме того, клиенту не нужно знать, как реализован серверный объект. Например, серверный объект может быть реализован как набор классов C++ или с помощью миллиона строк на КОБОЛе — клиент не почувствует разницу. В чем действительно нуждается клиент, так это в опубликованном интерфейсе своего серверного объекта. Такой интерфейс служит связующим контрактом между клиентом и сервером. Весь смысл в IDL

CORBA IDL является чисто декларативным языком. Это означает, что он не описывает детали реализации. Вы можете использовать IDL, чтобы лаконично определить API, а также некоторые важные моменты, например, обработку ошибок. Методы, определенные на языке IDL, могут быть реализованы и вызваны из любых языков, которые обеспечивают поддержку CORBA. В настоящий момент это С, C++, Ada и Smalltalk COBOL, Java и Objective С. Программисты имеют дело с объектами CORBA, используя естественные и хорошо знакомые языковые конструкции. Для всех сервисов и компонентов, которые связаны с шиной CORBA, IDL предоставляет интерфейсы, не зависящие от операционной системы и языка программирования. IDL позволяет взаимодействовать клиентскими серверным объектам, написанным на различных языках

Рис 1 CORBA IDL Обеспечивает Интероперабельность

Вы можете использовать OMG IDL для указания атрибутов компонентов, родительских классов, от которых они унаследованы, исклюльных ситуаций, порождаемых компонентами, генерируемых ими событий, а также методов, которые поддерживаются интерфейсом компонентов, включая входные и выходные параметры методов и их типы данных. Грамматика IDL является подмножеством C++ с дополнительными ключевыми словами для поддержки концепции распределеннос, кроме того, полностью поддерживаются особенности стандарта препроцессора C++ и директивы pragma.

Амбициозность целей CORBA заключается в «IDL-изации» всего клиент/серверного middleware и всех компонентов, взаимодействующих через ORB. OMG надеется достичь этих целей с помощью следующих двух шагов: 1) она превратит все в гвозди и 2) даст каждому молоток.

«Гвоздем» программы станет IDL. Он позволяет производителям компонентов описать на стандартном языке определений интерфейсы и структуры поставляемых объектов. Определенные с помощью IDL контракты связывают производителей распределенных объектных сервисов с их клиентами. Объект, который запрашивает что-либо у другого объекта, обязан знать интерфейс этого объекта. Репозитарий Интерфейсов (Interface Repository) CORBA содержит определения всех таких интерфейсов. Он содержит метаданные, позволяющие компонентам находить друг друга динамически во время выполнения (run-time). Это делает CORBA самоопределяемой системой.

«Молоток» состоит из набора распределенных сервисов, которые будут поставлять производители OMG. Такие сервисы определяют: какие объекты существуют в сети, какие методы они предоставляют, и какие-адаптеры объектных интерфейсов они поддерживают. Местонахождение объекта должно быть прозрачным для клиента. Не должно иметь значения, находится ли объект в том же процессе или где-то во вселенной.

Целью является создание мультипроизводителей, мульти-операционных систем, мультиязыков, функционирующих в мире, используя объекты. Такие производители, как Oracle, Sun, HP, IBM, Digital, Apple,Netscape, Tandem и NCR, используют CORBA как стандартный, IDL-ный интерфейс на объектной дороге. IDL является контрактом, который связывает их всех вместе.

Компоненты СОКВА: от системных объектов к Бизнес-объектам

Обратите внимание, что мы использовали термины «компоненты» и «распределенные объекты» как взаимозаменяемые. Распределенныеобъекты CORBA по определению являются компонентами из-за способа их упаковки. В распределенных объектных системах единицей работы и распределенности является компонент. Инфраструктура распределенных объектов CORBA предоставляет простые механизмы, чтобы компоненты стали более автономными, самоуправляемыми и взаимодействующими. Такая заявка намного смелее, любых попыток конкурирующих форм промежуточного программного обеспечения Технология распределенных объектов CORBA позволяет нам собирать в единое целое сложные информационные клиент/серверные системы, просто связывая и расширяя их компоненты. Вы можете модифицировать объекты, не влияя на другие компоненты или на то, как они взаимодействуют. Клиент-серверные приложения превращаются в наборы взаимодействующих компонентов.

Последнее достижение в области индустрии компонентов клиент/сервер — суперинтеллектуальные компоненты, которые не просто взаимодействуют, — они сотрудничают на семантическом (смысловом) уровне, чтобы выполнить необходимую работу. Программисты могут легко добиться необходимого взаимодействия компонентов, создавая проммный код независимо для каждого компонента . Хитрость, однако, состоит в том, чтобы создать компоненты, которые a priori ничего не знают друг о друге, но сделают именно то, что нужно. Чтобы этого добиться, необходимы стандарты, устанавливающие правила стыковки на разных уровнях взаимодействия компонентов.

ОМА- Архитектура Управления Объектами от OMG(Object Management Architecture)

Осенью 1990 года OMG впервые опубликовала Руководство по Арпектуре Управления Объектами (Object Management Architecture Guide -ОMA Guide). Его обновление было сделано в 1992 году. Подробности, касающиеся Общих Средств (Common Facilities) были добавлены в январе 1995. На рис 2 показаны четыре основных элемента данной архитекы: 1) Брокер Объектных Запросов (Object Request Broker — ORB) опредеяет объектную шину CORBA; 2) Сервисы CORBA (CORBAservices)определяют системный уровень объектной структуры, которая расширяет шину; 3) Общие Средства CORBA (CORBAfacilities) определяют горизонтальные и вертикальные структуры, которые непосредственно используются бизнес-объектами; 4) Application Objects представляют прикладные объекты и приложения, то есть конечных потребителей ифраструктуры CORBA. Данный раздел описывает общий взгляд на четыре приведенных элемента инфраструктуры CORBA.

Рис 2. Архитектура Управления Объектами ORB

Брокер объектных запросов — Object Request Broker (ORB)

Брокер объектных запросов — это объектная шина. Она позволяет объектам прозрачно генерировать запросы и получать ответные отклики от других объектов — локальных или удаленных. Клиент ничего не знает о мех анизмах, используемых для коммуникации, активизации или хранения серверных объектов. Спецификации CORBA 1.1 (выпущенные в 1991)определяют только IDL, языковое связывание и API для обращения к ORB. Таким образом, вы могли бы написать переносимые программы, способные работать на дюжине CORBA-совместимых ORB, представленных на рынке (особенно со стороны клиента). CORBA 2.0 определяет взаимодействие (interoperability) ORB разных производителей.

CORBA ORB обеспечивает широкий спектр сервисов распределенного промежуточного программного обеспечения. ORB позволяет объектам обнаруживать друг друга во время выполнения (run-time) и вызывать сервисы друг друга. ORB намного более сложен, чем альтернативные формы клиент/серверного middleware, включая традиционные вызовы удаленных процедур (Remote Procedure Calls — RPC), обмен сообщениями (Message-Oriented Middleware — MOM), хранимые процедуры баз данных или сетевые службы взаимодействия «точка-точка» (peer-to-peer). Теоретически, CORBA является лучшим клиент/серверным middleware из когда-либо определенных. На практике же CORBA хороша настолько,насколько хорош реализующий эту архитектуру продукт. Чтобы показать, почему CORBA ORB так хороши для ППО архитектуры клиент/сервер, мы приводим следующий ‘«краткий» список замечательных свойств, присущих всем ORB:

• Статические и динамические вызовы лгетодов. CORBA ORB позволяет статически определять вызовы ваших методов во время компиляции или находить их динамически во время выполнения. Таким образом, вам предоставляется выбор: строгий контроль типов на стадии компиляции или максимальная гибкость при отложенном (на этапе выполнения) связывании. Большинство других видов middleware поддерживают только статическое связывание.
• Связывание с языком высокого уровня. CORBA ORB позволяет вызывать методы серверного объекта с помощью выбранного Вами языка высокого уровня. При этом не имеет значения на каком языке написаны серверные объекты. CORBA отделяет интерфейс от его реализации и предоставляет независимые от языка типы данных, что дает возможность вызывать объекты из любого языка и для любой операционной системы. Наоборот, другие типы промежуточного программного обеспечения обычно предоставляют низко-уровневые API-библиотеки для определенного языка . Кроме того, они не отделяют реализацию от спецификации и, как следствие, API тесно связан с реализацией, что делает интерфейс очень чувствительным к изменениям.
• Самоописываемая система. CORBA предоставляет метаданные на этапе выполнения для описания каждого серверного интерфейса, известного системе. Каждый CORBA ORB должен поддерживать Репозитарий Интерфейсов (Interface Repository), который содержит текущую (real-time) информацию, описывающую предоставляемые сервером функции и их параметры. Клиенты используют метаданные, чтобы определить, каким образом вызывать сервисы во время выполнения. Метаданныетакжепомогаютинструментальным средствам создавать код «на- лету». Такие метаданные генерируются автоматически либо прекомпиляторами языка IDL, либо такими компиляторами, которые знают, как генерировать IDL непосредственно из объектно-ориентированного языка. Например, компилятор MetaWare C++ генерирует IDL непосредственно из определения класса C++; Inprise VisiBroker/Netscape Caffeine генерирует IDL непосредственно из байт-кода Java. Насколько нам известно, не существует других видов middleware клиент/сервер, которые бы обеспечивали такой тип метаданных и независимые от языка определения для всех своих сервисов. Как станет ясно из дальнейшего изложения, все бизнес-объекты и компоненты требуют позднего связывания, чтобы обеспечить наибольшую гибкость, на которую они способны.
• Прозрачность локальная/удаленная. ORB может выполняться в автономном режиме на лаптопе, или же может взаимодействовать со всеми другими ORB во вселенной, используя сервисы протокола ПОР (Internet Inter’ ORB Protocol — Internet-протокола взаимодействия ORB) стандарта CORBA 2.0. ORB может выступать в качестве посредника для межобъектных вызовов внутри единственного процесса, нескольких процессов, выполняющихся на одном компьютере, или множества процессов, выполняющихся в разных сетях под управлением разных операционных систем. Такой механизм полностью прозрачен для ваших объектов. Обратите внимание, что ORB может выступать посредником как между «мелко-зернистыми» объектами — подобными классам C++, так и для более масштабных — «крупно-зернистых» объектов. В общем случае, CORBA-программисту нет дела до транспортных протоколов, местоположения серверов, активации объектов, порядка следования байтов через различные платформы или целевых операционных систем — CORBA все это сделает прозрачным.
• Встроенная безопасность и транзакции. ORB включает в свои сообщения контекстную информацию для управления безопасностью и транзакциями при переходе с машины на машину и через границы ORB.
• Полиморфные сообщения. В отличие от других форм middleware, ORB не просто вызывает удаленную функцию — он вызывает функцию целевого объекта. Это означает, что вызов одной и той же функции может дать разный эффект, в зависимости от объекта, принимающего вызов. Например, вызов метода configure_yourself приведет к разным результатам в случае вызова для объекта базы данных и для объекта-принтера.
• Сосуществование с существующими системами. Отделение определения объекта от его реализации в архитектуре CORBA обеспечивает возможность инкапсуляции существующих приложений. Используя CORBA IDL, вы можете сделать ваш существующий код, подобным объекту на шине ORB, даже если он реализован в хранимых процедурах, CICS, IMS или КОБОЛе. Это делает CORBA эволюционным решением. Вы можете написать ваши новые приложения как «чистые» объекты и инкапсулировать существующие приложения в IDL-обертку.

Итак, чем вызовы методов ORB отличаются от вызовов RPC? Эти механизмы очень похожи, но есть некоторые важные отличия. С помощью RPC вы вызываете указанную функцию (данные отделены), С помощью ORB, наоборот, вы вызываете метод определенного объекта. Различные объектные классы могут отвечать на вызов одного и того же метода по-разному благодаря полиморфизму. Поскольку каждый объект управляет своим собственным экземпляром данных, вызываемый метод работает с этим определенным экземпляром данных. Вызов методов ORB обладает точностью скальпеля. Вызов направляется определенному объекту, который управляет конкретными данными, затем выполняется функция определенным для данного класса способом. Вызовы RPC, наоборот, не отличаются специализацией — все функции с одним и тем же именем реализованы одинаково. Здесь нет дифференцированных сервисов.

Анатомия CORBA ORB

CORBA Object Request Broker представляет собой промежуточное программное обеспечение, которое устанавливает клиент/серверныe отношения между объектами. Используя ORB, объект-клиент может прозрачно (не задумываясь ни о чем) вызывать метод объекта-сервера, который может находиться на той же машине или где-то в сети. ORB перехватывает вызов и отвечает за поиск объекта, способного ответить на запрос, передает ему параметры, вызывает метод и возвращает результат. Клиент не должен беспокоиться о том, где расположен объект, на каком языке программирования он создан, под управлением какой операционной системы выполняется и т.п. Клиента никогда не интересуют системные аспекты объектов, не являющиеся частью их интерфейсов. Очень важно отметить то, что роли клиент/сервер используются только для координации взаимодействия между двумя объектами. Объекты на шине ORB могут выступать и в качестве клиентов, и в качестве серверов, в зависимости от ситуации.

На рис 3 показаны клиентская и серверная части CORBA ORB. Светлые части являются новыми для CORBA 2.0. Несмотря на большое количество прямоугольников, ситуация не так запутана, как кажется. Главнoe — необходимо понять, что CORBA, подобно SQL, предоставляет как статические, так и динамические интерфейсы для своих сервисов. Это произошло потому, что OMG получила два запроса на разработку ORB: один от HyperDesk и Digital, основанный на динамическом API, а другой от Sun и HP, основанный на статическом API. OMG дала задание двум группам объединить эти две особенности. Результатом явилась CORBA. «Общая» («Common») в аббревиатуре CORBA означает слияние предложений для такого двойного API, что имеет колоссальный смысл, поскольку дает нам и статический и динамический API.

Рис 3 Структура ORB в CORBA

Для начала давайте рассмотрим, что делает CORBA с клиентской стороны:

• IDL-стабы клиента (Client IDL Stubs) обеспечивают статические интерфейсы к объектным сервисам. Такие прекомпилированные стабы определяют, как клиенты вызывают соответствующие сервисы на сервере. С точки зрения клиента стабы подобны локальному вызову — это локальный заместитель (proxy) для удаленного серверного объекта. Эти сервисы определяются посредством IDL., Стабы и клиента и сервера генерируются компилятором IDL. Клиент должен иметь IDL-стаб для каждого интерфейса, который он использует на сервере. Стаб содержит код маршалинга — marshaling). Это означает, что стаб кодирует и декодирует операцию и ее параметры в единообразный формат сообщения, которое может быть отослано серверу. Он также содержит заголовочные файлы, которые дают возможность вызывать метод сервера из языка высокого уровня (С, C++, Java или Smalltalk), не заботясь о базовом протоколе или таких преобразованиях, как упорядочение данных. Для обращения к удаленному сервису вы просто вызываете метод из вашей программы.
• Интерфейс Динамических Вызовов (Dynamic Invocation Interface — DII) позволяет вам во время выполнения обнаруживать методы, которые необходимо вызвать. CORBA определяет стандартный API для поиска метаданных, определяющих серверный интерфейс, генерации параметров, удаленного вызова и получения результатов.
• API Репозитария Интерфейсов (Interface Repository API) позволяет вам получать и модифицировать описания интерфейсов всех зарегистрированных компонентов, поддерживаемых ими методов и их параметров. CORBA называет такие описания — сигнатурой метода (method signature). Репозитарий интерфейсов представляет собой распределенную базу данных реального времени которая содержит в машинном формате версии определенных на IDL интерфейсов. Думайте о нем, как о динамическом репозитарий метаданных ORB. Данный API разрешает компонентам динамический доступ, хранение и модификацию метаданных. Такое всеобъемлющее использование метаданных позволяет каждому компоненту, живущему на ORB, иметь самоописываемый интерфейс. Сам ORB является самоописываемой шиной.
• Интерфейс ORB состоит из нескольких API к локальным сервисам, которые могут быть полезны приложениям. Например, CORBA предоставляет API для преобразования ссылки на объект в строку и наоборот. Эти вызовы могут быть очень полезны, если необходимо хранить ссылки на объекты и использовать их для связи с объектами. CORBA: Глобальные репозитарные идентификаторы.

В стандарте CORBA 2.0 ORB предоставляют глобальные идентификаторы — Репозитарные ID (Repository ID) — для уникальной и глобальной идентификации компонентов и их интерфейсов среди ORB разных производителей и множества репозитариев. Репозитарный ID генерируется системой и представляет собой уникальную строку, которая используется для поддержания целостности в соглашениях по наименованию. Соглашения по наименованию используются для всех репозитариев, при этом конфликты имен недопустимы. Репозитарный ID генерируется директивой pragma языка IDL. Эта директива специфицирует, генерировать ли идентификатор с использованием системы универсальных уникальных идентификаторов (Universal Unique Identifiers — UUID) DCE или он будет определяться пользователем — добавлением уникального префикса к составным именам IDL. Сам по себе репозитарный ID представляет строку, состоящую из трехуровневой иерархии имен. Поддержка как статических, так и динамических вызовов клиент/сервер, а также репозитарий интерфейсов, дает CORBA неоспоримые преимущества по сравнению с конкурирующими middleware. Статические вызовы легче программировать, они быстрее и самодокументируемы. Динамические вызовы предоставляют максимальную гибкость, но они сложнее в программировании; они очень полезны для инструментальных средств, которые исследуют сервисы во время выполнения.

Серверная часть не может определить разницу между статическим и динамическим вызовом; оба они имеют одинаковую семантику сообщения. В обоих случаях ORB находит объектный адаптер сервера, передает ему параметры, а затем передает управление коду объекта с помощью IDL-стаба (или скелетона — skeleton) сервера. На рис 3 показано, что делают элементы CORBA на стороне сервера:

• IDL-стабы сервера (Server IDL Stubs) (OMG называет их скелетонами — skeletons) предоставляют статические интерфейсы каждому сервису, экспортируемому сервером. Эти стабы, как и стабы клиентов, создаются компилятором IDL.
• Интерфейс Динамических Скелетонов (Dynamic Skeleton Interface DSI), введенный в CORBA, предоставляет механизм связывания реального времени для тех серверов, которым необходимо управлять входящими вызовами методов компонентов не имеющих IDL-скомпилированных скелетонов (или стабов). Динамический скелетон ищет значения параметров во входном сообщении, чтобы понять, для кого они предназначены, т.е. для какого объекта и метода. В противоположность этому, нормально скомпилированные скелетоны определены для конкретного класса объектов и располагают реализацией для каждого метода, описанного на IDL. Динамические скелетоны чрезвычайно полезны для реализации универсальных мостов между ORB. Они могут также использоваться интерпретаторами и языками сценариев, чтобы динамически сгенерировать реализацию объекта. DSI является серверным эквивалентом DII. Он может воспринимать как статические, так и динамические вызовы клиентов.
• Объектный Адаптер (Object Adapter) располагается на вершине ядра коммуникационных сервисов ORB и принимает запросы к сервису со стороны серверных объектов. Он обеспечивает среду реального времени для создания экземпляров серверных объектов, передачи запросов объектам и назначения объектам идентификаторов (ID) -СORBA вызывает идентифицированные объектные ссылки (object references). Объектный адаптер также регистрирует поддерживаемые им классы и их экземпляры этапа выполнения (т.е. объекты) в Репозитарии Реализаций (Implementation Repository). CORBA указывает, что каждый ORB должен поддерживать хотя бы стандартный адаптер — Базовый Объектный Адаптер (Basic Object Adapter — BOA). Серверы могут поддерживать более одного адаптера.
• Репозитарий Реализаций (Implementation Repository) является репозитарием времени выполнения с информацией о классах, поддерживаемых сервером, об объектах, экземпляры которых созданы, а также их ID. Он также служит общим хранилищем дополнительной информации, связанной с реализацией ORB. В качестве примера можно привести информацию о трассировке, безопасности и другие административные данные.
• Интерфейс ORB состоит из нескольких API к локальным сервисам, которые идентичны таковым на клиентской стороне.

На этом закончим панорамный обзор компонентов ORB и их интерфейсов.

CORBA: Архитектура Взаимодействия ORB (Inter-ORB)

Даже если некоторым разработчикам приложений понадобится разобраться в том, как взаимодействуют ORB, то это будет чисто спортивный интерес. Мы углубимся в вопросы взаимодействия стандарта CORBA. Ниже дано описание того, что делает каждый из элементов архитектуры взаимодействия ORB в стандарте CORBA:

• Общий Протокол Взаимодействия ORB (General Inter-ORB Protocol — GIOP) определяет набор форматов сообщений и общего представления данных (common data representation) для коммуникаций между ORB. GIOP был создан специально для обеспечения взаимодействия между ORB (ORB-to— ORB). Он спроектирован для работы поверх любого транспортного протокола, ориентированного на соединение (connection-oriented transport protocol). GIOP определяет семь форматов сообщений, которые охватывают всю семантику запрос/ответ для ORB. Формат предварительных «переговоров» (для установления соединения) не нужен. В большинстве случаев клиенты посылают запросы объектам сразу же после установления связи. Общее Представление Данных (Common Data Representation— CDR) отображает определенные в OMG IDL типы данных в единообразное, ориентированное на сетевое сообщение, представление. CDR заботится также о межплатформных нюансах, таких как порядок байтов (перестановка байтов не нужна) и выравнивание данных в памяти (memory alignments).
• Internet-Протокол Взаимодействия ORB (Internet Inter ORB Protocol — IIOP) определяет способ обмена сообщениями формата GIOP по сети TCP/IP. IIOP предоставляет возможность использовать Internet как таковой в качестве основы инфраструктуры ORB, через которую возможно соединение с другими ORB. Данный протокол был спроектирован так, чтобы быть простым и обеспечивать «внешнее» взаимодействие для ORB на основе TCP/IP. Со временем GIOP может быть перенесен на другие транспорты. Чтобы быть совместимым с CORBA, брокер ORB обязан поддерживать GIOP поверх TCP/IP (или соединяться с ним посредством полумоста). Обратите внимание на то, что, как IIОР, так и DCE/ESIOP имеют встроенные механизмы для передачи контекстных данных, т.е. данных связанных с сервисом транзакций или сервисом безопасности. ORB берет на себя передачу таких запросов, не вовлекая в этот процесс ваше приложение. Более того эта информация может передаваться в гетерогенной среде CORBA между различными ORB с помощью мостов. Стандарт CORBA сделал хорошую работу, указав местоположение контекстных данных в генерируемых ORB сообщениях.
• Зависящие от Среды Протоколы Взаимодействия ORB (Environment-Specific Inter-ORB Protocols — ESIOP) используются для обеспечения «внешнего» взаимодействия в специализированных сетевых средах. CORBA определяет DCE как первый из многих возможных ESIOP. Подобно GIOP, протокол DCE/ESIOP поддерживает IOR, используя конфигурацию DCE. DCE/ESIOP использует GIOP CDR для представления типов данных OMG IDL над DCE RPC. Это означает, что DCE IDL не требуется. Вместо этого, типы OMG IDL и CDR отображаются непосредственно в «родное» Сетевое Представление Данных (Network Data Representation — NDR) протокола DCE. В настоящее время DCE ESIOP обеспечивает устойчивую среду для ORB специализированного применения (mission-critical). Он включает расширенные возможности, такие как средства поддержки безопасности Kerberos, ячеистые (cell) и глобальные каталоги, распределенное время, а также аутентичный RPC. DCE также позволяет вам эффективно передавать большие объемы данных, поддерживает многие базовые транспортные протоколы, включая TCP/IP. Наконец, с использованием DCE для коммуникаций с вашими ORB вы можете использовать как протоколы с установлением соединения, так и без установления соединения.

GIOP также определяет формат для Интероперабельных Объектных Ссылок (Interoperable Object References — IOR). ORB обязан создавать IOR (из ссылки объекта) всегда, когда ссылка объекта передается между ORB. IOR ассоциирует набор профилей (tagged profiles) со ссылкой на объект. Эти профили описывают один и тот же объект, но каждый из них описывает способ контакта с объектом посредством механизма конкретного ORB. Более точно, профиль предоставляет самоописываемые данные, идентифицирующие домен ORB (с которым ассоциирована ссылка) и поддерживаемые им протоколы.

Общие средства CORBA (CORBAfacilities)

Средства CORBA представляют собой набор определенных на IDL структур, которые предоставляют сервисы для непосредственной связи с объектами приложения. Думайте о них, как о следующем шаге вверх в семантической иерархии. Две категории общих средств — горизонтальные и вертикальные — определяют правила совместного использования тех бизнес-компонентов, которым необходимо эффективно взаимодействовать между собой. В октябре 1994 OMG выпустила в свет запрос на разработку общих средств (RFP1) с целью получения технологии составных документов. В марте 1996 OMG адаптировала OpenDoc для своей технологии составных документов. Этой технологии присвоили название Средства компонентов для распределенных документов (Distributed Document Component Facility — DDCF). DDCF определяет сервисы представления компонентов и стандарт обмена документами, основанныйна OpenDoc Bento.

Общие средства, находящиеся в настоящее время в разработке, включают мобильные агенты, обмен данными, структуры прикладных объектов и интернационализацию. Подобно скоростным магистралям, общие средства являются бесконечным проектом. Работа продолжится до тех пор, пока не будут определены IDL-интерфейсы CORBA для всех распределенных сервисов, известных сегодня, а также тех, которые еще будут изобретены. Когда это произойдет, CORBA предоставит IDL-интерфейсы фактически для каждого сетевого сервиса (многие будут представлять IDL-изованные версии существующих middleware).

CORBA BUSINESS OBJECTS: БИЗНЕС — ОБЪЕКТЫ

Бизнес — объекты предоставляют естественный способ описания независимых от конкретного приложения концепций, таких как заказчик, заказ, конкурент, деньги, платежи, автомобиль, пациент. Они способствуют формированию взгляда на программное обеспечение, как на нечто, выходящее за пределы инструментальных средств, приложений, баз данных и других системных концепций. Окончательная цель объектной технологии и компонентов состоит в том, чтобы предоставить такие компоненты среднего уровня детализации (medium-grained), которые лучше всего описывают поведение реального мира. Конечно, кто-то должен первым определить правила игры для компонентов, чем и занимается OMG. (Согласно Business Object Task Force — комитету OMG по бизнес-объектам, бизнес-объекты — суть компоненты уровня приложения, которые вы вольны использовать в непредопределенных комбинациях. Бизнес-объект, по определению, не зависит от какого-либо конкретного приложения. «Пост-монолитные» приложения будут состоять из набора бизнес-объектов — приложение будет просто обеспечивать среду для функционирования таких бизнес-объектов. Другими словами, бизнес-объект есть компонент, представляющий «узнаваемую» вповседневной жизни сущность. В противоположность этому, объекты системного уровня представляют сущности, которые имеют смысл только для информационных систем или для программистов. Они не понятны конечным пользователям.

В небоскребе чей-то потолок является чьим-то полом, пока вы не доберетесь до пентхауса, где только небо будет вашим потолком. Вы можете представлять бизнес-объект как «пентхаус компонентов». В соответствии с определением OMG эти объекты верхнего уровня узнаваемы конечным пользователем системы. Масштаб объекта соответствует такой «бизнес»-сущности, как автомобиль или налоговая декларация. Слово «бизнес» используется в достаточно широком смысле. Бизнес-объект является самодостаточным, т.е. имеет пользовательский интерфейс, состояние, и знает, как взаимодействовать с другими, независимо разработанными бизнес-объектами, для выполнения возложенной на него задачи.

Бизнес-объекты будут использоваться для проектирования систем, которые имитируют бизнес-процессы. В реальном мире бизнес-события редко замыкаются на единственный бизнес-объект. Как правило, в эти события вовлечено множество объектов (группы взаимосвязанных объектов). Для имитации своих двойников из реального мира бизнес-объекты должны уметь взаимодействовать друг с другом на семантическом уровне. Такие взаимодействия вы можете описать, используя наиболее популярные методологии проектирования, включая Ivar Jacobson’s use cases, Ian Graham’s task scripts, Grady Booch’s interaction diagrams, and Jim Rambaugh’s event traces. Все эти методологии используют некоторую форму диаграмм сценариев, чтобы показать, «кто» и «что» делает, «для кого» и «когда». Эти сценарии могут полностью описать (документировать) результат определенных бизнес-событий.

Бизнес-объекты должны обладать поздним и гибким связыванием, а также четко определенными интерфейсами, чтобы их можно было реализовать независимо друг от друга. Бизнес-объекты должны уметь распознавать события в своей среде, изменять свои атрибуты и взаимодействовать с другими бизнес-объектами. Подобно любым объектам CORBA, бизнес-объекты раскрывают свои интерфейсы для клиентов посредством IDL и взаимодействуют с другими объектами через ORB.

На рис.4 показан набор из четырех бизнес-объектов, которые являются частью системы заказа автомобилей: заказчик, счет, автомобиль, склад. Обратите внимание, что склад — бизнес-объект, который содержит другие бизнес-объекты — автомобили. Очевидно, что эти четыре бизнес-объекта имеют некоторую согласованную семантику для взаимодействия друг с другом, чтобы выполнять прикладные транзакации. На нижнем уровне они могли бы использовать сервис объектных транзакаций CORBA для синхронизаций своих действий. Они также способны «поделить» между собой единственное окно для корректного отображения информации.

Анатомия Бизнес-объектов CORBA

Бизнес-объекты CORBA представляют собой разновидность парадигмы Модель/Представление/Контроллер (Model/View/Controller — MVC) MVC является шаблоном проектирования объектов, используемым для построения интерфейсов в Smalltalk и практически во всех библиотеках классов GUI (чаще всего в библиотеках программирования для графических оболочек Unix и Java; например, хорошо знакомая нашим программистам библиотека компонентов JavaBeans с возможностью работы с базами данных — JBCL , входящая в состав Borland JBuilder, реализована именно в модели MVC). MVC состоит из объектов трех типов. «Модель» представляет объект приложения и его инкапсулированные данные. «Представление» (view) отвечает за визуальный вид объекта на экране. А «контроллер» определяет способ реакции пользовательского интерфейса на события пользовательского ввода и оболочки GUI.

В модели CORBA прикладной объект также состоит из трех типов объектов:

• Бизнес- объекты инкапсулируют память, метаданные, согласованность и бизнес-правила, связанные с активной прикладной сущностью (entity). Они также определяют реакцию объекта на изменение представлений (view) или модели (model).
• Объекты бизнес-процессов инкапсулируют прикладную логику на уровне предприятия. В традиционных системах MVC контроллер зависит от процесса. В модели CORBA функции короткоживущего процесса управляются бизнес-объектом. Долгоживущие процессы, вовлекающие в функционирование другие бизнес-объекты, управляются объектом бизнес-процесса — это специализация бизнес-объекта, который управляет долгоживущими процессами и средой в целом. Например, он знает, как управлять потоком документов или долгоживущей транзакцией. Бизнес-процесс обычно выступает в роли клея, объединяющего другие объекты. Например, он определяет реакцию объекта на изменения в среде. Такое изменение может быть вызвано исполнением прикладной транзакции или приходом сообщения от другого бизнес-объекта. Обратите внимание, что некоторые бизнес-объекты могут быть полностью процессо-ориентированы и не связаны с какими-либо данными или представлениями.
• Объекты представления отвечают за визуализацию объекта перед пользователем. Каждый бизнес-объект может иметь несколько представлений для разных целей. Представления взаимодействуют непосредственно с бизнес-объектом для отображения данных на экране. Иногда они взаимодействуют непосредственно с бизнес-процессом. OMG также сознает, что существуют невизуальные интерфейсы бизнес-объектов.

Типичный прикладной компонент состоит из бизнес-объекта, одного или нескольких объектов-представлений и бизнес-процесса. Обратите внимание, что эти сущности выступают как единое целое. Внутреннее разделение обязанностей между различными объектами никак не волнует (является прозрачным для) пользователей и клиентов данного бизнес-объекта. Бизнес-объект взаимодействует также с другими серверами и объектами системного уровня, но, опять же, как единый механизм. Пользователь видит только агрегированный бизнес-объект. Клиенты объекта имеют дело только с IDL-определенными интерфейсами, выставленными данным агрегированным бизнес-объектом. OMG выпустило RFP для Общих бизнес-объектов (Common Business Objects) и Средств бизнес-объектов (Business Object Facility). Средства будут предоставлять бизнес-объектам структуру для обмена семантической информацией и ьподдержки правил стыковки.

Анатомия клиент/серверных визнес-объектов

Обычно бизнес-объект (например, автомобиль) имеет несколько объектов-представлений, развернутых на нескольких клиентах. Бизнес-объект и бизнес-процесс могут располагаться на одном или нескольких серверах. Красота архитектуры CORBA заключается в том, что все объекты-участники имеют IDL-определенные интерфейсы и могут выполняться на ORB. Таким образом, не имеет значения, выполняются объекты-участники на одной и той же машине, или на разных (ORB обеспечивает прозрачность локальный/удаленный). Касается это клиентов, или нет, но они все еще имеют дело с единственным при’кладным компонентом , даже если он построен из объектов, выполняющихся на разных машинах. Хорошо спроектированный бизнес-объект строится на основе сервисов CORBA. Например, вы можете использовать сервисы совместного доступа и транзакций для обеспечения целостности состояния бизнес-объекта. ORB предоставляет вам сервисы бесплатно, используйте их, если вам это нужно.

Нирвана компонентов CORBA

На самом базовом уровне компонентная инфраструктура представляет объектную шину — Брокер объектных запросов (Object Request Broker — ORB), — которая позволяет компонентам взаимодействовать, невзирая на разницу в адресных пространствах, языках, операционных систем и сетевых инфраструктур. Шина предоставляет также механизмы, позволяющие компонентам обмениваться метаданными и исследовать друг друга. На следующем уровне эта инфраструктура расширяет шину за счёт дополнительных сервисов системного уровня, которые позволяют создавать «суперинтеллектуальные» компоненты. Примерами таких Сервисов служат сервисы лицензирования, безопасности, управления версиями, хранения, стыковки составных частей, обмена семантическими сообщениями, выполнения сценариев, транзакций.

Конечная цель состоит в том, чтобы позволить вам создавать компоненты, которые ведут себя как бизнес-объекты. Эти компоненты моделируют своих двойников из реального мира в приложениях для некоторых отраслей промышленности. Обычно они выполняют специфичные бизнес-функции, например, «автомобиль», «заказчик» или «гостиница». Вы можете сгруппировать эти бизнес-объекты в визуальные наборы, которые отображаются на экране, но основаны на отношениях клиент/сервер.

Итак, последняя нирвана в области компонентов клиент/сервер —суперинтеллектуальные прикладные компоненты, которые более чем взаимодействуют, они сотрудничают на семантическом уровне для выполнения требуемой задачи. Например, разъездные агенты, используя глобальную сеть должны иметь возможность обмениваться информацией со своими коллегами. Агенты представляют собой примеры бизнес-объектов. Такая инфраструктура обеспечивает стандарты сотрудничества приложений в форме инфраструктур уровня приложения (OMG называет их отраслевыми или доменными структурами — domain frameworks).Такие инфраструктуры определяют правила стыковки между независимыми компонентами.

Трехзвенноя архитектура клиент/сервер в объектном стиле

Бизнес- объекты идеальны для создания масштабируемой трехзвенной архитектуры клиент/сервер, поскольку им присуща декомпозиция. Бизнес-объект не является монолитным куском кода. Наоборот, он больше напоминает модель конструктора «Лего», которую вы сначала разбираете, а затем опять собираете в трехзвенную цепочку клиент/сервер. Первое звено представляет визуальные аспекты бизнес-объекта— один или несколько визуальных объектов могут воплощать различные представления. Эти визуальные объекты обычно располагаются на клиентах. Промежуточное звено — серверные объекты, представляющие хранимые данные и функции бизнес-логики. В третье звено включаются базы данных и унаследованные серверные приложения. Такое деление бизнес-объектов достаточно условно. Вы обязаны решить, где расположить различные звенья для этапа выполнения.

Серверные объекты промежуточного звена взаимодействуют со своими клиентами (визуальными объектами) и реализуют логику бизнес-объектов. Они могут извлекать информацию о своем состоянии из нескольких источников данных, например, SQL-серверов, файлов HTML, Lotus Notes и мониторов транзакций. Серверные объекты воплощают интегрированную модель несопоставимых источников данных и фоновых приложений. Клиенты взаимодействуют с бизнес-объектами, которые обычно соответствуют отраслевым понятиям. Их не интересует «кухня» третьего звена — хранимые процедуры и базы данных. Бизнес-объекты скрывают всю эту суету.

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

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

Распределенные объекты CORBA — смоделированные как бизнес-объекты — превосходно подходят для трехзвенной архитектуры клиент/сервер. Они обеспечивают масштабируемые гибкие решения для межгалактической среды клиент/сервер, для Internet и Intranet. Бизнес-объекты могут естественным образом подвергаться декомпозиции и разбиению на множество звеньев для удовлетворения потребностей приложения. Они представляют собой самоописываемые и самоуправляемые «единицы интеллектуальности», которые вы можете перемещать повсюду и запускать там, где в этом есть наибольший смысл. Наиболее важно то, что бизнес-объекты эволюционны, они не вынуждают вас выбросить существующие серверные приложения и начать все сначала. Вы можете инкапсулировать то, что уже имеете, и постепенно добавлять новую интеллектуальность, по одному компоненту за один раз.

Источник