|
Обща архитуктура за посредници при запитвания за обекти (CORBA)
CORBA специфицира система , която осигурява интероперативността между обектите в хетерогенна ,
разпределена среда , която е в известен смисъл ясна на програмиста. Нейният замисъл се баизра на
обектния модел на OMG.
Обектен модел на OMG
Обектния модел на OMG дефинира общата семантика на обектите при специфицирането на външните видими
харакеристики не обектите по стандартен и независим от имплементацията начин. При този модел клиентите
отправят заявки за услуги към обектите (те ще се наричат още сървъри), чрез добре дефиниран интерфейс.
Този интерфейс е специфициран в Езика за интерфейсни дефиниции (Interface Definition Language , IDL)
на OMG. Клиентът достига до обекта чрез подаване на заявка към обекта. Заявката е събитие , което носи информация,
включваща операцията, обектната референция, на доставчика на услуги и реалните параметри (ако има такива).
Обектната референция е име на обекта , което еднозначно го дефинира (обекта).
Основни механизми на подаването на заявка
Следващата схема показва най-важните компоненти на архитектурата на ORB и техните взаимовръзки.
Най-важният компонент на CORBA е Обектния брокер за заявки (Object Request Broker, ORB). Той включва
цялата инфраструктура , необходима за идентифицирането и определянето на обектите , обслужва управлението
на връзката и доставката на данни. Като цяло , не е задължително ORB да е един единствен компонент, той просто
е дефиниран чрез своите интерфейси. Ядрото на ORB е най-решаващата част от Обектния брокер за заявки, то е отговорно
за комуникацията на заявките.
Най-важната услуга, осигурявана от ORB се състои в предаването на заявки от клиентите към обектните
импламентации ,за които те са извикани. За да осъществи заявка , клиентът може да комуникира с ядрото на ORB чрез IDL
stub или чрез динамично извиквания интерфейс (DII). Stub представлява mapping между езика на имплементацията на клиента и
ядрото на ORB. Ето защо клиентът може да е реализиран на какъвто и да е език , стига имплементацията на ORB да поддържа този
mapping. Тогава ядрото на ORB може да пренесе заявката към имплементацията на обекта , която получава заявката като up-call или
чрез IDL скелета , или чрез динамичен скелет. Точно какво се случва можете да видите от следния прост пример.
Преглед на компонентите на архитектурата
Връзката между обектните имплементации и ядрото на ORB се реализира от обектния адаптор (Object Adaptor , OA). Той управлява услугите като
генериране и интерпретация на обектните референции, извикването на методи, сигурността на взимовръзките, активацията и деактивацията
на обектите и реализациите , поддържа референциите , отговарящи на обектните реализации и регистрацията на изпълненията. Очаква се ,че ще има много
различни обектни адаптери със специално предназначение за задоволяване на нуждите на специфичните системи (например бази данни).
OMG специфицира четири случая, в които ОА може да управлява активирането на обектна имплементация: Случай на споделен сървър , при която
множество обекти се изпълняват в рамките на една и съща програма, Случай на несподелен сървър, Случай на сървър-за-метод, при който се стартира нов сървър
всеки път , когато се получи заявка и случай на устойчив сървър.
Само в случая на ъстойчив сървър се очаква обектанта имплементация да е постоянно активна (ако не е - резултатът е системно изключение)
Ако в някои от останалите случаи бъде извикана заявка , обектът ще бъде активиран от OA по специфичния за случая начин.
За да бъде в състояние да извърши това действие , ОА трябва да има достъп до местоположението на обекта и опертивната среда.
Базите данни , съдържащи тази информация се наричат Хранилища на имплементации - Implementation Repository и те са стандартна част от архитектурата на
CORBA. Информацията се извлича от тях от ОА при активирането на обекта. Хранилищата на имплементации могат също така да съдържат информация относно реализациите
на сървърите, като например за debugging, за версията , както и административна информация.
Интерфейсите към обектите могат да бъдат специфицирани по два начина: или чрез OMG IDL , или могат да бъдат добавени в Хранилището за интерфейси ,което е друг
компонент на архитектурата. Динамичното извикване на интерфейси позволява на клиента да специфицира заявки към обекти, чиито дефиниции и интерфейс са му непознати
по времето на компилиране. За да използва DII, клиентът трябва да състави заявка (общо към всички ORB -и) в която да са включени: обектната референция, операцията
и списък с параметрите. Тези спецификации (на обектите и на услугите , които осигуряват) се получават от Хранилището на интерфейси - базата данни , която осигурява
устойчиво съхранение на интерфейсните дефиниции на обектите . Хранилището на интерфейси съдържа също така информация за типовете на параметрите, известна информация
за debugging и т.н.
От страна на сървъра , аналог на Динамичното извикване на интерфейси (DII) е Динамичният скелетен интерфейс (DSI);
с негова помощ операцията вече не е достъпна чрез специфичен за операцията скелет, генериран от IDL интерфейсната спецификация ,
а вместо това се достига от интерфейс , който осигурява достъп до името и параметрите на операцията (така, както в DII по-горе информацията може да бъде
възвърната от Хранилището на интерфейси).Така DII е начин да се доставят заявки от ORB към обектната реализация , която по време на компилацията няма информация
за обекта , който реализира. Въпреки , че на пръв поглед изглежда, че такава ситуация не се случва често , в действителност DII е отговор на средства за разработка на интерактивен
софтуер , базиран на интерпретатори и дебъгери. Той също така може да бъде използван и за осигуряване на интероперативност вътре в ORB , която е и тема на
следващия параграф.
Интероперативност
В момента има на разположение множество ORB продукти, тъхното разнообразие е много полезно, тъй като то позволява на търговците да пригодят продуктите си към
специфичните нужди на техните операционни среди. То също така води и до нуждата различните ORB да оперират помежду си. Още повече, име разпределени и/или клиентски/сървърски
системи, които не са CORBA-приложими и все по нарастваща е нуждата да бъде осигурена интероперативност между тези системи и CORBA. За да отговори на тези нужди
OMG формулира архитектура за интероперативността на ORB.
Разликите в имплементациите не са единствената бариера, която разделя обектите; по някакви причини може да са включени строги мерки за сигурност, или да бъде осигурена
защитена среда за тестове за продукти, които се разработват. За да бъде създадена напълно интероперативна среда, всички тези бъзможности трябва да бъдат взети под внимание.
Ето защо CORBA 2.0 представя на по-високо ниво концепцията за област, която приблизително обозначава сбор от обекти, които по някаква причина,
административна или касаеща имплементацията, са разделени от всички останали обекти. Ето защо обектите от различните области имат нужда от някакъв мостов
механизъм (mapping между домейните) с цел да си взаимодействат. Още повече, този мостов механизъм трябва да е достатъчно гъвкав, за да е пригоден както
за случаи , при които е необходима много малка или никаква транслация (като преминаването през административните области вътре в самия ORB), но е необходима ефикасност,
така също и за случаи, при които ефикасността може да е по-малка , но е необходимо да бъде осигурен общ достъп до ORB.
Подходите за постигане на интероперативност могат да бъдат разделени най-общо на непосредствен и посредствен мост
При метода на посредсвения мост елементите на един домейн се трансформират на границите на всеки домейн от вътрешната форма , характерна за този домейн във
някаква друга форма , която е договорена между домейните. Тази обща форма може да бъде или стандарт (специфициран от OMG, напр. IIOP), или частно споразумение между
две групи. При непосредствения мост елементите на взаимодействие се трансформират директно между вутрешните форми на домейна и останалите.
Втората възможност има потенциал за по-голяма бързина, но е по-малко общ, поради което би трябвало да може да се използват и двете. Когато посредничеството е
вътрешно за средата на изпълнение ( напр. TCP/IP), то е познато като "пълен мост", в противен случай , ако средата на изпълнение на ORB е различна от
общия протокол, ние казваме , че всеки ORB е "полу-мост".
 
