Создание интерфейса взаимодействия элементов сайта 304.ru. Интеграция пользовательской базы.
Надо оценить объёмы работы. Может её там на неделю, а может - на несколько лет...
Всем привет. ДН прислал ссылку на эту тему, вижу знакомые темы. Ну поехали...
Народ, кто думает, что это на неделю -- я вот только что из института приехал. И так каждый день. Угадайте, чем мы там занимаемся?
Правильно. Интегрируем. Не в смысле матанализа, а весь зоопарк наших цифровых ресурсов приводим к общему знаменателю. И надо сказать, за год работы, в течение которого за первую половину мы этот зоопарк создавали, а за вторую пытались его как-то обуздать, пришли к неутешительным, но совершенно очевидным выводам (выводы я озвучивал еще в феврале, но некоторые их еще до сих пор не осознали):1. Много ресурсов -- это хорошо. Это просто замечательно! Особенно учитывая феноменальную особенность менталитета типового студента (я буду что-то делать в своем проекте, а с этими, теми или даже воооон с теми упырями я работать не буду, они не идейные, куда им до меня!), лучше разбивать проектные группы на максимально автономные и малочисленные, легко контролируемые и, при необходимости, замещаемые подразделения, не завязанные друг на друга. Оптимально -- 2-3 человека на самостоятельный проект, на выходе у них должен быть некий продукт, пусть небольшой, но вполне законченный. Модуль, дизайн, сайт целиком, не важно, важно -- законченный и без пересечений с другими на этапе работы. Результаты их трудов уже можно перемешивать и править по вкусу.
2. Чтобы перемешивать результаты трудов, они должны быть совместимыми. Тут мы вспоминаем про стандарты и про процессный подход вообще. В двух словах: пусть делают, что хотят, но на входе и выходе должно быть то, что ожидается. Не совсем, конечно, так грубо, но идея именно такая: мы не смотрим за процедурами, мы регулируем процесс целиком. Если есть два модуля, то общаться они должны по строго определенному формату/протоколу, крайне желательно, чтобы этот протокол был стандартным. Например, список пользователей можно хранить в одном месте, чтобы все программы, которым он нужен, туда обращались. Для этого можно использовать что угодно, но вообще есть стандартный протокол -- LDAP. Ну и т.д. При таком подходе всегда можно обеспечивать независимое развитие и взаимозаменяемость проектных групп, что особенно важно при большой текучести кадров (для образовательных учреждений это норма).
3. При проектировании любого веб-ресурса невредно придерживаться классического принципа CMS: разделения контента, дизайна и программной части. Мне кажется, тут ближе всего к истине подошли идеи XML/XSL/JAVA -- взаимная независимость и вдобавок еще и платформенная независимость. Что такое платформенная зависимость, Степа может рассказать в исторической лекции "о базе выпускников с использованием MS Access"
Возвращаясь к теме. Я так понял, захотелось собрать воедино разные составляющие 304й? Форум, вики, фотогалерею, сайт со ссылками и файлами? Собственно этим и еще кое чем я занимаюсь (точнее, не столько занимаюсь, сколько руковожу, делают все уже давно студенты). Задача, которая казалась такой простой, на деле упирается в феноменальную кривизну реализации конкретных программ.
Могу кратенько, минут за сорок, описать разворачиваемую у нас на кафедре систему, вы в ней отчасти узнаете то, к чему через некоторое время может прийти 304. Просто у меня это профильная тема, а у ДНа и Степы -- работа для души, соответственно, я за последнее время получил не только технические ресурсы, но и административные, что позволяет развернуться более широко.
1. Сначала был сайт. И на нем был форум. Сайт был на Постнюке, форум был PHPBB2, интегрированный в Постнюк. Поскольку форум был подключаемый в виде модуля, ничего с объединением делать не приходилось, хотя вопли программистов, залезавших в код, были слышны далеко.
2. Постнюк -- штука мощная. Навесить на нее можно много и она это выдержит. Но. Работает она крайне медленно, а любая попытка что-то поправить будет сопровождаться полным переписыванием исправляемого модуля и нескольких с ним связанных. Читаем -- долго и криво. Охотников это делать было мало, поэтому концепцию сменили: одна задача -- один проект. Знакомо? Правильно, юникс. Там так и есть. И все можно связать.
3. Как сделать много разных проектов и при этом не потерять контроль над системой? Как это сделано в государстве? Единое финансовое пространство. А как сделать в вычислительной системе? Что там самое дорогое и важное? Пользователи. Трогательная забота об них родимых. То есть, мы объявляем, что "пользователь получает единый логин на все цифровые ресурсы от сайта до почты и локальной сети (домен), соответственно стеной встает вопрос: как это реализовать? И не просто, как реализовать, а как реализовать в том зоопарке, который мы имеем и можем заиметь: винды, линуксы всех мастей, сайты на самых разных системах и самых разных производителей, софт разноперый... никакими там корпоративными стандартами на ПО и не пахнет.
Не буду пересказывать всю мучительную историю развития идеи, но пришли вот к чему:
Есть пользователь. Он логинится на любом из существующих ресурсов.
Ресурс (например, сайт) обращается к своей базе пользователей.
Откуда база берет информацию о пользователях? Обычно, она попадает туда от админа или самого пользователя: при регистрации на ресурсе (сайт, ActiveDirectory и т. д.) Мы не можем себе позволить такую халяву, нам надо оторваться от конкретных реализаций. Так что берем за жабры Гугл и через некоторое время понимаем: есть такой протокол X.500. Нет, это круто, возьмем попроще: LDAP. Это упрощенная версия, нам и этой за глаза хватит.
Кто знает более-менее базы данных, вспомнит, что они бывают реляционные и иерархические. Вот ЛДАП -- иерархическая БД. Дерево. И у него есть все свойства этого типа баз. В частности, неспособность поддерживать свою целостность самостоятельно. В большинстве случаев, одна и та же запись там может оказаться востребованной в нескольких ветвях. Ну и ладно, выкрутимся. Действительно, в деревьях удобно представлять данные для программ, запросы быстро выполняются и все такое, поэтому посадим хоть целый лес этих деревьев и будем их "поливать" из реляционной базы данных, которая будет стоять за этим лесом. И там-то мы и будем хранить в едином месте всю информацию.
Что мы этим добились? Во-первых, всем угодили. Вот появляется какая-нибудь экзотическая программа, которая хочет, чтобы ей подавали данные в таком-то виде и никак иначе. А все остальные уже привыкли получать по-другому. Ну и ладно. Строим еще одно дерево под новую программу. Вообще, каждому проекту по своему ЛДАП дереву.
Получается, надо плодить копии одной и той же информации. Нехорошо. Особенно кусается, что надо копировать в кучу мест пароли. А если присмотреться:
а. Пароли мы храним открытыми, а вот передаем -- шифрованными. Каждому дереву в том виде, в каком ему удобно.
б. Сервер БД (мы ставим сейчас Оракл) ставится таким образом, чтобы он взаимодействовал с ЛДАП-серверами только по шифрованным или обособленным каналам и не был доступен из Интернет. Если система распределенная и нужно разместить ЛДАП на удаленном сервере -- организуется VPN туннель и далее по тексту.
в. Допускается только односторонняя передача данных -- от базы к каталогу ЛДАП. Обратное недопустимо. Если пользователь хочет поменять свой пароль или еще какую информацию -- для этого есть администратоский интерфейс, там в соответствии с правами, он может поправить что нужно, но не через LDAP. Так мы закрываем подавляющее большинство дыр, в первую очередь, оберегаемся от кривости "внешнего" софта, где могут быть дыры при авторизации на LDAP сервере.
Кстати, следующим этапом у нас по плану работа с RADIUS сервером, но нам это по причине наличия радиосети и потенциально мы хотим использовать несколько линий dial-in. К вашей теме это вроде не относится.
Материалы по теме:
Раздел форума "Электронная кафедра". http://forum.auditor...48e5787290c2490
Указатель по электронным интернет-ресурсам. В разработке пока, так что там свалка, но пощелкаете, найдете что-нибудь. http://auditory.ru/
Вообще, централизованно поддерживаются следующие сервисы:
-- кафедральный домен (AD)
-- центральный сайт http://eva.miem.edu.ru
-- учебный домен 2 уровня auditory.ru
-- почтовый сервер http://mail.auditory.ru с кучей сервисов, включая FTP и HTTP для пользователей.
-- форум http://forum.auditory.ru
-- фотогалерея http://photo.auditory.ru
-- База знаний на движке wiki (в работе) http://wiki.auditory.ru
-- система дистанционного тестирования http://testing.auditory.ru
-- радиосеть Wi-Fi: http://wi-fi.auditory.ru
-- WAP сайт -- http://wap.auditory.ru (временно отключен на модернизацию).
Из этого всего сейчас обеспечена интеграция форума, почты, домена в локальной сети, идут работы над фотогалереей и Вики.
Остальное из интернет не очень видно или оно совсем не готово к употреблению. Есть голосовая IP связь, строится пиринговая сеть, помнится, были подвижки IRC поднять, но заглохло, строим систему управления вузом (ERP), систему накопления, анализа и хранени контента (накопление трудов студентов и сотрудников и хранение библиотечных материалов, анализ сдаваемых работ на идентичность). А в планах... у... видеовещание, конференции, электронные подписи, система локализации студентов по RFID (вместо перекличек), локализованное громкоговорящее оповещение (где засекли, на тот динамик и прокричали), дальше больше, еще больше, получается "Большой брат", фантазия есть, додумаете.
Вот так мы строим ядро системы и обвешиваем его разными вкусняшками. Если будет интересно, могу в следующей серии рассказать, как строится все остальное, могу для желающих даже устроить экскурсию по МИЭМу с тыканьем пальцами в вайфайные точки под потолком и серверы на шкафу и в кучу всяких скриптов, если интересно -- пишите, устрою.
Напоследок: объединять ресурсы не только хорошо, но и жизненно необходимо с какого-то момента. Параллельно с этим я провожу достаточно жесткую политику упорядочивания имен. ВСЕ без исключения пользователи получили в принудительном порядке имена типа имя.фамилия латиницей, а еще, НИКАКАЯ отчетность не может быть сдана, минуя электронную систему (пока почту, потом будет поумнее система). Иначе все это будет полумерой. Игрушкой, хотя и прикольной. Мне для проведения такой работы понадобилось дорасти до зам. зав. кафедры по ИТ (в корпоративном эквиваленте это CIO). Чтобы что-то двигать дальше, придется забраться еще выше. Оцените свои силы, это очень непростая работа и не в программировании дело. Если вы ограничиваете задачу только втыканием нескольких сайтов в одно пространство имен пользователей, то это одно, если доводите идею до логического конца, то там вам на диссер насобирается? причем не на один, это я по своему опыту говорю
Летом у нас пачками пойдут студенческие дипломы по этой теме, я уж постарался, народу там крутится уйма. Близко к вашей теме?
