CORBA – Архітектура розподілених об’єктів, Різне, Програмування, статті

Огляд архітектури CORBA


Узагальнена архітектура побудови Брокерів об’єктних запитів (Object Request Broker – ORB) розроблена для підтримки інтеграції найрізноманітніших об’єктних систем. Специфікація CORBA встановлює принципи створення Брокерів об’єктних запитів, Які й допускають таку інтеграцію. Запит надсилається від клієнта до сервера. Клієнт це додаток, або щось інше, що виконує операцію над об’єктом, а реалізація об’єкта – це код і дані, які насправді виконують цю операцію. ORB здатний виконати всі дії, необхідні для знаходження реалізація зазначеного об’єкта, підготовці цієї реалізації до обробки запиту і передачі даних, що відносяться до запиту. Інтерфейс, що надається клієнту, абсолютно не залежить від місця розташування реалізації об’єкта, мови програмування, на якому він написаний або будь-яких інших аспектів, які не впливають на визначення інтерфейсу для даного об’єкта.


Брокер об’єктних запитів


При визначенні конкретної архітектури Брокер об’єктних запитів зовсім необов’язково повинен бути реалізований як один компонент, але кожна реалізація повинна реалізовувати три категорії операцій:



Різні реалізації ORB-а можуть підтримувати різні види реалізацій, а різні адаптери об’єктів можуть забезпечувати різні набори сервісів для клієнта і реалізацій. Ядро Брокера об’єктних запитів забезпечує основні механізми для маніпуляцій об’єктами і виконання запитів. Специфікація CORBA призначається для підтримки різних механізмів реалізації об’єктів, тому структура ядра не визначається. Замість цього задається набір інтерфейсних функцій, які повинні бути присутніми в кожній реалізації ORB-а і тим самим маскують відмінності між різними реалізаціями Брокерів об’єктних запитів.


Об’єкти


Система об’єктів забезпечує клієнта набором сервісів. Клієнт здатний запросити деякий сервіс. Об’єкт – Це щось, що забезпечує один або більше сервісів, які клієнт може запитати.


Приклад Брокерів об’єктних запитів


Доступно широке безліч способів реалізації конкретних ORB-ов. Далі будуть наведені приклади таких реалізацій. Слід мати на увазі, що конкретний ORB може бути реалізований відразу декількома
способами.


ORB, що включається в клієнтське і серверне додаток


Якщо є відповідний механізм комунікацій, то можлива реалізація ORB-а у вигляді набору підпрограм як з боку клієнта, так і з боку реалізації об’єкта. Виклики методів можуть транслюватися в роботу із засобами взаємодії процесів (Inter Process Communication – IPC).


ORB, виконаний у вигляді сервера


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


ORB як частина системи


Для підвищення надійності, захисту даних і досягнення кращої продуктивності ORB може бути реалізований як частина операційної системи. При цьому посилання на об’єкт можуть бути зроблені постійними, таким чином, зменшуючи час, необхідний для обробки кожного запиту. При реалізації ORB-а як частини операційної системи можливі всілякі види оптимізації, такі як уникнути кодування і декодування даних, якщо клієнт і сервер знаходяться на одній і тій же машині.


ORB, заснований на бібліотеках


Якщо код об’єкта займає невеликий об’єм і не вимагає ніяких додаткових коштів, то він може бути виконаний у вигляді бібліотеки. При цьому всі заглушки насправді будуть справжніми методами. При цьому передбачається, що маючи доступ до даних реалізації, клієнт не зруйнує ці дані.


Реалізації об’єктів


Реалізація об’єкта забезпечує саме поняття об’єкта, зазвичай задаючи дані для конкретного екземпляра об’єкта і код для виконання методів об’єкта. Часто реалізація буде використовувати інші об’єкти або Допоміжні програми для забезпечення функціонування об’єктів. В деяких випадках виконання операції над об’єктом тягне якісь побічні дії не над об’єктами. Конкретний ORB може підтримувати широкий набір об’єктних реалізацій: окремі сервери, бібліотеки, об’єктно-орієнтовані системи управління базами даних та ін За допомогою використання додаткових Адаптерів об’єктів теоретично можна підтримувати будь-яку реалізацію об’єкта.


