Затраты 8 страница

Диспетчер пользовательского интерфейса ответствен за «облик и дух» пользо­вательского интерфейса клиента. С другой стороны, пользуясь расширяемостью набора ресурсов, доступных системе \YW\V, другой ллсмент — диснетчср пред­ставлений — можетделегировать полномочия по отображению информации внеш­ним программам (просмотра). Так происходит с ресурсами, которые известны системе, но которые диспетчер пользовательского интерфейса нс поддерживает напрямую. В частности, большинство веб-браузеров делегируют внешней про­грамме обязанности по отображению файлов PostScript и.pdf. Такое решение возникло как компромисс между стремлением к интеграции пользовательского интерфейса (способной стабилизировать его представление и, следовательно, повысить практичность), с одной стороны, и расширяемостыо — с другой.

Рис. 13.5. Представление размещения клиент-серверной модели Всемирной паутины, а также представление декомпозиции на модули клиента HTTP и серверных компонентов

Диспетчер пользовательского интерфейса забирает запрос на поиск информа­ции, поданный пользователем в виде URL, а затем передает эти данные диспет­черу доступа. Диспетчер доступа проводит проверку иа наличие запрошенного URL в кэше и интерпретирует историческую навигацию (например, «Назад»). Если файл присутствует в кэше, он извлекается из диспетчера кэширования и пе­редается диспетчеру представлений для отображения пользовательским интер­фейсом или внешней программой просмотра. В случае отсутствия файла в кэше диспетчер протоколов определяет тип запроса и запускает для его обслуживания соответствующий стек протоколов. С помощью последнего клиентский диспет­чер протоколов передает запрос на сервер. Получив от сервера ответ, выражен­ный в форме документа, диспетчер потоков передает его диспетчеру представле­ний, который, в свою очередь, обеспечивает его отображение. При попытке установления соответствия типа документа внешним программам просмотра дис­петчер представлений обращается за помощью к конфигурационному файлу уп­равления статическим представлением (mimerc, mailcap и т. д.).

В обязанности HTTP-сервера входит обеспечение прозрачного доступа к фай­ловой системе — благо именно она является источником документов, которые передаются в WWW. HTTP-сервер управляет доступом либо напрямую (для из­вестных типов ресурсов), либо через посредника, называемого общим шлюзовым интерфейсом (common gateway interface, CGI). CGI обрабатывает те типы ресур­сов, с которыми не может справиться сервер, а также рассматриваемые ниже рас­ширения функциональности сервера. До появления этих расширений в WWW- серверах реализовывалось подмножество определенных HTTP-запросов, которые предусматривали поиск документов и связанной с ними метаинформации, а так­же исполнение программ, размещенных на стороне сервера, средствами CGI.

Получив запрос, диспетчер потоков на стороне сервера определяет его тип и при помощи распознавателя путей устанавливает путь к указанному URL. Для проверки полномочий доступа, которыми обладает запрашивающий клиент, IITTP- сервер обращается к таблице доступа. Если речь идет об обращении к защищен­ным данным, сервер может запустить сеанс парольной аутентификации клиента. Затем, приняв допущение об аутентификации, сервер обращается к файловой системе (расположенной за его границами) и записывает запрошенную инфор­мацию в выходной поток. Для исполнения программы средствами CGI ей предо­ставляется процесс (новый или освобожденный в результате опроса), после чего выходные данные исполняемой программы фиксируются диспетчером потоков сервера, и он, в свою очередь, передает их клиенту.

Как бы то ни было, CGI — это одно из основных средств, обеспечивающих расширяемость сервера; иначе говоря, оно удовлетворяет важнейшему требова­нию, определяющему развитие веб-приложений. Важность CGI как аспекта веб­приложений позволяет нам остановиться на этой теме чуть подробнее.

Общий шлюзовой интерфейс (CGI)

