Решение архитектуры: замена толстого Java-клиента веб-клиентом - PullRequest
0 голосов
/ 10 мая 2018

У меня есть клиент-серверное приложение, основанное на Java с Spring для сервера.

Теперь мне нужно заменить клиент Java веб-клиентом.

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

Вот эти концепции:

  1. Использованиевстроенного веб-сервера в моем сервере приложений. Pro: Я не должен реализовывать обработку сеансов между веб-сервером и сервером приложений.Веб-сервер может использовать хранилища данных сервера приложений для запросов. Минусы: Клиент должен решить, разрешено ли серверу приложений запускать собственный веб-сервер.И я не уверен, что это хороший стиль - смешивать логику веб-интерфейса с бизнес-логикой сервера приложений

  2. Встраивать бизнес-логику в веб-интерфейс пользователя вВойна за отдельный веб-сервер. Pro: Базовая защита, такая как обработка https, будет выполняться веб-сервером.Может быть, более приемлемым для клиента в отношении развертывания.Я не должен реализовывать какую-либо обработку сеанса между веб-сервером и сервером приложений.Веб-сервер может использовать хранилища данных сервера приложений для запросов. Минусы: Сервер приложений имеет много памяти и использования процессора.Возможно, это проблема для веб-сервера.

  3. Встраивание веб-интерфейса пользователя в веб-сервер и связывание его с сервером приложений через сокетное соединение. Pro: строгое разделение между пользовательским интерфейсом и бизнес-логикой.Сервер приложений не должен быть изменен, поскольку соединение сокетов между веб-сервером и сервером приложений может использовать существующее соединение сокетов для толстого клиента. Минусы: Обработка пользовательских сессий должна выполняться два раза.Сначала веб-сеанс, а второй сеанс на сервере приложений.Кроме того, веб-сервер должен настроить свои собственные хранилища данных и синхронизировать их с хранилищами на сервере приложений.

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

Спасибо за предоставленную мне информацию!

1 Ответ

0 голосов
/ 10 мая 2018

Ваш третий подход лучше. Разделение сервера приложений будет лучше обслуживать различных клиентов, таких как клиенты Java, веб-клиенты и т. Д. Это разделит 2 разных проблемы. Если есть проблема, связанная с пользовательским интерфейсом, вы можете отключить сервер пользовательского интерфейса и исправить ее. Но другие ваши клиенты Java будут работать нормально. Более того, это будет лучше и с точки зрения развития.

...