Адаптери об’єктів


Адаптер об’єктів – Це первинний шлях для забезпечення сервісу конкретною реалізацією об’єкта. Передбачається, що є кілька адаптерів об’єктів, кожен з яких забезпечує доступ до об’єктів певного виду. Послуги, які забезпечуються ORB-му за допомогою адаптерів об’єктів часто включають: генерацію та інтерпретацію посилань на об’єкти, виклик методів, активацію і деактивацію реалізацій об’єктів, а також реєстрацію конкретних реалізацій і відображення об’єктних посилань і реалізацій. Інформація, яка знаходиться в кожному зі сховищ може бути довільно змінена в будь-який момент часу за допомогою методів, які забезпечуються реалізацією ORB-а. Однак, необережне зміна, зроблене під час роботи може привести порушити цілісність інформації, що знаходиться в кожному зі сховищ і зробити неможливим подальше функціонування ORB-а.


Скелет реалізації


Для конкретного відображення і, можливо, використовуваного адаптера об’єктів визначається свій порядок виклику методів кожного об’єкта. Цей інтерфейс в загальному випадку є інтерфейсів зворотних викликів. При необхідності ORB викликає необхідні процедури.


Динамічна обробка запитів


Також доступний інтерфейс для динамічної обробки вступників запитів. У цьому випадку реалізація об’єкта взаємодіє із заданим інтерфейсом по аналогії з інтерфейсом динамічних викликів.


Підпрограми динамічної відпрацювання запитів можуть викликатися як за допомогою інтерфейсу динамічних викликів, так і за допомогою процедур-заглушок, кожен метод дає однаковий результат.


Запити


Клієнт запитує сервіси ініціюванням запитів. Запит – Це подія, тобто дія, що відбувається в конкретний момент. Із запитом пов’язана інформація, що складається з операції, об’єкта, у якої запитується сервіс, нуля або більше дійсних параметрів виклику і необов’язковий контекст запиту. Форма запиту – це опис або шаблон, який може бути виконаний довільну кількість разів. Форма запиту визначається відображенням для конкретної мови програмування. Альтернативною формою запиту є використання Інтерфейсу Динамічних викликів, Який дозволяє створити запит, додати аргументи і виконати запит. Під значенням розуміється допустимий параметр запиту. Значення яке визначає об’єкт, називається посиланням на об’єкт, пов’язаної з конкретним екземпляром об’єкта. Виконання запиту викликає виконання відповідного сервісу. Після завершення запиту клієнту повертається результат запиту (якщо він є). У разі ненормального завершення запиту клієнту повертається виняток. Виняток може містити специфічні параметри, специфічні для даного типу винятків.


Параметри


Параметр характеризується режимом передачі і своїм типом. Режим визначає, чи повинна передаватися значення параметра від клієнта до сервера (in), від сервера до клієнта (out) або в обох напрямках (inout).



Параметри запитів визначаються їх позицією. Параметри можуть бути вхідні, вихідні і вхідні і вихідні одночасно. Як результат запит може повернути одне значення, як, втім, і будь-які вихідні параметри. У разі виникнення винятку значення всіх вихідних параметрів не визначено.


Інтерфейси


Інтерфейс – Це опис безлічі можливих операцій, які клієнт може виконувати над об’єктом. Об’єкт задовольняє інтерфейсу, якщо він може бути вказаний як кінцевим об’єктом для кожного потенційного запиту, описаного в інтерфейсі. Типу інтерфейсу задовольняють тільки об’єктні типи.


Інтерфейс ORB-а


Інтерфейс ORB-а є функціям, що викликаються безпосередньо у Брокера об’єктних запитів і ідентичним для всіх ORB-ов, не залежних від конкретного об’єкта або адаптера об’єктів. Але так як більшість дій з об’єктами виконується за допомогою адаптерів об’єктів, існує всього кілька загальних операцій, які можуть бути виконані над кожним об’єктом. Ці операції можуть викликатися як клієнтом, так і реалізацією об’єкта.


Інтерфейс динамічного виконання викликів


Цей інтерфейс допускає динамічне створення запитів до об’єкта замість виклику процедури, декорують таке створення. При динамічному створенні запиту клієнт повинен вказати всю інформацію. Необхідну виконання операції. Наприклад, інформація про типи параметрів може бути отримана за допомогою сховища описів об’єктів.


Клієнтська частина – заглушки


Для об’єктно-неорієнтованих мов програмування задається програмний інтерфейс для доступу до методів об’єкта-заглушки, наявного у клієнта. Ця заглушка здійснює передачу запиту і зазвичай оптимізована для виконання під керуванням конкретного ORB-а. Якщо доступно більше одного ORB-а, то у них може бути різне внутрішнє подання заглушок. Об’єктно-орієнтовані мови програмування, такі як C + + і Smalltalk такого інтерфейсу не вимагають.


Огляд протоколу GIOP


Специфікація протоколу GIOP складається з наступних елементів:



  1. Визначення Загального Подання даних ( Common Data Representation – CDR ). CDR – Це спосіб кодування типів даних, визначених у IDL в низькорівневе уявлення, придатне для передачі їх за наявними каналами зв’язку між ORB-ами.

  2. Формат повідомлення протоколу GIOP. Повідомлення протоколу GIOP забезпечують знаходження об’єкта, відпрацювання запитів, а також найпростіше управління каналом комунікації.

  3. Припущення про транспорт. Специфікація GIOP описує загальні припущення, які робляться при розгляді будь-якого мережевого транспортного шару, який може бути використаний для обміну повідомленнями протоколу GIOP. Також описуються загальні принципи управління з’єднанням.

Специфікація IIOP додає до специфікації протоколу GIOP наступний пункт:



  1. Транспорт для повідомлень протоколу IIOP.

Специфікація IIOP описує, яким чином агенти можуть встановити з’єднання по протоколу TCP / IP і використовувати його для передачі повідомлень протоколу GIOP.


Протокол IIOP не є самостійною специфікацією – це спеціалізоване відображення протоколу GIOP поверх транспортного шару TCP / IP. Специфікація GIOP (без елементів, специфічних для IIOP) може розглядатися як самостійний документ, який є базовим для забезпечення в майбутньому відображення на нові транспортні протоколи.


Протокол обміну GIOP


За винятком рідкісного випадку прямих викликів методів між класами одного і того ж мови програмування необхідний механізм кодування виклику методу в деяку послідовність байт (byte stream ) У клієнта і декодування цієї послідовності у сервера. Для цієї мети специфікація визначає Загальний Протокол обміну між Брокерами об’єктних запитів (General Inter-Orb Protocol – GIOP). Крім того, визначено протокол передачі повідомлень протоколу GIOP поверх транспортного протоколу TCP / IP, який є основним видом взаємодії в Internet, через що цей протокол отримав назву Протоколу обміну між Брокерами об’єктних запитів в Internet ( Internet Inter-Orb Protocol – IIOP ). Протокол IIOP повинен підтримуватися усіма Брокерами об’єктних запитів, незалежно від особливостей їх реалізації, що є головною вимогою для забезпечення взаємодії між довільними ORB-ами двох різних і абсолютно незалежних виробників.


Особливості та цілі протоколу


Протоколи GIOP і IIOP допускають взаємодію між різними ORB-ами незалежно від платформ, на яких вони виконуються, операційних систем, під управлінням яких відбувається взаємодія та інших апаратно-і програмно-залежних аспектів. При розробці цих протоколів переслідувалися наступні цілі:


