Базы данныхИнтернетКомпьютерыОперационные системыПрограммированиеСетиСвязьРазное
Поиск по сайту:
Подпишись на рассылку:

Назад в раздел

Веб кулинария

div.main {margin-left: 20pt; margin-right: 20pt} Веб кулинария

На вооружении программиста, занятого в разработке интернет- и интранет-приложений, находится большое кол-во технологий с труднопроизносимыми названиями : HTML, HTTP, ASP, PHP, SSL и пр. С каждым днем их становится все больше. Попробуем разобраться в том, что есть что, а также ответить на вопрос : насколько удобны эти технологии и как их использовать с наибольшей эффективностью?

Часть 1. Историческая.

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

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

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

Правильное решение заключается в "умной" специализации компьютеров, создании "сетевой среды". Задачи хранения, архивации, обработки, передачи и отображения данных, управления доступом, адресации разделяются между компьютерами, которые взаимодействуют между собой с использованием специальных протоколов. Для создания подобной сети необходимо эффективно решить ряд вопросов. Приведем наиболее важные из них : какие задачи возложить на компьютер пользователя? Какова схема адресации, то есть как компьютеры находят друг друга? Какие протоколы обмена информацией будут использоваться? Как решается вопросы безопасности, то есть ограничения доступа? В каком виде должны формироваться запросы и ответы в такой среде, какие языки следует использовать? Сеть интернет представляет собой аналог подобной сетевой среды.

Транспортной основой сети интернет, в настоящее время, является TCP (Transmission Control Protocol) версии 4. Данный протокол скрывает от клиентов все особенности передачи данных по сетевым соединения, предоставляя им возможность "надежно" обмениваться информацией. Разработчики TCP не предполагали, что он будет использоваться в глобальной компьютерной сети, но в процессе своей эксплуатации этот протокол был "доведен до ума" и зарекомендовал себя с хорошей стороны. Основной пробел TCP - отсутствие встроенных средств обеспечения безопасности. Всем интернет-приложениям приходится реализовывать авторизационные процедуры самостоятельно. Существует и другая серьезная проблема - исчерпание пространства адресов в TCP, которое по некоторым прогнозам произойдет в период 2005 - 2010 г. Новая версия TCP (т.н. версия 6) призвана решить эти и другие вопросы (неэффективное использование пропускных способностей, отсутствие вложенных заголовков и пр.), однако, ее внедрение сталкивается с вполне понятными трудностями - огромное количество "железа" понимает "старый" TCP.

Компьютеры находят друг друга в интернет, используя DNS (Dynamic Name Service). Данный сервис позволяет скрыть реальный, т.н. IP-адрес, компьютера, за относительно удобной нотацией доменных имен иерархического вида. К сожалению, DNS ненадежен с точки зрения безопасности. Недавно проведенные исследования показали, что в отдельных регионах 70% DNS-серверов подвержены атакам, которые направлены на подмену реального адреса фиктивным. Последствия таких атак чрезвычайно опасны - происходит перехват информации. Существует и другая не менее сложная проблема - получение желаемого доменного имени. Эта тема заслуживает отдельного разговора и напрямую связана с вопросом "Кому принадлежит интернет?". В настоящее время "хорошее" доменное имя (то есть удобное для запоминания и вызывающее определенную ассоциацию) можно считать своеобразной формой собственности.

Итак, два компьютера нашли друг друга с помощью DNS и получили возможность обмениваться информацией между собой через соединение TCP. Что они будут друг другу передавать? Одним из важнейших достижений интернета принято считать использование HTML (Hyper Text Markup Language) - языка представления "умного" текста, структурированного специальным образом. HTML позволяет представлять текстовую информацию в удобном для пользователя виде (таблицы, списки, параграфы, выделение фрагментов текста, управление размером шрифта и пр.) и насыщать ее иллюстрациями. HTML хранит не только сам текст, но и способ отображения частей этого текста на экране, а также ссылки на другие интернет-ресурсы, которые активизируются щелчком мыши. HTML решил вопрос пользовательского интерфейса следующим образом: на компьютер пользователя возложили ответственность "лишь" за правильное отображение HTML-страниц специальной программой (браузером). Что же должен "уметь" сервер?


Часть 2. Про сервер

Программа, которая выдает HTML-страницы в ответ на запрос на языке HTTP (Hyper Text Transfer Protocol), называется www- (или веб-) сервером. В основе интранет-технологий лежит простая идея - HTML-страницы не обязаны быть статичными и хранится в готовом виде. Ничто не мешает формировать их динамически в ответ на запрос пользователя! Если для этого используется отдельное приложение, которое запускается www-сервером, это CGI (Common Gateway Interface). Создать CGI-приложение несложно. В то время как www-сервер занимается управлением правами доступа, обработкой поступающих запросов, передачей данных клиенту и пр., от программы CGI требуется всего лишь вывести HTML-страницу в стандартный поток вывода. При этом она может быть написана на C++, присоединяться к базам данных или другим ресурсам и выполняться очень быстро. Данные запроса передаются в CGI-приложения через переменные окружения или через стандартный ввод. В настоящее время генерация HTML с помощью CGI, будь то скомпилированная программа или интерпретируемый перл-скрипт, распространено чрезвычайно широко. Однако использование CGI имеет и недостатки.

Давайте представим себе сильно загруженный www-сервер. В течение одной секунды он должен обслужить 100 запросов пользователей. Это означает одновременный запуск 100 CGI-приложений! С точки зрения операционной системы (далее ОС) создание нового процесса всегда штука трудоемкая, как, впрочем, и поддержание его в работоспособном состоянии (шутка). Для запуска программы ОС создает специальные структуры внутри ядра, выделяет память под сегменты задачи, загружает данные приложения с диска и связывает его с динамическими библиотеками. После завершения работы приложения необходимо освобождать все занятые им ресурсы. Не надо забывать и про время инициализации приложения. В случае, когда идет работа с базой данных, время инициализации - это время установления соединения с сервером БД, и это соединение не всегда выполняется быстро (требуется установить канал связи, проверить права доступа и пр.) В ситуации, когда сервер БД загружен, это время будет еще больше. Технология CGI проста и удобна, но ее следует использовать в том случае, когда время отклика не критично (генерация отчетов и пр.) и когда запросы для CGI-приложений поступают не очень часто (раз в 10-60 секунд). Что же делать, если необходим динамический HTML, но ресурсы на CGI тратить не хочется?

