我对 EJB3（也许太简单了）的理解是，它是一种将 POJO 转变为符合 Java EE 的业务逻辑单元的方法。它是可重用的，并且可以“插入”到跨多个项目的不同后端架构中。这是朝着真正的组件驱动架构方向迈出的一步。如果这些断言中的任何一个是不真实的，请先纠正我！！
如果我在这些项目上是正确的，那么我想知道 EJB3 是如何/在哪里/何时/如果像 Apache Camel 这样的 ESB 卡入的。使用 Camel，每个端点通常都会实现一些 EIP，例如WireTap、Filter或Transformer。我想知道 EJB（特别是 EJB3）适合哪些 EIP/SOA 模式。是不是很简单Filter？还有什么？
我想我的问题的根源是：
在这种情况下没有对错。
EJB 可以很好地插入 JavaEE 应用程序服务器，并被构建为提供一种架构，将业务逻辑封装为 EJB 中的 Java 代码，让应用程序服务器处理缩放、节流、故障转移、集群、负载平衡等，以及暴露EJB 到通信协议（Web 服务或消息驱动 Bean 的 JMS）。
我认为在 Apache Camel 中引入 EJB 作为业务逻辑容器没有任何意义，除非您已经拥有一个希望 Camel 使用的全栈 Java EE 应用程序。
Camel 有一组很棒的功能可以通过bean-binding连接到“真实的”pojos 。
我建议使用简单的 java beans/pojos 来实现业务逻辑，您可以通过 Camel 丰富的连接器集轻松地将它们插入任何其他应用程序。实施不同的骆驼 EIP 有多种选择。一种常见的方法是使用 java 代码，但用于转换的 XSLT 和用于过滤器的 groovy 也同样常见。我永远不会将 EJB 用于简单的过滤器，而是在 Java EE 应用程序中调用一些复杂的逻辑。服务器，或者通常避免一起使用（MDB 除外），而是查看 JMS 与应用程序服务器的通信。
基本上，EJB 是一项服务。服务背后的理念是可以简单地使用它，而无需将其创建为消费者。此外，服务通常可以在注册表中查找。
因此，我的建议是在易于实例化 bean impl 的情况下使用简单的 bean 集成，而在困难的情况下使用服务。因此，您可以将初始化封装在提供服务的组件内部。
我不经常使用 EJB，但经常使用在概念上与 EJB 非常相似的 OSGi 服务。
除了以前的答案，我还提到 SOA 是一种具有特定要求的方法，而不是具体的技术堆栈。至少让您的 EJB3 bean 或 OSGI 服务可以通过网络操作，而不管操作系统、平台和语言如何，您将拥有面向服务的系统。因此，当 EJB 和 OSGI 或 Spring 驱动的应用程序满足 SOA 的要求时，它们确实适合 SOA。