Информация, которую сервер возвращает клиенту, по большей части является статической; изменениям она подвержена только в рамках собственной файло­вой системы. Сценарии CGI, напротив, подразумевают возможность возврата динамической, индивидуальной для каждого запроса информации. Исторически сложившаяся роль CGI заключается в расширении функциональности сервера по части ввода информации, поиска и щелчков на изображениях. Впрочем, чаще всего CGI используется для создания виртуальных документов (virtual docu­ments) — документов, которые синтезируются динамически в ответ на запросы пользователей. К примеру, если пользователь ищет в Интернете конкретную ин­формацию, поисковая система генерирует ответ па каждый поисковый запрос;

сценарий CGI создает из ответа новый HTML-документ и возвращает сто пользо­вателю.

Сценарии CGI сохранили гибкость, характерную для ранних, основанных на библиотеке libWWW вариантов архитектуры. На рис. 13.5 CGI изображен как внешний по отношению к HTTP-серверу элемент. Сценарии C.GI пишутся на разных языках — как компилируемых (С. C++, Fortran), так и интерпретиру­емых (Perl, Visual Basic. AppleScript и т. д.). Сценарии CGI позволяют разработ­чикам произвольным образом расширять функциональность сервера — в частно­сти, производить информацию, возвращаемую сервером пользователю.

С другой стороны, поскольку в сценариях CGI может содержаться любая функ­циональность С, Perl и других языков, в системе защиты машины, на которой они устанавливаются, образуется серьезная брешь. К примеру, с помощью сцена­рия (исполняемого как отдельный от сервера процесс) на хосте от имени удален­ного пользователя можно запустить любую команду. Эта угроза, которую демон­стрируют исполняемые на стороне сервера сценарии (в том числе CGI), заставила выставить к Всемирной паутине новое требование, касающееся повышения безо­пасности. Механизм реализации этого требования с помощью HTTPS описыва­ется в следующем разделе.

Вероятно, наиболее важным результатом введения в архитектуру веб-техно- лопш CGI явилась возможность «размещать» (put) в сети информацию — в до­полнение к стандартной для сервера операции ее «получения» (get). Впрочем, это требование, выдвинутое еще к первоначальному проекту WWW, так и не удалось реализовать в полной мере. CGI позволяет пользователям размещать информацию только посредством специализированных механизмов — например, вносить записи в базу данных путем заполнения формы.

С помощью технологии CGI — в основном за счет обеспечения возможностей обработки сервером произвольных ресурсов и (ограниченного) размещения пользо­вателями данных — удалось решить множество проблем, присущих первоначаль­ному проекту libWWW. С другой стороны, у CGI есть несколько существенных недостатков. Один из них связан с безопасностью, другой — с переносимостью. Сценарии CGI, написанные на Visual Basic, AppleScript и С Shell, работают в сре­дах Windows, Macintosh и UNIX соответственно. Переносить эти сценарии с од­ной платформы на другую довольно сложно.

Таблица 13.2. Реализация задач по качеству, заданных для первоначальной версии WWW

Задача	Как реализована	Какие тактики применялись
Удаленный доступ Способность к взаимодействию Расширяемость программного обеспечения Масштабируемость	Организация WWW на основе сети Интернет Маскировка деталей конкретной платформы при помощи библиотеки libWWW Локализация расширений протоколов и типов данных в библиотеке libWWW; возможность введения подключаемых компонентов (апплетов и сервлетов) Применение архитектуры «клиент- сервер», поддержание ссылок на данные, являющиеся локальными относительно местоположения ссылающихся данных	Применение предписанных протоколов Общие абстрактные службы Информационная закрытость Общие абстрактные службы Информационная закрытость Замена компонентов Конфигурационные файлы Введение параллелизма Снижение вычислительных издержек

Реализация первоначальных задач по качеству

Реализация первоначально сформулированных для Всемирной паутины задач по качеству — удаленному доступу, способности к взаимодействию, расширяемости и масштабируемости — расписана в табл. 13.2.

13.4. Еще одна итерация архитектурно­экономического цикла: эволюция вариантов веб-архитектуры систем электронной коммерции

