1. Web-среда
Принципно погледнато, организацията на Web-средата е проста, защото тя се оформя от три основни компонента: Web-сървър, мрежова връзка и Web-клиент (браузър). Сървърът прослушва мрежата и изчаква получаването на заявка от даден клиент. След получаването и обработването й, той изпраща обратно към клиента отговор във вид на документ (страница), който браузърът изобразява на монитора на клиентския компютър. Най-често този документ е Web-страница, описана на езика HTML, към който непрекъснато се добавят нови, все по-разнообразни разширения. Възможно е обаче типът на съдържа-нието на документа да е друг – например обикновен текст или графичен документ в определен формат – GIF, JPEG и т.н. Правилата, по които се осъществява комуникацията между клиента и сървъра се опреде-лят от протокола HTTP.
2. Протоколът HTTP. Обработка на заявки
HTTP (HyperText Transfer Protocol) е един от про-токолите от приложно ниво на фамилията TCP/IP. Той осигурява поддръжката на разпределени системи с хипермедийна среда.
Клиентските HTTP заявки и отговорите, подавани от сървъра обратно към клиента, имат подобна струк-тура, която включва няколко реда текст.
Клиентска HTTP заявка.
Клиентът се свързва към HTTP-сървъра на опре-деления порт, който по подразбиране е 80, като из-праща заявка, състояща се от следните елементи:
• ред за заявка;
• заглавна част (header);
• тяло на заявката.
.
Редът за заявка има следния формат:
Method Request-URI Protocol
Да разгледаме един пример: редът за заявка
GET /index.htm HTTP/1.1
означава, че тази заявка използва метод GET, заяве-ният документ се намира в главната директория на сървъра, името му е index.htm, и се използва версия 1.1 на HTTP-протокола.
Методите за HTTP-заявки указват на сървъра по какъв начин трябва да обработи пристигналата заяв-ка. В табл. 1.1. са систематизирани основните методи за заявка в HTTP1.1.
Най-използвани са методите POST и GET. Обикно-вено GET се използва за прости заявки, в които няма голям обем данни. При по-сложни заявки се използва POST. Използването на PUT и DELETE изисква на кли-ента да бъдат осигурени специални правомощия.
Табл. 1.1.
Методи за заявка в HTTP 1.1.
След реда за заявка следва заглавната част. Тя не е задължителна и може да заема няколко реда. Всеки ред се състои от два елемента: име на параметър и стойност за този параметър. С тяхна помощ клиентът подава информация на сървъра за своята конфигурация и за форматите на документите, които е в състояние да приема. Имената и допустимите стойности на тези параметри са стандартизирани под името HTTP-заглавия (хедъри). Някои от тях се използват при формирането на HTTP-заявки, други - при HTTP-отговорите, разбира се – всеки със специфичното си предназначение.
В табл. 1.2. са представени някои от най-важните хедъри.
Табл.1.2.
Хедъри за заявка и отговор в HTTP 1.1.
Краят на заглавната част на заявката се отбелязва с 1 празен ред. Тялото на заявката също не е задължително. То съдържа допълнителни данни, които трябва да бъдат обработени от сър-въра. По такъв начин напр. става изпращането на данните от 1 форма, използваща POST метода.
Цялата HTTP-заявка завършва с изпращането на още един празен ред. Следващият пример представлява една коректна заявка:
Пример 1.1.
HTTP заявка
GET /index.html HTTP/1.1
accept: */*
accept-language: bg
referrer: http://localhost/test/start.html
user-agent: Mozilla/4.0
(compatible;MSIE 6.0;Windows NT5.0)
Пълно описание на всички HTTP-хедъри и информация за допустимите стойн. за всеки от тях може да бъдат намерени в спецификацията на HTTP/1.1, която може да се изтегли от адрес
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/ draft-lafon-rfc2616bis-03.html
HTTP отговор от сървъра.
Отговорът на HTTP-сървъра, който се изпраща към клиента в резултат на получена заявка, също се състои от три елемента:
• ред за състоянието;
• заглавна част (header);
• тяло на отговора.
Редът за състояние има следния формат:
Protocol Status-code Description
Например в нормалния случай редът за състоя-нието е:
HTTP/1.1 200 OK
Това означава, че сървърът използва за своя от-говор HTTP версия 1.1, а код 200 и описанието OK показват, че заявката е успешно обработена.
В табл. 1.3. са показани основните категории на кодовете за състояние. Конкретните стойности са описани пълно в спецификацията на HTTP/1.1.
Табл.1.3.
Категории на кодовете на състояние в HTTP 1.1.
След реда за съст. сървърът изпраща редовете, формиращи заглавната част на отговора. Начинът на тяхното оформяне е аналогичен с този при HTTP-заявките, но се използват хедъри, с които сървърът подава информ. за себе си и за връщания документ. Край на заглавната част на отговора се поставя с 1 празен ред.
Тялото на отговора представлява същинската част на резултата от изпълнението на заявката. Ако то е успешно, тялото на отговора всъщност е самият заявен документ. Ако заявката не може да се изпълни, в тялото на отговора сървърът подава допълнителна информация за причините за неуспеха. В заглавната част сървърът описва характеристиките на тялото, като типът на съдържанието (с хедъра Content-Type) и неговата дължина (с хедъра Content-Length).
Следващият пример демонстрира как изглежда един реален отговор от HTTP-сървър (за краткост не са посочени всички хедъри):
Пример 1.2.
HTTP отговор
HTTP/1.1 200 OK
Date: Fri, 11 Jan 2008 14:25:33 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 11 Jan 2008 10:12:26 GMT
Content-Length: 4538
Connection: close
Content-Type: text/html; charset=iso-8859-1
…
3. Web-приложения
Съществуват много дефиниции на понятието “Web-приложение”. Според някои от тях това е интерактивно приложение, което е достъпно през Internet или Intranet; според други това е приложение, чиито интерфейс е съставен от динамични Web-страници, или приложение, даващо достъп до набор от страници, разположени в директориите на Web-сървър. Всичко това е съвсем вярно, но не дава точна представа за организацията и функционирането на Web-приложенията.
В най-простия модел на клиент-сървър с-мите се използва двуслойна архитектура, вкл. клиента и сървъра. Тук основната част от натоварването се поема от сървъра – той диспечери-зира заявките, комуникира с клиентите и с базата данни, което намалява неговата ефективност.
Значително по-ефективни са решенията, използ-ващи трислойна архитектура. При тях могат да се раз-граничат три ясно дефинирани слоя, всеки от които може да е разположен на отделна платформа:
• Клиентски слой – той отговаря за представянето на информацията пред потребителя и oсигурява фор-мирането на различните заявки към системата;
• Приложен слой. Това е междинният слой м/у слоя на клиента и слоя на данните. Той осигурява управлението на обмена на данни, реализирайки логиката на приложението, обслуж-ващо клиента (бизнес-логика). Реализира се като набор от реентерантни модули, всеки със специфично предназначение, под управлението на сървър на приложенията (Application server);
• Слой на данните. Това са един или няколко източника на данни, които могат да бъдат разпределени на различни сървъри в мрежата.
Трислойната организация на клиент-сървър приложенията има сериозни предимства. Модулността на бизнес-логиката в средния слой позволява лесната модификация на определени елементи, без това да засяга работата на останалите. Разделянето на приложните функции от тези за управление на базата данни позволява постигането на по-балансирано натоварване. Специа-лизацията на отделните слоеве опростява тяхната реализация и поддържане.
Спецификата на Web-средата позволява още по-детайлното разслояване на архитектурата на клиент-сървър приложението. На следващата фигура е пока-зана неговата обща схема:
Тук разделението на функциите е още по-добро. Клиентът и Web-сървърът са силно олекотени, защото не извършват операции, свързани с логиката на приложението. Това позволява да се опрости реализацията им и да се повиши ефективността на тяхната работа. Основната тежест пада върху бизнес-логиката. Тя приема заявките, подадени от клиента към Web-сървъра и ги обработва, при което отправя нужните заявки към сървъра на БД.
Накрая оформя резултата, като конструира нова или видоизменя текущата Web-страница и я подава на Web-сървъра, който я връща на клиента. Големият товар върху бизнесслоя се разпределя балансирано, благодарение на модулната му структура.
При реализацията на Web-приложения по тази принципна схема са възможни вариации в някои от слоевете. В някои случаи е уместно да се разшири функционалността на клиента. Например в страниците за попълване на форми, валидирането на формата може да стане с помощта на клиентски скриптове. Така се избягват ненужните обръщения към сър-въра при некоректно попълнени данни, намалява се мрежовият трафик и се печели време.
В зависимост от избраната технология за реализация на бизнесслоя също могат да се получат различия в схемата. Във всички случаи обаче многослойните приложения доказват своята повишена ефективност и производителност.
Принципно погледнато, организацията на Web-средата е проста, защото тя се оформя от три основни компонента: Web-сървър, мрежова връзка и Web-клиент (браузър). Сървърът прослушва мрежата и изчаква получаването на заявка от даден клиент. След получаването и обработването й, той изпраща обратно към клиента отговор във вид на документ (страница), който браузърът изобразява на монитора на клиентския компютър. Най-често този документ е Web-страница, описана на езика HTML, към който непрекъснато се добавят нови, все по-разнообразни разширения. Възможно е обаче типът на съдържа-нието на документа да е друг – например обикновен текст или графичен документ в определен формат – GIF, JPEG и т.н. Правилата, по които се осъществява комуникацията между клиента и сървъра се опреде-лят от протокола HTTP.
2. Протоколът HTTP. Обработка на заявки
HTTP (HyperText Transfer Protocol) е един от про-токолите от приложно ниво на фамилията TCP/IP. Той осигурява поддръжката на разпределени системи с хипермедийна среда.
Клиентските HTTP заявки и отговорите, подавани от сървъра обратно към клиента, имат подобна струк-тура, която включва няколко реда текст.
Клиентска HTTP заявка.
Клиентът се свързва към HTTP-сървъра на опре-деления порт, който по подразбиране е 80, като из-праща заявка, състояща се от следните елементи:
• ред за заявка;
• заглавна част (header);
• тяло на заявката.
.
Редът за заявка има следния формат:
Method Request-URI Protocol
Да разгледаме един пример: редът за заявка
GET /index.htm HTTP/1.1
означава, че тази заявка използва метод GET, заяве-ният документ се намира в главната директория на сървъра, името му е index.htm, и се използва версия 1.1 на HTTP-протокола.
Методите за HTTP-заявки указват на сървъра по какъв начин трябва да обработи пристигналата заяв-ка. В табл. 1.1. са систематизирани основните методи за заявка в HTTP1.1.
Най-използвани са методите POST и GET. Обикно-вено GET се използва за прости заявки, в които няма голям обем данни. При по-сложни заявки се използва POST. Използването на PUT и DELETE изисква на кли-ента да бъдат осигурени специални правомощия.
Табл. 1.1.
Методи за заявка в HTTP 1.1.
След реда за заявка следва заглавната част. Тя не е задължителна и може да заема няколко реда. Всеки ред се състои от два елемента: име на параметър и стойност за този параметър. С тяхна помощ клиентът подава информация на сървъра за своята конфигурация и за форматите на документите, които е в състояние да приема. Имената и допустимите стойности на тези параметри са стандартизирани под името HTTP-заглавия (хедъри). Някои от тях се използват при формирането на HTTP-заявки, други - при HTTP-отговорите, разбира се – всеки със специфичното си предназначение.
В табл. 1.2. са представени някои от най-важните хедъри.
Табл.1.2.
Хедъри за заявка и отговор в HTTP 1.1.
Краят на заглавната част на заявката се отбелязва с 1 празен ред. Тялото на заявката също не е задължително. То съдържа допълнителни данни, които трябва да бъдат обработени от сър-въра. По такъв начин напр. става изпращането на данните от 1 форма, използваща POST метода.
Цялата HTTP-заявка завършва с изпращането на още един празен ред. Следващият пример представлява една коректна заявка:
Пример 1.1.
HTTP заявка
GET /index.html HTTP/1.1
accept: */*
accept-language: bg
referrer: http://localhost/test/start.html
user-agent: Mozilla/4.0
(compatible;MSIE 6.0;Windows NT5.0)
Пълно описание на всички HTTP-хедъри и информация за допустимите стойн. за всеки от тях може да бъдат намерени в спецификацията на HTTP/1.1, която може да се изтегли от адрес
http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/ draft-lafon-rfc2616bis-03.html
HTTP отговор от сървъра.
Отговорът на HTTP-сървъра, който се изпраща към клиента в резултат на получена заявка, също се състои от три елемента:
• ред за състоянието;
• заглавна част (header);
• тяло на отговора.
Редът за състояние има следния формат:
Protocol Status-code Description
Например в нормалния случай редът за състоя-нието е:
HTTP/1.1 200 OK
Това означава, че сървърът използва за своя от-говор HTTP версия 1.1, а код 200 и описанието OK показват, че заявката е успешно обработена.
В табл. 1.3. са показани основните категории на кодовете за състояние. Конкретните стойности са описани пълно в спецификацията на HTTP/1.1.
Табл.1.3.
Категории на кодовете на състояние в HTTP 1.1.
След реда за съст. сървърът изпраща редовете, формиращи заглавната част на отговора. Начинът на тяхното оформяне е аналогичен с този при HTTP-заявките, но се използват хедъри, с които сървърът подава информ. за себе си и за връщания документ. Край на заглавната част на отговора се поставя с 1 празен ред.
Тялото на отговора представлява същинската част на резултата от изпълнението на заявката. Ако то е успешно, тялото на отговора всъщност е самият заявен документ. Ако заявката не може да се изпълни, в тялото на отговора сървърът подава допълнителна информация за причините за неуспеха. В заглавната част сървърът описва характеристиките на тялото, като типът на съдържанието (с хедъра Content-Type) и неговата дължина (с хедъра Content-Length).
Следващият пример демонстрира как изглежда един реален отговор от HTTP-сървър (за краткост не са посочени всички хедъри):
Пример 1.2.
HTTP отговор
HTTP/1.1 200 OK
Date: Fri, 11 Jan 2008 14:25:33 GMT
Server: Apache/2.0.54
Last-Modified: Fri, 11 Jan 2008 10:12:26 GMT
Content-Length: 4538
Connection: close
Content-Type: text/html; charset=iso-8859-1
…
3. Web-приложения
Съществуват много дефиниции на понятието “Web-приложение”. Според някои от тях това е интерактивно приложение, което е достъпно през Internet или Intranet; според други това е приложение, чиито интерфейс е съставен от динамични Web-страници, или приложение, даващо достъп до набор от страници, разположени в директориите на Web-сървър. Всичко това е съвсем вярно, но не дава точна представа за организацията и функционирането на Web-приложенията.
В най-простия модел на клиент-сървър с-мите се използва двуслойна архитектура, вкл. клиента и сървъра. Тук основната част от натоварването се поема от сървъра – той диспечери-зира заявките, комуникира с клиентите и с базата данни, което намалява неговата ефективност.
Значително по-ефективни са решенията, използ-ващи трислойна архитектура. При тях могат да се раз-граничат три ясно дефинирани слоя, всеки от които може да е разположен на отделна платформа:
• Клиентски слой – той отговаря за представянето на информацията пред потребителя и oсигурява фор-мирането на различните заявки към системата;
• Приложен слой. Това е междинният слой м/у слоя на клиента и слоя на данните. Той осигурява управлението на обмена на данни, реализирайки логиката на приложението, обслуж-ващо клиента (бизнес-логика). Реализира се като набор от реентерантни модули, всеки със специфично предназначение, под управлението на сървър на приложенията (Application server);
• Слой на данните. Това са един или няколко източника на данни, които могат да бъдат разпределени на различни сървъри в мрежата.
Трислойната организация на клиент-сървър приложенията има сериозни предимства. Модулността на бизнес-логиката в средния слой позволява лесната модификация на определени елементи, без това да засяга работата на останалите. Разделянето на приложните функции от тези за управление на базата данни позволява постигането на по-балансирано натоварване. Специа-лизацията на отделните слоеве опростява тяхната реализация и поддържане.
Спецификата на Web-средата позволява още по-детайлното разслояване на архитектурата на клиент-сървър приложението. На следващата фигура е пока-зана неговата обща схема:
Тук разделението на функциите е още по-добро. Клиентът и Web-сървърът са силно олекотени, защото не извършват операции, свързани с логиката на приложението. Това позволява да се опрости реализацията им и да се повиши ефективността на тяхната работа. Основната тежест пада върху бизнес-логиката. Тя приема заявките, подадени от клиента към Web-сървъра и ги обработва, при което отправя нужните заявки към сървъра на БД.
Накрая оформя резултата, като конструира нова или видоизменя текущата Web-страница и я подава на Web-сървъра, който я връща на клиента. Големият товар върху бизнесслоя се разпределя балансирано, благодарение на модулната му структура.
При реализацията на Web-приложения по тази принципна схема са възможни вариации в някои от слоевете. В някои случаи е уместно да се разшири функционалността на клиента. Например в страниците за попълване на форми, валидирането на формата може да стане с помощта на клиентски скриптове. Така се избягват ненужните обръщения към сър-въра при некоректно попълнени данни, намалява се мрежовият трафик и се печели време.
В зависимост от избраната технология за реализация на бизнесслоя също могат да се получат различия в схемата. Във всички случаи обаче многослойните приложения доказват своята повишена ефективност и производителност.
This entry was posted
at 11:33
and is filed under
Компютърни системи и технологии
. You can follow any responses to this entry through the
.