Учебная работа. Реферат: Технология Клиент-сервер 3

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (5 оценок, среднее: 4,80 из 5)
Загрузка...
Контрольные рефераты

Учебная работа. Реферат: Технология Клиент-сервер 3



Разработка «клиент-сервер»
пришла на замену централизованной схеме управления вычислительным действием на мейнфреймах еще в 80-х годах прошедшего века. Благодаря высочайшей живучести и надежности вычислительной системы, легкости масштабирования, способности одновременной работы юзера с несколькими приложениями, высочайшей оперативности обработки инфы, обеспечению юзера качественным интерфейсом и остальным способностям эта очень многообещающая и далековато не исчерпавшая себя разработка получила свое предстоящее развитие.

Со временем малофункциональную модель файлового сервера для локальных сетей (FS) поменяли показавшиеся одна за одной модели структуры «Клиент- сервер» (RDA, DBS и AS).

Заняв нишу баз данных, разработка «Клиент – сервер» стала главный технологией глобальной сети Internet. Дальше, в итоге перенесения мыслях сети Internet в среду корпоративных систем, возникла разработка Intranet
В отличие от технологии «Клиент-сервер» эта разработка нацелена не на данные, а на информацию в ее совсем готовом к потреблению виде. Вычислительные системы, построенные на базе Intranet, имеют в собственном составе центральные серверы инфы и распределенные составляющие представления инфы конечному юзеру (программы-навигаторы, либо браузеры). Взаимодействие меж клиентом и сервером в Intranet происходит с помощью web – технологий.

На нынешний денек разработка «Клиент-сервер» получает все большее распространение, но сама по для себя она не дает всепригодных рецептов. Она только дает общее время реализации данной технологии в определенных программных продуктах и даже в видах программного обеспечения различаются очень значительно.


Обычно составляющие сети не равноправны: у одних есть доступ к ресурсам (к примеру, принтер, микропроцессор, система управления базой данных (СУБД), файловая система и так дальше), остальные имеют возможность обращаться к сиим ресурсам.



— это архитектура программного комплекса, в какой происходит распределение прикладной программки по двум логически разным компонентам (клиент и сервер), взаимодействующим по схеме «запрос-ответ» и решающим свои определенные задачки (набросок 6).

Набросок 6 – Архитектура «Клиент – сервер»

комп (либо программка), управляющий и/либо обладающий любым ресурсом, именуют

этого ресурса.

комп (либо программка), запрашивающий и пользующийся любым ресурсом, именуют

этого ресурса.

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

Главный принцип технологии «Клиент-сервер» заключается в разделении функций приложения как минимум на три группы:


Также эту группу именуют логикой представления. Через эту группу юзеры ведут взаимодействие с приложением. Независимо от определенных черт логики представления (интерфейс командной строчки, сложные графические пользовательские интерфейсы, интерфейсы через посредника) ее задачка заключается в том, чтоб обеспечить средства для более действенного обмена информацией меж юзером и информационной системой.



;

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



(функции управления ресурсами);

Эту группу также именуют логикой доступа к данным либо методами доступа к данным. Методы доступа к данным исторически рассматривались как специфичный для определенного приложения интерфейс к механизму неизменного хранения данных наподобие файловой системы либо СУБД. С помощью модулей обработки данных организуется специфичный для приложения интерфейс к СУБД. С помощью интерфейса приложение управляет соединениями с базой данных и запросами к ней (перевод специфичных для определенного приложения запросов на язык SQL, получение результатов и перевод этих результатов назад в специальные для определенного приложения структуры данных).

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

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




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

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

Чтоб избежать несогласованности разных частей архитектуры были сделаны две модификации двухзвенной архитектуры «Клиент – сервер»: «Толстый клиент» («Узкий сервер») и «Узкий клиент» («Толстый сервер»).

В данных архитектурах создатели попробовали делать обработку данных на одной из 2-ух физических частей — или на стороне клиента («Толстый клиент»), или на сервере («Узкий клиент).

Любой подход имеет свои недочеты. В первом случае необоснованно перегружается сеть, поэтому что по ней передаются необработанные, а означает, лишниие данные. Не считая того, усложняется поддержка системы и ее изменение, потому что подмена метода вычислений либо исправление ошибки просит одновременной полной подмены всех интерфейсных программ, а по другому могут появиться ошибки либо несогласованность данных. Если же вся обработка инфы производится на сервере, то возникает неувязка описания интегрированных процедур и их отладки. Систему с обработкой инфы на сервере полностью нереально перенести на другую платформу (ОС), что является суровым недочетом.

Есди все-же разрабатывается двухуровневая традиционная архитектура «Клиент – сервер», то нужно держать в голове последующее:



;

Набросок 33. – Архитектура «Узкий клиент»

Передача запроса от клиента на сервер, обработка запроса сервером и передача результата клиенту. При всем этом архитектуры имеют последующие недочеты:

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

