ESB 通常会提供多少业务 logic/abstraction
How much business logic/abstraction would typically be provided by an ESB
我正在查看指定 ESB 的客户需求（不太详细）。我不是专业开发人员，我倾向于担任产品所有者类型的角色，但 ESB 是我以前从未真正了解过的一个术语。谷歌搜索显示它更像是一种架构风格而不是特定组件，提供各种数据传输和翻译服务以允许不同的应用程序松散耦合。
我想就 ESB 可能包含的内容征求一些专家意见。例如，如果我有一堆应用程序，其中许多应用程序都有从另一个应用程序接收 'command' 的概念，但每个应用程序都有不同的协议和内容，那么 ESB 可能会提供一种通用的 'send command' 方法，可以使用一系列协议的通用语法？本质上是跨应用程序提供高级 API？这些方法可能包括业务逻辑（例如优先发送哪些命令，根据当前操作条件拒绝命令等？）
ESB 通常会保存状态信息还是更短暂？例如，如果某些应用程序定期报告状态，是否可以将其保留在总线中以供其他应用程序检索（或者将其视为使用 ESB 的持久性应用程序）？我读过 ESB 通常包含消息传递功能，所以我猜是的，但我在这里追求的是典型的开发人员或架构师认为典型的 ESB 功能，以指导我如何解释需求和提出哪些问题问我什么时候和我们自己的建筑师说话。感谢这个问题相当广泛，但希望足以被视为一个可以接受的问题。
您在这里提出了一个非常宽泛的问题，而且这个问题充满了您的特定架构师可能不具备的意见和最佳实践。此处给出的任何建议都注定过于宽泛，通常只会让您与架构师争论不休。
与您的架构师进行这种对话比与 Whosebug 进行对话要好得多。做出免责声明，请阅读来自 MuleSoft 的这篇文章。它很好地概述了 ESB 的一般功能和用途。这需要考虑到您的组织可能以不同方式使用它这一事实。 ESB 是一种工具，它适合您的环境的地方可能不适用于其他组织的环境。
您询问的事情都可以用 ESB 完成，是否应该完成取决于您的架构师如何设计解决方案。继续阅读这篇文章，然后与您的架构师就如何在您的组织中使用这项技术进行开诚布公的对话。
由于您的问题基础广泛，我想为您提供一个概述，并从您 post 编辑的内容中挑选一些您的问题。希望此信息对您有所帮助。
ESB 可能包括什么？
ESB 允许业务信息在跨多个硬件和软件平台的不同应用程序之间流动。 ESB 更像是一个中间件层，它包含应用程序连接逻辑和最少甚至没有业务逻辑。这允许应用程序做它最擅长的事情，而不必担心嵌入任何关于如何与其他 N 个需要它的数据的应用程序交互的连接逻辑。 ESB 架构试图解决企业中点对点的混乱局面。
下面列出了 ESB 的许多重要功能中的一小部分：
Data transformation : For example, XML to JSON format or JSON to CSV format
Protocol transformation : For example, FTP to HTTPS
Enrichment : Data passing through ESB layer could be enriched before delivery to destination
Routing : Based on payload or pre-determined rules, route data to appropriate destination
下面的wiki页面，对ESB进行了详细的描述，包括ESB名称的由来。
https://en.wikipedia.org/wiki/Enterprise_service_bus
ESB 通常会保存状态信息还是更短暂？
理想情况下，ESB 不应保存任何状态信息。特别是，现在所有 ESB 供应商都在从单体 ESB 部署转向基于微服务的部署。企业有一个单独的消息层来临时排队数据。消息传递允许您的应用程序解耦。例如，当 App A 想要与 App B 通话时，App B 必须在线。但是，如果应用程序 A 可以在消息传递层中删除消息，那么在这种情况下，应用程序 B 无需等待来自应用程序 A 的消息。它可以在准备好时从消息传递层选择数据自己的节奏。这样 App A 和 App B 就相互解耦了。您可以在消息和队列上查看以下 link => https://en.wikipedia.org/wiki/Message_queuing_service
您可能应该开始了解企业中当前的应用程序环境以及应用程序如何相互交互。由于 ESB 已在您的 post 中提及，请讨论通过集成层（ESB 是其中的一个组件）的数据可见性。例如，假设应用程序 A 推送数据，而应用程序 B 抱怨没有收到来自最终业务用户的数据，他如何在联系应用程序支持团队之前进行调查。此外，您可能想了解 ESB 的治理方面。
我正在查看指定 ESB 的客户需求（不太详细）。我不是专业开发人员，我倾向于担任产品所有者类型的角色，但 ESB 是我以前从未真正了解过的一个术语。谷歌搜索显示它更像是一种架构风格而不是特定组件，提供各种数据传输和翻译服务以允许不同的应用程序松散耦合。
我想就 ESB 可能包含的内容征求一些专家意见。例如，如果我有一堆应用程序，其中许多应用程序都有从另一个应用程序接收 'command' 的概念，但每个应用程序都有不同的协议和内容，那么 ESB 可能会提供一种通用的 'send command' 方法，可以使用一系列协议的通用语法？本质上是跨应用程序提供高级 API？这些方法可能包括业务逻辑（例如优先发送哪些命令，根据当前操作条件拒绝命令等？）
ESB 通常会保存状态信息还是更短暂？例如，如果某些应用程序定期报告状态，是否可以将其保留在总线中以供其他应用程序检索（或者将其视为使用 ESB 的持久性应用程序）？我读过 ESB 通常包含消息传递功能，所以我猜是的，但我在这里追求的是典型的开发人员或架构师认为典型的 ESB 功能，以指导我如何解释需求和提出哪些问题问我什么时候和我们自己的建筑师说话。感谢这个问题相当广泛，但希望足以被视为一个可以接受的问题。
您在这里提出了一个非常宽泛的问题，而且这个问题充满了您的特定架构师可能不具备的意见和最佳实践。此处给出的任何建议都注定过于宽泛，通常只会让您与架构师争论不休。
与您的架构师进行这种对话比与 Whosebug 进行对话要好得多。做出免责声明，请阅读来自 MuleSoft 的这篇文章。它很好地概述了 ESB 的一般功能和用途。这需要考虑到您的组织可能以不同方式使用它这一事实。 ESB 是一种工具，它适合您的环境的地方可能不适用于其他组织的环境。
您询问的事情都可以用 ESB 完成，是否应该完成取决于您的架构师如何设计解决方案。继续阅读这篇文章，然后与您的架构师就如何在您的组织中使用这项技术进行开诚布公的对话。
由于您的问题基础广泛，我想为您提供一个概述，并从您 post 编辑的内容中挑选一些您的问题。希望此信息对您有所帮助。
ESB 可能包括什么？
ESB 允许业务信息在跨多个硬件和软件平台的不同应用程序之间流动。 ESB 更像是一个中间件层，它包含应用程序连接逻辑和最少甚至没有业务逻辑。这允许应用程序做它最擅长的事情，而不必担心嵌入任何关于如何与其他 N 个需要它的数据的应用程序交互的连接逻辑。 ESB 架构试图解决企业中点对点的混乱局面。
下面列出了 ESB 的许多重要功能中的一小部分：
Data transformation : For example, XML to JSON format or JSON to CSV format
Protocol transformation : For example, FTP to HTTPS
Enrichment : Data passing through ESB layer could be enriched before delivery to destination
Routing : Based on payload or pre-determined rules, route data to appropriate destination
下面的wiki页面，对ESB进行了详细的描述，包括ESB名称的由来。 https://en.wikipedia.org/wiki/Enterprise_service_bus
ESB 通常会保存状态信息还是更短暂？
理想情况下，ESB 不应保存任何状态信息。特别是，现在所有 ESB 供应商都在从单体 ESB 部署转向基于微服务的部署。企业有一个单独的消息层来临时排队数据。消息传递允许您的应用程序解耦。例如，当 App A 想要与 App B 通话时，App B 必须在线。但是，如果应用程序 A 可以在消息传递层中删除消息，那么在这种情况下，应用程序 B 无需等待来自应用程序 A 的消息。它可以在准备好时从消息传递层选择数据自己的节奏。这样 App A 和 App B 就相互解耦了。您可以在消息和队列上查看以下 link => https://en.wikipedia.org/wiki/Message_queuing_service
您可能应该开始了解企业中当前的应用程序环境以及应用程序如何相互交互。由于 ESB 已在您的 post 中提及，请讨论通过集成层（ESB 是其中的一个组件）的数据可见性。例如，假设应用程序 A 推送数据，而应用程序 B 抱怨没有收到来自最终业务用户的数据，他如何在联系应用程序支持团队之前进行调查。此外，您可能想了解 ESB 的治理方面。