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

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

Възражда се подход за изграждане на разпределени системи, базирани на peer-to-peer архитектура, при който, за разлика от доминиращата днес в разпределените системи архитектура клиент-сървър, ролите на взаимодействащите страни в мрежата не са фиксирани. Те се назначават в зависимост от ситуацията в мрежата, от натоварването на нейните възли.

Във връзка с интензивното развитие на комуникационните технологии активно се развива мобилната AIS. Разработени са техническите средства и софтуерът за тяхното създаване. Това доведе до разработването на мобилни системи за бази данни. Много изследователски екипи провеждат изследвания върху специфичните характеристики на такива системи и създават техните различни прототипи. Java технологиите се превърнаха във важен инструмент за разработка на мобилен софтуер.

Създаден е стандарт за Wireless Application Protocol (WAP), който вече се поддържа от някои модели мобилни телефони. Базиран на WAP и XML, W3C разработи език за маркиране за безжични комуникации, WML (Wireless Markup Language).

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

AIS използва различни начини и средства за представяне на метаданни (различни видове хранилища на метаданни). Липсата на унификация в тази област значително усложнява решаването на проблемите с мобилността на приложенията, повторното използване и интегрирането на информационните ресурси и информационните технологии, както и реинженеринга на AIS.

За преодоляване на тези трудности активно се преследва разработването на стандарти за метаданни, фокусирани върху различни информационни технологии. В тази област вече съществуват редица международни, национални и индустриални стандарти, които определят представянето на метаданни и обмена на метаданни в AIS. Някои от тях вече са придобили статут на де факто стандарти. Тук ще се ограничим да споменем само най-значимите от тях.

Вероятно първият де факто стандарт за тази категория беше езикът за описание на данни CODASYL за мрежови бази данни. Следва да се назоват следните стандарти: стандартът на SQL езика за заявки за релационни бази данни, съдържащ дефиницията на т. нар. информационна схема - набор от представяния на схеми на релационни бази данни; стандартният компонент на базата данни за обекти ODMG, който описва интерфейсите на хранилището на схемата на обекта; международен стандарт IRDS (Information Resource Dictionary Systems), който описва системи за създаване и поддържане на директории с информационни ресурси на организация.

След това трябва да се спомене стандартът Common Warehouse Metamodel (CWM) за представяне на метаданни за хранилища на данни, разработени от консорциума OMG, въз основа на предварително създаден за по-широки цели стандарт OIM (Open Information Model) от консорциума MDC (Meta Data Coalition). .

Новият XML за уеб технологичната платформа включва и стандарти за представяне на метаданни. Поддръжката на метаданни е една от най-важните иновации в мрежата, която коренно променя технологията за управление на нейните информационни ресурси. Докато поддръжката на метаданни първоначално се изискваше в технологиите за бази данни, метаданните не се поддържаха в мрежата от първо поколение.

Стандартите за уеб метаданни включват подмножество от езика XML, използван за описване на логическата структура на някакъв тип XML документ. Това описание се нарича DTD (Определение на типа на документа). В допълнение, XML платформата включва стандарта XML Schema, който предлага по-разширени възможности за описание на XML документи. Стандартът Resource Definition Framework (RDF) дефинира прост език за представяне на знания за описание на съдържанието на XML документи. И накрая, нововъзникващият стандарт OWL (онтологичен уеб език) дефинира формален език за описание на онтологията за семантичната мрежа.

Стандартът Unified Modeling Language (UML), който осигурява представяне на метаданни за CASE визуален обектен анализ и инструменти за проектиране, е разработен от консорциума OMG. Този език се поддържа в много софтуерни продукти на CASE. OMG също така създаде стандарта за обмен на метаданни XML (XMI) за обмен на метаданни между CASE инструменти с помощта на UML.

Тук трябва да се спомене и стандартът Dublin Core (DC), набор от елементи на метаданни за описание на съдържанието на документи от различно естество. Този стандарт бързо придоби популярност и по-специално намери широко приложение в уеб средата (вж. Раздел 3.3).

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

Според известния експерт в областта на компютърните науки Е. Таненбаум няма общоприета и в същото време строга дефиниция за разпределена система. Някои умници твърдят, че разпределеното е такова изчислителна система, при което неизправност на компютър, за чието съществуване потребителите дори не са подозирали преди, води до прекратяване на цялата им работа. Значителна част от разпределените изчислителни системи, за съжаление, отговарят на това определение, но формално се отнася само до системи с уникална точка на уязвимост ( единична точка на провал).

Често, когато се дефинира разпределена система, фокусът е върху разделянето на нейните функции между няколко компютъра. С този подход всяка се разпределя изчислителна системакъдето обработката на данни е разделена между два или повече компютъра. Въз основа на дефиницията на Е. Таненбаум, малко по-тясно разпределена система може да се определи като съвкупност от независими компютри, свързани с комуникационни канали, които от гледна точка на потребителя на някакъв софтуер изглеждат като едно цяло.

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

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

Ориз. 1.1.

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

Ориз. 1.2.

Помислете за определено типично приложение, което в съответствие със съвременните концепции може да бъде разделено на следните логически нива (фиг. 1.2): потребителски интерфейс(PI), логика на приложението (LP) и достъп до данни (DD), работа с база данни (DB). Потребителят на системата взаимодейства с нея чрез потребителския интерфейс, базата данни съхранява данни, описващи домейна на приложението, а логическият слой на приложението реализира всички алгоритми, свързани с предметна област.

Тъй като на практика различни потребители на системата обикновено се интересуват от достъп до едни и същи данни, най-простото разделяне на функциите на такава система между няколко компютъра ще бъде разделянето на логическите слоеве на приложението между една сървърна част на приложението , който отговаря за достъпа до данните, и клиентските части, разположени на няколко компютъра.реализиращи потребителския интерфейс. Логиката на приложението може да бъде присвоена на сървъра, клиентите или споделена между тях (Фигура 1.3).

Ориз. 1.3.

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

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

Ориз. 1.4.

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

В предишната глава разгледахме тясно свързани многопроцесорни системи със споделена памет, споделени структури от данни на ядрото и споделен пул, от който се извикват процесите. Често обаче е желателно процесорите да се разпределят по такъв начин, че да са автономни от работната среда и работните условия за целите на споделянето на ресурси. Да предположим, например, че потребител на персонален компютър трябва да получи достъп до файлове, разположени на по-голяма машина, но в същото време да запази контрола над персоналния компютър. Въпреки че някои програми, като uucp, поддържат мрежов трансфер на файлове и други мрежови функции, тяхното използване няма да бъде скрито от потребителя, тъй като потребителят е наясно, че използва мрежата. Освен това трябва да се отбележи, че програми като текстови редактори не работят с изтрити файлове, както с обикновените. Потребителите трябва да имат стандартния набор от системни функции на UNIX и освен потенциалното затруднение в производителността, не трябва да усещат преминаването на границите на машината. Така, например, работата на системните функции, отворени и четени с файлове на отдалечени машини, не трябва да се различава от работата им с файлове, принадлежащи на локални системи.

Архитектурата на разпределената система е показана на Фигура 13.1. Всеки компютър, показан на фигурата, е самостоятелна единица, състояща се от процесор, памет и периферни устройства. Моделът не се разваля, въпреки че компютърът няма локална файлова система: той трябва да има периферни устройства, за да комуникира с други машини и всички файлове, принадлежащи към него, могат да бъдат разположени на друг компютър. Физическата памет, достъпна за всяка машина, е независима от процесите, изпълнявани на други машини. В това отношение разпределените системи се различават от тясно свързаните многопроцесорни системи, разгледани в предишната глава. Съответно, ядрото на системата на всяка машина функционира независимо от външните работни условия на разпределената среда.

Фигура 13.1. Модел на системата с разпределена архитектура

Разпределените системи, добре описани в литературата, традиционно попадат в следните категории:

Периферни системи, които са групи от машини, които имат силна общност и са свързани с една (обикновено по-голяма) машина. Периферните процесори споделят натоварването си с централния процесор и препращат всички повиквания към операционната система към него. Целта на периферната система е да повиши общата производителност на мрежата и да осигури възможност за разпределяне на процесор към един процес в UNIX операционна среда. Системата стартира като отделен модул; За разлика от други модели на разпределени системи, периферните системи нямат реална автономия, освен в случаите, свързани с диспечиране на процеси и локално разпределение на паметта.

