 |
Тема 1. Проектирование 3-х уровневой архитектуры.
|
|
|
|
Наиболее интересными и полезными качествами, которыми привлекала технология JSP, можно считать:
· удобный способ объединение Server-Side Script c HTML;
· скриптовый подход (интерпретируемый язык) - т.е. файл с исходным кодом JSP одновременно является его исполняемым файлом, что упрощает процессы разработки и поддержки;
· концепция "Session" - переменные для каждого пользовательского соединения, как удачное решение вечной проблемы stateless-протокола HTTP;
· удобный набор объектов-утилит: Request, Response, Session, Context.
Проблемы, присущие плохо структурированным JSP-проектам:
· Смесь бизнес-кода и HTML приводит к трудностям поддержки и того и другого;
· Наличие большого количества DB-зависимого кода в JSP-страницах привязывает их к источнику данных;
· Перегруженность JSP-страниц функциональностью приводит к перегрузкам IIS (хотя это можно решить кластеризацией IIS);
· Смысловая перегрузка JSP-страниц затрудняет их поддержку;
· Хранение бизнес-логики в JSP-страницах в "размазанном" виде приводит к затруднению ее вынесения в объекты 2-nd tier (при необходимости масштабирования и поддержки разных видов 1st tier-клиентов);
· Полная зависимость кода проекта от самой технологии JSP
Что предлагается делать:
1. Вынести HTML из JSP-страниц в отдельные файлы;
2. Вынести SQL из JSP-страниц;
3. Абстрагировать JSP-специфические возможности в объекты общей библиотеки;
4. Организовать все часто используемые функции в виде методов общей объектно-ориентированной библиотеки;
5. Использовать JavaScript и отслеживать пути быстрого перехода на JSP/PHP, при возникновении подобной необходимости.
Рисунок 1.1.1 Разбиение представления на части
1.1 Технологии JEE
На текущий момент платформа JEE включает в себя технологии представленные в таблице 1
|
|
|
Таблица 1 Технологии JEE
| Описание | Использованная версия | ||||
| J2EE 1.4 | JEE 5 | JEE 6 | JEE 7 | ||
| EJB | Enterprise JavaBeans — спецификация технологии серверных компонентов, содержащих бизнес-логику | 2.1 | 3.0 | 3.1 | 3.2 |
| JPA | Java Persistence API | Нет | 1.0 | 2.0 | 2.1 |
| Сервлет | Обслуживание запросов веб-клиентов | 2.4 | 2.5 | 3.0 | 3.1 |
| JSP | JavaServer Pages — динамическая генерация веб-страниц на стороне сервера | 2.0 | 2.1 | 2.2 | 2.3 |
| JSTL | JavaServer Pages Standard Tag Library | Нет | 1.2 | 1.2 | 1.2 |
| JSF | JavaServer Faces — компонентный серверный фреймворк для разработки веб-приложений на технологии Java | Нет | 1.2 | 2.0 | 2.2 |
| JAX-WS | Java API for XML Web Services — создание веб-сервисов | 1.0 | 1.2 | 1.2 | 2.2 |
| JAX-RS | Java API for RESTful Web Services -- создание RESTful веб-сервисов | Нет | Нет | 1.1 | 2.0 |
| JNDI | Java Naming and Directory Interface — служба каталогов | 1.2 | 1.2 | 1.2 | |
| JMS | Java Message Service — обмен сообщениями | 1.1 | 1.1 | 1.1 | 2.0 |
| JTA | Java Transaction API | 1.0.1B | 1.1 | 1.1 | 1.2 |
| JAAS | Java Authentication and Authorization Service — Java реализация PAM | 1.0 | 1.0 | 1.0 | |
| JavaMail | Получение и отправка электронной почты | 1.2 | 1.4 | 1.4 | 1.5 |
| JACC | Java Authorization Contract for Containers | 1.0 | 1.1 | 1.1 | 1.4 |
| JCA | J2EE Connector Architecture | 1.5 | 1.5 | 1.6 | 1.6 |
| JAF | JavaBeans Activation Framework | 1.0 | 1.1 | 1.1 | 1.1 |
| StAX | Streaming API for XML | Нет | 1.0 | 1.0 | 1.0 |
| CDI | Context and Dependency Injection | Нет | Нет | 1.0 | 1.1 |
1.2 Шаблоны J2EE
Шаблоны J2EE — набор шаблонов проектирования, описывающих архитектуру серверной платформы для задач средних и крупных предприятий. Эти шаблоны рекомендуется применять при проектировании приложений с использованием java-архитектуры J2EE.
Список шаблонов привиден ниже:
Intercepting Filter - Обеспечивает централизованную точку входа для управления обработкой запроса.
Front Controller - Комбинирует Dispatcher, Front Controller и View Helper, откладывая обработку сигналов.
Dispatcher View - шаблон описывает общую комбинацию контроллера и диспетчера с видами и помощниками.
Service to Worker описывает общую комбинацию контроллера и диспетчера с видами и помощниками.
|
|
|
Composite View - Создание составного визуального представления
View Helper - Обеспечивает предварительную и пост-обработку запроса.
Business Delegate - Прячет сложности поиска и создания бизнес-сервисов.
Service Locator - Управляет исполнением запросов, кэшированием результатов и их обработкой.
Value List Handler - Собирает составной Value Object из многих источников данных.
Value Object Assembler - Прячет сложность бизнес-объекта, централизует обработку workflow.
Composite Entity - Обеспечивает обмен данными между слоями, уменьшая сетевой трафик.
Value Object - Прячет сложность бизнес-объекта, централизует обработку workflow.
Session Facade - Разделяет презентационный и сервисный уровни, обеспечивает интерфейсы фасада и посредника для сервисов.
Data Access Object - Абстрагирует источник данных; обеспечивает прозрачный доступ к данным.
Service Activator - Обеспечивает асинхронную обработку для компонентов EJB.
1.3 Приоритеты в Business Web Application
Предлагаемая, но не единственно верная, иерархия такова:
1. Функциональная адекватность - Приложение корректно выполняет свои функции в идеальных условиях (один пользователь в единицу времени, идеальное функционирование аппаратуры и т.д.).
2. Надежность в условиях ограниченной загрузки - Приложение устойчиво и надежно обслуживает небольшое фиксированное число одновременно работающих пользователей. (Типичные проблемы Интернет, такие, например, как сбой соединения, не нарушают работу.).
3. Удобство работы, интуитивно понятный интерфейс - пользователям удобно работать с системой;
4. Возможность обслужить максимальное расчетное количество одновременно работающих пользователей - система готова надежно обслужить всех потенциальных пользователей;
5. Высокая скорость работы - короткое время отклика системы;
6. Красивый дизайн - дизайн системы эстетически приятен большинству пользователей.
1.4 Распределенная архитектура Веб-приложений.
Интерпритация 3-х уровневой архитектуры
Клиент (слой клиента) — это интерфейсный (обычно графический) компонент комплекса, предоставляемый конечному пользователю. Этот уровень не должен иметь прямых связей с базой данных (по требованиям безопасности и масштабируемости), быть нагруженным основной бизнес-логикой (по требованиям масштабируемости) и хранить состояние приложения (по требованиям надёжности).
|
|
|
Сервер приложений (средний слой, связующий слой) располагается на втором уровне, на нём сосредоточена бо́льшая часть бизнес-логики. Вне его остаются только фрагменты, экспортируемые на клиента (терминалы), а также элементы логики, погруженные в базу данных (хранимые процедуры и триггеры).
Сервер баз данных (слой данных) обеспечивает хранение данных и выносится на отдельный уровень, реализуется, как правило, средствами систем управления базами данных, подключение к этому компоненту обеспечивается только с уровня сервера приложений.
Интерпритация 3-х уровневой архитектуры
Интерпритация 3-х уровневой архитектуры
В этой схеме собраны почти все варианты названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания.
Три уровня (с позиции программирования) - это хранение, обработка и представление информации. Идея заключается в том, чтобы не смешивать эти три составляющие. 3-х уровневый подход - это просто хороший стиль программирования. Его можно применять при разработке любых приложений. Новизна же и идея распределенных приложений в том, чтобы иметь возможность распределить эти три уровня физически на различных компьютерах, а также возможность иметь несколько взаимозаменяемых вариантов каждого уровня.
Основные критерии идеальной распределенной архитектуры:
|
|
|
