CORBA -об'єкти та їх особливості

CORBA-об'єкти та їх особливості 2003-2007

Зміст • Створення CORBA-об'єктів. Interoperable Object Reference (IOR). • Репозиторні ідентифікатори (Repository ID). • CORBA-об'єкти, серванти та їх життєві цикли. Приклади. • Установлення зв'язку між клієнтом і серверним CORBA-об'єктом. • Стандартні засоби встановлення зв'язку. • Використання StringifiedIOR. CORBA-об'єкти та їх особливості

Створення CORBA-об'єкту – це створення на боці сервера логічного об'єкту (не фізичного, пам'ять безпосередньо під об'єкт не виділяється!) та спеціального (вже фізичного) посилання – інтероперабельного об'єктного посилання – Interoperable Object Reference (IOR). Саме IOR, при потребі, передається від одного ORB до іншого. IOR складається з Repository ID (як type_id) та послідовності профілів (profiles), що представляють підтримувані протоколи. Зокрема, для IIOP (він ґрунтується на використанні TCP/IP) структура профілю містить ім'я хосту, номер порту, ідентифікатор (ключ) об'єкта Object Key. Object Key у свою чергу містить ім'я адаптера (POA), який створив CORBA-об'єкт, та ObjectID, який ідентифікує CORBA-об'єкт, серед інших, створених адаптером. (Принагідно зауважимо, що у ролі фабрики CORBA-об'єктів виступає об'єктний адаптер POA). Створення CORBA-об'єктів.Interoperable Object Reference (IOR) struct IOR { string type_id; // Repository ID sequence < TaggedProfile> profiles; }; CORBA-об'єкти та їх особливості

Складові частини IOR у випадкупротоколаIIOP, який ґрунтується на TCP/IP: Repository ID; Profiles: Host IP; Host port; Object Key; POA name; Object ID; Можлива додаткова інформація. Складові частини IOR CORBA-об'єкти та їх особливості

Репозиторні ідентифікатори (Repository ID) генеруються IDL-компілятором idl2cpp,використовуючи формат OMG IDL. (Загалом, у CORBA використовується ще один формат на основі універсальних унікальних ідентифікаторів Середовища Розподілених Обчислень DCE – Distributed Computing Environment). Приклад: module MyModule { interface MyInterface { long MyMethod() }; }; Компілятором idl2cpp генеруються для окремих частин такого IDL-визначення наступні репозиторні ідентифікатори: IDL:MyModule:1.0 IDL:MyModule/MyInterface:1.0 IDL:MyModule/MyInterface/MyMethod:1.0 Репозиторні ідентифікатори CORBA-об'єкти та їх особливості

Можна впливати на генерацію окремих складових Repository ID, використовуючи наступні директиви (в IDL-файлі): #pragma prefix #pragma ID #pragma version Приклад 1. При використанні директиви #pragma prefix "omg.org”IDL-транслятором будуть генеруватись репозиторні ідентифікатори: omg.org:MyModule:1.0, omg.org:MyModule/MyInterface:1.0 omg.org: MyModule/MyInterface/MyMethod:1.0(зауважимо, що omg.org – це реальний префікс з orb.idl) Приклад 2. При використанні директиви #pragma MyMethod “KU:Method_KVF:2.0”транслятором для MyMethod буде генеруватись репозиторний ідентифікатор KU:Method_KVF:2.0 Репозиторні ідентифікатори та їх генерація IDL-компіляторами CORBA-об'єкти та їх особливості

СтворенняCORBA-об'єкту – це лише потенційна, але не реальна можливість клієнту скористатись функціональністю CORBA-об'єкта. Після створення CORBA-об'єкта можна “передати” (і для цього є різні можливості) IOR (IO-посилання) на цей об'єкт клієнтській програмі. Та цього замало для забезпечення реалізації клієнтських викликів. Щоб можна було скористатись функціональністю CORBA-об'єкта треба мати сервант (servant) цього CORBA-об'єкта. Сервант – це реальний програмний код, що реалізує експоновану CORBA-об'єктом (інтерфейсом) функціональність. Найчастіше (але не завжди!) сервант – це програмний об'єкт, який реалізує функціональність CORBA-об'єкта (інтерфейсу). (Borland-”майстрами” за IDL-описом інтерфейсу генерується клас реалізації, на основі якого можуть створюватись об'єкти-серванти). CORBA-об'єкти та серванти Створення CORBA-об'єкту – це створення на боці сервера логічного об'єкту (не фізичного, пам'ять безпосередньо під об'єкт не виділяється!) та спеціального (вже фізичного) посилання – інтероперабельного об'єктного посилання – Interoperable Object Reference (IOR). CORBA-об'єкти та їх особливості

