Проведенный автором анализ самых разных информационных источников показал, что популярность термина intranet определенности ему не добавила… Более того, ценовой диапазон имеющихся коммерческих программных продуктов, попадающих по тем или иным причинам в категорию intranetware (не путайте с названием ОС от Novell — существуют же software и hardware), вообще заставляет задаться вопросом: а так ли хороша и выгодна информационная технология, воплощенная в корпоративных календарях-планировщиках и записных книжках стоимостью от $200 до $2000 для одного пользователя? Вероятнее всего, подобная "тяжеловесная" ценовая политика в сочетании с некоторой неопределенностью в терминах и пугающим наследованием сложности Internet-решений и приводят к сложившейся сегодня ситуации: об intranet говорят много и многие, но никто не видит реально работающих intranet-систем.
Так вот ты какая, intranet
Точное определение intranet найти очень трудно — в лучшем случае большинство авторов ограничивается чем-то вроде "Internet в локальной сети" или просто "локальная Internet". Подобные "дефиниции" ясности, увы, не добавляют из-за отсутствия четкой формулировки цели: даже если вы знаете до мельчайших подробностей, что такое Internet (например, вы — маститый администратор серверов крупнейшего провайдера Internet), ответа на вопрос, зачем все это нужно в локальных масштабах одной организации, из такого определения intranet вы не получите (варианты "модно" и "перспективно" по очевидным причинам бессодержательности не принимаются).
Прежде чем формализовать предмет нашего обсуждения, рассмотрим пару очень важных примеров из реальной жизни, не отрываясь от современной украинской действительности (да простят меня читатели, но по ряду причин наименования программных продуктов и юридических лиц не приводятся).
Итак, в одной из небольших фирм возникла проблема с надежностью функционирования компьютеризованных систем товарооборота и бухгалтерского учета, созданных с помощью популярного специализированного программного продукта X. Претензии пользователей и администратора системы основаны на объективных показателях (потеря записей и регулярные сбои с частичной утратой всей базы данных), однако формулируются "потерпевшими" в весьма субъективной форме с интенсивным использованием ненормативной лексики. Единственное возможное предположение о причине возникновения "неполадок" — присущая продукту X "архитектурная кривизна": клиент-серверная архитектура с удивительной для этой идеологии необходимостью обработки локальных клиентских копий базы данных (БД). Естественно, что за два-три года эксплуатации размер БД фирмы достиг пусть не гигантских, но весьма внушительных размеров — отсюда и дополнительные проблемы с производительностью локальной сети… Все возможности "подлечить" существующую систему администратором уже исчерпаны и к полной "реанимации больного" не привели. В конце концов, отчаявшись от всей этой кутерьмы, фирма принимает решение полностью перестроить систему, используя "человеческий" клиент-серверный пакет на основе СУБД (Система Управления Базами Данных)… корпоративного класса. Соображения здесь просты: такие СУБД очень надежны (классовая принадлежность требует), да и для выбранной СУБД есть отечественные разработки клиентских программ, которые вполне подходят для решения стоящих перед фирмой задач (правда, требуя модификации).
Второй пример куда менее тривиален — высшее учебное заведение, осчастливленное в незапамятные времена бюджетного финансирования электронным микроскопом и уже сравнительно недавно "компьютеризованное" (пара десятков 486-х ПК в локальной сети учебного класса), второй год пытается создать клиент-серверную систему дистанционного управления микроскопом и отображения "картинок" на всех ПК. Задача оказалась нестандартной — микроскоп достаточно старый (не в смысле технических показателей — просто не "компьютеро-ориентированный"), биологический профиль учебного заведения не способствует бурному развитию "программизма" среди студентов, и, наконец, — финансовое положение вуза исключает возможность оплаты подобной дорогостоящей услуги сторонним разработчикам.
Двух таких разных примеров вполне достаточно для… точного определения intranet. Общее в них — клиент-серверная архитектура (КСА). Общими являются и сложности, свойственные этой архитектуре (массовое отрезвление IT-специалистов относительно истинных возможностей и ограничений КСА наступило на рубеже 1995—96 гг. — именно тогда стал ясен фактический провал масштабных клиент-серверных проектов).
Главные слабости КСА — отсутствие формального представления данных в процессе обмена между клиентом и сервером (больше того, допустимо говорить о потенциальной невозможности этой формализации, слишком разнообразны данные "реального мира") и необходимость разработки множества сложных клиентских программ в соответствии с постоянно растущим множеством информационных потребностей пользователей.
Эти две присущие КСА "болячки" настолько серьезны, что буквально навязывают осознание необходимости введения и строгого соблюдения ряда существенных ограничений: минимальное количество несложных и точно определенных протоколов взаимодействия между клиентом и сервером, повсеместное использование простого, функционального и стандартного языка описания данных и взаимосвязей между данными. Развивавшаяся параллельно с "обычными" клиент-серверными системами Internet сформировала пусть очень компактный, но и в такой же мере жизнеспособный набор стандартов-ограничений: протоколы HTTP, FTP и представление данных в формате HTML, при этом критерии проектирования "трех составных частей" Internet значительно отличались от аналогичных в КСА-проектировании (универсальность против "задачеориентированности", "всеплатформенность" против эффективности, гарантирование приемлемых показателей качества функционирования в условиях низкой пропускной способности каналов связи против исходной посылки о "достаточной пропускной способности").
Вот теперь пора и привести долгожданное определение: intranet — это "локальная" информационная система клиент-серверной архитектуры, созданная с учетом ряда строгих ограничений (протоколы обмена — HTTP и FTP, основная форма представления информации — HTML). "Локальность" подразумевает высокую пропускную способность каналов связи (например, 10/100/1000 Mbps) между клиентом и сервером, а строгость ограничений — использование как стандартных серверов и клиентов (HTTP-сервер и броузер), так и стандартных механизмов расширения возможностей системы, например CGI и его модификации (FastCGI).
Мифы об intranet
Их существует бесконечное множество — от грандиозной идеи "интернетизации всего" (без учета соответствия возможностей технологии и требований реальных систем) до не менее великой идеи "ганьба!" (сторонники которой склонны выражать свое возмущение в приблизительно такой форме: "Это что же, в броузере таблички заполнять?"). Среди подобного многообразия заблуждений наблюдается ряд вопросов, которые автор не вправе оставить без ответов…
Миф первый: "intranet — значит дешево". Мягко говоря, это не совсем так: все зависит от масштабов интра-сети, используемого программного обеспечения (типичный пример "недорогой" интра-системы — сервер Netscape Enterprise и СУБД Oracle для сети с сотней-другой клиентов). Есть еще один аспект "недешевизны" intranet — требование к высокой квалификации обслуживающего персонала и группы разработчиков (что, естественно, вынуждает повышать затраты на их содержание).
Миф второй: "intranet пригодна только для внутрикорпоративного распространения справочной и оперативной информации". Эта точка зрения отражает миграцию опытных Internet-разработчиков и администраторов в "интра-сферу", а ведь "узкий специалист подобен флюсу — полнота его односторонняя".
Миф третий: "intranet-решения не соответствуют высоким требованиям к конфиденциальности и защищенности данных". На самом деле можно построить "непробиваемые" (по крайней мере — снаружи) интра-системы без особо ощутимых затрат.
Миф четвертый: "intranet — это технология для корпораций". А ведь именно на корпоративном уровне любая информационная система — это большая головная боль. Намного проще обстоит дело в сетях меньшего масштаба, и именно здесь интра-системы способны проявиться "во всей красе".
Проектирование интра-сети
"Вживление" новой технологии в уже существующую информационную систему — дело непростое и, по большому счету, неблагодарное. На этом тернистом пути "новатор" сталкивается с противодействием как рядового персонала (надо переучиваться — а кто это любит?), так и со стороны руководства (новые затраты, естественно, руководством одобряются вяло). Интра-сети позволяют несколько ослабить этот эффект "всестороннего давления", но — при правильном подходе к проектированию.
Итак, вы решили создать интра-сеть на основе уже имеющейся локальной сети. В зависимости от ставящихся вами задач для этого может понадобиться один или группа серверов (имеется в виду "железо") и достаточно большой перечень программного обеспечения. Начнем с самого главного — системного ПО, ведь именно оно определяет требования к hardware и потенциальные возможности вашего "детища". Здесь выбор несколько ограничен — сразу отбросим экзотические и "настольные" операционные системы (Apple MacOS, Windows 95/98). Остаются Windows NT, Sun Solaris, HP UX, бесплатные Unix-подобные ОС. Если вам необходимы удобства администрирования Windows NT, то при ориентации на эту платформу смиритесь с повышенными расходами на "железо".
Жестко "привязанные" к своим аппаратным платформам (в первую очередь, дорогостоящим RISC) ОС следует выбирать только в случае больших масштабов уже имеющейся локальной сети, хотя возможны решения (о них ниже), позволяющие обойтись несколькими куда менее дорогими серверами x86. Теперь множество претендентов сократилось до минимума: Solaris или freeware ОС (Linux/Free/Net/OpenBSD). Наиболее оптимальным выбором можно считать Solaris, но пока эта система весьма дорогостоящая и (по этой очевидной причине) у нас малораспространенная, что может повлечь за собой ряд сложностей в ее эксплуатации (если Sun со временем "освободит" x86-версии Solaris, что, к слову, вполне возможно, переход на нее с "бесплатных" Unix-совместимых ОС не составит большого труда).
Дальнейший выбор — дело ваших личных пристрастий: все freeware-ОС из приведенного выше перечня очень надежны и прекрасно справятся с возложенными на них функциями.
Теперь пора определиться с перечнем информационных услуг, предоставляемых вашим интра-сервером. Intranet-технология позволяет очень многое, включая внутреннюю видео/аудиотрансляцию, доступ к файлам и базам данных, мощным расчетным задачам и даже к экзотическим аппаратным средствам — вспомните упомянутый вначале электронный микроскоп. "Недобор" в формируемом перечне даже хуже, чем "перебор", — по крайней мере, интра-сервер, спроектированный "с запасом", всегда можно нагрузить рядом дополнительных задач. В противном случае вам грозит увлекательный, продолжительный и дорогостоящий процесс модернизаций.
Результатом такого "концептуального проектирования" является искомый перечень информационных услуг, позволяющий обоснованно сформулировать требования к "железу".
Основные ориентиры для "проектировщиков": специфические для интра-сетей серверы (HTTP и FTP) не слишком ресурсоемки в отношении процессорного времени, но очень "любят" производительные шины для сетевых интерфейсов и контроллеров дисков, качественные и хорошо поддержанные контроллеры (для их выбора тщательно изучите документацию по ОС и не постесняйтесь задать вопросы о функционировании понравившихся вам вариантов в соответствующие конференции Internet и fido — несколько дней, проведенных в ожидании ответов, сэкономят кучу времени и избавят вас от головной боли).
После интенсивной концептуальной подготовки с выбором "железа" особенных проблем возникнуть не должно. Единственный вопрос, достойный отдельного обсуждения, — перспективность многопроцессорных SMP-серверов. С одной стороны, SMP достаточно неплохо поддерживается основными Unix-подобными ОС (Linux и FreeBSD), с другой — SMP-серверы весьма дороги. Существует хорошее неформальное правило, подтвержденное опытом эксплуатации серверов на платформе x86, — "лучше два недорогих однопроцессорных сервера, чем один дорогой — двухпроцессорный".
Наконец мы добрались до одного из самых важных элементов интра-сервера — программных реализаций HTTP/FTP-серверов (демонов в Unix-терминологии). Хочу вас разочаровать — столь популярный в Internet HTTP-сервер Apache может оказаться неоптимальным в интра-сети. То, что вам действительно нужно, зависит от задач, стоящих перед интра-системой, а для обеспечения высоких показателей существует обширный перечень бесплатных HTTP-демонов (HTTPD). Какой именно из них выбрать — вопрос непростой, но… Все http-серверы предназначены для выполнения минимума функций: обязательного приема запроса от клиента, возможного запуска CGI-приложения и обязательного возврата требуемого в запросе файла (результата выполнения CGI-приложения/сообщения об ошибке) клиенту. Важнейший критерий, по которому можно сравнить различные HTTPD — количество обрабатываемых запросов в секунду (hits per second, hps), является комплексным показателем и определяется множеством факторов. Нас интересуют, в первую очередь, характер изменения hps для конкретного HTTPD в зависимости от количества обслуживаемых клиентов и размеров файлов. Подобное исследование не слишком сложно, но его результаты очень информативны: если в перечне услуг вашего интра-сервера есть, например, видеотрансляция, то, очевидно, требуется сервер, способный обеспечивать большое значение hps для больших файлов, для обычной справочной системы оптимальным будет HTTPD с высоким hps для малых файлов, и, наконец, для доступа к ресурсам базы данных необходим HTTPD с очень высоким hps для CGI-вызовов. Рассмотрение всех существующих реализаций HTTPD, пригодных для интра-систем, — предмет пусть простого, но дорогостоящего исследования, однако есть ряд соображений, позволяющих сократить множество претендентов на "HTTPD-трон" вашего сервера до обозримого минимума. Увы, здесь придется сделать два, достаточно сложных для понимания, но очень важных отступления, связанных со спецификой Unix-систем.
Во всех без исключения Unix присутствует демон с именем inetd, так называемый "суперсервер интернет". Несмотря на такое "страшное" название, inetd выполняет достаточно простую функцию: он "наводит порядок" в мешанине демонов многофункциональных (точнее — многосервисных) серверов. На человеческом языке это можно пояснить приблизительно так: inetd "слушает" TCP/IP и при поступлении запроса проверяет, какой сервис запрашивается, затем вызывает соответствующую этому сервису программу-демон, после окончания выполнения которой опять продолжает "мониторинг" TCP/IP.
В принципе, inetd — очень удобный и удачный механизм, но… Во-первых, он достаточно медленный (не по человеческим меркам, конечно же), во-вторых — потенциально опасный с точки зрения "непробиваемости". Если со вторым недостатком в интра-сетях можно мириться (в конце концов, существуют и усовершенствованный xinetd, в котором основные "бреши" устранены, и грамотные администраторы), то потери скорости на услуги "суперсервера" в intranet-приложениях могут оказаться весьма неприятными. Поэтому в intranet-сервере целесообразнее всего вообще не пользоваться inetd (или его вариациями), что исключает перспективность ряда HTTPD, специально разработанных для запуска их "суперсервером" (существуют и такие…).
Второй важный момент буквально обязывает нас "зарыться" в глубины Unix, хотя страшного и здесь ничего не будет. Речь идет о внутренних механизмах (или идеологии) построения HTTPD. Разнообразием выбора в этом случае поразить воображение трудно: конкретный HTTPD может соответствовать классической fork-, более современной thread- или совсем "модерной" select-идеологиям.
Fork-идеология предусматривает запуск полной копии HTTPD-процесса для каждого нового запроса (что очень просто реализуется в Unix). Такой подход хорош всем, кроме производительности: порождение нового процесса — весьма ресурсоемкая и медленная задача. В ходе эволюции HTTPD сформировалась некая "мутация" fork-идеологии, называемая pre-fork: HTTPD создает множество порожденных процессов, и поступающий запрос обрабатывается одной из незанятых в данный момент копий. Именно на pre-fork-идеологии основан самый популярный HTTP-сервер Apache. К достоинствам pre-fork-"мутации" следует отнести высокую производительность (в 2—10 раз большую, чем для чистой fork-модели), к недостаткам — столь же высокую сложность реализации (особенно в части синхронизации как процессов-копий HTTPD, так и операций ввода/вывода).
Более современная thread-идеология отлично подходит для воплощения на таких платформах, как Windows NT или (даже в большей мере) BeOS. Создание thread (нити, или "тонкого" процесса) — значительно менее ресурсоемкая по сравнению с fork задача, соответственно, HTTPD, основанные на thread-идеологии, ощутимо быстрее своих fork- и pre-fork-собратьев. Единственное "но" — отсутствие стандартов на thread-модель с вытекающей отсюда низкой мобильностью реализаций. Хотя отчаиваться не стоит — существуют замечательные thread HTTP, прекрасно работающие на всех Unix и в Windows NT.
Гарантирующая самое высокое быстродействие select-идеология доступна, увы, только для реализаций HTTPD на Unix-платформе. Удивительным фактом является то, что основа основ этой идеологии оставалась незаметной для разработчиков HTTP-серверов столь длительное время: системный вызов select известен Unix-программистам хороший десяток лет. Особо не вдаваясь в "дебри" select, опять же "по-человечески" можно кратко рассказать о нем так: select "перекладывает на плечи" ОС всю черновую работу по синхронизации множественных операций ввода/вывода. Нам же важно, что отличает select-HTTPD от остальных: во-первых, select-серверы используют один-единственный процесс, во-вторых (следствие во-первых), обладают самой высокой скоростью, в-третьих, позволяют реализовать недоступные для остальных HTTPD функции. В дополнение следует заметить, что select-серверы характеризуются минимальными размерами простого и понятного кода и очень неприхотливы в отношении используемой оперативной памяти.
Из перечня "симпатичных" для интра-приложений и доступных (легально бесплатных) HTTPD можно особо выделить следующие реализации: Xitami (www.imatix.com) и thttpd (https://www.acme.com/software/thttpd/). Оба этих сервера относятся к "современным" категориям (Xitami — один из лучших представителей thread-, thttpd — select-идеологий), поэтому они в несколько раз производительнее Apache, что подтверждается результатами тестирований и опытом эксплуатации (сомневающиеся в этом могут посетить страничку benchmarks.html на сайте thttpd и даже провести собственные исследования с помощью утилиты http_load https://www.acme.com/software/http_load/). По крайней мере, проведенные автором эксперименты с серверами thttpd/Xitami и утилитой http_load полностью подтвердили очень высокие показатели производительности: на тестовой машине (процессор — Celeron 400 MHz, ОЗУ — 64 MB) под управлением FreeBSD 2.2.8 thttpd "обогнал" Apache по показателю hps в 4,5 раза. Xitami также оказался впереди, продемонстрировав трехкратное превосходство в hps перед Apache. К дополнительным достоинствам этих HTTPD можно причислить компактность кода реализации (соответственно, и высокую надежность), простоту администрирования, а также достаточную для интра-приложений "непробиваемость".
Окончательно определиться с выбором HTTPD (Xitami или thttpd) поможет простое правило: если вы планируете предоставлять в интра-сети как HTTP-, так и FTP-сервисы, — выбирайте Xitami (этот сервер гибридный, т. е. объединяющий HTTP- и FTP-демоны). В противном случае остановитесь на thttpd — его уникальные возможности по управляемому ограничению скорости выдачи файлов разного типа (throttling) существенно улучшат показатели вашей интра-сети, особенно в случаях передачи больших файлов. Интересны и комбинации "настроек" Unix-thttpd, открывающие новые возможности по снижению требований к пропускной способности локальной сети: например, разделением сети на сегменты средствами маршрутизации Unix, дополненным ограничением скорости передачи бинарных файлов (jpg, gif, pdf,…), можно значительно (в несколько раз) увеличить число одновременно работающих в интра-сети пользователей.
А дальше что?
Ну хорошо, определились мы с сервером и системным "интранетовым" ПО. Что со всем этим делать дальше? Естественно, для достижения простых целей (например, распространение справочной информации, хранящейся в множестве html-файлов) проделанной работы почти достаточно — остается только организовать требуемый каталог в файловой системе (или дерево каталогов) и заготовить. Однако затрачивать столько труда на подобную "систему", честно говоря, — мартышкин труд. Реальные интра-приложения нуждаются в специальных программах. Существует ряд доступных комплексных открытых "оболочек" для создания интра-систем, но для начала стоит ознакомиться с общими принципами построения таких задач.
Основа основ интра-приложений — интерфейсы между задачами и HTTP-сервером. Сложного в них ничего нет, а возможности выбора очень ограничены: существует один стандарт — CGI, удачная вариация этого стандарта — FastCGI и ряд нестандартных, специфичных для конкретного HTTP-сервера программных механизмов, направленных на повышение скорости выполнения (точнее — запуска) "псевдо-CGI"-задач. Кратко CGI-программу можно охарактеризовать так: это относительно независимая задача, запускаемая HTTP-сервером при получении соответствующего запроса, возвращающая серверу результат своего выполнения (обычно HTML-страницу) и прекращающая свое существование как исполняемый процесс после этого перечня действий. О высокой ресурсоемкости порождения новых процессов уже говорилось, и именно для ускорения запуска CGI-программ и предназначены нестандартные вариации интерфейсов: так, FastCGI по сути аналогичен pre-fork-"мутации" HTTPD: CGI-программы постоянно находятся в оперативной памяти и ждут поступающих запросов, что может повысить быстродействие интра-системы на порядок.
Рекомендованные в этой статье HTTPD Xitami и thttpd поддерживают, естественно, стандартный CGI (Common Gateway Interface), а Xitami "знает" еще два очень быстрых механизма: FastCGI и собственный уникальный WSX. Столь любимый автором thttpd очень легко "доводится руками" до поддержки FastCGI (что занимает один-два дня и требует хороших знаний Internet-протоколов и Unix API). Перечень инструментальных средств для создания CGI-программ огромен, и подавляющее большинство популярных инструментов ориентированы на Unix-платформы (это не удивительно, ведь Internet и Unix — "близнецы-братья"). Однако существуют две основные категории, позволяющие сделать правильный выбор для интра-приложений.
Первая обширная категория — интерпретирующие средства — включает в себя разнообразные языки программирования (например, Perl, Python и, по большому счету, PHP). К достоинствам интерпретирующих средств можно отнести высокую насыщенность специализированными для Inter/intranet-приложений функциональными особенностями, к недостаткам — низкую производительность (это общая слабость всех виртуальных машин, в том числе и лежащих в основе интерпретаторов) и ощутимую ресурсоемкость.
Вторая категория — исполняемые программы в машинных кодах целевой платформы, т. е. реальной машины. Она включает в себя множество специализированных библиотек подпрограмм и классов для разработки ПО на языках высокого уровня (наиболее популярны для Unix-систем, естественно, C и C++). Главное достоинство исполняемых программ — недостижимая для интерпретаторов производительность и очень низкая ресурсоемкость, недостаток — повышенные требования к квалификации разработчиков (хотя для программирования интерпретирующих средств также нужны отнюдь не дилетанты).
Необоснованно навязывать свою точку зрения по поводу выбора той или иной технологии разработки интра-приложений не хочется, поэтому в качестве аргумента приведу один факт из очень близкой к предмету нашего обсуждения области, а именно, из опыта проектирования клиент-серверных систем на основе различных СУБД. Если еще пять лет назад большинство разработчиков (около 50%) ориентировались на использование так называемых высокоуровневых средств визуального программирования, то сегодня ситуация коренным образом изменилась: 49% программистов предпочитают "классический" подход (C/C++).
В случае с интра-приложениями этот подход еще более перспективен — во-первых, программные интерфейсы (CGI/FastCGI) крайне просты, во-вторых, существует огромное количество надежных, компактных и очень хорошо документированных библиотек, существенно облегчающих работу.
Желающие освоить технологию разработки CGI-приложений могут начать со знакомства с информационными материалами на сайте www.drclue.net/F1.cgi/HTML/CGI/CGI.html, а для реальных проектов использовать очень компактные и надежные библиотеки классов, например LUCGI Криса Дюэрра (www.iit.edu/~duerchr/, подобных "упростителей" можно отыскать в Сети сотни). Для сторонников "полной оптимизации всего" есть отличный сайт www.fastcgi.com, со страниц которого доступны как спецификации интерфейса FastCGI, так и необходимые для разработки приложений библиотеки.
Всю мощь и эффективность неинтерпретирующего подхода можно ощутить только при разработке реальных приложений: здесь вам очень поможет обладающая сумасшедшей "скорострельностью" библиотека индексирования и поиска по ключевым словам в HTML-страницах SWISH++ (www.best.com/~pjl/software/swish/), позволяющая во многих случаях избавиться от "неповоротливой" базы данных и не ограничивающая возможности поиска.
Что же касается СУБД, неотъемлемой части чуть ли не любого информационного интра-проекта, то здесь, увы, возможности выбора очень ограничены, и вовсе не по причине отсутствия СУБД из категории freeware (кроме хорошо известных и популярных Postgres, PostgreSQL и MySQL, существует еще несколько десятков весьма неплохих реализаций, с перечнем и краткими описаниями которых вы можете ознакомиться на сайте www.iam.unibe.ch/~scg/Archive/Software/FreeDB/
FreeDB.list.html. Причина подобного утверждения, скорее, заключается в особенностях различных СУБД: некоторые из них лучше ведут себя при выполнении интенсивных операций чтения (например, MySQL), другие — весьма сносно справляются и с чтением, и с записью данных (Postgres и PostgreSQL). Проблема выбора в подобной ситуации усложняется и ключевым вопросом: нужны ли вашим интра-приложениям SQL-запросы или вполне допустимо обойтись без них? Ответ на этот вопрос зависит от стоящих перед разработчиком задач, но, по мнению автора, при любой возможности избежать SQL-запросов следует ею воспользоваться. И не надо возмущаться — SQL-интерпретатор "страдает" теми же "болячками", что и все интерпретаторы, — ресурсоемкостью и "неповоротливостью". Поэтому попробуйте замечательную библиотеку Berkeley DB (относящуюся к классу так называемых embedded database — встраиваемых СУБД), бесплатно распространяемую и постоянно совершенствуемую компанией Sleepycat (www.sleepycat.com), — ее возможности способны удовлетворить самые взыскательные запросы, а простота программных интерфейсов, существующих чуть ли не для всех популярных языков программирования, позволяет буквально за пару дней "набросать" очень быструю и надежную, встраиваемую непосредственно в CGI-приложения СУБД. Уровень документации Berkeley DB можно оценить как очень высокий, а надежность кода гарантируется его открытостью и постоянным развитием с 1992 г.
Приведенные выше программные продукты и "метаподход" к проектированию на их основе больше годятся для случаев, когда задача хорошо определена или даже существуют "прообразные" программы для ее решения (например, при замене неэффективной клиент-серверной системы документооборота или товарно-складского учета на интра-систему). В этом случае с помощью набора простых и доступных инструментальных средств, легко поддающихся изучению разработчиками, можно значительно сократить сроки проектирования, повысить надежность системы и, что главное, существенно упростить код ее реализации (что эквивалентно как минимуму затрат на сопровождение ПО, так и облегчению процессов его модернизации).
В случаях, когда речь идет о профессионально-"заказной" разработке "интранетовых" приложений, более целесообразно ориентироваться на комплексные (и потому, естественно, весьма сложные в освоении) "окружения"-frameworks, создаваемые специально для этих целей. К таким "интра-монстрам" можно отнести Zope (www.zope.org), Inter/intra-framework от Obsidian Systems (www.obsidian.co.za) и "единый набор инструментальных средств информационных серверов" GIST (gist.jrc.it). Все эти программные продукты чрезвычайно сложны, поэтому их применение оправдано только для высокопрофессиональных разработчиков.
Например…
Из отечественной практики привести что-либо в качестве примера трудно — факты существования функционально насыщенных интра-систем в Украине, увы, автору неизвестны. Но ряд экспериментов и собственный опыт показывают, что есть очень хорошо поддающиеся "интранетизации" задачи. Так, с помощью элементарных CGI-программ и перечисленных выше библиотек была организована прототипная система управления документооборотом, включающая подготовку, учет, хранение, поиск и распечатку товарных накладных (платформа — x86 FreeBSD, HTTPD — модифицированный thttpd, СУБД — встраиваемая на основе Berkeley DB, подготовка файлов к печати — форматизатор текста Lout). Впоследствии был произведен эксперимент по объединению созданной системы с готовым интра-модулем электронной почты (www.endymion.com/products/mailman/), пакетами Web-администрирования Unix-систем Webmin (webmin.bilkent.edu.tr) и мониторинга BigBrother. Можно сказать, что результат превзошел все ожидания как по скорости работы (при "обычной" дешевой Ethernet-сети), так и по надежности и легкости разработки.
Для повышения защищенности и снижения требований к используемому "железу" в ходе описанного "эксперимента" применялись два раздельных сервера — один выполнял традиционные Internet-, второй — intranet-функции. Подобную практику следует считать наиболее целесообразной: во-первых, резко снижается "уязвимость" внутренней локальной сети, во-вторых, даже сверхдешевые Pentium 166 MHz прекрасно справляются со всеми задачами при значительном числе пользователей (единственная ресурсоемкая задача — подготовка PostScript-документов к печати).
К возможным дальнейшим расширениям следует отнести факс-сервер, доску объявлений, виртуальный конференц-зал — для всех этих задач существует бесплатное высококачественное ПО, которое достаточно просто "завернуть" в "интра-оболочку".