Посоветуйте embedded WEB-сервер для GUI-приложенией
Модератор: Модераторы
Грубо говоря, приложение должно принимать данные от сложных датчиков, обладающих внутренним интеллектом (Микро Питон)- датчики могут послать GET-запрос с полученными параметрами. Приложение должно анализировать принятые данные, сравнивать их с данными из базы, и в соответствии с некоторой логикой, писать также в базу.
При этом, я точно знаю, что может быть несколько вариантов использования приложения. В первом варианте, так сказать не визуальном, экземпляр приложения будет один, и к нему будут обращаться все датчики. В этом случае приложение, по сути, выступает интеллектуальным посредником между датчиками и базой. Тут важна поддержка сессий на уровне приложения. Во втором варианте, будет реализована схема: один датчик - один экземпляр приложения. При этом, приложение будет писать в базу, но оно также будет запущено и постоянно видно на экране компьютера на данном рабочем месте, где датчик, отображая текущие данные. В третьем варианте, потом нужно будет отображать данные и в браузере, оборудовав часть рабочих мест не компьютером, а Smart TV. Если при этом всплывут какие-либо проблемы с формированием контента встроенным WEB-сервером, можно будет даже пойти на запуск нескольких экземпляров приложения, по одному на каждый Smart TV, на отдельном компьютере. Просто разнеся их по портам: 8080, 8081 и.т.п.
Почему я еще цепляюсь за встроенный WEB-сервер? Во-первых, опираясь на подобный сервер, потенциально можно не изобретать велосипеды по поводу создания сессий со своим контекстом, включая цикл обработки поступающих GET-запросов (в Intraweb можно встроить простую обработку поступающих command в servercontroller.IWServerControllerBaseBeforeDispatch). Во-вторых, хочется сделать одно приложение, универсальное, к которому потом можно было бы получать доступ и по WEB, через браузер.
При этом, я точно знаю, что может быть несколько вариантов использования приложения. В первом варианте, так сказать не визуальном, экземпляр приложения будет один, и к нему будут обращаться все датчики. В этом случае приложение, по сути, выступает интеллектуальным посредником между датчиками и базой. Тут важна поддержка сессий на уровне приложения. Во втором варианте, будет реализована схема: один датчик - один экземпляр приложения. При этом, приложение будет писать в базу, но оно также будет запущено и постоянно видно на экране компьютера на данном рабочем месте, где датчик, отображая текущие данные. В третьем варианте, потом нужно будет отображать данные и в браузере, оборудовав часть рабочих мест не компьютером, а Smart TV. Если при этом всплывут какие-либо проблемы с формированием контента встроенным WEB-сервером, можно будет даже пойти на запуск нескольких экземпляров приложения, по одному на каждый Smart TV, на отдельном компьютере. Просто разнеся их по портам: 8080, 8081 и.т.п.
Почему я еще цепляюсь за встроенный WEB-сервер? Во-первых, опираясь на подобный сервер, потенциально можно не изобретать велосипеды по поводу создания сессий со своим контекстом, включая цикл обработки поступающих GET-запросов (в Intraweb можно встроить простую обработку поступающих command в servercontroller.IWServerControllerBaseBeforeDispatch). Во-вторых, хочется сделать одно приложение, универсальное, к которому потом можно было бы получать доступ и по WEB, через браузер.
- alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
Когда задача видна целиком - то можно уже и предметно предлагать решения 
Я бы не стал делать всё в виде одного приложения - разбил бы задачу на несколько модулей:
0. База данных для хранения информации - любая нормальная субд на ваш выбор (птица/слоник/MysSQL)
1. Приём информации от датчиков - это явно не визуальная часть. Вариантов реализации множество. Если хочется всё на паскале - то просто реализовать службу/демон, который будет слушать порты и обрабатывать get запросы от датчиков. Образец есть в комплекте lazarus/fpc.
2. Визуальная морда на Lazarus для отображения информации из базы.
3. Если нужна веб морда - то любой WEB серве и приложение под него. Можно только приложение под него на FPC/Lazarus, можно и полностью веб сервер паскале реализовать. Тоже есть в примерах.
4. Также можно реализовать отдельный сервис по рассылки уведомлений по любым каналам (email/sms/push уведомления) по какимто критериям информации.
У меня практически также реализован мой самописный мониторинг инфраструктуры предприятия. Отличие только в том, что у меня датчики пасивные - я их со стороны службы (аналог п.1) дёргаю и снимаю с них параметры.
Я бы не стал делать всё в виде одного приложения - разбил бы задачу на несколько модулей:
0. База данных для хранения информации - любая нормальная субд на ваш выбор (птица/слоник/MysSQL)
1. Приём информации от датчиков - это явно не визуальная часть. Вариантов реализации множество. Если хочется всё на паскале - то просто реализовать службу/демон, который будет слушать порты и обрабатывать get запросы от датчиков. Образец есть в комплекте lazarus/fpc.
2. Визуальная морда на Lazarus для отображения информации из базы.
3. Если нужна веб морда - то любой WEB серве и приложение под него. Можно только приложение под него на FPC/Lazarus, можно и полностью веб сервер паскале реализовать. Тоже есть в примерах.
4. Также можно реализовать отдельный сервис по рассылки уведомлений по любым каналам (email/sms/push уведомления) по какимто критериям информации.
У меня практически также реализован мой самописный мониторинг инфраструктуры предприятия. Отличие только в том, что у меня датчики пасивные - я их со стороны службы (аналог п.1) дёргаю и снимаю с них параметры.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
У меня практически также реализован мой самописный мониторинг инфраструктуры предприятия.
Есть и готовые каскадируемые линёвые решения типа ICINGA (Nagios) - к которому легко пишутся самописные плагины выборки-мониторинга чего угодно на самом компе и того, что можно увидеть по кабелям и сети, которые умеют рассылать оповещения на емэйл, к телеграм-ботам,..
Интересно, а нельзя ли сделать совсем просто?
1. Берем Indy IdHTTPServer
2. При загрузке приложения устанавливаем коннект с БД через MySQL57Connection
3. В обработчике IdHTTPServer1CommandGet через ARequestInfo.Params.Values[………] анализируем и извлекаем нужные данные. Принимаем решение - отдать текст HTML-страницы и (или) работать с БД.
4. Получив данные из запроса, динамически создаем SQLQuery и привязываем его к MySQL57Connection, который общий для всех создаваемых SQLQuery.
5. Читаем или пишем в БД
6. Уничтожаем SQLQuery
7. Поток обработки IdHTTPServer1CommandGet прекращает существование автоматически.
1. Берем Indy IdHTTPServer
2. При загрузке приложения устанавливаем коннект с БД через MySQL57Connection
3. В обработчике IdHTTPServer1CommandGet через ARequestInfo.Params.Values[………] анализируем и извлекаем нужные данные. Принимаем решение - отдать текст HTML-страницы и (или) работать с БД.
4. Получив данные из запроса, динамически создаем SQLQuery и привязываем его к MySQL57Connection, который общий для всех создаваемых SQLQuery.
5. Читаем или пишем в БД
6. Уничтожаем SQLQuery
7. Поток обработки IdHTTPServer1CommandGet прекращает существование автоматически.
То есть проблем с авторизацией и контекстным выполнением запросов пока в принципе нет ? А что с буферизаций и блокировкой одновременной записи/чтения одних и тех-же полей (и прочих структур БД) ? Остается на откуп самой БД или разруливается в приложении ? (А то я как-то положился на как-бы "многопользовательский" механизм "движка БД" и был печально удивлен появлением мусора, а иногда и разрушением структуры )
Сеть будет закрытая. Пока, по крайней мере, при записи очередной порции данных не требуется анализировать данные из той же таблицы, поступившие от других датчиков. Но в потоках придется читать из другой, более или менее статичной таблицы-справочника, содержащей референсные данные. Но не писать в нее... Интересно, есть какие-либо тонкости обращения к общему MySQL57Connection из потоков с динамически создаваемыми SQLQuery? А так да, я пока надеюсь на БД в смысле параллельной обработки запросов на чтение/запись
Нужно, конечно, почитать про управление транзакциями в компонентах Lazarus и их поддержку в MySQL
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
При загрузке приложения устанавливаем коннект с БД через MySQL57Connection
При сингл-коннекшэне организовать неглючный и некостыльный малтиюзер - сущий ад. Поэтому по-дружески советую индивидуальные коннекшэны, выдаваемые из пула.
Да, тут бы мне еще понять, хотя бы на будущее, будут ли разные транзакции через один MySQL57Connection действительно разными, или они окажутся вложенными транзакциями. Тогда принципиально полный тупик?
Насчет пула думаю, но кроме самописного велосипеда пока ничего не приходит в голову. Кстати, интересно - как понять, что соединение можно считать свободным?
Насчет пула думаю, но кроме самописного велосипеда пока ничего не приходит в голову. Кстати, интересно - как понять, что соединение можно считать свободным?
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Да, транзакции разных клиентов в одном коннэкшэне - полный тупик. Мало того что фиг разрулишь логически, так еще и ожидание на каждой транзакции.Да, тут бы мне еще понять, хотя бы на будущее, будут ли разные транзакции через один MySQL57Connection действительно разными, или они окажутся вложенными транзакциями. Тогда принципиально полный тупик?
Добавлено спустя 16 минут 44 секунды:
Кстати, интересно - как понять, что соединение можно считать свободным?
Выставлять признак "занято" в начале клиентского запроса, и сбрасывать этот признак в конце этого запроса. Не выдавать соединение из пула пока это признак не сброшен. При выделении коннекта из пула проверять жив ли коннект. Всегда откатывать возможные незавершенные транзакции,а также освобождать серверные ресурсы (курсоры и параметры) при возвращении соединения в пул. Следить за фичей AutoCommit...
Да, с пулом соединений конечно интересно бы разобраться, но пока, видимо, придется пробовать готовые решения. А их немного, как я понял. Что-то есть в ZEOS. Есть еще https://github.com/FMXExpress/delphipooling и https://code.google.com/archive/p/delphipooling/
Скажите, пожалуйста - никто это не использовал? Или есть что-то еще, апробированное для пула соединений (MySQL или ODBC или прочего доступа к БД)?
Кстати, в диспетчере ODBC в Windows есть какой-то встроенный пул соединений. Через него нельзя сработать? В том смысле, что иногда может быть выходом создание и уничтожение ODBC соединения в потоке. Повторные коннекты, во всяком случае, будут быстрыми.
Скажите, пожалуйста - никто это не использовал? Или есть что-то еще, апробированное для пула соединений (MySQL или ODBC или прочего доступа к БД)?
Кстати, в диспетчере ODBC в Windows есть какой-то встроенный пул соединений. Через него нельзя сработать? В том смысле, что иногда может быть выходом создание и уничтожение ODBC соединения в потоке. Повторные коннекты, во всяком случае, будут быстрыми.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
https://code.google.com/archive/p/delphipooling/
Кэшировать датасеты и параметрические запросы (если они определены в одном датамодуле с соединением) - хорошее решение, не нужно будет вручную их закрывать. Если еще и транзакции автоматические откатываются - вообще ништяк.
Кэшировать датасеты и параметрические запросы (если они определены в одном датамодуле с соединением) - хорошее решение, не нужно будет вручную их закрывать. Если еще и транзакции автоматические откатываются - вообще ништяк.
Aleks69 писал(а):...Смотрел на Lazarus fpWeb, и попробовал немного - работает, но, к стыду своему, пока не понял как его прикрутить к обычной форме. ...
Здравствуйте.
У меня возник такой же как и у автора темы вопрос: Возможно ли встроить fpWeb в GUI приложение ?
Пытаюсь решить задачу встраивания Web-сервера на основе fpWeb в GUI Win приложение.
Это возможно? Не могу сообразить как это сделать, помогите.
tsknv писал(а):Aleks69 писал(а):...Смотрел на Lazarus fpWeb, и попробовал немного - работает, но, к стыду своему, пока не понял как его прикрутить к обычной форме. ...
Здравствуйте.
У меня возник такой же как и у автора темы вопрос: Возможно ли встроить fpWeb в GUI приложение ?
Пытаюсь решить задачу встраивания Web-сервера на основе fpWeb в GUI Win приложение.
Это возможно? Не могу сообразить как это сделать, помогите.
Не знаю как там конкретной библиотекой fpWeb но в чем проблем с Web-сервером в GUI приложении ?
Вот скрин гибрид сервера и браузера(вполне себе GUI приложение на Лазарусе).


