Файл: «Вариант 21. Модель клиент-сервер».pdf

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

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

Толстый или Rich-клиент - это приложение, обеспечивающее (в противовес тонкому клиенту) расширенную функциональность независимо от центрального сервера. [2] Часто сервер в этом случае является лишь хранилищем данных, а вся работа по обработке и представлению этих данных переносится на машину клиента. Достоинства:

• Толстый клиент обладает широким функционалом в отличие от тонкого.
• Режим многопользовательской работы.
• Предоставляет возможность работы даже при обрывах связи с сервером.
• Имеет возможность подключения к банкам без использования сети Интернет.
• высокое быстродействие.

Недостатки:

• Большой размер дистрибутива.
• Многое в работе клиента зависит от того, для какой платформы он разрабатывался.
• При работе с ним возникают проблемы с удаленным доступом к данным.
• Довольно сложный процесс установки и настройки.
• Сложность обновления и связанная с ней неактуальность данных.

Большинство современных средств быстрой разработки приложений(RAD), которые работают с различными базами данных, реализует стратегию: "толстый" клиент обеспечивает интерфейс с сервером базы данных через встроенный SQL. Такой вариант реализации системы с "толстым" клиентом, кроме перечисленных выше недостатков, обычно обеспечивает недопустимо низкий уровень безопасности. [1] Например, в банковских системах приходится всем операционистам давать права на запись в основную таблицу учетной системы. Кроме того, данную систему почти невозможно перевести на Web-технологию, так как для доступа к серверу базы данных используется специализированное клиентское ПО. [1]

Итак, рассмотренные выше модели имеют следующие недостатки.

"Толстый" клиент:

• сложность администрирования;
• усложняется обновление ПО, поскольку его замену нужно производить одновременно по всей системе;
• усложняется распределение полномочий, так как разграничение доступа происходит не по действиям, а по таблицам;
• перегружается сеть вследствие передачи по ней необработанных данных;
• слабая защита данных, поскольку сложно правильно распределить полномочия.

2. "Толстый" сервер:

• Усложняется реализация, так как языки типа PL/SQL не приспособлены для разработки подобного ПО, и нет хороших средств отладки;
• Производительность программ, написанных на языках типа PL/SQL, значительно ниже, чем созданных на других языках, что имеет важное значение для сложных систем;
• Программы, написанные на СУБД-языках, обычно работают недостаточно надежно; ошибка в них может привести к выходу из строя всего сервера баз данных;
• Получившиеся таким образом программы полностью непереносимы на другие системы и платформы.

Для решения перечисленных проблем используются многоуровневые (три и более уровней) архитектуры клиент-сервер.

Рассмотрим следующие компоненты:

1. Презентационная логика (Presentation Layer - PL);
2. Бизнес-логика (Business Layer - BL);
3. Логика доступа к ресурсам (Access Layer - AL).

Таким образом, можно придти к нескольким моделям клиент-серверного

взаимодействия:

"Толстый" клиент. Наиболее часто встречающийся вариант реализации архитектуры клиент-сервер в уже внедренных и активно используемых системах. [1] Такая модель подразумевает объединение в клиентском приложении как PL, так и BL. Серверная часть, при описанном подходе, представляет собой сервер баз данных, реализующий AL. К описанной модели часто применяют аббревиатуру RDA - Remote Data Access. [2]

"Тонкий" клиент. Модель, начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и, в первую очередь, Web-браузеров. В этом случае клиентское приложение обеспечивает реализацию PL, а сервер объединяет BL и AL.

Сервер бизнес-логики. Модель с физически выделенным в отдельное приложение блоком BL. [3]

Хотя, рассматриваемые в этой части варианты разделения функциональности между клиентом и сервером являются "классическими", далее будет использоваться не только устоявшаяся традиционная, но и более новая терминология, возникшая вследствие распространения в корпоративных средах Internet/intranet-технологий и стандартов. [5]

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

Модели, основанные на Internet-технологиях и применяемые для построения внутрикорпоративных систем получили название intranet. Хотя intranet-системами сегодня называют все, что, так или иначе использует стек протоколов TCP/IP, с ними скорее следует связать использование Web-браузеров в качестве клиентских приложений. При этом важно отметить тот факт, что браузер не обязательно является HTML-"окном", но, в не меньшей степени, представляет собой универсальную среду загрузки объектных приложений/компонент -Java или ActiveX. [7]

Описанные три модели организации клиент-серверных систем в определенной степени являются ориентирами в задании жесткости связей между различными функциональными компонентами, чем строго описываемыми программами в реальных проектах. Жесткость связей в схеме взаимодействия компонент системы часто определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL),обеспечивающего обмен информацией между различными компонентами.

