Файл: Варианты архитектуры клиент-сервер (Модели клиент-сервер).pdf

Недостатки:

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

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

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

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

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

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

Для решения данных проблем используются многоуровневые архитектуры клиент-сервер. Рассмотрим следующие компоненты:

• презентационная логика (Presentation Layer - PL);
• бизнес-логика (Business Layer - BL);
• логика доступа к ресурсам (Access Layer - AL).

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

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

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

1).Хотя, рассматриваемые в этой части варианты разделения функциональности между клиентом и сервером являются "классическими", далее будет использоваться не только устоявшаяся традиционная, но и более

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

будет сохраняться ориентация на серверы баз данных, как оконечное серверное звено. 3). Модели, основанные на Internet-технологиях и применяемые для построения внутрикорпоративных систем получили название intranet. Хотя intranet-системами сегодня называют все, что так или иначе использует стек протоколов TCP/IP, с ними скорее следует связать использование Webбраузеров в качестве клиентских приложений. При этом важно отметить тот факт, что браузер не обязательно является HTML-"окном", но, в не меньшей степени, представляет собой универсальную среду загрузки объектных приложений/компонент -Java или ActiveX. Описанные три модели организации клиент-серверных систем в определенной степени являются ориентирами в задании жесткости связей между различными функциональными компонентами, чем строго описываемыми программами в реальных проектах. Жесткость связей в схеме взаимодействия компонент системы часто определяется отсутствием (или наличием) транспортного или сетевого уровня (Transport Layer - TL), обеспечивающего обмен информацией между различными компонентами.

5.Серверы приложений

Посмотрим на то, что же происходит в реальной жизни. С точки зрения применения описанных моделей, при проектировании прикладных систем разработчик часто сталкивается с правилом 20/80. Суть этого правила заключается в том, что 80% пользователей обращаются к 20% функциональности, заложенной в систему, но оставшиеся 20% задействуют основную бизнес-логику - 80%. В первую группу пользователей попадают операторы информационных систем, занимающиеся ввод и редактирование информации, а также рядовые сотрудники и менеджеры, обращающиеся к поисковым и справочным механизмам. Во вторую группу пользователей попадают эксперты, аналитики и менеджеры управляющего звена, которым требуются как специфические возможности отбора информации, так и развитые средства ее анализа и представления. С точки зрения реализации моделей необходимо обеспечить прозрачность взаимодействия между различными компонентами системы, а, следовательно, обратиться к существующим стандартам такого взаимодействия. Любая прикладная система, вне зависимости от выбранной модели взаимодействия, требует такой инструментарий, который смог бы существенно ускорить сам процесс создания системы и, одновременно с этим, обеспечить прозрачность и наращиваемость кода. На фоне разработки и внедрения систем корпоративного масштаба явно присутствует тенденция использования объектно-ориентированных компонентных средств разработки. Соответственно, полноценное применение объектов в распределенной клиент-серверной среде требует и распределенного объектно-ориентированного взаимодействия, то есть возможности обращения к удаленным объектам. Таким образом, мы приходим к анализу существующих распределенных объектных моделей. На настоящий момент наибольшей проработанностью отличаются COM/DCOM/ ActiveX и CORBA/DCE/Java. Если в первом случае требуемые механизмы поддержки модели являются неотъемлемой частью операционной платформы Win32 (Windows 95/NT/CE), то во втором случае предусмотрена действительная кроссплатформенность (например, везде, где есть виртуальная машина Java). Если попытаться объективно оценить (хотя любая такая попытка во многом субъективна) перспективы применения этих моделей, то для этого необходимо понять требования к операционным платформам, выдвигаемые различными функциональными компонентами системы. При построении реальных систем корпоративного масштаба уже мало обходиться их разделением на три базовых фрагмента PL, BL, AL. Так как бизнес-логика является блоком, наиболее емким и специфичным для каждого проекта, именно ее приходится разделять на более мелкие составляющие. Такими составляющими могут быть, например, функциональные компоненты обработки транзакций (Transaction Process Monitoring), обеспечения безопасности (Security) при наличии разграничения прав доступа и выходе в Internet (Fire-wall), публикование информации в Internet (Web-access), подготовки отчетов (Reporting), отбора и анализа данных в процессе принятия решений (Decision Support), асинхронного уведомления о событиях (Event Alerts), тиражирования данных (Replication), почтового обмена (Mailing) и др. Вследствие наличия такого огромного количества функций, закладываемых в блоки поддержки бизнес-логики, появляется понятие сервера приложений (Application Server - AS). Причем, сервер приложений не просто является некоим единым универсальным средним BL-звеном между клиентской и серверной частью системы, но AS существует во множественном варианте, как частично изолированные приложения, выполняющие специальные функции, обладающие открытыми интерфейсами управления и поддерживающие стандарты объектного взаимодействия. Проникновение информационных технологий в сферу бизнеса в качестве неотъемлемого условия успешного управления приводит к тому, что системы корпоративных масштабов требуют сочетания различных клиентсерверных моделей в зависимости от задач, решаемых на различных конкретных направлениях деятельности предприятия. Вспомнив, снова, о правиле 20/80 можно придти к выводу, что наиболее оптимальным выбором, с точки зрения управляемости и надежности системы, является сочетание различных моделей взаимодействия клиентской и серверной части. По сути, мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели, объединяющей различных по "толщине" клиентов, серверы баз данных и множество специализированных серверов приложений, взаимодействующих на базе открытых объектных стандартов. Существенным облегчением в реализации многоуровневых гетерогенных систем является активная работа ряда производителей программного обеспечения, направленная на создание переходного ПО. В отличие от продуктов middleware, обеспечивающих верхний транспортный уровень (универсальные интерфейсы доступа к данным ODBC, JDBC, BDE; Message Oriented Middleware - MOM; Object Request Broker - ORB;), переходное ПО отвечает за трансляцию вызовов в рамках одного стандарта обмена в вызовы другого - мосты ODBC/JDBC и BDE/ODBC, COM/CORBA, Java/ActiveX и т.п. Причем, различные стандарты взаимодействия могут применяться в различных связках узлов системы, а мосты встраиваться в любой узел или выделяться в своеобразные серверы приложений, с физическим выделением в узлах сети. Двигаясь между клиентами слева-направо на диаграмме, мы можем наблюдать переход между различными моделями распределенных вычислений - через intranet к Internet.

