在 Camel 路线中，我是否应该考虑将业务逻辑放入离散托管的 bean 端点（例如消息驱动的 bean 或 Web 服务）中，而不是仅仅在 Camel 处理器中实现它？
使用 Camel 进行调解和处理似乎是更清晰的关注点分离。编排，使用处理器作为过滤器，而不是作为业务逻辑的容器。不过，我目前并不预见到需要 EJB 容器，而且似乎我需要一个来托管 MDB。
因此，更干净的架构与更小的占地面积、更少的技术相比——有人对此有想法、观点或强烈的感受吗？
In a Camel route, should I be thinking about putting my business logic in a discretely hosted bean endpoint, like a message-driven bean or a web service, vs just implementing it in Camel processors?
It seems like cleaner separation of concerns to use Camel just for mediation & orchestration, using Processors as filters, rather than as a container for business logic. However I don't forsee the need for an EJB container at this time, and it seems like I'd need one to host MDBs.
So cleaner architecture vs smaller footprint, fewer technologies - Does anyone have thoughts, perspectives, or strong feelings about this?
发布评论
评论（2）
我通常使用 Camel 执行以下操作...
否则，对于自包含的业务逻辑（尤其是遗留集成），最好使用 POJO 或 WebServices。这提高了可测试性并使您的应用程序更加模块化等。然后，您可以使用 Camel 进行以下操作...
对于长时间运行的流程，Camel 可以通过各种CXF 来促进这一点。 apache.org/async.html" rel="noreferrer">异步 模式/技术（JMS、CXF、轮询消费者、计划作业等），并让您能够控制 线程...
尽管如此，有很多方法可以对其进行切片。 Camel 轻量级、灵活，旨在轻松与现有技术集成，而不是取代它们......祝你好运
I generally use Camel to perform the following...
Otherwise, for business logic that is self contained (especially legacy integration), it may be preferable to use POJOs or WebServices. This promotes testability and makes your application more modular, etc. Then, you can use Camel for the following...
In regards to long running processes, Camel can facilitate this via various asycnhronous patterns/technologies (JMS, CXF, polling consumers, scheduled jobs, etc.) as well as gives you control over threading...
That all said, there are many ways to slice it. Camel is lightweight, flexible and designed to ease integration with existing technologies, not replace them...good luck
您应该尝试将路由或过滤等技术事物与业务逻辑分开。
因此，最重要的部分是不要将它们混淆在同一类中。将它们分成离散的部署单元可能有意义，但不太重要。
Camel 可以很好地用来实现“消息驱动 bean”。只需使用 pojos + JAXB 注释定义您的数据结构或从 XSD 生成它们。然后您可以使用camel pojo 消息传递将它们连接到http、jms 甚至文件端点。
请参阅 http://www.liquid-reality.de/x/NoBe
当您跑步时在 OSGi 上，一个显而易见的选择是将您的服务作为 OSGi 服务提供。然后可以在单独的捆绑包中使用 Camel 将这些服务连接到传输。这样你就可以让你的服务完全是纯java的。
您还可以使用 CXF 将您的服务作为 SOAP 服务或剩余资源提供。我更喜欢 XML，而不是使用 Camel 的 JMS，因为它更轻量级，并且由于 jms，在高可用性和负载平衡方面具有一些很好的优势。
You should try to separate technical things like routing or filtering from you business logic.
So the most important part is to not mix up these in the same class. To separate them into discrete deployment units may make sense but is less important.
Camel can be used very nicely to implement "message driven beans". Simply define your data structures using pojos + JAXB annotations or generate them from XSD. Then you can use camel pojo messaging to connect these to http, jms or even file endpoints.
See http://www.liquid-reality.de/x/NoBe
When you run on OSGi an obvious choice is to offer your services as OSGi services. Camel can then be used in a separate bundle to connect these services to the transports. This way you can make your services completely plain java.
You can also use CXF to offer your services as SOAP services or rest resources. I prefer XML over JMS with camel though as it is more light weight and has some nice advantages regarding high availability and load balancing thanks to jms.