Выход был найден и здесь - чтобы обойтись без запуска отдельного приложения, его нужно встроить в www-сервер. Поскольку заранее неизвестно, что именно будет делать это приложение (шутка), следует встроить в www-сервер интерпретатор удобного для перемалывания данных языка. Такое решение позволит каждый запрос обрабатывать отдельным потоком сервера (нитью, фредом, обычно называется thread), а не отдельным процессом ОС. Это увеличивает время отклика и снижает нагрузку на процессор. Программы, которые обрабатывает этот интерпретатор, часто называют "скриптами". В решении внедрить интерпретатор в www-сервер таятся как плюсы, так и минусы - интерпретация скриптов позволяет вносить в них изменения и немедленно видеть результат, но выполняются они медленнее скомпилированной программы. К тому же ошибка в CGI-приложении никак не повлияет на устойчивость www-сервера, а вот ошибка во встроенном интерпретаторе, скорее всего, будет для сервера фатальна! Как показала практика, плюсы все же перевесили. Основной задачей, возлагаемой на скрипты, стало взаимодействие с БД, а здесь основные задержки возникают, как правило, на сервере БД. К тому же отсутствие необходимости в компиляции необычайно удобно при отладке интернет-приложений. Это важно, так как в стадии отладки эти приложения пребывают вплоть до того момента, когда их заменяют другими (шутка).

Интерпретатор скриптов от фирмы MicroSoft называется ASP (Active Server Pages). Этот язык является "кастрированным" бейсиком, так горячо любимым отцом-основателем этой фирмы. Достоинство ASP, однако ж, в том, что оный позволяет в процессе работы расширять себя дополнительными модулями, которые могут быть написаны на любом языке, включая C++. ASP можно встраивать прямо в HTML. Это удобно, хотя в результате можно легко добиться жуткого вида HTML-страниц - код HTML, перемешанный с ASP и все это густо усеяно врезками JavaScript и описаниями стилей! Найти потом нужное место и подправить скрипт очень непросто! Почти все скриптовые языки "объектно-подобны". Это означает, что они не поддерживают, к примеру, наследование, но предоставляют в распоряжение программиста некие псевдо-объекты типа "запрос пользователя", за которыми скрываются элементы протокола HTTP.

Для дальнейшего обсуждения ASP нам нужно уяснить каким образом протекает общение пользователя с некоторым сайтом. Протокол HTTP реализует схему авторизации пользователей через пароли. Ресурсы, открытые для всех, доступны для "анонимных" запросов. При обращении к закрытому ресурсу веб-сервер проверяет - есть ли в запросе логин и пароль пользователя? Если есть - разрешен ли ему доступ к этому ресурсу? В том случае, когда доступ к ресурсу запрещен, сервер возвращает браузеру страницу с сообщением об ошибке и специальный код ответа. Браузер обычно реагирует на это просьбой к пользователю указать его логин и пароль. После ввода данных браузер опять запрашивает ресурс, а в случае отказа от ввода - показывает страницу с сообщением об ошибке, которую вернул ему сервер. Если же логин и пароль указаны верно, пользователь получает доступ к "настоящему" содержанию ресурса. Работающий экземпляр браузера реагирует на это следующим образом : он сохраняет во внутренних переменных логин и пароль, введенные пользователем, и, в дальнейшем, передает их на сервер при любом запросе. Данные переменные не сохраняются на диске и будут уничтожены при завершении работы этого экземпляра. Кстати, Microsoft Internet Explorer 4.0 может "спутать" авторизационную информацию между разными браузерами, запущенными одновременно.

Данный механизм авторизации не может быть использован для идентификации пользователей, обращающихся к открытым ресурсам. Необходимость же подобной идентификации диктуется несомненной обоюдной выгодой пользователя и поставщика интернет-ресурса. К примеру, поисковая машина может хранить несколько последних запросов пользователя и предлагать их выбрать при последующих обращениях. Или, скажем, интернет-магазин может отслеживать перемещения пользователя по сайту и предлагать ему товары и услуги, близкие к тем, которые ему наиболее интересны. Несмотря на то, что скрипт, как правило, может узнать IP-адрес, с которого пришел запрос (он хранится в специальной серверной переменной доступной в любом приличном веб-сервере), этот адрес не поможет в идентификации пользователя. В том случае, если несколько пользователей работают через один и тот же прокси-сервер (сервер-посредник между браузером и веб-сервером, используется в целях безопасности, для оптимизации запросов и кеширования) IP-адреса их запросов совпадают (и являются IP-адресом прокси-сервера). Существуют и другие случаи, которые делают неудобной или невозможной ассоциацию "IP-адрес = пользователь". При этом протокол HTTP не поддерживает понятие "сессия анонимного пользователя" в "чистом виде", в нем нет явно выраженных событий начала и конца работы с сайтом для определенного пользователя.

