Интеграция на приложения

Станимир Стоянов 1

Интеграция на приложения

доц. д-р Станимир СтояновПУ “Паисий Хилендарски”, Катедра “Компютърни систми”


Модул “CORBA”


8. CORBA базирана интероперативност


Съдържание

Достъп до обекти върху отдалечени ORBs

Мащабируеми сървъри


Достъп до обекти върху отдалечени ORBs


Клиент Обект

Stub Skel

ORB1

Клиент Обект

Stub Skel

ORB2

Достъп до обекти върху отдалечен ORB

Извикването се насочва към локален обект

Извикването се насочва към отдалечен обект


При отдалечените извиквания клиентите не правят нищо различно в сравнение с локалния случай;

Те изпращат обичайното IDL-базирано извикване към техните локални ORB: Ако извикването съдържа референция на обект,

реализиран локално: ORB го насочва към целевия обект;

В противен случай – го препраща към отдалечения ORB, който е host на целевия обект:

След това отдалечения ORB го насочва към целевия обект.


Клиентите не могат да определят формата на извикването или референцията, както и това дали целевият обект е локален или отдалечен;

Те могат да знаят, че целта е например обект на банкова сметка и обект за принтер;

Всички детайли, свързани с извикването се извършват от ORB: Разрешаване на референции към специфичен

отдалечен ORB или обект; Транслиране реда на байтовете и форматите.


Всеки ORB трябва да поддържа една IR: Когато се увеличат ORBs и интерфейсите, това

става едно значително разпределено приложение, използващо БД;

Трябва да се синхронизират също така комуникациите – ORB мрежови протоколи и gateways;CORBA архитектурата не занимава клиентите и приложните програмисти с този слой;Клиентите и реализацията на обектите извършват или получават само локални извиквания: понеже тяхната комуникация е през stub към

техния локален ORB.OMG стандартът гарантира, че ORB ще взаимодейства правилно с мрежата.


Комуникацията между ORBs е ключово свойство, което доставя на CORBA допълнителна гъвкавост;

Клиентът и реализацията на обект могат да се разполагат:

Върху различни ORBs; Върху различни платформи; Различни операционни системи; Различни мрежи; Написани на различни езици;

Те ще взаимодействат перфектно, ако клиентът и обектът използват един и същ синтаксис и семантика.

Многократно използване – интегриране на придобити реализации на обекти


Това от което се нуждае програмистът за създаване на един клиент, който има достъп до един отдаличен обект е следното:Копие на неговия IDL файл;Описание на това, което прави всяка

операция;Референция на обекта – в run-time.

Така лесно може да се интегрира доставени реализации на обекти.


Клиент

Stub

ORB

IDL

Клиентски код

Skeleton код Stub

код

Language compiler, Linker

Object

Обект

Skel

ORB

Върху десктопа Върху сървъра

Обобщение


Когато поръчваме софтуер от доставчици ще получим:Изпълнима реализация на обекти; IDL файл.


Инсталирането на поръчания софтуер се извършва на два етапа: Сървърна страна:

Инсталираме обектите върху сървъра;По време на инсталацията се генерират

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


Клиентска страна – пренестваме се към развойната платформата, която не трябва да бъде същата като тази, където ще работи обекта; Зареждаме IDL файла Компилираме го с локалния IDL

компилатор Отказваме се от генерирания skeleton – не

ни е необходим Използваме stub за достъп до ORB от

клиента


Мащабируеми сървъри


CORBA-обектите могат да бъдат с различна големина;

В терминологията на архитектурата те могат да бъдат:Fine-grained:

Например, множество от карти за разплащане в един сайт за електронна търговия;

Coarse–grained:Например, счетоводна система на фирма.


Когато създаваме напр. CORBA-базиран сайт за електронна търговия – трябва да решим проблема скалируемост; Т.е. – как ще се обслужва натоварването, което

очакваме използвайки наличните ресурси;

Може да се очакват хиляди или стотици хиляди клиенти да използват сайта.


CORBA притежава голямо множество от средства за създаване на скалируеми сървъри;

Вече разгледахме концепцията за инстанцииране: Когато нов клиент иска да купува – създаваме нов

обект-карта за пазаруване; Веднъж създадена картата е налична – клиентът

може да въвежда различни артикули, докато тя се даде на касиера за контрол;

След контрола картата се “затваря”; Когато иска да пазарува отново – генерира се

нова карта.


След като клиентът се върне отново след един определен период: Какво трябва да прави клиентската програма за да

използва отново картата за пазаруване?

Нищо специално: Използва референцията към обекта за извикване

на операции върху него: Навярно съхранена в една бисквитка (cookie);

CORBA не поддържа активиращи и дезактивиращи операции;

От клиентска гледна точка един обект, веднъж инстанцииран работи непрекъснато докато не бъде премахнат явно.


От клиентска гледна точка всичко е наред;

Какво обаче трябва да направи сървърът за да може да поддържа обектите-карти за милиони клиенти?

Между отделните посещения картите могат да не се използват с дни или месеци: Това натоварва допълнително изчислителните

ресурси и затруднява обработката на актуалните карти.


Каква инфраструктура на сървъра е необходима, която да позволява въвеждане и извеждане на CORBA обекти от оперативното пространство;Когато за една инстанция се поддържа персистентно състояние – при извеждане от оперативното пространство тя може да се съхрани във вторичната памет и след това да се възстанови отново;CORBA поддържа такава инфраструктура – нарича се Portable Object Adapter (POA);CORBA Component Model – използва също така POA.

Documents

Интеграция на приложения