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

1-уровневая архитектура

  1. Уровень представления: это компонент (в большинстве случаев пользовательский интерфейс), который пользователь использует для взаимодействия с приложением.
  2. Уровень приложения: это бизнес-компонент (логика) приложения, который решает, что делать с входными данными, которые он получает от уровня представления.
  3. Уровень базы данных: это компонент, в котором хранятся и принимаются все данные, относящиеся к приложению.

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

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

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

2-х уровневая архитектура

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

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

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

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

3-х уровневая архитектура

В настоящее время наша прикладная система находится в одном месте, а логика базы данных - в другом. Программисты хотели еще больше оптимизировать двухуровневую систему.

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

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

n-уровневая архитектура

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

Примечание. Трехуровневая архитектура также является примером многоуровневой архитектуры.

Добро пожаловать в Интернет

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

  1. Веб сервер
  2. Веб-контейнер
  3. Сервер приложений

Веб сервер

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

Когда пользователь вводит URL-адрес (начиная с http :), браузер проверяет этот URL-адрес на локальном DNS-сервере. Локальный DNS-сервер свяжется с веб-сервером для установления соединения. Затем веб-сервер проверит, есть ли у него запрошенные данные. Если он есть, он отправит данные в DNS, который затем отправит их обратно в веб-браузер. Если данные не существуют, будет отправлено сообщение об ошибке.

Веб-контейнер

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

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

Примечание. У сервлетов нет основного метода. Таким образом, загрузка выполняется в веб-контейнере.

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

Сервер приложений

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

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

EJB (Enterprise Java Bean) разрабатывается на серверах приложений. Эти типы приложений потребуют интенсивной обработки на стороне сервера. Таким образом, серверы приложений дороже, чем два других сервера.

Примечание. EJB - это технология, построенная на основе RMI (удаленного вызова метода). Существует 3 основных технологии EJB. Сессионный компонент, компонент, управляемый событиями, и объектный компонент. Щелкните здесь для получения дополнительной информации.

Микросервисная архитектура

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

Облачная архитектура

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

  1. Front End: это будет клиентская инфраструктура. Клиенты смогут напрямую взаимодействовать с. Пример: веб-браузер, мобильные устройства.
  2. Back End: здесь выполняются все остальные части приложения, включая базу данных, логику приложения и все межсетевые взаимодействия. Безопасность системы и обслуживание выполняются на внутренней стороне.

Примечание. Облачные вычисления - большая тема для обсуждения в этой статье. Чтобы узнать больше об облачных вычислениях, щелкните здесь.

использованная литература