Разпределени системи като "Нюкасъл", позволяващи отдалечена комуникация чрез имената на отдалечени файлове в библиотеката (името е взето от статията "The Newcastle Connection" - виж). Изтритите файлове имат спецификация (отличително име), която в пътя за търсене съдържа специални знаци или незадължителен компонент за име, който предхожда корена на файловата система. Прилагането на този метод не включва извършване на промени в ядрото на системата и следователно е по-просто от другите методи, разгледани в тази глава, но по-малко гъвкаво.

Разпределените системи са напълно прозрачни, в които стандартните отличителни имена са достатъчни, за да се отнасят до файлове, намиращи се на други машини; от ядрото зависи да разпознае тези файлове като изтрити. Пътеките за търсене на файлове, посочени в съставните им имена, пресичат границите на машината в точките на монтиране, без значение колко такива точки се образуват, когато файловите системи са монтирани на дискове.

В тази глава ще разгледаме архитектурата на всеки модел; цялата предоставена информация не се основава на резултатите от конкретни разработки, а на информация, публикувана в различни технически статии. Това предполага, че протоколните модули и драйверите на устройства са отговорни за адресирането, маршрутизирането, контрола на потока и откриването и коригирането на грешки - с други думи, че всеки модел е независим от използваната мрежа. Примерите за използване на системни функции, показани в следващия раздел за периферни системи, работят по подобен начин за системи като Нюкасъл и за напълно прозрачни системи, които ще бъдат обсъдени по-късно; затова ще ги разгледаме подробно веднъж, а в разделите, посветени на други видове системи, ще се съсредоточим основно върху характеристиките, които отличават тези модели от всички останали.

13.1 ПЕРИФЕРНИ ПРОЦЕСОРИ

Архитектурата на периферната система е показана на Фигура 13.2. Целта на тази конфигурация е да подобри цялостната производителност на мрежата чрез преразпределяне на изпълняваните процеси между централния процесор и периферните процесори. Всеки от периферните процесори няма на разположение никакви други локални периферни устройства, освен тези, които са му необходими за комуникация с централния процесор. Файловата система и всички устройства са на разположение на централния процесор. Да предположим, че всички потребителски процеси се изпълняват на периферния процесор и не се движат между периферните процесори; веднъж прехвърлени в процесора, те остават на него до завършване. Периферният процесор съдържа олекотена версия на операционната система, предназначена да обработва локални повиквания към системата, управление на прекъсвания, разпределение на паметта, мрежови протоколи и драйвер за комуникация с централния процесор.

Когато системата се инициализира на централния процесор, ядрото зарежда локалната операционна система на всеки от периферните процесори чрез комуникационни линии. Всеки процес, изпълняващ се в периферията, е свързан със сателитен процес, принадлежащ на централния процесор (вижте); когато процес, изпълняващ се на периферен процесор, извика системна функция, която изисква услугите само на централния процесор, периферният процес комуникира със своя сателит и заявката се изпраща до централния процесор за обработка. Сателитният процес изпълнява системна функция и изпраща резултатите обратно на периферния процесор. Връзката между периферен процес и неговия сателит е подобна на връзката клиент-сървър, която обсъдихме подробно в Глава 11: периферният процес действа като клиент на неговия сателит, който поддържа функциите за работа с файловата система. В този случай процесът на отдалечен сървър има само един клиент. В раздел 13.4 ще разгледаме сървърните процеси с множество клиенти.

Фигура 13.2. Конфигурация на периферна система

Фигура 13.3. Формати на съобщения

Когато периферен процес извика системна функция, която може да бъде обработена локално, ядрото не трябва да изпраща заявка до сателитния процес. Така например, за да получи допълнителна памет, процесът може да извика функцията sbrk за локално изпълнение. Въпреки това, ако услугите на централния процесор са необходими, например, за отваряне на файл, ядрото кодира информация за параметрите, предадени на извиканата функция, и условията за изпълнение на процеса в съобщение, изпратено до сателитния процес (Фигура 13.3). Съобщението включва знак, от който следва, че системната функция се изпълнява от сателитния процес от името на клиента, параметри, предавани на функцията и данни за средата за изпълнение на процеса (например потребителски и групови идентификационни кодове), които са различни за различните функции. Останалата част от съобщението са данни с променлива дължина (например, сложно име на файл или данни, които трябва да бъдат записани с функцията за запис).

Сателитният процес чака заявки от периферния процес; когато се получи заявка, той декодира съобщението, определя типа на системната функция, изпълнява я и преобразува резултатите в отговор, изпратен до периферния процес. Отговорът, в допълнение към резултатите от изпълнението на системната функция, включва съобщението за грешка (ако има такова), номера на сигнала и масив от данни с променлива дължина, съдържащ, например, информация, прочетена от файл. Периферният процес е спрян до получаване на отговор, след като го получи, той декриптира и предава резултатите на потребителя. Това е общата схема за обработка на повиквания към операционната система; сега нека преминем към по-подробно разглеждане на отделните функции.

За да обясните как работи периферната система, разгледайте редица функции: getppid, open, write, fork, exit и signal. Функцията getppid е доста проста, тъй като се занимава с прости формуляри за заявка и отговор, които се обменят между периферното устройство и процесора. Ядрото на периферния процесор генерира съобщение, което има знак, от който следва, че исканата функция е функцията getppid, и изпраща заявката до централния процесор. Сателитният процес на централния процесор чете съобщението от периферния процесор, дешифрира типа на системната функция, изпълнява я и получава идентификатора на своя родител. След това генерира отговор и го предава на чакащ периферен процес в другия край на комуникационната линия. Когато периферният процесор получи отговор, той го предава на процеса, който извика системната функция getppid. Ако периферният процес съхранява данни (като идентификатора на процеса на родителя) в локалната памет, той изобщо не трябва да комуникира със своя спътник.

Ако се извика отворената системна функция, периферният процес изпраща съобщение до своя спътник, което включва името на файла и други параметри. Ако е успешен, придружаващият процес разпределя индекс и входна точка към файловата таблица, разпределя запис в таблицата на потребителския файлов дескриптор в своето пространство и връща файловия дескриптор на периферния процес. През цялото това време, в другия край на комуникационната линия, периферният процес чака отговор. Той няма на разположение никакви структури, които да съхраняват информация за отваряния файл; Дескрипторът, върнат от open, е указател към запис в придружаващия процес в таблицата с дескриптори на потребителския файл. Резултатите от изпълнението на функцията са показани на Фигура 13.4.

Фигура 13.4. Извикване на отворената функция от периферен процес

Ако се направи извикване на системната функция за запис, периферният процесор генерира съобщение, състоящо се от знак за функцията за запис, файлов дескриптор и количеството данни, които трябва да бъдат записани. След това, от пространството на периферния процес, той копира данните към сателитния процес през комуникационната линия. Сателитният процес дешифрира полученото съобщение, чете данните от комуникационната линия и ги записва в съответния файл (дескрипторът, съдържащ се в съобщението, се използва като указател към индекса на който и записът за който се използва във файловата таблица ); всички тези действия се извършват на централния процесор. В края на работата сателитният процес изпраща на периферния процес съобщение, което потвърждава получаването на съобщението и съдържа броя байтове данни, които са били успешно копирани във файла. Операцията за четене е подобна; сателитът информира периферния процес за броя на реално прочетените байтове (в случай на четене на данни от терминал или от канал, това число не винаги съвпада с количеството, посочено в заявката). За да изпълните една или друга функция, може да се наложи да изпращате информационни съобщения многократно по мрежата, което се определя от количеството изпратени данни и размера на мрежовите пакети.

Единствената функция, която трябва да се промени, докато работи на процесора, е системната функция на вилицата. Когато процесът изпълни тази функция на процесора, ядрото избира периферен процесор за него и изпраща съобщение до специален процес - сървъра, като го информира, че ще започне да разтоварва текущия процес. Ако приемем, че сървърът е приел заявката, ядрото използва fork, за да създаде нов периферен процес, разпределяйки запис в таблицата с процеси и адресно пространство. Централният процесор разтоварва копие на процеса, който е извикал функцията fork на периферния процесор, презаписва новоразпределеното адресно пространство, създава локален сателит, за да комуникира с новия периферен процес и изпраща съобщение до периферното устройство за инициализиране на програмния брояч за новия процес. Сателитният процес (на CPU) е потомък на процеса, който се нарича вилица; периферният процес технически е потомък на сървърния процес, но логически е потомък на процеса, който нарича функцията fork. Процесът на сървъра няма логическа връзка с детето, когато fork завърши; единствената задача на сървъра е да помогне за разтоварването на детето. Поради силната връзка между компонентите на системата (периферните процесори нямат автономия), периферният процес и сателитният процес имат един и същ идентификационен код. Връзката между процесите е показана на Фигура 13.5: непрекъснатата линия показва връзката родител-дете, а пунктираната показва връзката между партньорите.