Поширеність


Протоколи GIOP і IIOP розроблялися з урахуванням доступного широко розповсюдженого і гнучкого транспортного механізму (TCP / IP) і задає мінімум додаткових протоколів, необхідних для передачі запитів між окремими ORB-ами.


Простота


Крім інших вимог, протокол GIOP зроблений максимально простим. Його простота допускає можливість реалізації взаємодії по цьому протоколу практично в будь-якій системі.


Масштабованість


Протокол GIOP / IIOP повинен підтримуватися як окремими ORB-ами, так і ORB-ами, об’єднаними в мережу на рівні Internet і, можливо, ширше.


Невеликі витрати на реалізацію


Реалізація підтримки протоколів GIOP/IIOP повинна вимагати мінімальних витрат як в плані інженерного проектування, так в плані розповсюдження готових ORB-ов.


Спільність


У той час як IIOP спочатку визначений поверх протоколу TCP / IP, повідомлення, якими відбувається обмін в рамках протоколу GIOP спеціально розроблені для реалізації поверх будь-якого протоколу, який базується на встановленому між сервером і клієнтом з’єднанні.


Архітектурна незалежність


Специфікація GIOP робить мінімальні припущення про архітектуру агентів, які підтримують обмін даними по цьому протоколу. Специфікація GIOP вважає ORB якоїсь системою з невідомою архітектурою.


Підхід конкретного ORB-а до забезпечення підтримки протоколу GIOP / IIOP не визначений. Наприклад, ORB може прийняти IIOP в якості внутрішнього протоколу, використовувати його тільки для зовнішнього обміну, використовуючи для обміну в рамках самого ORB-а якісь додаткові засоби комунікації або вибрати щось середнє між цими двома крайностями. Все що потрібно від ORB-а – це щоб існувало щось здатне приймати і відправляти повідомлення по протоколу IIOP.


Формат повідомлень протоколу GIOP


Перед тим, як описувати повідомлення протоколу GIOP, необхідно визначити поняття клієнта і сервера. Під клієнтом далі розуміється агент, який відкрив з’єднання і ініціював запит. Сервер – це агент, який прийняв з’єднання і цей запит отримав. Протокол GIOP визначає сім повідомлень, список яких наведено далі в таблиці разом із зазначенням того, яка сторона які повідомлення може посилати.














































Значення, відповідне
типу повідомлення

Тип повідомлення

Хто може посилати повідомлення

Клієнт

Сервер

0

Request

Та


1

Reply


Та

2

CancelRequest

Та


3

LocateRequest

Та


4

LocateReply


Та

5

CloseConnection


Та

6

MessageError

Та

Та


Тема повідомлення однозначно визначає його тип. Тема визначений таким чином, щоб не залежати від порядку байт в поданні базових типів даних. Елементами заголовка є:



  1. Поле magic, Яке складається з чотирьох символів “GIOP”, Що ідентифікують всі повідомлення протоколу GIOP.

  2. Поле GIOP_version, Яке складається з двох полів major і minor, Що ідентифікують старший і молодший номер версії використовуваного протоколу. Поточна специфікація визначає версію 1.0. Додаток повинен підтримувати взаємодію в рамках протоколу тільки якщо номер, міститься в полі major дорівнює, а в поле minor – Більше або дорівнює номерами версії, використовуваної при розробці програми.

  3. Поле byte_order. Значення 0 в цьому полі визначає, що в повідомленні прийнято кодування даних з лідируючим найбільш значущим байтом, 1 – найменш значущим. В даний час переважна більшість процесорів, у тому числі і серія Intel x86 використовується подання з лідируючим найменш значущим байтом.

  4. Поле message_type містить значення від 0 до 6, що визначає тип повідомлення.

  5. Поле message_size містить довжину частини повідомлення (0 якщо більше нічого немає).

За загальним заголовком кожного повідомлення в залежності від його типу може йти заголовок і тіло конкретного повідомлення. Структура кожного заголовка специфічна для кожного типу повідомлення і представляє особливого інтересу для розгляду.