— производительность программ, написанных на языках типа SQL, существенно ниже, чем сделанных на остальных языках, что имеет принципиальное

— программки, написанные на СУБД-языках, обычно работают недостаточно накрепко; ошибка в их может привести к выходу из строя всего сервера баз данных;

— получившиеся таковым образом программки вполне непереносимы на остальные системы и платформы.


Обработка запроса происходит на стороне клиента, другими словами происходит передача клиенту всех необработанных данных с сервера. При всем этом архитектуры имеют последующие недочеты:

— усложняется обновление ПО , так как его подмену необходимо создавать сразу по всей системе;

— усложняется распределение возможностей, потому что разграничение доступа происходит не по действиям, а по таблицам;

— перегружается сеть вследствие передачи по ней необработанных данных;

— слабенькая защита данных, так как трудно верно распределить возможности.

Набросок 34. – Архитектура «Толстый клиент»

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


С середины 90-х годов прошедшего века признание профессионалов получила трехзвенная архитектура «Клиент – сервер», которая поделила информационную систему по многофункциональным способностям на три отдельных компонента: приложений, который предназначен для воплощения бизнес-логики, при всем этом вполне разгружается клиент, который направляет запросы промежному программному обеспечению, и очень употребляются все способности серверов.

В трехуровневой архитектуре клиент обычно не перегружен функциями обработки данных, а делает свою главную роль системы представления инфы, поступающей с сервера приложений. Таковой интерфейс можно воплотить при помощи обычных средств Web-технологии — браузера, CGI и Java. Это уменьшает размер данных, передаваемых меж клиентом и сервером приложений, что дозволяет подключать клиентские компы даже по неспешным линиям типа телефонных каналов. Не считая того, клиентская часть быть может так обычный, что почти всегда ее реализуют при помощи всепригодного браузера. Но если поменять ее все-же придется, то эту функцию можно выполнить стремительно и безболезненно.



– это программное обеспечение, являющееся промежным слоем меж клиентом и сервером (набросок 35).

Набросок 35 — приложений

Существует несколько категорий товаров промежного слоя:

Message orientated – калоритные представители MQseries и JMS;

— Object Broker – калоритные представители CORBA и DCOM;

— Component based – калоритные представители.NET и EJB.

Внедрение сервера приложений дает больше способностей, к примеру, миниатюризируется перегрузка на клиентские компы, поэтому что приложений распределяет нагрузку и обеспечивает защиту от сбоев. Потому что бизнеснесколько серверов приложений от таковых именитых компаний как Sun Microsystem, Borland, IBM, Oracle и любой из их различается набором предоставляемых сервисов (производительность в данном случае учесть не будем). Эти сервисы упрощают программирование и развертывание приложений масштаба компании. Обычно приложений предоставляет последующие сервисы:

— WEB Server – почаще всего включают в поставку самый пользующийся популярностью и мощнейший apache;

— WEB Container – дозволяет делать JSP и сервлеты. Для apache таковым обслуживанием является Tomcat;

— CORBA Agent – может предоставлять распределенную директорию для хранения CORBA объектов;

— Messaging Service – брокер сообщений;

— Transaction Service – уже из наименования понятно, что это сервис транзакций;

— JDBC – драйвера для подключения к базам данных, ведь конкретно серверу приложений придется разговаривать с базами данных и ему необходимо уметь подключаться к применяемой в вашей компании базе;

Java Mail – данный сервис может предоставлять сервис к SMTP;

— JMS (Java Messaging Service) – обработка синхронных и асинхронных сообщений;

— RMI (Remote Method Invocation) — вызов удаленных процедур.

Многоуровневые клиент-серверные системы довольно просто можно перевести на Web-технологию — для этого довольно поменять клиентскую часть всепригодным либо спец браузером, а сервер приложений дополнить Web-сервером и маленькими программками вызова процедур сервера. Для разработки этих программ можно применять как Common Gateway Interface (CGI), так и наиболее современную технологию Java.

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

Из всего вышесказанного можно прийти к выводу, что двухуровневая архитектура очень уступает многоуровневой архитектуре, потому в истинное время употребляется лишь многоуровневая архитектура «Клиент – сервер», в какой различают три модификации — RDA, DBS и AS.





Самой первой базисной технологией для локальных сетей являлась

. В свое время данная разработка была весьма посреди российских разрабов, использовавших такие системы, как FoxPro, Clipper, Clarion, Paradox и так дальше.

В модели FS функции всех 3-х компонент (компонент представления, прикладной компонент и компонент доступа к ресурсам) совмещены в одном коде, который производится на компьютере-сервере (хосте). компклиент в данной архитектуре совершенно отсутствует, а ввод и отображение данных выполняются через терминал либо комп в режиме эмуляции терминала. Приложения обычно разрабатываются на языке 4-ого поколения (4GL). один из компов в сети считается файловым сервером и предоставляет остальным компам услуги по обработке файлов. Он работает под управлением сетевых ОС и играет роль компонента доступа к информационным ресурсам. На остальных ПК в сети работает приложение, в кодах которого совмещены компонент представления и прикладной компонент.

