Skip to content

Add files via upload #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kafnevod wants to merge 9 commits into
base: master
Choose a base branch
from
Open

Add files via upload #3

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
a3b8a38
Add files via upload
Feb 17, 2018
38ffcac
Add files via upload
Feb 17, 2018
4b445f5
Update 0000-kafkaFSB.md
Feb 19, 2018
e93b0ba
Delete 0000-kafkaFSB.md
Feb 19, 2018
634863d
Update 0000-phpPythonlibs.md
Feb 19, 2018
e1d1778
Update 0000-phpPythonlibs.md
Feb 19, 2018
19505a1
Add files via upload
Feb 19, 2018
be7d934
Delete FSB-kafka.md
Feb 19, 2018
9de0fd1
Create 0000-fsbkafkaIntegration.md
Feb 19, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions text/0000-fsbkafkaIntegration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
- Дата создания:2017-02-17
- RFC PR:
- RFC Issue:
- Flexberry Issue:

# Интеграция Flexberry Service Bus с брокером сообщений kafka

## Краткое описание

Создать настаиваемые адаптеры, обеспечивающие двусторонний обмен соощениями между Flexberry Service Bus и брокером сообщений kafka

## Обоснование

Flexberry Service Bus отлично справляется с задачей координации потоков даныых невысокой (до сотни сообщений в секунду) интенсивности.
В то же время в ряде задач приходится иметь дело с обработкой потоков высокой (сотни, тысячи сообщений в секунду) интенсивности.

Эти два решения взаимно дополняют друг друга, но при совместном использовании необходимо обеспечить взаимную интеграцию этих двух типов шин:
* клиенты работающие с Flexberry Service Bus должны иметь возможность передавать и получать сообщения из брокера сообщений kafka;
* клиенты работающие с kafka должны иметь возможность передавать и получать сообщения из Flexberry Service Bus.


## Детальное проектирование


Необходимо на одном из языков программирования (C#, Python, ...) написать легко-конфигуриуемые адаптеры, обеспечивающие:
* подписке на тему Flexberry Service Bus и передачу всех полученных сообщений в тему (topic) kafka;
* подписке на тему (topic) kafka и передачу всех полученных сообщений в тему Flexberry Service Bus.

Возможны два варианта реализации:
* для каждой пары тема Flexberry Service Bus - тема kafka запускается отдельный адаптер;
* для каждого направления запускается по одному адаптеру, обеспечивающему пием и передачу сообщений по всем подписанным темам.

Возможно комбинированное использование - для передачи сообщений от kafka в Flexberry Service Bus запускается по отдельному адаптеру для каждой темы,
для пеедачи сообщений от Flexberry Service Bus к kafka запускается один адаптер, принимающий сообщений по всем темам по callBack-механизму.


## Документирование и обучение

> Данный раздел заполняется при необходимости. Минимально рекомендуется указать
необходимые изменения в документации платформы.

> Какие определения и термины лучше всего подойдут для объяснения описанного
проектного решения и почему? Как наилучшим образом презентовать описанную
идею - как логическое продолжение используемых в платформе подходов или как
совершенно новую концепцию?

> Должно ли принятие RFC повлечь изменения в структуре или тексте документации?
Затрагивают ли эти измнения подход к обучению пользователей работе с платформой?

> Каким образом проектное решение должно быть представлено для существующих
пользователей платформы?

## Недостатки

> Есть ли причины, почему *не* нужно принимать предложенное проектное решение?
Пожалуйста, хорошо оцените влияние предложенной идеи на обучение платформе, на
интеграцию с существующим и планируемым функционалом, на необходимые изменения
в API и исходном коде существующих приложений, реализованных на базе платформы
и т.п.

> Пожалуйста, попытайтесь идентифицировать необходимые компромисы и последствия
принятия предложенной идеи.

## Альтернативы

> Существуют ли другие варианты проектного решения? Почему мы не выбрали один из
этих вариантов?

> Каким образом подобные проблемы решаются в других аналогичных платформах,
фреймворках, библиотеках?

## Нерешенные вопросы

> Этот раздел является опциональным, но чаще всего необходим для первых "черновых"
версий RFC. Какие части продложенного проектного решения подлежат дальнейшему
уточнению? Есть ли проблемы, которые однозначно нельзя решить и по которым
требуется принятие окончательного решения после обсуждения?
75 changes: 75 additions & 0 deletions text/0000-phpPythonlibs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
- Дата создания: 2018-02-17
- RFC PR:
- RFC Issue:
- Flexberry Issue:

# Интерфейсные библиотеки на языках PHP, Python к Flexberry Servive Bus

## Краткое описание

Создать на языках PHP, Python набора библиотек (классов) обеспечивающих основной интерфейс (передачу, подписку, прием сообщений)
с Flexberry Servive Bus

## Обоснование

Реализация библиотек и классов на языках PHP, Python (возможно Java, Scala) значительно расширит круг пользователей Flexberry Servive Bus,
позволит состыковать ее с широким классом программных комплексов и технологий.

## Детальное проектирование

Как правило развитие программные продукты с открытыми лицензиями (
[MongoDB](http://api.mongodb.com/), clickHouse, Cassandra, [kafka](https://cwiki.apache.org/confluence/display/KAFKA/Clients) и т.п.) имеют
реализацию библиотек на широком наборе языков:
* Python;
* PHP;
* Java;
* Scala;
* C++;
* Erlang;
* GO;
* ...

Предлагается реализовать набор библиотек (классов) для работы с Flexberry Servive Bus для языков PHP и Python.

В качестве примера возможного использования данных библиотек можно привести систему Сокол, где необходимо обеспечивать
возможность взаимодействия системы Сокол (С#) с сиcтемой Сокол-Аналитика (Python, PHP, в дальнейшем Scala).
В дальнейшем предполагается в Сокол-Аналитика (и других возможных проектах) использовать технологию потоковой обработки данных Spark-Streaming,
поддерживающая языки Java, Scala, Python.

На первом этапе предлагается написать библиотеки (классы) на самих языках программирования (Python, PHP).
При наличии четко прописанного API готов поучаствовать как в написании постановки задачи, так и в реализации, тестировании и
использования в работах Сокол, Сокол аналитика и других.

В случае необходимости возможна оптимизация путем реализации данных библиотек на языках низкого уровня (С).

## Документирование и обучение


Описание библиотек и классов с примерами необходимо включить в основную документацию наряду с примерами на языке C#.


## Недостатки

> Есть ли причины, почему *не* нужно принимать предложенное проектное решение?
Пожалуйста, хорошо оцените влияние предложенной идеи на обучение платформе, на
интеграцию с существующим и планируемым функционалом, на необходимые изменения
в API и исходном коде существующих приложений, реализованных на базе платформы
и т.п.

> Пожалуйста, попытайтесь идентифицировать необходимые компромисы и последствия
принятия предложенной идеи.

## Альтернативы

> Существуют ли другие варианты проектного решения? Почему мы не выбрали один из
этих вариантов?

> Каким образом подобные проблемы решаются в других аналогичных платформах,
фреймворках, библиотеках?

## Нерешенные вопросы

> Этот раздел является опциональным, но чаще всего необходим для первых "черновых"
версий RFC. Какие части продложенного проектного решения подлежат дальнейшему
уточнению? Есть ли проблемы, которые однозначно нельзя решить и по которым
требуется принятие окончательного решения после обсуждения?