Использование веб-сервисов для подключения внешнего интерфейса и внутреннего интерфейса - хорошая идея?

Question

Этот проект запускает интерфейсный веб-сервер на одной JVM, а внутренний - на другой. Чтобы сеть вызывала какие-либо бизнес-логические методы в серверной части, она должна выполнять этот вызов через веб-службы (JAX-WS).

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

Производительность? Сделки? В общем хорошая идея?

Answer 1

В общем, этот подход является хорошей идеей, если ваш «бэкэнд» (я бы назвал их «сервисами») предназначен для повторного использования другими приложениями.

Только примечание: веб-сервисы - это просто интерфейс передачи / передачи сообщений между системами. Здесь есть множество других опций для обработки интерфейса между ними - Java RMI, Spring remoting, REST и т. Д. Хорошо разработанное сервисное решение будет не зависеть от используемой вами технологии обмена сообщениями (и должно иметь возможность поддерживать более одного). .

Answer 2

Я большой поклонник принципа KISS (Keep It Simple Stupid). Должна существовать веская причина для разделения приложения между JVM и создания уровня интерфейса WS. Возможные причины включают необходимость масштабировать уровень представления в отличие от бизнес-уровня. Различия в настройке JVM, такие как другой алгоритм сборки мусора. Или необходимость в DMZ.

Если убедительной причины не существует, разделение добавляет ненужную сложность, которая, скорее всего, вызовет головную боль от разработки до операций.

А необходимость предоставления бизнес-логики другим приложениям не является убедительной причиной для разделения уровней между JVM. Бизнес-логику по-прежнему можно предоставлять через WS для внешних приложений, в то время как уровень презентации физически находится в той же JVM и напрямую ссылается на бизнес-уровень через реализацию бизнес-службы POJO. Хотя вокруг реализации POJO будет оболочка веб-службы, представляющая бизнес-службы как веб-службы.

Answer 3

Ваша идея разбить приложение не так уж редка. Когда большинство ваших служб предназначено для повторного использования, рекомендуется развернуть их как отдельное приложение и отделить его, чтобы другие системы могли легко получить к ним доступ. Это будет определенно влиять на производительность, но технически это не должно влиять на транзакции (если только вам не нужны транзакции через сервисные вызовы, где вы можете использовать WS-Reliability).