Для идентификации пользователей и имитации подобной сессии были придуманы "вафельки" (в вольном переводе cookie, читается как "куки"). Это переменные, которые хранятся у клиента и которые браузер присылает в каждом своем запросе на сайт. Упрощая, можно сказать, что веб-сервер "пачкает" разной краской пользователей, которые на него заходят, и затем отличает их по цвету друг от друга. Данный механизм встречает некоторое противодействие со стороны борцов за защиту прав человека, так как он позволяет незаметно получить и сохранить информацию о предопочтениях клиента. Последнее время произошло несколько скандалов в этой области в Америке, граждане которой борются за свои права и свободы большую часть своего времени (шутка). Все эти скандалы, как правило, связаны с нежеланием пользователей терять свою виртуальную анонимность. Несмотря на дружные заверения большинства интернет-магазинов о том, что они не будут собирать информацию о вкусах и предпочтениях пользователей, все они это делали и делают. "Вафельки" по умолчанию разрешают все браузеры и они сильно упрощают программирование интернет-приложений. Во-первых, такие переменные позволяют понять - был ли пользователь на сайте до этого (если не был - "вафелек" в запросе не будет). Во-вторых, можно хранить некоторую индивидуальную информацию для пользователя и выдавать HTML, ориентированный конкретно на него. В-третьих, "вафелька" может хранить некий уникальный номер, который позволит различать клиентов друг от друга в процессе работы с сайтом, и "эмулировать" интернет-сессию. Гарантией уникальности таких сессий является случайность ее идентификатора. Обычно в качестве подобного идентификатора используют строку случайных букв латинского алфавита длиной 20-30 символов. Вероятностью повтора такого номера в течение времени жизни интернет-приложения можно пренебречь. Стартом такой "анонимной" сесии будет первый запрос от пользователя веб-серверу. С окончанием сессии все не так просто. Вообще говоря, она заканчивается, когда закрывается браузер. Но как об этом узнает веб-сервер? Есть разные способы реализации окончания сессии. Во-первых, язык HTML (в своих последних версиях) поддерживает события, связанные с "линией жизни" документов. То есть при выгрузке документа можно отправить запрос специального вида на сервер. Существует и другой способ, который дополнительно загружает каналы и сервер, но является более надежным. У пользователя в браузере создается невидимый фрейм (часть страницы), который обновляется через определенный промежуток времени (например, минуту). Если сервер в течение длительного времени (например, 5 минут) не получает запросов от этого фрейма, он считает, что пользователь закончил работу с сайтом и закрывает сессию. Для этого требуется поддерживать список активных сессий и регулярно его обновлять (при поступлении запроса от невидимого фрейса сессия продлевается). В механизме сессий есть еще один тонкий момент.

В реальной жизни, как правило, пользователь такой системы будет равен ее клиенту. Что, однако, мешает этому самому пользователю открыть 2 или 3 окна браузера и в каждом из них "войти" на сайт? Как в таком случае поступит система - зависит от ее реализации. Правильно ли считать каждую последующую сессию концом предыдущей? Видимо наиболее безопасным и разумным можно считать запрет на одновременную работу пользователя в нескольких сессиях.

Вернемся к ASP. Он поддерживает механизм сессий в удобном для программиста виде, "выстреливая" события старта и окончания сессии. Окончание сессии происходит через определенное время, отсчитываемое от последнего обращения пользователя к серверу (по умолчанию этот период составляет 15 минут). ASP вводит псевдо-объект "сессия" и позволяет хранить внутри него данные, уникальные для пользователей. Вообще говоря, механизм сессий в ASP очень удобен, но, к сожалению, в серьезном интернет-проекте им пользоваться не следует. В противном случае вы неизбежно столкнетесь с непредсказуемыми задержками в работе веб-сервера. Будьте готовы к частым зависаниям "на пустом месте" и необъяснимыми паузами при обработке ASP-скриптов. К недостаткам ASP относится также ненадежность веб-сервера IIS (при серьезной нагрузке приготовьтесь перегружать его каждую ночь) и не вполне удобная нотация языка бейсик (каждый оператор в отдельной строке, Then после If и пр.). Нужно понимать, что ASP-скрипты не предназначены для проведения сложных расчетов или замысловатых преобразований данных. Рано или поздно подобный абсолютно корректный скрипт начнет "вышибать" ваш веб-сервер с завидной регулярностью. Microsoft, озабоченная "падучестью" своего сервера, даже разработала специальный продукт под названием IIS Exception Monitor. Это приложение должно было развеять злые умыслы тех, кто считал что веб-сервер "падает" из-за внутренних ошибок, и переложить груз неудачи на встраиваемые в IIS приложения. Единственно полезной функцией Exception Monitor является сигнализация о "падении" веб-сервера посылкой сообщения и его немедленный рестарт. Просмотр же многостраничных распечаток с дампами стека и памяти для понимания того, в какой именно функции ASP-интерпретатор дал сбой, интересен лишь отьявленному хакеру или виртуальному мазохисту. Впрочем эти понятия не так далеки друг от друга (шутка). ASP поддерживается www-сервером MicroSoft, начиная с версии 3.0, но для его установки и настройки придется немного потрудится - в стандартную поставку он не входит.

В стане UNIX изначально получил широкое распространение интерпретатор языка PERL (Practical Expression Regular Language). В названии таится главный смысл - "обработка регулярных выражений", то есть специальных выражений, которые перемалывают строки по шаблонам. Перл позволяет лаконично описывать и решать сложные задачи хранения и синтаксического разбора строк произвольной длины. Для интернет-задач, которые, в основном, оперируют текстом, это вполне удобный инструмент. Интерпретатор этого самого перла был встроен в основной www-сервер ОС Linux Apache. Однако, перл придуман был изначально не для интернета и отсюда вытекали все его недостатки, например, неудобства при организации доступа к базам данных. Да и далеко не прост PERL в обучении! Более разумной альтернативой является PHP (Personal Home Page). PHP был придуман в 1994 году для расширения возможностей "домашней" страницы. Вначале умел он не очень много – понимал простейший язык и всего несколько макросов. Позднее PHP получил развитие и в настоящее время это интерпретатор мощного C-подобного языка, который встраивается в www-сервер Apache. Огромная часть интернет-приложений под юниксовым семейством ОС создается на PHP. Существует он и под Windows, но особой популярностью здесь не пользуется. Для создания работоспособной версии веб-сервера со встроенным PHP придется немного потрудится. Вначале необходимо получить исходный текст www-сервера и PHP-интерпретатора. Затем установить библиотеки для работы с СУБД, которая Вам необходима. Наконец, скомпилировать, связать (слинковать, как-то некрасиво, хотя более точно) это друг с другом и заняться редактированием настроечных файлов.

К недостаткам PHP (версии 3) сам автор относит снижение производительности на больших проектах, отсутствие поддержки сессий, малое кол-во подключаемых модулей (хотя это вопрос времени). В настоящее время движок PHP переписывается и версия 4 должна решить все эти проблемы.

Выбор Apache/PHP на платформе UNIX и IIS/ASP/Windows можно считать разумным решением для создания серверной части интернет-приложения. Несмотря на то, что проведенные исследования показывают, что Apache не самый быстрый веб-сервер (хотя многие считают его таковым), это наиболее распространенный и относительно простой в установке пакет. Доступность его исходных текстов можно считать одним из плюсов. Всегда устанавливайте последнюю "стабильную" версию Apache. Если же Вы выбираете IIS, не стоит торопиться в будущее вслед за Microsoft. Установите IIS версии 3.0 и последний сервис-пак для Windows NT (на момент написания статьи - 6a). Обязательно перед началом работы уделите время оптимизации веб-сервера и скачайте все необходимые "заплаты" по безопасности. Для сложных, с точки зрения вычисления, задач (генерация больших отчетов) следует использовать CGI-приложения или создавать встраиваемые в веб-сервер компоненты (технология COM под Windows, расширение Apache дополнительными модулями).

