Типичные проблемы эксплуатации информационных систем и способы их решения
Классические многопользовательские системы, как правило, содержат последние два компонента информационной системы на рабочих станциях пользователей. Из этого следует, что подобные рабочие станции должны предоставлять для самих себя весь требующийся для этого набор сервисов и содержать соответствующее программное обеспечение для их функционирования. Подобное требование нередко усложняет технические требования, предъявляемые к аппаратной части клиентской рабочей станции, и в конечном итоге приводит к удорожанию всей системы в целом (рис. 1)
Рис. 1. Классическая информационная система
Следует также отметить, что подобное программное обеспечение требует обычно проведения работ по его настройке и поддержанию этих настроек в рабочем состоянии. Так, пользовательское приложение должно, как минимум, "знать" о том, где расположены используемые им данные, какого они типа (имеется в виду тип серверной СУБД либо формат данных сетевой СУБД), с помощью какого сетевого протокола они доступны, каков поддерживаемый базой данных язык, определяющий порядок алфавитной сортировки и индексирования данных. Подобная работа нередко является весьма трудоемким процессом, особенно при большом количестве и неоднородном парке рабочих станций. Отметим, что далеко не все компоненты подобного программного обеспечения могут быть включены в состав дистрибутива пользовательского приложения, так как многие из них являются предметом лицензирования и продажи.
Есть и еще один немаловажный фактор: чем сложнее конфигурация, обеспечивающая доступ к данным рабочей станции, тем чаще происходят нарушения в ее работе. По данным некоторых западных источников, переконфигурация и сопровождение программного обеспечения, обеспечивающего доступ рабочих станций к данным, приводит в среднем к четырем дням простоя рабочей станции в год.
Имеется еще один фактор, напрямую связанный с тем, что многие средства разработки используют одни и те же стандартные библиотеки доступа к данным (в случае Windows это BDE и ODBC).
На сегодняшний день как на российском, так и на мировом рынке имеется немалое количество различных программных продуктов, содержащих какие-либо данные (в особенности энциклопедий и справочников), при установке которых устанавливаются и эти библиотеки (подобные действия разрешены при определенных условиях производителями этих библиотек). В этом случае нет никакой гарантии, что версия любой из подобных библиотек, входящая в комплект поставки такого продукта, окажется новее, чем уже используемая в корпоративной информационной системе, и что программа установки не внесет изменений в настройки, сопровождающие эту библиотеку, таким образом, что работоспособность уже установленной информационной системы окажется нарушенной. Это, конечно, противоречит правилам создания дистрибутивов, но такие случаи время от времени случаются даже с неплохими коммерческими продуктами.
Известен случай выпуска большим тиражом в одной из европейских стран коммерческого программного продукта (а именно телефонного справочника), установка которого на рабочих станциях пользователей приводила к выходу из строя всех пользовательских приложений, использующих доступ к данным и созданных с помощью более новой версии того же средства разработки, что использовался при создании данного справочника. Причиной подобных неприятностей явилась замена библиотек доступа к данным их более старыми версиями и переписывание файлов конфигурации при инсталляции этого продукта. (Как вы думаете, кому в первую очередь пользователи предъявляли претензии по поводу выхода из строя корпоративной информационной системы? Уверяю вас, отнюдь не разработчикам телефонного справочника, лежавшего в тот момент во всех магазинах этой страны… Собственно, сама эта история была расказана автору его коллегой-программистом из той самой европейской страны как раз в разгар потока претензий и рекламаций, получаемых им от разъяренных клиентов его компании, занимавшейся разработкой на заказ корпоративных информационных систем, вдруг переставших нормально функционировать после установки купленного пользователями телефонного справочника).
Итак, используя стандартные архитектуры создания многопользовательских информационных систем, можно столкнуться как минимум с двумя серьезными проблемами, требующими материальных затрат: все более повышающимися требованиями к аппаратному обеспечению рабочих станций и обеспечением поддержки настроек доступа к данным. Отметим, что список возможных проблем этим не исчерпывается. Мы не рассматривали проблемы, связанные с перегрузкой сети при росте объема данных (частично они могут быть решены при замене сетевых СУБД на серверные, но далеко не всегда такой переход полностью решает эти проблемы), проблемы, связанные с эксплуатацией всеми пользователями каких-либо общих ресурсов (например, высококачественного многопроцессорного сервера, способного быстро обрабатывать данные по сравнению с пользовательскими рабочими станциями), а также проблемы, возникающие при территориальной разбросанности предприятия или низком качестве линий связи.
Каким образом можно решить весь этот набор проблем? Способов их решения достаточно. Нередко применяются так называемые экстенсивные меры (наращивание аппаратной части рабочих станций, увеличение пропускной способности сети, прокладка новых линий связи, перенос прошлогодних данных в архивы с целью уменьшения объема базы данных), которые обычно требуют немалых материальных затрат, особенно при большом количестве пользователей и высокой скорости роста объема базы данных.
Есть, однако, и иные, интенсивные способы решения подобных проблем. Эти способы решения могут иметь различную реализацию, но в целом они используют одну общую идею. Эта идея заключается в создании новых сервисов, общих для пользователей информационной системы.
Такие сервисы, как правило, являются сервисами промежуточного слоя (middleware services), поскольку занимают промежуточный уровень между данными и сервисами, их обслуживающими, с одной стороны, и пользовательскими приложениями, ориентированными на конкретную предметную область, с другой стороны. Эти сервисы обычно обладают минимальным пользовательским интерфейсом или не имеют его вовсе.
Нередко они могут быть реализованы для нескольких различных платформ, так как являются сервисами более высокого уровня, чем сервисы, специфичные для данной операционной системы или СУБД. Такие сервисы могут быть реализованы внутри приложений или библиотек (такие приложения или библиотеки обычно называются серверами приложений - Application Server), а также в виде служб операционных систем. Пользовательские приложения, использующие сервисы промежуточного слоя, обычно называются клиентами.
Технологии, используемые для реализации таких сервисов, могут быть различными. В частности, их реализация может использовать технологию и стандарты DCE (Distributed Computing Environment), разработанные OSF (Open Software Foundation), как это сделано в Inprise Entera. Можно реализовать такие сервисы с использованием спецификации CORBA (Common Object Request Broker Architecture), разработанной консорциумом OMG (Object Management Group). В обоих случаях набор возможных клиентских и серверных платформ весьма широк и отнюдь не ограничивается различными версиями Windows. Если же речь идет об относительно недорогих решениях на основе Windows, вполне допустимо использовать DCOM (Distributed Component Object Model) либо различные расширения COM (например, технологию Inprise MIDAS) и реализовывать сервисы middleware внутри серверов автоматизации или компонентов Microsoft Transaction Server (о нем пойдет речь в следующей статье данного цикла).
