Архитектурные принципы: интеграция

Интеграция, базирующаяся на стандартах
Формулировка	Интеграция между системами должна базироваться на стандартах (протоколы, форматы и т.п.)
Основная причина	Интеграция, базирующаяся на стандартах, улучшает интероперабельность (т.е. способность продукта или системы, интерфейсы которых полностью открыты, взаимодействовать и функционировать с другими продуктами или системами без каких-либо ограничений доступа и реализации) не только с существующими системами, но и с системами, которые будут внедрены в будущем. Это облегчает целостное управление и мониторинг, а также увеличивает стоимость поддержки и усложняет развитие интеграции между системами.
Следствия/выводы	·         Поддержка промышленных стандартов таких как SOAP, REST, JMS, MQ и т.п. ·         При разработке избегать подхода в интеграции «точка-точка», т.к. этот подход имеет тенденцию становиться негибким и более дорогом в поддержке и развитии. См. принцип «Избегать интеграции по принципу Точка-Точка»

Логическая модель данных
Формулировка	Сообщения и форматы данных должны базироваться на логической модели бизнес объектов вместо нативных структур данных конкретных приложений
Основная причина	Основная цель сервис-ориентированной интеграции – это способствовать созданию композитных приложений. Распространение форматов данных специфичных конкретным приложениям негативно влияют на возможность композиции.
Следствия/выводы	·         Архитектура должна предоставлять возможность создания и использования логической модели данных ·         Формат данных должен базироваться на логической модели бизнес-сущностей

Нормализованные форматы данных
Формулировка	Трансформация данных «из» и «в» нормализованные форматы данных.
Основная причина	Нормализованные форматы данных способствуют композиции и снижают количество трансформаций, которые должны быть созданы и поддерживаться.
Следствия/выводы	·         Если нормализованных форматов данных нет, то они должны быть созданы; ·         Архитектура должна предоставлять возможности по трансформации данных из одного формата в другой.

Избегать интеграции по принципу Точка-Точка
Формулировка	Интеграцию по принципу Точка-Точка следует избегать
Основная причина	Интеграция по принципу Точка-Точка негибкая и более дорогая в поддержке. Хотя существуют случаи, когда интеграция по принципу Точка-Точка необходима и такие случаи нужно считать исключениями. Пример исключений включает требования к производительности, которые могут быть достигнуты используя Точка-Точка и когда передаётся большой объём данных.
Следствия/выводы	·         Архитектура должна предоставлять средства для отделения (т.е. отсутствия жесткой связи) участников интеграция; ·         Архитектура должна предоставлять механизм для передачи большого объёма данных, когда это необходимо; ·         Следует избегать интеграции по принципу Точка-Точка.

Техническая оркестровка
Формулировка	Техническая оркестровка должна быть отделена от бизнес-процессов
Основная причина	Явное разделение между техническими и бизнес аспектами способствует улучшению поддержки и развития. Технические аспекты меняются, когда происходит изменение конкретной системы, а бизнес аспекты, когда меняется бизнес-процессы.
Следствия/выводы	·         Архитектура должна поддерживать оба вида процессов (техническая оркестровка и бизнес процессы) ·         В документации (руководства) должны быть описаны различия между технической оркестровкой и бизнес-процессами, а также возможные подходы к их реализации.

Выделение бизнес-сервисов
Формулировка	Бизнес-сервисы реализовывают бизнес уровень функциональности и данных
Основная причина	Бизнес уровень функциональности и данных необходим для создания ценных для бизнеса композитных приложениям, а также возможности реализации и поддержки бизнес-процессов подготовленными бизнес пользователями. Также могут быть низкоуровневые сервисы, которые переиспользуются в бизнес-сервисах.
Следствия/выводы	·         Сервисы должны быть созданы в соответствии с слоями архитектуры; ·         При разработке сервисов должно учитываться разделение сервисов на технические и бизнес; ·         Архитектура должны поддерживать бизнес-сервисы.

Доступ через сервисы
Формулировка	Доступ к данным или функциональности должен осуществляться через сервисы.
Основная причина	Сервисы предоставляют основу для гибкой композитной разработки.
Следствия/выводы	·         Архитектура должны предоставлять механизм для доступа к данным через сервисы; ·         Архитектура должна предоставлять механизм для доступа к функциональности через сервисы.

Непрозрачная реализация сервиса
Формулировка	Реализация сервиса не должна быть прозрачной для всех потребителей сервиса.
Основная причина	Потребители сервиса должны быть в состоянии успешно вызывать сервисы без необходимости понимания внутреннего устройства вызываемого сервиса.
Следствия/выводы	·         Интерфейс сервиса должен быть создан таким образом, чтобы детали реализации не были видны через интерфейс; ·         Архитектура должны поддерживать возможность непрозрачной реализации сервисов.

Версионность сервисов
Формулировка	Может быть одновременно несколько версий сервиса в промышленной эксплуатации.
Основная причина	Как правило, сервисы изменяются для подключения новых потребителей и расширения функциональности.
Следствия/выводы	·         Должна быть описана стратегия версионирования сервисов; ·         Архитектура должна поддерживать несколько параллельных версий сервиса.