Преобразование настольного приложения Access в приложение с архитектурой "клиент-сервер". Целесообразность перехода к клиент-серверной архитектуре.
Приложение, разработанное в среде Access, является настольным приложением. Оно может быть предназначено для одного пользователя или может быть многопользовательским. Оно может быть простым или достаточно сложным, как, например, приложение, рассмотренное в гл. 16, в котором взаимодействуют несколько процессов. Однако все эти процессы работают под управлением настольной СУБД Access, a настольная СУБД имеет ограничения как по количеству одновременно работающих пользователей, так и по объему базы данных. С увеличением сложности приложения и накоплением данных в таблицах Access может возникнуть необходимость перенесения этих данных на сервер баз данных, который работает на значительно более мощной программно-аппаратной платформе. В этом случае приложения Access 2002 устанавливаются на клиентских машинах и играют роль клиентов, обращающихся к данным, хранящимся в базах данных SQL-сервера.
В клиент-серверных информационных системах на компонент "сервер" возлагается задача надежного хранения данных и обработки запросов клиента, в то время как от "клиентской" части требуется лишь обеспечение удобного интерфейса пользователя. Поэтому компонент "сервер" исполняется на специальной серверной платформе, которая обеспечивает серверное приложение необходимыми ресурсами и мощностью, а компонент "клиент" исполняется на менее мощной аппаратно-программной платформе. В нашем случае мы рассматриваем систему с серверной СУБД Microsoft SQL Server, работающей под управлением Windows NT Server, и клиентскими частями, управляемыми менее мощными СУБД Microsoft Access 2002.
(О технологии "клиент-сервер" и ее применении в Access см. гл. 17.)
Целесообразность перехода к клиент-серверной архитектуре
Выбор архитектуры приложения главным образом зависит от поставленной задачи. Многие задачи успешно реализуются в небольших сетях с файловым сервером. В других случаях нужно применять более мощную клиент-серверную архитектуру. Преобразование настольного приложения в клиент-серверное (upsizing) целесообразно с точки зрения обеспечения четырех важнейших требований:
- надежность;
- масштабируемость;
- производительность;
- безопасность.
Надежность
Наиболее важным требованием, которое обычно предъявляется к масштабным приложениям, является повышение надежности. Отдельные копии приложений, работающие на клиентских компьютерах в файл-серверных сетях, не имеют синхронизированного журнала транзакций (напомним, что транзакция представляет собой одну операцию обмена данными между клиентом и сервером), поэтому сбой на любой клиентской машине или в сети может привести к порче данных. Обычно такую базу данных можно восстановить, но это может занять достаточно продолжительное время, в течение которого никто из пользователей не сможет работать с системой. В клиент-серверных системах при централизованном управлении данными сбои в сети или клиентских компьютерах редко влияют на базу данных. Кроме того, большинство серверов имеют возможность быстро и качественно восстановить данные. Для этого сервер использует специальный механизм управления транзакциями. Этот механизм гораздо более эффективен, чем соответствующий механизм в настольных СУБД, т. к. сервер контролирует работу транзакций централизованно. Например, процессор обработки данных Jet поддерживает обработку транзакций только во время текущей сессии (сеанса работы). Он не может разрешить проблем, возникших из-за сбоя в предыдущей сессии. Он может оставить "зависшие" блокировки в файле блокировок (файле с расширением Idb), и никто не сможет получить доступ к данным, пока вы не удалите этот файл. Он также не гарантирует защиту данных, если сбой произошел в процессе завершения транзакции. Разумеется, это очень редкое событие, но оно может стать основанием для серьезного рассмотрения вопроса о переходе к использованию клиент-серверных приложений.