разработка взаимодействия клиента и сервера последующая: запрос направляется на файловый , который передает СУБД, размещенной на компьютере-клиенте, требуемый блок данных. Вся обработка осуществляется на терминале (набросок 4).

протокол обмена представляет собой набор вызовов, обеспечивающих приложению доступ к файловой системе на файл-сервере.

Набросок 4 — Модель файлового сервера

Преимуществами данной технологии являются:




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



(терминалы либо дешевенькие компы с низкими чертами в режиме эмуляции терминала постоянно дешевле всеполноценных ПК ).

Но плюсы FS – модели перекрывают ее недочеты:


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



, потому что все юзеры делят его ресурсы;



.

Благодаря решению заморочек, присущих технологии «Файл – сервер» возникла наиболее прогрессивная разработка, получившая заглавие «Клиент – сервер».

Для современных СУБД архитектура «клиент-сервер» стала практически эталоном. Если предполагается, что проектируемая сетевая разработка будет иметь архитектуру «клиент-сервер», то это значит, что прикладные программки, реализованные в ее рамках, будут иметь распределенный нрав, другими словами часть функций приложений будет реализована в программе-клиенте, иная — в программе-сервере.

Различия в реализации приложений в рамках технологии «Клиент-сервер» определяются 4-мя факторами:







Исходя из этого, выделяются три подхода, любой из которых реализован в соответственной модели технологии «Клиент – сервер»:




Разглядим функции и свойства разных моделей технологии «Клиент-сервер».



– сетевая архитектура технологии «Клиент – сервер», при которой коды компонента представления и прикладного компонента совмещены и производятся на компьютере-клиенте. Доступ к информационным ресурсам обеспечивается с помощью непроцедурного языка (к примеру ,SQL – запросов для баз данных) либо вызовами функций специальной библиотеки (если имеется особый интерфейс прикладного программирования — API).

Запросы к информационным ресурсам направляются по сети удаленному компу, который обрабатывает и делает их, возвращая клиенту блоки данных (набросок 1).

Набросок 1 — Модель доступа к удаленным данным

Главным преимуществом RDA-модели является широкий выбор инструментальных средств разработки приложений, обеспечивающих резвое создание desktop-приложений, работающих с SQL-ориентированными СУБД. Обычно инструментальные средства поддерживают графический интерфейс юзера с ОС, также средства автоматической генерации кода, в каких смешаны прикладные функции и функции представления.

При всем этом RDA-модель имеет ряд ограничений.

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

Во-2-х, удовлетворительное администрирование приложений в RDA-модели фактически нереально. Если разные по собственной природе функции (функции представления и чисто прикладные функции) смешаны в одной и той же программке, написанной на языке 4-ого поколения (4GL), то по мере необходимости конфигурации прикладных функций приходится переписывать всю программку полностью.

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

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

Невзирая на обширное распространение, RDA-модель уступает пространство наиболее технологичной DBS-модели.



— сетевая архитектура технологии «Клиент – сервер», базу которой составляет механизм хранимых процедур, реализующий прикладные функции. В DBS – модели понятие информационного ресурса сужено до базы данных из-за такого же механизма хранимых процедур, который реализован в СУБД, ну и то не во всех.

В DBS-модели приложение является распределенным. Компонент представления производится на компьютере-клиенте, в то время как прикладной компонент (реализующий бизнес-функции) оформлен как набор хранимых процедур и работает на компьютере-сервере БД. Хранимые процедуры также именуют компилируемыми резидентными процедурами либо процедурами базы данных (набросок 2).

Набросок 2 — Модель сервера базы данных.

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

Во-1-х, различные процедурные расширения SQL, применяемые для написания хранимых процедур, не являются языками программирования в полном смысле слова. Они интегрированы в определенные СУБД и имеют ограниченные способности. Как следует, система, в какой прикладной компонент реализован с помощью хранимых процедур, не является мобильной относительно СУБД. В большинстве СУБД отсутствуют способности отладки и тестирования хранимых процедур, что может привести не попросту к сбою, а к полной неработоспособности всей базы данных.

Во-2-х, в DBS-модели не предусмотрены различные варианты взаимодействия клиента и сервера, нужные для децентрализация приложений, к примеру хранимые очереди, асинхронные вызовы и остальные.

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

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

Все недочеты DBS — модели учтены в AS-модели, которая в большей степени отражает мощные стороны технологии «клиент-сервер».



(набросок 3)- сетевая архитектура технологии «Клиент – сервер», представляющая собой процесс, выполняемый на компьютере-клиенте и отвечающий за интерфейс с юзером (ввод и отображение данных). Главным элементом данной модели является прикладной компонент, называющийся сервером приложения, функционирующий на удаленном компе (либо нескольких компах). приложений реализован как группа прикладных функций, оформленных в виде сервисов (служб). Любой сервис предоставляет некие услуги всем программкам, которые хотят и могут ими пользоваться.

