Русские Блоги
Распределенная структура при проектировании архитектуры корпоративных приложений Java
Архитектура корпоративных приложений JavaДизайн — это знания, которые не нужно изучать каждому Java-разработчику.В этой статье будут представлены некоторые базовые сведения об архитектуре и дизайне приложений Java EE, и это содержание заложило основу всей разработки приложений Java EE.
Архитектура корпоративных приложений JavaРаспределенную структуру в проекте можно условно разделить на одноуровневую структуру, двухуровневую структуру, трехуровневую структуру и многоуровневую структуру. Полное понимание и применение распределенной структуры может лучше понять статус-кво современных сетевых вычислений и разрабатывать более совершенные приложения корпоративного уровня.
В течение долгого времени Java Enterprise Edition (Java EE) стала предпочтительной платформой для разработки и развертывания корпоративных бизнес-приложений во многих отраслях (таких как банковское дело, страхование, розничная торговля, гостиничный бизнес, туризм, телекоммуникации и т. Д.). Причина, по которой Java EE так широко используется, заключается в том, что Java EE может предоставить стандартизированную платформу для создания надежных и высокомасштабируемых распределенных систем приложений, а объем поддержки этих приложений может варьироваться от основных бизнес-операций банка до авиакомпаний. Огромное пространство между двигателями бронирования. Однако разработка успешных приложений Java EE также может стать сложной задачей.Архитектура корпоративных приложений JavaДизайн играет в этом важную роль.
Во-первых, богатый выбор, предоставляемый самой платформой Java EE, может обескураживать. Эти лишние фреймворки, служебные библиотеки, интегрированные среды разработки (IDE) и альтернативные инструменты все усложняют. Поэтому выбор правильной технологии имеет важное значение для разработки программного обеспечения на основе Java EE. И те технологии, которые имеют надежную архитектуру и рекомендации по проектированию, принесут большую пользу для создания системы приложений, которую легко поддерживать, повторно использовать и расширять.
Сначала мы рассмотрим эволюционную историю распределенных вычислений и n-уровневую структуру. Позже я покажу, как платформа Java EE решает проблемы разработки распределенных приложений. В то же время вы также поймете структурные рекомендации модель-представление-контроллер (MVC). Затем я объединю рекомендации MVC и платформу Java EE, чтобы объяснить структуру многоуровневого приложения Java EE.
После понимания архитектуры прикладной системы я сосредоточусь на разработке приложений Java EE на основе объектно-ориентированных принципов. Я также объясню, как использовать шаблоны проектирования для упрощения процесса проектирования и как выбирать лучшие практические примеры. Кроме того, я также коснусь каталога шаблонов проектирования, включенного в Sun Java BluePrints, который подробно описан в Deepak Alur et al. «Core J2EE Design Patterns» (Prentice Hall Press, 2003). В конце статьи я расскажу об универсальном языке моделирования (UML) и его роли в разработке и архитектуре визуальных документов Java EE.
Эволюционная история распределенных вычислений
В распределенных вычислениях приложение будет разделено на несколько более мелких компонентов и запущено на разных компьютерах одновременно. Этот метод расчета также называется «сетевым расчетом», потому что эти компоненты обычно обмениваются данными через некоторые протоколы, основанные на TCP / IP или UDP. Эти более мелкие компоненты приложения называются «уровнями», и каждый уровень может независимо предоставлять класс услуг другим уровням подключения. «Уровень» может быть разделен на несколько «уровней», чтобы уменьшить степень детализации функций. большинствоАрхитектура корпоративных приложений JavaДизайн должен состоять из трех разных слоев:
◆ Уровень представления отвечает за пользовательский интерфейс.
◆ Бизнес-уровень выполняет бизнес-логику. Во время работы он также взаимодействует с уровнем доступа к данным.
◆ Уровень доступа к данным отвечает за такие операции, как доступ к данным, хранящимся в информационной системе предприятия (EIS).
Анализируя историю перехода структуры распределенных вычислений, мы можем лучше понять текущее состояние современных сетевых вычислений. В следующих нескольких разделах я буду использовать несколько подходящих примеров, чтобы представить изменения в распределенной архитектуре.
Одноступенчатая конструкция
Использование одноуровневой структуры восходит к тем временам, когда простые терминалы использовались для подключения к гигантским хостам. В этой структуре все компоненты приложения, такие как пользовательский интерфейс, бизнес-логика и данные, настроены на одном физическом хосте. Пользователь взаимодействует с системой через терминал или консоль, и этот метод имеет очень ограниченные возможности обработки текста (см. Рисунок 1).
Рис. 1. Одноуровневая структура (текст на рисунке: Консоль — «Консоль»; «Тупой терминал» — «Простой терминал»; Мэйнфрейм — хост)
Структура уровня 2
В начале 80-х годов прошлого века персональные компьютеры (ПК) стали очень популярными. Они были дешевле, чем мэйнфреймы, и обладали большей вычислительной мощностью, чем простые терминалы. Появление ПК проложило путь к действительно распределенным (клиент-сервер, C / S) вычислениям. ПК в качестве клиента теперь может запускать программу клиентского интерфейса (UI) независимо, а также поддерживает графический интерфейс клиента (GUI), позволяя пользователям вводить данные и взаимодействовать с хостом сервера, в то время как хост сервера теперь отвечает только за бизнес-логику и данные. раздел. После того, как пользователь завершит ввод данных на клиенте, программа GUI может выборочно проверить достоверность данных, а затем отправить данные на сервер для обработки бизнес-логики. Приложение Oracle на основе форм — отличный пример двухуровневой структуры. Графический интерфейс формы хранится на клиентском ПК, а бизнес-логика (включая код и хранимые процедуры) и данные остаются на сервере базы данных Oracle.
С тех пор появилась еще одна двухуровневая структура, в которой не только пользовательский интерфейс (UI), но и бизнес-логика размещается на уровне клиента. Типичный режим работы этого приложения — прямое подключение к серверу базы данных для выполнения различных запросов к базе данных. Такой тип клиента называется «толстым клиентом», потому что эта структура помещает значительную часть исполняемого кода на клиентский уровень (см. Рисунок 2).
Рис. 2. Двухуровневая структура (уровень бизнес-логики — уровень бизнес-логики; необязательно — необязательно; уровень пользовательского интерфейса — уровень пользовательского интерфейса; толстый клиент — толстый клиент; уровень доступа к данным — уровень доступа к данным; мэйнфрейм-сервер ——Серверный хост)
Структура уровня 3
Хотя разработка приложений «толстого клиента» уровня 2 очень проста, любые обновления программного обеспечения, вызванные изменениями в пользовательских интерфейсах или бизнес-логике, должны выполняться на всех клиентах. К счастью, в середине 1990-х годов затраты на оборудование становились все ниже и ниже, в то время как вычислительная мощность ЦП значительно возросла. В то же время Интернет развивается очень быстро, и постепенно наметилась тенденция к разработке Интернет-приложений. Сочетание этих двух факторов в конечном итоге привело к появлению трехуровневой структуры.
В модели с трехуровневой структурой клиенту ПК требуется только установить программное обеспечение «тонкий клиент», такое как браузер, для отображения отображаемого содержимого, предоставляемого сервером. Сервер отвечает за подготовку отображаемого содержимого, бизнес-логику и логику доступа к данным, а также Данные поступают из корпоративных информационных систем, таких как реляционные базы данных. В такой системе к бизнес-логике можно получить доступ удаленно, поэтому поддержка независимого клиента через консольное приложение Java становится курсом. Бизнес-уровень в основном взаимодействует с информационной системой через уровень доступа к данным. Поскольку все приложение находится на сервере, такой сервер также называют «сервером приложений» или «промежуточным программным обеспечением» (см. Рисунок 3).
Рисунок 3. Трехуровневая структура (текст на рисунке: уровень представления — уровень представления; уровень бизнес-логики — уровень бизнес-логики; уровень доступа к данным — уровень доступа к данным; тонкий клиент — тонкий клиент; сервер приложений — приложение. Сервер; Enterprise Data — данные предприятия; Сервер базы данных — сервер базы данных)
N-уровневая структура
В связи с постоянным улучшением пропускной способности Интернета крупные компании по всему миру начали предоставлять свои сетевые услуги. Это изменение делает сервер приложений неспособным продолжать нести огромную нагрузку уровня представления. Эта задача теперь выполняется выделенным веб-сервером, отвечающим за создание отображаемого содержимого. После того, как отображаемый контент будет передан браузеру клиентского уровня, браузер будет отвечать за отображение пользовательского интерфейса. Сервер приложений в структуре N-уровня отвечает за предоставление удаленно доступных компонентов бизнес-логики, в то время как веб-сервер уровня представления использует этот сетевой протокол для доступа к этим компонентам через сеть. На рисунке 4 показана n-уровневая структура.
Выше Архитектура корпоративных приложений Java Распределенная структура в дизайне, в разных потребностях и сценариях приложений, мы будем использовать разные распределенные структуры и разрабатывать разные Архитектура корпоративных приложений Java 。