КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Затраты 7 страница
12.7. Дополнительная литература Одними из первых исследований по методу СВАМ явились [Kazman 01] и [Asun- di 01]. Моделированию затрат посвящены работы [Boehm 81] и [Jones 99]. Об оценке архитектуры системы ECS по методике АТАМ речь идет в издании [Clements 02а]. 12.8. Дискуссионные вопросы 1. Одно из нововведений СВАМ заключается в употреблении кривых «реакция-полезность». Ознакомьтесь со стилями кривых, изображенных на рис. 12.2. Каковы, по вашему мнению, были обстоятельства, в которых мы при участии заинтересованных лиц выяснили информацию для построения каждой из этих кривых? Какие ситуации они выражают? 2. Попытки определения издержек и выгод обычно сопряжены с неопределенностью. Каковы типичные источники неопределенности и как их следует характеризовать, измерять и минимизировать? Глава 13 Всемирная паутина. Конкретный пример реализации способности к взаимодействию (в соавторстве сХон-Мей Чен (Хои-Мей Чен (Hong-Mei Chen) — адъюнкт-профессор факультета менеджмента в области информационных технологий Университета шт. Гавайи.)) Нашей основной целью было достижение гибкости. Любые спецификации, призванные обеспечить способность к взаимодействию, на самом деле накладывали на реализацию Всемирной паутины ограничения. Таким образом, число спецификаций требовалось свести к минимуму... а самые необходимые следовало составить так, чтобы они не зависели друг от друга... Такой подход предоставляет возможность замены отдельных элементов проектного решения без корректировки архитектуры как таковой. Тим Берперс-Jlu [Bemers-Lee 96b] Полагаю, что в будущем — не слишком отдаленном — у любого, не обзаведшегося собственной веб-страницей, будет полное право на этом основании требовать от правительства выделения субсидии.
Скотт Адамс, создатель Dilbert Наверное, самый выразительный пример практического действия архитектурноэкономического цикла (Architecture Business Cycle, ABC) — это изменения, которым подверглись задачи, бизнес-модель и архитектура Всемирной паутины с момента ее появления в 1990 году. Никто — ни заказчики, ни пользователи, ни сам архитектор (Тим Бернерс-Ли) — в тот момент не могли даже предположить, что Всемирной паутине уготовано пройти этап бурного развития и умопомрачительного роста. В настоящей главе мы намерены рассмотреть Всемирную паутину с точки зрения ABC и обратить ваше внимание на то, как изменяющиеся задачи и коммерческие потребности ее игроков отражаются на уровне архитектуры. Сначала мы обратимся к тем требованиям, которые предъявлялись к Сети первоначально, к ее первым игрокам, а затем проанализируем изменения, происшедшие в серверной архитектуре под влиянием ЛВС. 13.1. Отношение к архитектурноэкономическому циклу Предложение об организации Всемирной паутины изначально сформулировал Тим Бернерс-Ли (Tim Berners-Lee) — научный сотрудник Европейской лаборатории ядерных исследований (European Laboratory for Particle Physics, CERN). Понаблюдав за другими сотрудниками CERN, он пришел к выводу, что они формируют постоянно развивающуюся социальную «паутину». Люди приходили и уходили, организовывали новые научные сообщества, распускали старые, пользовались одними и теми же документами, болтали в курилках и занимались кучей других дел. Идея Бернерса-Ли состояла в том, чтобы подкрепить эту неформальную сеть аналогичной паутиной, связывающей представленную в электронном виде информацию. В 1989 году он составил и распространил в пределах CERN документ, озаглавленный «Управление информацией: предложение» («Information Management: A Proposal»). К октябрю 1990 года пересмотренная версия предложения была утверждена руководством, и, после того как для нового проекта выбрали имя «Всемирная паутина» (World Wide Web), началась его разработка.
Элементы ABC, которые участвовали в первоначальном предложении, получившем поддержку руководства CERN, изображены на рис. 13.1. Исходная система была призвана активизировать взаимодействие между научными сотрудниками CERN (конечными пользователями) в рамках неоднородной вычислительной среды. В роли заказчика выступило руководство CERN, а разработчиком оказался один-единственный исследователь. Согласно предложенной Бернерсом-Ли экономической модели, проектируемая система должна была стимулировать обмен информацией между штатными сотрудниками CERN. Ограниченность самого предложения и поставленных задач (носивших, за невозможностью проверки реальности их достижения, умозрительный характер) компенсировалась незначительностью вложений со стороны CERN — для создания и тестирования системы требовалось всего-то несколько месяцев труда одного исследователя. Тем исследователям, которые уже с начала 1970-х годов, когда появилась сеть Интернет, эксплуатировали ее возможности, техническая база новой системы не казалась чем-то из ряда вон выходящим. Центральное управление в существовавшей сети осуществлялось крайне фрагментарно (обязанности добровольческих комитетов сводились к определению протоколов, обеспечивавших передачу информации между различными узлами Интернета, и выделению полномочий для создания новых новостных групп); кроме того, для нее был характерен
стихийный, «дикарский» стиль общения, основными каналами которого служили специализированные новостные группы. Первые гипертекстовые системы появились еще раньше — все началось с концепции Ванневара Буша (Vannevar Bush), изложенной им в 1940-х годах. Исследования в рамках этой концепции проводились в 1960-е, 1970-е и даже в 1980-е годы; в частности, регулярно собирались конференции, посвященные гипертексту. Впрочем, крупномасштабной реализации концепции Буша к 1980-м годам так и не случилось — гипертекст в основном использовался в небольших системах управления документацией. Как оказалось, так будет не всегда.
В 1990 году руководство CERN одобрило предложение Бернерса-Ли. К ноябрю он разработал на платформе NeXT первую веб- программу; из этого со всей очевидностью следует, что к работе над реализацией он приступил, не дожидаясь ответа со стороны руководства. Рассогласованность позиции руководящих инстанций и действий исследователей вообще характерна для научно-исследова- тельских организаций, в которых начальные капиталовложения в проекты держатся на низком уровне. Неструктурированная разработка характерна для них в большей степени, чем для коммерческих компаний, что объясняется их ориентацией на свежие решения и творческие устремления своих сотрудников, а следовательно, большей, по сравнению со среднестатистической компанией-разра- ботчиком, свободой действий. Некоторые характеристики первоначальной реализации веб-системы до сих пор не реализованы в браузерах. К примеру, веб-система предусматривала для пользователей возможность создания ссылок, не выходя из программы просмотра; кроме того, комментировать информацию могли как авторы, так и читатели. Поначалу Бернерс-Ли был уверен в том, что пользователи не захотят возиться с языком разметки гипертекста (HyperText Markup Language, HTML) и унифи- цированными указателями ресурсов (URLs). Как оказалось, он ошибался. Ради возможности создания веб-публикаций пользователи были готовы мириться с этими неудобствами. 13.2. Требования и атрибуты качества Согласно представлениям сотрудников CERN и первоначальной реализации, Всемирная паутина (World Wide Web, WWW) характеризовалась рядом желаемых атрибутов качества. Она должна была воплотить переносимость, способность к взаимодействию с компьютерами разных типов (при условии, что на них установлено одно и то же программное обеспечение), масштабируемость и расширяемость. Коммерческие задачи по стимулированию взаимодействия между пользователями и созданию гетерогенной вычислительной среды диктовали реализацию таких атрибутов качества, как удаленный доступ, способность к взаимодействию, расширяемость и масштабируемость; все это в конечном итоге вылилось в создание libWWW — первой программной библиотеки, поддерживающей веб-разработку и распределенную архитектуру типа «клиент-сервер». Благодаря реализации в первоначальной программной архитектуре перечисленных свойств появилась инфраструктура, на основе которой Всемирная паутина впоследствии получила стремительнейшее развитие (табл. 13.1). Поскольку в libWWW предусматривается строгое разделение задач, библиотека может работать практически на любом аппаратном обеспечении, без труда приспосабливается к новым протоколам, форматам данных и приложениям. Отсутствие централизованного управления позволяет Паутине расти бесконечно.
Ниже мы намерены более подробно разобрать эти, а также некоторые другие базовые требования; к структуре библиотеки libWWW мы вернемся немного позже, в разделе 13.3. Стоит заметить, что требование об удобстве использования изначально сформулировано не было, а умопомрачительный взлет популярности Паутины начался лишь после возникновения «мышиных» браузеров. С другой стороны, требование к переносимости и поддержке гетерогенной вычислительной среды привело к появлению самого понятия «браузер» как отдельного элемента и тем самым подготовило почву для разработки более сложных программ просмотра. Первоначальные требования В первоначальных предложениях по проекту «Всемирная паутина» были озвучены следующие требования. ♦ Удаленный доступ в пределах отдельных сетей. Любая информация, хранящаяся на любой входящей в сеть CERN машине, должна быть доступна с любой другой машины в этой сети. ♦ Гетерогенность. Ограничения по работе системы на той или иной аппаратной или программной платформе недопустимы. ♦ Децентрализация. Согласно законам социальной паутины и Интернета, существование монопольного источника данных и услуг также не допускается. Данное требование ставилось в расчете на дальнейшее развитие WWW. В частности, следовало децентрализовать операцию установки ссылок на документы. ♦ Доступ к существующим данным. Существовавшие базы данных требовалось сделать доступными. ♦ Возможность введения новых данных пользователями. «Публиковать» в Сети свои собственные данные пользователи должны были через тот же интерфейс, с помощью которого они просматривали уже опубликованную информацию. ♦ Личные ссылки. Требовалась возможность частного комментирования ссылок и узлов. ♦ Оформление. Первоначально в качестве единственной формы отображения данных планировался вывод на терминал 24 х 80 символов ASCII. Графическое представление считалось необязательным. ♦ Анализ данных. Пользователям следовало предоставить возможность поиска по различным базам данных, выявления аномалий, закономерностей, девиаций и пр. В качестве примера Бернерс-Ли упоминал поиск недокументированного ПО и организаций без штата. ♦ Активные ссылки. Учитывая то, что информация постоянно изменяется, при ее просмотре пользователю необходимо было предоставить возможность обновления. Этого можно было добиться посредством извлечения информации при каждом обращении по соответствующей ссылке или (что сложнее) путем оповещения пользователей об изменении информации, доступной по определенному адресу.
Помимо перечисленных требований было установлено несколько антитребований (nonrequirements). В частности, защита авторских прав и данных явно определялась как требования, которые в рамках данного проекта (в его исходной версии) реализованы не будут. Дело в том, что Всемирная паутина изначально планировалась как общедоступная среда. Кроме того, согласно оригинальному предложению, пользователи не обязаны были отдавать предпочтение какому-то одному формату разметки. Ниже перечислены некоторые критерии и характеристики, которые в рассматриваемое время часто встречались в предложениях по системам гипертекста, но, несмотря на это, не были отражены в предложении по WWW: ♦ контроль над топологией; ♦ определение методик навигации и требований по пользовательскому интерфейсу, в том числе по ведению журнала визуальной истории; ♦ наличие нескольких типов ссылок, отражающих разные отношения между узлами. * Некоторые требования из числа продекларированных первоначально вошли в состав современной реализации Всемирной паутины; иные на сегодняшний день не реализованы или реализованы частично. Важность отдельных требований сильно недооценена — к примеру, возможности анализа данных, а также создания активных и личных ссылок до сих пор не получили должного внимания и по большей части не отражены на практике. Для беспрецедентных систем в целом характерны адаптация и выборочная отсрочка. Мало того что под видом требований часто подаются списки желаемых характеристик, разобраться с компромиссными решениями, которые приходится принимать для реализации этих требований, в беспрецедентных системэх зачастую удается лишь после создания проекта. Одни требования в процессе принятия компромиссных решений приобретают относительно большую важность, другие — относительно меньшую. Про одно из вышеперечисленных требований можно со всей определенностью сказать, что его влияние сильно недооценили. Речь идет об «оформительской» функции графики, которая на сегодняшний день формирует львиную долю веб-трафика. Графическая информация возбуждает недюжинный интерес, и этим определяется ее доля в интернет-трафике. И тем не менее ни Бернерс-Ли, когда составлял первоначальное предложение, ни руководство CERN, когда его утверждало, не проявили должного внимания к графике, и первый браузер стал линейным. Аналогичным образом, в первоначальном предложении не было ни намека на намерения обеспечить поддержку звука и видеоизображения. По мере прохождения Всемирной паутиной архитектурно-экономического цикла отдельные антитребования превратились в требования. В частности, существенный вес приобрела проблема безопасности; в особо крупных масштабах она обозначила себя после того, как па лидирующие позиции в составе веб-тра-, фика стала выходить коммерческая информация. С учетом распределенности н децентрализации сети Интернет проблема безопасности становится сложной и многокомпонентной. Трудно говорить о безопасности, если нельзя гарантировать защищенный доступ к приватным данным, — Всемирная паутина открывает возможность проникновения в систему клиента, которой при случае не преминут воспользоваться непрошеные гости. За последние несколько лет вышеупомянутая проблема стала еще более актуальной — структура и направление развития WWW теперь определяются предприятиями электронной коммерции, безопасное функционирование которых обеспечивается многочисленными специализированными механизмами. Наиболее очевидным решением представляется простое шифрование уязвимых данных. В большинстве случаев оно осуществляется средствами протокола защищенных сокетов (secure sockets layer, SSL), представленного в веб-браузерах иод именем протокола защищенной передачи гипертекста (hypertext transfer protocol secure, HTTPS). Впрочем, этот протокол лишь снижает вероятность выслеживания приватных данных во время их передачи но общедоступной сети. Другая категория решений, представителем которой является технология Microsoft Passport, ориентирована на проверку достоверности сведений, которые пользователь предоставляет сам о себе. (Различные аспекты безопасности рассматривались в главе 4, а в главе 5 изложен ряд тактик их реализации.) Требования приходят и уходят Предсказать невиданный рост Всемирной паутины (равно как и Интернета в целом), происшедший за последние несколько лет, было невозможно. Согласно статистическим данным 2001 года, каждые полгода Всемирная паутина удваивается в размере. Так, она прошла путь от 130 сайтов в середине 1993 года до 230 ООО в середине 1996-го и, наконец, включала в себя 27 миллионов сайтов в начале 2001-го (см. табл. 13.1). На рис. 13.2 изображена схема интернет-магистралей, охватывающих всю территорию Соединенных Штатов. Соответственно возросла численность интернет-хостов (их статистика ведется согласно зарегистрированным IP-адресам) — от 1,3 миллиона в 1993 году до 9,5 миллиона в начале 1996-го. Процессы роста охватывают как Всемирную паутину, так и Интернет в целом, однако по темпам первая явно опережает. Эта тенденция хорошо прослеживается по последнему столбцу табл. 13.1, демонстрирующему стабильное снижение отношения интернет-хостов к веб-серверам. Иначе говоря, все большая доля интернет-хостов становится веб-серверами. Меняется не только масштаб Всемирной паутины, но и ее характер, о чем свидетельствует содержание третьего столбца табл. 13.1. Несмотря на истоки в научно-исследовательском сообществе, все большее место в ней занимает коммерческий трафик (подтверждение тому — количество интернет-хостов с именами, заканчивающимися на.сот). В процентном отношении сайтов в домене.сот около 55 %; стабилизация этой цифры никак не связана с каким бы то ни было спадом коммерческой деятельности — скорее ее следует относить к повышению популярности других доменов наподобие.net и.biz.
Весьма занимателен побочный эффект упрощения и распространения доступа к Всемирной паутине. Удобный, практически неконтролируемый доступ к графике подтолкнул развитие «киберпорнографии», что, в свою очередь, определило появление нового требования о возможности маркирования контента и контролируемости доступа к нему. В результате появилась спецификация платформы отбора информации в Интернете (platform for Internet content selection, PICS) — общеотраслевого набора принципов и их реализаций, предусматривающего маркирование контента и гибкие критерии отбора. Таким образом, потребители информации получили возможность выбирать материал, который они хотят (а их клиенты могут) просматривать, руководствуясь лишь собственными вкусами и убеждениями; при этом ограничения свободы действий контент-провайдеров удалось избежать. Действенность PICS проявляется, когда, к примеру, родитель желает ограничить просмотр детьми видеоматериала фильмами с определенным рейтингом, а работодатель — запретить своим подчиненным посещать в рабочее время не относящиеся к делу сайты. Чтобы уяснить степень различия современной Всемирной паутины от ее первоначального замысла, представим, что в своем предложении Бернерс-Ли сформулировал требование об ограничении информации, мотивируя его необходимостью уберечь детей от доступа к порнографическим материалам. Как бы на это отреагировало руководство CERN? Без разговоров отклонило бы. То, как меняются задачи заинтересованных лиц, мы обсудим в разделе 13.5 применительно к архитектурно-экономическому циклу Всемирной паутины. 1 © 1996, Donna Сох, Robert Patternson; производство Национального центра но применению суперкомпьютеров (National Center for Supcrcomputing Applications), Упипсрситст шт. Иллинойс, Урба- на-Шамиейн. Перепечатывается с разрешения.
13.3. Архитектурное решение Архитектурной основой Всемирной паутины, принятой сначала CERN, а затем и консорциумом W3C, стало сочетание модели «клиент-сервер» и библиотеки (libWWW), скрывающей все зависимости по аппаратному обеспечению, операционным системам и протоколам. На рис. 13.3 приводится схема взаимодействия производителей и потребителей контента посредством соответствующих серверов и клиентов. Производитель размещает на машине, исполняющей роль сервера, описание информации на языке HTML. Обмен информацией с клиентом осуществляется сервером по протоколу передачи гипертекста (hypertext transfer protocol, HTTP). Программное обеспечение сервера и клиента основывается на libWWW, что позволяет маскировать детали протокола и зависимости от платформ. Одним из элементов, расположенных на стороне клиента, является браузер, который отвечает за понятное для потребителя информации отображение HTML.
Ниже мы намерены более подробно поговорить о библиотеке libWWW и архитектуре «клиент-сервер», которые, однажды составив основу первоначальной версии WWW, сохраняют это качество по сей день. В разделе 13.4 мы проанализируем изменения в архитектуре Всемирной паутины и в соответствующем программном обеспечении, происшедшие в ответ на революцию электронной коммерции. Реализация первоначальных требований: libWWW Как мы уже говорили, libWWW представляет собой библиотеку программного обеспечения для создания приложений, предназначенных для работы на сторо- нах клиента и сервера. Реализованная в ней функциональность — подключение к удаленным хостам, интерпретация потоков данных HTML и пр. — универсальна для большинства таких приложений. libWWW — это компактная, переносимая библиотека, которая встраивается в различные веб-приложения: клиенты, серверы, базы данных и веб-пауки. Она состоит из пяти уровней, изображенных на рис. 13.4.
Из общих утилит формируется уровень переносимости, служащий основой для всех остальных элементов системы. На этом уровне находятся базовые стандартные блоки — в том числе средства сетевого управления и управления строками, а также типы данных (в частности, классы-контейнеры). Службы этого уровня обеспечивают независимость всех вышележащих уровней от конкретной платформы; таким образом, задача по перенесению на новую аппаратную или программную платформу практически полностью сводится к однократному (для каждой платформы) перенесению данного обслуживающего уровня. На уровне ядра содержится «скелет» функциональности веб-приложения: средства доступа к сети, управления данными, синтаксического анализа, регистрации и т. д. Сам по себе этот уровень не выполняет никаких действий. Он лишь предоставляет стандартный интерфейс веб-приложения, при том что фактическая функциональность последнего обеспечивается сменными модулями и вызываемыми функциями, которые это приложение регистрирует. Сменные модули (plug-ins), регистрируемые в период прогона, реализуют на практике все функции уровня ядра — они ответственны за отправку и обработку данных. Как правило, они обеспечивают поддержку протоколов, осуществляют траиспортпые функции ни.ч- кого уровня и интерпретируют форматы данных. Сменные модули можно заменять в динамическом режиме, что упрощает задачу введения новой функциональности и даже позволяет вносить коррективы н характер неб-ириложеннй. Вызываемые функции (call-out functions) — это еще одно средство, нрн номо- щи которого приложения могут выходить за рамки функциональности, предоставляемой уровнем ядра. Они являют собой произвольные прикладные функции, которые вызываются перед пли после подами запросов модулям протоколов. Каков характер отношений между общими утилитами и ядром? Общие утилиты, предоставляющие независимые от конкретной платформы функции, подходят для любых сетевых приложений. Те абстракции, которые предоставляет уровень ядра, напротив, специально предназначены для конструирования вебприложений. Уровень потоков предусматривает абстракцию потока данных, передаваемых между приложением и сетью. На уровне доступа содержатся модули отдельных сетевых протоколов. Стандартный набор, который первоначально поддерживала библиотека libWWW, состоит из следующих протоколов: IITTP — базовый протокол WWW; NNTP (network news transport protocol, сетевой протокол передачи новостей) — протокол передачи сообщений в сети Usenet; WAIS (wide area information server, глобальный информационный сервер) — сетевая информационно-поисковая система; FTP (file transfer protocol, протокол передачи файлов), TELNET, rlogin, Gopher, локальная файловая система и TN3270. Многие из них в настоящее время утра- тили былое значение, однако есть и нововведения — к списку прибавился протокол HTTPS (HTTP secure, протокол защищенной передачи гипертекста). Введение новых модулей протоколов не представляет сложности, поскольку они строятся на абстракциях нижележащих уровней. Верхний уровень, содержащий модули веб-приложения, фактически предоставляет функциональный набор для их написания; универсальные модули кэширования, регистрации информации, прокси-серверов (в целях преобразования протоколов) и шлюзов (для взаимодействия с защитными брандмауэрами), модули ведения журнала истории и т. д. Выводы из опыта применения libWWW На сегодняшний день, исходя из опыта конструирования самой библиотеки libWWW и множества основанных на ней приложений, уже можно делать некоторые выводы. При их формулировании учтены попытки разработчиков удовлетворить перечисленные в разделе 13.2 требования заинтересованных лиц: гетерогенность инструментальных средств для WWW, поддержка удаленного доступа в масштабе многочисленных сетей, децентрализация и т. д. Самой трудной задачей оказалось удовлетворение неожиданно возникшего требования о графическом оформлении. Таким образом, способность веб-приложений к росту стимулировала принятие в рамках libWWW новых решений и обусловила принятие ряда умозаключений. ♦ Необходимы формализованные интерфейсы прикладного программирования (application programming interfaces, APIs). Имеются в виду интерфейсы* которые представляют функциональность библиотеки libWWW сконструированным на ее основе программам. Поскольку libWWW должна была содействовать разработке приложении на различных платформах и языках, зависимость спецификаций таких интерфейсов от конкретного языка не допускалась. ♦ Функциональность и представляющие ее интерфейсы прикладного программирования должны быть многоуровневыми. Разные приложения обращаются к разным ступеням абстракции обслуживания, организовать которые проще всего посредством уровней. ♦ Библиотека должна поддерживать динамический, расширяемый набор характеристик. Все эти характеристики должны быть заменяемыми, в гом числе в период прогона. ♦ Встраиваемые в програлшное обеспечение процессы должны быть многопоточными. Веб-приложения должны предусматривать возможность одновременного выполнения нескольких функций. Связано это, в частности, с тем. что операции загрузки крупных файлов по медленному каналу связи занимают довольно много времени. Отсюда необходимость в одновременном поддержании нескольких потоков управления. Следовательно, функциональность, раскрываемая интерфейсами прикладного программирования, должна быть защищенной в такой степени, которая требуется для ее применения в многопоточной среде. Как оказалось, поддержка библиотекой libWWW решения перечисленных задач реализована не так полно, как это можно было бы сделать. К примеру, ядро libWWW принимает ряд допущений о важнейших службах, что закрывает возможность динамической замены отдельных характеристик. Кроме того, поскольку библиотека libWWW не рассчитана на какую-либо конкретную платформу, опираться на однопоточную модель она не может. По этой причине в ней реализованы псевдопотоки, предоставляющие лишь часть необходимой функциональности. Наконец, большинство современных веб-приложений не поддерживают динамическое конфигурирование характеристик; для того чтобы зарегистрировать новые службы, их необходимо перезапустить. Ранний вариант архитектуры «клиент-сервер», реализованный при помощи libWWW На рис. 13.5 изображено представление размещения типичной клиент-серверной модели Всемирной паутины, построенной с участием libWWW. Там же показано представление декомпозиции на модули HTTP-клиента и серверных компонентов представления размещения. На этой схеме четко прослеживаются некоторые особенности libWWW. Во-первых, далеко не все элементы модели «клиент-сервер» строятся на ее основе. К примеру, от нее никак не зависит пользовательский интерфейс. Во-вторых, имена диспетчеров не обнаруживают точного соответствия с именами уровней. В то время как диспетчеры доступа, протоколов и потоков четко связаны с уровнями доступа и потоков, диспетчер кэширования обращается к службам прикладного уровня. Диспетчеры потоков в рамках пары «клиент- сервер» управляют низкоуровневой передачей данных и тем самым обеспечивают для остальных элементов системы прозрачность информационного обмена.
Дата добавления: 2015-04-25; Просмотров: 470; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |