РАДЖА
   
  О проекте в целом 
   
  Системная архитектура 
   



Разграничение общесистемных и прикладных функций
Документоориентированность
Поддержка работы с отчетами
Управление доступом и cистема безопасности
Протоколирование действий пользователя
Администрирование системы
Контроль целостности программ
Обновления от разработчика
Лицензирование и защита от нелегального копирования


Сразу расставим акценты - есть "системная" архитектура ("как это устроено"), а есть "прикладная" ("что полезного все это умеет делать"). В этой главе пойдет речь о системных аспектах реализации программы "Раджа", то есть в какой степени потенциальные достоинства трехзвенной клиент-серверной архитектуры удалось реализовать.




   
  Разграничение общесистемных и прикладных функций 
   

На рис. 1-4 показана классическая схема трехзвенной клиент-серверной программы. Полезность любой программы определяется только реализацией прикладных функций. Но кроме прикладных задач, неизбежно должны решаться и "общесистемные". В "Радже" четко выделено системное ядро ("движок", "engine", "платформа"... - называть можно как угодно). Причем ядро это распределено по всем трем звеньям системы. В функции ядра входят следующие подсистемы:
Ядро - это та часть программы, которая остается неизменной независимо от прикладной направленности задач, реализованных с помощью технологии "Раджа". Более того, это системное обеспечение технологии процесса создания прикладных решений. Это тот "скелет", на который наращивается "мускулатура" в виде полезного потребителю программного обеспечения. На "компьютерном" сленге ядро - это "API прикладного программиста".
Ядро - суть отдельный продукт, который комплектуется очень тесно связанными с ним прикладными программами для дальнейшей поставки конечному потребителю. Ядро - это инструмент, которым пользуются программисты фирмы разработчика.
Ядро - трехзвенная клиент-серверная программа. Без оговорок и исключений. Таковыми являются и прикладные программы в рамках проекта.
Сказанное можно отобразить рисунком и проиллюстрировать примером:

Рис. 2-1, Pис. 2-2

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



   
  Документоориентированность 
   

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



   
  Поддержка работы с отчетами 
   

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



   
  Управление доступом. Система безопасности 
   

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



   
  Протоколирование действий пользователя 
   

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



   
  Администрирование системы 
   

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



   
  Контроль целостности программ 
   

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



   
  Обновления от разработчика 
   

Ядро содержит средства поддержки обновлений программ разработчиком. Существует дистрибутивный набор системы "Раджа" и последовательность так называемых "Сервис-Пакетов" обновлений. Нумерация Сервис-Пакетов - последовательная. Любой дистрибутивный набор программы характеризуется номером последнего Сервис-Пакета, который учтен в данном экземпляре дистрибутивного набора.
Сервис-Пакеты принимаются специальными средствами программы "Раджа" и используются для обновления уже установленной программы.
Сервис-Пакеты доступны пользователю на сайте фирмы-разработчика, могут поставляться дилером фирмы-разработчика или присылаться по электронной почте.
Обновление установленной программы осуществляется только на серверном компьютере, а клиентские программы, как это уже говорилось, обновляются по мере загрузки на выполнение.
Следует отдельно отметить, что программа контролирует последовательность установки сервис-пакетов: так она не позволит установить сервис-пакет № 5, если ранее был установлен сервис-пакет № 6. Кроме того, некоторые сервис-пакеты могут требовать предустановки каких-либо ранних обновлений. Так, сервис-пакет № 6 может требовать обязательной установки сервис-пакета № 5, но для сервис-пакета № 5 может быть не обязательно наличие сервис-пакетов № 2-4.



   
  Лицензирование и защита от нелегального копирования 
   

