Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

Стратегии интеграции JavaFX

Anna | 2.06.2014 | нет комментариев

В рамках серии мастер-классов от IT-гуру, которые организовывает Luxoft Training, предлагаем вам познакомиться с переводом статьи Адам Биена “ Integration Testing for Java EE”

Об авторе
Референт и автор книг Адам Биен является членом Экспертной группы по Java EE 6 и 7, EJB 3.X, JAX-RS, и JPA 2.X JSRs. Работает с спецтехнологией Java, начиная с JDK 1.0, и с Servlets/EJB 1.0. В подлинный момент является зодчим и разработчиком в планах по Java SE и Java EE. Под его редакцией вышло несколько книг, посвященных JavaFX, J2EE и Java EE. Является автором книг Real World Java EE Patterns—Rethinking Best Practices и Real World Java EE Night Hacks—Dissecting the Business Tier. Адам владеет наградой Java Champion, Top Java Ambassador 2012, JavaOne 2009, 2011 и 2012 Rock Star. Периодично устраивает мастер-классы по Java EE в здании мюнхенского аэродрома (http://airhacks.com).

С лямбда-выражениями и помощью асинхронной коммуникации JavaFX представляет новые вероятности интеграции для серверных служб.

В организации редко дозволено встретить изолированные приложения. Корпоративное приложение для настольной системы отображает и манипулирует данными одной и больше серверных служб, представленных сервером приложений. Во времена Swing и J2EE сообщение было однонаправленным и синхронным. JavaFX и Java EE 6 и 7 представили многообразные новые синхронные, асинхронные, push- и pull-стратегии интеграции. В данной статье речь пойдет об интеграции Java EE-служб с Java FX-приложениями.
JavaFX – это Java
JavaFX – это Java. Следственно, лучшие практики, которые используются для Swing-приложений, могут использоваться и для JavaFX. Интеграция серверных служб не зависит от используемых протоколов и спецтехнологий.
Службы имеют многообразные конфигурации, такие как IP-адреса, порты и файлы свойств. А способы API Зачастую выбрасывают исключения, специфичные для протокола, типа java.rmi.RemoteException и, следственно, загрязняют презентационную логику непотребными деталями. Тонкий упаковщик вокруг собственной службы инкапсулирует детали реализации и представляет больше важные детали интерфейса. Это типичный GoF паттерн Adapter.

Возрождение Business Delegate
J2EE-заказчики в значительной степени опирались на спецтехнологию Remote Method Invocation, основанную на протоколе Internet Inter-ORB Protocol (RMI-IIOP), а позднее, на Java API для XML-based RPC (JAX-RPC) и Java API для XML Web Services (JAX-WS) с серверными службами. Оба API насыщенно применяют контролируемые исключения и привязаны к определенной спецтехнологии. Паттерн Business Delegate был нужен для разъединения презентационной логики и протокола:

«Используйте Business Delegate для уменьшения сцепления между заказчиками яруса представления и бизнес-службами. Business Delegate скрывает детали реализации бизнес-службы, такие как поиск и доступ к EJB-архитектуре».

Business Delegate Зачастую расширялся фабричным способом, тот, что создавал настоящие прокси в варианте по умолчанию и mock-объекты в тестовом окружении. C современными mock-библиотеками, такими как Mockito, Business Delegate дозволено имитировать напрямую. Business Delegate в контексте JavaFX и JavaEE может быть реализован как адаптер Plain Old Java Object (POJO), тот, что инкапсулирует детали реализации и предоставляет JavaFX комфортный интерфейс.

Рисунок 1

Вначале запрос, потом результат
Отправка блокирующего запроса на сервер приложения и ожидание приобретения данных – простейшая допустимая интеграция с серверной частью. Business Delegate становится службой, которая сообщается с серверной частью, как это показано в Листинге 1:

Листинг 1

Класс MethodMonitoring легко реализовать, протестировать и интегрировать с презентером. Так как способ getMethodStatistics допустимо может блокировать на неограниченное число времени синхронный вызов из способа UI listener, то применение его сделает UI неотзывчивым.

Асинхронная интеграция
К счастью, JAX-RS 2.0 API так же поддерживает асинхронную модель обратного вызова. Взамен блокирования, способ getMethodStatistics инициирует запрос и регистрирует обратный вызов (см. Листинг 2).

Листинг 2

Обратный вызов превращает входящий JsonObject в объект предметной области и передает его в реализацию функции java.util.function.Consumer. Реализация Business Delegate по-бывшему не зависит от JavaFX API и использует Java 8 java.util.function.Consumer в качестве обратного вызова. С Java 7 всякий настраиваTML5-заказчики. Исключительное различие между синхронной коммуникацией и long polling – это повторная инициация блокирующего вызова. Повторяющийся опрос может быть напрямую реализован через javafx.concurrent.Service. Вне зависимости от того, удастся выполнение либо нет, сервис будет сброшен, а после этого перезапущен:

Листинг 8

Интеграция Push 
Push-коммуникация – это запросно-ответный жанр связи, только без запросной части; сервер приложений может вытолкнуть данные в всякий момент времени. Java Message Service (JMS), WebSockets и memory grids имеют механизм уведомления, тот, что работает по тезису «запустил и позабыл» (fire-and-forget), и могут легко интегрироваться с JavaFX.
JSR 356 реализует протокол WebSocket, является частью Java EE 7 и поступает с Java client API. Спецификация WebSocket вводит двунаправленный бинарный протокол и безупречно подходит для интеграции заказчиков UI. Сообщения WebSocket могут иметь бинарный либо текстовый нрав и получаются с подклассом Endpoint, как показано в Листинге 9:

Листинг 9

Класс SnapshotEndpoint получает строковое сообщение и конвертирует его с поддержкой Java Archite cture for XML Binding (JAXB) API. Объект предметной области Snapshot – это аннотированный POJO:

Листинг 10

JSR 356 API поддерживает растяжения, следственно сериализация и десериализация могут быть вынесены в выделенный класс. Мы также не ограничены только JAXB; дозволено применять всякую доступную презентацию объекта, такую как JSON либо сериализацию. SnapshotEndpoint выполняется на клиентской части выделенным потоком WebSocket, следственно сообщение не может быть использовано только для обновления UI. С способом Platform.runLater, сообщение правильно передается от WebSocket в поток JavaFX.

Endpoint отвечает только за фактическую коммуникацию. В дополнение, WebSocket контейнер требует изначальной конфигурации и инициализации для того, что реализуется в выделенном классе:

Листинг 11

До сих пор мы фактически не применяли интеграционные вероятности JavaFX, а лишь фокусировались на разных интеграционных жанрах. Впрочем свойства JavaFX делают синхронную и асинхронную интеграцию исключительно увлекательной.
Интеграция JavaFX
Качество javafx.beans.property.ObjectProperty упаковывает экземпляр Object и является bindable. Заинтересованный заказчик может зарегистрироваться как слушатель либо напрямую привязаться к свойству и получать уведомления при замене упакованного экземпляра. (См. раздел «Binding for Narrow Interfaces» статьи в Java Magazine «JavaFX Data Binding for Enterprise Applications.») Вне зависимости от протокола связи и синхронности, результат несет объект предметной области, тот, что должен быть отражен UI. С ObjectProperty UI может легко напрямую привязываться к значению и получать механические уведомления при приобретении данных. Презентер напрямую привязывается к ObjectProperty, что делает добавочные способы управления избыточными:

Листинг 12

“Привязывающееся” ObjectProperty устраняет мусор и делает интерфейс предельно «тесным». Привязывание может так же использоваться к исходящей связи. Презентер меняет состояние объекта либо модели предметной области, что приводит к уведомлению службы (Business Delegate). Исходящая коммуникация не требует синхронизации с потоками UI. Асинхронные операции могут напрямую выполняться из потока UI, а долгие операции могут либо упаковываться в Service либо асинхронно выполняться в Business Delegate. Впрочем не все операции UI меняют состояние объекта предметной области. Примитивные пользовательские действия, такие как “save” либо “refresh” могут напрямую передаваться в вызовы способа Business Delegate.

Последующее возрастание отзывчивости и облегчение
UI JavaFX управляется событиями и является асинхронным. Так же, Java EE 7 API, такие как JAX-RS 2.0, JMS либо WebSockets, имеют асинхронные вероятности. Применение JavaFX коллективно с асинхронными Java EE 7 API гораздо упрощает код. Все операции Business Delegate могут асинхронно выполняться без блокирования UI либо даже самого Business Delegate. Паттерн взаимодействия не зависит от протокола связи и может ступенчато использоваться ко каждому асинхронным Java EE 7 API.
Запрос передается на сервер в режиме «запустил и позабыл».

Источник: programmingmaster.ru

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB