= Entaxy
:imagesdir: .
:hardbreaks:

Entaxy - шина, которую можно конфигурировать извне с помощью графического интерфейса или API, состоящая из модулей:

image::Entaxy.png[]

== *Управленческий слой(core):*

=== basic-auth

модуль, отвечающий за аутентификацию в шине. Tак же занимается хранением, созданием, редактированием и удалением учетных записей.

xref:core/auth/Authorization.adoc[Более полную информации о basic-auth найдете по этой ссылке]

_Для разработчиков:
-имеет Api, который занимается Crud операциями,
-хранит учетные записи в базе данных,
-предоставляет файл с актуальной информацией для nginx,
-выставляет interсeptor для аутентификации в других сервисах,
-выставляет interсeptor для определения принадлежности аккаунта определённой системе._


=== permission

модуль, отвечающий за управление правами доступа.

xref:core/permission/SOAP-service-Permission-management.adoc[Более полную информации о permission найдете по этой ссылке]

_Для разработчиков:
-имеет Api, который занимается Crud операциями
- хранит права в базе данных,
-(camel)компонент, который используется в маршрутах, для проверки возможности отправки из системы a в систему b.
-выставляет interсeptor для авторизации в служебных сервисах._


=== system-management-api

модуль, отвечающий за создание систем и разнообразных коннекторов. (коннекторы бывают разных типов, будет описано далее)

xref:core/system-managment/Users-manual-System-management.adoc[Более полную информации о system-management найдете по этой ссылке]

__Для разработчиков:
-имеет Api, который занимается Crud операциями
-хранит параметры в базе данных,
-генерирует профиля и коннекторы на основе переданных через Api параметров и деплоит их через репозиторий nexus или файловую систему и cellar (блок Deployer) в шину.
-также имеет возможность Crud прав доступа над учетными записями систем.
__

=== system-registry

модуль, осуществляющий поддержку динамического управления профилями систем(профиль - это отражение параметров системы в шине)

__Для разработчиков:
-хранит информацию о системах в базе данных,
-(camel)компонент, который используется в маршрутах для определения нужной системы и коннектора для отправки сообщения в нее.
__

=== system-group-registry

модуль, осуществляющий поддержку динамического управления группами систем, которые определяют логику отправки в необходимую систему в определенной группе.

__Для разработчиков:
-хранит информацию о группах в базе данных,
-(camel)компонент, который используется в маршрутах для определения нужной системы из группы.
__

=== events

модуль, для работы с топиками(по схеме Publisher (издатель)-Subscriber (подписчик)) для систем.

xref:core/topic/Topic-management-Rest-service.adoc[Более полную информации о events найдете по этой ссылке]

__Для разработчиков:
-хранит информацию о топиках в базе данных,
-имеет Api(Rest), который занимается Crud операциями
__

=== schema

модуль, осуществляющий хранение всех схем, через которые делаются преобразования сообщений, валидация, поднятие сервиса в шине.

xref:core/schema/Schema.adoc[Более полную информации о schema найдете по этой ссылке]

__Для разработчиков:
-имеет Api, который занимается Crud операциями
-хранит информацию о загруженных схемах в базе данных,
-(camel)компонент, который используется в маршрутах для валидации xml через xsd, которую загрузили в бд.
-service, который подключается к xslt компоненту для подгрузки xsl из бд
-service, который подключается к cxf компоненту для подгрузки xsd и wsdl из бд
__

=== bridge

модуль, осуществляющий передачу сообщений в другую шину.

xref:core/bridge/Bridge-Description-and-Configuration.adoc[Более полную информации о bridge найдете по этой ссылке]

__Для разработчиков:
-знает о всех подключенных шинах и их именах в рамках всей системы
-осуществляет передачу сообщений через artemis, также получает сообщения из другой шины.
-в перспективе будет создан компонент который по названию будет определять в какую шину отправить, а не напрямую через очереди, как это сделано сейчас.
__

=== Error Handler

модуль, осуществляющий за обработку ошибок в шине.

Централизованный обработчик ошибок для формирования кодов ошибок, их синхронного возврата клиенту и для асинхронного дублирования более подробного описания ошибки (для клиента и для Центральной Базы Интеграции).

xref:core/exception/Centralized-error-handler.adoc[Более полную информации о централизованном обработчике ошибок найдете по этой ссылке]

xref:core/exception/Error-description.adoc[Более полную информации о классификации ошибок найдете по этой ссылке]

__Для разработчиков:
-знает о всех подключенных шинах и их именах в рамках всей системы
-осуществляет передачу сообщений через artemis, также получает сообщения из другой шины.
-в перспективе будет создан компонент, который по названию будет определять в какую шину отправить, а не напрямую через очереди, как это сделано сейчас.
__

=== Deployer

набор модулей осуществляющих работу с бандлами

xref:core/deployer/deployer-common.adoc[Более полную информации о Deployer найдете по этой ссылке]

__Для разработчиков:
-deployer-api - интерфейс репозитория для хранения артефактов
-file-system-deployer - реализация репозитория в папке
-nexus-deployer - реализация репозитория в Sonartype Nexus
-cellar-deployer - система управления бандлами через Apache Cellar
__

== Также как вспомогательные инструменты используется следующие модули:

_сellar_ - модуль для загрузки сгенерированных blueprint в шину(в несколько карафов).
_ignite_ - модуль для создания распределенного хранилища ключ-значение.(используется для более быстрой работы некоторых компонентов, которым нужно хранилище)
_liquibase_ - модуль для поддержки актуальной схемы бд.

== Клиентский слой

_US_ - универсальный коннектор, через который можно отправлять сообщения в другие системы.
_(делится на обычный и служебный)_
xref:connectors/uniform-exchange-service/uniform-exchange-service.adoc[Универсальный сервис]

_file-connector_ - коннектор, который сообщения для определенной системы отправляет с помощью файла(получая сообщение, проводит необходимые преобразования, нпрм архивацию, и складывает в определенную папку).

_db-connector_ - коннектор, который осуществляет обмен сообщениями с системой через бд. (сообщение полученное из другой системы конвертируется в запись в бд, и для отправки сообщения в шину необходимо сделать запись в бд)

xref:connectors/create_new_connectors.adoc[Информация о создании новых коннекторов]

image::connectors/db-connector/deployment_schema.png[]

_nsi_ - soap коннектор, который был поднят с помощью клиентской wsdl и работает по специальной схеме, определенной клиентом с помощью бд.
_big-packets-connector_ - soap коннектор, через который можно отправлять сообщения в другие системы, предназначенный для отправки больших сообщений, которые отправляются по частям.

=== Необходимые для шины внешние модули

nginx(опционально) - балансировщик нагрузки, также занимается предварительной аутентификацией.
nexus(опционально) - необходим для хранения и динамической развертки блюпринтов.
db(поддерживается mssql и postgresql) esb_entaxy - необходима для хранения служебных данных(связанных с настройкой маршрутов в шине).
db(поддерживается mssql и postgresql) cache - необходима для хранения временных данных, связанных с определенным сообщением.
artemis - брокер сообщений.
file-storage(nfs) - необходим для работы сервиса больших пакетов, nginx и тд.

=== Схема прохождения пакета

Для разработчиков:

image::connectors/Message.png[]

_Все сообщения отправляемые в шину будут отправляться из входного коннектора в выходную точку профиля._

Общее описание Entaxy:

xref:core/Common-description-of-the-transport-layer.adoc[Общее описание Entaxy]