Интернет-операционные системы

ИГОРЬ ТЕТЕРИН

Интернет-операционные системы

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

Что такое «Интернет-операционная система»?

Интернет-операционная система (ИОС, либо более понятное название WebOS) – программный продукт, предоставляющий некий сервис для программ более высокого уровня, которые, в свою очередь, основываются на этом сервисе. ИОС принципиально ставит перед собой задачу – облегчить труд программиста, а значит, сэкономить, структуризировать, разбить задачи создателя сайта на более мелкие и иметь более четкое и безопасное решение для своего интернет-проекта. Возможно, вы привыкли к обычному пониманию фразы – операционная система. В голове сразу начинают появляться слова Windows, DOS, Linux... На самом деле операционная система – это всего лишь программа, предоставляющая интерфейс для работы остальных программ, суть этого интерфейса в стандартизации, едином синтаксисе написания программ, единых стандартов и т. п. А так как мы рассматриваем ИОС или WebOS, то, соответственно, ограничиваем себя следующими задачами: предоставить некий интерфейс для работы с интернет-сайтами (в случае WebOS) или с некоторым комплексом процессов интернет-сервисов (в случае ИОС). В чем разница? Разница лишь в том, что ИОС должна решать значительно больше задач. Мы хоть и рассматриваем именно ИОС, но нас интересует ограниченное направление. Позже мы коснемся темы микро-ИОС. Вам пока лишь стоит понять, что мы будем рассматривать сайты, имеющие широкий спектр возможностей, а позже касаясь микро-ИОС, коснемся ограниченных возможностей.

Движки сайтов

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

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

Сравнение ИОС и движков

Давайте попробуем сравнить ИОС и движки. В чем разница? Так как на свете нет бесплатных ИОС, то понимание разницы должно заставить вас понять и то, насколько необходима ИОС вообще. Принципиальная разница в назначении этих двух вещей и уровне программирования/реализации. Давайте вспомним, что же такое ИОС и что такое движок и для начала определим сходства. Они имеют примерно одинаковый уровень программирования, но только примерно, они оба начинают работать по запросу клиента. Можно даже запутаться. Тут тоже может возникнуть подозрение, что в принципе некоторые задачи могут быть одинаковыми. Дело в том, что в идеале обработка запроса сайтом происходит по следующей упрощенной цепочке:

1. сервер (Apache)

2. Perl

3. ОС

4. движок

3. ОС

2. Perl

1. сервер (Apache)

Тут мы схематично можем представить, где находится ИОС. Другими словами, движок строится на веб-операционной системе, которая построена на Perl, Си, Python или, на худой конец, на PHP. Как и любой программе, движку предоставляется выбор: либо использовать функции ОС, либо писать, используя только язык программирования. А ИОС предоставляет этот выбор. Создает некоторую выгоду использования себя.

Схема построения сайтов при помощи ИОС и движков

Давайте рассмотрим детальнее, как будет выглядеть обычная обработка запроса. Клиент вводит URL в браузере. Запрос посылается на указанный IP, где управление получает сервер, для примера пусть это будет Apache, который ищет страницу по умолчанию index.html (для примера). В странице оказываются SSI-ссылки на выполнение скрипта, пусть это будут новости. Apache запускает интерпретатор (я все привожу в очень простой форме) и передает параметр (имя скрипта и возможные параметры для скрипта). Следующим шагом интерпретатор запускает скрипт и передает ему параметры.

Далее мы рассмотрим 2 варианта: с ИОС и без нее.

Без ИОС. Скрипт читает файл с новостями, файл с шаблоном, параметрами, возможно, эти операции разделяются (а, возможно, работа происходит через SQL), в общем итоге составляется код HTML, который передается в stdout.

C ИОС управление получает скрипт ОС, который подгружает необходимую минимальную базу модулей, проделывает базовые операции: форматирует входящие параметры, устанавливает обработчик ошибок, устанавливается кешеризатор вывода. Затем управление передается нужному скрипту движка, который вызывает функции чтения и указывает, что читать (шаблон5, 20 последних новостей). В общем итоге получается HTML, который отправляется якобы в stdout. Ядро собирает заголовки, отправляет, что получилось у движка, и в случае наличия ошибок, могут быть отправлены данные и об этом. При наличии серьезных ошибок вызывается некое событие.

В общем, вот простой пример, как происходит совместная работа, и в чем разница между отсутствием и присутствием ИОС.

Функциональное наполнение ИОС

Из рассмотренной схемы мы уже начинаем представлять, что собственно должна делать ИОС. Давайте слегка пройдемся по функциям:

