Как сохранить серверное приложение C ++ в реальном времени с современным интерфейсом веб-клиента?

Question

Я разрабатываю промышленное клиент-серверное приложение (C ++) с жесткими требованиями в реальном времени. Я чувствую, что пришло время изменить внешний вид клиентского интерфейса, который разработан в MFC, но мне интересно, какой будет правильный выбор. Если я обращаюсь к веб-клиенту, есть ли способ обмена данными между C ++ и JavaScript, кроме AJAX <-> Web-сервис <-> COM? Требования к веб-клиенту: быстрое обновление статусов, пользовательские команды, таблицы

Answer 1

Я обычно строю свои приложения в 2 раза:

1. Имейте реальное сверхмощное приложение только для CLI. Используемый протокол обычно основан только на тексте и состоит из запросов и ответов.
2. Оберните GUI как еще один процесс, который говорит с интерфейсом CLI.

Веб-интерфейс - это просто еще один графический интерфейс, который можно обернуть. Также намного проще обернуть API на основе REST / JSON в интерфейс CLI (просто автоматически переводить сообщения).

Отладка также довольно проста, так как вы можете просто вывести запросы между двумя элементами и гораздо проще воспроизвести ошибки.

Answer 2

Моя команда должна была принять то же решение несколько месяцев назад ...

Крутая вещь в создании веб-приложения заключается в том, что его очень легко будет изменить позже. Даже пользователь интерфейса (с небольшим ноу-хау) может изменить его в соответствии со своими потребностями. Пользовательское программное обеспечение становится намного проще.

Мы пошли с веб-интерфейсом, и Ajax, похоже, был верным путем, он был довольно отзывчивым.

С другой стороны, в зависимости от того, насколько сильны ваши требования в реальном времени, это может оказаться затруднительным. У нас была проблема с отображением данных в реальном времени через браузер, в итоге мы использовали плагин Firefox для рисования графика. Если вы просто пытаетесь отобразить текстовые данные в режиме реального времени, это не должно быть такой большой проблемой.

Запустите несколько тестов для вашего конкретного приложения и посмотрите, как оно выглядит.

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

Answer 3

Запишите на своем сервере HTTP-сервер для обработки обратной связи AJAX. Если вы не хотите обслуживать файлы, создайте свой сервер на нестандартном порту (например, 8081) и используйте обычный веб-сервер для фактической доставки веб-страницы. Теперь ваш движок AJAX должен связываться с сервером через порт Bizarro вместо порта 80.

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

Google Desktop Search делает это сейчас. Когда я ищу на рабочем столе «foobar», открывается следующий URL:

http://127.0.0.1:4664/search?q=foobar&flags=68&num=10

В этом случае 4664 - это порт Bizarro. (GoogleDesktop обслуживает все данные здесь; он использует только порт Bizarro, чтобы избежать конфликтов с любым веб-сервером, на котором я могу работать.)

Answer 4

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