Архитектура на разпределени системи

1. Архитектура на разпределени системи

2. Цели • Да обясни предимствата и недостатъците на различните архитектури за разпределени с-ми, • Да се обсъдят архитектурите клиент-сървър и разпределени обекти • Да опише ORB (object request brokers) и принципите определящи стандартите на CORBA • Да въведе равнопоставените архитектури (peer-to-peer) и ориентираните към услуги с-ми като нови модели на разпределената обработка.

3. Основни теми • Многопроцесорна архитектура • Клиент-сървър архитектура • Разпределени обекти • Между-организационни архитектури

4. Разпределени системи • Виртуално всички големи с-ми сега са разпределени с-ми. • Обработката на информацията е разпределена м/у много машини. • Инженерингът на разпределените с-ми е много важен за компютърните с-ми на предприятията.

5. Типове системи • Персонални системи, които не са разпределени и са предназначени за персонален компютър или работна станция • Вградени (еmbedded) с-ми, които се изпълняват на единичен процесор или на интегрирана група от процесори • Разпределени с-ми, при които софтуерът се изпълнява на хлабаво свързани група процесори свързани в мрежа.

6. Характеристики на РС • Поделяне на ресурси • Поделят се софтуерни и хардуерни ресурси • Отвореност • Използване на хардуер и софтуер от различни източници • Конкурентност • Паралелна обработка за по-добра ефективност • Възможност за разширение(scalability) • Продуктивността се увеличава с добавката на нови ресурси • Нечувствителност към грешки • Способността да продължи една операция след настъпването на грешка

7. Недостатъци на РС • Сложност • Обикновено разпределените с-ми са по-сложни от централизираните. • Сигурност • По-податливи на външни атаки • Леснота за управление • Нужни са повече усилия за управлението им • Непредсказуемост • Непредсказуеми отговори зависещи от организацията на с-мата и на натоварването на мрежата

8. Архитектури на РС • Клиент-сървър • Разпределени услуги, които се искат от клиентите. Сървърите, които доставят услугите се държат и проектират различно от клиентите, които ползват услугите • Разпределени обекти • Няма разлики м/у клиент и сървър. Всеки обект в с-мата може да доставя на и да ползва услуги от друго обекти.

9. Мидълуер • Софтуер, който управлява и поддържа различни компоненти на разпределените с-ми. Всъщност, той стои в средата на с-мата. • Обикновено е готова компонента, а не специално разработен за случая софтуер. • Примери • Монитори за протичане на трансакциите; • Преобразователи на данни; • Комуникационни контролери;

10. Многопроцесорни архитектури • Най-простият модел • С-мата е съставена от множество процеси, които могат (но не задължително) да се изпълняват от различни процесори • Архитектурен модел на много с-ми за реално време • Разпределението на процесите към процесора може да е предопределено или да под управлението на диспечер

11. Многопроцесорна с-ма за управление на движението Процесор Процесор Процесор движение светофари сензори Процес за Процес Процес управл. управление дисплей светофари на сензорите светофари Сензори и камери Операторски конзоли за контрол на движението

12. Архитектура клиент-сървър • Приложението се моделира като набор от услуги, предоставяни от сървъри, и набор от клиенти ползващи тези услуги. • Клиентите познават сървърите, но не е нужно сървърите да знаят за клиентите. • Клиентите и сървърите са логически процеси. • Отношението м/у процесорите и процесите не е задължително 1 : 1.

13. С-ма клиент-сървър

14. Компютри в C/S мрежа

15. Слоеста архитектура • Представителен слой • Занимава се с представянето на резултатите на потребителите и въвеждането на входните данни. • Слой на приложните обработките • Занимава с доставката на специфичните функции на приложението, напр. в банкова с-ма това са откриване на сметка, закриване на сметка и др. • Слой за управление на данните • Занимава с управление на ситемните бази от данни.

16. Слоеве на приложението Представителен слой Слой на обработките Слой за управление на данните