Невероятный успех Всемирной паутины возбудил к ней серьезный интерес со стороны бизнес-сообщества, которое впоследствии через посредство архитектур­но-экономического цикла оказало на ее архитектуру беспрецедентное воздействие. Коммерческие требования в архитектуре Всемирной паутины вскоре стали пре­валирующими. Большинство инновационных разработок в области веб-прило­жений было выполнено с подачи веб-сайтов В2В и В2С.

Согласно первоначальной концепции, Всемирная паутина должна была стать коллекцией документов, основанной на гипертексте. С точки зрения электрон­ной коммерции WWW является коллекцией данных. Эти две концепции отчасти находятся в противоречии друг с другом. К примеру, сложности вызывает задача «проталкивания» информации пользователю. Общеупотребительная методика обновления данных предусматривает их регулярную перезагрузку; однако сами по себе изменения, происходящие с данными, не приводят к обновлению экрана. Другая проблема связана с кнопками «Назад» в различных браузерах — в опре­деленных обстоятельствах их употребление приводит к выводу на экран устарев­ших данных.

Требования, которые в настоящее время выдвигают игроки электронной ком­мерции, отличаются от приведенных в разделе 13.2 первоначальных требований как по существу, так и по жесткости.

♦ Высокая производительность. Популярные веб-сайты ежедневно фиксиру­ют десятки миллионов обращений, и пользователи рассчитывают на мак­симально возможное сокращение задержек. Покупатели не намерены тер­петь отказы в ответ на свои запросы.

♦ Высокая готовность. Сайты электронной коммерции должны быть рабо­тоспособны 24 часа в сутки, 7 дней в неделю. Поскольку они никогда не закрываются, периоды простоя необходимо строго ограничивать — жела­тельно, чтобы они не превышали нескольких минут в год.

♦ Масштабируемость. Вместе с ростом популярности веб-сайтов должна расти и их обрабатывающая способность — без этого невозможна обработка бо­лее серьезных объемов данных и поддержание приемлемого уровня обслу­живания клиентов.

♦ Безопасность. Пользователи должны быть уверены в том, что секретную информацию, которую они отправляют через Сеть, никто ие перехватит. Операторы веб-сайтов» в свою очередь, должны быть гарантированы от атак на свои системы (конкретнее — от похищения и модификации данных, отправки огромного количества запросов, приводящей к неготовности дан­ных, порче данных и т. д.).

♦ Модифицируемость. Веб-сайты электронной коммерции постоянно (иног­да — ежедневно) претерпевают обновления, в связи с чем возникает по­требность в удобстве изменения размещаемой на них информации.

Архитектурное решение перечисленных требований лежит в плоскости си­стемной, а не просто программной, архитектуры. Дело в том, что подобного рода системы по большей части состоят из коммерческих компонентов. В эту катего­рию, естественно, входят веб-серверы и веб-клиенты; кроме того, это базы дан­ных, серверы безопасности, серверы приложений, прокси-серверы, серверы транз­акций и т. д.

Эталонная архитектура современной системы электронной коммерции изо­бражена на рис. 13.6. Функция взаимодействия программы просмотра с пользо­вателем, как правило, осуществляется веб-браузером (кроме того, это может быть киоск, устаревшая система или какое-либо другое устройство с подключением к Сети). Функция бизнес-правил и бизнес-приложений обычно реализуется серве­рами приложений и транзакций. Уровень служб обработки данных в большинстве случаев воплощается в современной базе данных, хотя не исключаются и другие варианты — соединения с устаревшими системами и подключение к устаревшим базам данных. Изображенную схему часто называют n-звенной архитектурой (при­чем в данном случае п = 3). Звено (tier) представляет собой элемент функцио­нальности, на который можно отвести отдельную физическую машину.

Рис. 13.6. Эталонная архитектура системы электронной коммерции

Типичная реализация архитектуры системы электронной коммерции включа­ет некоторое количество звеньев (каждое из которых представляет собой связ­ную группу программного обеспечения, как правило, состоящую из специализи­рованных коммерческих компонентов), а также аппаратное обеспечение. Подобная конфигурация изображена на рис. 13.7, который, кроме того, иллюстрирует рас­пределение программ между аппаратными блоками.

