Советы по архитектуре приложений

Question

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

Разъединение фронт-энда / бэк-энда - это новая территория для меня, и я не уверен в лучшей архитектуре.Я хочу, чтобы интерфейс был веб-ориентированным.Он будет отправлять команды в движок через формы и отображать выходную мощность и текущее состояние движка через вызовы ajax.Я не буду использовать Spring-based веб-приложение внутри Tomcat.

Мой вопрос касается лучшей структуры для компонента двигателя.Вот возможности, которые я рассматриваю:

• Реализация движка в виде набора потоков и структур данных в веб-приложении.Преимуществами здесь будет более простая реализация, а обмен сообщениями между интерфейсом веб-приложения и механизмом будет простым (не более, чем некоторые общие структуры данных).Недостатками могут быть жесткая связь между передней и задней сторонами, зависимость от сервера-контейнера для управления движком (например, в случае сбоя веб-сервера или веб-приложения, так же как и движка).

• * 1012Реализуйте серверную часть как отдельное Java-приложение и предоставьте его функциональность через какой-либо сервис на порте TCP.Мне нравится этот подход, потому что он отделен от веб-сервера.Тем не менее, я не в восторге от количества необходимого низкоуровневого сетевого / коммуникационного кода.Я бы предпочел более высокий уровень передачи сообщений, который абстрагирует сокеты и т. Д.

• Используйте контейнер OSGi, такой как сервер Spring DM, для размещения как веб-приложения, так и механизма.Этот подход хорош, потому что сетевой код не существует.Движок предоставляет сервисы контейнеру OSGI для использования веб-приложением.Недостатком является кривая обучения и накладные расходы новой технологии: OSGi.Кроме того, передний и задний конец остаются соединенными снова, что я действительно не хочу.Другими словами, я не мог развернуть интерфейс на каком-либо старом контейнере сервлета, он должен быть в том же контейнере OSGi, что и движок.

У меня такое чувство, что RMI - это то, что нужно, но опять же это новая область технологии для меня, и она до сих пор не объясняет, как проектировать архитектуру базовогосистемы.Что насчет JMS?

Спасибо за любой совет.

Answer 1

Если вы действительно хотите разделить веб-приложение и движок, вы также можете развернуть движок на другом сервере и представить API как вызовы веб-службы (WS- * или REST).

Answer 2

Вы отделите свой пользовательский интерфейс, если будете писать свой бэкэнд как сервисы, и установите формат сообщений XML или JSON для передачи между клиентом и сервисами.

Все остальные комментарии Cletus могут быть верными для серверной части, но клиент может блаженно не знать об этом. Это может быть даже реализация .NET для всех, кого это волнует. Основное внимание уделяется вариантам использования и сообщениям, а не серверной реализации.

Это также может быть полезно в тех случаях, когда вы используете пользовательский интерфейс не на основе HTML (например, Flex).

Answer 3

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

Основой, которую я бы использовал (и я использую для проекта, над которым я сейчас работаю, как выясняется), является стек следующего вида:

• Пружина 3
• Веб-контейнер
• Приложение, развернутое как веб-приложение (WAR);
• Для персистентности, либо Ibatis (мой предпочтительный вариант), либо JPA / Hibernate (если вы предпочитаете более персистентный подход к объектам);
• Ваш предпочтительный выбор веб-фреймворка. Здесь нет простого ответа, и есть десятки на выбор, от простых шаблонов до более компонентных (JSF, Seam и т. Д.). Гобелен / калитка выглядят интересно, но я тоже не эксперт.

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

На переднем конце это зависит от того, что вы хотите. Прямой HTML может быть сделан с любым веб-фреймворком. Даже если украшен каким-то Javascript. Я использую jQuery для такого рода вещей.

Это немного изменится, если вы захотите, чтобы интерфейс был похож на настольное приложение (так называемый «богатый» интерфейс). Для этого вам нужно либо использовать Google Web Toolkit («GWT»), возможно, компонентную веб-инфраструктуру, такую ​​как JSF (хотя я склонен думать, что они очень быстро запутываются), или Javascript, такую ​​как ExtJS, SmartClient, YUI или довольно новый уки.