Эволюция информационных систем предприятия

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

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

Чуть позже появилась возможность «одновременной» работы нескольких пользователей с вычислительной машиной через терминалы или консоли (рис. 11). В действительности программы продолжали выполняться по-очереди, но в это время несколько пользователей могли набирать тексты программ и пр. (операционная система VM – Virtual Machine или ее советский аналог СВМ – Среда Виртуальных Машин). Это не меняет сути – вычислительная машина продолжала оставаться общим ресурсом, предоставляемым по-очереди нескольким независимым программам.

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

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

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

Изначально СУБД предназначались для работы с данными на локальном компьютере (Access, Paradox, FoxPro). Эти же СУБД можно использовать и в сети. При этом данные располагаются на файл-сервере, а СУБД – на компьютерах пользователей (рис. 14). Файлы с данными целиком копируются с файл-сервера на локальный компьютер, а после модификации записываются обратно на файл-сервер. Одновременный доступ к данным обеспечивается с помощью обычных блокировок файлов на чтение/запись, предоставляемых ОС.

Хотя файл-серверные СУБД и снижают требования к аппаратному и программному обеспечению сервера, но существенно нагружают сеть, т. к. передают все данные целиком, а не только те, которые интересуют пользователя. Такая организация баз данных для крупных систем считается устаревшей. На смену пришла т. н. клиент-серверная [18] организация, когда СУБД располагается на том же сервере, что и сама база данных, и монопольно владеет ею (примеры таких СУБД: Oracle, Interbase, DB2, MySQL, MS SQL Server и др., см. рис. 15). Централизованное управление данными существенно снижает загрузку сети, облегчает обеспечение надежности, безопасности и пр.

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

СУБД реализует только типовые операции с данными: поиск, добавление, обновление и т. п. Для каждого конкретного приложения существуют свои специфические алгоритмы обработки данных, называемые бизнес-логикой: правила расчета зарплаты, сбор специфической статистики в виде отчетов и пр. Эта логика изначально реализовалась на стороне клиентов. Там же реализовался интерфейс пользователя или логика представления. Такие клиенты называются толстыми.

Реализация бизнес-логики на стороне клиента не всегда эффективна. Например, для подсчета специфической статистики приходилось передавать с сервера на клиент весь массив данных, где те будут обрабатываться. После обработки пользователю предоставляется полученная статистика в виде, например, единственного числа. Операция была бы гораздо эффективней, если бы расчет производился на стороне сервера, а по сети передавался только окончательный результат. Для этой цели в современных СУБД предусматриваются т.н. хранимые процедуры – пользовательские исполняемые модули, которые хранятся на сервере, имеют доступ к данным и могут вызываться с удаленного клиента. Таким образом, хранимые процедуры позволяли перенести часть бизнес-логики с клиентов на сервер (рис. 16).

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

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

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

Рассмотренная двухзвенная архитектура клиент-сервер все чаще заменяется трехзвенной (трехуровневой). А именно, сервер разделяется на два: сервер данных и сервер приложений. Сервер данных по-прежнему содержит в себе базу данных, а на сервер приложений выносится бизнес-логика (рис. 19).

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

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