Двухзвенный клиент-серверный подход предоставляет значительные преимущества по сравнению с однозвенным подходом - проектирование происходит заметно быстрее, а сервер может быть довольно простым, поскольку большая часть сложной обработки возлагается на клиента. Следствием из этого является заметное удешевление системы, особенно серверной ее части. Появляется возможность не зависеть от платформы сервера, поскольку все базы данных от одного поставщика предоставляют одинаковый интерфейс независимо от платформы сервера. А такие интерфейсы, как ODBC (Microsoft) или IDAPI (Borland-Inprise) позволяют добиться и независимости от производителя БД.
Также двухзвенный подход обладает и недостатками. Это проблемы с безопасностью данных, проблемы с надежностью и управляемостью информационной системы, чрезмерные расходы при модификации и обслуживании информационной системы. Двухзвенная архитектура работает прекрасно, если имеется только одна реляционная БД, а клиентские приложения совершают четко определенные простые действия с данными. Hо по мере возрастания сложности системы - когда количество источников данных и количество пользователей возрастает - двухзвенная клиент-серверная система очень быстро исчерпывает возможности по развитию. Без жесткого контроля по безопасности, который могла бы предоставить только централизованная система, такой контроль должен возлагаться на каждое клиентское приложение в отдельности. По мере возрастания сложности клиентского приложения увеличивается и его размер, а, следовательно, и затраты.
Одной из методик, повышающей надежность и управляемость корпоративной информационной системы, является перенос логики управления данными в хранимые процедуры на корпоративный SQL сервер. При этом логика доступа к данным отделяется от логики обработки данных. Хранимые процедуры представляют собой предкомпилированные функции SQL, работающие внутри SQL сервера. Они заметным образом повышают общую устойчивость и производительность системы.
Однако написание хранимых процедур требует довольно высокой квалификации. Кроме того, при написании хранимых процедур разработчик имеет дело со специфическим окружением конкретного SQL-сервера, его специфической архитектурой и его ограничениями.
Также двухзвенный клиент-серверный подход хорошо работает в случае, когда все корпоративные данные хранятся лишь в одном месте, в одном SQL-сервере. Но на самом деле большинство данных до сих пор находится в прежних форматах баз данных, а то и просто сохраняются в файловой системе. Существующие на сегодня RAD-инструменты (rapid application development) предназначены большей частью для операций с данными, выбираемыми из реляционных таблиц, и почти не предлагают средств для интеграции данных из многих источников в единую систему.
Каждый производитель SQL-сервера поддерживает свой собственный протокол для обращения к данным, поэтому разработчику приходится каждый раз заново решать проблему установления соединения, синхронизации данных, безопасности и множество других мелких и неприятных технических проблем.
Клиентские приложения становятся все более сложными и все менее управляемыми. Это общая тенденция для двухзвенного клиент-серверного подхода.
Двухзвенная клиент-серверная архитектура - это архитектура, существенно зависящая от применяемых программных инструментов.
Возможности масштабирования и развития системы существенно ограничены. Двухзвенная архитектура позволяет весьма производительным способом использовать RAD-инструменты, однако стоимость масштабируемости, администрирования, развития такой архитектуры непомерно высока. И при всем при этом такая архитектура принципиально ограничивает доступ ко всем корпоративным данным и возможности интеграции всех систем в единое целое, поддержку одновременно и новых и прежних технологий.
Но инструменты визуальной сборки приложений дали возможность проектировать систему чрезвычайно быстро. SQL_серверы позволяют одновременно работать большому числу пользователей. Сетевой трафик настолько мал, что сеть практически не замедляет работу большого числа конечных пользователей и передает данные с большой скоростью. Проблемы и ограничения содержатся не в программных продуктах, а в выбранной архитектуре прикладной информационной системы.
1.2.3 Трехзвенные приложения
Способ преодолеть ограничения двухзвенной архитектуры существует. Переход к трехзвенной архитектуре позволяет сохранить преимущества двухзвенного клиент-серверного подхода, и, кроме того, добиться дополнительной гибкости.
Под тремя звеньями понимаются три логические части корпоративной прикладной системы, количество компьютеров, работающих в системе, не имеет значения. Трехзвенная модель информационной системы подразумевает логическое деление прикладной системы на три звена - презентационная логика, бизнес-логика и логика доступа к данным. В самом общем случае в системе может существовать сколь угодно много компонент каждого типа. Поэтому говорят о многозвенной архитектуре. Каждая прикладная компонента системы может разделяться любым количеством прикладных систем. При разработке компоненты каждого типа может использоваться самый подходящий тип инструментального средства. Каждая компонента может быть установлена на одном или сразу на многих вычислительных машинах. Каждая компонента взаимодействует друг с другом через общий интерфейс, который скрывает детали реализации соответствующей логики. Hа инфраструктуру системы возлагаются задачи обеспечения безопасности данных, совместимости и надежной синхронизации между компонентами системы.
Эта задача решена для всех компонент системы, и не требует отдельной проработки для каждой компоненты.
1.2.3.1 Модули и объекты
Преимущества трехзвенной архитектуры заключаются не только в жизненном цикле приложения. То, что строится в результате применения многозвенного подхода - это набор клиентских и серверных модулей, которые взаимодействуют друг с другом при помощи стандартных протоколов и стандартных соглашений об интерфейсах, их можно интегрировать и сопрягать друг с другом. Каждый модуль содержит в себе один или более объектов, разделяемых между приложениями. Эти объекты могут включаться в качестве составной части в другие системы.
1.2.3.2 Балансировка загрузки и надежность системы
Динамическая распределенная инфраструктура позволяет распределенному приложению динамически реконфигурироваться для того, чтобы приспособиться к увеличившемуся количеству пользователей, изменившейся загрузке процессора или при внезапно случившемся сбое. Это может происходить абсолютно незаметно для пользователя. Именно физическое разделение системы на модули является наиболее эффективным средством для поддержки масштабируемости, надежности системы. По мере подключения дополнительных пользователей, при превышении допустимого уровня использования процессора, при исчерпании физической памяти или при наступлении какого-либо другого критерия серверный модуль может переключиться на альтернативную серверную машину или разместить нагрузку на нескольких дополнительных машинах. Модуль балансировки может быть использован для того, чтобы повысить надежность системы в целом. Это достигается автоматическим переключением на работающую серверную машину в случае возникновения какой-либо неисправности. Это означает, что распределенная инфраструктура, позволяющая приложению быть разделяемым, безопасным, надежным, масштабируемым и управляемым, является самой важной составляющей корпоративной информационной системы.
1.2.3.3 Служба каталогов
Служба каталогов организует доступ к динамическому списку ресурсов всего предприятия. Когда пользователь или клиентское приложение формирует запрос, служба каталогов обрабатывает его и сообщает клиенту, каким образом взаимодействовать с соответствующим ресурсом. Для того, чтобы объект можно было найти в системе, тот должен быть зарегистрирован, как DCOM_объект. При этом это дает требуемую гибкость, характерную для трехзвенных систем - мы просто указываем объект, и - в соответствии с каталогом представляется тот компьютер, на котором будет исполняться код. В результате такой гибкости становится возможной и балансировка загрузки - можно предоставить тот компьютер, который в данный момент меньше всего загружен работой.
1.2.3.4 Сервис безопасности
Сервис безопасности устанавливает реестр авторизированных пользователей и групп пользователей всего предприятия и регулирует, какие ресурсы всей системы допустимо использовать для каждого пользователя. Сервис безопасности предоставляет единственный пароль для пользователя для всех доступных ресурсов предприятия. Если пользователь был аутентифицирован при входе в систему, все подсистемы воспринимают его аутентифицированным и не требуют повторного введения пароля при перемещении от подсистемы к подсистеме.
1.2.3.5 Служба управления приложениями
Служба управления приложениями предоставляет средство динамической реконфигурации приложений. Эта служба отвечает за запуск приложений на соответствующей машине и их последующий мониторинг. Если с приложением что-нибудь случилось в процессе эксплуатации, служба управления приложениями должна рестартовать приложение или произвести некую последовательность действий в зависимости от того, что было предписано при конфигурации системы.
1.2.3.6 Интерфейс приложений
Для того чтобы трехзвенная инфраструктура заработала, недостаточно создать набор распределенных приложений, которые могут запускаться и уничтожаться под управлением сервера приложений. Кроме этого, необходимо, чтобы разные слои трехзвенной архитектуры могли взаимодействовать между собой.
Как правило, ключевая идея такого взаимодействия заключается в том, что базовый программный продукт предоставляет централизованный или распределенный репозиторий интерфейсов всех модулей системы. При введении модуля в систему такой интерфейс регистрируется в репозитории-хранилище, после чего различные модули, чьи интерфейсы совместимы между собой, могут подключаться друг к другу и взаимодействовать между собой, в каком бы месте сети они не находились.
Для того чтобы разработчик мог использовать программные инструменты от различных производителей (например, Java, C++, Delphi и т.п.) для определения интерфейсов распределенных объектов применяется специальный язык определения интерфейсов IDL. Для разных стандартов (CORBA, DCOM, DCE) этот язык несколько отличается, но главный его смысл - он нужен для однозначного определения интерфейса взаимодействия модулей между собой.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9