Рис. 13.7. Типичная система электронной коммерции

Надписи на рис. 13.7, повторяющие приведенные на рис. 13.6 функциональ­ные элементы, в очередной раз свидетельствуют о том, что любая отдельная функ­ция эталонной архитектуры может соответствовать нескольким звеньям архи­тектуры системы электронной коммерции. Веб-браузеры (клиенты) и веб-серверы с рис. 13.5 предстают здесь в виде элементарных компонентов. Таким образом, налицо тенденция перехода к компонентным системам, в которых снижается зна­чимость внутренней компонентной структуры.

Изображенные на рис. 13.7 элементы мы намерены обсудить ниже в контек­сте атрибутов качества, реализации которых они способствуют.

Браузеры ради модифицируемости

Запросы на получение информации конечные пользователи, как правило, иници­ируют при помощи веб-браузера. Поддержка модифицируемости пользователь­ского интерфейса в современных веб-браузерах осуществляется весьма многооб­разно, причем наиболее очевидный способ не претерпел никаких изменений с момента появления Всемирной паутины, — пользовательский интерфейс, который отобра­жает браузер, не «вшивается», а специфицируется средствами HTML. По край­ней мере, так было раньше. Сегодня технологий создания сложных пользова­тельских интерфейсов стало гораздо больше. XML, Flash, ActiveX, Java- апнлеты — это лишь некоторые средства, расширяющие стандартную палитру неб-инструментов (состоящую из графики и горячих точек) и способствующие

отображению средствами браузеров полностью программируемых интерактив­ных интерфейсов.

HTTPS ради безопасности

Поданный пользователем запрос необходимо передать па целевой веб-сайт. Пере­дача обычно осуществляется средствами HTTP, однако если речь идет о секрет­ной информации, вроде номеров кредитных карт и идентификационных номеров, применяется протокол HTTPS (HTTP Secure). В HTTPS в качестве нодпротоко- ла HTTP применяется протокол защищенных сокетов (Secure Sockets Layer, SSL) от компании Netscape. Для отправки зашифрованных запросов на службы ТСР/ IP он использует порт 443 (стандартный порт HTTP — 80). Шифрование данных в рамках SSL производится с помощью 128-бптной пары открытого/секретного ключей — этот уровень шифрования при обмене небольшими пакетами коммер­ческой информации в рамках коротких транзакций считается достаточным.

Прокси-серверы ради производительности

Иногда запросы от браузеров проходят через прокси-сервер — элемент, ориенти­рованный на повышение производительности веб-системы. Эти серверы кэширу­ют веб-страницы, к которым пользователи обращаются чаще всего, в результате чего необходимость в обращении к веб-сайту для их получения отпадает. (Кэши реализуют «многоэкземплярную» тактику.) За счет того, что они, как правило, максимально приближены к пользователям и зачастую даже находятся с ними в одной сети, вычислительные и коммуникационные издержки резко снижаются.

В некоторых компаниях прокси-серверы ограничивают доступ сотрудников к тем или иным веб-сайтам. В таком случае прокси-сервер функционально сближается с брандмауэром.

Маршрутизаторы и брандмауэры ради безопасности

Запросы, отправляемые браузером (ив некоторых случаях обрабатываемые про­кси-сервером), прибывают на маршрутизатор, расположенный в сети предприя­тия электронной коммерции. Иногда эта сеть защищается брандмауэром, а в не­которых случаях маршрутизатор перенаправляет HTTP-запросы на автономный брандмауэр. Маршрутизаторы часто проводят трансляцию сетевых адресов (net­work address translation, NAT) — иначе говоря, преобразуют IP-адреса из внешне видимых во внутренние. IP-адреса для любого возвращаемого с веб-сервера трафи­ка, напротив, транслируются из внутренних во внешне видимые. NAT — это один из инструментов методики выравнивания нагрузки, к рассмотрению которой мы вернемся чуть позже.

Брандмауэр предотвращает несанкционированные информационные потоки и попытки доступа извне, осуществляя, таким образом, тактику «ограничения доступа». Брандмауэры подразделяются на несколько типов, из которых наи-