Часть 4. Про клиента

Если серверные технологии развивались солидно и степенно, то на клиенте развернулась самая настоящая борьба за пользователя! В это трудно поверить, но глава MicroSoft Билл Гейтс не смог предугадать потенциал интернет и долгое время его попросту игнорировал. Осознав свою ошибку, MicroSoft сосредоточила большие усилия в области глобальной компьютерной сети. В результате, в настоящее время большинство пользователей "серфит" сеть с помощью браузера MicroSoft Explorer (наиболее распространенной версией является в настоящее время 4-я), а программисты клянут все на свете, так как разные браузеры _несовместимы_ между собой. Приходится мириться с тем, что есть HTML от MicroSoft и HTML от Netscape. При разработке интернет-приложения, использующего "незаурядный" HTML, следует сразу определить круг его потенциальных клиентов. К примеру, можно ориентировать свои разработки на определенную версию браузера. Данный подход неприемлем для, скажем, поисковой машины, но для некоторого специализованного интернет-приложения вполне годится. Трудности при работе с HTML связаны еще и с тем, что он постоянно развивается. Эволюция HTML приводит к "устареванию" некоторых его тегов (управляющих элементов). Одновременно новые версии браузеров получают больше возможностей, от которых трудно отказаться. В результате HTML-код становится все более ориентированным на конкретную программу, а не на универсальный браузер. Если Вы заглянете в HTML-код страниц крупных порталов, то почти всегда обнаружите там проверку версии браузера пользователя: разным браузерам "выдаются" разные ресурсы. В интернете можно найти рекомендации о том, как должен выглядеть HTML, чтобы "угодить всем" (то есть отображаться одинаково в Netscape Communicator, Microsoft Explorer, Opera и пр.). Обратимся к истории HTML для понимания пути, по которому он идет.

После широкого распространения браузера от Netscape недостатки первой версии HTML быстро стали очевидны. С некоторыми из них еще можно было мирится. К примеру, с тем, что сам текст и его оформление не были достаточно разумно отделены друг от друга, возможностей позиционирования и разукрашивания текста не хватало. HTML, однако, позволял только отображать информацию, требовалось же еще и получить данные от пользователя. В результате были придуманы формы, то есть стандартные элементы ввода данных. Строка ввода, список выбора, кнопки переключения - все это теперь можно было вставить в текст и получить введенные данные на сервере после того, как пользователь нажмет на кнопку отправки. Программистам, однако, этого оказалось маловато - клиент по-прежнему оставался "глупым". Перед тем как отправлять форму на сервер не мешало бы проверить введенную информацию, чтобы отреагировать на возможную ошибку немедленно, а не после долгого ожидания ответа от сервера. И эта проблема была решена. Браузер "поумнел" - появилась возможность выполнять программы "внутри" документа, осуществлять доступ к его элементам и взаимодействовать с пользователем. Язык, на котором эти программы пишутся, назвали JavaScript (JScript у Microsoft).

Бурное развитие объектной модели документа позволило свободно манипулировать его содержимым, создавать "слои" и прочие украшения, но возможностей языка JavaScript, все же, не хватало. Несмотря на то, что он уже умел управлять одновременно несколькими окнами, в каждом из которых могло быть загружено несколько документов (фреймов), несмотря на возможность изменить внешний вид документа после его загрузки, несмотря на большое кол-во событий, которые "выстреливал" браузер в ответ на действия пользователя (как-то теребение мыши и стучание по клавишам), несмотря на все это продолжал существовать ряд задач, которые не находили гладкого решения в этой среде. Например, графическое отображение динамически изменяющихся данных, а попросту говоря графиков. При передаче пользователю картинки в виде графического образа (GIF или JPEG) сильно возрастала нагрузка на канал, особенно, если требовалось мгновенно отображать меняющиеся во времени данные. Кроме того график - это, вообще говоря, не статичная картинка. Его нужно уметь растянуть, перемасштабировать, изменить цвет элементов и пр. Небезызвестная фирма MicroSoft, кстати, отлично понимала важность задачи обмена данными в реальном режиме времени и в свое время придумала для решения этого вопроса технологию DDE (Dynamic Data Exchange). С момента появления браузера Netscape существовала возможность создания, т.н. плагина (plug in), то есть внешнего двоичного модуля, подключаемого к браузеру. Однако, вопросы безопасности для подобных модулей вообще не были решены, да и надежностью эта технология не отличалась.

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

Разрабока и создание нового браузера - очень дорогая штука по деньгам и времени и сведет на нет всю экономию! Необходимо было расширить возможности существующих браузеров и дополнить их функции отображения HTML. Сразу две технологии были предложены в ответ на этот вызов.

Часть 5. Технологическая про ActiveX

Первую из них придумала MicroSoft и нарекла ее ActiveX. За активностью и иксом стоят "умные" динамически загружаемые библиотеки (DLL). Вся ОС Windows, включая ядро, построена на DLL. Windows позволяют любому приложению с помощью системного вызова LoadLibrary отобразить в свое адресное пространство код из файла определенного формата. Этот файл и называется DLL. При этом ОС берет на себя задачу автоматической связки функции, которая эта DLL использует, с ядром. После загрузки DLL становится как бы частью приложения и предоставляет ему в распоряжение свои функции. Похожие технологии существуют во многих ОС, они позволяют избежать дублирования кода. Очень просто и удобно, но MicroSoft это показалось мало! Она отделила интерфейсы (то есть соглашения о вызове функций, содержащие индексы этих функций, их имена и описание параметров) от собственно реализаций функции (то есть от кода, который выполняется при вызове функции). Интерфейсы стали хранить отдельно от программ, которые их реализуют. Одни программы (серверы автоматизации) научились объявлять о том, какие интерфейсы они предоставляют, другие (клиенты автоматизации) научились их использовать. Все это назвали COM-технологией и стало хорошо. Еще раньше правда это называлось OLE1, потом OLE2 и потом опять OLE. Чтобы покончить с этой путаницей MicroSoft обозвала все это ActiveX элементами и научила Internet Explorer их использовать. Подводя итог, ActiveX - это "умная" DLL, которая предоставляет стандартные интерфейсы и за счет этого умеет встраиваться в Internet Explorer. При этом браузер в ответ предоставляет свои интерфесы и ActiveX может им управлять как ей вздумается.