Посмотрим на то, что же происходит в реальной жизни. С точки зрения применения описанных моделей, при проектировании прикладных систем разработчик часто сталкивается с правилом 20/80. Суть этого правила заключается в том, что 80% пользователей обращаются к 20%функциональности, заложенной в систему, но оставшиеся 20% задействуют основную бизнес-логику - 80%. [8] В первую группу пользователей попадают операторы информационных систем (ввод и редактирование информации), а также рядовые сотрудники и менеджеры, обращающиеся к поисковым и справочным механизмам (поиск и чтение данных). Во вторую группу пользователей попадают эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления. С точки зрения реализации моделей необходимо обеспечить прозрачность взаимодействия между различными компонентами системы, а, следовательно, обратиться к существующим стандартам такого взаимодействия. [9]

Любая прикладная система, вне зависимости от выбранной модели взаимодействия, требует такой инструментарий, который смог бы существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и наращиваемость кода. На фоне разработки и внедрения систем корпоративного масштаба явно присутствует тенденция использования объектно-ориентированных компонентных средств разработки. Соответственно, полноценное применение объектов в распределенной клиент-серверной среде требует и распределенного объектно-ориентированного взаимодействия, то есть возможности обращения к удаленным объектам. Таким образом, мы приходим к анализу существующих распределенных объектных моделей. [9]

На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ ActiveX и CORBA/DCE/Java. Если в первом случае требуемые механизмы поддержки модели являются неотъемлемой частью операционной платформы Win32 (Windows 95/NT/CE),то во втором случае предусмотрена действительная кросс-платформенность (например, везде, где есть виртуальная машина Java). Если попытаться объективно оценить (хотя любая такая попытка во многом субъективна) перспективы применения этих моделей, то для этого необходимо понять требования к операционным платформам, выдвигаемые различными функциональными компонентами системы. [8] При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL, AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций(Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов(Reporting), отбора и анализа данных в процессе принятия решений (DecisionSupport), асинхронного уведомления о событиях (Event Alerts),тиражирования данных (Replication), почтового обмена (Mailing) и др. [7]

Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений(Application Server - AS). Причем, сервер приложений не, просто является некоим единым универсальным средним BL-звеном между клиентской и серверной, частью системы, но AS существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия.[5]

Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания различных клиент-серверных моделей в зависимости от задач, решаемых на различных конкретных направлениях деятельности предприятия. Вспомнив, снова, о правиле 20/80 можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. [3] По сути, мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели, объединяющей различных по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. [2]

Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; MessageOrientedMiddleware - MOM; ObjectRequest Broker - ORB;), переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого - мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т.п.[1]

В общем случае, многоуровневая модель клиент-серверной системы может быть представлена, например, следующим образом:

Рисунок 6. Многоуровневая клиент-серверная модель

Причем, различные стандарты взаимодействия могут применяться в различных связках узлов системы, а мосты встраиваться в любой узел или выделяться в своеобразные серверы приложений, с физическим выделением в узлах сети. [1] Двигаясь между клиентами слева-направо на диаграмме, мы можем наблюдать переход между различными моделями распределенных вычислений - через intranet к Internet.

1.5 КЛИЕНТ-СЕРВЕРНЫЕ ВЫЧИСЛЕНИЯ

В 1970-х и 1980-х годов была эпоха централизованных вычислений на мэйнфреймах IBM занимающих более 70% в компьютерном бизнесе мира. Бизнес транзакции, деятельности и базы данных, запросы и техническое обслуживание - все исполнялось на мэйнфреймах IBM. [1] Этап перехода к клиент-серверным вычислениям представляет совершенно новую концепцию и технологию реорганизации всего делового мира. Вычислительные парадигмы 1990-х годов называли «волной будущего». [1] Машина-клиент обычно управляет интерфейсами процессов, таких как графический интерфейс (графический пользовательский интерфейс), отправкой запросов на сервер программ, проверкой данных, введенных пользователем, а также управляет местными ресурсами, а пользователь взаимодействует с такими, как монитор, клавиатура, рабочие станции, процессора и других периферийных устройств. С другой стороны, сервер выполняет запрос клиента, с помощью службы. После того как сервер получает запросы от клиентов, он выполняет поиск базы данных, обновления и управляет целостностью данных и отправляет ответы на запросы клиентов. [2]

Цель клиент-серверных вычислений - позволить каждой сетевой рабочей станции (клиента) и принимающей (сервера) быть доступными, по мере необходимости приложения, а так же обеспечивать доступ к существующему программному обеспечение и аппаратным компонентам от различных поставщиков для совместной работы. Когда эти два условия соединены, становятся очевидными преимущества клиент-серверной архитектуры, такие как: экономия средств, повышение производительности, гибкости и использования ресурсов.[2] Клиент-серверные вычисления состоят из трех компонентов: клиентского процесса, запрашивающего обслуживание и серверного процесса предоставления запрашиваемых услуг, с Middleware между ними для их взаимодействия.