Может ли кто-нибудь объяснить мне служебный автобус предприятия в не-buzzspeak?

Ответ 1

Хотя ESB основан на обмене сообщениями, это не "просто" обмен сообщениями, а не просто модное слово.

Итак, если вы начинаете с простого старого асинхронного обмена сообщениями, ранние сети имеют тенденцию быть очень точными. Вам нужно было подключиться (то есть настроить через какой-то интерфейс администратора) каждое соединение и каждую пару пунктов назначения, и если вы осмелились что-то перемещать, то что-то сломалось. Поскольку точки подключения были подключены вручную, эти сети никогда не достигали высокой плотности соединения. Инкрементная стоимость была слишком высокой и не масштабировалась. В топологии также было много контроля доступа и политики. Отсутствие плотности соединения фактически благоприятствует этому подходу к безопасности, даже несмотря на то, что оно препятствует гибкости.

ESB пытается решить эти проблемы с помощью...

• Резервное время назначения пунктов назначения/услуг/ресурсов
• Прозрачность местоположения
• Связь между любыми подключениями и максимальной плотностью соединений
• Архивировано для избыточности, горизонтальной масштабируемости, отказоустойчивости
• Политика, контроль доступа, правила, внешние из топологии
• Уровень сетевой логики обмена сообщениями, реализованный на сетевом уровне физической сети обмена сообщениями.
• Общее пространство имен

Итак, когда ваш клиент спрашивает о совместимости с ESB, они хотят, чтобы все было так. С точки зрения приложения это также подразумевает...

• Избегайте аффинности сообщений, таких как требования к обработке в строгом порядке или для обращения к запросам только к определенным узлам, а не к универсальному назначению сети
• Возможность динамического назначения адресатов во время выполнения (т.е. добавляет другой экземпляр очереди и автоматически начинает получать трафик, удаляет один и маршруты трафика остальным узлам).
• Заявители и поставщики приложений отключены от знания, где друг друга "живет". Requestor делает одно соединение, независимо от того, сколько служб ему может понадобиться для вызова
• Авторизовать по политике, а не топологии
• Приложения поставщика услуг, способные распознавать и обрабатывать обманки (согласно спецификации JMS, см. "Функциональный дубликат" из-за обработки сеанса)
• Возможность запуска нескольких активных экземпляров приложения поставщика услуг
• Прикрепите приложения поставщика услуг, чтобы вы могли узнать о состоянии сети или выполнить тест без отправки фактической транзакции.

С другой стороны, если ваш клиент не может сформулировать эти вещи, они могут просто захотеть проверить коробку, в которой говорится: "Работает с ESB".

Ответ 2

Я постараюсь сохранить его без малейшего напряжения (но может произойти сокращение абзаца).

Когда службы/приложения/мейнфреймы/и т.д. хотят интегрировать (так что отправляйте сообщения друг другу), вы можете столкнуться с беспорядком. ESB скрывает, что беспорядок внутри себя (или он сам), чтобы организация могла притворяться, что нет беспорядка и что у него есть что-то управляемое. Затем он обертывает весь набор функций вокруг этого, чтобы сделать этот блок еще более привлекательным для старших людей в организации, которые примут решение купить такой дорогой продукт. Эти люди, как правило, захотят ввести большую инициативу, которая стоит больших денег, чтобы доказать, что они "что-то делают" и знают, как тратить большие деньги. Если это инициатива SOA, то различные поставщики заявили им, что ESB требуется, чтобы поставщики видят, как работает SOA (как правило, после того, как количество услуг, которое они могут захотеть, имеет тривиальное число).

Итак, ESB:

• Автомобиль для продавцов, чтобы заработать много денег;
• Автомобиль для консультантов, чтобы заработать много денег;
• Способ для руководителей высшего звена (ИТ-директоров и т.п.) показать, что они могут тратить много денег;
• Коробка для скрытия беспорядка;
• Общая PITA для технической команды, с которой можно работать.

Ответ 3

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