Немного сбавим пыл и попробуем осознать - что нам дает ActiveX технология с практической точки зрения? Единственный браузер, который поддерживает ActiveX, это Internet Explorer. По каналам связи он скачивает DLL в двоичном виде, регистрирует ее компьютере пользователя и выполняет ее код (код событий). Ясно как божий день, что если у клиента стоит не Windows (или не Explorer), то он не сможет воспользоваться этой ударной технологией. Более того, даже если у него стоит Windows NT, но под процессором Alpha, то ActiveX, созданный под семейство процессоров Intel Penitum, опять-таки не будет работать.

Поговорим дальше о размерах и принципах обновления версий ActiveX элементов. ActiveX с минимальным функционалом займет минимум 200 Кбайт, если создавать его с помощью Delphi или набора готовых библиотек для C++ от MicroSoft. Создавать с нуля подобное приложение можно долгими месяцами - спецификаций довольно много и реализация их нетривиальна. И это при том, что любое, даже минимальное, изменение программы вызовет повторную закачку новой версии ActiveX к пользователю. ActiveX технология, к сожалению, не содержит возможностей структурирования приложений и разделения их на небольшие части. Более точно, разбиение возможно, но каждая из таких частей обязана быть полноценной ActiveX DLL, что сводит на нет все усилия по уменьшению размеров. Еще одна огромная технологическая проблема ActiveX - это обновление версий. При попытке загрузить новую версию ActiveX, после того как поработала старая, Internet Explorer выдает сообщение, потрясающее до глубины души. Он предлагает перезагрузить компьютер, указывая при этом на то, что "системные установки изменились"! На самом деле достаточно всего лишь перезапустить сам Explorer, но и это решение нельзя признать удачным с точки зрения комфорта для пользователя.

Рассмотрим теперь соображения безопасности. Даже если ActiveX будет работать у пользователя - захочет ли этого пользователь? Только безумец откроет доступ к своему компьютеру приложениям из интернета, среди которых могут оказаться вирусы или не менее зловредные программы. MicroSoft, осознавая этот факт, предложила сертифицировать ActiveX с помощью электронной подписи. Заплатите около 300$, получите сертификат и дело в шляпе! Но что мешает мошенникам зарегистрировать фирму и сертифицировать свой "плохой" ActiveX элемент? Сертификация всего лишь удостоверяет _авторство_ ActiveX элемента. Далее, надо понимать, что ActiveX создаются людьми, а те ошибаются. "Порывшись" в интернете, Вы легко найдете множество примеров того, как сертифицированные "чистые" ActiveX элементы от таких грандов как MicroSoft или Adobe содержат ошибки переполнения буфера. То есть можно загрузить такой ActiveX элемент клиенту и вызвать метод, который выполнит _любой_ двоичный код на компьютере пользователя от его имени. В настоящее время ActiveX элементы используются, в основном, внутри интранет-сетей. Здесь проблемы больших размеров и безопасности решаются с других позиций. В интернет эта технология получила рапространение в виде Flash (флеш) проигрывателя, который позволяет воспроизводить анимацию, сильно превосходящую стандартные возможности HTML.


Часть 6. Технологическая про Яву

И все же - что делать, если мы не хотим подвергать свой компьютер опасности, но желаем выполнять на нем программы, достаточно мощные для отображения графики и управления вводом от пользователя? В 1995 году группа программистов, финансируемая фирмой Sun, выдвинула идею аппаратно-независимой Ява-платформы. Изначально этот проект создавался для управления бытовой техникой. Однако, интернет востребовал Яву гораздо сильнее. В основе Явы лежит идея полной кроссплатформенности. Приложение на Яве отделяет от ОС и аппаратной части компьютера специальная среда, содержащая разветвленные библиотеки на все случаи жизни, называемая виртуальной Ява-машиной (JVM). Однако, обычная интерпретация показалась авторам слишком медленным и неоптимизируемым, в смысле размера кода, процессом. В результате, программа на Яве компилируется, но не в двоичные коды, исполняемые процессором определенной архитектуры, а в специальный компактный Ява-код, исполняемый Ява-машиной. Программист, знакомый с языком форт(forth) или PostScript, найдет похожие решения в Ява-машине. В ее основе "стековая" архитектура, все вычисления проводятся через стек операндов. Ява-код представляет из себя набор команд, которые оперируют стеком или изменяют ход выполнения программы. Яву, как систему программирования, отличает отсутствие указателей (вместо них экземпляры класса), глобальных переменных, функций работы с памятью (автоматическая сборка мусора), строгая типизация, встроенная поддержка многозадачности, поддержка интерфейсов взамен множественного наследования. Ява-код, получаемый в результате компиляции, перед выполнением проверяется специальной программой (верификатором). Это означает, что Вы не сможете выполнить "искуственно" созданный Ява-код, который исчерпает стек операндов или каким-либо еще способом нарушит работу Ява-машины. Кстати говоря, байт-код не обязательно должен получаться в результате компиляции Ява-программы! Существуют другие языки, которые можно использовать в этих целях.

Современные браузеры (Communicator, Explorer) имеют "встроенную" Ява-машину и позволяют выполнять "безопасный" Ява-код. Вызовы отдельных методов при этом запрещены. К примеру, Ява-программы, выполняемые в браузере, не могут обратиться к файлам на диске. Основные проблемы, с которыми сталкивается программист при работе с Явой, это - неэффективное исполнение Ява-кода, неполная или неточная поддержка спецификаций стандартных классов, большая нагрузка на ресурсы компьютера, плохие алгоритмы сбора мусора и, как следствие, утечки памяти. Стандартная библиотека, окружающая Ява-программу, постоянно изменяется. Sun ведет большую работу, направленную на ее улучшение, но на практике это означает, что Ява бывает разной! Как правило, можно выделить Яву до версии 1.1, версию 1.1 (наиболее распространенную и встроенную в браузеры Netscape Communicator и Microsoft Explorer) и версию 1.2 (т.н. Java 2), поддержка которой в браузере возможна, но сопряжена с определенными трудностями (надо устанавливать дополнительный модуль). К тому же Microsoft приложила усилия для компроментации Явы, создав на платформе Windows Ява-машину, не полностью соответствующую спецификациям от Sun. Особенности Ява-машин заслуживают отдельного разговора. Работа программиста сводится к постоянному тестированию своих Ява-приложений в различных условиях для избежания возможных проблем.