Дистрибутивный набор программы "Раджа" одинаков для всех пользователей и не зависит от затребованной ими функциональности. В стоимость дистрибутивного набора входит только стоимость носителя (компакт-диск, упаковка и буклет), стоимость торговых издержек и доставки. Этот же дистрибутивный набор может быть совершенно бесплатно загружен с сайта фирмы-разработчика. Допустимо также владеть копией, сделанной с оригинального компакт-диска фирмы-разработчика. Таким образом, можно сказать, что дистрибутив программы "Раджа" и сервис-пакеты его обновлений никак не защищены от копирования и использования. Фирма-разработчик не только не запрещает копировать дистрибутив, но даже приветствует подобные формы распространения системы, приводящие к тому, что цена дистрибутива для конечного пользователя будет пренебрежительно низкой или даже нулевой.
Однако владение таким дистрибутивным набором (независимо от формы его приобретения) дает пользователю право только на некоммерческое использование. Под некоммерческим использованием следует понимать запрет проставлять на создаваемых системой документах реальные реквизиты владельца дистрибутива. А именно: кода ОКПО и наименования предприятия или налогового номера и имени частного предпринимателя. Можно изучать систему, можно сколь угодно долго проверять ее возможности, можно даже вести реальный учет. Но нельзя делать документы, вроде накладных, счетов, отчетов, платежных ведомостей... с реальными атрибутами фирмы. Это ограничение дает возможность познакомиться с системой, проверить заявленные возможности, обучить персонал совершенно бесплатно, а только потом уже принимать решение о коммерческом использовании. А для такого использования системы нужно приобрести лицензию. Эта лицензия так и называется - Лицензия на право коммерческого использования.
Физически лицензия представляет собой специальный файл, содержащий, помимо прочего, атрибуты владельца лицензии, о которых уже говорилось. Файл этот может предоставить только фирма-разработчик и никто другой. Файл зашифрован специальными методами и "изготовить" его самостоятельно весьма и весьма сложная задача. Задача эта сводится к взлому алгоритма шифрования с открытым ключом.
Сказанное можно перефразировать более коротко - фирма-разработчик не ограничивает применение системы "Раджа" никакими условиями, кроме прямого запрета проставлять реальные атрибуты пользователя какими-либо способами, отличными от предоставляющихся системой с помощью оригинального файла-лицензии, созданного фирмой-разработчиком.
Кроме атрибутов владельца, лицензия содержит список функциональных, количественных и временных ограничений.
Функциональные ограничения - список затребованных (и оплаченных) пользователем функциональных возможностей: какими приложениями пользователь намерен пользоваться, какие отчеты создавать. Это позволяет оплачивать только тот функционал системы, который реально нужен потребителю.
Количественные ограничения - ограничения на максимальное количество создаваемых в определенный отрезок времени документов (накладных, счетов...). Логика этих ограничений такова - маленькая фирма с небольшим документооборотом будет требовать от системы гораздо меньших усилий..., а значит и платить за право использования должна меньше, чем фирма, создающая 500-3000 только расходных накладных в день. Кроме того, количественные ограничения касаются предельного числа одновременно работающих с системой клиентских компьютеров. Именно одновременно работающих, а не максимальное количество подключенных (установленных) клиентских программ. Обоснование аналогичное - чем больше потребитель требует от системы, тем больше он должен платить за право ее использования.
Ограничения на время использования - это специальная группа ограничений, регламентирующих право датировать документы определенным периодом времени. Например, лицензия может позволять создавать накладные с датой от 01.01.2005 до 01.03.2005 (период в два месяца). Такие возможности лицензирования позволяют предоставлять программу с отсрочкой платежа (сначала выдается лицензия с ограничением периода до обещанной проплаты, а по осуществлению последней - выдается постоянная лицензия без ограничений по времени). Такой подход позволяет сдавать программу в аренду, использовать лизинг и т.п. А самое главное - позволяет предоставлять любому потенциальному потребителю право на ограниченное по времени коммерческое использование программы. Фирма-разработчик предоставляет одноразовую бесплатную двухмесячную лицензию на право использования системы "Раджа" в коммерческом режиме. Для этого нужно только прислать электронное письмо-заявку. Бланк такого письма можно найти в дистрибутивном наборе, в папке "TRIAL". Никаких обязательств покупать систему в будущем такая лицензия на потребителя не накладывает.
В дистрибутивном наборе всегда находится специальная лицензия для изучения системы на вымышленном предприятии. В этой лицензии код ОКПО условный, а название фирмы - "РАДЖА". Количественных и функциональных ограничений в этой лицензии не содержится. Не содержится там и ограничений на время использования.
Таким образом, процесс ознакомления с системой и последующее ее приобретение можно выстроить по схеме:
Всегда сохраняется возможность доплатить за ранее невостребованные возможности системы (и функциональные, и количественные) и получить новый файл лицензии.
Если файл лицензии будет утерян, то фирма-разработчик вышлет его по электронной почте совершенно бесплатно.
При этом доступна возможность телефонных консультаций с фирмой-разработчиком, ее филиалами или партнерами. Более подробно об этом можно прочитать в документах, находящихся в папке "SUPPORT" дистрибутивного набора.
Реализованная в программе "Раджа" система лицензирования делает совершенно ненужным применение всевозможных средств защиты от нелегального копирования вроде электронных ключей защиты (HASP), специальных дискет и т.п. технических анахронизмов, требующих от пользователя дополнительных затрат и зачастую преподносящих пользователям же неприятные сюрпризы. Автоматически решаются запросы: "как изучить", "как продемонстрировать" - для этого используется лицензия на предприятие "Раджа". Нет проблем и с потребностями установки на другой площадке предприятия - никто не мешает снять копию с реальной лицензии. Можно устанавливать систему дома, на мобильном компьютере... Нет ограничений на количество установок, а значит допустимо произвольно менять технику.
Но самым главным результатом есть то, что потребитель не вынужден будет покупать "кота в мешке" (точнее "в коробке"). Можно сначала изучить систему, оценить ее, а потом уже платить. Причем платить только за те возможности, которые реально нужны.