Транспорт для протоколу GIOP


Протокол GIOP призначається для реалізації поверх великої кількості транспортних протоколів. При цьому робляться наступні припущення про особливості протоколу:



  1. Транспорт орієнтується на встановлення з’єднання з подальшим обміном інформації в рамках з’єднання. З’єднання використовується для визначення правил нумерації запитів.

  2. Транспорт протокол повинен гарантувати проходження переданих байт в тому порядку, в якому вони були послані.

  3. Транспорт може розглядатися як потік байт без додаткових
    обмежень на розміри, фрагментацію чи вирівнювання розмірів посилок.

  4. Транспорт повинен забезпечувати сигналізацію про розрив з’єднання. Якщо один з учасників обміну несподівано перервав свою роботу, стався збій в операційній системі або мережі, то інший повинен бути повідомлений про це.

Сервер не ініціює встановлення з’єднання, але він виконує деякі дії з підготовки до прийняття запитів від клієнтів. Клієнт знає місце розташування (адреса) сервера і встановлює з’єднання по вказаною адресою. Сервер може прийняти з’єднання, унікальне для кожного клієнта (при цьому продовживши очікування нових запитів), а може і не прийняти, наприклад, внаслідок нестачі ресурсів. Якщо з’єднання встановлено, то з даного каналу може відбуватися двосторонній обмін інформацією, причому кожна сторони має можливість в довільний момент часу розірвати з’єднання.


Зовсім не обов’язково конкретний транспорт повинен прямо реалізовувати всі перераховані вимоги, але повинна бути можливість для емулювання описаної транспортної моделі.


Управління з’єднанням


З’єднання двонаправлене в сенсі потоку даних, але воно не є симетричним у плані обміну повідомленнями GIOP. Повідомлення Request, LocateRequest і CancelRequest можуть надсилатися лише клієнтом. Повідомлення Reply, LocateReply і CloseConnection – тільки сервером. Повідомлення ErrorMessage може бути послано обома сторонами. Через з’єднання для обміну відповідно до протоколу GIOP можуть надсилатися лише повідомлення GIOP.


Кожне повідомлення типу Request повинно мати унікальний номер, який ідентифікує запит в рамках встановленого з’єднання. Цей номер жодним чином не інтерпретується сервером, але він дозволяє клієнту встановити відповідність між запитом і прийшли відповідним повідомленням у разі ініціації відразу декількох запитів. Генерація цих унікальних номерів покладається на клієнта.


З’єднання може бути або закрито в рамках протоколу, або розірватися. Закриття з’єднання може ініціюватися з боку сервера за допомогою посилки повідомлення CloseConnection або клієнтом за допомогою звичайного закриття з’єднання в довільний момент часу. Якщо на момент закриття з’єднання є невідпрацьовані запити, то сервер повинен розглядати такі запити як скасовані. Сервер не може послати повідомлення CloseConnection, якщо він почав обробку запиту, для якого не надійшло повідомлення CancelRequest, або він (сервер) не послав листа у відповідь.


При отриманні повідомлення CloseConnection клієнт повинен розглядати всі повідомлення, для яких не було отримано відповіді як необроблені. Такі повідомлення клієнт може без додаткових заходів обережності послати ще раз при встановленні нового з’єднання.


У разі якщо сервер надає таку можливість, то клієнт може посилати в рамках одного з’єднання запити до різних об’єктів, оптимізуючи таким чином використання ресурсів. З іншого боку, клієнт може віддати перевагу встановлення нового з’єднання для кожного нового об’єкта, що обслуговується сервером, хоча рекомендується уникати таких випадків.


Мова опису інтерфейсів