ЗЫ
Да совсем забыл ! Недавно вообще левую и чисто техническую утилитку захвата графики с "псевдо Веб доступом" сделал .


Там вообще от веб-сервера "три сточки" кода . Но работает .
Зы
Если интересно могу вытащить код тамошнего "Веб-сервера" (нужно чуть повозится потому, что это схема для ХайАсма но в основе все тоже код для FPC )
debi12345 писал(а):Залинковать C-шную libLightHTTPD.
Не понимаю... Вы имеете в виду использовать libLightHTTPD как внешний по отношению к моей программе сервер? т.е. это будет отдельный exe или dll? или FPC умеет компилировать из исходников на C чтобы можно было исходный код libLightHTTPD использовать в проекте Lazarus?
Добавлено спустя 1 минуту 14 секунд:
Добавлено спустя 11 минут 47 секунд:
Alex2013 писал(а):...Не знаю как там конкретной библиотекой fpWeb ...
при использовании fpWeb объект Application типа TApplication - это не то что TApplication из модуля Forms при использовании GUI приложения.
TApplication из модуля fphttpapp при использовании fpWeb - это консольное приложение которое имеет специфические свойства типа Port, LegacyRouting...
Alex2013 писал(а):...Вот скрин гибрид сервера и браузера(вполне себе GUI приложение на Лазарусе)....
Подскажите какие компоненты использовали? brookframework(TBrookHTTPServer)?
Добавлено спустя 6 минут 48 секунд:
В общем задача которую я пытаюсь решить выглядит примерно так: Создать приложение состоящее из одного exe файла и файла БД которое висит на 80 порту.... ну в общем чтобы к нему браузером можно было подключиться... типа Web-интерфейс к БД. Примерно так.
