Architecture 骆驼处理器与服务端点中的业务逻辑

在Camel路径中，我应该考虑将业务逻辑放在一个离散托管的bean端点中，比如消息驱动bean或web服务，而不是仅仅在Camel处理器中实现它吗

将Camel仅用于中介和编排，将处理器用作过滤器，而不是作为业务逻辑的容器，这似乎是更清晰的关注点分离。然而，目前我并不认为需要EJB容器，似乎我需要一个容器来承载MDB

---

因此，更清洁的体系结构与更小的占地面积、更少的技术相比——有人对此有想法、观点或强烈的感觉吗？

我通常使用Camel来执行以下操作

• 任何集成（文件、jms、http等）
• 实现逻辑（基于内容的路由、筛选器、限制等）
• 基于计时器的进程（使用或）
• 异常处理（重试逻辑、错误记录/通知/排队）

否则，对于自包含的业务逻辑（特别是遗留集成），最好使用POJO或WebServices。这提高了可测试性，使您的应用程序更加模块化，等等。然后，您可以使用Camel实现以下功能

• 使用与这些服务交互，以及
• 将这些服务连接成路由
• 管理/监视消息流、异常处理

对于长时间运行的流程，Camel可以通过各种模式/技术（JMS、CXF、轮询消费者、计划作业等）促进这一点，并让您能够控制

---

总而言之，有很多方法可以分割它。Camel轻量级、灵活，旨在简化与现有技术的集成，而不是取代它们……祝您好运

您应该尝试将路由或过滤等技术内容从业务逻辑中分离出来

所以最重要的一点是不要把它们混在同一个班级里。将它们分离为独立的部署单元可能有意义，但不那么重要

Camel可以很好地用于实现“消息驱动bean”。只需使用POJO+JAXB注释定义您的数据结构，或者从XSD生成它们。然后，您可以使用camelpojo消息传递将它们连接到http、jms甚至文件端点

看

当您在OSGi上运行时，一个明显的选择是将您的服务作为OSGi服务提供。然后，可以在单独的包中使用Camel将这些服务连接到传输。通过这种方式，您可以使您的服务完全纯java

---

您还可以使用CXF将您的服务作为SOAP服务或rest资源提供。不过，我更喜欢XML而不是带有camel的JMS，因为它重量更轻，而且由于JMS，在高可用性和负载平衡方面有一些很好的优势。

谢谢@boday！我的主要问题应该是“在不拖拽EJB容器的情况下，我可以把业务逻辑放在哪里？”——我不知道消息驱动的POJO和bean绑定很酷…是的，POJO/Beans是所有定制业务逻辑应该去的地方…如果想将Camel排除在测试等式之外，效果非常好，等等。。。