Фигура 13.5. Изпълнение на функция на вилка на процесора

Когато процесът изпълнява функцията fork на периферния процесор, той изпраща съобщение до своя сателит на CPU, който след това изпълнява цялата последователност от действия, описани по-горе. Сателитът избира нов периферен процесор и прави необходимата подготовка за разтоварване на изображението на стария процес: изпраща заявка до родителския периферен процес да прочете неговото изображение, в отговор на което прехвърлянето на исканите данни започва от другия край на комуникационния канал. Сателитът чете предаденото изображение и го презаписва на периферния потомък. Когато разтоварването на изображението приключи, сателитът обработва разклонение, създавайки своето дете на процесора, и предава стойността на програмния брояч на периферното дете, така че последното да знае от кой адрес да започне изпълнението. Очевидно би било по-добре детето на придружаващия процес да бъде присвоено на периферното дете като родител, но в нашия случай генерираните процеси могат да се изпълняват на други периферни процесори, а не само на този, на който са създадени. Връзката между процесите в края на функцията fork е показана на фигура 13.6. Когато периферният процес приключи работата си, той изпраща съответно съобщение до сателитния процес и това също приключва. Придружаващ процес не може да инициира изключване.

Фигура 13.6. Изпълнение на функция fork на периферен процесор

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

Когато периферен процес извика функцията на сигналната система, той съхранява текущата информация в локални таблици и изпраща съобщение до своя сателит, като го информира дали определеният сигнал трябва да бъде получен или игнориран. Сателитният процес не се интересува дали прихваща сигнала или действието по подразбиране. Реакцията на процес към сигнал зависи от три фактора (Фигура 13.7): дали се получава сигнал, докато процесът изпълнява системна функция, дали е направена индикация с помощта на сигналната функция за игнориране на сигнала, дали сигналът се появява на същия периферен процесор или на някой друг. Нека да преминем към разглеждането на различните възможности.

алгоритъм на sighandle / * алгоритъм за обработка на сигнал * /

if (текущият процес е нечий спътник или има прототип)

ако (сигналът се игнорира)

if (сигналът дойде по време на изпълнението на системна функция)

поставете сигнал пред сателитния процес;

изпращане на сигнално съобщение до периферен процес;