CORBA-об'єкт та його серванти (їх може бути кілька протягом життєвого циклу CORBA-об'єкту, але не більше одного одночасно) мають незалежні життєві цикли. (Зокрема, відзначимо, що CORBA-об'єкти можуть залишатись “живими” навіть після перезапуску серверної програми). З огляду на наявність у CORBA-об'єкта серванта використовуються терміни "активний" та "неактивний" CORBA-об'єкт. Кажуть також про "активізацію" та "дезактивізацію" CORBA-об'єкта. Стосовно сервантів застосовуються терміни інкарнація та ефемерізація, коли, відповідно, встановлюється чи втрачається “зв'язок” CORBA-об'єкта з сервантом. У технології CORBA застосовуються різні механізми активізації CORBA-об'єктів та створення сервантів для CORBA-об'єктів. Зокрема, серванти можуть створюватись динамічно – у момент, коли надходить запит від клієнта, при тому можуть серванти створюватись “під один запит” чи на тривалий час. CORBA-об'єкти, сервантита їх життєві цикли CORBA-об'єкти та їх особливості

PortableServer::ObjectId_var objID1 = PortableServer::string_to_ObjectId("Ob"); CORBA::Object_var oRef = myPOA->create_reference_with_id( objID1,"IDL:sm:1.0"); СтворенняCORBA-об'єктів та сервантів. Приклади Створення CORBA-об'єкта без серванта Repository ID interface sm { float add(in float a1,in float a2); }; smImpl servant; PortableServer::ObjectId_var objID = PortableServer::string_to_ObjectId ("MyObject"); myPOA->activate_object_with_id (objID, &servant); Створення активногоCORBA-об'єкта (з сервантом) Явна активізація CORBA-об'єкта CORBA-об'єкти та їх особливості

Варіанти активізації CORBA-об'єктів: явна активізація; активізація за вимогою; неявна активізація; активізація із сервантом за замовчуванням. Варіанти активізації CORBA-об'єктів CORBA-об'єкти та їх особливості

Активізація за вимогою (з використанням ServantActivator). Приклад Створено CORBA-об'єкт без серванту Реєстрація менеджера сервантів Запуск сервера (USE_SERVANT_MANAGER, RETAIN) Запуск клієнта CORBA-об'єкти та їх особливості

Активізація за вимогою (з використанням ServantActivator). Приклад інкарнації CORBA-об'єкти та їх особливості

Активізація за вимогою (з використанням ServantActivator). Ілюстрація до прикладу Запуск сервера (USE_SERVANT_MANAGER, RETAIN) Запуск клієнта CORBA-об'єкти та їх особливості

Активізація за вимогою (з використаннямсерванта за замовчуванням).Приклад Створено два CORBA-об'єкти, обидва “без” сервантів “Реєстрація” серванта за замовчуванням Запуск Smart Agent Запуск сервера (USE_DEFAULT_SERVANT) Запуск клієнта CORBA-об'єкти та їх особливості

Активізація за вимогою (з використаннямсерванта за замовчуванням).Ілюстрація до прикладу Запуск Smart Agent Запуск сервера (USE_DEFAULT_SERVANT) Запуск клієнта CORBA-об'єкти та їх особливості

Установлення зв'язку між клієнтом і серверним CORBA-об'єктом полягає в отримуванні клієнтом інтероперабельного об'єктного посиланняIOR на цей об'єкт. (IOR – Interoperable Object Reference). Термінологія CORBA – “клієнт зв'язується (bind) з CORBA-об'єктом сервера”. Клієнт має отримати посилання IORна CORBA-об'єкт, вважаючи, що той вже існує. Клієнт ніколи не створює CORBA-об'єкт, а тільки зв'язується з ним. Установлення зв'язку між клієнтом і серверним CORBA-об'єктом Створення CORBA-об'єкту – це створення на боці сервера логічного об'єкту та IOR як реального даного. CORBA-об'єкти та їх особливості

1. Стандартні засобиCORBA, що дозволяють зробити серверний об'єкт доступним для клієнта, тобто, дозволяють отриматиIOR: Naming Service; Trader Service; використання функції string_to_object. Наприклад, функція object_to_string дозволяє з посилання IOR отримати рядок SIOR (StringifiedIOR). Цей рядок можна якимось чином передати клієнту (файл, e-mail, звичайна пошта тощо) та знову перетворити його у посилання IOR., скориставшись уже функцією string_to_object 2. Нестандартний засібVisiBroker – Smart Agent з нестандартної служби Location Service. Установлення зв'язку між клієнтом і серверним CORBA-об'єктом. Стандартні засобиCORBA interface ORB { // PIDL . . . string object_to_string (in Object obj); Object string_to_object (in string str); ...} CORBA-об'єкти та їх особливості

Три схеми (шаблони) рядків, розрахованих на застосування у string_to_object: 1. IOR-схема (рядок у вигляді “IOR: . . .”). 2. URL-схема corbaloc corbaloc:[протокол]:[адреса][“/”<Object_Key як частина StringifiedIOR >] Протоколи: iiop (за замовчуванням); rir – для об'єктних посилань, що отримуються при використанні метода resolve_initial_reference. Приклад: corbaloc::my_server.my_company.com:1050/NameServiceЗа вказаною IP- адресою (хост, порт) має бути програма, яка здатна обробляти Corba-запити та Corba-об'єкт якої має відповідний Object Key. Функціяstring_to_object. ВикористанняURLу CORBA interface ORB { // PIDL . . . string object_to_string (in Object obj); Object string_to_object (in string str); ...} CORBA-об'єкти та їх особливості

3. URL-схема corbaname: corbaname: <corbaloc-URL служби іменування COS Naming >#<INS-ім'я>. Зауважимо, що на відміну від попередньої, можна сказати, універсальної URL-схеми, ця схема розрахована на застосування служби іменування COS Naming. Приклад: corbaname::my_server.my_company.com: 1050/NameService#my_context/my_obТут підрядок “/NameService” можна не вказувати (замовчування), оскільки застосування служби іменування у цій схемі є обов'язковим. Кроки обчислення об'єктного посилання IOR: за зазначеною адресою (першою частиною corbaname) отримується об'єктне посилання на службу іменування. за іменем у стилі INS (другою частиною corbaname), використовуючи вже визначену службу іменування, отримується шукане посилання на Corba-об'єкт. ВикористанняURLу CORBA. Функціяstring_to_object (прод.) CORBA-об'єкти та їх особливості

Оbject_to_string, SIOR (Stringified IOR).Фрагменти серверного проекта Створено активний CORBA-об'єкт з сервантом Запис SIOR у файл CORBA-об'єкти та їх особливості

CORBA::ORB_var orb = CORBA::ORB_init(__argc, __argv); ifstream inp_file ("MyORef.ior"); inp_file >> str; inp_file.close(); CORBA::Object_var obj = orb->string_to_object (str); sm_var objRef = sm::_narrow (obj); objRef->add(...,...); IOR:012020200b00000049444c3a736d3a312e30002002000000015349565c000000010102200f00000043505131353833363330323337310020040a0000000000003300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f410020000000000000000050000000010102200a0000003132372e302e302e3100c00b3300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f41002000000000 Отримання клієнтом IOR на основі файлу із SIOR. Фрагменти клієнтського проекту Запуск сервера Запуск клієнта CORBA-об'єкти та їх особливості

Приклади застосування встановлення зв'язку між клієнтом і серверним CORBA-об'єктом із використанням SIOR: потреба зберегти зв'язок із серверним об'єктом на тривалий час (протягом якого клієнтський процес зупиняється); потреба зберегти посилання на ключові фабрики об'єктів CORBA (чи псевдооб'єктів) або на ключові об'єкти на зразок служби іменування (Naming Service), Trader-служби; потреба зберегти посилання на репозиторій інтерфейсів (InterfaceRepository). Загалом, вважається, що SIOR надає максимально зручний засіб для встановлення зв'язку між клієнтом і серверним CORBA-об'єктом для різних продуктів ORB. Установлення зв'язку між клієнтом і серверним CORBA-об'єктом із використанням SIOR CORBA-об'єкти та їх особливості

IOR:012020200b00000049444c3a736d3a312e30002002000000015349565c000000010102200f00000043505131353833363330323337310020040a0000000000003300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f410020000000000000000050000000010102200a0000003132372e302e302e3100c00b3300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f41002000000000IOR:012020200b00000049444c3a736d3a312e30002002000000015349565c000000010102200f00000043505131353833363330323337310020040a0000000000003300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f410020000000000000000050000000010102200a0000003132372e302e302e3100c00b3300000001504d43000000000b00000049444c3a736d3a312e300020090000004d794f626a65637400202020070000002f4d79504f41002000000000 Stringified IOR Stringified IOR, згенерований вдруге на тому ж комп'ютері Stringified IOR, згенерований на іншому комп'ютері CORBA-об'єкти та їх особливості

Додаток CORBA-об'єкти та їх особливості

// an Interoperable Object Reference is a sequence of // object-specific protocol profiles, plus a type ID. struct IOR { string type_id; //Repository ID sequence <TaggedProfile> profiles; }; struct TaggedProfile { ProfileId tag; sequence <octet> profile_data; }; typedef unsigned long ProfileId; const ProfileId TAG_INTERNET_IOP = 0; const ProfileId TAG_MULTIPLE_COMPONENTS = 1; IOR (файлIOP.idl) CORBA-об'єкти та їх особливості

struct ProfileBody_1_1 {// also used for 1.2 Version iiop_version; string host; unsigned short port; sequence <octet> object_key; // Added in 1.1 unchanged for 1.2 sequence <IOP::TaggedComponent> components; }; ProfileBody_1_1 (файл IIOP.idl) CORBA-об'єкти та їх особливості

struct RequestHeader_1_2 { // GIOP 1.2 unsigned long request_id; octet response_flags; octet reserved[3]; TargetAddress target; string operation; // Principal not in GIOP 1.2 IOP::ServiceContextList service_context; // 1.2 change }; struct ReplyHeader_1_2 { unsigned long request_id; ReplyStatusType_1_2 reply_status; IOP::ServiceContextList service_context; // 1.2 change }; Заголовки Request- та Reply-повідомлень (файл GIOP.idl) CORBA-об'єкти та їх особливості

typedef short AddressingDisposition; const short KeyAddr = 0; const short ProfileAddr = 1; const short ReferenceAddr = 2; struct IORAddressingInfo { unsigned long selected_profile_index; IOP::IOR ior; }; union TargetAddress switch (AddressingDisposition) { case KeyAddr: sequence <octet> object_key; case ProfileAddr: IOP::TaggedProfile profile; case ReferenceAddr: IORAddressingInfo ior; }; enum ReplyStatusType_1_2 { NO_EXCEPTION, USER_EXCEPTION, SYSTEM_EXCEPTION, LOCATION_FORWARD, LOCATION_FORWARD_PERM, // new value for 1.2 NEEDS_ADDRESSING_MODE // new value for 1.2 }; Дані з Request- та Reply-повідомлень (файл GIOP.idl) CORBA-об'єкти та їх особливості

General Inter-ORB Protocol (GIOP) – загальний (універсальний) між-ORB (міжброкерний) протокол. Загалом описуються (з використанням IDL) вісім варіантів повідомлень. // File: GIOP.idl // From CORBA 3.0: Chapter 15, General Inter-ORB Protocol // GIOP 1.1 enum MsgType_1_1{ Request, Reply, CancelRequest, LocateRequest, LocateReply, CloseConnection, MessageError, Fragment // GIOP 1.1 addition }; General Inter-ORB Protocol CORBA-об'єкти та їх особливості

Request-повідомлення: заголовок повідомлення містить, зокрема, ідентифікатор запиту, адресу цільового об'єкту (типу TargetAddress), ім'я методу, що викликається; тіло повідомлення містить значення in-, inout-аргументів методу, що викликається. Reply-повідомлення: заголовок повідомлення містить, зокрема, ідентифікатор запиту (того Request-повідомлення, відповіддю на яке є дане Reply-повідомлення), ознаку завершення (наприклад, NO_EXEPTION, USER_EXEPTION, SYSTEM_EXEPTION тощо); тіло повідомлення у випадку NO_EXEPTION містить обчислені значення out-, inout-аргументів метода, що був виконаний. General Inter-ORB Protocol. Request- та Reply-повідомлення CORBA-об'єкти та їх особливості

CORBA -об'єкти та їх особливості