Мова опису інтерфейсів (IDL), який використовується OMG визначає типи об’єктів за допомогою специфікації їх інтерфейсів. Інтерфейс складається з безлічі іменованих операцій і їх параметрів. Хоча й опис на IDL забезпечує ORB всією необхідною інформацією про тип об’єкта, для роботи зовсім необов’язково, щоб ORB-у був доступний початковий текст цих описів. Ця ж інформація може бути закладена також у вигляді заглушок з боку клієнта і скелета з боку сервера, а також в динамічно змінюваному сховище описів, що дозволить ORB-у нормально функціонувати.


Мова опису інтерфейсів розглядається як засіб, за допомогою якого реалізація об’єкта повідомляє своїм потенційним клієнтам про те, які операції доступні і яким чином їх слід викликати. Можна відтранслювати опис на мові IDL у вихідний код на конкретній мові програмування.


Відображення IDL у мови програмування


Різні об’єктно-орієнтовані або об’єктно-неорієнтовані мови програмування можуть отримувати доступ до об’єктів різним чином. Для об’єктно-орієнтованих мов допускається відображення об’єктів, доступних ORB-у в об’єкти в сенсі цих мов програмування. Навіть для об’єктно-неорієнтованих мов декорування цього подання посилань на об’єкти буде корисним. Конкретне відображення IDL для мови програмування має бути ідентичним для всіх реалізацій ORB-ов. Відображення для мови програмування включає в себе визначення специфічних для мови програмування типів даних та опис процедур доступу до об’єктів за допомогою ORB-а. Воно також включає в себе інтерфейс для доступу клієнта до заглушки, що може не вимагатися для об’єктно-орієнтованих мов, інтерфейс динамічних викликів, скелет реалізації, опис адаптерів об’єктів і прямий інтерфейс до ORB-у.


Відображення для мови також визначає порядок взаємодії між викликом методу і потоками (тред – threads) як з боку клієнта, так і з боку реалізації. Зазвичай забезпечується синхронний виклик, в якому підпрограма виклику повертає управління при завершенні виконання запиту. Допускається визначення додаткових коштів, для визначення порядку передачі управління і синхронізації клієнтського коду з викликом методу об’єкта.


Типи даних


Типом називається якийсь предикат (математична функція з одним аргументом повертає значення логічного типу істина / неправда), який визначений на множині всіляких значень. Значення задовольняють цього типу, якщо результат предиката – істина. Такі значення називаються членами типу.


Об’єктним типом називається тип, членами якого є об’єкти, що задовольняють даному типу.


Визначено такі основні (базові) типи даних:



Також можуть бути визначені складові типи:



Синтаксис Загальних Подання даних – CDR


CDR – Це спосіб представлення всіх типів даних, визначених у OMG IDL у вигляді послідовності восьмирозрядних величин, далі званих байтами.


Потік байт представляє з себе деяку абстракцію зазвичай відповідну буферу даних, який передається між процесами або машинами за допомогою засобів IPC або мережевого транспорту. Далі вважається, що потік байт або просто потік – це послідовність змінної (але кінцевої) довжини величин, що складаються з 8 біт (байт) з чітко визначеним заголовком. Байти в потоці нумеруються від 0 до n-1, де n – Це довжина потоку. Індекс кожного байта використовується для обчислення меж вирівнювання, як це описано далі.


Протокол GIOP визначає два види потоків – повідомлення і інкапсуляція. Повідомлення – це основна одиниця обміну інформацією в протоколі GIOP. Інкапсуляція – це потік, всередині якого будь-яка структура даних, наявна в OMG IDL може бути декодована незалежно від решти контексту повідомлення. Інкапсуляція дозволяє здійснювати попереднє кодування складних типів даних (таких як TypeCode) або обробляти частини повідомлень без вимоги повного його декодування.


Кодування базових типів


Всі базові типи можуть бути закодовані як набір байт. При цьому допускається використання як подання, в якому першим у потік поміщається найбільш значимий або найменш значущий байт. Заголовок повідомлення включає в себе прапор, який визначає порядок при кодуванні базових типів в повідомленні. Порядок байт всередині будь інкапсуляції може відрізнятися від порядку байт в повідомленні або інший інкапсуляції, усередині якої ця інкапсуляція знаходиться. Зміна порядку байт в разі необхідності покладається на одержувача повідомлення.


