Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может . Для всего этого выбрана SOA, но тут требуется реализация стандартного паттерна publisher — subscriber, а, например, под WCF — это duplex communication — проприетарная технология, а хочется странного — возможности расширяемости системы, т.е. возможности подключения софта третьей стороны, поэтому никакого Дуплекса хотя прототип уже работает именно на такой реализации и менеджмент уже "тащится" от возможностей... Kакие есть альтернативы, чтобы и SOA, и поддержка различных протоколов (именно по этой причине "вроде как" Web API не подходит — кому-то показалось, что обмен по http слишком медленный, хотя есть возможность использовать здесь и tcp ? — но тут могу ошибаться, про Web API я только читал...). SignalR тоже смотрели — слишком много нужно тянуть сборок непонятного назначения, да еще работа с dynamic типами... NetMQ — проприетарна с точки зрения возможности подключения софта третьей стороны... Есть ли вообще требуемое в природе? Сориентируйте пожалуйста.
Здравствуйте, sourcerer, Вы писали:
S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время
Возможно, M2Mqtt — MQTT Client Library for .Net
Он и PUB/SUB, и маленький, и быстрый, и создавался как раз для мониторинга.
Здравствуйте, sourcerer, Вы писали:
S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может .
Рассмотрите такой вариант: каждая часть системы подключается к СУБД и вносит/читает необходимые ей данные из таблицы.
Плюсы: коннекторы для популярных СУБД есть под любые ОС и под любые платформы. Все строго типизировано. Базы бывают на любой вкус и цвет.
S>каждая часть системы подключается к СУБД и вносит/читает необходимые ей данные из таблицы.
S>Плюсы: коннекторы для популярных СУБД есть под любые ОС и под любые платформы. Все строго типизировано. Базы бывают на любой вкус и цвет.
Обмениваться данными через БД? Это опять поллинг, но теперь уже в БД — не все СУБД настолько интегрированы в ОС, что могут генерировать собственные события (я сейчас не о триггерах конечно, а о механизмах общения с "внешним миром"...).
Здравствуйте, Слава, Вы писали:
С>Возможно, M2Mqtt — MQTT Client Library for .Net
С>Он и PUB/SUB, и маленький, и быстрый, и создавался как раз для мониторинга.
Посмотрел, спасибо.
В общем, в решении с WCF не устраивает лишь проприетарность duplex connection, с обменом же сообщениями придется решать массу доп.проблем — например вызов удаленных процедур — лишь через Reflection, т.е. ожидаю нечто большее, чем стандартный паттерн pub-sub... Вероятно, нужно будет, "гибрид" делать — вызов RPC через механизмы WCF (обычный service contract и т.п.), а часть, реализующую функциональность pub-sub — через WebSockets — эта технология хотя бы не проприетарна, а стала стандартом de facto. На самом деле, и это решение мне не слишком нравится — я всегда был против зоопарков технологий.
Блин ну хоть бы читали сообщение... сразу неее..
Это для установки on premise...
Service Bus for Windows Server is a set of installable components that provides the messaging capabilities of Windows Azure Service Bus on Windows. Service Bus for Windows Server enables you to build, test, and run loosely-coupled, message-driven applications in self-managed environments and on developer computers. Service Bus queues offer reliable message storage and retrieval with a choice of protocols and APIs. Building on the same foundation as queues, Service Bus topics provide rich publish/subscribe capabilities that allow multiple, concurrent subscribers to independently retrieve filtered or unfiltered views of the published message stream.
Здравствуйте, sourcerer, Вы писали:
S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может .
Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.
Если нужно синхронные сервисы — обычный JSON/XML через веб-сервисы.
Здравствуйте, Cyberax, Вы писали:
C>Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.
C>Если нужно синхронные сервисы — обычный JSON/XML через веб-сервисы.
А можно чуть подробней про технологию — о чем почитать? (JSON — это же формат... хотя про JSON-RPC я краем уха слышал), а веб-сервисы... если не рассматривать устаревшие технологии — остается Web API, и все тот же WCF (уже без duplex'a)... вероятно все же Web API.
Здравствуйте, Cyberax, Вы писали:
C>Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.
Начал смотреть RabbitMQ, а потом и сам AMQP, наткнулся на Apache Qpid — похоже то, что нужно — вот нам и SOA