• Перехват, обработка ввода/вывода, возможность управления этими процессами из движка (кеширование как один из видов обработки).
• Обработка ошибок, предупреждений, исключений, максимум прозрачности для движка.
• Функции СУБД. При отсутствии SQL должна быть альтернатива, предоставляющая способ работы с данными, избегая при этом работы с файловой системой.
• Некоторые функции безопасности. Фильтры, конверторы.
• Независимая от платформы база пользователей и удобный, гибкий интерфейс к ней.
• Универсальная система логирования.
• Система работы, создания и обработки событий и другие не менее значимые функции.

Зависимости

Давайте взглянем на примитивную схему ИОС: ИОС представляет собой несколько модулей. Будем исходить из того, что ОС написана на Perl. У ИОС не должно быть как такового ядра. Программист движка будет сам выбирать, что ему нужно. Отсюда каждая часть ИОС должна быть максимально независимой. Это действительно должно быть так, но связей и зависимостей не избежать. Обязательные зависимости должны быть решены жестко, подключением необходимых модулей, а остальные связи должны общаться через единую систему взаимодействия. Эта система обязательна для всех модулей. Я бы назвал ее системой событий. Именно события придают гибкость и возможность взаимодействия самых разных уровней решения задач.

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

Вопрос о способе вызова скриптов и взаимосвязь с ИОС

На мой взгляд, на свете существует две модели вызова скриптов, и они обе имеют достаточно оснований быть первыми.

Эти две модели можно наблюдать в Perl и PHP. Perl не предоставляет функций включения кода в HTML, хотя это и несложно реализовать. PHP принципиально позволяет делать это.

Какой способ лучше? На мой взгляд, возможность встраивания кода в HTML лишняя, хотя и удобная. В чем недостатки такого метода?

• Лишние проблемы с безопасностью.
• Размазывание границы между версткой и программированием.

Почему я поднял вообще этот вопрос? Потому что это важно для ИОС. Важно это в том плане, что ИОС должна гарантировать безопасность со своей стороны, и предоставлять базовый интерфейс для работы с контентом, а без продуманной системы могут возникнуть какие-либо ограничения. Ограничения – очень нехорошая штука. Я все же не даю конкретных решений, а всего лишь рекомендую строить свою систему на базе подключения внешних скриптов.

Перспективы ИОС

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

Некоторые принципы ИОС

По ходу были указаны некоторые принципы ИОС, давайте еще раз взглянем на них:

• бесплатный продукт;
• открытый код;
• платформонезависимость;
• компактность;
• отсутствие ограничений;
• принцип выбора, а не навязывания.

Микро-WebOS

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

ret WebOS проект

ret WebOS – это микро-операционная система для WEB, основанная на Perl. Бесплатный, открытый проект, сочетающий в себе некоторые принципы ИОС.

ret рассчитан на бесплатные хостинги и некрупные проекты, хотя это относится лишь к некоторым частям ОС. Итак, что представляет из себя ret? Несколько компактных модулей, отвечающих за конкретные задачи:

• cru.pm – модуль, отвечающий за преобразование данных (фильтры, хеши, подсветки и др.);
• data.pm – собственная микро-СУБД;
• err.pm – модуль, перехватывающий и обрабатывающий ошибки, предупреждения и др.;
• logs.pm – система ведения логов и обработка событий;
• rights.pm – система ведения прав (интересно то, что в данной системе нет стандартных пользователей типа root, которым дозволено все);
• wim.pm – модуль, обрабатывающий входящие данные, в том числе и приходящие файлы.

Каждый модуль самостоятелен, кроме модуля rights.pm, который зависит от СУБД. Программист волен подключать только то, что ему будет по душе. Чем интересен данный проект? Во-первых, основным принципом: код ret не должен превышать 50 Кб. СУБД ret предоставляет простые функции (например GetRec, Put), но внутренняя сложность структуры данных зависит только от фантазии программиста.

Очень интересная вещь – события. Изначальных событий в код не встроено. Но создана база для того, чтобы можно было очень просто добавлять собственные события. Для примера у вас есть свой скрипт, читающий новости. Его вы вызываете из скрипта, который показывает новости. Последний получает новости в отформатированном виде посредством события обработки текста новостей из первого, который явно вызывает это событие, определенное в logs.pm.

В чем заслуга такой системы? Заслуга в том, что модуль logs просто коллекционирует все события, создавая некий стандарт описания событий.

Система прав построена достаточно интересно. Существуют шаблоны и собственно сами пользователи, весь интерес в том, как накладываются шаблоны на права пользователей, и какие преимущества это дает.

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

С точки зрения ret событие описывается следующим образом: a:b:c, где a – виновник события, b – тип события, c – детализация; но правильно описанным событием будет считаться и событие, описанное, например, так: jhskdjhkajsdh. Конечно, смысла в этих символах нет, но если событие с таким именем описано, то оно произойдет. Поэтому хотелось бы подчеркнуть, что ret предоставляет некую базу, на основе которой можно строить логику движка.

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