@strelkovandreyvalerievich

Как реализовать сервис уведомлений внутри Интранет сети?

Добрый день. Вопрос большой, но пока интересует архитектура как это должно быть.

Итак, представьте что есть большое предприятие, с Интранет сетью, Active Directory c примерно 5000 активных пользователей. Внутри предприятия силами отдела разработки создано многочисленные как десктоп так и веб-приложения.
Необходимо создать некий сервис уведомлений, которым смогут пользоваться как разработчики со стороны своих приложений (т.е. интегрироваться с ним, и с помощью него отправлять уведомления) так и конечные пользователи, которые с помощью десктоп клиента или же веб-клиента получать уведомления адресованные им.
Одними из основных требований этих уведомлений, это то что они все должны где то хранится, а именно в базе данных, и каждое уведомление должно иметь своего получателя, прочитанность которого также должна фиксироваться в базе данных.

Я лишь ещё начинающий разработчик на C#, только только начинаю изучать это, потому я пока пытаюсь понять концепцию как это должно работать, считая что у этого сервиса в будущем должны быть различные дополнительные и обязательные функции (такие как контроль доступ к API, к возможности создания уведомления, его чтения и т.п.)
То сначала хочу понять как это на архитектурном уровне должно быть, чтобы потом могло легко допиливаться.

Прошу отнестись к моим высказываниям как совсем ещё начинающему разработчику.

Как я это вижу, допустим в качестве базы данных используется Oracle, хотя подразумеваю что нужно делать так, чтобы было без разницы какая база, что MySQL, MSSQL, Postgresql и т.п.
Т.к. подразумеваю, что база данных используется только как хранилище, только для CRUD (никакой бизнес логики в ней не должно быть, бизнес логику хочу поместить в приложение)

Модель базы данных понравилась здесь www.vertabelo.com/blog/technical-articles/database...
Т.к. в ней есть понятие именно одного сообщения, и отдельных уведомлений с привязкой к сообщению для каждого пользователя, а также идеология групп подписок.

Т.е. по базе данных имею грубо говоря набор из 3х таблиц на первую простейшую реализацию, это message, message_recipient и user. С помощью которых уже можно создавать сообщения их уведомления с фактом прочтённости и со связью с получателем.

Сам механизм создания этих сообщения, я хочу поместить в отдельно живущее API в виде WebAPI на C#, которое по программе минимум будет иметь набор из несколько методов (или как то они подругому называются),с помощью которых можно создать сообщение и получить сообщение.

Т.е. разработчик будет отправлять на WebAPI некий HTTP запрос, где в параметрах как минимум укажет Текст сообщения, Идентификатор получателя/елей. Например:

ТЕКСТ СООБЩЕНИЯ: На вас назначена задача
ПОЛУЧАТЕЛЬ: "ivanov.aa","petrov.bb","sidorov.cc"

Таким образом в базе в таблице message создастся одна строка (т.к. одно сообщение) в таблице message_recipient 3 строки (т.к. 3 получателя) со связью на одну строку из таблицы message и по одной связи от каждой строки к таблице user соответственно по получателю

Таким образом будет на сервере приложений висеть в ожидание запросов некое WebAPI к которому будут обращаться разработчики со стороны своих приложений (тут конечно на будущее нужно будет как раз ещё как то реализовать разграничение прав доступ к API, т.е. вообще возможность создания сообщения, возможность кому отправлять сообщения (каким пользователям или сразу подписки с группой пользователей/подписчиков) но это уже потом

А далее получается нужен как минимум десктоп клиент, который будет висеть в трее пользователя и периодически опрашивать это же WebAPI на получение новых уведомлений с контекстом в виде текущего авторизованного в ОС пользователя. На что WebAPI должно выдать только те сообщения, которые доступны по связям текущему пользователю.

Пока не забегая далее вперёд, что можете сразу посоветовать, предупредить и по рекомендовать. Спасибо!
  • Вопрос задан
  • 264 просмотра
Пригласить эксперта
Ответы на вопрос 2
@m0nym
Jabber возьми за основу.
Сервер Джаббера - есть несколько на выбор.
Библиотек для клиента под Джаббер - более чем достаточно
Ответ написан
Комментировать
gromdron
@gromdron
Работаю с Bitrix24
Мне кажется, что вопрос изначально стоит не в том чтобы написать свой сервис, а в том чтобы отправить соответствующие уведомления.
Опять же, уведомления отправляются куда-то - например в приложение или на почту, но тогда у всех сотрудников должно быть.
А что есть в увсех сотрудников, которые работают на таком большом предприятии? Правильно - почта.

В чем преимущества использовании почты перед остальными вариантами?
1) Она есть у всех офисных сотрудников.
2) Она кроссплатформенная. Т.е. и Android, iOS, Windows, Mac etc
3) Она уже сохраняет отправленные уведомления (не нужно заботиться о хранении, т.к. всегда знаем кто, когда и кому отправил)
4) У многих серверов уже есть прослойка в виде Web-API или готовых протоколов (smtp) и множество реализаций

В чем недостатки:
1) Не у всех сотрудников она может быть. Например у грузчиков ее может и не быть, но я не думаю что Вы им будете отправлять уведомления. В крайнем случае можно и завести
2) Отправляет лишь текстовые сообщения (не push, не комманды и т.п.). Но вроде как Вам это и нужно.

В итоге - не нужно ничего писать, просто заведите корпоративную почту и все.

P.S. Если уж очень хочется написать свой неоптимальный дублирующий велосипед, то можете перед ней поставить буфером свое приложение, на которое все остальные будут ссылаться.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы