Постоянный веб-сервис для приложений Rich Client Java (Swing) - PullRequest
4 голосов
/ 20 декабря 2010

Я переписываю свое клиентское серверное приложение базы данных расширенного клиента (Swing) в трехуровневое приложение с расширенным клиентом RCP Netbeans.

По умолчанию Hibernate и другие JPA провайдеры могут использоваться только очень громоздким способом из полнофункциональных клиентов (соединение с собственной базой данных не прерывается через брандмауэры, теряется отложенная загрузка, концептуальные проблемы с управлением жизненными циклами Session / EntityManager ... и другие проблемы). Поэтому для их комфортного использования в богатых клиентах нужно какое-то расширение.

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

Есть ли такая постоянная служба ???

Вот подробности моих идей / требований:

Служба должна работать с POJO, аннотированными JPA , поэтому на сервере должен использоваться какой-либо поставщик сохраняемости JPA. В настоящее время я использую Hibernate, поэтому, если он активно поддерживает Hibernate, это плюс. Конечно, классы POJO должны быть включены в конфигурацию JPA на стороне сервера, я не ожидаю обработки ЛЮБОГО ВИДА неизвестных POJO.

Я не хотел бы создавать отдельные объекты-значения или объекты передачи данных для отправки данных между клиентской и серверной частями службы. Я хотел бы использовать только аннотации JPA с POJO даже для передачи . Я считаю, что в настоящее время это стандартная практика.

Клиент должен получать данные и отправлять данные с HTTP-запросами на серверную часть службы, чтобы уменьшить проблемы связи брандмауэра. HTTP прокси использование должно быть настраиваемым.

Клиентская сторона службы персистентности может получать результаты списка POJO для своих выполненных запросов JPA QL (отправляется в виде простой строки запроса, , опционально ** именованные параметры ** также отправляется в запросе). Эти запросы отправляются от клиента в виде вызова веб-службы или простого HTTP-запроса к сервлету . Было бы хорошо, если бы в одном запросе можно было отправить несколько запросов JPA. Клиент получает результаты запросов в виде списков POJO, которые могут иметь загруженных с отложенной загрузкой коллекций и ссылок на объекты (они не отправляются с сервера во время запроса).

клиентская сторона службы персистентности должна иметь возможность выполнять отложенная загрузка запросов автоматически / прозрачно , когда клиентское приложение обращается к загруженным с отложенной загрузкой атрибут в POJO (в более поздний момент времени, а не в начальном запросе). Таким образом, прозрачная отложенная загрузка должна оставаться работоспособной после передачи POJO клиенту .

Новые, обновленные / грязные или подлежащие удалению POJO могут быть отправлены клиентской стороной службы персистенции на сервер, где изменения сохраняются и успех / сбой статусы отправляются обратно (например, идентификатор, который был присвоен вновь сохраненным POJO). В одном запросе может быть отправлено несколько POJO для сохранения.

У него должен быть механизм для маркировки границ транзакций, , чтобы в одной транзакции базы данных можно было выполнить несколько независимых вызовов службы HTTP (с сохранением чего-то вроде Session / EntityManager. beginTransaction () , commit () и rollback ()).

Было бы неплохо, если бы проверка и контроль доступа проверки могли быть подключены к компоненту сервера.

Есть ли такой проект службы персистентности ???Возможно, как расширение, поставляемое с поставщиком сохраняемости JPA?

Ответы [ 3 ]

1 голос
/ 17 января 2011

Когда я разработал подобное приложение в 2002 году, мы много раз искали фреймворк для использования, но в конце концов нам пришлось запустить наш собственный.Транспортировка подграфов постоянных объектов на клиент свинга осуществлялась путем их перевода в объекты DTO (DataTransferObjects), которые поддерживали сопоставление атрибутов и информацию, если клиент загрязнял атрибут.На обратном пути к серверу в trx были обновлены только загрязненные атрибуты.

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

Однако вы теряете возможность минимизировать данные, пересылаемые черезthe wire.

Лучшая ставка на данный момент: запустите свой собственный механизм и добавьте метод createDTO и updateFromDTO к своим постоянным объектам, но я был бы очень рад оказаться ошибочным.

0 голосов
/ 16 января 2011

Я буду использовать Spring с JPA. Spring предоставляет разумные значения по умолчанию для большинства проблем управления сохранением, которые вы упомянули. (Управление транзакциями, отложенная загрузка)

0 голосов
/ 22 декабря 2010

Транзакции, обработка запросов к серверу, проверка и контроль доступа - все это, как вы сказали, далеко за пределами уровня персистентности.Вы не найдете службы персистентности, которая реализует эти вещи.

При этом существует множество веб-фреймворков, которые быстро предоставляют базовую реализацию операций CRUD.В частности, вы ищете термин scaffolding .

Grails - это популярный веб-фреймворк для Java, который предоставляет scaffolding .Я уверен, что есть много других.Я бы посоветовал взглянуть на Грааля.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...