17. Слаб и дебел клиент • Модел на слабия (thin) клиент • Цялата обработка и управление на данните се извършва от сървъра. Клиентът е отговорен само за представителния слой • Модел на дебелия (Fat) клиент • Сървърът е отговорен само за управлението на данните. Софтуерът на клиента осъществява логиката на приложението и взаимодействието с потребителя.

18. Слаб и дебел клиент

19. Модел на слабия клиент • Използва се, когато се мигрира от наследени с-ми към клиент-сървър архитектура. • Наследената с-ма действа като сървър, а графичният интерфейс се осъществява на клиента • Основен недостатък е, че оставя тежките обработки на сървърите и мрежата.

20. Модел на дебелия клиент • Обработките на приложението се извършват от клиентския софтуер. • По-подходящ за нови C/S с-ми, в които се знаят предварително възможностите на клиентската с-ма. • По-сложен от слабия клиент, особено за управление. Новите версии на приложението трябва да инсталират на всички клиенти.

21. ATM клиент-сървър с-ма A TM A TM Сървър на сметките Монитор База на на теле- клиентските сметки обработката A TM A TM

22. Три-възлова архитектура (Three-tier) • Всеки от слоевете може да се изпълнява на отделен процесор • Позволява по-добра ефективност от слабия клиент и е по-проста за управление от дебелия клиент, • По-приспособима архитектура – с увеличение на заявките може да се увеличи броя на сървърите.

23. 3-възлова C/S архитектура

24. Интернет банкираща система

25. Използване на C/S архитектурите

26. Разпределени обекти • Тук няма разлика м/у клиенти и сървъри. • Всеки разпределен обект доставя услуги на други обекти и получава услуги от други обекти. • Комуникация м/у обектите се осъществява от мидълуер с-ма наречена Брокер на обектните заявки (object request broker) или ORB. • Обаче, тази архитектура е по-сложна за проектиране от клиент-сървър архитектурата

27. Архитектура на разпределени обекти

28. Предимства на разпределените обекти • Позволява на системния проектант да отложи решението за това, къде и как трябва да се доставят услугите. • Много отворена с-ма, която позволява при нужда да се добавят нови ресурси. • С-мата е гъвкава и разширяема. • Възможно е при нужда да се преконфигурира с-мата динамично с обекти мигриращи в мрежата.

29. Използване на разпределените обекти • Като логически модел позволява да се структурира и организира с-мата. Може да се мисли за функционалността на приложението само с термините на услуги и комбинации от услуги. • Като гъвкав подход за осъществяването на клиент-сървър с-ма. Логическият модел е клиент-сървър, но и клиентът и сървърът се реализират като разпределени обекти, комуникиращи през обща комуникационна структура.

30. С-ма за дейта майнинг (data mining)

31. С-ма за дейта майнинг • За разлика от АТМ логическият модел е не за осигуряване на услуги с с добре определени услуги за управление на данни. • Той позволява да се увеличава броя на използваните бази от данни без да се разруши с-мата. • Позволява да се откриват нови типове отношения чрез добавянето на нови интегриращи обекти.

32. CORBA • CORBA е международен стандарт за ORB – мидълуер за управление на комуникацията м/у разпределени обекти. • Той изисква 2 нива: • На логическо комуникационно ниво той позволява на обектите от различни компютри да обменят данни и управляваща информация. • На компонентно ниво, той дава основа за разработване на съвместими компоненти. Дефинирани са CORBA компонентни стандарти.

33. Структура на CORBA приложение

34. Структура на приложението • Приложни обекти • Стандартни обекти, дефинирани от OMG, за специфична област, напр. застраховане. • Основни CORBA услуги като управление на директории и сигурност. • Хоризонтални (т.е които пресичат приложенията) като средства за потребителски интерфейс.