друго (/ * периферен процес * /

/ * дали е получен сигнал по време на изпълнението на системна функция или не * /

изпращане на сигнал до сателитния процес;

алгоритъм сателитен_end_of_syscall / * прекратяване на системна функция, извикана от периферен процес * /

входна информация: отсъства

отпечатък: няма

ако (получено е прекъсване по време на изпълнението на системна функция)

изпращане на съобщение за прекъсване, сигнал към периферния процес;

иначе / * изпълнението на системната функция не е прекъснато * /

изпращане на отговор: активиране на флага, показващ пристигането на сигнала;

Фигура 13.7. Обработка на сигнали в периферната система

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

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

2. Ако процесът е инструктиран да игнорира този тип сигнал, сателитът продължава да следва алгоритъма за изпълнение на системната функция, без да излиза от спряно състояние чрез longjmp. В отговора, изпратен до периферния процес, няма да има съобщение за получен сигнал.

3. Ако при получаване на сигнал сателитният процес прекъсне изпълнението на системна функция (чрез longjmp), той информира периферния процес за това и го информира за номера на сигнала.

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

Фигура 13.8. Прекъсване по време на изпълнение на системна функция

Да предположим, например, че периферен процес извиква функция за четене от терминал, свързан към централния процесор, и спира работата си, докато сателитният процес изпълнява функцията (Фигура 13.8). Ако потребителят натисне клавиша за прекъсване, ядрото на процесора изпраща сигнал към сателитния процес. Ако сателитът е бил в спряно състояние, чакайки част от данни от терминала, той незабавно излиза от това състояние и прекратява функцията за четене. В отговора си на заявка от периферен процес, сателитът предоставя код за грешка и номер на сигнала, съответстващи на прекъсването. Периферният процес анализира отговора и, тъй като съобщението казва, че е пристигнало прекъсване, изпраща сигнала до себе си. Преди да излезе от функцията за четене, периферното ядро ​​проверява за сигнализиране, открива сигнал за прекъсване от сателитния процес и го обработва както обикновено. Ако в резултат на получаване на сигнал за прекъсване, периферният процес прекрати работата си с изходната функция, тази функция се грижи за унищожаването на сателитния процес. Ако периферният процес прихваща сигнали за прекъсване, той извиква дефинираната от потребителя функция за обработка на сигнали и връща код за грешка на потребителя при излизане от функцията за четене. От друга страна, ако сателитът изпълнява функцията на системата stat от името на периферния процес, той няма да прекъсне изпълнението му, когато получи сигнал (функцията stat е гарантирано да излезе от всяка пауза, тъй като има ограничено време за изчакване на ресурса ). Сателитът завършва изпълнението на функцията и връща номера на сигнала към периферния процес. Периферният процес изпраща сигнал към себе си и го получава на изхода от системната функция.

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

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

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

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

13.2 КОМУНИКАЦИЯ ТИП НЮКАСЪЛ

В предишния раздел разгледахме тип тясно свързана система, която се характеризира с изпращане на всички извиквания към функциите на подсистемата за управление на файлове, които възникват на периферния процесор, към отдалечен (централен) процесор. Сега се обръщаме към разглеждането на системи с по-слаба връзка, които се състоят от машини, които извършват извиквания към файлове, разположени на други машини. В мрежа от персонални компютри и работни станции, например, потребителите често имат достъп до файлове, разположени на голяма машина. В следващите два раздела ще разгледаме системни конфигурации, в които всички системни функции се изпълняват в локални подсистеми, но в същото време е възможен достъп до файлове (чрез функциите на подсистемата за управление на файлове), разположени на други машини.

Тези системи използват един от следните два пътя за идентифициране на изтритите файлове. В някои системи към съставното име на файл се добавя специален символ: компонентът с име, който предхожда този знак, идентифицира машината, останалата част от името е файлът на тази машина. Така, например, отличителното име

"sftig! / fs1 / mjb / rje"

идентифицира файла "/ fs1 / mjb / rje" на машината "sftig". Тази схема за идентификация на файлове следва конвенцията uucp за прехвърляне на файлове между UNIX-подобни системи. В друга схема изтритите файлове се идентифицират чрез добавяне на специален префикс към името, например:

/../sftig/fs1/mjb/rje

където "/../" е префикс, показващ, че файлът е изтрит; вторият компонент на името на файла е името на отдалечената машина. Тази схема използва познатия синтаксис на UNIX имена на файлове, така че за разлика от първата схема, потребителските програми не трябва да се адаптират към използването на имена с необичайна конструкция (вижте).

Фигура 13.9. Формулиране на заявки към файловия сървър (процесор)

Ще посветим останалата част от този раздел на модел на система, използваща връзка към Нюкасъл, в която ядрото не се занимава с разпознаване на изтрити файлове; тази функция е изцяло присвоена на подпрограмите от стандартната библиотека C, които в този случай играят ролята на системния интерфейс. Тези процедури анализират първия компонент на името на файла, който и в двата описани метода за идентификация съдържа признак за отдалеченост на файла. Това е отклонение от рутината, в която библиотечните процедури не анализират имената на файлове. Фигура 13.9 показва как се формулират заявките към файлов сървър. Ако файлът е локален, ядрото на локалната система обработва заявката нормално. Помислете за обратния случай:

отворен ("/../ sftig / fs1 / mjb / rje / файл", O_RDONLY);

Отворената подпрограма в библиотеката C анализира първите два компонента на разграниченото име на файл и знае да търси файла на отдалечената машина "sftig". За да има информация дали процесът преди е имал връзка с дадена машина, подпрограмата стартира специална структура, в която запомня този факт и в случай на отрицателен отговор установява връзка с файловия сървър, работещ на отдалеченото машина. Когато процесът формулира първата си заявка за отдалечена обработка, отдалеченият сървър потвърждава заявката, ако е необходимо, записва в полетата на потребителски и групови идентификационни кодове и създава сателитен процес, който ще действа от името на клиентския процес.

За да изпълни клиентски заявки, сателитът трябва да има същите разрешения за файл на отдалечената машина като клиента. С други думи, потребителят "mjb" трябва да има еднакви права за достъп както до отдалечени, така и до локални файлове. За съжаление е възможно клиентският идентификационен код "mjb" да съвпада с идентификационния код на друг клиент на отдалечената машина. По този начин системните администратори на машини, работещи в мрежата, трябва или да гарантират, че на всеки потребител е присвоен идентификационен код, който е уникален за цялата мрежа, или да извършат преобразуване на кода в момента на формулиране на заявка за мрежова услуга. Ако това не бъде направено, придружаващият процес ще има правата на друг клиент на отдалечената машина.

По-деликатен проблем е получаването на права на суперпотребител във връзка с работата с отдалечени файлове. От една страна, клиентът на суперпотребител не трябва да има същите права върху отдалечената система, за да не подвежда контролите за сигурност на отдалечената система. От друга страна, някои от програмите, ако не им бъдат предоставени права на суперпотребител, просто няма да могат да работят. Пример за такава програма е програмата mkdir (вижте Глава 7), която създава нова директория. Отдалечената система няма да позволи на клиента да създаде нова директория, тъй като правата на суперпотребител не са в сила при изтриване. Проблемът със създаването на отдалечени директории служи като сериозна причина за преразглеждане на системната функция mkdir в посока разширяване на нейните възможности за автоматично установяване на всички връзки, необходими за потребителя. Въпреки това, все още е често срещан проблем, че програмите setuid (като програмата mkdir) получават привилегии на суперпотребител над отдалечени файлове. Може би най-доброто решение на този проблем би било да се зададат допълнителни характеристики за файлове, които описват достъпа до тях от отдалечени суперпотребители; за съжаление, това ще изисква промени в структурата на индекса на диска (по отношение на добавяне на нови полета) и ще създаде твърде много бъркотия в съществуващите системи.

Ако отворената подпрограма успее, локалната библиотека оставя съответна бележка за това в достъпна за потребителя структура, съдържаща адреса на мрежовия възел, идентификатора на процеса на сателитния процес, файловия дескриптор и друга подобна информация. Процедурите за четене и запис на библиотеката определят въз основа на файловия дескриптор дали файлът е изтрит и ако е така, изпращат съобщение до сателита. Клиентският процес взаимодейства със своя спътник във всички случаи на достъп до системни функции, които изискват услугите на отдалечена машина. Ако даден процес осъществява достъп до два файла, разположени на една и съща отдалечена машина, той използва един сателит, но ако файловете са разположени на различни машини, вече се използват два сателита: по един на всяка машина. Два сателита също се използват, когато два процеса имат достъп до файл на отдалечена машина. Чрез извикване на системната функция чрез сателит, процесът генерира съобщение, което включва номера на функцията, името на пътя за търсене и друга необходима информация, подобна на тази, включена в структурата на съобщението в системата с периферни процесори.

Механизмът за извършване на операции в текущата директория е по-сложен. Когато процесът избере отдалечена директория като текуща, рутинната библиотека изпраща съобщение до сателита, което променя текущата директория и рутината запомня, че директорията е изтрита. Във всички случаи, когато името на пътя за търсене започва със знак, различен от наклонена черта (/), подпрограмата изпраща името на отдалечената машина, където сателитният процес го насочва от текущата директория. Ако текущата директория е локална, рутината просто предава името на пътя за търсене към ядрото на локалната система. Системната функция chroot на отдалечена директория е подобна, но остава незабелязана за локалното ядро; строго погледнато, процесът може да игнорира тази операция, тъй като само библиотеката записва нейното изпълнение.

Когато процес извика fork, съответната библиотечна рутина изпраща съобщения до всеки сателит. Сателитните процеси се разклоняват и изпращат своите дъщерни идентификатори до родителския клиент. Клиентският процес изпълнява системната функция fork, която прехвърля контрола на детето, което създава; локалното дете е в диалог с отдалеченото дете сателит, чиито адреси се съхраняват от рутинната библиотека. Тази интерпретация на функцията fork улеснява сателитните процеси да контролират отворените файлове и текущите директории. Когато процесът, работещ с отдалечени файлове, излезе (чрез извикване на функцията за изход), подпрограмата изпраща съобщения до всичките си отдалечени сателити, така че те да направят същото, когато получат съобщението. В упражненията се обсъждат някои аспекти от изпълнението на функциите на exec и exit.

Предимството на връзката в Newcastle е, че достъпът на процеса до отдалечени файлове става прозрачен (невидим за потребителя), без да е необходимо да се правят промени в ядрото на системата. Това развитие обаче има редица недостатъци. На първо място, по време на неговото изпълнение е възможно намаляване на производителността на системата. Поради използването на разширената C библиотека, размерът на използваната от всеки процес памет се увеличава, дори ако процесът няма достъп до отдалечени файлове; библиотеката дублира функциите на ядрото и изисква повече място в паметта. Увеличаването на размера на процесите удължава периода на стартиране и може да създаде повече спорове за ресурсите на паметта, създавайки условия за по-често разтоварване и пейджинг на задачи. Локалните заявки ще се изпълняват по-бавно поради увеличаването на продължителността на всяко извикване към ядрото, а обработката на отдалечени заявки също може да се забави, цената за изпращането им по мрежата се увеличава. Допълнителната обработка на отдалечени заявки на потребителско ниво увеличава броя на превключванията на контекста, операциите за разтоварване и размяна. И накрая, за да получите достъп до отдалечени файлове, програмите трябва да бъдат прекомпилирани с помощта на новите библиотеки; старите програми и доставените обектни модули няма да могат да работят с отдалечени файлове без него. Всички тези недостатъци липсват в системата, описана в следващия раздел.

13.3 "ПРОЗРАЧНИ" РАЗПРЕДЕЛЕНИ ФАЙЛОВИ СИСТЕМИ

Терминът "прозрачно разпределение" означава, че потребителите на една машина могат да имат достъп до файлове на друга машина, без да осъзнават, че пресичат границите на машината, точно както са на своята машина, когато преминават от една файлова система към друга, преминават през точките за монтиране. Имената, с които процесите се отнасят до файлове, разположени на отдалечени машини, са подобни на имената на локални файлове: в тях няма отличителни знаци. В конфигурацията, показана на фигура 13.10, директорията "/ usr / src", принадлежаща на машина B, е "монтирана" в директорията "/ usr / src", принадлежаща на машина A. същият системен изходен код, традиционно намиращ се в "/ usr / src" директория. Потребителите, работещи на машина A, имат достъп до файлове, разположени на машина B, като използват познатия синтаксис за запис на имена на файлове (например: "/usr/src/cmd/login.c"), а самото ядро ​​​​решава дали файлът е отдалечен или локален . Потребителите, работещи на машина B, имат достъп до своите локални файлове (без да знаят, че потребителите на машина A имат достъп до същите файлове), но от своя страна нямат достъп до файлове, разположени на машина A. Разбира се, възможни са и други опции, в по-специално тези, в които всички отдалечени системи са монтирани в основата на локалната система, така че потребителите да имат достъп до всички файлове на всички системи.

Фигура 13.10. Файлови системи след дистанционно монтиране

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

Интересен проблем е свързан с имената на пътища, които включват "..". Ако даден процес създава текущата директория от отдалечена файлова система, тогава използването на символи ".." в името по-вероятно ще върне процеса към локалната файлова система, а не за достъп до файлове над текущата директория. Връщайки се отново към Фигура 13.10, имайте предвид, че когато процес, принадлежащ на машина А, след като преди това е избрал текущата директория "/ usr / src / cmd", разположена в отдалечената файлова система, ще изпълни командата

текущата директория ще бъде главната директория на машина A, а не машина B. Алгоритъмът namei, работещ в ядрото на отдалечената система, след като получи последователността от знаци "..", проверява дали процесът на извикване е агент на клиента процес, и ако е така, задава, дали клиентът третира текущата работна директория като корен на отдалечената файлова система.

Комуникацията с отдалечена машина приема една от двете форми: отдалечено извикване на процедура или извикване на отдалечена системна функция. В първата форма всяка процедура на ядрото, занимаваща се с индекси, проверява дали индексът сочи към отдалечен файл и ако е така, изпраща заявка до отдалечената машина за извършване на определената операция. Тази схема естествено се вписва в абстрактната структура за поддръжка на различни типове файлови системи, описана в последната част на глава 5. Така достъпът до отдалечен файл може да инициира прехвърлянето на няколко съобщения през мрежата, чийто брой е определя се от броя на подразбиращите се операции върху файла, със съответно увеличение на времето за отговор на заявката, като се вземе предвид времето за изчакване, прието в мрежата. Всеки набор от отдалечени операции включва най-малко действия за заключване на индекс, преброяване на референции и т.н. С цел подобряване на модела бяха предложени различни оптимизационни решения, свързани с комбиниране на няколко операции в една заявка (съобщение) и буфериране на най-важните данни (cm. ).

Фигура 13.11. Отваряне на отдалечен файл

Помислете за процес, който отваря отдалечен файл "/usr/src/cmd/login.c", където "src" е точката на монтиране. Чрез анализиране на името на файла (използвайки схемата namei-iget), ядрото открива, че файлът е изтрит и изпраща заявка до хост машината да получи заключения индекс. След като получи желания отговор, локалното ядро ​​създава копие на индекса в паметта, съответстващо на отдалечения файл. След това ядрото проверява за необходимите права за достъп до файла (за четене, например), като изпраща друго съобщение до отдалечената машина. Отвореният алгоритъм продължава в пълно съответствие с плана, описан в Глава 5, като изпраща съобщения до отдалечената машина, ако е необходимо, докато алгоритъмът не завърши и индексът не бъде освободен. Връзката между структурите от данни на ядрото при завършване на отворения алгоритъм е показана на Фигура 13.11.

Ако клиентът извика системната функция за четене, клиентското ядро ​​​​заключва локалния индекс, издава заключване на отдалечения индекс, заявка за четене, копира данните в локалната памет, издава заявка за освобождаване на отдалечения индекс и освобождава локалния индекс . Тази схема е в съответствие със семантиката на съществуващото еднопроцесорно ядро, но честотата на използване на мрежата (множество извиквания към всяка системна функция) намалява производителността на цялата система. Въпреки това, за да се намали потокът от съобщения в мрежата, множество операции могат да бъдат комбинирани в една заявка. В примера с функцията read, клиентът може да изпрати на сървъра една обща заявка за "четене", а самият сървър решава да вземе и освободи индекса, когато бъде изпълнен. Намаляването на мрежовия трафик може да се постигне и чрез използване на отдалечени буфери (както обсъдихме по-горе), но трябва да се внимава да се гарантира, че функциите на системния файл, използващи тези буфери, се изпълняват правилно.

Във втората форма на комуникация с отдалечена машина (извикване към функция от отдалечена система), локалното ядро ​​открива, че системната функция е свързана с отдалечен файл и изпраща параметрите, посочени в нейното извикване, до отдалечената система, която изпълнява функция и връща резултатите на клиента. Клиентската машина получава резултатите от изпълнението на функцията и излиза от състоянието на повикване. Повечето от системните функции могат да се изпълняват с помощта само на една мрежова заявка и получаване на отговор след разумно време, но не всички функции се вписват в този модел. Така например, при получаване на определени сигнали, ядрото създава файл за процеса, наречен "core" (глава 7). Създаването на този файл не е свързано с конкретна системна функция, но в крайна сметка изпълнява няколко операции, като създаване на файл, проверка на разрешенията и извършване на поредица от записи.

В случай на функцията отворена система, заявката за изпълнение на функцията, изпратена до отдалечената машина, включва частта от името на файла, останала след изключване на компонентите на името на пътя за търсене, които разграничават отдалечения файл, както и различни флагове. В предишния пример за отваряне на файла "/usr/src/cmd/login.c", ядрото изпраща името "cmd / login.c" на отдалечената машина. Съобщението включва също идентификационни данни като потребителски и групови идентификационни кодове, които са необходими за проверка на разрешенията за файлове на отдалечена машина. Ако се получи отговор от отдалечената машина, показващ успешна отворена функция, локалното ядро ​​извлича свободен индекс в паметта на локалната машина и го маркира като индекс на отдалечен файл, съхранява информация за отдалечената машина и отдалечения индекс и рутинно разпределя нов запис в таблицата с файлове. В сравнение с реалния индекс на отдалечената машина, индексът, притежаван от локалната машина, е формален и не нарушава конфигурацията на модела, която като цяло е същата като конфигурацията, използвана при извикване на отдалечената процедура (Фигура 13.11). Ако функция, извикана от процес, осъществява достъп до отдалечен файл от неговия дескриптор, локалното ядро ​​знае от (локалния) индекс, че файлът е отдалечен, формулира заявка, която включва извиканата функция, и я изпраща до отдалечената машина. Заявката съдържа указател към отдалечения индекс, чрез който сателитният процес може да идентифицира самия отдалечен файл.

След като получи резултата от изпълнението на която и да е системна функция, ядрото може да прибегне до услугите на специална програма, за да я обработи (след завършване на която ядрото ще приключи работата с функцията), тъй като локалната обработка на резултатите, използвани в еднопроцесорна система не винаги е подходящ за система с няколко процесора. В резултат на това са възможни промени в семантиката на системните алгоритми, насочени към осигуряване на поддръжка за изпълнение на отдалечени системни функции. В същото време обаче в мрежата циркулира минимален поток от съобщения, което осигурява минимално време за реакция на системата на входящи заявки.

13.4 РАЗПРЕДЕЛЕН МОДЕЛ БЕЗ ПРОЦЕСИ НА ПРЕНОС

Използването на процеси на трансфер (сателитни процеси) в прозрачна разпределена система улеснява проследяването на изтритите файлове, но таблицата на процесите на отдалечената система е претоварена със сателитни процеси, които не работят през повечето време. В други схеми се използват специални сървърни процеси за обработка на отдалечени заявки (вижте и). Отдалечената система има набор (пул) от сървърни процеси, които тя присвоява от време на време за обработка на входящи отдалечени заявки. След обработка на заявката, сървърният процес се връща в пула и влиза в състояние, готово за обработка на други заявки. Сървърът не запазва потребителския контекст между две повиквания, тъй като може да обработва заявки от няколко процеса наведнъж. Следователно всяко съобщение, пристигащо от клиентски процес, трябва да включва информация за неговата среда за изпълнение, а именно: потребителски идентификационни кодове, текуща директория, сигнали и др. функции.

Когато процес отвори отдалечен файл, отдалеченото ядро ​​присвоява индекс за последващи връзки към файла. Локалната машина поддържа персонализирана таблица с файлови дескриптори, файлова таблица и индексна таблица с редовен набор от записи, като запис в индексната таблица идентифицира отдалечената машина и отдалечения индекс. В случаите, когато системна функция (например read) използва файлов дескриптор, ядрото изпраща съобщение, насочващо към предварително присвоения отдалечен индекс и прехвърля информация, свързана с процеса: идентификационен код на потребителя, максимален размер на файла и т.н. машината има сървърен процес на негово разположение, взаимодействието с клиента приема формата, описана по-рано, но връзката между клиента и сървъра се установява само за времето на функционирането на системата.

Използването на сървъри вместо сателитни процеси може да затрудни управлението на трафика на данни, сигналите и отдалечените устройства. Голям брой заявки към отдалечена машина при липса на достатъчен брой сървъри трябва да се поставят на опашка. Това изисква протокол от по-висок слой от този, използван в основната мрежа. В сателитния модел, от друга страна, пренасищането е елиминирано, тъй като всички клиентски заявки се обработват синхронно. Клиентът може да има най-много една чакаща заявка.

Обработката на сигнали, които прекъсват изпълнението на системна функция, също е сложна при използване на сървъри, тъй като отдалечената машина трябва да търси подходящия сървър, обслужващ изпълнението на функцията. Възможно е дори, поради натовареността на всички сървъри, заявка за системна функция да е в процес на обработка. Условия за възникване на конкуренция възникват и когато сървърът връща резултата от системната функция към процеса на извикване и отговорът на сървъра включва изпращане на съответното сигнално съобщение през мрежата. Всяко съобщение трябва да бъде маркирано, така че отдалечената система да може да го разпознае и, ако е необходимо, да прекрати сървърните процеси. При използване на сателити, процесът, който обработва изпълнението на заявката на клиента, се идентифицира автоматично и при пристигане на сигнал не е трудно да се провери дали заявката е обработена или не.

И накрая, ако системна функция, извикана от клиента, кара сървъра да пауза за неопределено време (например при четене на данни от отдалечен терминал), сървърът не може да обработва други заявки, за да освободи сървърния пул. Ако няколко процеса имат достъп до отдалечени устройства наведнъж и ако броят на сървърите е ограничен отгоре, има доста осезаемо затруднение. Това не се случва със сателитите, тъй като за всеки клиентски процес се разпределя сателит. Друг проблем с използването на сървъри за отдалечени устройства ще бъде разгледан в упражнение 13.14.

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

Фигура 13.12. Концептуална диаграма на взаимодействие с отдалечени файлове на ниво ядро

13.5 ЗАКЛЮЧЕНИЯ

В тази глава разгледахме три схеми за работа с файлове, разположени на отдалечени машини, третирайки отдалечените файлови системи като разширение на локалната. Архитектурните разлики между тези оформления са показани на Фигура 13.12. Всички те от своя страна се различават от многопроцесорните системи, описани в предишната глава, по това, че процесорите тук не споделят физическа памет. Периферната процесорна система се състои от тясно свързан набор от процесори, които споделят файловите ресурси на централния процесор. Връзка от типа Newcastle осигурява скрит ("прозрачен") достъп до отдалечени файлове, но не чрез ядрото на операционната система, а чрез използването на специална C библиотека. Поради тази причина всички програми, които възнамеряват да използват този тип връзки, трябва да бъдат прекомпилирани, което като цяло е сериозен недостатък на тази схема. Отдалечеността на даден файл се обозначава с помощта на специална последователност от знаци, описващи машината, на която се намира файлът, и това е друг фактор, ограничаващ преносимостта на програмите.

В прозрачни разпределени системи се използва модификация на функцията на системата за монтиране за достъп до отдалечени файлове. Индексите в локалната система се маркират като отдалечени файлове и локалното ядро ​​изпраща съобщение до отдалечената система, описващо исканата системна функция, нейните параметри и отдалечения индекс. Комуникацията в "прозрачна" разпределена система се поддържа в две форми: под формата на повикване към отдалечена процедура (до отдалечената машина се изпраща съобщение, съдържащо списък с операции, свързани с индекса) и под формата на повикване към отдалечена системна функция (съобщението описва исканата функция). Последната част на главата обсъжда въпроси, свързани с обработката на отдалечени заявки с помощта на сателитни процеси и сървъри.

13.6 УПРАЖНЕНИЯ

*1. Опишете изпълнението на изходната системна функция в система с периферни процесори. Каква е разликата между този случай и кога процесът излиза при получаване на неуловен сигнал? Как трябва ядрото да изхвърли съдържанието на паметта?

2. Процесите не могат да игнорират сигналите SIGKILL; Обяснете какво се случва в периферната система, когато процесът получи такъв сигнал.

* 3. Опишете изпълнението на системната функция exec в система с периферни процесори.

*4. Как централният процесор трябва да разпределя процесите между периферните процесори, за да балансира общото натоварване?

*5. Какво се случва, ако периферният процесор няма достатъчно памет, за да побере всички процеси, разтоварени към него? Как трябва да се извършва разтоварването и размяната на процеси в мрежата?

6. Помислете за система, в която се изпращат заявки към отдалечен файлов сървър, ако в името на файла е намерен специален префикс. Нека процесът извика execl ("/../ sftig / bin / sh", "sh", 0); Изпълнимият файл е на отдалечена машина, но трябва да работи на локалната система. Обяснете как отдалеченият модул се мигрира към локалната система.

7. Ако администраторът трябва да добави нови машини към съществуваща система с връзка като Newcastle, тогава кой е най-добрият начин да информира модулите на библиотеката C за това?

*осем. По време на изпълнението на функцията exec, ядрото презаписва адресното пространство на процеса, включително библиотечните таблици, използвани от връзката на Newcastle за проследяване на връзки към отдалечени файлове. След като изпълни функцията, процесът трябва да запази възможността за достъп до тези файлове чрез техните стари дескриптори. Опишете изпълнението на тази точка.

*девет. Както е показано в раздел 13.2, извикването на изходната системна функция в системи с връзка с Нюкасъл води до изпращане на съобщение до придружаващия процес, принуждавайки последния да прекрати. Това се прави на ниво библиотечни рутини. Какво се случва, когато локален процес получи сигнал, който му казва да излезе в режим на ядрото?

*десет. В система с връзка към Нюкасъл, където отдалечените файлове се идентифицират чрез префикс на името със специален префикс, как може потребител, указващ ".." (родителска директория) като компонент с име на файла, да премине през отдалечената точка на монтиране?

11. От глава 7 знаем, че различни сигнали карат процеса да изхвърли съдържанието на паметта в текущата директория. Какво трябва да се случи, ако текущата директория е от отдалечената файлова система? Какъв отговор бихте дали, ако системата използва връзка като Нюкасъл?

*12. Какви последици за локалните процеси би имало, ако всички сателитни или сървърни процеси бъдат премахнати от системата?

*13. Помислете как да приложите алгоритъма на връзката в прозрачна разпределена система, параметрите на която могат да бъдат две отдалечени имена на файла, както и алгоритъмът exec, свързан с извършването на няколко вътрешни операции за четене. Помислете за две форми на комуникация: отдалечено извикване на процедура и извикване на отдалечена системна функция.

*четиринадесет. При достъп до устройството сървърният процес може да влезе в спряно състояние, от което ще бъде изведен от драйвера на устройството. Естествено, ако броят на сървърите е ограничен, системата вече няма да може да удовлетворява заявките на локалната машина. Измислете надеждна схема, при която не всички сървърни процеси се спират, докато се чака завършването на свързаните с устройството I/O. Системната функция няма да се прекрати, докато всички сървъри са заети.

Фигура 13.13. Конфигурация на терминален сървър

*15. Когато потребител влезе в системата, дисциплината на терминалната линия съхранява информацията, че терминалът е операторски терминал, водещ група от процеси. Поради тази причина, когато потребителят натисне клавиша "break" на клавиатурата на терминала, всички процеси в групата получават сигнал за прекъсване. Помислете за системна конфигурация, в която всички терминали са физически свързани към една машина, но регистрацията на потребител е логично реализирана на други машини (Фигура 13.13). Във всеки случай системата създава getty процес за отдалечения терминал. Ако заявките към отдалечена система се обработват от набор от сървърни процеси, имайте предвид, че когато се изпълни отворената процедура, сървърът спира да чака връзка. Когато функцията за отваряне приключи, сървърът се връща към сървърния пул, прекъсвайки връзката си с терминала. Как се задейства сигнал за прекъсване чрез натискане на клавиша "break", изпратен до адресите на процеси, включени в същата група?

*16. Споделянето на паметта е функция, присъща на локалните машини. От логическа гледна точка, разпределението на обща област на физическа памет (локална или отдалечена) може да се извърши за процеси, принадлежащи на различни машини. Опишете изпълнението на тази точка.

* 17. Процесът за пейджинг и алгоритмите за пейджинг, обсъдени в глава 9, предполагат използването на локален пейджър. Какви промени трябва да се направят в тези алгоритми, за да могат да се поддържат устройства за отдалечено разтоварване?

*осемнадесет. Да предположим, че отдалечената машина (или мрежа) претърпява фатален срив и протоколът на локалния мрежов слой записва този факт. Разработете схема за възстановяване за локална система, която прави заявки към отдалечен сървър. Освен това разработете схема за възстановяване на сървърна система, която е загубила контакт с клиенти.

*19. Когато даден процес осъществява достъп до отдалечен файл, е възможно процесът да премине през множество машини в търсене на файла. Вземете името "/ usr / src / uts / 3b2 / os" като пример, където "/ usr" е директорията, принадлежаща на машина A, "/ usr / src" е точката на монтиране на корена на машина B, " / usr / src / uts / 3b2 "е точката на монтиране на корена на машина C. Преминаването през множество машини до крайната й дестинация се нарича мултихоп. Въпреки това, ако има директна мрежова връзка между машини A и C, изпращането на данни през машина B би било неефективно. Опишете особеностите на реализацията на „мултишопинг“ в система с връзка в Нюкасъл и в „прозрачна“ разпределена система.

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

Исторически погледнато, архитектурата на файлов сървър беше първата, която получи широко разпространение, тъй като нейната логика е проста и е най-лесно да се прехвърлят в такава архитектура IS, които вече се използват. След това се трансформира в архитектура сървър-клиент, която може да се интерпретира като нейно логическо продължение. Съвременните системи, използвани в глобалната мрежа ИНТЕРНЕТ, се отнасят главно до архитектурата на разпределените обекти (виж фиг. III‑15 )

IS може да се представи, състоящ се от следните компоненти (фиг. III-16)

III.03.2. a Приложения за файлов сървър.

В исторически план това е първата разпределена архитектура (фиг. III-17). Тя е организирана много просто: има само данни на сървъра, а всичко останало принадлежи на клиентската машина. Тъй като локалните мрежи са доста евтини и поради факта, че с такава архитектура приложният софтуер е автономен, такава архитектура често се използва днес. Можем да кажем, че това е вариант на архитектурата клиент-сървър, при който на сървъра се намират само файлове с данни. Различните персонални компютри взаимодействат само посредством общо хранилище на данни, така че програмите, написани за един компютър, са най-лесни за адаптиране към такава архитектура.

Професионалисти:

Плюсове на архитектурата на файлов сървър:

Лесна организация;

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

Претоварване на мрежата;

Непредвидим отговор на заявка.

Тези недостатъци се обясняват с факта, че всяко искане към базата данни води до прехвърляне на значителни количества информация през мрежата. Например, за да изберете един или няколко реда от таблици, цялата таблица се изтегля на клиентската машина и СУБД вече избира там. Значителният мрежов трафик е особено изпълнен с организацията на отдалечен достъп до базата данни.

III.03.2. b Приложения клиент-сървър.

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

В модела на тънкия клиент цялата работа с приложенията и управлението на данни се извършват на сървъра. Потребителският интерфейс в тези системи "мигрира" към персонален компютър, а самото софтуерно приложение изпълнява функциите на сървър, т.е. изпълнява всички процеси на приложение и управлява данни. Моделът на тънкия клиент може също да бъде приложен, когато клиентите са компютри или работни станции. Мрежовите устройства работят с интернет браузъра и потребителския интерфейс, внедрен в системата.

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

Обратно, моделът на дебелия клиент използва процесорната мощност на локалните машини: самото приложение се поставя на клиентския компютър. Пример за този тип архитектура са ATM системите, в които банкоматът е клиент, а сървърът е централният компютър, обслужващ базата данни за клиентски акаунти.

III.03.2. c Дву- и тристепенна архитектура клиент-сървър.

Всички обсъдени по-горе архитектури са двустепенни. Те правят разлика между ниво клиент и ниво сървър. Строго погледнато, IC се състои от три логически нива:

· Потребителско ниво;

Ниво на приложение:

· Слой данни.

Следователно, в двустепенен модел, където участват само две нива, има проблеми с мащабируемостта и производителността, ако е избран моделът на тънкия клиент, или проблеми с управлението на системата, ако е избран моделът на дебелия клиент. Тези проблеми могат да бъдат избегнати, ако приложим модел, състоящ се от три нива, където две от тях са сървъри (фиг. III-21).

Сървър за данни

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

Таблица III-5 Приложение на различни видове архитектури

Архитектура	Приложение
Двустепенен тънък клиент	1 Наследени системи, в които не е препоръчително да се разделят изпълнението на приложения и управлението на данни. 2 Изчислявайте интензивни приложения с малко управление на данни. 3 Приложения с големи количества данни, но малко изчисления.
Двустепенен дебел клиент	1 Приложения, при които потребителят изисква интензивна обработка на данни, т.е. визуализация на данни. 2 Приложения с относително постоянен набор от потребителски функции, приложени към добре управлявана системна среда.
Тристепенен сървър-клиент	1 Големи приложения с клетки и хиляди клиенти 2 Приложения, в които данните и методите на обработка се променят често. 3 Приложения, които интегрират данни от множество източници.

Този модел е подходящ за много видове приложения, но ограничава разработчиците на IS, които трябва да решат къде да предоставят услуги, да осигурят поддръжка за мащабируемост и да разработят инструменти за свързване на нови клиенти.

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

По-общ подход се осигурява от архитектурата на разпределени обекти, на която обектите са основни компоненти. Те предоставят набор от услуги чрез своите интерфейси. Други обекти изпращат заявки, без да правят разлика между клиент и сървър. Обектите могат да бъдат разположени на различни компютри в мрежа и да взаимодействат чрез междинен софтуер, подобно на системната шина, която ви позволява да свързвате различни устройства и да поддържате комуникация между хардуерни устройства.

…

ODBC мениджър на драйвери

Шофьор 1

Шофьор К

DB 1

ДБ К

Работа с SQL

…

ODBC архитектурата включва компоненти:

1. Приложение (напр. IS). Той изпълнява задачи: изисква връзка с източника на данни, изпраща SQL заявки към източника на данни, описва областта за съхранение и формата за SQL заявки, обработва грешки и уведомява потребителя за тях, извършва или връща обратно транзакции, иска връзка към източник на данни.

2. Диспечер на устройства. Той зарежда драйвери при поискване от приложения, предлага единен интерфейс за всички приложения, а ODBC администраторският интерфейс е един и същ и независимо с коя СУБД ще взаимодейства приложението. Доставеният от Microsoft Driver Manager е библиотека с динамично зареждане (DLL).

3. Драйверът зависи от СУБД. ODBC драйверът е библиотека с динамични връзки (DLL), която реализира ODBC функции и взаимодейства с източник на данни. Драйверът е програма, която обработва заявка за функция, специфична за СУБД (може да модифицира заявките в съответствие с СУБД) и връща резултата на приложението. Всяка СУБД, която поддържа ODBC технология, трябва да предостави на разработчиците на приложения драйвер за тази СУБД.

4. Източникът на данни съдържа контролната информация, посочена от потребителя, информация за източника на данни и се използва за достъп до конкретна СУБД. В този случай се използват средствата на ОС и мрежовата платформа.

Динамичен модел

Този модел предполага много аспекти, за които се използват поне 5 диаграми в UML, вижте стр. 2.04.2- 2.04.5.

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

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

Има два основни типа контрол в софтуерните системи.

1. Централизирано управление.

2. Управление, базирано на събития.

Централизираното управление може да бъде:

· Йерархичен- на базата на принципа "обаждане-връщане" (така най-често работят образователните програми)

· Модел на диспечеракойто се използва за паралелни системи.

V модели на диспечеритеприема се, че един от компонентите на системата е диспечер. Той управлява както стартирането и изключването на системите, така и координацията на останалите процеси в системата. Процесите могат да протичат успоредно един на друг. Процесът се отнася до програма, подсистема или процедура, която се изпълнява в момента. Този модел може да се приложи и в последователни системи, където управляващата програма извиква отделни подсистеми в зависимост от някои променливи на състоянието (чрез оператора случай).

Организиране на събитияпредполага липсата на подпрограма, отговорна за управлението. Управлението се осъществява чрез външни събития: натискане на бутон на мишката, натискане на клавиатура, промяна на показанията на сензора, промяна на показанията на таймера и др. Всяко външно събитие се кодира и се поставя в опашката за събития. Ако е предоставена реакция на събитие в опашката, тогава се извиква процедурата (подпрограма), която изпълнява реакцията на това събитие. Събитията, на които реагира системата, могат да възникнат или в други подсистеми, или във външната среда на системата.

Пример за такова управление е организацията на приложения в Windows.

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

Потребителски интерфейс

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

III.03.4. а Психофизически характеристики на човек, свързани с възприемането и обработката на информация.

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

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

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

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

Краткосрочната памет е тесното място в системата за обработка на информация на човек. Капацитетът му е 7 ± 2 несвързани обекта. Непотърсена информация се съхранява в него за не повече от 30 секунди. За да не забравим някоя важна за нас информация, обикновено си я повтаряме, актуализирайки информацията в краткосрочната памет. По този начин, когато проектирате интерфейси, трябва да се има предвид, че преобладаващото мнозинство се затруднява, например, да запомнят и въвеждат числа, съдържащи повече от пет цифри, на друг екран.

Въпреки че капацитетът и времето за съхранение на дългосрочната памет са неограничени, достъпът до информация не е лесен. Механизмът за извличане на информация от дългосрочната памет има асоциативен характер. За да се подобри запомнянето на информация, тя е обвързана с данните, които паметта вече съхранява и улеснява получаването им. Тъй като достъпът до дългосрочната памет е труден, препоръчително е да се очаква от потребителя да не запомни информацията, а на факта, че потребителят ще я разпознае.

III.03.4. b Основни критерии за оценка на интерфейсите

Многобройни проучвания и проучвания, проведени от водещи фирми за разработка на софтуер, показват, че потребителите ценят в един интерфейс:

1) лекота на овладяване и запомняне - конкретно оценяване на времето на овладяване и продължителността на запазване на информацията и паметта;

