Кто-то может объяснить Сервисную шину предприятия мне в non-buzzspeak?
Некоторые наши партнеры говорят нам, что наше программное обеспечение должно взаимодействовать с Сервисной шиной предприятия. После исследования этого немного, мой инстинкт должен сказать, что это - просто шум, выступают за высказывание, что у нас должна быть платформа-indpendent способ передать сообщения назад и вперед. Я просто пытаюсь получить ощущение того, что наши партнеры говорят нам. Я корректен в отклонении запроса наших партнеров как просто пытающийся заставить наше программное обеспечение быть более совместимым модным словечком, или они говорят нам что-то, что мы должны слушать (даже если закодированный в buzzspeak)?
4 ответа
Хотя ESB основан на обмене сообщениями, это не «просто» обмен сообщениями и не просто модное слово.
Итак, если вы начнете с простого старого асинхронного обмена сообщениями, ранние сети, как правило, были очень двухточечными. Вам приходилось подключать (т.е. настраивать через какой-то административный интерфейс) каждое соединение и каждую пару пунктов назначения, и если вы осмеливались перемещать что-либо, неизменно что-то ломалось. Поскольку точки подключения подключались вручную, в этих сетях никогда не было высокой плотности подключения.Дополнительные затраты были слишком высокими и не масштабировались. В топологию также встроено множество средств контроля доступа и политик. Отсутствие плотности соединений на самом деле способствует этому подходу к безопасности, хотя и снижает гибкость.
ESB пытается решить эти проблемы с помощью ...
- Разрешение во время выполнения пунктов назначения / услуг / ресурсов
- Прозрачность местоположения
- Возможность подключения «любой-к-любому» и максимальная плотность подключения
- Разработано для избыточность, горизонтальная масштабируемость, переключение при отказе
- Политика, управление доступом, правила, извлеченные из топологии
- Уровень сети логического обмена сообщениями, реализованный поверх физического уровня сети обмена сообщениями
- Общее пространство имен
Таким образом, когда ваш заказчик запрашивает совместимость с ESB, он хочу такие вещи, как указано выше. С точки зрения приложения это также подразумевает ...
- Избегание сходства сообщений, таких как требования для обработки в строгой последовательности или адресации запросов только к определенным узлам, а не к общему сетевому назначению
- Возможность динамически разрешать адресаты при запуске времени (то есть добавить еще один экземпляр очереди, и он автоматически начнет получать трафик, удалить один и маршруты трафика к оставшимся узлам)
- Приложения запрашивающего и поставщика отделены от информации о том, где друг друга «живут».Запрашивающая сторона устанавливает одно соединение, независимо от того, сколько служб ему может потребоваться вызвать.
- Авторизация по политике, а не по топологии
- Приложения поставщика услуг, способные распознавать и обрабатывать дублирование (согласно спецификации JMS, см. «Функциональный дубликат» из-за обработка сеанса)
- Возможность запуска нескольких активных экземпляров приложения поставщика услуг
- Инструментирование приложений поставщика услуг, чтобы вы могли узнать о состоянии сети или выполнить тест без отправки фактической транзакции
С другой стороны стороны, если ваш клиент не может сформулировать эти вещи, он может просто установить флажок, который говорит «работает с ESB».
Изучив это немного, мои инстинкт говорит, что это просто Buzz говорят за то, что говорят, что нам нужно иметь независимый от платформы способ передачи сообщения туда и обратно
Вы правы, отчасти потому, что термин ESB - всегда хорошее слово, которое хорошо сочетается с другим модным словом, законным или нет - это управление (то есть помогает вам управлять тем, кто доступ к вашим конечным точкам и отчетность по метрикам - Метрики, кстати, это то, что хотят видеть все костюмы, так что это может быть вкладчик)
Еще одна причина, по которой им может потребоваться нейтральное платформенное устройство, заключается в том, чтобы любое сервисы, которые они потребляют, всегда отображаются как конечные точки из центрального местоположения, а не из определенного машинного ресурса. ESB делает фактические физические конечные точки ваших сервисов несущественными для них, о чем они в любом случае не должны особо заботиться, но позволяет перемещать сервисы, однако они будут использовать только конечную точку ESB.
Помимо централизованного репозитория для Discovery , ESB также упрощает параллельное управление версиями служб. Если бы у меня был выбор и у моей компании был бюджет, мы бы купили устройство IBM x150: (
В-третьих, многие более продвинутые шины, такие как продукт SoftwareAG, если я помню, изначально могут предоставлять устаревшие данные, например, из данные, размещенные на основных фреймах как службы без необходимости кодирования через адаптеры
, я не знаю, намерены ли они использовать все преимущества, предоставляемые ESB, или, как вы сказали, сделать его совместимым с модным словом.
Изучив это немного, я решил, что это просто разговоры о том, что нам нужен независимый от платформы способ передачи сообщений туда и обратно.
Это примерно верно. Иногда ESB идет немного дальше и включает дополнительные функции, такие как гарантии доставки сообщений, сообщения подтверждения / подтверждения и так далее. Наличие ESB также обычно явно или неявно создает новый протокол там, где его раньше не было, что является еще одним важным соображением. (То есть, должен быть установлен какой-то стандарт или интерфейс в отношении формата сообщений.)
Правильно ли я отклонил запрос наших партнеров как просто попытку сделать наше программное обеспечение более совместимым с модными словами, или они говорят нам что-то, что мы должны слушать (даже если они закодированы в разговорной речи)?
Вы всегда должны слушать своих клиентов, даже если поначалу это звучит глупо. Обычно стоит хотя бы потратить усилия, чтобы решить, что происходит. Читая между строк, ваши партнеры, вероятно, имеют в виду, что они хотят, чтобы ваш сервис мог легче интегрироваться с их собственными сервисами и продуктами.
Сервисная шина предприятия обрабатывает сообщения между системами стандартным образом. Это позволяет вам общаться с шиной одним и тем же способом на всех платформах, а шина обрабатывает фактический перевод на индивидуальный механизм связи, необходимый для конкретной конечной точки. Это означает, что вы пишете весь свой код для общения с шиной, используя общую схему обмена сообщениями, а шина берет вашу общую схему и переводит ее так, чтобы конечная точка ее понимала.