большим распространением пользуются фильтры пакетов (packet filters) и при­кладные посредники (application proxies). Фильтры пакетов исследуют заголовки всех входящих пакетов TCP и IP, и в случае обнаружения злонамеренного пове­дения (например, попытки подключения через несанкционированный порт или отправки файлов неразрешенных типов) пакет отклоняется. В контексте переда­чи данных в WWW фильтры пакетов хороши тем, что исследуют каждый пакет в отдельности и не делают попыток фиксировать историю предыдущих сеансов связи.

Брандмауэры типа «прикладной посредник», как и предполагает их название, ориентированы на конкретное применение. Как правило, они интерпретируют прикладные протоколы и поэтому при фильтрации трафика опираются на извест­ные модели поведения. К примеру, прикладной посредник может отказать в при­еме HTTP-отклика, если перед этим на соответствующий узел не был отправлен HTTP-запрос. Брандмауэры такого типа работают значительно медленнее филь­тров пакетов; связано это с тем, что, во-первых, они сохраняют историческую информацию значительного объема, а во-вторых, механизм обработки в них зна­чительно сложнее.

Выравнивание нагрузки ради производительности, масштабируемости и готовности

Компоненты, обеспечивающие выравнивание нагрузки, а следовательно, произ­водительность, масштабируемость и готовность, в обязательном порядке присут­ствуют на всех уважающих себя веб-сайтах электронной коммерции. Функция блока выравнивания нагрузки заключается в распределении «нагрузки» — вхо­дящих запросов HTTP и HTTPS — между участниками пула компьютеров с про­граммным обеспечением веб-сервера. (Как мы говорили в главе 5, выравнивание нагрузки соответствует тактике «внедрения физического параллелизма»). Блок выравнивания нагрузки может перенаправить запрос на другой компьютер само­стоятельно (и прозрачно) или отослать веб-клиенту ответ с соответствующей инструкцией. Несмотря на то что перенаправление проходит незаметно для ко­нечного пользователя, фактически оно приводит к дополнительному круговому обращению.

При выборе компьютера для перенаправления трафика блок выравнивания нагрузки основывается на алгоритме кругового обслуживания или на знании вычислительных и нагрузочных характеристик подключенных компьютеров. Поскольку исполняемая блоком выравнивания нагрузки роль посредника рас­пространяется на пул компьютеров, введение в этот пул дополнительных машин не требует модификации внешних интерфейсов. Таким образом, блок выравни­вания нагрузки обеспечивает масштабируемость производительности — точнее говоря, гот тип этой характеристики, который называют горизонтальным масш­табированием (он подразумевает введение дополнительных экземпляров данно­го ресурса).

Кроме того, блок выравнивания нагрузки способен отслеживать живучесть подключенных к нему компьютеров. Если один из них выходит из строя, его трафик передается другим участникам пула. Таким способом гарантируется го­товность.

Веб-серверы ради производительности

Наконец, запрос HTTP или HTTPS прибывает иа веб-сервер. Старые веб-серве­ры (один из таких изображается на рис. 13.5) в основном были однопоточными. Современные версии веб-серверов отличаются многопоточностью и применени­ем пулов потоков, распределяемых для обработки входящих запросов. Распола­гая пулом с потоками, готовыми для обслуживания новых входящих запросов, многопоточный сервер снижает вероятность образования узких мест (а следова­тельно, и задержек) при обработке многочисленных «долгоиграющих» запросов HTTP или HTTPS (к таковым относятся операции проверки достоверности дан­ных кредитных карт). Таким образом реализуется тактика «введение параллелизма».

Вертикальное масштабирование (введение более мощных экземпляров ресур­са) достигается за счет замены существующих серверов более производительны­ми машинами, способными параллельно запускать большее количество потоков.

Завершив анализ запроса, веб-сервер отправляет его серверу приложений. Тот обычно отвечает с помощью служб базы данных.

В главе 16 мы разберем систему корпоративных JavaBeans (Enterprise Java- Beans) — современную методику реализации веб-серверов.

