Интернет-кухня
АрхивНа вооружении программиста, занятого в разработке Интернет- и интранет-приложений, находится большое число технологий с труднопроизносимыми названиями: HTML, HTTP, ASP, PHP, SSL и пр. С каждым днем их становится все больше. Попробуем разобраться в том, что есть что, а также ответить на вопрос, насколько удобны эти технологии и как их использовать с наибольшей эффективностью?
ИСТОРИЯ
С тех пор как компьютеры объединили в сеть для обмена информацией, среди них начали выделять те, что запрашивают услуги, и те, что их предоставляют. Первые назвали клиентами, вторые — серверами. Между клиентом и сервером появились посредники («брокеры» в терминологии CORBA), удлиняя цепочку, связывающую пользователя с нужными ему данными.
Вначале на свет появился «тонкий клиент». Так называют организацию системы, в которой компьютер пользователя является, по сути, экраном сервера (терминалом). Клиент вообще не имеет вычислительного блока и не может заниматься обработкой данных. Отсюда недостатки: большой объем передаваемых данных (в готовом для отображения на мониторе виде), невозможность хранения информации на клиенте, долгая реакция на действия пользователя (каждый раз обращение к серверу), психологический фактор («если сервер сломается — все пропадет»). Фактически это не сеть, а одна «большая» ЭВМ.
Реализация удобного интерфейса пользователя требует наличия мощного компьютера у клиента (особенно если речь идет о графической, или «оконной», оболочке). Последующий крен в эту сторону (который стал возможен благодаря удешевлению компьютеров) привел к появлению «толстого клиента». Речь идет о ситуации, когда основные приложения работают на компьютере пользователя, а сервер лишь предоставляет услуги по хранению и обмену файлами (или вовсе отсутствует). Фактически каждый компьютер является одновременно и клиентом, и сервером. Нет никакой специализации — вся сеть однородна. Поговорим о недостатках этой схемы. Нецентрализованное хранение данных усложняет доступ к ним. Невозможно гарантировать целостность (непротиворечивость) информации, произвести полноценную архивацию. Возникают вопросы разграничения доступа и безопасности — каждый компьютер обращается к любому другому. Клиент уже не может быть «карманным калькулятором»: ему придется производить расчеты, быстро реагировать на действия пользователя, управлять сетевой средой и отображением данных. К тому же стоимость администрирования подобной сети очень велика: представьте, что у вас в системе тысяча компьютеров и на все нужно установить новую версию рабочего приложения!
Правильное решение заключается в «умной» специализации компьютеров, создании «сетевой среды». Задачи хранения, архивации, обработки, передачи и отображения данных, управления доступом, адресации разделяются между компьютерами, которые взаимодействуют между собой с использованием специальных протоколов. Для создания подобной сети необходимо решить ряд вопросов. Приведем наиболее важные из них. Какие задачи возложить на компьютер пользователя? Какова схема адресации, то есть как компьютеры находят друг друга? Какие протоколы обмена информацией будут использоваться? Как решаются вопросы безопасности, то есть ограничения доступа? В каком виде должны формироваться запросы и ответы, какие языки следует использовать? Сеть Интернет представляет собой аналог подобной сетевой среды.
Разработчики TCP/IP не предполагали, что этот протокол будет использоваться в глобальной компьютерной сети, но в процессе эксплуатации он был «доведен до ума» и зарекомендовал себя с хорошей стороны. Основной его пробел — отсутствие встроенных средств обеспечения безопасности. Всем Интернет-приложениям приходится реализовывать авторизационные процедуры самостоятельно. Существует и другая серьезная проблема — исчерпание пространства IP-адресов, которое, по некоторым прогнозам, произойдет в период 2005–2010 гг. Новая версия протокола (так называемая версия 6) призвана решить эти и другие вопросы (неэффективное использование пропускных способностей, отсутствие вложенных заголовков и пр.), однако ее внедрение сталкивается с вполне понятными трудностями: огромное количество «железа» (точнее, встроенного в него программного обеспечения. — С.Л.) понимает лишь «старый» TCP/IP.
Компьютеры находят друг друга в Интернете, используя DNS (Dynamic Name Service). Этот сервис позволяет скрыть реальный, так называемый IP-адрес компьютера за относительно удобной нотацией доменных имен иерархического вида. К сожалению, DNS ненадежен с точки зрения безопасности (см. врезку).
По данным австралийской компании DeMorgan (www.demorgan.com.au), дела с безопасностью DNS-серверов в стране обстоят плачевно. Компания просканировала все серверы в регионе — более 8,5 тыс. систем (поддерживающих около 80 тыс. доменных имен Австралии и Новой Зеландии). 75% из них уязвимы для DoS-атак (Denial-of-Service), а 55% могут предоставить взломщику полный доступ — уровень root. Один из методов, который используют хакеры, это перенаправление зоны DNS на прокси-сервер, захват важной информации и отсылка данных обратно реальному серверу.
Итак, два компьютера нашли друг друга и получили возможность обмениваться инфор мацией. Что они будут друг другу передавать? Одним из важнейших достижений Интернета принято считать использование HTML (Hyper Text Markup Language) — языка представления «умного» текста, структурированного специальным образом. HTML решил вопрос пользовательского интерфейса следующим образом: на компьютер пользователя возложили ответственность «лишь» за правильное отображение HTML-страниц специальной программой (браузером). Что же должен «уметь» сервер?
ПРО СЕРВЕР
Программа, которая выдает HTML-страницы в ответ на запрос на языке HTTP (Hyper Text Transfer Protocol), называется WWW-, или вебсервером. В основе Интернет-технологий лежит простая идея: HTML-страницы не обязаны быть статичными и храниться в готовом виде. Ничто не мешает формировать их динамически в ответ на запрос пользователя. Если для этого используется отдельное приложение, которое запускается WWW-сервером, тогда это CGI (Common Gateway Interface). Создать CGI-приложение нетрудно. В то время как WWW-сервер занимается управлением правами доступа, обработкой поступающих запросов, передачей данных клиенту и пр., от программы CGI требуется всего лишь вывести HTML-страницу в стандартный поток вывода. При этом она может быть написана на C++, присоединяться к базам данных или другим ресурсам и выполняться очень быстро. Данные запроса передаются в CGI-приложения через переменные окружения или через стандартный ввод.
Представим себе сильно загруженный WWW-сервер. В течение одной секунды он должен обслужить сто запросов пользователей. Это означает одновременный запуск ста CGI-приложений! С точки зрения операционной системы (далее ОС), создание нового процесса всегда штука трудоемкая, как, впрочем, и, хм, поддержание его в работоспособном состоянии. Для запуска программы ОС создает специальные структуры внутри ядра, выделяет память под сегменты задачи, загружает с диска данные приложения и связывает его с динамическими библиотеками. После завершения работы приложения необходимо освобождать все занятые им ресурсы. Не надо забывать и о времени инициализации приложения. Если идет работа с базой данных, время инициализации — это время установления соединения с сервером БД, и это соединение не всегда выполняется быстро (требуется установить канал связи, проверить права доступа и пр.). А если сервер БД загружен, времени понадобится еще больше.
CGI следует использовать в том случае, когда время отклика не критично (генерация отчетов и пр.) и когда запросы для CGI-приложений поступают не очень часто (раз в 10–60 секунд). Что же делать, если необходим динамический HTML, но ресурсы на CGI тратить не хочется?
Выход был найден и здесь: чтобы не запускать отдельное приложение, его нужно встроить в WWW- сервер. Поскольку заранее не известно, что именно будет делать это приложение, следует встроить в WWW-сервер интерпретатор удобного для перемалывания данных языка. Такое решение позволит каждый запрос обрабатывать отдельным потоком сервера (нитью, тредом [thread]), а не отдельным процессом ОС. Это уменьшает время отклика и снижает нагрузку на процессор. Программы, которые обрабатывает этот интерпретатор, часто называют скриптами. В решении внедрить интерпретатор в WWW-сервер таятся как плюсы, так и минусы: интерпретация скриптов позволяет вносить в них изменения и немедленно видеть результат, но выполняются они медленнее скомпилированной программы. К тому же ошибка в CGI-приложении никак не повлияет на устойчивость WWW-сервера, а вот ошибка во встроенном интерпретаторе, скорее всего, будет для сервера фатальна. Как показала практика, плюсы все же перевесили. Главной задачей, возлагаемой на скрипты, стало взаимодействие с БД, а здесь основные задержки возникают, как правило, на сервере БД. К тому же отсутствие необходимости в компиляции необычайно удобно при отладке Интернет-приложений, что очень важно, так как в стадии отладки эти приложения пребывают вплоть до того момента, когда их заменяют другими.
Решение этой задачи, предложенное фирмой Microsoft, называется ASP (Active Server Pages) (см. врезку).
Для дальнейшего обсуждения ASP нам нужно уяснить, каким образом протекает общение пользователя с неким сайтом. Протокол HTTP реализует схему авторизации пользователей через пароли. Ресурсы, открытые для всех, доступны для «анонимных» запросов. При обращении к закрытому ресурсу вебсервер проверяет — есть ли в запросе идентификатор и пароль пользователя? Если есть, разрешен ли ему доступ к этому ресурсу? В том случае, когда доступ к ресурсу запрещен, сервер возвращает браузеру страницу с сообщением об ошибке и специальный код ответа. Браузер обычно реагирует на это просьбой к пользователю указать его идентификатор (login, логин) и пароль. После ввода данных браузер вновь запрашивает ресурс, а в случае отказа от ввода — показывает страницу с сообщением об ошибке, которую вернул ему сервер. Если же логин и пароль указаны верно, пользователь получает доступ к содержимому ресурса. Работающий экземпляр браузера реагирует на это следующим образом: он сохраняет во внутренних переменных логин и пароль, введенные пользователем, и в дальнейшем передает их на сервер при любом запросе. Эти переменные не сохраняются на диске и будут уничтожены по завершении работы данного экземпляра. Кстати, Microsoft Internet Explorer 4.0 может «путать» авторизационную информацию разных копий браузера, запущенных одновременно.
| ASP — это «кастрированный» Бейсик, так горячо любимый отцом-основателем Microsoft. Достоинство ASP, однако ж, в том, что он позволяет в процессе работы расширять себя дополнительными модулями, которые могут быть написаны на любом языке, включая C++. ASP можно встраивать прямо в HTML. Это удобно, хотя в результате можно легко добиться жуткого вида HTML-страниц: код HTML, перемешанный с ASP, и все это густо усеяно врезками JavaScript и описаниями стилей! Найти потом нужное место и подправить скрипт очень непросто! Почти все скриптовые языки «объектноподобны». Это означает, что они не поддерживают, к примеру, наследование, но предоставляют в распоряжение программиста некие псевдообъекты типа «запрос пользователя», за которыми скрываются элементы протокола HTTP. |
Такой механизм авторизации не может быть использован для идентификации пользователей, обращающихся к открытым ресурсам. Необходимость же подобной идентификации диктуется несомненной обоюдной выгодой пользователя и поставщика Интернет-ресурса. К примеру, поисковая машина может хранить несколько последних запросов пользователя и предлагать их выбрать при последующих обращениях. Протокол HTTP не поддерживает понятие «сессия анонимного пользователя» в «чистом виде», в нем нет явно выраженных событий начала и конца работы с сайтом для определенного пользователя.
Для идентификации пользователей и имитации подобной сессии были придуманы так называемые куки (cookies), или в вольном переводе «вафельки». Это переменные, хранящиеся у клиента, которые браузер присылает в каждом своем запросе на сайт. Упрощая, можно сказать, что вебсервер «метит» разной краской заходящих на него пользователей и затем отличает их друг от друга по цвету.
Данный механизм встречает некоторое противодействие со стороны борцов за защиту прав человека, так как позволяет незаметно получить и сохранить информацию о предпочтениях клиента. Последнее время произошло несколько скандалов в этой области в Америке, граждане которой борются за свои права и свободы большую часть своего времени. Все эти скандалы, как правило, связаны с нежеланием пользователей терять виртуальную анонимность. Несмотря на дружные заверения большинства Интернет-магазинов в том, что они не станут собирать информацию о вкусах и предпочтениях пользователей, все они это делали и делают.
Куки, по умолчанию разрешенные всеми браузерами, сильно упрощают программирование Интернет-приложений. Во-первых, такие переменные позволяют понять, был ли пользователь на сайте прежде (если не был — куки в запросе не будет). Во-вторых, можно хранить некоторую индивидуальную информацию для пользователя и выдавать HTML, ориентированный конкретно на него. В-третьих, куки могут хранить некий уникальный номер, который позволит различать клиентов в процессе работы с сайтом и «эмулировать» Интернет-сессию. Гарантией уникальности сессии является случайность ее идентификатора. Обычно в качестве идентификатора используют строку случайных букв латинского алфавита длиной 20–30 символов. Вероятностью повтора последовательности символов в течение времени жизни Интернет-приложения можно пренебречь. Стартом такой «анонимной» сесии будет первый запрос от пользователя вебсерверу. С окончанием сессии все не так просто. Вообще говоря, она заканчивается, когда закрывается браузер. С точки зрения пользователя, такой момент наступает и при уходе на другой сайт, но браузер сохраняет все сессионные куки до момента закрытия главного окна, из которого открыты все остальные. Если, допустим, человек зарегистрировался в магазине и затем ушел на другой сайт, то вернуться обратно в магазин он сможет уже без пароля, если не был использован специальный механизм выхода, который стирает куки.
Но как об окончании сессии узнает вебсервер? Во-первых, язык HTML (в своих последних версиях) поддерживает события, связанные с «линией жизни» документов. То есть при выгрузке документа можно отправить запрос специального вида на сервер. Существует и другой способ, который дополнительно загружает каналы и сервер, но является более надежным. У пользователя в браузере создается невидимый фрейм (часть страницы), который обновляется через определенный промежуток времени (например, минуту). Если сервер в течение длительного времени (например, пять минут) не получает запросов от фрейма, он считает, что пользователь закончил работу с сайтом и закрывает сессию. Для этого требуется поддерживать список активных сессий и регулярно его обновлять (при поступлении запроса от невидимого фрейма сессия продлевается).
В механизме сессий есть еще один тонкий момент. В реальной жизни, как правило, пользователь такой системы будет равен ее клиенту. Что, однако, мешает открыть два или три окна браузера и в каждом из них «войти» на сайт? Как в таком случае поступит система, зависит от ее реализации. Правильно ли считать каждую последующую сессию концом предыдущей? Видимо, самым безопасным и разумным можно считать запрет на одновременную работу пользователя в нескольких сессиях.
Вернемся к ASP. Он поддерживает механизм сессий в удобном для программиста виде, «выстреливая» события старта и окончания сессии. Окончание сессии происходит через определенное время, отсчитываемое от последнего обращения к серверу (по умолчанию этот период составляет пятнадцать минут). ASP вводит псевдообъект «сессия» и позволяет хранить внутри него данные, уникальные для пользователей. Вообще говоря, механизм сессий в ASP очень удобен, но, к сожалению, в серьезном Интернет-проекте им пользоваться не следует. В противном случае вы неизбежно столкнетесь с непредсказуемыми задержками в работе вебсервера. Будьте готовы к частым зависаниям «на пустом месте» и необъяснимым паузам при обработке ASP-скриптов. К недостаткам ASP стоит отнести также ненадежность вебсервера IIS (при серьезной нагрузке приготовьтесь перегружать его каждую ночь) и не вполне удобная нотация Бейсика (каждый оператор в отдельной строке, Then после If и пр.). Нужно понимать, что ASP-скрипты не предназначены для проведения сложных расчетов или замысловатых преобразований данных. Рано или поздно абсолютно корректный скрипт начнет «вышибать» ваш вебсервер с завидной регулярностью. Microsoft, озабоченная «падучестью» своего сервера, даже разработала специальный продукт под названием IIS Exception Monitor. Это приложение должно было развеять злые умыслы тех, кто считал, что вебсервер «падает» из-за внутренних ошибок, и переложить груз неудачи на встраиваемые в IIS приложения. Единственно полезной функцией Exception Monitor является сигнализация о «падении» вебсервера путем посылки сообщения и немедленный рестарт. Просмотр же многостраничных распечаток с дампами стека и памяти для обнаружения того, в какой именно функции ASP-интерпретатор дал сбой, интересен лишь отъявленному хакеру или виртуальному мазохисту. Впрочем, эти понятия не так далеки друг от друга.
В стане Unix изначально получил широкое распространение интерпретатор языка PERL (Practical Expression Regular Language). В названии таится главный смысл: «обработка регулярных выражений», то есть специальных выражений, которые перемалывают строки по шаблонам. PERL позволяет лаконично описывать и решать сложные задачи хранения и синтаксического разбора строк произвольной длины. Для Интернет-задач, которые в основном оперируют текстом, это вполне удобный инструмент. Интерпретатор языка был встроен в основной WWW-сервер систем класса Unix Apache. Однако PERL был изначально придуман не для Интернета, и отсюда вытекали все его недостатки, например, неудобства при организации доступа к базам данных. Да и в изучении он далеко не прост! Более разумной альтернативой является PHP (Personal Home Page). PHP придумали в 1994 году для расширения возможностей «домашней» страницы. Вначале он умел не очень много: понимал простейший язык и всего несколько макросов. Но по мере развития PHP превратился в интерпретатор мощного C-подобного языка, который встраивается в WWW-сервер Apache. Огромная часть Интернет-приложений под юниксовым семейством ОС создается на PHP. Существует он и под Windows, но особой популярностью здесь не пользуется. Для создания работоспособной версии вебсервера со встроенным PHP придется немного потрудиться. Вначале необходимо получить исходный текст WWW-сервера и PHP-интерпретатора. Затем установить библиотеки для работы с СУБД, которая вам необходима. Наконец, скомпилировать, связать это друг с другом и заняться редактированием настроечных файлов.
К недостаткам PHP (версии 3) относится снижение производительности на больших проектах, отсутствие поддержки сессий, малое число подключаемых модулей. Однако в настоящее время движок PHP переписывается, и версия 4 должна решить все эти проблемы.
ПРО КЛИЕНТА
Если серверные технологии развивались солидно и степенно, то на клиенте развернулась самая настоящая борьба за пользователя. Трудно поверить, но глава Microsoft Билл Гейтс не смог предугадать потенциал Интернета и долгое время его попросту игнорировал. Microsoft осознала свою ошибку, и в результате в настоящее время большинство пользователей «серфит» сеть с помощью браузера Microsoft Internet Explorer (самой распространенной версией является в настоящее время четвертая), а программисты клянут все на свете, так как разные браузеры несовместимы между собой. Приходится мириться с тем, что есть HTML от Microsoft и HTML от Netscape. При разработке Интернет-приложения, использующего «незаурядный» HTML, следует сразу определить круг потенциальных клиентов. К примеру, можно ориентировать свои разработки на определенную версию браузера. Если вы заглянете в HTML-код страниц крупных порталов, то почти всегда обнаружите там проверку версии браузера пользователя: разным браузерам «выдаются» разные ресурсы.
После широкого распространения браузера от Netscape недостатки первой версии HTML быстро стали очевидны. С некоторыми из них еще можно было мириться. К примеру, с тем, что сам текст и его оформление не были достаточно разумно отделены друг от друга, возможностей позиционирования и разукрашивания текста не хватало. HTML, однако, позволял только отображать информацию, требовалось же еще и получить данные от пользователя. В результате были придуманы формы, то есть стандартные элементы ввода данных. Строка ввода, список выбора, кнопки переключения — все это теперь можно было вставить в текст и получить введенные данные на сервере после того, как пользователь нажмет на кнопку отправки. Программистам, однако, этого оказалось маловато — клиент по-прежнему оставался «глупым». Перед тем как отправлять форму на сервер, не мешало бы проверить введенную информацию, чтобы отреагировать на возможную ошибку немедленно, а не после долгого ожидания ответа от сервера. И эта проблема была решена. Браузер «поумнел»: поя вилась возможность выполнять программы «внутри» документа, осуществлять доступ к его элементам и взаимодействовать с пользователем. Язык, на котором эти программы пишутся, назвали JavaScript (JScript у Microsoft).
Бурное развитие объектной модели документа позволило свободно манипулировать его содержимым, создавать «слои» и прочие украшения, но возможностей языка JavaScript все же не хватало. Несмотря на то, что он уже умел управлять одновременно несколькими окнами, в каждом из которых могло быть загружено несколько документов (фреймов), несмотря на возможность изменить внешний вид документа после его загрузки, несмотря на большое число событий, которые «выстреливал» браузер в ответ на действия пользователя (как-то: теребление мыши и стучание по клавишам), несмотря на все это, продолжал существовать ряд задач, которые не находили гладкого решения в этой среде. Например, графическое отображение динамически изменяющихся данных, а попросту говоря, графиков. При передаче пользователю картинки в виде графического образа (GIF или JPEG) сильно возрастала нагрузка на канал, особенно если требовалось мгновенно отображать меняющиеся во времени данные. Кроме того, график — это, вообще говоря, не статичная картинка. Его нужно уметь растянуть, перемасштабировать, изменить цвет элементов и пр. Microsoft, кстати, отлично понимала важность задачи обмена данными в реальном режиме времени и в свое время придумала для ее решения технологию DDE (Dynamic Data Exchange). С момента появления браузера Netscape существовала возможность создания так называемого плагина (plug in), то есть внешнего двоичного модуля, подключаемого к браузеру. Однако вопросы безопасности для подобных модулей вообще не были решены, да и надежностью эта технология не отличалась.
Вопрос «усиления» браузера стоял довольно остро: Интернет-технологии упрощали программирование большого класса задач, связанных с обработкой данных, и получали все большее распространение не только за счет расширения самой Сети, но и благодаря интранет-приложениям. Мелкие и крупные компании начали вне дрять в своих локальных сетях Интернет-технологии и обнаружили, что они ускоряют и удешевляют разработку и поддержку приложений. Их достоинства, помимо прочих, и в отсутствии необходимости обновлять клиентскую часть. Для крупного предприятия, которое постоянно совершенствует свою автоматизационную систему, это может явиться главным критерием выбора! Сразу оговорюсь, речь здесь идет о вполне определенном классе задач, решаемых при автоматизации бизнес-процессов предприятий.
Разработка и создание нового браузера — очень дорогая штука по деньгам и времени и сведет на нет всю экономию! Необходимо было расширить возможности существующих браузеров и дополнить их функции отображения HTML. В ответ на этот вызов были предложены сразу две технологии.
| Выбор Apache/PHP на платформе Unix и IIS/ASP/Windows можно считать разумным решением для создания серверной части Интернет-приложения. Несмотря на то, что проведенные исследования показывают, что Apache не самый быстрый вебсервер (хотя многие считают его таковым), это наиболее распространенный и относительно простой в установке пакет. Доступность его исходных текстов можно считать одним из плюсов. Всегда устанавливайте последнюю «стабильную» версию Apache. Если же вы выбираете IIS, не стоит торопиться в будущее вслед за Microsoft. Установите IIS версии 3.0 и последний сервис-пак для Windows NT (на момент написания статьи — 6a). Перед началом работы обязательно уделите время оптимизации вебсервера и скачайте все необходимые «заплаты» по безопасности. Для задач с внушительным объемом вычислений (генерация больших отчетов) следует использовать CGI-приложения или создавать встраиваемые в вебсервер компоненты (технология COM под Windows, расширение Apache дополнительными модулями). |
ПРО 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 Pentium, опять-таки не будет работать.
Поговорим дальше о размерах и принципах обновления версий ActiveX-элементов. ActiveX с минимальным функционалом займет минимум 200 Кбайт, если создавать его с помощью Delphi или набора готовых библиотек для C++ от Microsoft. Создавать с нуля подобное приложение можно долгие месяцы — спецификаций довольно много, и реализация их нетривиальна. И это при том, что любое, даже минимальное изменение программы вызовет повторную закачку новой версии ActiveX к пользователю. ActiveX-технология, к сожалению, не содержит возможностей структурирования приложений и разделения их на небольшие части. Более точно, разбиение возможно, но каждая из таких частей обязана быть полноценной ActiveX DLL, что сводит на нет все усилия по уменьшению размеров. Еще одна огромная технологическая проблема ActiveX — это обновление версий. При попытке загрузить новую версию ActiveX, после того как поработала старая, Internet Explorer выдает сообщение, потрясающее до глубины души. Он предлагает перезагрузить компьютер, указывая при этом на то, что «системные установки изменились»! На самом деле достаточно всего лишь перезапустить сам Explorer, но и это решение нельзя признать удачным с точки зрения комфорта для пользователя.
Рассмотрим теперь соображения безопасности. Даже если ActiveX будет работать у пользователя — захочет ли этого пользователь? Только безумец откроет доступ к своему компьютеру приложениям из Интернета, среди которых могут оказаться вирусы или не менее зловредные программы. Microsoft, осознавая этот факт, предложила сертифицировать ActiveX с помощью электронной подписи. Заплатите около трехсот долларов, получите сертификат, и дело в шляпе! Но что мешает мошенникам зарегистрировать фирму и сертифицировать свой «плохой» ActiveX-элемент? Сертификация всего лишь удостоверяет авторство ActiveX-элемента. Далее, надо понимать, что ActiveX создаются людьми, а те ошибаются. Порывшись в Интернете, вы легко найдете множество примеров того, как сертифицированные «чистые» ActiveX-элементы от таких грандов, как Microsoft или Adobe, содержат ошибки переполнения буфера. В настоящее время ActiveX-элементы используются в основном внутри интранет-сетей. Здесь проблемы больших размеров и безопасности решаются с других позиций. В Интернете эта технология получила рапространение в виде Flash-проигрывателя, который позволяет воспроизводить анимацию, сильно превосходящую стандартные возможности HTML.
ПРО «ЯВУ»
И все же — что делать, если мы не хотим подвергать свой компьютер опасности, но желаем выполнять на нем программы, достаточно мощные для отображения графики и управления вводом от пользо вателя? В 1995 году группа программистов, финансируемая фирмой Sun, выдвинула идею аппаратно-независимой «Ява»-платформы. Изначально этот проект создавался для управления бытовой техникой. Однако Интернет востребовал «Яву» гораздо сильнее. В основе «Явы» лежит идея полной кроссплатформности. Приложение на «Яве» отделяет от ОС и аппаратной части компьютера специальная среда, содержащая разветвленные библиотеки на все случаи жизни, называемая виртуальной «Ява»-машиной (JVM). Однако обычная интерпретация показалась авторам слишком медленным и неоптимизируемым в смысле размера кода процессом. В результате программа на «Яве» компилируется, но не в двоичные коды, исполняемые процессором определенной архитектуры, а в специальный компактный «Ява»-код, исполняемый «Ява»-машиной. Программист, знакомый с языком форт (forth) или PostScript, найдет похожие решения в «Ява»-машине. В ее основе «стековая» архитектура, все вычисления проводятся через стек операндов. «Ява»-код представляет собой набор команд, которые оперируют стеком или изменяют ход выполнения программы. «Яву» как систему программирования отличает отсутствие указателей (вместо них экземпляры класса), глобальных переменных, функций работы с памятью (автоматическая сборка мусора), строгая типизация, встроенная поддержка многозадачности, поддержка интерфейсов взамен множественного наследования. «Ява»-код, получаемый в результате компиляции, перед выполнением проверяется специальной программой (верификатором). Это означает, что вы не сможете выполнить «искусственно» созданный «Ява»-код, который исчерпает стек операндов или каким-либо еще способом нарушит работу «Ява»-машины. Кстати говоря, байт-код не обязательно должен получаться в результате компиляции «Ява»-программы! Существуют другие языки, которые можно использовать в этих целях.
| Современные браузеры (Communicator, Explorer) имеют «встроенную» «Ява»-машину и позволяют выполнять «безопасный» «Ява»-код. Вызовы отдельных методов при этом запрещены. К примеру, «Ява»-программы, выполняемые в браузере, не могут обратиться к файлам на диске. Основные проблемы, с которыми сталкивается программист при работе с «Явой», это неэффективное исполнение «Ява»-кода, неполная или неточная поддержка спецификаций стандартных классов, большая нагрузка на ресурсы компьютера, плохие алгоритмы сбора мусора и, как следствие, утечки памяти. Стандартная библиотека, окружающая «Ява»-программу, постоянно изменяется. Sun ведет большую работу, направленную на ее улучшение, но на практике это означает, что «Ява» бывает разной! Как правило, можно выделить «Яву» до версии 1.1, версию 1.1 (наиболее распространенную и встроенную в браузеры Netscape Communicator и Microsoft Explorer) и версию 1.2 (так называемая Java 2), поддержка которой в браузере возможна, но сопряжена с определенными трудностями (надо устанавливать дополнительный модуль). К тому же Microsoft приложила усилия для компрометации «Явы», создав на платформе Windows «Ява»-машину, не полностью соответствующую спецификациям от Sun. |
МНОГОЛИКИЕ МИРЫ «ЯВЫ»
Немного отвлечемся от рекламных проспектов Sun и обратимся к реальности. Для разработки «Ява»-приложений под Windows можно использовать как «родной» пакет Sun JDK, так и Microsoft Java SDK (свободно доступны на вебсерверах упомянутых фирм). Но если вы серьезный программист, то рекомендую вам поставить оба этих пакета и вот почему: компилятор Java SDK от Microsоft на порядок быстрее своего сановского собрата. При отладке больших программ вы оцените это преимущество очень быстро. В то же время конечную (final) компиляцию приложения в «Ява»-код следует все же поручить компилятору от Sun, так как он строго следует спецификациям.
Программа на «Яве», исполняемая браузером, называется апплетом («приложеньицем» в переводе Internet Explorer). Апплет обязан унаследовать специальный класс Applet и переопределить методы инициализации, отображения на экране и уничтожения. Апплет выполняется с учетом ограничений среды, обычно называемой «песочницей» (sandbox). Последняя запрещает апплету вызывать методы, которые считаются опасными с точки зрения воздействия на компьютер пользователя, например, обращаться к файлам на диске.
Действительно ли «Ява» безопасна? В теории — да, но ее реализации уязвимы! За продуктами 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) использует каналы передачи данных и снижает нагрузку на сервер. Он широко применяется в приложениях, где потеря одного-двух пакетов из, скажем, ста несущественна. Как ни странно, можно назвать много клиент-серверных приложений, которые прекрасно работают, «теряя» по ходу некоторую информацию. Это, к примеру, биржевые котировки, передаваемые клиенту. Потоковое вещание видео- или аудиоинформации также имеет смысл реализовать на UDP. Потеря нескольких кадров не является здесь большой проблемой (особенно это справедливо для аудиопотока, видеопоток обычно «связан» сильнее). Рассмотрим схему, при которой клиент отображает некоторую актуальную информацию, периодически опрашивая сервер через фиксированный интервал времени. Этот интервал достаточно мал (5–30 с), тогда как запрашиваемая информация обновляется не слишком часто (10–60 с). В своем запросе клиент передает момент времени, информацией до которого он обладает. Сервер отвечает, высылая ему всю новую информацию от запрошенного момента плюс этот самый момент, чтобы клиент мог прислать его в следующем запросе. Подобная схема с большой вероятностью гарантирует попадание нужной информации к клиенту за определенный период времени при не слишком высокой вероятности потери пакета. Используя методы теории вероятности, можно точно определить требуемые временные рамки запросов.
Сочетание данной схемы обновления, «Ява»-апплета и UDP кажется вам весьма удачным решением для отображения графиков и другой информации у клиента? Сядьте в кресло, дышите глубже: Microsoft Internet Explorer не позволяет анонимному «Ява»-апплету принимать UDP-пакеты, несмотря на cтандарты. Остается только догадываться о причинах подобного поведения. Возможно, это связано с распространившимися атаками на DNS-серверы (они часто используют UDP вместо TCP), официальная позиция Microsoft заключается в том, что это ошибка. Так или иначе, UDP вашему апплету не грозит, остается TCP. Как уже было сказано, установление TCP-соединения апплета с хостом, с которого он был загружен, разрешается, причем, по любому порту. На практике это означает, что на машине с вебсервером вам следует установить серверную часть приложения, которое будет обрабатывать запросы апплетов. Функционал такого приложения сильно напоминает функционал вебсевера: прослушивание порта, установление соединений, идентификация пользователей, обработка запросов, отправление ответов. Естественно, возникает вопрос, нельзя ли обойтись вебсервером для решения этих задач? Разумеется, можно! Протокол HTTP позволяет передавать и специальным образом организованную двоичную информацию. Более того, ничего не мешает воспользоваться для обработки запросов скриптами того же ASP. Существует, однако, два ограничения, которые могут попортить вам крови. Во-первых, даже если пользователь идентифицирован сервером, апплету об этом неизвестно. Он не может попросить браузер «добавить» к своим запросам данные логина и пароля. Во-вторых, если браузер работает через прокси, апплет не сможет с ним соединиться. У апплета есть права только на соединение со своим хостом. Таким образом, если ваш прокси имеет специальное назначение (например, шифрует трафик), апплет не сможет работать с вебсервером. Вообще говоря, эта проблема решаема. Можно создать редиректор, который «обманет» браузер и разрешит его апплету работать с прокси, но подобная программа заслуживает отдельного разговора!
Отличий «Ява»-машин, которые способны свести вас с ума, слава Гейтсу, немного. Ограничения UDP или отсутствие RMI можно обойти. Мелочей же, отравляющих жизнь, — не счесть! Запустите апплет, который просто отображает выпадающий список, в Explorer и Communicator и увидите разную картину — цвет фона списка там и здесь отличается. Добавьте полосу прокрутки (ScrollBar), и вы обнаружите, что Explorer версии 4 с «Ява»-машиной версии 1.1 под Windows 95 не умеет менять длину бегунка! Создайте объект Calendar, который служит для преобразования сочетания «день-месяц-год» в дату, и попробуйте отсчитать некоторое количество дней от начала века. В вышеупомянутой версии Explorer вы будете получать каждый раз разные даты! При этом в поздних версиях Microsoft Internet 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. Это может происходить, когда вы «кликаете» мышью на апплете, и вызывается сообщением о передаче фокуса. Причем на нормальной работе апплета это не отражается!
«Ява»-платформа была предложена программистам как средство, позволяющее сосредоточиться на сути проекта и сэкономить время. Наверное, лет через десять так оно и будет. Однако в настоящее время «Ява»-библиотеки все еще меняют свои очертания, а отличия в их реализации приводят к определенным трудностям. Будьте готовы засучить рукава! В крупных «Ява»-проектах программисты, как правило, вначале пишут свои собственные библиотеки, «обертывающие» стандартные, и используют в дальнейшем именно их и при создании визуального интерфейса, и для других задач. Все же, несмотря на недостатки, альтернативы «Ява»-платформе пока нет. Компактный «Ява»-код, наличие «Ява»-машин в браузерах последнего поколения, мощная среда разработки, встроенная многозадачность и наличие относительно простой оконной библиотеки позволяют разрабатывать довольно сложные апплеты, дополняющие возможности HTML.
| Выход в свет «Ява»-машины от Microsoft привел, как известно, к заявлению Sun о недопустимости использования в названии продукта высокого слова Java! Что же вызвало у Sun столь негативную реакцию? Насколько сильно отличается Ява-машина Microsoft от стандарта? Как ни странно, ничем особенным не отличается. Microsoft «всего лишь» подправила спецификацию Java, «заточив» ее под Windows. Она добавила некоторые новые классы и незначительно изменила реализацию отдельных методов. Из «Ява»-платформы в реализации от Microsoft пропал всего лишь один метод стандартной библиотеки (ByteArrayOutputStream. toString()), и тот без труда эмулируется двумя другими. Необходимо отметить, что Microsoft не стала поддерживать некоторые разработки, которые конкурировали с ее собственными технологиями (RMI, JNI, CORBA) и одновременно позволила из «Явы» вызывать некоторые API, специфичные для Windows (например, DirectX). Корень несовместимости «Ява»-машин лежит, к сожалению, не в документированных отличиях от стандарта. Увы, проблема в недокументированных «особенностях» поведения в одних и тех же условиях! Основная задача, которую ставила перед собой Microsoft, видимо, заключалась в дискредитации «Ява»-платформы как универсальной гетерогенной платформы разработки. |
ПЕРСПЕКТИВЫ
Поговорим о будущем Интернет-технологий. Все сказанное ниже является всего лишь моим личным (субъективным и предвзятым) мнением. В области «Явы» основной упор должен быть сделан на гибком наращивании «Ява»-библиотек у клиента. Сами «Ява»-машины рано или поздно станут быстрыми и надежными, а проблема отличия «Ява»-классов будет решена за счет введения версионности и глобальных идентификаторов классов (подобных тем, что применяются в COM). Библиотека классов более не будет монолитом, неотъемлемой частью «Ява»-машины. Появятся стандартные средства публикации «Ява»-классов, будут созданы серверы для накопления и обмена «Ява»-компонентами. Все это приведет к созданию «умной» сети взаимозависимых самоидентифицирующихся «Ява»-компонентов. Запуск нового класса на машине пользователя приведет к наращиванию его «Ява»-среды нужными составляющими. За счет разбиения задач на множество компактных библиотек подобное обновление не приведет к большим нагрузкам на каналы. «Ява»- среда пользователя фактически будет расти, формироваться в требуемом направлении согласно его запросам.
Подобный механизм невозможен без «доверительных отношений». Пользователи получат возможность заявлять о своей степени доверия к компонентам. Чем больше пользователей у компонента, тем более надежным он будет представляться. Сертификация компонентов будет, таким образом, проводиться децентрализованно всеми клиентами сети.
Язык XML не получит столь большого распространения и одобрения, как HTML со стороны независимых программистов, так как спецификации этого языка будут создаваться компьютерными грандами, каждый из которых «потянет одеяло» на себя. В отличие от HTML, реализация которого понятна без дополнительной информации, XML требует наличия парсера, который объясняет браузеру, что ему делать с этим XML. HTML спустя какое-то время опять получит развитие, на этот раз для более структурированного представления информации. Появятся «расширения» HTML, которые будут направлены на решение специализированных задач, таких как представление анимации или трехмерных моделей. Не исключено и создание HTML нового поколения, четко ориентированного на удобное и однозначное представление информации на экране. В этом HTML уже не будет тегов, которые структурируют документ. Только отображение информации с широким использованием стилей. Параллельно будет развиваться язык структурированного представления информации на клиенте, скорее всего, в иерархическом виде. Этот язык позволит определять произвольные структуры данных и их взаимосвязь, принципы синхронизации с сервером, схему событий при изменении данных и пр. Приложение у клиента будет состоять из нескольких независимых частей: структурированной информации, описания представления данных на экране, реализации событий.
Браузер от Microsoft будет все больше дополняться ненужными вещами и все более исполь зоваться самой Microsoft для своих приложений в качестве интерфейса пользователя. Explorer останется все таким же ненадежным и все еще будет отъедать память вашей машины. Новые версии будут выходить быстрее, чем обновления старых. Основная задача при этом — загромоздить экран как можно большим числом панелек с кнопочками, чтобы пользователь пошел покупать монитор с большей диагональю. На этот счет у Microsoft, я думаю, существует тайный сговор с производителями мониторов, памяти, процессоров и пр. Альтернативных браузеров появится много, все они будут отличаться друг от друга, так что у пользователя будет стоять на компьютере 5–10 различных экземпляров. Каждый из них будет иметь неоспоримые преимущества перед другими (в скорости, размере, стоимости, количестве наворотов и пр.) и реализовывать «свое» расширение HTML (см. выше), так что все они будут необходимы.
Microsoft, выиграв раунд в борьбе за Интернет-клиента, попробует подмять под себя Интернет-технологии на сервере. Называться это будет Windows.NET (хорошее название для русского прочтения). Через какое-то время вы с удивлением обнаружите, что помимо старого доброго HTTP ваш Интернет-провайдер предлагает вам новый протокол MSRULEZ, который гораздо быстрее и полнее предоставляет информацию из Интернета. Вы можете получать ее и на компьютер, и на мобильник, и на настольную лампу. Все это удобно и быстро. Одна проблема: телефон и лампа должны быть «Microsoft compatible», а на компьютере должно стоять что? Правильно, Windows Next Generation. Поставив себе новую версию Windows, вы постепенно откажетесь от HTTP и начнете наслаждаться MSRULEZ, так как он удобнее (не забывая при этом периодически чертыхаться при глюках системы). Не беда, что данный протокол поддерживает только новый браузер от Microsoft и только под Windows. Все равно вы других ОС и не видели. Через какое-то время вы обнаружите, что ошибки исправлять бесплатно никто и не собирался, а денег платить приходится немало. Но все равно не вернетесь к HTTP, так как Microsoft выпустит заплатку x4274N35, которая исправит 90% ошибок и добавит еще 15% новых.
Необходимо все же отметить, что победить весь Интернет Microsoft не сможет. Скорее всего, борьба пойдет за интранет-технологии (довольно прибыльные, надо сказать). Появится новая версия корпоративной Windows, которая изначально будет обладать широким спектром возможностей. Как то: последняя версия браузера, наличие мощной скриптовой машины и вебсервера, компонентов «Офиса» (а то и весь «Офис» целиком), а также поддержка большого количества сетевых сервисов от Microsoft, которые работают только под управлением Windows. Не исключен и сервер БД. Такая ОС со встроенным софтом, готовым к работе без дополнительных усилий, получит рас пространение и пошатнет позиции Unix. Все это поведет к росту недоверия к программным продуктам, так как надежность этой новой ОС будет обратно пропорциональна «мощности» заготовленного ПО. Основная проблема Microsoft — совместимость с предыдущими версиями. Подобная задача не стоит (пока) перед создателями BeOS. Эта ОС постепенно получит распространение в Интернете и интранете за счет «гладкой» установки рядом с Windows. Самый лучший способ ее популяризации — выпуск Quake IV или War Craft III только под BeOS, но этого, увы, не произойдет. Позиции Linux будут укрепляться, рано или поздно эта ОС получит мощную, современную 64-битную файловую систему, поддержку многопроцессорности и большого количества оперативной памяти, но серьезно конкурировать с той же Solaris не сможет. Все из-за «любительского» ореола вокруг ее создателей и отсутствия четкой линии развития.
ИТОГИ
Интернет-технологии — это еще одна ступень развития компьютерных систем. Время показало, что правильное применение этих технологий позволяет повысить эффективность труда программистов и сократить время разработки информационных систем. В то же время Интернет-технологии — это не «серебряная пуля». Без грамотного проектирования и труда квалифицированного персонала решение проблем автоматизации невозможно.
