Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Распределенные сервис-ориентированные системы..pdf
Скачиваний:
16
Добавлен:
05.02.2023
Размер:
9.2 Mб
Скачать

Рисунок 2.25 — Результат полной реализации тестового приложения

2.4 Реализация уровня интерфейса сервисов

Если первое назначение технологии JSF — формирование уровня бизнес-логики для архитектурной бизнес-парадигмы предприятия (см. рис. 1.12, стр. 32), то второе ее назначение

формирование уровня интерфеса сервисов этой же парадигмы.

Впервой главе данного учебного пособия приведен тестовый пример, выполненный по JSP-технологии. Учебная цель этого примера — проверка и демонстрация работоспособности сервера приложений Apache TomEE и интегрированной инструментальной среды разработки Eclipse EE.

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

102

браузер запрашивал содержимое этой переменной, она возвращалась в ответе как часть HTML-страницы и отображалась браузером со всеми вставленными в нее тегами: переводом строки <br> и линией подчеркивания <hr>.

В проекции шаблона проектирования MVC, HttpServlet TestTomee выполняет функции контроллера и модели, а поскольку сервер приложений кэширует сервлеты в памяти ЭВМ, то это создает преимущество по сравнению с реализацией приложения на основе PHP-технологии, но создает общие проблемы, в плане реализации распределенных систем.

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

Сохранение в сервлете TestTomee разделяемой переменной msgs делает тестовое приложение сильносвязанной системой, имеет следующие пос-лед- ствия:

а) делает сервлет уникальным и пригодным для решения только одной конкретной задачи;

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

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

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

а) компонент-подложка TestTomee имеет несвойственную таким задачам область действия @ApplicationScope, что делает систему сильносвязанной;

б) остаются проблемы многопользовательского доступа;

в) сложные по структуре сообщения должны определяться в виде классов и соответствующим образом реализовываться.

Учебная цель данного подраздела — изучение той части JSF-технологии, которая обеспечивают реализацию интерфейса сервисов уровня предприятия.

Неудивительно, что постановки задач, в стиле рассмотренного ранее те-

103

стового примера, приводят к мнению, что технология JSF, да и сама программная платформа Java EE, слишком сложны для практического применения и вызывают стремление использовать другие, более «популярные», инструменты.

Поскольку объем возможностей JSF — достаточно большой, в следующих пунктах данного подраздела ограничимся наиболее важными примерами использования CDI-компонент, которые будем конкретизировать, опираясь на базовый шаблон lab3Templ.xhtml проекта labs.

2.4.1Жизненый цикл компонентов-подложек

Впункте 2.2.3 «Модель в виде компонентов-подложек» было представлено пять вариантов области их действия (см. таблица 2.2, стр. 76).

Наиболее важными для наших рассуждений являются области действия, представленные аннотациями: @ApplicationScoped, @SessionScoped и @RequestScoped.

1.@ApplicationScoped — аннотация, соответствующая компоненте приложению, жизненый цикл которой начинается с запуском сервера приложений и заканчивается с остановкой сервера. В проекции на бизнес-пара- дигму предприятия, она соответствует уровню приложений, и поэтому не должна использоваться. Исключением являются внутренние потребности проекта на уровне интерфеса сервисов, например, когда нужно защитить приложение, ограничив права доступа, или для учебных (проектных) работ, моделируя работу бизнес-приложения.

2.@SessionScoped — аннотация, соответствующая сессии пользователя с момента, когда браузер подключился к серверу приложений и web-контей- нер создал сессию, до момента, когда web-контейнер закрыл сессию. В проекции на бизнес-парадигмы предприятия, она соответст-вует уровню интерфеса сервисов, поэтому является основным объектом нашего внимания. На компоненты-подложки с таким жизненным циклом должны опираться Facelets-компоненты базовых шаблонов, когда они предоставляют доступ к расположенным на них формам, компонентам ссылок и другим активным компонентам XHTML-ресурсов. Как CDI-компоненты допускают инъекции объектов, аннотированных жизенными циклами приложений или сессий.

3.@RequestScoped — аннотация, соответствующая непосредственному запросу браузера с момента получения его сервером приложений и до момента, когда сервер отправил браузеру ответ. Фактически все активные компоненты XHTML-ресурсов должны использовать подложки такого типа. Как CDI-компоненты допускают инъекции объектов, аннотированных жизенными циклами приложений или сессий.

104

Facelets-шаблону изучаемой дисциплины необходима компонента-подложка с жизненным циклом сессии.

2.4.2 Компонента Users с ЖЦ @ApplicationScoped

Уровень приложений обеспечивает компонента Users, доступ к которой осуществляет только компонента-подложка RSOS с жизненным циклом (ЖЦ, области действия)

@SessionScoped.

Уровень приложений может быть реализован различными способами, некоторые из которых будут рассмотрены в последующих главах. В данном пунке мы реализует POJO-класс, который приватно хранит несколько имен пользователей с паролями и имеет метод getUser(...), и который по заданному имени и паролю возвращает:

а) имя пользователя, если такой пользователь имеется и пароль указан провильно;

б) пустую строку (null), если имя и/или пароль заданы неправильно.

Для учебных целей, хранилище имен и паролей пользователей реализовано в виде Java-коллекции HashMap<String,String>, работа с которой обеспечивается следующими определениями:

а) HashMap<String,String> map = new HashMap<String,String>() — начальное создание пустой коллекции;

б) map.put("имя", "пароль") — добавление пары слов в коллекцию; в) map.get("имя") — получение пароля по имени пользователя;

г) map.remove("имя") — удаление пары <"имя", "пароль"> из коллекции.

Исходный текст класса Users представлен на листинге 2.19.

Листинг 2.19 — Исходный текст класса Users.java проекта labs

package asu.rsos;

import java.util.HashMap;

import javax.annotation.PostConstruct;

import javax.enterprise.context.ApplicationScoped; import javax.inject.Named;

@Named

@ApplicationScoped public

105