Предисловие редакторов русского издания

Вид материала

Документы

Содержание ОКБ против RPC Анатомия CORBA 2.0 ORB IDL-стабы клиента (Client IDL Stubs) Интерфейс Динамических Вызовов (Dynamic Invocation Interface — DII) IDL-стабы сервера (Server IDL Stubs) Интерфейс Динамических Скелетонов (Dynamic Skeleton Interface -DSI) Объектный Адаптер (Object Adapter)

Подобный материал:

• От редакторов русского издания, 12579.28kb.
• Предисловие переводчика и редактора русского издания, 173.31kb.
• Предисловие от редакторов, 3279.6kb.
• Крайон книга третья. Алхимия человеческого духа руководство по переходу человечества, 3416.54kb.
• Электронная библиотека студента Православного Гуманитарного Университета, 3857.93kb.
• Предисловие, 5158.35kb.
• Автор файла (январь 2009г.): Мухамеджан Мухамеджанов, 250.83kb.
• Предисловие ко второму изданию, 1366.96kb.
• Аллан Кардек спиритизм в самом простом его выражении содержание, 4227.55kb.
• Философия русского религиозного искусства XVI-XX вв. Антология, 6335.43kb.

ОКБ против RPC

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

Вызов методов ORB обладает точностью скальпеля. Вызов направ­ляется определенному объекту, который управляет конкретными дан­ными, затем выполняется функция определенным для данного класса способом. Вызовы RPC, наоборот, не отличаются специализацией - все функции с одним и тем же именем реализованы одинаково. Здесь нет дифференцированных сервисов.

Анатомия CORBA 2.0 ORB

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

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



Для начала давайте рассмотрим, что делает 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 2.0: Глобальные репозитарные идентификаторы В стандарте CORBA 2.0 ORB предоставляют глобальные идентифи­каторы - Репозитарные ID (Repository ID) — для уникальной и глобаль­ной идентификации компонентов и их интерфейсов среди ORB разных производителей и множества репозитариев. Репозитарный ID генериру­ется системой и представляет собой уникальную строку, которая ис­пользуется для поддержания целостности в соглашениях по наименова­нию. Соглашения по наименованию используются для всех репозитари­ев, при этом конфликты имен недопустимы. Репозитарный ID генери­руется директивой pragma языка IDL. Эта директива специфицирует, генерировать ли идентификатор с использованием системы универсаль­ных уникальных идентификаторов (Universal Unique Identifiers — UUID) DCE или он будет определяться пользователем — добавлением уникаль­ного префикса к составным именам IDL. Сам по себе репозитарный ID представляет строку, состоящую из трехуровневой иерархии имен.

Поддержка как статических, так и динамических вызовов клиент/ сервер, а также репозитарии интерфейсов, дает CORBA неоспоримые преимущества по сравнению с конкурирующими middleware. Статичес­кие вызовы легче программировать, они быстрее и самодокументируе­мы. Динамические вызовы предоставляют максимальную гибкость, но они сложнее в программировании; они очень полезны для инструмен­тальных средств, которые исследуют сервисы во время выполнения.

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

• IDL-стабы сервера (Server IDL Stubs) (OMG называет их скелетона­ми - skeletons) предоставляют статические интерфейсы каждому сервису, экспортируемому сервером. Эти стабы, как и стабы клиен­тов, создаются компилятором IDL.

• Интерфейс Динамических Скелетонов (Dynamic Skeleton Interface -DSI), введенный в CORBA 2.0, предоставляет механизм связывания реального времени для тех серверов, которым необходимо управ­лять входящими вызовами методов компонентов не имеющих IDL-скомпилированных скелетонов (или стабов). Динамический скеле­тон ищет значения параметров во входном сообщении, чтобы по­нять, для кого они предназначены, т.е. для какого объекта и метода. В противоположность этому, нормально скомпилированные скелето­ны определены для конкретного класса объектов и располагают реа­лизацией для каждого метода, описанного на IDL. Динамические ске­летоны чрезвычайно полезны для реализации универсальных мостов между ORB. Они могут также использоваться интерпретаторами и языками сценариев, чтобы динамически сгенерировать реализацию объекта. DSI является серверным эквивалентом DII. Он может вос­принимать как статические, так и динамические вызовы клиентов.

• Объектный Адаптер (Object Adapter) располагается на вершине ядра коммуникационных сервисов ORB и принимает запросы к сервису со стороны серверных объектов. Он обеспечивает среду реального времени для создания экземпляров серверных объектов, передачи запросов объектам и назначения объектам идентификаторов (ID) — CORBA вызывает идентифицированные объектные ссылки (object references). Объектный адаптер также регистрирует поддерживаемые им классы и их экземпляры этапа выполнения (т.е. объекты) в Репо-зитарии Реализации (Implementation Repository). CORBA указывает, что каждый ORB должен поддерживать хотя бы стандартный адап­тер - Базовый Объектный Адаптер (Basic Object Adapter - BOA). Сер­веры могут поддерживать более одного адаптера.

• Репозитарий Реализации (Implementation Repository) является репози-тарием времени выполнения с информацией о классах, поддержи­ваемых сервером, об объектах, экземпляры которых созданы, а так­же их ID. Он также служит общим хранилищем дополнительной ин­формации, связанной с реализацией ORB. В качестве примера мож­но привести информацию о трассировке, безопасности и другие административные данные.

Интерфейс ORB состоит из нескольких API к локальным сервисам, которые идентичны таковым на клиентской стороне. На этом закончим панорамный обзор компонентов ORB и их интер­фейсов.