Реферат: Архитектура аппаратно-программных средств распределенной обработки информации для интранет-технологии - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Архитектура аппаратно-программных средств распределенной обработки информации для интранет-технологии

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 67 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

20 МОСКОВСКИЙ ИНСТИТУТ РАД ИОТЕХНИКИ , ЭЛЕКТРОНИКИ И АВТОМАТИКИ (ТУ ) Курсовая работа по предмету системн ое программное обеспечение Тема : Архитектура аппаратно-программных средст в распределенной обработки информации для инт ранет-технологии . Студента группы ВВ -22-95 Головченко В. Преподаватель Малыгина О.П. Москва 1998 Содержание 1. Архитектура “клиент-сервер” 1.1. Открытые системы 1.2. Клиенты и серверы локальных сетей 1.3. Системная архитектура “клиент-сервер” 1.4. Серверы баз данн ых 1.5. Принципы взаимодействия между клиен тскими и серверными частями 1.6. Преимущества протоколов удаленного вызова процедур 1.7. Типичное разделение функций между кли ентами и серверами 1.8. Архитектуры процессора б азы данны х 2. Трехуровневая архитектура “клиент-сервер” 3. Программные средства разработки 3.1. Универсальные средства 3.2. Персональные СУБД 4. Intranet и архитектура “клиент-сервер”. 4.1. Двухуровневая архитектура “клиент-сервер ” 4.2. Трехуровневая архитектура “клиент-сервер” 4.2.1. Программы расширения серверной части 5. Пример базы данных 1. Архитектура "клиент-сервер " Применительно к системам баз данных архитектура "клиент-сервер " интересна и акту альна главным образо м потому , что обеспечивает простое и относ ительно дешевое решение проблемы коллективного доступа к базам данных в локальной сет и. 1.1. Открытые системы Реальное распространение архитект уры "клиент-сервер " стало возможным благодаря р аз витию и широкому внедрению в практи ку концепции открытых систем . Поэтому мы н ачнем с краткого введения в открытые сист емы . Основным смыслом подхода открытых систем является упрощение комплексирования вычислитель ных систем за счет международной и национ ал ьной стандартизации аппаратных и програ ммных интерфейсов . Главной побудительной причиной развития концепции открытых систем явились повсеместный переход к использованию локальн ых компьютерных сетей и те проблемы компл ексирования аппаратно-программных сред с тв , которые вызвал этот переход . В связи с бурным развитием технологий глобальных комм уникаций открытые системы приобретают еще бол ьшее значение и масштабность . Ключевой фразой открытых систем , направле нной в сторону пользователей , является незави симость от конкретного поставщика . Ориентиру ясь на продукцию компаний , придерживающихся с тандартов открытых систем , потребитель , который приобретает любой продукт такой компании , н е попадает к ней в рабство . Он может продолжить наращивание мощности своей системы путем приобретения продуктов любой другой компании , соблюдающей стандарты . Причем это касается как аппаратных , так и пр ограммных средств. Практической опорой системных и прикладны х программных средств открытых систем являетс я стандартизованная операционн ая система . В настоящее время такой системой является UNIX. Фирмам-поставщикам различных вариантов ОС UNIX в результате длительной работы удалось придти к соглашению об основных стандартах этой операционной системы . Сейчас все распростран енные версии UNIX в основном совместимы по части интерфейсов , предоставляемых прикла дным (а в большинстве случаев и системным ) программистам . Как кажется , несмотря на п оявление претендующей на стандарт системы Windows NT, именно UNIX останется основой открытых систем в бли ж айшие годы . Технологии и стандарты открытых систем обеспечивают реальную и проверенную практикой возможность производства системных и приклад ных программных средств со свойствами мобильн ости (portability) и интероперабельности (interoperability). Свойств о мобильности означает сравнительную простоту переноса програм мной системы в широком спектре аппаратно-прог раммных средств , соответствующих стандартам . Интероперабельность оз начает упрощения комплексирования новых программ ных систем на основе использования гото вых компонентов со стандартными интерфейсами . Преимуществом для пользователей является то , что они могут постепенно заменять комп оненты системы на более совершенные , не ут рачивая работоспособности системы . В частности , в этом кроется решение проблем ы по степенного наращивания вычислительных , информационных и других мощностей компьютерной системы . 1.2. Клиенты и серверы локаль ных сетей В основе широкого распростран ения локальных сетей компьютеров лежит извест ная идея разделения ресурсов . Высокая про пускная способность локальных сетей обесп ечивает эффективный доступ из одного узла локальной сети к ресурсам , находящимся в других узлах . Развитие этой идеи приводит к функцио нальному выделению компонентов сети : разумно иметь не только доступ к ресурсами удаленного компьютера , но также получать от этого компьютера некоторый сервис , который специфичен для ресурсов данного рода и пр ограммные средства . Так мы приходим к разл ичению рабочих станций и серверов локальной сети . Рабочая станция предназначена для непосредственной рабо ты пользователя или категории пользователей и обладает ресурсами , соответствующими локальным потребностям данного пользователя. Сервер локально й сети должен обладать ресурсами , соответству ющими его функциональному назначению и потре бностям сети . Заметим , что в связи с ориентацией на подход открытых систем , п равильнее говорить о логических серверах (име я в виду набор ресурсов и программных средств , обеспечивающих услуги над этими ре сурсами ), которые располагаются не обязательно на ра з ных компьютерах . Особенностью логического сервера в открытой системе я вляется то , что если по соображениям эффек тивности сервер целесообразно переместить на отдельный компьютер , то это можно проделать без потребности в какой-либо переделке как его самого, так и использующих его прикладных программ . Примерами сервером могут служить : • сервер телекоммуникаций , обеспечивающий усл уги по связи данной локальной сети с внешним миром ; • вычислительный сервер , дающий возможность производить вычисления , которые нев озможно выполнить на рабочих станциях ; • дисковый сервер , обладающий расширенными ресурсами внешней памяти и предоставляющий их в использование рабочим станциями и , возможно , другим серверам ; • файловый сервер , поддерживающий общее х ранилище файлов для все х рабочих стан ций ; • сервер баз данных фактически обычная СУБД , принимающая запросы по локальной сети и возвращающая результаты . Сервер локальной сети предоставляет ресур сы (услуги ) рабочим станциям и /или другим серверам . Принято называть клиентом лока льной сети , запрашивающий услуги у некоторого с ервера и сервером - компонент локальной сети , оказывающий услуги некоторым клиентам . 1.3. Системная архитектура "клиент- сервер " Понятно , что в общем случа е , чтобы прикладная программа , выполняющаяся н а рабо чей станции , могла запросить усл угу у некоторого сервера , как минимум треб уется некоторый интерфейсный программный слой , поддерживающий такого рода взаимодействие (был о бы по меньшей мере неестественно требов ать , чтобы прикладная программа напрямую поль зо в алась примитивами транспортного ур овня локальной сети ). Из этого , собственно , и вытекают основные принципы системной архите ктуры "клиент-сервер ". Система разбивается на две части , кото рые могут выполняться в разных узлах сети , - клиентскую и серверную ча сти . Прикла дная программа или конечный пользователь взаи модействуют с клиентской частью системы , кото рая в простейшем случае обеспечивает просто надсетевой интерфейс . Клиентская часть систе мы при потребности обращается по сети к серверной части . Заметим , ч то в развитых системах сетевое обращение к серв ерной части может и не понадобиться , если система может предугадывать потребности поль зователя , и в клиентской части содержатся данные , способные удовлетворить его следующий запрос . Интерфейс серверной части определен и фиксирован . Поэтому возможно создание нов ых клиентских частей существующей системы (пр имер интероперабельности на системном уровне ). Основной проблемой систем , основанных на архитектуре "клиент-сервер ", является то , что в соответствии с конц епцией открытых систем от них требуется мобильность в как можно более широком классе аппаратно-прог раммных решений открытых систем . Даже если ограничиться UNIX-ориентированными локальными сетями , в разных сетях применяется разная аппара тура и протоколы св я зи . Попытки создания систем , поддерживающих все возможные протоколы , приводит к их перегрузке сетев ыми деталями в ущерб функциональности . Еще более сложный аспект этой проблем ы связан с возможностью использования разных представлений данных в разных узла х неоднородной локальной сети . В разных ком пьютерах может существовать различная адресация , представление чисел , кодировка символов и т.д . Это особенно существенно для серверов высокого уровня : телекоммуникационных , вычислител ьных , баз данных . Общим реше нием проблемы мобильности систем , основанных на архитектуре "клиент-серв ер " является опора на программные пакеты , реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При и спользовании таких средств обращение к сервис у в удаленно м узле выглядит как о бычный вызов процедуры . Средства RPC, в которых , естественно , содержится вся информация о сп ецифике аппаратуры локальной сети и сетевых протоколов , переводит вызов в последовательн ость сетевых взаимодействий . Тем самым , специф ика сете в ой среды и протоколов скрыта от прикладного программиста . При вызове удаленной процедуры программы RPC производят преобразование форматов данных к лиента в промежуточные машинно-независимые формат ы и затем преобразование в форматы данных сервера . При пере даче ответных параме тров производятся аналогичные преобразования . Если система реализована на основе стандартного пакета RPC, она может бы ть легко перенесена в любую открытую сред у . Технология “клиент-сервер” применительно к СУБД сводится к разделению системы на две части – приложение-клиент (front-end) и серве р базы данных (back-end). Эта архитектура совмещает лучшие черты обработки данных на мэйнфрейм ах и технологии “файл-сервер” . От мэйнфреймов технология “клиент-сервер” позаимствовала такие черты, как централизованное администр ирование , безопасность , надежность . От технологии “файл-сервер” унаследованы низкая стоимость и возможность распределенной обработки данных , используя ресурсы компьютеров-клиентов . Сейчас графический интерфейс пользователя ст а л стандартом для систем “клиент-сервер” . Кроме того , архитектура “клиент-сервер” значите льно упрощает и ускоряет разработку приложени й за счет того , что правила проверки ц елостности данных находятся на сервере . Непра вильно работающее кли ентское приложени е не может привести к потере или искаже нию данных . Все эти возможности , ранее свойственные только сложным и дорогостоящим системам , сейчас доступны даже небольшим организациям . Стоимость оборудования , про граммного обеспечения и обслуживания для персональ н ых компьютеров в десятки раз ниже , чем для мэйнфреймов. Особенности обработки данных в различных архитектурах по казаны на рис .1. Рис .1. Обработка данных в различных арх итектурах Локальный компьютер Локальное приложение СУБД Данные Архитектура “файл-сервер” Клиент Файл-сервер Сетевое приложение Д анные СУБД Клиент пересылка Сетевое приложение данных СУБД Архитектура “клиент-сервер” Сервер БД Клиентское СУБД приложение Данные Клиентское прилож ение пересылка запросов и результатов 1.4. Серверы баз данных Термин "сервер баз данных " обычно используют д ля обозначения всей СУБД , основанной на архитектуре "клиент-сервер ", включая и серверную , и клиентскую части . Такие системы предназначены для хранения и обеспечения доступа к базам данных . Хотя обычно одна база данных целиком хранится в одном узле сети и по ддерживается одним сервером , серверы баз данн ых представляют собой простое и дешевое п риближение к распределенным базам данных , пос кольку общая база данных доступна для все х пользователей локальной сети . 1.5. Принципы взаимодействия межд у клиентскими и серверными частями Доступ к базе данных от прикладной программы или пользователя производ ится путем обращения к клиентской части с истемы . В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Это язык по с ути дела пре дставляет собой текущий стандарт интерфейса С УБД в открытых системах . Собирательное назван ие SQL-сервер относится ко всем серверам баз данных , основанных на SQL. Серверы баз данных , интерфейс которых основан исключительно на языке SQL, облада ют своими преимуществами и своими нед остатками . Очевидное преимущество – стандартност ь интерфейса . В пределе , хотя пока это не совсем так , клиентские части любой SQL-ори ентированной СУБД могли бы работать с люб ым SQL-сервером вне зависимости от того , кто е го произвел. Недостаток тоже довольно очевиден . При таком высоком уровне интерфейса между клие нтской и серверной частями системы на сто роне клиента работает слишком мало программ СУБД . Это нормально , если на стороне к лиента используется маломощная рабочая стан ция . Но если клиентский компьютер обладает достаточной мощностью , то часто возникает ж елание возложить на него больше функций у правления базами данных , разгрузив сервер , кот орый является узким местом всей системы . Одним из перспективных направлений СУБД является гибкое конфигурирование системы , при котором распределение функций между кл иентской и пользовательской частями СУБД опре деляется при установке системы . 1.6. Преимущества протоколов удал енного вызова процедур Упоминавшиеся выше протоколы уд аленно го вызова процедур особенно важны в систе мах управления базами данных , основанных на архитектуре "клиент-сервер ". Во-первых , использование механизма удаленных процедур позволяет действительно перераспределять функции между клиентской и серверной ча стями системы , поскольку в тексте прог раммы удаленный вызов процедуры ничем не отличается от удаленного вызова , и следовател ьно , теоретически любой компонент системы мож ет располагаться и на стороне сервера , и на стороне клиента . Во-вторых , механизм удал енного вызова скрывает различия между взаимодействующими к омпьютерами . Физически неоднородная локальная сет ь компьютеров приводится к логически однородн ой сети взаимодействующих программных компоненто в . В результате пользователи не обязаны се рьезно заботи т ься о разовой закуп ке совместимых серверов и рабочих станций . 1.7. Типичное разделение функций между клиентами и серверами В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение , которое не имеет непо средственного доступа к база м данных , а обращается для этого к сер веру с использованием языка SQL. В некоторых случаях хотелось бы включ ить в состав клиентской части системы нек оторые функции для работы с "локальным кэш ем " базы данных , т.е . с той ее част ью , которая интенсивно используется клиен тской прикладной программой . В современной те хнологии это можно сделать только путем ф ормального создания на стороне клиента локаль ной копии сервера базы данных и рассмотре ния всей системы как набора взаимодействую щ их серверов . С другой стороны , иногда хотелось бы перенести большую часть прикладной системы на сторону сервера , если разница в мо щности клиентских рабочих станций и сервера чересчур велика . В общем-то при использов ании RPC это сделать нетрудно . Но требу ет ся , чтобы базовое программное обеспечение сер вера действительно позволяло это . В частности , при использовании ОС UNIX проблемы практически не возникают . 1.8. Архитектуры процессора базы данных. Основная часть любой системы “клиент-сервер” – это сервер БД . Со времени возникновения архитектуры “клиент-сервер ” появилось много вариантов архитектуры проце ссора БД , поскольку он во многом определяе т успех всей системы . Основное требование к серверу БД – обеспечение минимального времени выполнения запросов пр и мак симально возможном числе пользователей . Существую т две основные архитектуры для построения процессора БД : архитектура с несколькими пр оцессами и многопоточная архитектура . 1. Архитектура с нескольк ими процессами Характеризуется тем , что несколько экз емпляров исполняемого файла работают одно временно . Эти системы отличаются хорошей масш табируемостью , но требуют значительных расходов памяти , так как память каждому экземпляру приложения выделяется отдельно . Эта архитектура подразумевает наличие эффективн о го механизма взаимодействия процессов и полагае тся на операционную систему при разделении процессорного времени между отдельными экземпл ярами приложения . Самый известный пример серв ера , построенного по этой архитектуре , - Oracle Server. Ког да пользователь подключается к БД Oracle, он в действительности запускает отдельный экземпляр исполняемого файла процессора базы данных. 2. Многопоточная архитектура Эта архитектура использует только один исполняемый файл , с несколькими потоками ис полнения . Главное преиму щество – более скромные требования к оборудованию , чем для архитектуры с несколькими процессами . Здесь сервер берет на себя разделение времени между отдельными потоками , иногда давая п реимущество некоторым задачам над другими . Кр оме того , отпадает необход и мость в сложном механизме взаимодействия процессов . По этой архитектуре построены MS SQL Server и Sybase SQL Server. 2. Трехуровневая архитектура “клиент-сервер” На верхнем уровне абстрагиров ания взаимодействия клиента и сервера достато чно четко можно выделить следующие комп оненты : • презентационная логика (Presentation Layer - PL ), предназначенная для ра боты с данными пользователя ; • бизнес-логика (Business Layer - BL ), предназначенная для проверки правил ьности данных , поддержки ссылочной целостности .. ; • логика доступа к ресурсам (Access Layer - AL ), предназначенная для хранения данных ; Таким образом можно , можно придти к нескольким моделям клиент-серверного взаимодействи я : 1. "Толстый " клиент. (fat client) Сервер БД Пользовательский интерфейс Данные Бизнес-логика Пользовательский интерфейс Бизнес-логика Наиболее часто встречающийся ва риант реализации архитекту ры клиент-сервер в уже внедренных и активн о используемых системах . Такая модель подразу мевает объединение в клиентском приложении ка к PL, так и BL, таким образом обеспечивается по лная децентрализация управления бизнес-логикой . Од н ако в случае необходимости выпол нения каких-либо изменений в клиентском прило жении придется менять исходный код . Серверная часть , при описанном подходе , представляет собой сервер баз данных , реализующий AL. К описанной модели часто применяют аббревиатуру R DA - Remote Data Access. 2 . "Тонкий " клиент. (thin client) Бизнес - Л огика Пользовательский интерфейс Данные Пользовательский интерфейс Модель , начинающая активно использоваться в корпоративной среде в связи с распространением Internet-технологий и , в первую очередь , Web-браузеров . В этом случае клиентское приложение обеспечивает реализ ацию PL , поэтому клиент может довольствовать ся довольно скромной аппаратной платформой , а сервер объединяет BL и AL. Максимальная загрузка сервера предусматривает выполнение бизнес-логики только с помощью хранимых процедур серве ра ( Хранимые процедуры – откомпилир ованные SQL-инструкции , хранящиеся на сервере ). Это позволяет мак симально централизовать контроль над данными и легко изменять правила работы сразу для целого предприятия . С другой стороны , нез начительная корректировка правил , касающаяся толь ко части поль з ователей , потребует длительной процедуры согласования . В этом слу чае невозможно реализовать какие-то исключения из общих правил для некоторых пользователе й или приложений . В принципе , это хорошо и является залогом безопасности и целостно сти данных . 3. Сервер бизнес-логики . (т рехуровневая архитектура ) Промежуточный сервер Пользовательский Бизн ес-логика интерфейс второго уровня Серв ер БД Пользовательский Бизнес-логика интерфейс сервера Данные Модель с физич ески выделе нным в отдельное приложение блоком BL, таким образом получаем трехуровневую архитектуру “клиент-сервер” . На сервере БД м ожет функционировать “универсальная” часть бизне с-логики (правила на уровне предприятия или группы связанных приложений ). Такая схема п о зволяет поддерживать тонких клиентов на пользовательских компьютерах и в то же время разгрузить сервер БД от чрезм ерной загрузки при сохранении гибкой системы работы с бизнес-правилами . В качестве про межуточного сервера может использоваться второй SQL-сер в ер , но чаще рациональней задействовать персональную СУБД , которая менее требовательна к аппаратным ресурсам и мо жет обеспечить удобные средства построения и поддержки бизнес-логики. 3. Программные средства разработки 3.1. Универсальные средства Для разработки клиентских приложений существует громадное число универсальных пакет ов программ , которые позволяют выполнить соед инение с сервером и разработать для польз ователя удобный графический интерфейс , позволяющи й эффективно работать с данными . Неко т орые из этих средств для разработки прило жений в архитектуре “клиент-сервер” перечислены в таблице. Наименование Краткая характеристика CA-OpenROAD Полнофункциональная объектно-ориентированная сред а для разработки приложений на основе язы ка четвертого п околения 4GL. Delphi Client/Server Универсаль ный пакет для разработки клиентских приложени й . Обеспечивает объектно-ориентированную разработку с использованием визуальных средств . Поддержива ет групповую работу над приложением . Magic 6.0 Таблично-управл яемы й инструментарий для разработки трехуровневых приложений “клиент-сервер” . MS Visual Basic 5.0 Универсальный пакет разработки пользовательских приложений . Обеспечива ет визуальное построение форм и компиляцию приложения . В полном объеме поддерживаются OLE 2.0 и OLE Automation. Для работы с данными предн азначен визуальный инструментарий Visual Database Tools. PowerBuilder 4.0 Объектно-ориентированное средство разработки приложений “клиент-сервер” . Имеет мощные визуальные средства ; поддерживает стандарт ы OLE и ODBC. Progress 8 П акет поддерживает компонентную объектно-ориентированн ую разработку приложений . Используется новая технология SmartObject и среда компонентов приложения (ACE). SAS System Обеспечивает инстру ментарий для доступа , управления , анали за и представления данных в приложении для громадного числа систем и компьютерных п латформ , включая мэйнфреймы . Имеет 35 видов инте рфейса для различных систем и язык програ ммирования четвертого поколения . Поддерживает ODBC. Uniface Six Независимая среда р азработки . Поддерж ивает управление на уровне модели и компо нентное программирование . Имеет мощные визуальные средства . Допускает групповую разработку . Име ет интерфейс к более чем 30 серверам БД на различных платформах. 3.2. Персональные СУБД. Для разраб отки клиентских приложений в большинстве случаев вместо универсальных средств разработки удобнее использ овать персональные СУБД . Использование персональн ых СУБД позволяет не только эффективно ор ганизовывать работу с бизнес-правилами , но и поддержать незав и симую работу клие нтского приложения за счет наличия собственны х форматов хранения данных . Краткая характери стика некоторых персональных СУБД приведена в таблице. Наименование Краткая характеристика Lotus Approach 97 Позволяет выполня ть все виды обработки данных . Имеет очень простой интерфейс . СУБД тесно интегриро вана с базами данных Notes и электронными таб лицами Lotus 1-2-3. Поддерживает технологию электронного о бмена сообщениями MAPI. MS Access 97 П олнофункциональная СУБД , обладающая богатым набор ом ви зуальных средств , многочисленными ма стерами и мощным языком программирования Visual Basic for Applications. Имеет гибкую систему подготовки отчетов . Поддерживаются технологии ODBC и OLE 2.0. СУБД тесно интегрирована со всеми приложениями MS Office. MS Vi sual FoxPro 5 Одна из наиболее быстрых персональных СУБД , сочетающая технологи ю xBase и объектно-ориентированный язык программирован ия . Имеет богатый набор визуальных средств разработки и мастеров для быстрого построе ния приложений и отчетов . Поддерживаютс я технологии ActiveX, ODBC и OLE 2.0. Позволяет создавать OLE-серв ера и имеет очень развитые средства разра ботки и поддержки приложений “клиент-сервер”. Paradox 7 Поддерживает все ви ды работы с данными . Для визуального выпол нения стандартных задач имеется специальное средство Experts. Наделен собственным достаточно с ложным языком ObjectPAL. Поддерживает технологии OLE 2.0, ActiveX, MAPI и ODBC. 4. Intranet и архитектура “клиент-сервер”. 4.1. Двухуровневая архитектура “клиент-серве р” Web-броузер Источник данных Web- сервер NOS (Network Operation System) Разграниче ние функций меж ду Web-броузером и Web-сервером является очень четким . Web-сервер предоставляет HTML-страницы , а бро узер отображает эти страницы путем интерпрета ции тегов HTML. 4.2. Трехуровневая архитектура “к лиент-сервер” Web-броузер Источник данных Третий уровень Программа расширения сервера HTML Web-сервер NOS Клиентский уровень занимает броузер , на уровне сервера находится сервер БД , а н а промежуточном ур овне располагаются Web-сер вер и программа расширения сервера . Такое архитектурное решение позволяет уменьшить сетево й трафик , делает компоненты взаимозаменяемыми и повышает уровень безопасности . Однако такая архитектура также затрудняет обработку транз акц и й БД ввиду природы протокола HTTP, не запоминающего состояния (этот протокол использует для передачи данных между броуз ером и сервером БД ). Броузер посылает Web-серверу запросы на доставку Web-страниц или данных . Web-сервер обслужи вает заявки на Web-страни цы , а запросы отправляет программе-расширению серверной части . Последняя принимает передаваемые ей запросы , преобразует их в форму , понятную серверу БД , и передает их серверу БД. Затем сервер БД выполняет работу по обслуживанию запроса и возвращает результ ат программе-расширению серверной части . Н аконец та преобразует результаты в формат , приемлемый для броузера , и передает их Web-серверу , а тот в свою очередь – броу зеру. 4.2.1. Программы расширения серверн ой части Одной из главных причин и спользования п рограмм-расширений серверной ча сти на промежуточном уровне является возможно сть использовать стандарты , существующих для двух крайних уровней , путем осуществления тра нсляции между ними . Другие применения расшире ний серверной части состоят в поддержании со е динений между БД с целью уменьшить трафик в сети и в поддержани и резерва соединений между БД для уменьше ния затрат ресурсов на открытие /закрытие БД . Расширения серверной части также поддержи вают взаимозаменяемость в своих стандартных и нтерфейсах . Поэтому W eb-серверы и сер веры БД можно сравнительно легко заменять или наращивать. Существует три категории расширений серве рной части : с обычным CGI, с гибридным CGI и с API. 5. Пример базы данных Пример базы данных см . в прилагаемом к курсовой работе техниче с ком задании. Источники : 1. А.Горев , С.Макашарипов , Ю.Вла димиров “ SQL Server 6.5 для профе ссионалов” Изд . “Питер” Санкт-Петербург 1998 2. К.Ланг , Д.Чоу “Публикация баз данных в Интернете” Изд . “Символ-Плюс” Санкт-Петербург 1998 3. Д.Боуман , C.Эмерсон , М.Дарновс ки “Практическое руко водство по SQL” Изд . “Диалектика” Киев 1997 4. Microsoft Press “Секреты создания интрасетей” Изд . “Питер” Санкт-Петербург 1998 5. http:\\www.citforum.ru
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Мысли как протон: будь всегда позитивным!
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

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

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru