diff --git a/text/0000-fsbkafkaIntegration.md b/text/0000-fsbkafkaIntegration.md
new file mode 100644
index 0000000..6e2f807
--- /dev/null
+++ b/text/0000-fsbkafkaIntegration.md
@@ -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. Какие части продложенного проектного решения подлежат дальнейшему
+уточнению? Есть ли проблемы, которые однозначно нельзя решить и по которым
+требуется принятие окончательного решения после обсуждения?
diff --git a/text/0000-phpPythonlibs.md b/text/0000-phpPythonlibs.md
new file mode 100644
index 0000000..b935a85
--- /dev/null
+++ b/text/0000-phpPythonlibs.md
@@ -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. Какие части продложенного проектного решения подлежат дальнейшему
+уточнению? Есть ли проблемы, которые однозначно нельзя решить и по которым
+требуется принятие окончательного решения после обсуждения?