Серверы приложений ради модифицируемости, производительности и масштабируемости

От веб-сервера запрос переходит к серверу приложений. «Сервер приложений» — это широкий (и, согласно распространенному мнению, не совсем ясный) термин, который обозначает класс приложений, действующих «посередине» я-звенной архитектуры. Речь идет о бизнес-правилах и бизнес-приложениях. Такие серверы реализуют бизнес-логику и возможность соединения, которые регламентируют взаимодействие серверов с клиентами. Тенденция к введению серверов приложе­ний позволила разгрузить традиционные «жирные» клиенты и передать часть их функциональности среднему звену. Кроме того, они фокусируют базы данных на хранение, поиск и анализ данных, снимая с них обязанность по контролю над дальнейшим использованием этих данных.

Простые серверы приложений, как правило, состоят из интегрированной сре­ды разработки (integrated development environment, IDE) и сервера исполнения. Среды IDE поддерживают программные модели наподобие СОМ (а в последнее время —.NET), CORBA или J2EE (последняя рассматривается в главе 16). По­мимо этого, многие серверы приложений предусматривают наборы общеупотре­бительных служб для оперативного создания бизнес-приложений и приложений электронной коммерции — в частности, предназначенных для выписывания сче­тов, управления запасами, документооборотом и взаимодействием с заказчика-

мн. Ila более высоком уровне (в категориях стоимости, сложности и функцио­нальности) стоят приложения обработки и отслеживания транзакций. Блоки от­слеживания и процессоры транзакций взаимодействуют с базами данных и коор­динируют такие задачи, как распределенные транзакции (в том числе объединение данных из нескольких источников), организация очередей, поддержание целост­ности транзакции и выравнивание рабочей нагрузки (в этом они схожи с упомя­нутыми выше блоками выравнивания нагрузки).

Базы данных ради производительности, масштабируемости и готовности

В конце концов запрос на обслуживание достигает базы данных, где преобразу­ется в команду добавления, модификации или поиска информации. Варианты архитектуры современных баз данных во многом повторяют атрибуты качества представленной на рис. 13.7 системы электронной коммерции. Во многих случа­ях для реализации производительности, масштабируемости и высокой готовнос­ти в них вводится внутренняя репликация. Кэширование также способствует повышению производительности.

13.5. Реализация задач по качеству

Взятые вместе, вышеописанные элементы позволяют реализовывать в веб-систе- мах электронной коммерции самые жесткие задачи по безопасности, высокой готовности, модифицируемости, масштабируемости и высокой производительно­сти. Как это происходит, показано в табл. 13.3.

Таблица 13.3.Реализация задач по качеству в веб-архитектуре систем электронной коммерции

Задача	Как реализуется	Тактики
Высокая	Выравнивание нагрузки,	Введение параллелизма;
производительность	трансляция сетевых адресов, многоэкземплярная тактика	расширение ресурсов; прокси-серверы
Высокая готовность	Резервные процессоры, сети, базы данных и программы; выравнивание нагрузки	Активное резервирование; транзакции; введение параллелизма
Масштабируемость	Обеспечение горизонтального и вертикального масштабиро­вания; выравнивание нагрузки	Общие абстрактные службы; применение предписанных протоколов; введение параллелизма
Безопасность	Брандмауэры; шифрование открытым/секретным ключами в общедоступных сетях	Ограничение доступа; целостность; ограничение внешних воздействий
Модифицируемость	Разделение функциональности браузера, проектного решения базы данных и бизнес-логики на отдельные звенья	Общие абстрактные службы; семантическая связность; посредник; стабильность интерфейса

13.6. Архитектурно-экономический цикл сегодня

Если проанализировать текущее состояние Всемирной паутины по прошествии нескольких итераций архитектурно-экономического цикла, п глаза бросится це­лый ряд явлений.

