WebClub - Всероссийский Клуб Веб-разработчиков
WebClub.RU » Советы » Распределенная архитектура, как наиболее подходящая для Business Web Application

Распределенная архитектура, как наиболее подходящая для Business Web Application


Дата публикации: 19-02-2011

В этой схеме собраны почти все варианты  названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания. Выбирать названия по другим критериям слишком сложно. Называть 3-х уровневую архитектуру N-уровневой вероятно не стоит, т.к. эти N уровней, обычно, появляются как более детальное изображение той же 3-х уровневой схемы, не внося принципиально новых идей. N-уровневые схемы удобны чтобы показать систему с точки зрения развертывания и администрирования. Но с точки зрения разработки эти дополнительные уровни  малоинтересны. 
    Три уровня (с позиции программирования) - это хранение, обработка и представление информации. Идея заключается в том, чтобы не смешивать эти три составляющие. Грубо говоря, 3-х уровневый подход - это просто хороший стиль программирования. Его можно применять при разработки практически любых приложений. Новизна же и идея распределенных приложений в том, чтобы иметь возможность распределить эти три уровня физически на различных компьютерах, а также возможность иметь несколько взаимозаменяемых вариантов каждого уровня.

 

2-x уровневая архитектура (Клиент-Сервер)

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

 

3-x уровневая архитектура (идеальный вариант)

3-х уровненая архитектура подразумевает четкое выделение бизнес-логики.

Интересно отметить, что  сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Такой подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).

 

3-x уровневая архитектура (фактический вариант)

На практике, мы имеем нечто подобное.  По различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например,  поместив бизнес-логику в хранимые процедуры в 3rd tier, мы можем получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier распространена повсеместно(как уже упоминалось), и, обычно, связана с неудачной архитектурой. Вопрос о бизнес-логике в ASP-страницах мы рассмотрим позднее.

       
    Теперь, попытаемся выявить основные критерии идеальной распределенной архитектуры:

  • Каждый уровень распределенного приложения может взаимодействовать только со смежным уровнем.
    Это означает, что: 1st tier не должен иметь прямого доступа к 3rd tier и наоборот; 2nd и 3rd tiers не должны иметь прямого интерфейса с пользователем; обращение к источнику данных из 1st tier происходит только через объекты 2-nd tier;

  • Вся сложная бизнес-логика находится в объектах 2nd tier.
    Как уже упоминалось, это условие часто нарушается, снижая возможность масштабирования. Хотя подобные решения иногда оправданы.

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

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

    Проблема ASP заключается в том, что смесь скрипта бизнес-логики, HTML и SQL представляет собой 2-х уровневую архитектуру (клиент-сервер), которая с задачами Web-приложений не справляется.  Поэтому мы предложим способ как разделить ASP на три составляющие - ASP-код с бизнес-логикой, HTML и SQL.

 

 

 

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

Популярное

Не так давно в сети появился новый сервис, под названием Dead Man Zero. Этот сервис сделал...
Рынок социальных площадок уже давно стал стабильным. Несмотря на то, что время от времени...
Artisteer 4 – единственный в своем роде продукт, позволяющий автоматизировать работу над созданием...
Февраль 2017 (3)
Январь 2017 (1)
Август 2016 (1)
Май 2016 (2)
Ноябрь 2015 (1)
Октябрь 2015 (1)

Карта сайта: 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

Друзья сайта

Хотите продать свой сайт?
- Мы быстро и удобно для Вас сможем его купить:
  • Заявка на продажу сайта
  • Раcсматриваем цены на каждый сайт в индивидуальном порядке.

    Случайная цитата

    E. W. Dijkstra:

    "Использование COBOL калечит разум; исходя из этого, обучение этому языку должно быть признано уголовно наказуемым преступлением."

    Опрос

    Какой аудио плеер Вы используете?

    Winamp
    Light Alloy
    foobar2000
    Apollo
    AIMP
    1by1
    iTunes
    jetAudio
    Другой...