Клиент-серверная архитектура (курсовая), страница 6

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

"Толстый" сервер:усложняется реализация, так как языки типа PL/SQL не приспособленыдля разработки подобного ПО, и нет хороших средств отладки;производительность программ, написанных на языках типа PL/SQL,значительно ниже, чем созданных на других языках, что имеет важноезначение для сложных систем;программы, написанные на СУБД-языках, обычно работают недостаточнонадежно; ошибка в них может привести к выходу из строя всегосервера баз данных;получившиеся таким образом программы полностью непереносимы надругие системы и платформы.Для решения перечисленных проблем используются многоуровневые (три иболее уровней) архитектуры клиент-сервер. [14]Рассмотрим следующие компоненты:презентационная логика (Presentation Layer - PL);бизнес-логика (Business Layer - BL);логика доступа к ресурсам (Access Layer - AL).35Таким образом, можно придти к нескольким моделям клиент-серверноговзаимодействия 1):"Толстый" клиент.

Наиболее часто встречающийся вариант реализацииархитектуры клиент-сервер в уже внедренных и активно используемыхсистемах.Такаямодельподразумеваетобъединениевклиентскомприложении как PL, так и BL. Серверная часть, при описанном подходе,представляет собой сервер баз данных2)., реализующий AL. К описанноймодели часто применяют аббревиатуру RDA - Remote Data Access."Тонкий" клиент. Модель3), начинающая активно использоваться вкорпоративной среде в связи с распространением Internet-технологий и, впервую очередь, Web-браузеров. В этом случае клиентское приложениеобеспечивает реализацию PL, а сервер объединяет BL и AL.Сервер бизнес-логики. Модель с физически выделенным в отдельноеприложение блоком BL.1).Хотя,рассматриваемыевэтойчастивариантыразделенияфункциональности между клиентом и сервером являются "классическими",далее будет использоваться не только устоявшаяся традиционная, но и болееноваятерминология,корпоративных2)средахвозникшаявследствиераспространенияInternet/intranet-технологийивстандартов..

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

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

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

На настоящий момент наибольшейпроработанностью отличаются 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), отбора и анализа данных в процессе принятия решений (DecisionSupport),асинхронногоуведомленияособытиях(EventAlerts),тиражирования данных (Replication), почтового обмена (Mailing) и др.Вследствие наличия такого огромного количества функций, закладываемых в38блоки поддержки бизнес-логики, появляется понятие сервера приложений(Application Server - AS). Причем, сервер приложений не просто являетсянекоим единым универсальным средним BL-звеном между клиентской исерверной частью системы, но AS существует во множественном варианте,как частично изолированные приложения, выполняющие специальныефункции,обладающиеоткрытымиинтерфейсамиуправленияиподдерживающие стандарты объектного взаимодействия.Проникновение информационных технологий в сферу бизнеса вкачестве неотъемлемого условия успешного управления приводит к тому, чтосистемы корпоративных масштабов требуют сочетания различных клиентсерверных моделей в зависимости от задач, решаемых на различныхконкретных направлениях деятельности предприятия.

Вспомнив, снова, оправиле 20/80 можно придти к выводу, что наиболее оптимальным выбором,с точки зрения управляемости и надежности системы, является сочетаниеразличных моделей взаимодействия клиентской и серверной части. По сути,мы приходим даже не к трехуровневой, а многоуровневой (N-tier) модели,объединяющей различных по "толщине" клиентов, серверы баз данных имножество специализированных серверов приложений, взаимодействующихна базе открытых объектных стандартов. Существенным облегчением вреализации многоуровневых гетерогенных систем является активная работаряда производителей программного обеспечения, направленная на созданиепереходного ПО. В отличие от продуктов middleware, обеспечивающихверхний транспортный уровень (универсальные интерфейсы доступа кданным ODBC, JDBC, BDE; Message Oriented Middleware - MOM; ObjectRequest Broker - ORB;), переходное ПО отвечает за трансляцию вызовов врамках одного стандарта обмена в вызовы другого - мосты ODBC/JDBC иBDE/ODBC, COM/CORBA, Java/ActiveX и т.п.В общем случае, многоуровневая модель клиент-серверной системыможет быть представлена, например, следующим образом:39Рис.

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