Основные  виды архитектур приложений

Оглавление:

Введение: 3

Клиент-сервер 4

Модель сервиса (один сервис - много серверов) 4

Технология подключения через proxy 5

Сервер инициирует соединение 6

Мобильные агенты 7

Тонкий клиент 7

Трехзвенная архитектура 8

Архитектура P2P (Peer - to Peer) 9

Литература: 10 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Введение:

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

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

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

      Архитектура программы или компьютерной системы - это структура или структуры  системы, которые включают элементы программы, видимые извне свойства этих элементов и связи между ними. [Басс (Bass)]

      Архитектура программного обеспечения системы  или набора систем состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые  составляют системы. Проектные решения  обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения  предоставляют концептуальную основу для разработки системы, ее поддержки  и обслуживания. [Мак-Говерн (McGovern)]

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

Клиент-сервер

 

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

Рис. 1.1. Архитектура "клиент - сервер" 

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

Модель  сервиса (один сервис - много серверов)

 

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

Рис. 1.2. Модель сервиса 

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

Технология  подключения через  proxy

 

      Примером  системы, построенной в такой  архитектуре, является привычная система  из браузера, прокси-сервера и веб-сервера. Отличием от ранее рассмотренных моделей является то,  что клиент соединяется не с сервером, а с неким промежуточным компонентом (посредником) (Рис. 1.3). Этот посредник, в свою очередь, от имени клиента передает запрос серверу. При этом посредник может сам решать, на какой из серверов послать запрос (возможны стратегии балансировки нагрузки). Кроме того, он может поддерживать кэш последних задаваемых запросов и при очередном запросе пользователя вернуть ему ответ, не обращаясь к серверу.

Рис. 1.3. Технология подключения через proxy 

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

Сервер  инициирует соединение

 

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

Мобильные агенты

 

Рис. 1.4. Мобильные агенты 

      Идея   рассматриваемой  модели   (Рис.   1.4)   состоит   в  том,   что   зачастую,   как это не парадоксально, клиент сам в состоянии выполнить ту задачу, решение которой он запросил у сервера,   более   того,   данные   необходимые   для   решения   этой   задачи   располагаются   на клиенте.  В  таком  случае,  для  разгрузки  сервера   (и,  очень  часто,  для   снижения   сетевого трафика) целесообразно решать эту задачу на клиенте. Но как это сделать, если у клиента нет соответствующего   программного  модуля,   содержащего   необходимую функциональность? Ответ таков - этот модуль нужно клиенту отправить. Клиент, получив модуль (этот модуль называется  мобильным  агентом)  может   выполнить   его  локально,   решив,   таким  образом, задачу.  В  качестве   примера  можно   рассмотреть   взаимодействие   браузера   и   веб-сервера, возвращающего   страницу,   содержащую   аплет.   Аплет   также   передается   клиенту   и выполняется в браузере   (т.е.  на клиенте),  выполняя  какие-то  значимые для пользователя действия.   Основная   проблема   для   такого   подхода   состоит   в   сложности   реализации механизма передачи и выполнения  мобильных агентов,   а   также   контроля  безопасности. Однако,   современные   средства  middleware  (Java,   например)   такими   возможностями обладают. 
 

Тонкий  клиент

 

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

Рис. 1.5. Тонкий клиент 

      Решить  эту проблему можно используя  технологию "тонкого клиента" (Рис. 1.5). Суть этой технологии состоит  в том, что клиент выполняет очень  ограниченную по функционалу задачу  (очень часто  -  только прием  ввода с клавиатуры и других устройств  и обработка команд   рисования).   Схема   работы   подобных   систем   в   простейшем   случае   следующая. Клиентская программа  передает весь ввод пользователя (нажатия  клавиш, движение мыши и т.д.)   по   сети   серверу.  Сервер,   разбирает   и   обрабатывает   этот   ввод   и   передает   клиенту готовые экраны,  которые  тот просто отображает.  Этот принцип  используется в системах типа X-Windows уже очень давно. Таким образом, сервер фактически берет на себя не только задачу управления данными, но и вообще все задачи по логике клиентского интерфейса. 

Трехзвенная архитектура

      Эту архитектуру не так-то просто нарастить  по мере роста и изменения ваших  приложений. В ней так же трудно использовать преимущества объектно-ориентированного программирования. Первая проблема недавно  нашла отражение в дискуссиях относительно «тонких клиентов». Потребность  тонких клиентов происходит из беспокоящей  тенденции в передаче клиенту  больших объемов обработки. Эта  проблема появилась в PowerBuilder и Visual Basic – инструментах, которые прямо вытаскивают данные из базы в GUI, а затем все операции над этими данными проводят в GUI. Такая тесная привязка интерфейса пользователя к ядру базы данных приводит к появлению программ, которые трудно модифицировать и невозможно масштабировать при увеличении числа пользователей и объема данных. Если у вас есть опыт разработки интерфейсов пользователя, то вы сталкивались с проблемой переработки интерфейса в зависимости от каприза пользователя. Что бы изолировать последствия такой переработки, проще всего оставить для GUI только одну задачу- действовать только в качестве интерфейса пользователя. Такой интерфейс пользователя действительно является тонким клиентом. Влияние на масштабируемость сказывается и с другой стороны. Когда требуется переработать приложение, что бы оно могло справляться с возросшим числом пользователей и объемом данных, модификация может быть осуществлена в результате изменений, вносимых в базу данных, в том числе таких, которые состоят в распределении базы данных по нескольким серверам. Навечно привязав свой интерфейс базе данных, вам приходится делать изменения в этом GUI для решения проблем масштабирования- проблем, связанных исключительно с сервером. Тонкие клиенты- не единственное сегодняшнее поветрие. Другая тенденция – повторное использование кода. Общий для разных приложений код тяготеет к обработке данных, обычно называемой деловой логикой. Если вся ваша деловая логика располагается в интерфейсе пользователя, то добиться повторного использования кода будет, по меньшей мере, трудно. Решение этих проблем является разбиение приложения на три, а не на две части. Такая архитектура называется трехзвенной.