Часть 7. Многоликие миры Явы

Как, Вы не слышали про Яву? Универсальную кросс-платформенную среду разработки распределенных приложений, сочетающую в себе последние достижения в области ООП с мощным языком и удобными библиотеками? Немного отвлечемся от рекламных проспектов Sun и обратимся к реальности. Для разработки Ява-приложений под Windows можно использовать как "родной" пакет Sun JDK, так и Microsoft Java SDK (свободно доступны на веб-серверах упомянутых фирм). Но если Вы серьезный программист, то рекомендую Вам поставить оба этих пакета и вот почему : компилятор Java SDK от Microsоft _на порядок_ быстрее своего сановского собрата. При отладке больших программ Вы оцените это преимущество очень быстро. В то же время конечную (final) компиляцию приложения в Ява-код следует все же поручить компилятору от Sun, так как он строго следует спецификациям.

Программа на Яве, исполняемая браузером, называется апплетом ("приложеньицем" в переводе Internet Explorer). Апплет обязан унаследовать специальный класс Applet и переопределить методы инициализации, отображения на экране и уничтожения. Апплет выполняется с учетом ограничений среды, обычно называемой "песочницей". "Песочница" запрещает апплету вызывать методы, которые считаются "опасными" с точки зрения воздействия на компьютер пользователя, например, обращаться к файлам на диске.

Действительно ли Ява безопасна? В теории - да, но ее реализации уязвимы! За продуктами Microsoft недаром идет слава "дырявых". Недостаточное тестирование при их разработке приводит к появлению ошибок, которые легко приводят к нарушениями безопасности. Опытные серферы отключают выполнение апплетов на браузере - они знают, что существуют возможности "обмануть" ява-машину Internet Explorer и выполнить зловредные действия на компьютере пользователя. Microsoft реагирует на сообщения об взломах, выпуская заплатки, но они всегда отстают от жизни. Сказанное выше относится и к другим производителям программных продуктов.

По умолчанию в Microsoft Internet Explorer версии 4 и Netscape Communicator 4.7 выполнение апплетов разрешено. В стандартную поставку 5-ой версии Internet Explorer Ява-машина уже не входит, хотя ее можно скачать позднее из интернета ("поигрались и хватит!"). Но и в 5-ой версии Ява-апплетам изначально выполняться разрешается. Этот факт говорит о безграничном доверии производителей браузеров к Ява-технологии. Посудите сами - без ведома и спроса пользователя на его компьютере запускается произвольная программа в тот момент, когда он заходит на некоторый сайт! Причем пользователь может даже и не заметить появления в статусной строке браузера сообщения "Starting Java..." и не иметь ни малейшего понятия о том, что апплет начал работу. Но это еще не все! Когда пользователь загружает в окно с апплетом другую страницу, он и не догадывается о том, что этот апплет может остаться в памяти и продолжать работать! Этот факт малоизвестен, а между тем легко проверяется с помощью простейшей Ява-программы, создающей несколько потоков. Лишь только закрыв окно браузера, в которое ранее была загружена страница с Ява-апплетом, пользователь остановит его выполнение.

Разрабатывая апплет, Вам следует узнать включена ли Ява у пользователя и если нет - убедить его сделать это! В Internet Explorer существует возможность создания списка сайтов, которым вы доверяете и настройки безопасности под эти сайты отдельно. Вот только справится ли с этим пользователь? Существует возможность подписывания апплетов, но рассматривать ее здесь подробно не имеет смысла по указанной выше причине - сертифицируется лишь авторство апплета.

Итак, предположим, что браузер скачал наш апплет на компьютер пользователя и начал его выполнение. Что мы можем делать? Все, что не может оставить след на компьютере пользователя после перезагрузки или передать нежелательную информацию о нем куда-либо! Апплету разрешается получение системной информации о среде выполнения, операционной системе и версии Ява-машины, но получить, к примеру, имя пользователя уже нельзя. Мы можем открыть окна, одно или несколько, но внизу каждого такого окна будет находиться надпись "Warning: Applet window", которая предупреждает пользователя о том, что данное окно не должно пользоваться его доверием безгранично. Апплету разрешается стартовать новые потоки, выполнение их будет происходить параллельно, однако, большое количество потоков очень быстро "съест" ресурсы машины. Запуск внешних программ и вообще любая связь с внешним миром запрщена, за одним исключением. Апплету разрешается установить полноценное TCP-соединение с хостом, с которого он был загружен.

Вообще говоря, стандарт Ява-машины разрешает апплету пользоваться протоколом UDP. Данный протокол позволяет обмениваться данными без установления соединения и не гарантируя надежности передачи данных. UDP более экономно (в сравнении с TCP) использует каналы передачи данных и снижает нагрузку на сервер. Он широко применяется в приложениях, где потеря 1-2 пакетов из, скажем, 100 несущественна. Как ни странно, можно привести много примеров клиент-серверных приложений, которые прекрасно работают, "теряя" по ходу некоторую информацию. Это, к примеру, новостные ленты, передаваемые клиенту. Новости здесь, как правило, повторяются и, к тому же, подводятся главные события дня, так что, с большой степенью вероятности, клиент не пропустит нужную ему информацию. Потоковое вещание видео- или аудио-информации также имеет смысл реализовать на UDP. Потеря нескольких кадров не является здесь большой проблемой (это справедливо в особенности для аудио-потока, видео-поток обычно "связан" сильнее). Рассмотрим схему, при которой клиент отображает некоторую актуальную информацию, периодически опрашивая сервер через фиксированный интервал времени. Этот интервал достаточно мал (5-30 сек), в то время как запрашиваемая информация обновляется не слишком часто (10-60 сек). В своем запросе клиент передает момент времени, информацией _до_ которого он обладает. Сервер отвечает, высылая ему всю _новую_ информацию _от_ запрошенного момента плюс этот самый момент, чтобы клиент мог прислать его в следующем запросе. Даже если запрос или ответ будут потеряны, клиент повторит свой запрос спустя некоторое время и все равно получит всю информцию (при этом повторный ответ наверняка будет отличаться от потерянного, поскольку пройдет какое-то время). Подобная схема с большой вероятностью гарантирует попадание нужной информации к клиенту за определенный период времени при не слишком высокой вероятности потери пакета. Используя методы теории вероятности, можно точно определить требуемые временные рамки запросов.

Сочетание данной схеме обновления, Ява-апплета и UDP кажется весьма удачным решением для отображения графиков и другой информации у клиента? Сядьте в кресло, дышите глубже - Microsoft Explorer не позволяет анонимному Ява-апплету принимать UDP-пакеты, несмотря на cтандарты. Остается только догадываться о причинах подобного поведения. Возможно это связано с распространившимися атаками на DNS-серверы (они часто используют UDP вместо TCP), официальная позиция Microsoft заключается в том, что это ошибка. Так, или иначе - UDP вашему аплету не грозит, остается TCP. Как было сказано ранее, установление TCP-соединения апплета с хостом, с которого он был загружен, разрешается, причем, по любому порту. На практике это означает, что на машине с веб-сервером Вам следует установить серверную часть приложения, которое будет обрабатывать запросы апплетов. Функционал такого приложения сильно напоминает функционал веб-севера : прослушивание порта, установление соединений, идентификация пользователей, обработка запросов, отправление ответов. Ествественно, возникает вопрос - нельзя ли обойтись веб-сервером для решения этих задач? Разумеется, можно! Протокол HTTP позволяет передавать и специальным образом организованную двоичную информацию. Более того, ничего не мешает воспользоваться для обработки запросов скриптами того же ASP. Существует, однако, здесь два ограничения, которые могут испортить вам кровь. Во-первых, даже если пользователь идентифицирован сервером, апплету про это неизвестно. Он не может попросить браузер "добавить" к своим запросам данные логина и пароля. Во-вторых, если браузер работает через прокси, апплет не сможет с ним соединиться. У апплета есть права только на соединение со своим хостом. Таким образом, в случае, если Ваш прокси имеет специальное назначение (например, шифрует трафик) апплет не сможет работать с веб-сервером. Вообще говоря, эта проблема решаема. Можно создать редиректор, который "обманет" браузер и разрешит его апплету работать с прокси, но подобная программа заслуживает отдельного разговора!

Выход в свет Ява-машины от Micrоsoft привел, как известно, к заявлению Sun о недопустимости использования в ее названии высокого слова "Java"! Что же вызвало у Sun столь негативную реакцию? Насколько сильно отличается Ява-машина Microsoft от стандарта? Как ни странно, ничем особенным не отличается. Microsoft "всего лишь" подправила спецификацию Java, "заточив" ее под Windows. Она добавила некоторые новые классы и незначительно изменила реализацию отдельных методов. Из Ява-платформы в реализации от Microsoft пропал всего лишь _один_ метод стандартной библиотеки (ByteArrayOutputStream.toString()), и тот без труда эмулируется двумя другими. Необходимо отметить, что Microsoft не стала поддерживать некоторые разработки, которые конкурировали с ее собственными технологиями (RMI, JNI, CORBA) и одновременно позволила из Явы вызывать некоторые API, специфичные для Windows (например, DirectX). Корень несовместимости Ява-машин лежит, к сожалению, не в документированных отличиях от стандарта. Увы, проблема в недокументированных "особенностях" поведения в одних и тех же условиях! Основная задача, которую ставила перед собой Microsoft, заключалась в дискредитации Ява-платформы, как универсальной гетерогенной платформы разработки.

Отличия Ява-машин, которые способны свести вас с ума, слава Гейтсу, немного. Ограничения UDP или отсутствие RMI можно обойти. Мелочей же, отравляющих Вашу жизнь - не счесть! Запустите апплет, который просто отображает выпадающий список, в Explorer и Communicator и Вы увидите разную картину - цвет фона списка там и здесь отличается. Добавьте полосу прокрутки (ScrollBar) и Вы обнаружите, что Explorer версии 4 с Ява-машиной версии 1.1 под Windows 95 не умеет менять длину бегунка! Создайте объект Calendar, который служит для преобразования сочетания "день-месяц-год" в дату, и попробуйте отсчитать некоторое количество дней от начала века. В вышеупомянутой версии Explorer вы будете получать каждый раз разные даты! При этом в поздних версиях Microsoft Explorer и любых Netscape Communicator все работает нормально. Все это Вам кажется мелочью? Что ж перейдем к казусам посильнее.

Возьмем опять объект Calendar и присвоим ему некоторую дату, скажем 1 января 1900 года. Теперь попросим представить ее в строковом виде. В Explorer Вы обнаружите, что загадочным образом оказались в конце 1899 года! Пользуясь какой-то своей внутренней логикой, браузер сдвигает часовые пояса относительно Гринвича и оказывается в прошлом веке (некоторые утверждают, что век заканчивается в конце нулевого года, но эту трактовку мое сознание не приемлет)! Версия ява-машины от Microsoft за нумером 1.2.2 такого странного поведения уже не демонстрирует, но и в 4-й и в 5-ы Explorer встроена версия ява-машины 1.1.4. Если Вы надеялись, что библиотека классов Ява избавит Вас от рутинной возни с датами - забудьте! Netscape Communicator тоже не ангел и порой сбивает тебя с толку не меньше, чем Explorer. Один и тот же апплет, работающий под Communicator и под Explorer, в первом случае частенько приводил к ошибке при работе с сокетом TCP, а в во-втором не дал ни одного сбоя! Подобная картина наблюдалась не раз и не два, а в течение всего времени разработки. Вы можете столкнуться и с более непредсказуемыми вещами. Например, Ява-машина Microsoft может выбрасывать исключительные ситуации, сообщая, что "указатель не инициализирован", если Вы скомпилировали апплет с помощью компилятора от Sun. Это может происходить, когда вы "кликаете" мышью на апплете и вызывается сообщением о передаче фокуса. Причем, на нормальной работе апплета это не отражается!