Набросок 3 — Модель сервера приложений.

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

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

Потому что данные «спрятаны» за сервером приложений, в каком обычно встроена проверка возможностей клиента, в СУБД обеспечивается высочайший уровень защиты данных.

Доступ к информационным ресурсам, нужным для решения прикладных задач, обеспечивается как и в RDA-модели менеджером ресурсов (к примеру, SQL-). Из прикладных компонент доступны такие ресурсы как, базы данных, очереди, почтовые службы и остальные. Серверы приложений производятся, как правило, на том же компе, где работает Менеджерресурсов, что устраняет от необходимости направления SQL-запросов по сети и увеличивает производительность системы, Также серверы приложений могут производиться и на остальных компах.

AS-модель является всепригодной системой, в какой быть может сколько угодно уровней, взаимодействующих меж собой. Точное разграничение логических компонент, возможность баланса загрузки меж несколькими серверами, и оптимальный выбор программных средств для их реализации обеспечивают модели таковой уровень гибкости, защиты данных и открытости, который пока недостижим в RDA- и DBS-моделях. В AS-модели вероятна работа по неспешным линиям связи, что существенно понижает трафик меж клиентом и сервером приложений. Исходя из выше произнесенного, конкретно AS-модель является фундаментом для мониторов обработки транзакций.

Исследовав все модели технологии «Клиент – сервер», можно создать последующий вывод: RDA- и DBS-модели имеют в базе двухзвенную схему разделения функций. В RDA-модели прикладные функции отданы клиенту, в DBS-модели их реализация осуществляется через ядро СУБД. В RDA-модели прикладной компонент соединяется с компонентом представления, в DBS-модели встраивается в компонент доступа к ресурсам.

В AS-модели реализована трехзвенная схема разделения функций, где прикладной компонент выделен как важный изолированный элемент приложения, имеющий стандартизированные интерфейсы с 2-мя иными компонентами.

Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер» представлены в таблице 1.

Невзирая на свое наименования разработка «Клиент –сервер» также является системой распределенных вычислений. В данном случае

рассматриваются как архитектура «Клиент – сервер» с ролью нескольких серверов. Применительно к распределенной обработке термин «сервер» значит просто программку, отвечающую на запросы и выполняющую нужные деяния по запросу клиента. Так как распределенные вычисления — это один из видов систем «Клиент – сервер», то юзеры получают такие же достоинства, к примеру, повышение общей пропускной возможности и возможность многозадачной работы. Не считая того, Интеграция дискретных сетевых компонент и обеспечение их функционирования как одного целого содействует повышению эффективности и понижению издержек.

Потому что обработка осуществляется в любом месте сети, распределенные вычисления в архитектуре «Клиент–сервер» гарантируют действенное масштабирование. Чтоб достигнуть баланса меж клиентом и сервером, компонент приложения должен производиться на сервере лишь в том случае, когда централизованная обработка наиболее эффективна. Если случае использования низкоскоростных каналов связи.

Таблица 1 — Результаты анализа моделей технологий «Файловый сервер» и «Клиент – сервер»

Аспекты


«Файловый сервер»


«Клиент – сервер»



FS — модель


RDA-модель


DBS-модель


AS-модель



1


2


3


4


5



Сложность разработки приложений


Низкая


Низкая


Высочайшая


Высочайшая



Сложность администрирования


Низкая


Высочайшая


Высочайшая


Высочайшая



Степень защиты данных


Высочайшая


Низкая


Высочайшая


Высочайшая



Требования к чертам сервера


Высочайшие


Низкие


Высочайшие


Высочайшие



Трафик, создаваемый в сети


Маленький


Весьма высочайший


Маленький


Маленький



Сложность обновления ПО


Низкая


Высочайшая


Низкая


Низкая



Требования к чертам сети


Низкие


Весьма высочайшие


Низкие


Низкие



Распределение загрузки


Нет


Есть


Есть


Есть



Требования к чертам рабочих станций



Весьма высочайшие


Низкие


Низкие



Внедрение графического интерфейса



+


+


+



Внедрение символьного интерфейса


+


+


+


+




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




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

Для удачного внедрения технологии «Клиент-сервер» обязано употребляться соответственное программное обеспечение, включающее клиентскую и серверную части.

Программное обеспечение, установленное на сервере для управления базой данных, реагируя на запросы клиентов, начинает поиск инфы. Как часть системы «клиент-сервер» оно возвращает лишь поисковые результаты.

Обработка данных на сервере включает их сортировку, извлечение затребованной инфы и отправку ее в адресок юзера.

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

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

