Теория и практика построения баз данных (1088289), страница 113
Текст из файла (страница 113)
Кролге того, СУБД могут вызываться с полюшью кодовых библиотек. Ни АОО, пи ОЕЕ 1)В ие реализованы на платформе 1)г1!х. Ранее мы упомянули, что НТТР является протоколом без состояния, имея в виду, что сервер обрабатывает запрос и затем забывает о том, кто его присылал. Бесстатусная обработка неприемлема для большшктва приложений баз данных, поэтому возможность отслеживать состояние сеанса была добавлена в ПЯ для %1пг!олня 2000, а также в Тогпсаг и подобные ему обработчики сервлетов в мире ()шхггЕ!пцх. Как это сделано, вы увидите пз следующих двух глав. Многоуровневая обработка В некоторых приложениях трехуровневая архитектура возлагает непомерно большое бремя на шеЬ-сервер.
Вспомшгте, что лчеЬ-сервер не только работает как НТТР-сервер, который может отвечать на тысячи запросов, но еше и управляет соединениями с сервером базы данных, генерирует и передает ДЯ(.-запросы, формирует из результатов запросов представления, реализует логику приложения н обеспечивает соблюдение делового регламента.
И после всего этого он еше генерирует отклик пользователю, работаюшему с браузером. При такой нагрузке чнеЬ-сервер может стать элементом, ограничивающим производительность. Одно цз решений этой проблемы состоит в распределении нагрузки между большим количеством, возможно даже сотнями, серверов. Однако это решение может, в свою очередь, привести к ряду других проблем, поскольку для его воплощения требуется, чтобы на каждом из ннеЬ-серверов были установлены все программы, необходимые для выполнения вышеописанных функций. Это может стать для администратора настоящей головной болью. Другое решение — нспользоватынеЬ-сервер (нли серверы) только для обработки НТТР- запросов н откликов, а обработку представлений, делового регламента н т. п.
возложить на другие серверы. Это решение изображено на рнс, 14.6, и, где обработка представленнй и реализация делового регламента производится различными компьютерами. Рнс. 14.6. Примеры многоуровневой архитектуры: а — использование нескольких пРоцессоров для обработки представлений и делового регламента; б — использование нескольких процессоров для распределенной обработки Еше одна проблема из этой серии возникает, когда обработка одной транзакции распределена между множеством компьютеров Предположим, что в системе, изображенной на рис.
14.6, б, информация о заказе находится в базе данных б2б Глава !4. Сети, многоуровневые архитектуры н хгл(. Языки разметки н 0НТМ(. 527 РВ1, а информация о пользователе — в базе данных РВ2. Предположим далее, что для нормальной обработки заказа обновления необходимо произвести в обеих базах данных и что прежде, чем заказ будет принят к выполнению, необходимо отправить сообщение на производство и получить добро. Решение, показанное на рис. 14.6, 6, состоит в том, чтобы поручить одному серверу обработк у распределенных транзакций, а другим — обработку баз данных и сообщений.
Ясно, что сугцествует много возможностей. По мере того как организации бу дуг набирать опыт в электронной коммерции, вероятно возникновение новых шаолонов ьшогоуровневой обработки. На данном этапе вам просто следует уяснить, что обработка баз данных с использованием интернет-технологий не сводится к трем уровняль и на каждом уровне может быть множество серверов, с реди которых распределена нагрузка.
Языки разметки и 0НТМ1. Языки разметки (шагйир!апйнайез) служат для определения внешнего вида и поведения тчеЬ-странищы. Как уже отмечалось, первым таким языком, завоевавшим доминирующее положение в ЪЧеЬ, стал НТМЕ, являющийся подмножеством более мощного и сложного языка под названием оСМ(.. В этом разделе мы рассмотрим два языка разметки — динамический НТМ1. (РНТМ1) и ХМЕ. По уровшо сложности атн языки занимают промежуточное положение между НТМ1.
и БСМ1.. Но прежде чем углубляться в рассмотрение этих языков, обсудим сначала историческни контекст, в котором происходило развитие чеЬ-стандартов. Стандарты языков разметки НТМ(. изначально имел необычайный успех, потому что оп дал толчок к развитию сотен тысяч сайтов и сделал общение в %еЬ реальностью для широкой компьютернон обгцественцости. Со временем, однако, стали выявляться значительные недостатки первоначальной версии НТМЕ, особенно в том, что касалось разрабо тки туеЬ-приложений баз данных.
В ходе работы над преодолением этих недостатков выросло понимание необходимости появления стандартов. В противном случае каждый производитель вносил бы свои собственные усовершенствования, и вскоре получилось бы так, что определенные страницы могли бы обрабатываться только определенными браузерами, а это свело бы на нет одно из наиболее важных преимуществ ~ЧеЬ.
Поэтому начиная с 1994 г. Всемирный чеЬ-консорциум (Ч'огЫ %'Ые ттге!т Сопзогг!цгп, %ЗС) стал пропагандировать станларты для НТМ1. и других языков разметки. Эти стандарты приобрели большую зна шмость. Посетите сайт консорциума под адресу ааа.вЗ.ого. Там вы найдете полезную информацию, учебные пособия, продвигаемые (или рекомендуемые) стандарты и те стандарты, которые еще находятся в процессе развития.
Роль и значение стандартов будет для вас более ясны, если вы поймете, какие чувства питают к стандартам производители программного обеспечения. Это од- повременно и любовь, и ненависть. С одной стороны, производители любят стандарты, поскольку те обеспечивают порядок па рынке и определяют основной набор возможностей, который должны иметь продукты. С другой стороны, производители их ненавидят, поскольку стандарты могут обесценить возможности, функции и технологии, в которые могли быть вложены значительные инвестиции.
Стандарты являются для производителей палкой о двух концах еще и в другом смысле. Если разработанный продукт будет строго соответствовать станларту и не более того, то у покупателей не будет оснований отдать ему предпочтение перел продуктами конкурентов. Но если производитель добавит в продукт новые возможности и функции, его будут критиковать за то, что он не следует стандарту. Например, М!сгозо(г разработала язык РНТМЕ, которьш поддерживал стандарт Ч'ЗС под названием НТМ1. 4.(). Однако в язык были также добавлены функции, выходящие за рамки этого стандарта.
В зависимости от ситуации, эти возможности могут быть прекрасными, поскольку опи расширяют функциональность, или ужаснымн, поскольку онп работают адекватно пе во всех браузерах. По этой причине нестандартные возможности добавляются в продукт таким образом, чтобы другие продукты, не поддерживающие зти возможности, справлялись с этим более или менее элегантно.
Например, схема документа будет динамически разворачиваться и сворачиваться в браузерах, поддерживающих данную функцию, а в тех браузерах, где она не поддерживается, схема будет всегда изображаться в развернутом виде. Проблемы, связанные с НТМ~ Исходная версия НТМЕ ооладала рядом недостатков. Во-первых, содержимое, разметка и формат страницы были перемешаны между собой — определение содержигиого было невозможно отделить от разметки и формата. Это означало, что если вы хотите представить одно и то же содержимое несколькими способами, вам прилется создать две копни этого содержимого, каждую со своей разметкой и своим форматом. Для приложений баз данных это означало также, что ланные и материализация представления были сложным образом перемешаны. Другой недостаток заключался в отсутствии возможности определить стили. Было невозможно, например, сделать так, чтобы все заголовки выводились шрифтом определенной гарнитуры, размера и начертания.
Соответственно, если бы разработчик захотел поменять формат всех заголовков первого уровня, ему пришлось бы найти все такие заголовки на странице (или на сайте) и изменить формат каждого из них по отлельности. Таким образом, нужна была возможность определить стиль заданного элемента формата. Третьим слабым местом оригинального НТМЕ было то, что к элегиентам туеЬ- страницы нельзя было обращаться из сценариев н других программ.
Например, не оыло возлюжности обращаться из сценария к элементу, представляюгцему заголовок страницы, чтобы динамически менять его внешний впд или расположение. Невозможно также было написать кол, реагирующий на события Аг!пг)отуз, такие как передвижение мыши и щелчки ее кнопками. Следовательно, чтобы изменить структуру или внешшьй вид страницы, браузер должен был заново 628 Глава 14. Сети, многоуровневые архитектуры и ХЬП. Языки разметки и С<НТМ1. 829 обратиться к серверу и получить с него целиком новую страницу. Такие круговые путешествия были медленными п неэкономными. Наконец, и вто для нас важнее всего, в НТМЕ не было конструкций, упрощающих кэширование и манипуляцию данными на клиенте.
Всякий раз, когда браузеру нужно было вывести дополнительные данные, он был вынужден обращаться к серверу. В связи со всеми перечисленнь<ми обстоятельствами, Всемирный Ч<еЬ-консорциум разработал для НТМ1 станларт под названием НТМЕ 4.0, в котором были введены возможности и функции, нацеленные на преодоление этих и других недостатков. онтм~ ВНТМ1.
— это реализация стандарта НТМ1. 4.0, разработанная М1сгоюра Она включает в себя все, что входит в стандарт, плюс дополнительные возможности и функции. РНТМЕ поддерживается браузерол< М<сгоэо(г 1пгегпег Ехр!огег 4.0 и более поздних версий, а также П5 4.0 и выше. Негзсаре Хат<па<от поддерживает только ту часть ВНТМ1, которая относится к НТМ1 4.0; остальные возможности РНТМ1, выходящие за рамки данного стандарта, им не поддерживаются. Следовательно, используя РНТМ1, необходимо следить за тем, чтобы оставаться в пределах НТМ1. 4.0, если пользователи создаваемого приложения работают с браузерами, отличными от 1п<егпе< Ехр!огег.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
