1 / 22

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

Интеграция на приложения. доц. д-р Станимир Стоянов ПУ “ Паисий Хилендарски ” , Катедра “ Компютърни систми ”. Модул “CORBA”. 8. CORBA базирана интероперативност. Съдържание. Достъп до обекти върху отдалечени ORBs Мащабируеми сървъри. Достъп до обекти върху отдалечени ORBs. Клиент.

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. Модул “CORBA” Станимир Стоянов

  3. 8. CORBA базирана интероперативност Станимир Стоянов

  4. Съдържание • Достъп до обекти върху отдалечени ORBs • Мащабируеми сървъри Станимир Стоянов

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

  6. Клиент Клиент Обект Обект Stub Stub Skel Skel ORB1 ORB2 Достъп до обекти върху отдалечен ORB Извикването се насочва към отдалечен обект Извикването се насочва към локален обект Станимир Стоянов

  7. При отдалечените извиквания клиентите не правят нищо различно в сравнение с локалния случай; • Те изпращат обичайното IDL-базирано извикване към техните локални ORB: • Ако извикването съдържа референция на обект, реализиран локално: • ORB го насочва към целевия обект; • В противен случай – го препраща към отдалечения ORB, който е host на целевия обект: • След това отдалечения ORB го насочва към целевия обект. Станимир Стоянов

  8. Клиентите не могат да определят формата на извикването или референцията, както и това дали целевият обект е локален или отдалечен; • Те могат да знаят, че целта е например обект на банкова сметка и обект за принтер; • Всички детайли, свързани с извикването се извършват от ORB: • Разрешаване на референции към специфичен отдалечен ORB или обект; • Транслиране реда на байтовете и форматите. Станимир Стоянов

  9. Всеки ORB трябва да поддържа една IR: • Когато се увеличат ORBs и интерфейсите, това става едно значително разпределено приложение, използващо БД; • Трябва да се синхронизират също така комуникациите – ORB мрежови протоколи и gateways; • CORBA архитектурата не занимава клиентите и приложните програмисти с този слой; • Клиентите и реализацията на обектите извършват или получават само локални извиквания: • понеже тяхната комуникация е през stub към техния локален ORB. • OMG стандартът гарантира, че ORB ще взаимодейства правилно с мрежата. Станимир Стоянов

  10. Многократно използване – интегриране на придобити реализации на обекти • Комуникацията между ORBs е ключово свойство, което доставя на CORBA допълнителна гъвкавост; • Клиентът и реализацията на обект могат да се разполагат: • Върху различни ORBs; • Върху различни платформи; • Различни операционни системи; • Различни мрежи; • Написани на различни езици; • Те ще взаимодействат перфектно, ако клиентът и обектът използват един и същ синтаксис и семантика. Станимир Стоянов

  11. Това от което се нуждае програмистът за създаване на един клиент, който има достъп до един отдаличен обект е следното: • Копие на неговия IDL файл; • Описание на това, което прави всяка операция; • Референция на обекта – в run-time. • Така лесно може да се интегрира доставени реализации на обекти. Станимир Стоянов

  12. Stub код Клиент Обект Stub Skel ORB ORB Обобщение Върху десктопа IDL Object Върху сървъра Skeleton код Клиентски код Language compiler, Linker Станимир Стоянов

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

  14. Инсталирането на поръчания софтуер се извършва на два етапа: • Сървърна страна: • Инсталираме обектите върху сървъра; • По време на инсталацията се генерират обектни референции, които могат автоматично да се разполагат в директорийна услуга или услуга за именуване или може да бъде записана във файла, към който имаме достъп. Станимир Стоянов

  15. Клиентска страна – пренестваме се към развойната платформата, която не трябва да бъде същата като тази, където ще работи обекта; • Зареждаме IDL файла • Компилираме го с локалния IDL компилатор • Отказваме се от генерирания skeleton – не ни е необходим • Използваме stub за достъп до ORB от клиента Станимир Стоянов

  16. Мащабируеми сървъри Станимир Стоянов

  17. CORBA-обектите могат да бъдат с различна големина; • В терминологията на архитектурата те могат да бъдат: • Fine-grained: • Например, множество от карти за разплащане в един сайт за електронна търговия; • Coarse–grained: • Например, счетоводна система на фирма. Станимир Стоянов

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

  19. CORBA притежава голямо множество от средства за създаване на скалируеми сървъри; • Вече разгледахме концепцията за инстанцииране: • Когато нов клиент иска да купува – създаваме нов обект-карта за пазаруване; • Веднъж създадена картата е налична – клиентът може да въвежда различни артикули, докато тя се даде на касиера за контрол; • След контрола картата се “затваря”; • Когато иска да пазарува отново – генерира се нова карта. Станимир Стоянов

  20. След като клиентът се върне отново след един определен период: • Какво трябва да прави клиентската програма за да използва отново картата за пазаруване? • Нищо специално: • Използва референцията към обекта за извикване на операции върху него: • Навярно съхранена в една бисквитка (cookie); • CORBA не поддържа активиращи и дезактивиращи операции; • От клиентска гледна точка един обект, веднъж инстанцииран работи непрекъснато докато не бъде премахнат явно. Станимир Стоянов

  21. От клиентска гледна точка всичко е наред; • Какво обаче трябва да направи сървърът за да може да поддържа обектите-карти за милиони клиенти? • Между отделните посещения картите могат да не се използват с дни или месеци: • Това натоварва допълнително изчислителните ресурси и затруднява обработката на актуалните карти. Станимир Стоянов

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

More Related