Инструментальные средства, приложения и утилиты для интерфейсной части дополняют способности модели «Клиент-сервер». К ним относятся средства запросов, которые упрощают доступ к данным сервера, используя предопределенные запросы и интегрированные способности для построения отчетов, пользовательские приложения, которые могут работать в качестве интерфейсной части, предоставляя доступ к серверу базы данных. Остальные приложения (такие, как Microsoft Access) имеют собственный свой SQL, который обеспечивает доступ к системам управления базами данных от различных производителей. Для реализации систем «Клиент-сервер» нужны специально разработанные интерфейсные части. Средства разработки программ (к примеру, Microsoft Visual Basic) существенно упрощают программерам и админам информационных систем создание приложений, которые отвечают за доступ к серверам базы данных.

Зависимо от выбора операционной системы (ОС) и намеченных целей определяется программное обеспечение. Так, если употребляется ОС Windows, то на компе – клиенте обычно употребляется пакет Microsoft Office, в состав которого входят текстовый машина — комплекс технических средств, предназначенных для автоматической обработки информации в процессе решения вычислительных и информационных задач) (либо вычислительной системы) которое делает арифметические и логические операции данные программкой преобразования инфы управляет вычислительным действием и коор Word, табличный микропроцессор Excel, система подготовки презентаций PowerPoint, система управления базами данных Access и программка управления информацией Outlook

В связи с фуррором распространения пакета Microsoft Office управления базами данных, SNA Server – для соединения с хост-компьютерами, Exchange Server – системы электрической почты и Internet Information Server – для работы с Internet.

Windows Server 2000/2003/2008 способна обеспечить совместное внедрение файлов, печатающих устройств, предоставить услуги по соединению с рабочими станциями (клиентскими компами) и иной сервис.

В качестве сетевой операционной системы употребляют Windows 2000/2003/2008 Server, которую можно употребляться и на рабочей станции для реализации доп способностей.

Windows Server 2000/2003/2008 обеспечивает совместное внедрение не только лишь огромного количества действий, да и ресурсов почти всеми юзерами. Возможность соединения с удаленными сетями реализуется через сервис удаленного доступа – RAS (Remote Access Service), также через средства связи с сетями остальных компаний (Novell, Digital Pathworks и Apple).

System Management Server (SMS) дозволяет сетевому админу централизованно управлять всей сетью. При всем этом обеспечивается возможность администрирования всякого компа, присоединенного к сети, включая установленное на нем программное обеспечение. SMS предоставляет разные виды сервиса, к примеру управление сетевыми приложениями и инвентаризацией программного и аппаратного обеспечения. SMS содержит в себе автоматизацию установки и распространения программного обеспечения, включая его обновление, удаленное устранение дефектов и предоставление полного контроля админу за устройствами ввода и экранами всех компов в сети.

SQL Server представляет собой систему управления реляционными базами данных, использующую принципы технологии «Клиент-сервер». MS SQL Server поддерживает систему обработки транзакций и механизм распределенных транзакций, систему сохранения ссылочной целостности и тиражирование данных.

SNA Server дозволяет нескольким настольным ПЭВМ, работающим под управлением разных операционных систем «созидать» хост-компьютеры.

Exchange Server обеспечивает средства передачи и приема сообщений в информационной сети организации. Этот сервис включает электрическую почту (E-mail) и обмен информационными сообщениями для рабочих групп. Microsoft Exchange Server построен на принципах технологии «Клиент-сервер» и масштабируется в согласовании с возрастанием вычислительных способностей сети.

Internet Information Server обеспечивает возможность сотворения Web-, FTP- и Gopher-серверов для сети Internet, поддерживает управление ими при помощи интегрированной программки Internet Service Manager.




Есть разные систематизации баз данных (БД), к примеру по степени изменчивости их можно подразделить на условно-постоянные (такие БД употребляются в главном для справочных систем) и очень оживленные (употребляются к примеру в банковских системах).

термин «сервер баз данных» обычно употребляют для обозначения всей СУБД, основанной на архитектуре «Клиент-сервер», включая и серверную, и клиентскую части. Такие системы предусмотрены для хранения и обеспечения доступа к базам данных.

Для ведения БД употребляются системы управления базами данных (СУБД), которые в значимой степени различаются друг от друга как по многофункциональным способностям, так и по эксплуатационным чертам.

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

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

Потому неважно какая СУБД не может идиентично удачно применяться при работе с БД различных классов.

Доступ к базе данных от прикладной программки либо юзера делается методом воззвания к клиентской части системы. В качестве основного интерфейса меж клиентской и серверной частями выступает язык запросов баз данных — SQL. Это язык представляет собой текущий эталон интерфейса СУБД в открытых системах. Собирательное заглавие SQL- относится ко всем серверам баз данных, основанных на SQL.

Серверы баз данных, интерфейс которых основан только на языке SQL, владеют своими преимуществами и своими недочетами. Явное преимущество – стандартность интерфейса. Недочет тоже достаточно очевиден. При таком высочайшем уровне интерфейса меж клиентской и серверной частями системы на стороне клиента работает очень не много программ СУБД. Это нормально, если на стороне клиента употребляется маломощная рабочая станция. Но если клиентский комп владеет достаточной мощностью, то нередко возникает желание возложить на него больше функций управления базами данных, разгрузив , который является узеньким местом всей системы.

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