Мостовете могат да бъдат реализирани както вътрещшно за ORB (просто при прекосяване на административните граници),
така и в слоевете над него. Ако те са реализирани вътре в ORB , то те се наричат in-line мостове , в другия случай се
наричат request-level мостове. In-line мостовете могат да са реализирани или чрез изискването ORB да осиугуряват определени
допълнителни услуги или чрез въвеждането на допълнителен код за stub и скелета. Взаимодействието чрез request-level мостове става
приблизително по следния начин: клиентския ORB "се преструва" , че мостът и сървърният ORB са части от обектната реализация и
и подава заявка към обекта чрез DSI (за DSI не е необходимо да се знае специифкацията за обекта по време на компилирането).
DSI , в сътрудничество с моста, транслира заявката във форма, която може да бъде разбрана от сървърния ORB и я извиква чрез DII
на сървърския ORB; резултатите (ако има такива) се предават обратно по подобен начин. Естествено , за да изпълнява своите функции
мостът трябва да знае нещо за обекта; поради тази причина му е необходимо или да има достъп до Хранилището за интерфейси, или
да бъде просто интерфейсен специфичен мост с "вградени" в него подходящи интерфейсни спецификации.
За да бъде възможно реализирането на мостове е необходимо да бъде специфициран някакъв стандартен синтаксис за трансфер.
Тази функция се изпълнява от Общия вътрешно-ORB протокол (General Inter-ORB Protocol, GIOP); той е специфично дефиниран да
посрещне нуждите на взаимодействието между ORB и ORB и е проектиран да работи с всички транспортни протоколи, които покриват
минимален брой изисквания. Разбира се, версиите на GIOP , реализирани чрез уптребата на различни транспортации, не е
задължително да са директно съвместими, тяхното взаимодействие ще бъде направено много по-ефективно.
Встрани от дефинирането на общ синтаксис за трансфер, OMG също така определиха каква ще бъде реализацията чрез използването на
TCP/IP и по тази причина специфициарха Интернет вътрешно-ORB протокол (Internet Inter-ORB Protocol, IIOP).
За да илюстрира отношението между GIOP и IIOP, OMG отбелязва, че то е като това между IDL и конкретния му mapping, например
C++ mapping. IIOP е проектиран да осигури имтероперативност "извън кутията" с други съвместими ORB- ове (TCP/IP е най-популярния
незвисим от дотавчиците транспортен слой). Още повече IIOP може също така да бъде използван като междинен слой между полу-мостове
и в допълнение към неговите интероперативни функции, доставчиците могат да го използват и за съобщения вътре в ORB (въреки , че това не се
изисква и е само страничен ефект към дефиницията му). Специифкацията също така осигурява и набор от Специифчни за средата
вътре- ORB протоколи (environment-Specific Inter-ORB Protocols, ESIOPs). Тези протоколи следва да бъдат използвани
за интероперативността, когато имплементациите , използващи тяхното транспортиране са общодостъпни.
|