Вы правы, частично потому, что термин ESB - это всегда приятное слово, которое хорошо сочетается с другим модным словом, легитимным или нет - это управление (т.е. помогает вам управлять , кто обращается к вашим конечным точкам и отчетности показателей - Metrics btw - это то, что все костюмы любят видеть, так что это может быть вкладчиком)

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

Помимо централизованного хранилища Discovery, ESB также упрощает бонусное управление версиями. Если бы у меня был выбор, а у моей компании был бюджет, мы бы приобрели устройство IBM x150: (

В-третьих, многие более продвинутые шины, такие как продукт SoftwareAG, если я помню, изначально могут предоставлять устаревшие данные, например, из данных, которые находятся на основных кадрах, как службы без необходимости кодирования через адаптеры

Я не знаю, намерены ли они использовать все преимущества, предоставляемые ESB, или, как вы сказали, сделать его подходящим для модного слова.

Ответ 4

После изучения этого немного, мой инстинкт должен сказать, что это просто гул говорит, говоря, что нам нужно иметь платформенный способ передачи сообщений назад и вперед

Что о правильном. Иногда ESB будет идти немного дальше и включать дополнительные функции, такие как гарантии доставки сообщений, сообщения подтверждения/подтверждения и т.д. Наличие ESB также обычно явно или неявно создает новый протокол, где ранее не существовало, что является еще одним важным соображением. (То есть, какой-то стандарт или интерфейс должен быть установлен в отношении формата сообщений.)

Правильно ли я отклоняю запрос наших партнеров, просто пытаюсь заставить наше программное обеспечение быть более подходящим для модного слова, или они сообщают нам что-то, что мы должны слушать (даже если оно закодировано в buzzspeak)?

Вы всегда должны слушать своих клиентов, даже если это изначально звучит глупо. Обычно стоит хотя бы потратить усилия на то, чтобы решить, что происходит. Чтение между линиями, что, вероятно, означает ваш партнер, заключается в том, что они хотят, чтобы ваш сервис мог легче интегрироваться со своими услугами и продуктами.

Ответ 5

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

Ответ 6

Простейшим объяснением является объяснение того, что он предоставляет:

В течение многих лет компании приобретали разные платформы и технологии для достижения конкретных функций в своем бизнесе от финансов до HR. Эти системы должны были говорить друг с другом об обмене данными, поэтому промежуточное ПО стало клеем, который позволял им подключаться. До того, как бизнес знал об этом, они платили за поддержку и поддержку каждой из этих систем и промежуточного программного обеспечения. По мере того, как потребности в бизнесе изменились, департаменты решили создать свои собственные решения для удовлетворения особых потребностей, а не пытаться сделать решения для старения достаточно гибкими, чтобы удовлетворить их потребности. Прежде чем они это знали, они платили за поддержку и поддержку устаревших систем, промежуточного программного обеспечения и пользовательских решений. С новыми законами, такими как Sarbanes Oxley, компаниям необходимо иметь лучшую информацию для целей отчетности. Для одного представления требуется, чтобы они собирали данные из всех систем. Кроме того, ИТ-директорам сейчас оказывают давление на снижение затрат и увеличение обслуживания клиентов. Одним из очевидных решений является устранение редутантных систем, дорогостоящих контрактов на поддержку и магистраль, а также дорогостоящие унаследованные решения, требующие поддержки специалистов. Переход на новую платформу позволяет это, но должен быть переход. Нет готовых решений, которые могут повторить то, что делает бизнес. Чтобы удовлетворить потребности в перемещении информации вокруг них, они идут с SOA, поскольку это позволяет получить доступ к информации через общий объект. Если я попрошу AllEmployees из служебной шины получить их, будь то из 15 HR-систем или 1. Когда 15 HR-систем становятся 1 системой, вызов и результат не меняются, как это было сделано за кулисами. Концепция Service Bus стандартизирует поток информации и позволяет ИТ-менеджерам проводить переходы за шиной без долгосрочного эффекта для пользователей, работающих на восходящем пути.