Одним из основополагающих устройств организации обработки данных в СУБД с фактически хоть какой архитектурой, в том числе и с архитектурой «Клиент-сервер» является механизм транзакций.



— это последовательность операций над данными, которая обязана быть выполнена как целый неразделимый блок. Транзакция считается завершенной лишь тогда, когда все составляющие ее операции выполнились удачно.

При ошибке в хоть какой из составляющих транзакция считается незавершенной при всем этом происходит

— приведение данных к виду, в каком они находились до начала транзакции.

Если же все составляющие транзакции были удачно выполнены, то происходит

.

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

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



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

— коммуникационный Менеджер, контролирующий обмен сообщениями меж компонентами информационной системы;

— менеджер авторизации, обеспечивающий аутентификацию юзеров и проверку их прав доступа;

Менеджертранзакций, управляющий распределенными операциями;

— менеджер ведения журнальных записей, контролирующий восстановление и откат транзакций;

Менеджерблокировок, обеспечивающий верный доступ к вместе применяемым данным.

Обычно коммуникационный Менеджеробъединен с авторизационным, а менеджер транзакций работает вместе с менеджерами блокировок и системных записей. При этом таковой Менеджеризредка заходит в набор поставки, так как его функции (ведение записей, распределение ресурсов и контроль операций), как правило, делает сама база данных.

1-ые менеджеры транзакций возникли еще сначала 70-х годов прошедшего века и использовались еще в технологии «Файловый сервер». С приходом технологии «Клиент — сервер» они некординально поменялись идеологически, но очень значительно — технологически. Самые большие идейные конфигурации произошли в коммуникационном менеджере, потому что в данной области возникли новейшие объектно-ориентированные технологии (CORBA, DCOM и так дальше).

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



либо

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

С возникновением технологии «Клиент – сервер» и объектно-ориентированного подхода в программировании мониторы транзакций не пропали, а перебежали на наиболее современную ступень развития.


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

Являясь по существу программной прослойкой меж приложением и системой либо системами СУБД, мониторы транзакций упрощают жизнь разрабам банковских, бухгалтерских либо складских СУБД. Вначале программер делает довольно многофункциональную однопользовательскую программную версию, которая может работать как многопользовательская с условием, что параллельно будут решаться задачки производительности и логики. Мониторы транзакций разрешают вынести эти задачки на уровень админа системы, при всем этом приложение обязано быть изменено так, чтоб оно могло выдавать транзакции, написанные на языке монитора транзакций, а не обращаться прямо к базе данных средством обыденных устройств (схожих разным формам встроенного SQL). Программеры прикладных систем являются также ответственными за составление файла описания, который показывает транзакции в определенные воззвания к базе данных на родном языке воззваний нижележащей СУБД (практически для всех СУБД под unix это SQL).

Главными чертами мониторов транзакций являются:


Внедрение мониторов транзакций фактически не накладывает каких-то ограничений на обилие либо сложность запросов доступа к СУБД.


монитор транзакций представляет собой многопоточное приложение, сразу открывая собственное соединение с СУБД и устраняя необходимость выполнения каждым прикладным действием прямых запросов к СУБД. При всем этом число сразу работающих юзеров СУБД значительно сокращается, что в особенности принципиально для СУБД с реализацией «Один к одному» (набросок 5).

В СУБД с реализацией «Один к одному» для всякого клиента на сервере употребляется отдельный процесс, даже если программкаклиент на физическом уровне производится на отдельной системе. Таковым образом, для работы всякого клиентского приложения употребляются два процесса — один на сервере и один на клиентской системе. Мониторы транзакций употребляются для того, чтоб значительно понизить доп расходы на компанию управления таковым огромным количеством действий. Обычно они подразумевают наличие 1-го кластера из нескольких действий (от 1-го до 5), работающих на серверной системе. Эти процессы имеют внутреннюю многопотоковую компанию, что обеспечивает сервис запросов огромного количества клиентов.

TP-мониторы разрешают также сделать лучше производительность за счет сокращения общего размера пересылки данных, пересылаемой меж СУБД и прикладным действием за счет определенной части каждой транзакции, состоящей из мало требуемых данных. Это в особенности принципиально для загруженной сети либо сети с низкой полосой пропускания, также в глобальной сети (к примеру, Internet на спутниковых каналах связи).

Одним из современных мониторов транзакций является

Microsoft Transaction Server обеспечивает поддержку транзакций, служб масштабирования, управления подключениями и администрирования, которые разрешают создавать и развертывать масштабируемые серверные приложения, делая при всем этом управление транзакциями прозрачным для разраба компонент.

Ни утилиты для серверов БД, ни распределенные СУБД, ни средства сотворения серверов приложений для новейших версий пакетов разработки передних систем, ни ПО передачи сообщений (ПО доставки сообщений в обсужденный интервал времени и частичной поддержки транзакций) не могут полностью поменять мониторы транзакций.

Набросок 5 – Конфигурация СУБД с архитектурой «Клиент-сервер» для работы с мониторами обработки транзакций.

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







С возникновением глобальных сетей многоуровневая архитектура «Клиент – сервер» отыскала свое применение в Internet. Иными словами, архитектура Internet не что другое, как архитектура «Клиент – сервер»: юзер постоянно работает с программкой — клиентом (Internet Explorer либо Netscape Navigator), которая обращается к web-серверам, обслуживающим сразу 10-ки и сотки запросов от клиентов по всему миру.



повсевременно соединены с глобальной сетью и готовы предоставлять сервис (к примеру, пересылать почту), отвечая при всем этом на 10-ки и сотки запросов сразу. Web — серверы защищены от сбоев электропитания и работают обычно под одной из модификаций ОС UNIX.



— индивидуальные компы, на которых установлены браузеры для поиска инфы в сети Internet. Таковой комп не соединен с глобальной сетью повсевременно, а подключается при необходимости.

Кроме клиентов-браузеров бывают и остальные клиенты, к примеру, клиенты электрической почты (Outlook Express, Netscape Messenger, The Bat, Pegasus Mail, Pine, Eudora и остальные.), клиенты для приема и передачи файлов (ftp-клиенты), telnet-клиенты, которые нужны для интерактивной работы на удаленном узле (простой telnet-клиент — программка telnet.exe) и почти все остальные.



также многообразны: web – , DNS – , ftp-сервер (для передачи файлов), приложений (для удаленной работы с приложениями), электрической почты и остальные.

Разработка «Клиент – сервер» для Internet организована последующим образом (набросок 55):


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


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

На сервере располагаются web-документы, которые визуализируются и интерпретируются программкой навигации (к примеру, web-браузер), функционирующей на рабочей станции.


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

Цикл повторяется, пока юзер не окончит работу с сервером.

Риунок 55 — разработка «Клиент – сервер» для Internet

В сервисе WWW для передачи инфы применяется протокол НТТР, при работе которого не имеет никакой инфы о состоянии браузера. При всем этом вести взаимодействие с сервером может быть лишь через механизм URL, это делает некие трудности при реализации клиентской части. Схема передачи инфы по протоколу НТТР состоит из последующих шагов (набросок 56):

браузер конвертирует доменное имя из URL в IP-адрес и устанавливает соединение с сервером;

— браузер передает остальную часть URL на ;

описывает по URL путь и название файла, по мере необходимости сформировывает его динамически;

пересылает файл браузеру;

— сервер разрывает соединение;

— браузер показывает документ.

Существует огромное количество технологий и языков программирования для написания серверных и клиентских Internet – приложений. В истинное время огромное распространение получила разработка Java, при помощи которой можно строить всепригодные системы со смешанной архитектурой, приложения, выполняемые на стороне клиента, именуются апплетами (applets), на стороне сервера — сервлетами (servlets). Довольно большенный популярностью пользуется Flashтехнология, в рамках которой можно создавать медиа-насыщенные интерактивные ресурсы, основная рабочая перегрузка при всем этом ложится на комп юзера.

Набросок 56. — Схема работы по HTTP в архитектуре «Клиент-сервер» для Internet

При помощи CGI (Common Gateway Interface) приложений может быть взаимодействие с хоть какими базами данных через формирование SQL запросов, либо остальные механизмы; также вероятна реализация счетчиков посещений, гостевых книжек и остальных расширений. CGI реализуется через скрипты на любом из языков программирования высочайшего уровня (более нередко употребляют С++, Perl, VisualBasic, Pascal, Java).

Server Sides Includes (SSI/SSI+) — разработка динамического формирования документов (в том числе и работы с БД). Скрипт (поточнее серверные аннотации) находится в html файле обычно имеющем расширение sht либо shtm, при всем этом серверные аннотации располагаются меж особыми разделителями (tokens), а сами аннотации записаны на языке Сscript, хотя это в основном зависит фактически от сервера. При пересылке таковой файл сканируется сервером на наличие SSI инструкций и итог динамически подставляется в посылаемый документ. SSI реализуется через особые составляющие (динамические библиотеки), которые входят в состав сервера. По аналогичному принципу организована работа со скриптами на языке PHP, в этом случае, программные конструкции врубаются в HTML при помощи разделителей <? php и ?>.

Идентичной по технике формирования динамических страничек является разработка Active Server Pages (ASP) от Microsoft. Данная разработка опирается на внедрение различных объектов и компонент (COM, activeX и тому схожее), работа с которыми ведётся средствами языков VBScript либо JavaScript.

