exam16 6
Реферат к лекции 16 Проектирование интеграционных решений.
Выполнил: Коньков Антон, группа ИДБ-19-06
Проверил: Веселов Илья, группа ИДБ-19-06
Сервисная шина предприятия (англ. enterprise service bus, ESB) — архитектурный паттерн, при котором связующее программное обеспечение, выполняет централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры (SOA). ESB обычно реализуется с помощью специально разработанной среды выполнения интеграции и набора инструментов (т.е. продукта ESB), которые обеспечивают наилучшую производительность.
Есть система из большого количества сервисов — каждый занимается чем-то своим, предоставляет часть функциональности всей системы. Сервисы общаются между собой простым способом — каждый вызывает или отправляет запросы тем сервисам, которые ему нужны. Получается такая схема, где каждый связан еще с несколькими другими. Разные сервисы используют различные протоколы для общения. Наглядно это выглядит так:
При наличии множества сервисов работа может легко превратиться в хаос — чтобы наладить пути коммуникации между ними, понадобится много ресурсов, а любое нововведение потянет за собой череду изменений, которые нужно будет вносить во все сервисы. При этом масштабирование в такой ситуации превращается в сущий кошмар.
Используя ESB можно достигнуть следующего результата:
Помогает решить проблему, когда разные сервисы общаются в разных протоколах. В ситуации, когда ESB не используется и нужно добавить еще один сервис, который будет общаться с несколькими другими по разным протоколам. Тогда нужно будет включить в него поддержку этих протоколов. Если же понадобится поменять какой-то протокол, то его нужно будет изменить во всех связанных сервисах. В такой схеме масштабирование превращается в головную боль.
ESB позволяет этого избежать — она берет на себя всю работу с протоколами, с их обработкой и трансформацией. Соответственно, каждый сервис может общаться с помощью какого-то одного протокола, например, по HTTP. Ему больше ничего знать не надо. Если он хочет отправить сообщение другому сервису, он делает это по HTTP на ESB. А дальше она преобразует HTTP, например, в JMS и наоборот.
Получается, что от сервисов скрыта внутренняя реализация: они не обязаны знать, кто как работает, их задача — отправить сообщение на шину. Соответственно, если у одного из сервисов поменять протокол, к примеру, был HTTP, стал JMS, то надо поправить это в одном месте — на самой шине.
Количество протоколов, которые поддерживает шина, зависит от конкретных решений.
Один сервис может предоставлять ответ в формате XML, второй — в JSON, третий - в CSV. Все это надо преобразовать, чтобы разные сервисы понимали друг друга. Эту задачу ESB тоже берет на себя. Многие ESB предоставляют достаточно удобные графические инструменты для преобразования данных.
Используя сервисную шину, можно одновременно работать с большим количеством информационных корпоративных систем и сервисов, равномерно распределяя нагрузку между отдельными приложениями. Плюс масштабируемость позволяет наращивать информационные мощности компании без необходимости иметь однородный ИТ-ландшафт.
ESB предоставляет сильно продвинутую логику маршрутизации. Например, можно добавить фильтры: «Если пришло сообщение, а там есть такое поле в таком-то значении, то отправим туда. Если другое значение, то отправим сюда».
Также есть возможность мультиплексирования, чтобы одно сообщение разослать нескольким клиентам. Причем можно отправить сразу всем или какому-то конкретному списку.
Можно сделать разбиение сообщения. Например, пришло одно большое сообщение, оно разбивается на пять маленьких, каждую часть отправили в свой сервис. Ответы собрали в одно большое сообщение и отправили обратно. Эту логику на себя берет ESB.
Другая возможность — добавление условных маршрутов. К примеру, пришло какое-то сообщение, но в нем нет нужного поля, поэтому оно не будет обработано.
Если сообщение было отправлено, то получатель его обязательно получит. Даже если его в тот момент не было «в живых», то когда он появится и подключится к ESB, сообщение все равно будет доставлено.
ESB позволяет в целом посмотреть, где в данный момент находится сообщение, куда уходит, помогает собирать статистику и так далее.
ESB позволяет самостоятельно вносить какие-то изменения в процесс и не трогать для этого разработчиков. Например, сегодня вы решили, что сообщения должны идти в какую-то другую систему, а завтра поменяете обратно и все будет продолжать работать. Однако, неподготовленному человеку может быть трудно разобраться с IDE.
-
Apache Camel (фреймворк для разработки интеграционных решений, в том числе и для разработки ESB)