♦ Организации, формирующие техническую базу, подразделяются на несколь­ко типов. Согласно наиболее общей классификации, их можно разделить на поставщиков услуг и контент-провайдеров. Поставщики услуг произво­дят программные продукты, обеспечивающие функционирование Всемир­ной паутины: браузеры, серверы, базы данных, серверы приложений, тех­нологии защиты (в частности, брандмауэры), серверы транзакций, сети и маршрутизаторы. Контент-провайдеры создают информацию, которая раз­мещается в Сети. В обеих областях наблюдается жестокая конкуренция.

♦ Помимо W3C, значительное влияние на эволюцию Всемирной паутины оказывает ряд проектов с открытым кодом — в частности, проект Apache.

♦ CERN никоим образом не участвует в развитии WWW.

♦ Языки с поддержкой веб-технологий (в особенности это касается Java) вносят свои коррективы в способы разработки и доставки функционально­сти в этой среде. (Пример конструирования веб-приложений с помощью Enterprise JavaBeans описывается в главе 18.)

♦ Превращение Всемирной паутины в распределенную среду разработки при­вело к появлению ряда новых организаций и продуктов. К примеру, UDDI (Universal Description, Discovery and Integration, универсальная система предметного описания и интеграции) организует распределенные регист­ры веб-служб. Эти службы используются в качества стандартных блоков распределенных веб-приложений.

На рис. 13.8 изображен архитектурно-экономический цикл Всемирной паути­ны в ее современном виде.

В роли заказчиков выступают производители программных серверов и брау­зеров, а также поставщики услуг и контент-провайдеры. Конечные пользовате­ли — это население планеты. Роль архитектора разделена между W3C и другими консорциумами (в частности, UDDI и Apache), с одной стороны, и несколькими влиятельными компаниями (Sun, Microsoft и AOL/Netscape) — с другой. По всем остальным показателям ABC практически не претерпел изменений — за исклю­чением, пожалуй, того, что техническая база теперь включает саму Всемирную паутину, а следовательно, перечень атрибутов качества дополняется требованием о прямой совместимости.

Возвратный цикл ABC мы разобрали в разделе 1.1. Существование системы со­здает для компании-разработчика и ее заказчиков новые коммерческие возмож­ности. В случае со Всемирной паутиной разработавшая ее компания — CERN — решила дистанцироваться от этого продукта и сосредоточиться на исследованиях в области ядерной физики; из-за этого коммерческими возможностями, создан­ными возвратным циклом ABC, воспользовались другие организации.

Рис. 13.8. Современный архитектурно-экономический цикл Всемирной паутины

13.7. Заключение

Своим успехом Всемирная паутина обязана способу реализации в ее архитектур­ных структурах желаемых атрибутов качества, а также преобразованиям этих структур в ответ на появление новых требований. Ее лавинообразное развитие свидетельствует о том, что всего за несколько лет архитектурно-экономический цикл был пройден неоднократно, создавая с каждой итерацией новые коммерче­ские возможности, требования и технические задачи.

О ТОМ, КАК ВСЕМИРНАЯ ПАУТИНА ИЗМЕНИЛА ДЕЛОВОЙ МИР:-------------------------------------------------------------------------------------------

AMAZON.COM

К моменту открытия в 1995 году своего виртуального представительства Amazon.com, про­дававший более 1 миллиона изданий, по своему масштабу был уже на порядок крупнее сред­нестатистических книжных магазинов. От традиционных магазинов он отличался и по многим другим показателям. Причиной столь разительных отличий оказалась электронная ориента­ция Amazon — реализация задач и предложение продуктов через Сеть.

Будучи электронным магазином, Amazon изменил мир (по крайней мере, деловой). В ча­стности, не затрачивая средства на издательскую деятельность, он смог себе позволить тор­говать книгами от независимых авторов и мелких издательств. Он изменил сам механизм покупки книг, чему поспособствовали издававшиеся в Сети отзывы читателей, обзоры, служ­ба личных рекомендаций, доставляемые по электронной почте извещения о выходе новых книг любимых получателями авторов и т. д. Наконец, поскольку Amazon делегировал боль­шинство операций сторонним организациям, а следовательно, избавился от значительной доли издержек, характерных для традиционной розничной книготорговли, магазин смог удер­жать цены на низком уровне.

Дата добавления: 2015-04-25