Ява-платформа была предложена программистам как средство, позволяющее сосредоточится на сути проекта и сэкономить время. Наверное, лет через 10 так оно и будет. Однако, в настоящее время Ява-библиотеки все еще меняют свои очертания, а отличия в их реализации приводят к определенным трудностям. Будьте готовы засучить рукава! В крупных Ява-проектах программисты, как правило, вначале пишут свои собственные библиотеки, "обертывающие" стандартные и используют в дальнейшем именно их и при создании визуального интерфейса и для других задач. Все же, несмотря на недостатки, альтернативы Явы-платформы пока нет. Компактный Ява-код, наличие Ява-машин в браузерах последнего поколения, мощная среда разработки, встроенная многозадачность и наличие относительно простой оконной библиотеки позволяют разрабатывать довольно сложные апплеты, дополняющие возможности HTML.

Часть 8. Переспективная.

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

Подобный механизм невозможен без "доверительных отношений". Пользователи получать возможность заявлять о своей степени доверия к компонентам. Чем больше пользователей у компонента, которые его активно используют, тем более надежным он будет представляться. Сертификация компонент будет, таким образом, проводится децентрализованно всеми клиентами сети.

Язык XML не получит столь большого распространения и одобрения как HTML со стороны независимых программистов, так как спецификации данного языка будут создаваться компьютерными грандами, каждый из которых будет "тянуть одеяло" на себя. В отличие от HTML, реализация которого понятна без дополнительной информации, XML требует наличия парсера, который объясняет браузеру что ему делать с этим XML. HTML спустя какое-то время опять получит развитие, на этот раз для более структурированного представления информации. Появятся "расширения" HTML, которые будут направление на решение специализированных задач, таких как представление анимации или трехмерных моделей. Не исключено и создание HTML нового поколения, четко ориентированного на удобное и однозначное представление информации на экране. В этом HTML уже не будет тегов, которые структурируют документ. Только отображение информации с широким использованием стилей. Параллельно будет развиваться язык структурированного представления информации на клиенте, скорее всего, в иерархическом виде. Данный язык позволит определять произвольные структуры данных и их взаимосвязь, принципы синхронизации с сервером, схему событий при изменении данных и пр. Приложение у клиента будет состоять из нескольких независимых частей : структурированной информации, описания представления данных на экране пользователя, реализация событий.

Браузер от Microsoft будет все больше дополняться ненужными вещами и все более использоваться самой Microsoft для своих приложений в качестве интерфейса пользователя. Explorer останется все таким же ненадежным и все еще будет отъедать вашу память. Новые версии будут выходить быстрее, чем обновления старых. Основная задача при этом - загромоздить экран пользователя как можно большим числом панелек к кнопочками, чтобы он пошел покупать себе монитор с большей диагональю экрана. На этот счет у Microsoft существует тайный сговор с производителями мониторов, памяти, процессоров и пр. Альтернативных браузеров будет много, все они будут отличаться друг от друга, так что у пользователя будет стоять на компьютере 5-10 различных экземпляров. Каждый из них будет иметь неоспоримые преимущества перед другими (в скорости, размере, стоимости, кол-ве наворотов и пр.) и каждый из них будет реализовывать "свое" расширение HTML (см. выше), так что все они будут необходимы.

Microsoft, "выиграв раунд" в борьбе за интернет-клиента (по последним данным более 85% пользователей используют Explorer), попробует "подмять под себя" интернет-технологии на сервере. Называется это будет Windows.NET (хорошое название для русского прочтения!). Через какое-то время Вы с удивлением обнаружите, что, помимо старого доброго HTTP, ваш интернет-провайдер предлагает вам новый протокол MSRULEZ, который гораздо быстрее и полнее предоставляет Вам информацию из интернета. Вы можете получать ее и на компьютер, и на мобильный, и на настольную лампу. Все это удобно и быстро. Одна проблема - телефон и лампа должны быть "Microsoft compatible", а на компьютере должна стоять, кто? Правильно, Windows Next Generation. Поставив себе новую версию Windows, Вы постепенно откажетесь от HTTP и начнете наслаждаться MSRULEZ, так как он удобнее (не забывая при этом периодически чертыхаться при "глюках" системы). Не беда, что данный протокол поддерживает только новый браузер от Microsoft и только под Windows. Все равно Вы других ОС и не видели. Через какое-то время Вы обнаружите, что ошибки исправлять бесплатно никто и не собирался, а денег платить приходится немало. Но все равно не вернетесь к HTTP, так как Microsoft выпустит заплатку x4274N35, которая исправит 100 ошибок и добавит 200 новых.

Необходимо все же отметить, что "победить" весь интернет Microsoft не сможет. Скорее всего борьба пойдет за интранет-технологии (довольно прибыльные, надо сказать). Появится новая версия корпоративной Windows, которая изначально будет обладать широким спектром возможностей. Как-то: последняя версия браузера, наличие мощной скриптовой машины и веб-сервера, компонентов офиса (а то и весь офис целиком), а также поддержка большого количества сетевых сервисов от Microsoft, которые работают только под управлением Windows. Не исключен и сервер БД. Такая ОС со встроенным "софтом", готовым к работе без дополнительных усилий, получит распространение и пошатнет позиции UNIX. Все это будет приводит к росту недоверия к программным продуктам, так как надежность этой новой ОС будет обратно пропорциональна "мощности" заготовленного ПО. Основная проблема Microsoft - это совместимость с предыдущими версиями. Подобная задача не стоит (пока) перед создателями BeOS. Эта ОС постепенно получит распространение в интер- и интранете за счет "гладкой" установки "рядом с" Windows. Самый лучший способ ее популяризации - это выпуск Quake IV или War Craft III _только_ под BeOS, но этого, увы, не произойдет. Позиции Linux будут укрепляться, рано или поздно эта ОС получит мощную, современную 64-битную файловую систему, поддержку многопроцессорности и большого количества оперативной памяти, но серьезно конкурировать с той же Solaris не сможет. Все из-за "любительского" ореола вокруг ее создателей и отсутствие четкой линии развития.


Часть 9. Итоги

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

Автор Grigory Grigorenko Сентябрь 2000
Картинки предоставлены автором.

  • Главная
  • Новости
  • Новинки
  • Скрипты
  • Форум
  • Ссылки
  • О сайте




  • Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
     Copyright © 2001-2024
    Реклама на сайте