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

Software Engineering, 7th edition. Chapter 12 Slide 1

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


Цели

Да обясни предимствата и недостатъците на различните архитектури за разпределени с-ми,

Да се обсъдят архитектурите клиент-сървър и разпределени обекти

Да опише ORB (object request brokers) и принципите определящи стандартите на CORBA

Да въведе равнопоставените архитектури (peer-to-peer) и ориентираните към услуги с-ми като нови модели на разпределената обработка.


Основни теми

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


Разпределени системи

Виртуално всички големи с-ми сега са разпределени с-ми.

Обработката на информацията е разпределена м/у много машини.

Инженерингът на разпределените с-ми е много важен за компютърните с-ми на предприятията.


Типове системи

Персонални системи, които не са разпределени и са предназначени за персонален компютър или работна станция

Вградени (еmbedded) с-ми, които се изпълняват на единичен процесор или на интегрирана група от процесори

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


Характеристики на РС

Поделяне на ресурси• Поделят се софтуерни и хардуерни ресурси

Отвореност• Използване на хардуер и софтуер от различни

източници Конкурентност

• Паралелна обработка за по-добра ефективност Възможност за разширение(scalability)

• Продуктивността се увеличава с добавката на нови ресурси

Нечувствителност към грешки• Способността да продължи една операция след

настъпването на грешка


Недостатъци на РС

Сложност• Обикновено разпределените с-ми са по-сложни от

централизираните. Сигурност

• По-податливи на външни атаки Леснота за управление

• Нужни са повече усилия за управлението им Непредсказуемост

• Непредсказуеми отговори зависещи от организацията на с-мата и на натоварването на мрежата


Архитектури на РС

Клиент-сървър• Разпределени услуги, които се искат от

клиентите. Сървърите, които доставят услугите се държат и проектират различно от клиентите, които ползват услугите

Разпределени обекти• Няма разлики м/у клиент и сървър. Всеки

обект в с-мата може да доставя на и да ползва услуги от друго обекти.


Мидълуер

Софтуер, който управлява и поддържа различни компоненти на разпределените с-ми. Всъщност, той стои в средата на с-мата.

Обикновено е готова компонента, а не специално разработен за случая софтуер.

Примери• Монитори за протичане на трансакциите;• Преобразователи на данни;• Комуникационни контролери;


Многопроцесорни архитектури

Най-простият модел С-мата е съставена от множество процеси, които

могат (но не задължително) да се изпълняват от различни процесори

Архитектурен модел на много с-ми за реално време

Разпределението на процесите към процесора може да е предопределено или да под управлението на диспечер


Многопроцесорна с-ма за управление на движението

светофари

Процесуправл.светофари

Процесорсветофари

Процесордвижение

Операторски конзолиСензори и камериза контрол на движението

Процесорсензори

Процес за управление

на сензоритеПроцесдисплей


Архитектура клиент-сървър

Приложението се моделира като набор от услуги, предоставяни от сървъри, и набор от клиенти ползващи тези услуги.

Клиентите познават сървърите, но не е нужно сървърите да знаят за клиентите.

Клиентите и сървърите са логически процеси.

Отношението м/у процесорите и процесите не е задължително 1 : 1.


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

s1

s2 s3

s4c1

c2 c3 c4

c5

c6c7 c8

c9

c10

c11

c12

Client process

Server process


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

Network

SC1SC2

CC1 CC2 CC3

CC5 CC6CC4

Servercomputer

Clientcomputer

s1, s2 s3, s4

c5, c6, c7

c1 c2 c3, c4

c8, c9 c10, c11, c12


Слоеста архитектура

Представителен слой• Занимава се с представянето на резултатите

на потребителите и въвеждането на входните данни.

Слой на приложните обработките• Занимава с доставката на специфичните

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

Слой за управление на данните• Занимава с управление на ситемните бази

от данни.


Слоеве на приложението

Представителен слой

Слой на обработките

Слой за управлениена данните


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

Модел на слабия (thin) клиент

• Цялата обработка и управление на данните се извършва от сървъра. Клиентът е отговорен само за представителния слой

Модел на дебелия (Fat) клиент• Сървърът е отговорен само за управлението

на данните. Софтуерът на клиента осъществява логиката на приложението и взаимодействието с потребителя.


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

Thin-clientmodel

Fat-clientmodel Client

Client

Server

Data managementApplication processing

Presentation

Server

Data management

PresentationApplication processing


Модел на слабия клиент

Използва се, когато се мигрира от наследени с-ми към клиент-сървър архитектура.• Наследената с-ма действа като сървър, а

графичният интерфейс се осъществява на клиента

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


Модел на дебелия клиент

Обработките на приложението се извършват от клиентския софтуер.