Internet Server Application Programming Interface (ISAPI), реализуется через механизм DLL. C помощью ISAPI Internet connector может быть взаимодействие с базами данных (SQL Server, Oracle, RBase, Access, Paradox, dBASE) через драйверы Open Database Connectivity (ODBC), также вероятна реализация остальных расширенных функций (создание разных фильтров запросов). Главным средством разработки приложений является Microsoft Visual C++ (The Internet Server API JavaScript, VBScript, SGML, HTML, XML и остальные языки, направленные на описание структур документов.







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



— личная компьютерная сеть, являющаяся внутренней web-системой, локализованной в границах одной организации, в какой употребляются эталоны и протоколы Internet (сервисы Web, TCP/IP, HTTP, протоколы связи и HTML – странички). Иными словами,

– это личная, защищенная внутрикорпоративная сеть, при построении которой употребляются технологии Internet, доступная лишь сотрудникам организации, при этом независимо от их физического местопребывания, ведь для доступа в Intranet сети употребляется Internet как транспорт

термин «Intranet» в первый раз возник 19 апреля 1995 году в журнальчике Digital News & Review.

Для преобразования локальной либо региональной компьютерной сети в Intranet не будет нужно распродавать старенькое оборудование, возможно обойтись уже существующими ресурсами.

Архитектура Intranet базирована на архитектуре «Клиент-сервер» (набросок 57).

В качестве клиентских программ употребляются браузеры. При конфигурациях функциональности корпоративной информационной системы обновление клиентского ПО не требуется. Web- выступает в качестве сервера приложений. клиент и ведут взаимодействие обычно по локальной сети, где есть выход в Internet через брандмауэр. Брандмауэром (firewall) – это комп с установленным на нем особом программным обеспечением, позволяющим:

— идентифицировать хоть какого входящего снаружи юзера, чтоб запретить либо разрешить ему доступ;

— аудит и протоколирование вхождений — запись, кто, когда и для чего заходил во внутреннюю сеть;

— тайнописью — шифрование скрытой инфы.

— экранирование — возможность однобокой передачи данных.

Набросок 56 – Простая схема Intranet с архитектурой «Клиент – сервер»

наличие диалоговых параметров в HTML и интерфейса CGI дозволяет строить Internet-приложения с доступом к БД. Более всераспространена схема динамической публикации отчетов. При всем этом в качестве CGI-процедуры употребляется параметризуемый генератор отчетов. Но это не единственная схема, может быть использовать программки ввода и обновления инфы в БД.

Если употребляются классические статичные странички гипертекста, то в ответ на запрос клиента Web-сервер передает страничку в формате html. При работе с базой данных клиент показывает в форме программку либо сценарий для пуска на сервере. Серверная процедура получает введенные юзером данные, сформировывает и передает SQL-запрос (определяющий логику управления данными) и, может быть, данные к СУБД. БД по запросу делает обновление, вставку, удаление либо подборку записей из БД. CGI-процедура конвертирует приобретенные результаты в формат HTML либо в формат диалоговых переменных. Потом Web- отправляет полученную html-cтраницу либо значения диалоговых переменных браузеру для отображения.

Внедрение CGI-процедур имеет ряд недочетов – статичное файл, отсутствие динамического просмотра конфигурации инфы в базе данных, процедура «не помнит состояний запросов» – каждое воззвание к БД просит повторного установления соединения. Не считая того, таковой принцип работы перегружает коммуникационную среду и имеет системные Издержки при запуске серверных действий.

Для устранения недочетов CGI употребляют способности особых API для Web-серверов и включают доп «релейное» звено в архитектуру. Все это лишь подталкивает к предстоящему совершенствования архитектуры «Клиент-сервер».

Intranet имеет 5 главных функций:

— электрическая почта;

— совместное внедрение файлов;

— каталогизация;

— кросс-платформенная сопоставимость;

— поиск и управление сетью.

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

Главные плюсы Intranet:


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


Web, благодаря поддержке открытых эталонов, просто встраивается в уже существующую гетерогенную среду, сохраняя Издержки на аппаратное обеспечение.



;

Web, как средство доступа к базам данных и приложениям, меняет обычное отношение к архитектуре «Клиент – сервер». Используя браузер, как средство доступа к корпоративной сети, юзер получает единый инструмент для работы с базами данных, приложениями и разными иными службами.


По сопоставлению с классическими способами разработки, дистрибуции и поддержки приложений «Клиент – сервер» Издержки при использовании Intranet Web-технологии довольно низкие. К примеру, в Web-приложениях, работающих с базами данных, используя Web-браузер как единый интерфейс, значительно понижается стоимость разработки и сопровождения программного обеспечения клиентской части.


Используя гибкие и массивные механизмы защиты можно выстроить Intranet-сеть той степени защищенности, которая нужна.


Для заслуги такового уровня производительности в сети употребляется один из основополагающих принципов построения Intranet — наращиваемость.

Недочеты Intranet:

— легкий доступ к корпоративным данным может спровоцировать их утечку к соперникам через нерадивого работника;

— работоспособность и упругость Интранет требуют значимых затратных расходов на разработку и администрирование;

— Intranet, как и неважно какая сеть быть может взломана и применена в алчных целях.

]]>