35. CORBA стандарти • Модел на обект за приложни обекти • CORBA обектът е капсулирано състояние с добре дефиниран, езиково неутрален интерфейс дефиниран на IDL (interface definition language). • Обектен брокер, който управлява заявките за услуги от обектите. • Набор от общи обектни услуги за използване от много разпределени приложения • Набор от общи компоненти изградени в/у тези услуги.

36. CORBA обекти • По принцип CORBA обектите са сравними с обектите в C++ и Java. • Те ТРЯБВА да имат отделна дефиниция на интерфейса, която се описва чрез общ език (IDL), подобен на C++. • Има съответствие м/у IDL и програмните езици (C++, Java, и др.) • Следователно обекти писани на различни езици могат да комуникират помежду си.

37. Обектен брокер на заявки (ORB) • ORB осигурява комуникацията м/у обектите. Той познава всички обекти в с-мата и техните интерфейси. • Като използва ORB, викащият обект свързва един IDL стъб, който дефинира интерфейса на извиквания обект. • Извикването на този стъб има за резултат извикване на ORB, който след това извиква искания обект чрез публикуван IDL скелет, който свързва интерфейса с осъществяването на услугата

38. Комуникация м/у обектите базирана на ORB

39. Между-ORB комуникации • Обикновено ORB не са отделни програми, а набор от обекти в библиотека, които се свързват с приложението при неговата разработка. • ORB осъществяват комуникацията м/у обектите на една и съща машина. • Много ORB могат да са на разположение и всеки компютър в разпределена с-ма има свой собствен ORB. • Между-ORB комуникациите се използват за извикване на разпределени обекти.

40. Между-ORB комуникации

41. CORBA услуги • Наименоване и преговори • Позволяват на обектите да откриват и да се обръщат към други обекти в мрежата. • Нотификация • Позволяват на обектите да известят други обекти са това, че е настъпило определено събитие. • Трансакции • Поддържат се атомарни трансакции и ролбек при неуспех.

42. Разпределени с-ми между различни организации • Повечето разпределени с-ми са осъществени на ниво организация по съображения за сигурност и оперативност. • Прилагат се местни стандарти, управление и работни процеси. • Разработват се нови модели, които да поддържат разпределение м/у организациите, където различните възли са разположени в различни организации.

43. Равнопоставени (Peer-to-peer)архитектури • Равнопоставените (p2p) с-ми са децентрализирани с-ми, в които всеки компютър в мрежата може да извършва всички операции. • Цялата с-ма е проектирана така, че да се възползва от мощността на голям брой компютри в мрежа. • Повечето p2p с-ми са от персонални компютри, но все повече се увеличава използването на тази технология от бизнеса.

44. P2p архитектурни модели • Архитектура на логическата мрежа • Децентрализирани архитектури; • Полу-централизирани архитектури; • Архитектура на приложението • Общата организация на компонентите съставящи p2p приложение • Тук се съсредоточаваме в/у архитектурата на мрежата

45. Децентрализирана p2p архитектура

46. Полу-нтрализирана p2p архитектура

47. Ориентирани към услуги архитектури • Основават се на понятието доставяни отвън услуги (уеб услуги) • Уеб услугата е стандартен подход да се направи една многократно използваема компонента достъпна в уеб пространството • Услуга за попълване на данъци поже да даде поддръжка на потребителите да попълнят данъчните си формуляри и да ги изпрати на данъчната служба

48. Услуга изобщо • Действие или работа предоставена от една страна на друга. Въпреки че процесът може да е свързан с физически продукт, работата е обикновено неосезаема и нормално не води до собственост на никой от посредниците. • Следователно доставянето на услугата е независимо от приложението използващо услугата

49. Уеб услуги Регистър на услуги Публикува Намира Заявител Доставчик Услуга на услуги на услуги Свързва се

50. Услуги и разпределени обекти • Независимост на доставчика • Публично обявяване на достъпните услуги • Скрито рън-тайм свързване с услугата • Опортюнистично изграждане на нови услуги чрез композиция. • Плащане за използване на услугите • По-малки, компактни приложения • Реактивни и адаптивни приложения