По-подходящ за нови C/S с-ми, в които се знаят предварително възможностите на клиентската с-ма.

По-сложен от слабия клиент, особено за управление. Новите версии на приложението трябва да инсталират на всички клиенти.


ATM клиент-сървър с-ма

Сървър на сметките

База на клиентските

сметки

Мониторна теле-

обработката

ATM

ATM

ATM

ATM


Три-възлова архитектура (Three-tier)

Всеки от слоевете може да се изпълнява на отделен процесор

Позволява по-добра ефективност от слабия клиент и е по-проста за управление от дебелия клиент,

По-приспособима архитектура – с увеличение на заявките може да се увеличи броя на сървърите.


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

Client

Server

Datamanagement

PresentationServer

Applicationprocessing


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

Database server

Customeraccountdatabase

Web serverClient

Client

Account serviceprovision

SQLSQL query

HTTP interaction

Client

Client


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

Архитектура Приложение

Двувъзлова с-ма със слаб клиент

Наследени приложения, където не е практично да се разделят обработката и управлението на данните. Приложения с интензивни изчисления (компилатори), при които няма или почти липсва управление на данните. Приложения с много данни (сърфиране и заявки) с много малка или никаква обработка

Двувъзлова с-ма с дебел клиент

Приложения, при които обработката се извършва с конфекционен (напр. Microsoft Excel) софтуер на клиента. Приложения с много изчисления в/у данните (напр. визуализация на данните).. Приложения с относително стабилна функционалност за крайния потребител, използвани в среда с добре установено управление.

Три- или многовъзлова архитектура

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


Разпределени обекти

Тук няма разлика м/у клиенти и сървъри. Всеки разпределен обект доставя услуги

на други обекти и получава услуги от други обекти.

Комуникация м/у обектите се осъществява от мидълуер с-ма наречена Брокер на обектните заявки (object request broker) или ORB.

Обаче, тази архитектура е по-сложна за проектиране от клиент-сървър архитектурата


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

Object request broker

o1 o2 o3 o4

o5 o6

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)


Предимства на разпределените обекти

Позволява на системния проектант да отложи решението за това, къде и как трябва да се доставят услугите.

Много отворена с-ма, която позволява при нужда да се добавят нови ресурси.

С-мата е гъвкава и разширяема. Възможно е при нужда да се

преконфигурира с-мата динамично с обекти мигриращи в мрежата.


Използване на разпределените обекти

Като логически модел позволява да се структурира и организира с-мата. Може да се мисли за функционалността на приложението само с термините на услуги и комбинации от услуги.

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


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

Database 1

Database 2

Database 3

Integrator 1

Integrator 2

Visualiser

Display

Report gen.


С-ма за дейта майнинг

За разлика от АТМ логическият модел е не за осигуряване на услуги с с добре определени услуги за управление на данни.

Той позволява да се увеличава броя на използваните бази от данни без да се разруши с-мата.

Позволява да се откриват нови типове отношения чрез добавянето на нови интегриращи обекти.


CORBA

CORBA е международен стандарт за ORB – мидълуер за управление на комуникацията м/у разпределени обекти.

Той изисква 2 нива:• На логическо комуникационно ниво той позволява на

обектите от различни компютри да обменят данни и управляваща информация.

• На компонентно ниво, той дава основа за разработване на съвместими компоненти. Дефинирани са CORBA компонентни стандарти.


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

CORBA services

Domainfacilities

Horizontal CORBAfacilities

Applicationobjects

Object request broker


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

Приложни обекти Стандартни обекти, дефинирани от OMG,

за специфична област, напр. застраховане.

Основни CORBA услуги като управление на директории и сигурност.

Хоризонтални (т.е които пресичат приложенията) като средства за потребителски интерфейс.


CORBA стандарти

Модел на обект за приложни обекти• CORBA обектът е капсулирано състояние с добре

дефиниран, езиково неутрален интерфейс дефиниран на IDL (interface definition language).

Обектен брокер, който управлява заявките за услуги от обектите.

Набор от общи обектни услуги за използване от много разпределени приложения

Набор от общи компоненти изградени в/у тези услуги.


CORBA обекти

По принцип CORBA обектите са сравними с обектите в C++ и Java.

Те ТРЯБВА да имат отделна дефиниция на интерфейса, която се описва чрез общ език (IDL), подобен на C++.

Има съответствие м/у IDL и програмните езици (C++, Java, и др.)

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


Обектен брокер на заявки (ORB)

ORB осигурява комуникацията м/у обектите. Той познава всички обекти в с-мата и техните интерфейси.

Като използва ORB, викащият обект свързва един IDL стъб, който дефинира интерфейса на извиквания обект.