Для того, щоб зробити можливим приміщення і витяг значень базових типів в потік і з потоку за допомогою підпрограм, призначених для роботи саме з цими типами даних, всі базові типи даних при приміщенні в потік повинні бути вирівняні на свою природну кордон, тобто на число байт, яке без остачі ділиться на число байт, необхідних для подання цього типу. Таким чином значення, має розмір n повинно кодуватися з позиції m * n, де m – це ціле число. В CDR n може приймати значення 1, 2, 4 або 8. Якщо необхідно, то вирівняні значенням передує область мінімально можливого розміру, необхідного для вирівнювання. Значення байтів всередині цієї області не визначено.


Вирівнювання визначається щодо початку потоку. Перший байт в повідомленні або інкапсуляції має індекс 0.


Кодування складових типів


Вирівнювання складових типів не накладає ніяких додаткових вимог, крім тих, які застосовуються при кодуванні їх елементів.


Елементи структури кодуються в тому порядку, в якому вони визначені в описі на IDL. Кожен елемент кодується чином, відповідним його типу.


Об’єднання кодується значенням дискримінатора і членом об’єднання, відповідним даним значенням.


Масив кодується як послідовність його елементів. Так як довжина масиву фіксована, вона не кодується. Якщо масив має кілька вимірів, то перший індекс змінюється найбільш повільно, а останній – Найбільш швидко.


Послідовність елементів кодується як величина типу unsigned long, За яким слідують елементи послідовності. Це значення визначає кількість елементів. Кожен елемент кодується відповідно до свого типом.


Рядок кодується як величина типу unsigned long, Що містить довжину рядка, і окремими символами – елементами рядка. Довжина рядка і її представлення у вигляді списку символів включають завершальний нульовий символ, що дає можливість використання стандартних функцій бібліотеки мови C (наприклад, strcpy) для декодування повідомлення.


Значення перечислимого типу кодується у вигляді величини типу unsigned long, Що відповідає даному значенню. Першому в порядок перерахування у визначенні на IDL значенню відповідає 0, другому – 1 і так далі.


Кодування інкапсуляції


Перший байт інкапсуляції кодує порядок байт всередині неї – значення типу 0 означає кодування за принципом першим – старший байт, 1 – молодший. Далі йдуть дані. Прапор порядку байт не включається в дані, але він включається в інкапсуляцію. Всі значення всередині інкапсуляції вирівнюються щодо її початку, перший байт (з індексом 0) відповідно займає прапор порядку байт. Якщо інкапсуляція кодується як послідовність величин типу octet (Байтів), то їй передує значення типу unsigned long, Що містить загальний розмір інкапсуляції. Ніякого вирівнювання для інкапсуляції не передбачається, але такий спосіб кодування завжди гарантує 4-байтного вирівнювання для першого байта інкапсуляції.


Кодування псевдооб’ектов


Специфікація CORBA визначає кілька псевдооб’ектов, які не є ні базовими ні складовими типами і кодуються спеціальним чином. Через особливу специфічності даного кодування і воно тут не розглядається.


Операції


Операція представляє сервіс, виконання якого може бути запитано. Операція визначається ідентифікатором операції. Операція описується деякою сигнатурою, яка задає параметри запиту і повертається значення. Зокрема сигнатура складається з:



Сховище описів


Сховище описів представляє з себе сервіс, який забезпечується постійним об’єктом, доступному з програми. Під час виконання програми він дає доступ до інформації, аналогічної тій, що зберігається в IDL описі об’єкта. Ця інформація може бути використана для виконання запиту – таким чином, програма, яка не передбачала використання об’єкта будь-якого типу, визначити доступні у цього типу методи, типи його параметрів і здійснити виклик.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*