2) скоростта на постигане на резултати при използване на системата, която се определя от броя команди и настройки, въведени или избрани от мишката;

3) субективна удовлетвореност от работата на системата (лекота на използване, умора и др.).

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

От тази гледна точка днес най-добрите характеристики за професионалните потребители са интерфейсите с безплатна навигация, а за непрофесионалните потребители - интерфейсите за директна манипулация. Отдавна е забелязано, че при извършване на операция за копиране на файлове, при равни други условия, повечето професионалисти използват обвивки като Far, докато непрофесионалистите използват Windows "drag and drop".

III.03.4. c Видове потребителски интерфейси

Различават се следните типове потребителски интерфейси:

Примитивен

Безплатна навигация

Директна манипулация.

Интерфейсът е примитивен

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

Интерфейс на менюто.

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

(Материал на сайта http://se.math.spbu.ru)

Въведение.

В днешно време практически всички големи софтуерни системи са разпространени. Разпределена система- система, в която обработката на информация е концентрирана не на един компютър, а се разпределя между няколко компютъра. При проектирането на разпределени системи, което има много общо с дизайна на софтуера като цяло, все още има някои специфики, които трябва да се вземат предвид.

Има шест основни характеристики на разпределените системи.

1. Споделяне на ресурси. Разпределените системи позволяват споделяне както на хардуерни (твърди дискове, принтери), така и на софтуерни (файлове, компилатори) ресурси.
2. Откритост.Това е възможността за разширяване на системата чрез добавяне на нови ресурси.
3. Паралелизъм.В разпределените системи множество процеси могат да се изпълняват едновременно на различни компютри в мрежата. Тези процеси могат да взаимодействат, докато се изпълняват.
4. Мащабируемост . Под мащабируемостразбира се възможността за добавяне на нови свойства и методи.
5. Толерантност към грешки. Наличието на множество компютри позволява дублиране на информация и устойчивост на някои хардуерни и софтуерни грешки. Разпределените системи могат да поддържат частична функционалност в случай на грешка. Пълен отказ на системата се случва само при мрежови грешки.
6. Прозрачност.Потребителите получават пълен достъп до ресурсите в системата, като в същото време информацията за разпределението на ресурсите в цялата система е скрита от тях.

Разпределените системи също имат редица недостатъци.

1. Сложност... Много по-трудно е да се разберат и оценят свойствата на разпределените системи като цяло и те са по-трудни за проектиране, тестване и поддръжка. Също така производителността на системата зависи от скоростта на мрежата, а не от отделните процесори. Преразпределението на ресурсите може значително да промени скоростта на системата.
2. Сигурност... Обикновено системата може да бъде достъпна от няколко различни машини, съобщенията в мрежата могат да бъдат наблюдавани и прихващани. Следователно в разпределена система е много по-трудно да се поддържа сигурността.
3. Контролируемост... Системата може да се състои от различни видове компютри, на които могат да бъдат инсталирани различни версии на операционни системи. Грешките на една машина могат да се разпространят на други машини по непредсказуем начин.
4. Непредсказуемост ... Реакцията на разпределените системи към някои събития е непредвидима и зависи от пълното натоварване на системата, нейната организация и натоварване на мрежата. Тъй като тези параметри могат постоянно да се променят, следователно времето за отговор на заявката може да се различава значително от времето.

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

1. Идентификация на ресурса ... Ресурсите в разпределените системи са разположени на различни компютри, така че системата за именуване на ресурси трябва да се мисли така, че потребителите да имат лесен достъп и да се позовават на ресурсите, от които се нуждаят. Пример е системата URL (Uniform Resource Locator), която дефинира имената на уеб страниците.
2. Комуникация... Универсалната работоспособност на Интернет и ефективното внедряване на TCP / IP протоколи в Интернет за повечето разпределени системи са примери за най-ефективния начин за организиране на комуникация между компютрите. Въпреки това, в някои случаи, когато се изисква специална производителност или надеждност, е възможно да се използват специализирани инструменти.
3. Качество на системното обслужване ... Този параметър отразява производителността, здравето и надеждността. Редица фактори влияят върху качеството на услугата: разпределението на процесите, ресурсите, хардуера и адаптивността на системата.
4. Софтуерна архитектура ... Софтуерната архитектура описва разпределението на системните функции между компонентите на системата, както и разпределението на тези компоненти между процесорите. Ако трябва да поддържате висококачествена системна услуга, изборът на правилната архитектура е от решаващо значение.

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

1. Архитектура клиент/сървър ... В този модел системата може да се разглежда като набор от услуги, предоставяни от сървъри на клиенти. В такива системи сървърите и клиентите се различават значително един от друг.
2. Тристепенна архитектура ... В този модел сървърът не предоставя услуги на клиенти директно, а чрез сървъра на бизнес логиката.

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

1. Архитектура на разпределени обекти ... В този случай няма разлики между сървъри и клиенти, а системата може да се разглежда като набор от взаимодействащи обекти, чието местоположение всъщност няма значение. Няма разлика между доставчика на услуги и техните потребители.

Тази архитектура е широко използвана днес и се нарича още архитектура на уеб услугите.Уеб услугата е приложение, което е достъпно през Интернет и предоставя някои услуги, чиято форма е независима от доставчика (тъй като се използва универсалният формат на данни - XML) и платформата на работа. В момента има три различни технологии, които поддържат концепцията за разпределени обектни системи. Това са технологиите EJB, CORBA и DCOM.

Първо, няколко думи за това какво е XML като цяло. XML е общ формат на данни, използван за предоставяне на уеб услуги. Уеб услугите се базират на отворени стандарти и протоколи: SOAP, UDDI и WSDL.

1. САПУН ( Протоколът за достъп до прост обект, разработен от W3C, дефинира формата за заявки към уеб услуги. Съобщенията между уеб услуга и нейния потребител са пакетирани в така наречените SOAP пликове (понякога наричани още XML пликове). Самото съобщение може да съдържа или заявка за извършване на някакво действие, или отговор - резултат от това действие.
2. WSDL (език за описание на уеб услугите).Интерфейсът на уеб услугата е описан в WSDL документи (а WSDL е подмножество на XML). Преди да разгърне услугата, разработчикът съставя нейното описание на език WSDL, посочва адреса на уеб услугата, поддържаните протоколи, списък с разрешени операции и формати на заявка и отговор.
3. UDDI (универсално описание, откриване и интеграция) -Протокол за търсене на интернет уеб услуги ( http://www.uddi.org/). Това е бизнес регистър, където доставчиците на уеб услуги регистрират услуги, а разработчиците намират услугите, които трябва да включат в своите приложения.

От разговора може да изглежда, че уеб услугите са най-доброто и безспорно решение и единственият въпрос е изборът на инструменти за разработка. Въпреки това не е така. Има алтернатива на уеб услугите, Семантичната мрежа, за която създателят на WWW Тим Бърнърс-Лий говори преди пет години.

Ако целта на уеб услугите е да улеснят комуникацията между приложенията, тогава семантичната мрежа е предназначена за решаване на много по-сложен проблем – използване на механизми за метаданни за повишаване на ефективността на стойността на информацията, която може да бъде намерена в мрежата. Това може да стане чрез изоставяне на документно-ориентирания подход в полза на обектно-ориентирания.

Библиография

1. СъмървилI. Софтуерно инженерство.
2. Драница А. Java срещу .NET. - "Компютъра", № 516.
3. Интернет ресурси.