SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 27.11.15 09:41
Оценка:
Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может . Для всего этого выбрана SOA, но тут требуется реализация стандартного паттерна publisher — subscriber, а, например, под WCF — это duplex communication — проприетарная технология, а хочется странного — возможности расширяемости системы, т.е. возможности подключения софта третьей стороны, поэтому никакого Дуплекса хотя прототип уже работает именно на такой реализации и менеджмент уже "тащится" от возможностей... Kакие есть альтернативы, чтобы и SOA, и поддержка различных протоколов (именно по этой причине "вроде как" Web API не подходит — кому-то показалось, что обмен по http слишком медленный, хотя есть возможность использовать здесь и tcp ? — но тут могу ошибаться, про Web API я только читал...). SignalR тоже смотрели — слишком много нужно тянуть сборок непонятного назначения, да еще работа с dynamic типами... NetMQ — проприетарна с точки зрения возможности подключения софта третьей стороны... Есть ли вообще требуемое в природе? Сориентируйте пожалуйста.
Недостатки прощаются, достоинства — никогда.
Re: SOA: Проблема выбора технологии под .NET
От: Слава  
Дата: 27.11.15 15:02
Оценка: 6 (2)
Здравствуйте, sourcerer, Вы писали:

S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время


Возможно, M2Mqtt — MQTT Client Library for .Net

Он и PUB/SUB, и маленький, и быстрый, и создавался как раз для мониторинга.
Re: SOA: Проблема выбора технологии под .NET
От: Shmj Ниоткуда  
Дата: 27.11.15 17:39
Оценка:
Здравствуйте, sourcerer, Вы писали:

S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может .


Рассмотрите такой вариант: каждая часть системы подключается к СУБД и вносит/читает необходимые ей данные из таблицы.

Плюсы: коннекторы для популярных СУБД есть под любые ОС и под любые платформы. Все строго типизировано. Базы бывают на любой вкус и цвет.
Re[2]: SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 29.11.15 09:24
Оценка:
Здравствуйте, Shmj, Вы писали:


S>каждая часть системы подключается к СУБД и вносит/читает необходимые ей данные из таблицы.


S>Плюсы: коннекторы для популярных СУБД есть под любые ОС и под любые платформы. Все строго типизировано. Базы бывают на любой вкус и цвет.


Обмениваться данными через БД? Это опять поллинг, но теперь уже в БД — не все СУБД настолько интегрированы в ОС, что могут генерировать собственные события (я сейчас не о триггерах конечно, а о механизмах общения с "внешним миром"...).
Недостатки прощаются, достоинства — никогда.
Re[2]: SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 29.11.15 09:40
Оценка:
Здравствуйте, Слава, Вы писали:

С>Возможно, M2Mqtt — MQTT Client Library for .Net


С>Он и PUB/SUB, и маленький, и быстрый, и создавался как раз для мониторинга.


Посмотрел, спасибо.
В общем, в решении с WCF не устраивает лишь проприетарность duplex connection, с обменом же сообщениями придется решать массу доп.проблем — например вызов удаленных процедур — лишь через Reflection, т.е. ожидаю нечто большее, чем стандартный паттерн pub-sub... Вероятно, нужно будет, "гибрид" делать — вызов RPC через механизмы WCF (обычный service contract и т.п.), а часть, реализующую функциональность pub-sub — через WebSockets — эта технология хотя бы не проприетарна, а стала стандартом de facto. На самом деле, и это решение мне не слишком нравится — я всегда был против зоопарков технологий.
Недостатки прощаются, достоинства — никогда.
Re: SOA: Проблема выбора технологии под .NET
От: ZloeBablo Германия  
Дата: 29.11.15 10:45
Оценка:
В качестве льтернативы:
Service Bus for Windows Server

Рассказал бы поболее о системе...
Re[2]: SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 29.11.15 10:54
Оценка:
Здравствуйте, ZloeBablo, Вы писали:

ZB>В качестве aльтернативы:

ZB>Service Bus for Windows Server

Azure? ... не-не-не...
Недостатки прощаются, достоинства — никогда.
Re[3]: SOA: Проблема выбора технологии под .NET
От: ZloeBablo Германия  
Дата: 29.11.15 11:01
Оценка: +1
S>Azure? ... не-не-не...

Блин ну хоть бы читали сообщение... сразу неее..
Это для установки 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.

Re: SOA: Проблема выбора технологии под .NET
От: Cyberax Марс  
Дата: 29.11.15 11:27
Оценка: +1
Здравствуйте, sourcerer, Вы писали:

S>Нужно связать разрабатываемый софт с другими частями системы, чтобы этот софт мог отдавать по запросу интересующие части логов, например, и другие свои параметры работы (реальное время тут не является вопросом — собственно под Вин оно вообще рассматриваться как требование не может .

Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.

Если нужно синхронные сервисы — обычный JSON/XML через веб-сервисы.
Sapienti sat!
Re[2]: SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 29.11.15 11:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.


C>Если нужно синхронные сервисы — обычный JSON/XML через веб-сервисы.

А можно чуть подробней про технологию — о чем почитать? (JSON — это же формат... хотя про JSON-RPC я краем уха слышал), а веб-сервисы... если не рассматривать устаревшие технологии — остается Web API, и все тот же WCF (уже без duplex'a)... вероятно все же Web API.
Недостатки прощаются, достоинства — никогда.
Re[2]: SOA: Проблема выбора технологии под .NET
От: sourcerer Германия  
Дата: 29.11.15 20:40
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Выкинуть нафиг это WCF-гуано и взять обычный RabbitMQ. Это просто тупая и надёжная система обмена сообщений. Все эти попытки сделать "дуплекс" и прочую хрень — это изначально провальная затея.


Начал смотреть RabbitMQ, а потом и сам AMQP, наткнулся на Apache Qpid — похоже то, что нужно — вот нам и SOA
Недостатки прощаются, достоинства — никогда.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.