Извикването на този стъб има за резултат извикване на ORB, който след това извиква искания обект чрез публикуван IDL скелет, който свързва интерфейса с осъществяването на услугата


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

o1 o2

S (o1) S (o2)

IDLstub

IDLskeleton

Object Request Broker


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

Обикновено ORB не са отделни програми, а набор от обекти в библиотека, които се свързват с приложението при неговата разработка.

ORB осъществяват комуникацията м/у обектите на една и съща машина.

Много ORB могат да са на разположение и всеки компютър в разпределена с-ма има свой собствен ORB.

Между-ORB комуникациите се използват за извикване на разпределени обекти.


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

o1 o2

S (o1) S (o2)

IDLstub

IDLskeleton


o3 o4

S (o3) S (o4)

IDLstub

IDLskeleton


Network


CORBA услуги

Наименоване и преговори• Позволяват на обектите да откриват и да се

обръщат към други обекти в мрежата. Нотификация

• Позволяват на обектите да известят други обекти са това, че е настъпило определено събитие.

Трансакции• Поддържат се атомарни трансакции и ролбек

при неуспех.


Разпределени с-ми между различни организации

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

Прилагат се местни стандарти, управление и работни процеси.

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


Равнопоставени (Peer-to-peer) архитектури

Равнопоставените (p2p) с-ми са децентрализирани с-ми, в които всеки компютър в мрежата може да извършва всички операции.

Цялата с-ма е проектирана така, че да се възползва от мощността на голям брой компютри в мрежа.

Повечето p2p с-ми са от персонални компютри, но все повече се увеличава използването на тази технология от бизнеса.


P2p архитектурни модели

Архитектура на логическата мрежа• Децентрализирани архитектури;• Полу-централизирани архитектури;

Архитектура на приложението• Общата организация на компонентите

съставящи p2p приложение Тук се съсредоточаваме в/у

архитектурата на мрежата


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

n1

n2 n3

n4

n5

n6

n7

n8

n9 n10 n11

n12

n13

n13


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

Discoveryserver

n1

n2

n3

n4

n5

n6


Ориентирани към услуги архитектури

Основават се на понятието доставяни отвън услуги (уеб услуги)

Уеб услугата е стандартен подход да се направи една многократно използваема компонента достъпна в уеб пространството • Услуга за попълване на данъци поже да

даде поддръжка на потребителите да попълнят данъчните си формуляри и да ги изпрати на данъчната служба


Услуга изобщо

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

Следователно доставянето на услугата е независимо от приложението използващо услугата


Уеб услуги

Регистърна услуги

Заявителна услуги

Доставчикна услуги

Публикува

Свързва се

Намира

Услуга


Услуги и разпределени обекти

Независимост на доставчика Публично обявяване на достъпните услуги Скрито рън-тайм свързване с услугата Опортюнистично изграждане на нови услуги чрез

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


Стандарти за услуги

Услугите основават на общоприети, XML бзирани стандарти, така че да се доставят на всякакви платформи и да се пишат на всякакви програмни езици.

Основни стандарти:• SOAP - Simple Object Access Protocol;• WSDL - Web Services Description Language;• UDDI - Universal Description, Discovery and

Integration.


Сценарий за услуги

Една с-ма за информиране в колите доставя на водачите информация за времето, пътните условия, местни новини и др. Тя е свързана с радиото на колата и се предава като сигнал на специфичен радио канал.

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


Система за автомобили

User interface

Locator

Discovers carposition

Weatherinfo

Receives requestfrom user

Receiver

Receivesinformation stream

from services

Transmitter

Sends position andinformation request

to services

Radio

Translates digitalinfo stream toradio signal

In-car software system

Mobile Info Service

Facilitiesinfo

Translator

Roadlocator

Trafficinfo

Collates information

Road traffic info

commandgps coord

gpscoord gps coordgps coord

Languageinfo

Infostream

Service discovery

Finds availableservices


Разпределените с-ми поддържат поделянето на ресурси, отвореност, конкурентност, разширяемост, толерантност към грешки, прозрачност.

При клиент-сървър архитектурата сървърите доставят услуги на програми работещи на клиенти.

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

При разпределените обекти няма разлика м/у клиент и сървър.

Обобщение


Обобщение...

С-мите с разпределени обекти имат нужда от мидълуер за да поддържа комуникацията м/у обектите и да добавя и отстранява обекти.

• CORBA стандартите са набор от стандарти за мидълуера, които поддържат архитектурата с разпределени обекти.

• Равнопоставената архитектура е децентрализирана архитектура без разлика м/у клиент и сървър.

С-мите ориентирани кум услуги се създават чрез свързване на софтуерни услуги от различни доставчици.

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

Documents