6.Клиент-серверные вычисления.

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

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

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

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

Для того чтобы связать клиентов и серверов вместе и в полной мере использовать ресурсы, содержащиеся в каждой машине, мы должны разработать сетевую систему, которая на это способна. Сети должны быть прозрачны для пользователей. Сети и приложения должны работать вместе так же хорошо, как если бы они работали на одном компьютере. Кроме того, сеть должна обеспечить возможности самовосстановления, чтобы можно было перенаправить сетевой трафик вокруг испорченного кабеля и быть достаточно гибкой, чтобы реагировать на бизнес-изменения в окружающей среде. Для простоты используются локальные сети LAN. Сейчас существует три различные LAN топологии: звезда, кольцо и шина и, по крайней мере, пять конкурирующих стандартов для передач, и два стандарта для информации, необходимой для управления сетью. Локальные сети стали настолько сложными, что они требуют собственную операционную систему. Сеть продолжает быть одним из наименее изученных и наиболее важным из компонентов в информационной структуре организации. Большинство организаций, приверженных клиент-серверной архитектуре согласны, что связь локальных сетей не место, чтобы сэкономить деньги. Мы не должны пытаться связать несовместимые локальные сети с различными платформами. Программное обеспечение, аппаратное обеспечение и операционная система, используемая в сети, должны быть тщательно протестированы.

Открытые системы и стандарты

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

система, мы должны придерживаться нескольких видов стандартов. Имеются

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

• -OSF (Open Software Foundation) - некоммерческий консорциум компьютерных производителей, разработчиков программного обеспечения и поставщиков чипов для разработок, основанных на стандартах программного обеспечения.
• UNIX-International - консорциум производителей компьютеров, разработчиков программного обеспечения, целью которых является создание UNIX и связанных с ними стандартов разработки и лицензирования продуктов UNIX.
• -OMG - международные организации системы поставщиков, разработчиков программного обеспечения и пользователей, сторонники развертывания объекта управления технологиями в разработке программного обеспечения. Применяя общую основу для всех объектно-ориентированных приложений, организации смогут управлять гетерогенными средами.
• CORBA (Common Object Request Broker Architecture), разработанная OMG, DEC, NCR, HP и SUN является новым механизмом, который позволяет объектам (приложениям) называть друг друга по сети.
• -SQL Access Group - это промышленный консорциум работает над определением и осуществления технических условий для гетерогенного доступа SQL данных с использованием принятых международных стандартов.

2.4. Модель клиент - сервер в Интернете

Взаимодействие клиента и сервера в Интернете осуществляется с помощью запросов, посылаемых клиентом серверу, и ответов сервера на запрос клиента:

Суть распределенных систем - связь между процессами, реализующими не только взаимодействие компьютеров, но и частей (уровней) приложений. Взаимодействие частей приложений реализуется с помощью протоколов, описывающих состав и формат данных, пересылаемых соответствующими частями клиентских и серверных приложений друг другу для решения поставленной задачи. В Интернете разбиение приложений на части осуществляется на базе стека протоколов TCP/IP: В этой модели разработчики имеют большую свободу в определении того, какие части клиент-серверного приложения будут на клиентском компьютере и какие на сервере. Логика пользовательского интерфейса существовала почти исключительно на сервере. Мы можем вновь приступить к использованию более эффективных и хорошо структурированных клиентсерверных моделей. Есть, конечно, еще технические вопросы, но мы в состоянии лучше строить истинные клиент-серверные приложений в настоящее время.